Administración de direcciones de GKE: Optimización de direcciones IPv4

Este documento es parte de una serie destinada a los arquitectos de red. En la serie, se analizan las opciones de administración de direcciones de Google Kubernetes Engine (GKE) disponibles para las organizaciones con restricción de dirección IPv4.

La serie consta de las siguientes partes:

En este documento, se describe un proceso para identificar los requisitos del bloque de CIDR de GKE. Luego, se presenta un modelo de decisión que te ayuda a identificar qué solución se recomienda para cualquier situación en particular. Por último, en el documento se explican varias soluciones, se las describe de forma breve y se enumeran sus ventajas y desventajas.

Identificación de los requisitos del bloque de CIDR de GKE

En esta sección, debes determinar los tamaños de los bloques de CIDR para el clúster. Es fundamental que lo hagas de forma correcta porque no puedes cambiar ni expandir un bloque de CIDR una vez que creaste el clúster.

Determina el tamaño del bloque de CIDR del nodo

Sigue estos pasos para determinar el tamaño del bloque de CIDR del nodo:

  1. Determina la cantidad máxima de nodos que necesitas en el clúster durante su vida útil.

    Si puedes determinar esta cantidad, que depende de la aplicación, el diseño y las previsiones de crecimiento del cliente, úsala como la cantidad necesaria de nodos. Si no puedes determinar la cantidad máxima de nodos que necesitas, usa el límite de cuota de 5,000 nodos como el valor máximo.

  2. Determina los bits de host necesarios para contemplar la cantidad necesaria de nodos.

    Cuando conoces el recuento de nodos obligatorios, puedes usar la tabla 1 para calcular los bits de host necesarios a fin de generar una máscara de red. Busca la cantidad de nodos obligatorios en la columna Nodos obligatorios. En el siguiente paso, usa el número correspondiente en la columna Bits de host para nodos.

    Nodos obligatorios Bits de host para nodos
    De 1 a 4 3
    De 5 a 12 4
    De 13 a 28 5
    De 29 a 60 6
    De 61 a 124 7
    De 125 a 252 8
    De 253 a 508 9
    De 509 a 1,020 10
    De 1,021 a 2,044 11
    De 2,045 a 4,092 12
    De 4,093 a 8,188 13

    Tabla 1. Bits necesarios para las direcciones de nodos.

  3. Genera una máscara de red de bloque de CIDR mediante el número de la columna Bits de host para nodos que determinaste en el paso anterior:

    32 – bits de host para nodos = máscara de red de bloque de CIDR

    En la siguiente figura, se muestra esta ecuación de manera gráfica.

    Máscara de red de bloque de CIDR de nodos

    Por ejemplo, en la tabla 1, se muestra que para un clúster de 5,000 nodos, se requieren 13 bits de host en la máscara de red del nodo. Para calcular la máscara de red completa, sustituye la cantidad de bits de host por los nodos en la ecuación, 32 – 13 = 19. El resultado es una máscara de red de /19.

Determina el tamaño del bloque de CIDR del Pod

Sigue estos pasos para determinar el tamaño del bloque de CIDR del Pod:

  1. Determina la cantidad máxima de Pods por nodo que necesitas en el clúster durante su vida útil.

    Si puedes determinar esta cantidad, que depende de la aplicación, úsala como la cantidad obligatoria de Pods por nodo. Si no puedes determinar la cantidad máxima que necesitas, usa el límite de cuota de 110 Pods por nodo como valor máximo.

  2. Determina los bits de host necesarios para la cantidad obligatoria de Pods.

    Cuando conoces los Pods obligatorios por recuento de nodos, puedes usar la tabla 2 para calcular los bits de host necesarios a fin de generar una máscara de red. Busca la cantidad de Pods obligatorios por nodo en la columna Recuento de Pods por nodo. Usa el número correspondiente en la columna Bits de host para Pods en el siguiente paso.

    Recuento de Pods por nodo Bits de host para Pods
    De 1 a 8 4
    De 9 a 16 5
    De 17 a 32 6
    De 33 a 64 7
    De 65 a 110 8

    Tabla 2. Bits necesarios para los Pods por nodo.

  3. Genera una máscara de red de bloque de CIDR con la cantidad de bits de host para los nodos que determinaste en el paso dos de la sección Determina el tamaño del bloque de CIDR y la cantidad de bits de host que determinaste en el paso anterior:

    32 – (bits de host para nodos + bits de host para Pods) = máscara de red del bloque de CIDR

    En la siguiente figura, se muestra esta ecuación de manera gráfica.

    Máscara de red del bloque de CIDR del Pod.

    Por ejemplo, si necesitas 110 Pods por nodo, necesitarás 8 bits de host para los Pods por nodo. Luego, toma los bits de host para los nodos (13) y sustituye esos números en la ecuación, 32 – (13 + 8) = 11. El resultado es una máscara de red de /11.

