En este documento, se muestra cómo planificar tus direcciones IP para una instalación de Google Distributed Cloud.
Antes de comenzar
Lee la descripción general de Google Distributed Cloud y la descripción general de la instalación.
Ejemplo de asignación de dirección 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 administrador con alta disponibilidad (HA)
Un clúster de usuario con alta disponibilidad que tiene cinco nodos trabajadores
Un clúster de usuario sin alta disponibilidad que tiene cuatro nodos trabajadores
En este ejemplo, los clústeres de usuario tienen habilitado Controlplane V2. Con Controlplane V2, los nodos del plano de control para un clúster de usuario están en el clúster de usuario.
Si no deseas habilitar Controlplane V2 para tus clústeres de usuario, consulta Planifica 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 más nodos del clúster de administrador. No recomendamos usar kubeception. Te recomendamos que habilites ControlPlane V2.
Nodos del clúster del administrador
Un clúster de administrador tiene tres nodos, cada uno de los cuales ejecuta componentes del plano de control.
Balanceo de cargas
Para este ejemplo, supongamos que los clústeres usan el balanceador de cargas MetalLB. Este balanceador de cargas se ejecuta en los nodos del clúster, por lo que no se necesitan VM adicionales para el balanceo de cargas
Subredes
Para este ejemplo, supongamos que cada clúster se encuentra en su propia VLAN y que los clústeres se encuentran en estas subredes:
| VM | Subred | Puerta de enlace predeterminada |
|---|---|---|
| Estación de trabajo de administrador y clúster de administrador | 172.16.20.0/24 | 172.16.20.1 |
| Clúster de usuario 1 | 172.16.21.0/24 | 172.16.21.1 |
| Clúster de usuario 2 | 172.16.22.0/24 | 172.16.22.1 |
En el siguiente diagrama, se ilustran las tres VLAN y subredes. Ten en cuenta que las VIP no se muestran asociadas con ningún nodo en particular en un clúster. Esto se debe a que el balanceador de cargas de MetalLB puede elegir qué nodo anuncia la VIP para un Service individual. Por ejemplo, en el clúster de usuario 1, un nodo trabajador podría anunciar 172.16.21.31 y otro nodo trabajador 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 de administrador se encuentra en la misma subred que el clúster de administrador: 172.16.20.0/24. Una dirección cercana a las direcciones de nodo sería adecuada para la estación de trabajo de administrador. Por ejemplo, 172.16.20.20.
Direcciones IP de ejemplo: nodos del clúster de administrador
El clúster de administrador en este ejemplo tiene tres nodos, por lo que debes configurar tres direcciones IP. Por ejemplo, puedes reservar las siguientes direcciones IP para los nodos del clúster de administrador:
| Clúster de administrador | Direcciones IP |
|---|---|
| Clúster de administrador con alta disponibilidad | 172.16.20.2 - 172.16.20.4 |
Direcciones IP de ejemplo: VIPs para el clúster de administrador
Debes reservar una VIP 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 esta VIP se llama controlPlaneVIP. Por ejemplo, puedes reservar la siguiente VIP para el servidor de la API de Kubernetes del clúster de administrador:
| VIP | Dirección IP |
|---|---|
| Es la VIP para el servidor de la API de Kubernetes del clúster de administrador | 172.16.20.30 |
Ten en cuenta que, para los clústeres de administrador de HA, controlPlaneVIP debe estar en la misma VLAN que las IP de los nodos del plano de control especificados en network.controlPlaneIPBlock.
Direcciones IP de ejemplo: Nodos del clúster de usuario 1
Para un clúster de usuario que tiene ocho nodos, debes reservar nueve direcciones IP. La dirección adicional es obligatoria, ya que se necesita durante la actualización, la reparación automática y las actualizaciones del clúster. Por ejemplo, puedes reservar las siguientes direcciones IP para los nodos del clúster de usuario 1:
| Direcciones IP para los nodos del clúster de usuario 1 |
|---|
| 172.16.21.2 - 172.16.21.10 |
Direcciones IP de ejemplo: VIP para el clúster de usuario 1
En la siguiente tabla, se muestra un ejemplo de cómo podrías designar las VIP que se configurarán en el balanceador de cargas para el clúster de usuario 1:
| VIP | Descripción | Dirección IP |
|---|---|---|
| VIP para el servidor de la API de Kubernetes del clúster de usuario 1 | Configurado en el balanceador de cargas para el clúster de usuario 1 | 172.16.21.30 |
| VIP de entrada para el clúster de usuario 1 | Configurado en el balanceador de cargas para el clúster de usuario 1 | 172.16.21.31 |
| VIP de servicio para el clúster de usuario 1 | Diez direcciones para los Services de tipo LoadBalancer.Se configura según sea necesario en el balanceador de cargas para el clúster de usuario 1. Observa que este rango incluye la VIP de entrada. Este es un requisito para el balanceador de cargas de MetalLB. |
172.16.21.31 - 172.16.21.40 |
Ten en cuenta que la VIP para el 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, el controlPlaneVIP debe estar en la misma VLAN que las IPs de los nodos del plano de control especificados en network.controlPlaneIPBlock.
Direcciones IP de ejemplo: Nodos de clúster de usuario 2
Para un clúster de usuario que tiene cinco nodos, debes reservar seis direcciones IP. La dirección adicional es obligatoria, ya que se necesita durante la actualización, la reparación automática y las actualizaciones del clúster. 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 usuario 2 |
|---|
| 172.16.22.2 - 172.16.22.7 |
Direcciones IP de ejemplo: VIP para el clúster de usuario 2
En la siguiente tabla, se muestra un ejemplo de cómo podrías designar las VIP que se configurarán en el balanceador de cargas para el clúster de usuario 2:
| VIP | Descripción | Dirección IP |
|---|---|---|
| VIP para el servidor de la API de Kubernetes del clúster de usuario 2 | Configurado en el balanceador de cargas para el clúster de usuario 2 | 172.16.22.30 |
| VIP de entrada para el clúster de usuario 2 | Configurado en el balanceador de cargas para el clúster de usuario 2 | 172.16.22.31 |
| VIP de servicio para el clúster de usuario 2 | Diez direcciones para los Services de tipo LoadBalancer.Se configura según sea necesario en el balanceador de cargas para el clúster de usuario 2. Observa que este rango incluye la VIP de entrada. Este es un requisito para el balanceador de cargas de MetalLB. |
172.16.22.31 - 172.16.22.40 |
Ten en cuenta que la VIP para el 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, el controlPlaneVIP debe estar en la misma VLAN que las IPs de los nodos del plano de control especificados en network.controlPlaneIPBlock.
Direcciones IP de ejemplo: Pods y Services
Antes de crear un clúster, debes especificar un rango CIDR para usar en las direcciones IP del Pod y otro rango en CIDR que se usará en las direcciones ClusterIP de los servicios de Kubernetes.
Decide qué rangos CIDR quieres usar para los Pods y Services. Por ejemplo:
| Objetivo | Rango de CIDR |
|---|---|
| Pods en el clúster de administrador | 192.168.0.0/16 |
| Pods en el clúster de usuario 1 | 192.168.0.0/16 |
| Pods en el clúster de usuario 2 | 192.168.0.0/16 |
| Services en el clúster de administrador | 10.96.232.0/24 |
| Services en el clúster de usuario 1 | 10.96.0.0/20 |
| Services en el clúster de usuario 2 | 10.96.128.0/20 |
En los ejemplos anteriores, se ilustran estos puntos:
El rango de CIDR de Pod puede ser el mismo para varios clústeres.
Por lo general, necesitarás más Pods que Services, por lo que, para un clúster determinado, es probable que quieras un rango de CIDR de pod que sea mayor que el rango de CIDR del Service. El rango de Pod de ejemplo para un clúster de usuario es 192.168.0.0/16, que tiene 2^(32-16) = 2^16 direcciones. Sin embargo, un ejemplo de rango de Service para un clúster de usuario es de 10.96.0.0/20, que solo tiene 2^(32-20) = 2^12 direcciones.
Evita la superposición
Se recomienda usar rangos CIDR no predeterminados para evitar la superposición con las direcciones IP a las que se pueda acceder en tu red. Los rangos de Service y Pod no deben superponerse con ninguna dirección fuera del clúster a la que deseas llegar desde dentro del clúster.
Por ejemplo, supongamos que el rango de Service es 10.96.232.0/24 y el rango de Pod es 192.168.0.0/16 (192.168.0.1 - 192.168.255.254). El tráfico enviado desde un Pod a una dirección en cualquiera de esos rangos se tratará como tráfico en el clúster y no llegará a ningún destino fuera del clúster.
En particular, los rangos de Service y Pod no deben superponerse con lo siguiente:
Direcciones IP de nodos en cualquier clúster
Direcciones IP que usan las máquinas del balanceador de cargas
VIP que usan los balanceadores de cargas y los nodos del plano de control
Direcciones IP de los servidores de vCenter, DNS y NTP
Recomendamos que los rangos de Service y Pod estén en el espacio de direcciones privadas RFC 1918.
Esta es una razón para que la recomendación use direcciones RFC 1918. Supongamos que tu rango de Pod o Service contiene direcciones IP externas. Cualquier tráfico enviado desde un Pod a una de esas direcciones externas se tratará como tráfico en el clúster y no llegará al destino externo.
Servidor DNS y puerta de enlace predeterminada
Antes de completar los archivos de configuración, debes conocer la dirección IP de un servidor DNS que pueden usar la estación de trabajo de administrador y los nodos del clúster.
También debes conocer la dirección IP de la puerta de enlace predeterminada para cada una de las subredes. En los ejemplos anteriores, la puerta de enlace predeterminada para cada subred es la primera dirección en el rango. 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
Administra las direcciones IP del nodo