En este documento se explica cómo planificar las direcciones IP para una instalación de Google Distributed Cloud.
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 estos elementos:
Una estación de trabajo de administrador
Un clúster de administradores de alta disponibilidad
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
En este ejemplo, los clústeres de usuarios tienen habilitado Controlplane V2. Con Controlplane V2, los nodos de plano de control de un clúster de usuarios se encuentran en el propio clúster de usuarios.
Si no quieres habilitar Controlplane V2 en tus clústeres de usuario, consulta Planificar tus direcciones IP (kubeception). El término kubeception hace referencia al caso en el que el plano de control de un clúster de usuario se ejecuta en uno o varios nodos del clúster de administrador. No recomendamos usar kubeception. Te recomendamos que habilites Controlplane V2.
Nodos de clúster de administrador
Un clúster de administrador tiene tres nodos, cada uno de los cuales ejecuta componentes del plano de control.
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
El clúster de administrador de este ejemplo tiene tres nodos, por lo que debe definir tres direcciones IP. Por ejemplo, puedes reservar las siguientes direcciones IP para los nodos del clúster de administrador:
| Clúster de administradores | Direcciones IP |
|---|---|
| Clúster de administradores de alta disponibilidad | 172.16.20.2 - 172.16.20.4 |
Direcciones IP de ejemplo: IP virtual del clúster de administrador
Debes reservar una IP virtual para el servidor de la API de Kubernetes del clúster de administrador.
Ten en cuenta que, en el archivo de configuración del clúster, el campo de este VIP se llama
controlPlaneVIP. Por ejemplo, puedes reservar la siguiente IP virtual para el servidor de la API de Kubernetes del clúster de administrador:
| VIP | Dirección IP |
|---|---|
| VIP del servidor de la API de Kubernetes del clúster de administrador | 172.16.20.30 |
Ten en cuenta que, en los clústeres de administrador de alta disponibilidad, controlPlaneVIP debe estar en la misma VLAN que las IPs de los nodos del plano de control especificadas en network.controlPlaneIPBlock.
Ejemplo de direcciones IP: nodos del clúster de usuario 1
En el caso de un clúster de usuarios con ocho nodos, debes reservar nueve direcciones IP. La dirección adicional es obligatoria, ya que 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.10 |
Ejemplo de direcciones IP: IPs virtuales del clúster de usuario 1
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 |
|---|---|---|
| VIP del servidor de la API de Kubernetes del clúster de usuario 1 | Configurado en el balanceador de carga del clúster de usuarios 1 | 172.16.21.30 |
| 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.31 |
| 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.31 - 172.16.21.40 |
Ten en cuenta que el VIP del servidor de la API de Kubernetes se especifica en loadBalancer.vips.controlPlaneVIP del archivo de configuración del clúster. Cuando ControlPlane V2 está habilitado, controlPlaneVIP debe estar en la misma VLAN que las IPs de los nodos del plano de control especificadas en network.controlPlaneIPBlock.
Ejemplo de direcciones IP: clúster de usuario con 2 nodos
En el caso de un clúster de usuarios que tenga cinco nodos, debes reservar seis direcciones IP. La dirección adicional es obligatoria, ya que 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.7 |
Direcciones IP de ejemplo: IPs virtuales del clúster de usuario 2
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 |
|---|---|---|
| VIP del servidor de la API de Kubernetes del clúster de usuario 2 | Configurado en el balanceador de carga del clúster de usuarios 2 | 172.16.22.30 |
| 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.31 |
| 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.31 - 172.16.22.40 |
Ten en cuenta que el VIP del servidor de la API de Kubernetes se especifica en loadBalancer.vips.controlPlaneVIP del archivo de configuración del clúster. Cuando ControlPlane V2 está habilitado, controlPlaneVIP debe estar en la misma VLAN que las IPs de los nodos del plano de control especificadas en network.controlPlaneIPBlock.
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.
Evita las 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