Determina el tamaño del bloque de CIDR de la IP del clúster

Sigue estos pasos para determinar el tamaño del bloque de CIDR de la dirección IP del clúster:

  1. Determina la cantidad máxima de direcciones IP del clúster que necesitas en el clúster durante su vida útil.

    Si puedes determinar esta cantidad, que depende de la aplicación, úsala como la cantidad obligatoria de direcciones IP del clúster. Si no puedes determinar la cantidad máxima que necesitas, usa la máscara de red /20 predeterminada. Si usas la máscara de red predeterminada, puedes omitir el siguiente paso.

  2. Determina la máscara de red para el bloque de CIDR de la dirección IP del clúster.

    Cuando conozcas la cantidad máxima de direcciones IP del clúster que necesitas, puedes usar la tabla 3 para encontrar la máscara de red.

    Cantidad de direcciones IP del clúster Máscara de red
    De 1 a 32 /27
    De 33 a 64 /26
    De 65 a 128 /25
    De 129 a 256 /24
    De 257 a 512 /23
    De 513 a 1,024 /22
    De 1,025 a 2,048 /21
    De 2,049 a 4,096 /20
    De 4,097 a 8,192 /19
    De 8,193 a 16,384 /18
    De 16,385 a 32,768 /17
    De 32,769 a 65,536 /16

    Tabla 3. Máscara de red del bloque de CIDR de objetos Service.

Información sobre la demanda de direcciones

Cuando observas los requisitos del bloque de CIDR derivados de los pasos anteriores, observa que el bloque de CIDR del Pod genera la mayor demanda de espacio de direcciones IP. La mayoría de las veces, el CIDR del nodo representa la segunda demanda más grande, seguida del bloque de CIDR de objetos Service.

Ahora que ya calculaste los requisitos de la dirección IP del clúster, debes revisar el espacio de direcciones IP RFC 1918 disponible y seleccionar una ruta de acceso.

Selecciona la mejor solución

En la figura 1, se muestra un árbol de decisión que puedes usar para determinar la mejor solución según los requisitos del bloque de CIDR. En la sección Revisa las soluciones, se resume cada solución.

Ejemplo de configuración de Service. Para obtener una versión en formato PDF legible, haz clic en la imagen.
Figura 1. Ejemplo de configuración de Service. Para obtener una versión en formato PDF legible, haz clic en la imagen.

Revisa las soluciones

En esta sección, se describe cada solución y cuándo usarla, y se resumen las ventajas, las desventajas y otras cuestiones.

Asignación de un espacio de direcciones disponible

Cuándo usarla:

  • Después de revisar el espacio de direcciones IP disponible y examinar la figura 1, determinaste que hay suficiente espacio de direcciones RFC 1918 disponible para asignar los bloques de CIDR del clúster. Por ejemplo, aunque la dirección 10.0.0.0/8 podría estar agotada, hay suficiente espacio en el espacio de direcciones 172.16.0.0/12192.168.0.0/16 para cumplir con los requisitos del bloque de CIDR.

Descripción:

  • No se requieren otros pasos de configuración especiales para esta solución. Asigna el espacio de direcciones y continúa con la instalación.

Ventajas:

  • Es la solución más fácil.
  • No requiere una configuración especial.

Desventajas:

  • Agota el espacio de direcciones IP disponible.

Otros problemas:

Traducción del bloque de CIDR del Pod de GKE

Cuándo usarla:

  • Después de revisar el espacio de direcciones IP disponible y examinar la figura 1, determinaste que hay suficiente espacio de direcciones RFC 1918 disponible para asignar al bloque del nodo, pero no suficiente espacio para el bloque de CIDR del Pod. Por lo tanto, debes traducir los bloques de CIDR del Pod (y tal vez el Service).

