En este documento se explica cómo planificar las direcciones IP para una instalación de Google Distributed Cloud que incluya clústeres de usuarios que utilicen kubeception.
¿Qué es kubeception?
El término kubeception se usa para transmitir la idea de que un clúster de Kubernetes se utiliza para crear y gestionar otros clústeres de Kubernetes. En el contexto de Google Distributed Cloud, kubeception se refiere al caso en el que el plano de control de un clúster de usuario se ejecuta en uno o varios nodos de un clúster de administrador.
No recomendamos usar kubeception. En su lugar, le recomendamos que utilice Controlplane V2. Con Controlplane V2, los nodos de plano de control del clúster de usuarios se encuentran en el propio clúster de usuarios.
Antes de empezar
Consulta la descripción general de Google Distributed Cloud y la descripción general de la instalación.
Ejemplo de asignación de direcciones IP
En esta sección se muestra un ejemplo de cómo asignar direcciones IP estáticas en una instalación que incluye los siguientes elementos:
Una estación de trabajo de administrador
Un clúster de administrador
Un clúster de usuarios de alta disponibilidad con cinco nodos de trabajador
Un clúster de usuarios sin alta disponibilidad que tiene cuatro nodos de trabajador
Nodos de clúster de administrador
El clúster de administrador tiene siete nodos:
- Un nodo que ejecuta el plano de control del clúster de administrador
- Dos nodos que ejecutan complementos para el clúster de administrador
- Tres nodos que ejecutan el plano de control del clúster de usuarios de alta disponibilidad
- Un nodo que ejecuta el plano de control del clúster de usuarios sin alta disponibilidad
Balanceo de carga
En este ejemplo, se da por supuesto que los clústeres usan el balanceador de carga MetalLB. Este balanceador de carga se ejecuta en los nodos del clúster, por lo que no se necesitan máquinas virtuales adicionales para el balanceo de carga.
Subredes
En este ejemplo, supongamos que cada clúster está en su propia VLAN y que los clústeres se encuentran en estas subredes:
| VMs | Subred | Pasarela predeterminada |
|---|---|---|
| Estación de trabajo de administrador y clúster de administrador | 172.16.20.0/24 | 172.16.20.1 |
| Clúster de usuarios 1 | 172.16.21.0/24 | 172.16.21.1 |
| Clúster de usuarios 2 | 172.16.22.0/24 | 172.16.22.1 |
En el siguiente diagrama se muestran las tres VLANs y subredes. Ten en cuenta que los VIPs no se muestran asociados a ningún nodo concreto de un clúster. Esto se debe a que el balanceador de carga de MetalLB puede elegir qué nodo anuncia la dirección IP virtual de un servicio concreto. Por ejemplo, en el clúster de usuarios 1, un nodo de trabajo podría anunciar 172.16.21.31 y otro nodo de trabajo podría anunciar 172.16.21.32.
Dirección IP de ejemplo: estación de trabajo de administrador
En este ejemplo, la estación de trabajo del administrador está en la misma subred que el clúster del administrador: 172.16.20.0/24. Una dirección cercana a las direcciones de los nodos sería adecuada para la estación de trabajo de administrador. Por ejemplo, 172.16.20.20.
Direcciones IP de ejemplo: nodos de clúster de administrador
En el caso de un clúster de administrador que tenga siete nodos, debes reservar ocho direcciones IP. La dirección adicional es obligatoria porque se necesita durante la actualización del clúster, la actualización y la reparación automática. Por ejemplo, puedes reservar las siguientes direcciones IP para los nodos de tu clúster de administrador:
| Direcciones IP de los nodos del clúster de administración |
|---|
| 172.16.20.2 - 172.16.20.9 |
Direcciones IP de ejemplo: IPs virtuales en la subred del clúster de administrador
En la siguiente tabla se muestra un ejemplo de cómo podrías designar VIPs para que se configuren en el balanceador de carga del clúster de administrador. Ten en cuenta que las IPs virtuales de los servidores de la API de Kubernetes de los clústeres de usuario se encuentran en la subred del clúster de administrador. Esto se debe a que, en este ejemplo, el servidor de la API de Kubernetes de un clúster de usuario se ejecuta en un nodo del clúster de administrador. Ten en cuenta que, en los archivos de configuración del clúster, el campo en el que se especifica la dirección IP virtual de un servidor de la API de Kubernetes se llama controlPlaneVIP:
| VIP | Dirección IP |
|---|---|
| VIP del servidor de la API de Kubernetes del clúster de administrador | 172.16.20.30 |
| VIP de complementos de clústeres de administradores | 172.16.20.31 |
| VIP del servidor de la API de Kubernetes del clúster de usuario 1 | 172.16.20.32 |
| VIP del servidor de la API de Kubernetes del clúster de usuario 2 | 172.16.20.33 |
Ejemplo de direcciones IP: nodos del clúster de usuario 1
En el caso de un clúster de usuarios que tenga cinco nodos, debes reservar seis direcciones IP. La dirección adicional es obligatoria porque se necesita durante la actualización del clúster, la actualización y la reparación automática. Por ejemplo, puedes reservar las siguientes direcciones IP para los nodos del clúster de usuarios 1:
| Direcciones IP de los nodos del clúster de usuario 1 |
|---|
| 172.16.21.2 - 172.16.21.7 |
Direcciones IP de ejemplo: IPs virtuales de la subred 1 del clúster de usuario
En la siguiente tabla se muestra un ejemplo de cómo podría designar a los clientes VIP para que se configuren en el balanceador de carga del clúster de usuarios 1:
| VIP | Descripción | Dirección IP |
|---|---|---|
| IP virtual de Ingress del clúster de usuarios 1 | Configurado en el balanceador de carga del clúster de usuarios 1 | 172.16.21.30 |
| VIPs de servicio del clúster de usuarios 1 | Diez direcciones de servicios de tipo LoadBalancer.Configurado según sea necesario en el balanceador de carga del clúster de usuarios 1. Ten en cuenta que este intervalo incluye el VIP de entrada. Este es un requisito del balanceador de carga MetalLB. |
172.16.21.30 - 172.16.21.39 |
Ejemplo de direcciones IP: clúster de usuario con 2 nodos
En el caso de un clúster de usuarios que tenga cuatro nodos, debes reservar cinco direcciones IP. La dirección adicional es obligatoria porque se necesita durante la actualización del clúster, la actualización y la reparación automática. Por ejemplo, puedes reservar las siguientes direcciones IP para los nodos del clúster de usuario 2:
| Direcciones IP de los nodos del clúster de usuarios 2 |
|---|
| 172.16.22.2 - 172.16.22.6 |
Direcciones IP de ejemplo: IPs virtuales de la subred 2 del clúster de usuario
En la siguiente tabla se muestra un ejemplo de cómo podría designar a los clientes VIP para que se configuren en el balanceador de carga del clúster de usuarios 2:
| VIP | Descripción | Dirección IP |
|---|---|---|
| IP virtual de Ingress del clúster de usuarios 2 | Configurado en el balanceador de carga del clúster de usuarios 2 | 172.16.22.30 |
| VIPs de servicio del clúster de usuarios 2 | Diez direcciones de servicios de tipo LoadBalancer.Configurado según sea necesario en el balanceador de carga del clúster de usuario 2. Ten en cuenta que este intervalo incluye el VIP de entrada. Este es un requisito del balanceador de carga MetalLB. |
172.16.22.30 - 172.16.22.39 |
Direcciones IP de ejemplo: pods y servicios
Antes de crear un clúster, debes especificar un intervalo CIDR que se usará para las direcciones IP de los pods y otro intervalo CIDR que se usará para las direcciones ClusterIP de los servicios de Kubernetes.
Decide qué intervalos CIDR quieres usar para los pods y los servicios. Por ejemplo:
| Finalidad | Intervalo CIDR |
|---|---|
| Pods del clúster de administrador | 192.168.0.0/16 |
| Pods del clúster de usuarios 1 | 192.168.0.0/16 |
| Pods del clúster de usuarios 2 | 192.168.0.0/16 |
| Servicios del clúster de administrador | 10.96.232.0/24 |
| Servicios del clúster de usuario 1 | 10.96.0.0/20 |
| Servicios del clúster de usuario 2 | 10.96.128.0/20 |
Los ejemplos anteriores ilustran estos puntos:
El intervalo CIDR de los pods puede ser el mismo en varios clústeres.
Normalmente, necesitas más pods que servicios, por lo que, en un clúster determinado, probablemente quieras que el intervalo CIDR de los pods sea mayor que el intervalo CIDR de los servicios. El intervalo de pods de ejemplo de un clúster de usuarios es 192.168.0.0/16, que tiene 2^(32-16) = 2^16 direcciones. Sin embargo, un intervalo de servicio de ejemplo para un clúster de usuarios es 10.96.0.0/20, que solo tiene 2^(32-20) = 2^12 direcciones.
Evitar superposiciones
Puede usar intervalos CIDR no predeterminados para evitar que se solapen con las direcciones IP a las que se puede acceder en su red. Los intervalos de servicios y pods no deben solaparse con ninguna dirección fuera del clúster a la que quieras acceder desde dentro del clúster.
Por ejemplo, supongamos que tu intervalo de servicio es 10.96.232.0/24 y tu intervalo de pods es 192.168.0.0/16 (192.168.0.1 - 192.168.255.254). Todo el tráfico enviado desde un pod a una dirección de cualquiera de esos intervalos se tratará como tráfico dentro del clúster y no llegará a ningún destino fuera del clúster.
En concreto, los intervalos de servicios y pods no deben solaparse con lo siguiente:
Direcciones IP de los nodos de cualquier clúster
Direcciones IP que utilizan las máquinas del balanceador de carga
IPs virtuales usadas por los nodos del plano de control y los balanceadores de carga
Direcciones IP de los servidores de vCenter, los servidores DNS y los servidores NTP
Te recomendamos que los intervalos de servicio y de pod estén en el espacio de direcciones privadas RFC 1918.
Este es uno de los motivos por los que se recomienda usar direcciones RFC 1918. Supongamos que el intervalo de tu pod o servicio contiene direcciones IP externas. El tráfico enviado desde un pod a una de esas direcciones externas se tratará como tráfico dentro del clúster y no llegará al destino externo.
Servidor DNS y pasarela predeterminada
Antes de rellenar los archivos de configuración, debes conocer la dirección IP de un servidor DNS que puedan usar tu estación de trabajo de administrador y los nodos del clúster.
También debe conocer la dirección IP de la puerta de enlace predeterminada de cada una de sus subredes. En los ejemplos anteriores, la puerta de enlace predeterminada de cada subred es la primera dirección del intervalo. Por ejemplo, en la subred del clúster de administrador, la puerta de enlace predeterminada se muestra como 172.16.20.1.
Más información
Gestionar direcciones IP de nodos