Descripción:

  • Para traducir los bloques de CIDR del Pod en un clúster de GKE, implementa la función ip-masquerade-agent como se muestra en la figura 2. Esta función oculta las direcciones IP del Pod detrás de las direcciones IP del nodo. Con este diseño, también es posible reutilizar bloques de CIDR para el bloque de CIDR del Service.

    NAT para un bloque CIDR de Pod en un clúster de GKE. Para obtener una versión en formato PDF legible, haz clic en la imagen.
    Figura 2. NAT para un bloque de CIDR de Pod en un clúster de GKE. Para obtener una versión en formato PDF legible, haz clic en la imagen.

    Esta arquitectura tiene varios componentes:

    • Terminología nueva para describir las características del bloque de CIDR en relación con la NAT
    • La función ip-masquerade-agent
    • Bloques de CIDR RFC 1918 reutilizados
    • Filtrado en la conexión local

Ventajas:

  • Elimina las dificultades de la asignación de direcciones IPv4 para el CIDR del Pod.
  • Escala al bloque de CIDR de Pod admitido más grande.
  • Aísla los bloques de CIDR RFC 1918 reutilizados de la tabla de enrutamiento global.
  • Posibilita las mallas de varios clústeres de Istio.
  • Permite la configuración de grupos de extremos de red.

Desventajas:

  • La NAT presenta problemas nuevos, como la conexión y el registro de direcciones, que debes abordar.
  • No todos los recursos de la VPC pueden comunicarse con los recursos locales que tienen asignado el mismo rango de CIDR que el Pod. Este problema también existe para los recursos locales que comparten el bloque de CIDR de Service si se reutiliza el rango de Service. El problema es que los bloques de CIDR reutilizados aparecen como rutas locales a la VPC y, por lo tanto, nunca se enrutan fuera de la VPC.

Otras cuestiones:

  • Ten cuidado cuando selecciones qué bloques de CIDR de RFC 1918 reutilizar para los bloques de CIDR de GKE.
  • No publiques los bloques de CIDR RFC 1918 reutilizados en la red local.
  • Debido a que los bloques de CIDR reutilizados se encuentran en la tabla de enrutamiento de VPC, ten cuidado cuando uses el intercambio de tráfico entre redes de VPC o las conexiones de VPN.

Traducción de todos los bloques de CIDR de GKE

Cuándo usarla:

  • Después revisar el espacio de direcciones IP disponible y examinar la figura 1, determinaste que no hay suficiente espacio de direcciones RFC 1918 disponible para asignar a los bloques de CIDR del Pod o del nodo del clúster. Por lo tanto, debes traducir todos los bloques de CIDR.

Descripción:

  • Para traducir todos los bloques de CIDR en un clúster de GKE, implementa la arquitectura que se muestra en la figura 3.

    NAT para todos los bloques de CIDR en un clúster de GKE. Para obtener una versión en formato PDF legible, haz clic en la imagen.
    Figura 3. NAT para todos los bloques de CIDR en un clúster de GKE. Para obtener una versión en formato PDF legible, haz clic en la imagen.

    Esta arquitectura tiene varios componentes:

    • Terminología nueva para describir las características del bloque de CIDR en relación con la NAT
    • Bloques de CIDR RFC 1918 reutilizados
    • Una VPC host que tiene una red compartida
    • Una VPC de Service denominada VPC aislada que contiene el clúster de GKE
    • Una instancia de Compute Engine llamada puerta de enlace de VPC aislada que realiza NAT y tiene una interfaz de red en la VPC aislada y la VPC host.
    • El concepto de un bloque de CIDR del balanceador de cargas interno
    • Rutas estáticas en ambas VPC que dirigen el tráfico de manera adecuada
    • Filtrado en la conexión local

Ventajas:

  • Elimina las dificultades de la asignación de direcciones IPv4.
  • Escala al clúster admitido más grande.
  • Permite la replicación sistemática para varios clústeres.
  • Ofrece el mejor aislamiento de los bloques de CIDR RFC 1918 reutilizados de la tabla de enrutamiento global.
  • Permite la configuración de grupos de extremos de red.

Desventajas:

  • Presenta más complejidad que las soluciones anteriores.
  • La NAT presenta problemas nuevos, como la conexión y el registro de direcciones, que debes abordar.
  • Las mallas de Istio de varios clústeres no se pueden usar en algunas implementaciones.

Otras cuestiones:

  • Ten cuidado cuando selecciones qué bloques de CIDR RFC 1918 reutilizar para los bloques de CIDR de GKE.
  • No publiques los bloques de CIDR RFC 1918 reutilizados en la red local.

Próximos pasos