Requisitos de red

En este documento se describen los requisitos de red para instalar y utilizar Google Distributed Cloud (solo software) en Bare Metal.

Esta página está dirigida a administradores, arquitectos, operadores y especialistas en redes que gestionan el ciclo de vida de la infraestructura tecnológica subyacente, y diseñan y desarrollan la arquitectura de la red de su organización. Para obtener más información sobre los roles habituales y las tareas de ejemplo a las que hacemos referencia en el contenido, consulta Roles y tareas de usuario habituales de GKE.Google Cloud

Requisitos de redes externas

Google Distributed Cloud requiere una conexión a Internet para funcionar. Google Distributed Cloud obtiene los componentes del clúster de Artifact Registry y el clúster se registra con Connect Agent.

Puedes conectarte a Google a través de Internet público mediante HTTPS, una red privada virtual (VPN) o una conexión de interconexión dedicada.

Si las máquinas que usas para tu estación de trabajo de administrador y los nodos del clúster utilizan un servidor proxy para acceder a Internet, este debe permitir algunas conexiones específicas. Para obtener más información, consulta la sección de requisitos previos del artículo Instalar detrás de un proxy.

Requisitos de red interna

Google Distributed Cloud puede funcionar con la conectividad de capa 2 o capa 3 entre los nodos del clúster. Los nodos del balanceador de carga pueden ser los nodos del plano de control o un conjunto de nodos específico. Para obtener más información, consulta Elegir y configurar balanceadores de carga.

Cuando usas el balanceo de carga de capa 2 agrupado con MetalLB (spec.loadBalancer.mode: bundled y spec.loadBalancer.type: layer2), los nodos del balanceador de carga requieren adyacencia de capa 2. El requisito de adyacencia de la capa 2 se aplica tanto si ejecutas el balanceador de carga en nodos del plano de control como en un conjunto específico de nodos de balanceo de carga. El balanceo de carga agrupado con BGP admite el protocolo de capa 3, por lo que no es necesario que haya una adyacencia estricta de capa 2.

Estos son los requisitos de las máquinas del balanceador de carga:

• En el caso del balanceo de carga de capa 2 agrupado, todos los balanceadores de carga de un clúster determinado se encuentran en el mismo dominio de capa 2. Los nodos del plano de control también deben estar en el mismo dominio de capa 2.
• En el caso del balanceo de carga de capa 2 agrupado, todas las direcciones IP virtuales (VIPs) deben estar en la subred de la máquina del balanceador de carga y se debe poder enrutar a la puerta de enlace de la subred.
• Los usuarios son responsables de permitir el tráfico del balanceador de carga de entrada.

Redes de pods y servicios

Los intervalos de direcciones IP disponibles para los servicios y los pods se especifican en el archivo de configuración del clúster. En las siguientes secciones se describen las restricciones mínimas y máximas de los intervalos de direcciones, así como algunos de los factores relacionados que debes tener en cuenta al planificar la instalación del clúster.

El número de pods y servicios que puedes tener en tus clústeres se controla mediante los siguientes ajustes:

• clusterNetwork.pods.cidrBlocks especifica el número de pods permitidos en el clúster.

• clusterNetwork.services.cidrBlocks especifica el número de servicios permitidos en tu clúster.

• nodeConfig.podDensity.maxPodsPerNode especifica el número máximo de pods que se pueden ejecutar en un solo nodo.

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: admin-basic
  namespace: cluster-admin-basic
spec:
  type: admin
  profile: default
  ...
  clusterNetwork:
    pods:
      cidrBlocks:
      - 192.168.0.0/16
    services:
      cidrBlocks:
      - 10.96.0.0/20
  ...
  nodeConfig:
    podDensity:
      maxPodsPerNode: 250

Intervalos de direcciones IP de pods y servicios

Especifica un intervalo de direcciones IP como un bloque de enrutamiento de interdominios sin clases (CIDR) que se usará para los pods y otro bloque CIDR que se usará para las direcciones ClusterIP de los servicios de Kubernetes. Usa direcciones IP del espacio de direcciones privadas, tal como se describe en el RFC 1918. El archivo de configuración del clúster se rellena previamente con valores que se ajustan a los límites descritos en la siguiente tabla:

Para evitar que se solapen con las direcciones IP a las que se puede acceder en tu red, es posible que tengas que usar intervalos CIDR distintos de los valores predefinidos. En concreto, los intervalos de servicios y pods no deben solaparse con los siguientes:

• Direcciones IP de los nodos de cualquier clúster

• IPs virtuales usadas por los nodos del plano de control y los balanceadores de carga

• Direcciones IP de servidores DNS o NTP

Las comprobaciones previas impiden la creación y las actualizaciones de clústeres si se identifican direcciones IP superpuestas.

Puedes aumentar el intervalo de la red de servicio (clusterNetwork.services.cidrBlocks) después de crear un clúster, pero no puedes reducir el número de direcciones IP asignadas ni cambiarlas. Solo puedes cambiar el sufijo del bloque CIDR, lo que reduce el valor de la máscara para aumentar el número de direcciones IP.

Tanto clusterNetwork.pods.cidrBlocks como nodeConfig.podDensity.maxPodsPerNode (descritos en la siguiente sección) son inmutables, por lo que debes planificar cuidadosamente el crecimiento futuro de tu clúster para evitar quedarte sin capacidad de nodos. Para ver los máximos recomendados de pods por clúster, pods por nodo y nodos por clúster según las pruebas, consulta Límites.

Número máximo de pods por nodo

En bare metal, Google Distributed Cloud te permite configurar un máximo de 250 pods por nodo. Kubernetes asigna un bloque CIDR a cada nodo para que cada pod pueda tener una dirección IP única. El tamaño del bloque CIDR de pods corresponde al número máximo de pods por nodo.

En la siguiente tabla se indica el tamaño del bloque CIDR que Kubernetes asigna a cada nodo en función del número máximo de pods por nodo configurado:

Para ejecutar 250 pods por nodo, Kubernetes debe reservar un bloque CIDR /23 para cada nodo. Si tu clúster usa el valor predeterminado /16 para el campo clusterNetwork.pods.cidrBlocks, tendrá un límite de (2^(23-16))=128 nodos.

Si tienes previsto ampliar el clúster más allá de este límite, te recomendamos que asignes a clusterNetwork.pods.cidrBlocks un bloque CIDR de pods significativamente mayor que el valor predefinido.

Para obtener más información sobre cómo afectan al escalado de clústeres el número de pods y servicios, así como otros factores, consulta Escalar verticalmente clústeres de Google Distributed Cloud.

Despliegue de un clúster de usuarios único con alta disponibilidad

En el siguiente diagrama se ilustran varios conceptos clave de redes de Google Distributed Cloud en una posible configuración de red.

Tenga en cuenta la siguiente información para cumplir los requisitos de la red:

• Los nodos del plano de control ejecutan los balanceadores de carga y todos tienen conectividad de capa 2, mientras que otras conexiones, incluidos los nodos de trabajador, solo requieren conectividad de capa 3.
• Los archivos de configuración definen las direcciones IP de los grupos de nodos de trabajo. Los archivos de configuración también definen IPs virtuales para los siguientes propósitos:
  • Servicios
  • Entrada
  • Acceso al plano de control a través de la API de Kubernetes
• Necesitas una conexión a Google Cloud.

Uso del puerto

En esta sección se identifican los requisitos de puertos de los clústeres de Google Distributed Cloud. En las siguientes tablas se muestra cómo usan los puertos UDP y TCP los componentes de Kubernetes en los nodos de clúster y de balanceador de carga.

Nodos del plano de control

Nodos de trabajador

Nodos de balanceador de carga

Requisitos de puertos para varios clústeres

En una configuración de varios clústeres, los clústeres añadidos deben incluir los siguientes puertos para comunicarse con el clúster de administrador.

Configurar puertos de firewalld

No es necesario inhabilitar firewalld para ejecutar Google Distributed Cloud en Red Hat Enterprise Linux (RHEL). Para usar firewalld, debes abrir los puertos UDP y TCP que usan los nodos del plano de control, los trabajadores y los balanceadores de carga, tal como se describe en la sección Uso de puertos de esta página. En los siguientes ejemplos de configuración se muestra cómo puedes abrir puertos con firewall-cmd, la utilidad de línea de comandos de firewalld. Debes ejecutar los comandos como usuario root.

Ejemplo de configuración de nodo del plano de control

El siguiente bloque de comandos muestra un ejemplo de cómo puedes abrir los puertos necesarios en servidores que ejecutan nodos del plano de control:

firewall-cmd --permanent --zone=public --add-port=22/tcp
firewall-cmd --permanent --zone=public --add-port=4240/tcp
firewall-cmd --permanent --zone=public --add-port=6444/tcp
firewall-cmd --permanent --zone=public --add-port=6081/udp
firewall-cmd --permanent --zone=public --add-port=10256/tcp
firewall-cmd --permanent --zone=public --add-port=10257/tcp
firewall-cmd --permanent --zone=public --add-port=10259/tcp
firewall-cmd --permanent --zone=public --add-port=2379-2380/tcp
firewall-cmd --permanent --zone=public --add-port=443/tcp
firewall-cmd --permanent --zone=public --add-port=30000-32767/tcp
firewall-cmd --permanent --new-zone=k8s-pods
firewall-cmd --permanent --zone=k8s-pods --add-source PODS_CIDR
firewall-cmd --permanent --zone=k8s-pods --set-target=ACCEPT
firewall-cmd --reload

Para consultar los requisitos de puertos específicos de la versión del clúster que quieras usar, consulta la sección Uso de puertos anterior. Actualiza los comandos de ejemplo según corresponda.

Sustituye PODS_CIDR por los bloques CIDR reservados para tus pods configurados en el campo clusterNetwork.pods.cidrBlocks. El bloque CIDR predeterminado de los pods es 192.168.0.0/16.

Ejemplo de configuración de nodo de trabajador

El siguiente bloque de comandos muestra un ejemplo de cómo puedes abrir los puertos necesarios en servidores que ejecutan nodos de trabajo:

firewall-cmd --permanent --zone=public --add-port=22/tcp
firewall-cmd --permanent --zone=public --add-port=4240/tcp
firewall-cmd --permanent --zone=public --add-port=6444/tcp
firewall-cmd --permanent --zone=public --add-port=6081/udp
firewall-cmd --permanent --zone=public --add-port=10250/tcp
firewall-cmd --permanent --zone=public --add-port=10256/tcp
firewall-cmd --permanent --zone=public --add-port=443/tcp
firewall-cmd --permanent --zone=public --add-port=30000-32767/tcp
firewall-cmd --permanent --new-zone=k8s-pods
firewall-cmd --permanent --zone=k8s-pods --add-source PODS_CIDR
firewall-cmd --permanent --zone=k8s-pods --set-target=ACCEPT
firewall-cmd --reload

Para consultar los requisitos de puertos específicos de la versión del clúster que quieras usar, consulta la sección Uso de puertos anterior. Actualiza los comandos de ejemplo según corresponda.

Sustituye PODS_CIDR por los bloques CIDR reservados para tus pods configurados en el campo clusterNetwork.pods.cidrBlocks. El bloque CIDR predeterminado de los pods es 192.168.0.0/16.

Ejemplo de configuración de un nodo de balanceador de carga

El siguiente bloque de comandos muestra un ejemplo de cómo puedes abrir los puertos necesarios en servidores que ejecutan nodos de balanceador de carga:

firewall-cmd --permanent --zone=public --add-port=22/tcp
firewall-cmd --permanent --zone=public --add-port=4240/tcp
firewall-cmd --permanent --zone=public --add-port=6444/tcp
firewall-cmd --permanent --zone=public --add-port=7946/tcp
firewall-cmd --permanent --zone=public --add-port=7946/udp
firewall-cmd --permanent --zone=public --add-port=6081/udp
firewall-cmd --permanent --zone=public --add-port=10250/tcp
firewall-cmd --permanent --zone=public --add-port=10256/tcp
firewall-cmd --permanent --zone=public --add-port=443/tcp
firewall-cmd --permanent --zone=public --add-port=30000-32767/tcp
firewall-cmd --permanent --new-zone=k8s-pods
firewall-cmd --permanent --zone=k8s-pods --add-source PODS_CIDR
firewall-cmd --permanent --zone=k8s-pods --set-target=ACCEPT
firewall-cmd --reload

Para consultar los requisitos de puertos específicos de la versión del clúster que quieras usar, consulta la sección Uso de puertos anterior. Actualiza los comandos de ejemplo según corresponda.

Sustituye PODS_CIDR por los bloques CIDR reservados para tus pods configurados en el campo clusterNetwork.pods.cidrBlocks. El bloque CIDR predeterminado de los pods es 192.168.0.0/16.

Configuración complementaria para RHEL 9.2 y 9.4

Las versiones 9.2 y 9.4 de Red Hat Enterprise Linux (RHEL) están disponibles de forma general en las versiones 1.29.400 y posteriores. Con las versiones 9.2 y 9.4 de RHEL, debe realizar una configuración adicional de firewalld en los nodos para que sus servicios y pods funcionen correctamente:

1. Lista las interfaces activas del nodo para encontrar la interfaz del nodo principal:

   firewall-cmd --list-interfaces
   

   Según las convenciones de nomenclatura de las interfaces de máquinas Linux, el nombre de tu interfaz principal puede ser uno de los siguientes: eth0, eno1, ens1 o enp2s0.

2. Lista las zonas del nodo para saber qué zona usa la interfaz principal:

   firewall-cmd --list-all-zones
   

   Por ejemplo, si tu interfaz principal es eno1, la siguiente sección de la respuesta indica que la interfaz principal está en la zona public:

   ...
   public (active)
     target: default
     icmp-block-inversion: no
     interfaces: eno1
     sources:
     ...
   

3. Ejecuta los siguientes comandos de firewalld para configurar la zona y los detalles de la política personalizadas en RHEL 9.2 o 9.4:

   firewall-cmd --permanent --new-zone=cilium
   firewall-cmd --permanent --zone=cilium --add-interface=cilium_host
   firewall-cmd --permanent --zone=cilium --set-target ACCEPT
   firewall-cmd --permanent --zone=cilium --add-masquerade
   firewall-cmd --permanent --zone=cilium --add-forward
   firewall-cmd --permanent --new-policy cilium-host-port-forwarding
   firewall-cmd --permanent --policy cilium-host-port-forwarding --add-ingress-zone IN_ZONE
   firewall-cmd --permanent --policy cilium-host-port-forwarding --add-egress-zone cilium
   firewall-cmd --permanent --policy cilium-host-port-forwarding --set-target ACCEPT
   firewall-cmd --reload
   

   Sustituye IN_ZONE por uno de los siguientes valores, en función de lo que hayas encontrado en los pasos anteriores:

   • public: zona predefinida para usar en zonas públicas en las que solo se aceptan las conexiones entrantes seleccionadas.
   • trusted: zona predefinida en un entorno controlado en la que se aceptan todas las conexiones de red.
   • El nombre de una zona personalizada que haya definido.

4. Sigue la documentación del proveedor para configurar tu solución de almacenamiento.

   Por ejemplo, si usas Portworx para gestionar cargas de trabajo con estado, en los requisitos de red de Portworx se indican los puertos que deben permanecer abiertos.

   Ejecuta el siguiente comando para cada uno de los puertos que se indican en la documentación del proveedor:

   firewall-cmd --permanent --zone=public --add-port=PORT_INFO
   

   Sustituye PORT_INFO por el número de puerto o el intervalo de números de puerto seguido del protocolo. Por ejemplo, 10250-10252/tcp.

Confirmar la configuración de puertos

Para verificar la configuración de los puertos, sigue estos pasos en los nodos del plano de control, de los trabajadores y del balanceador de carga:

1. Ejecuta el siguiente comando de Network Mapper para ver qué puertos están abiertos:

   nmap localhost
   

2. Ejecuta los siguientes comandos para obtener los ajustes de configuración de firewalld:

   firewall-cmd --info-zone=public
   firewall-cmd --info-zone=k8s-pods
   firewall-cmd --list-all-policies
   

3. Si es necesario, vuelve a ejecutar los comandos de las secciones anteriores para configurar los nodos correctamente. Puede que tengas que ejecutar los comandos como usuario root.

Problema conocido de firewalld

Cuando se ejecuta Google Distributed Cloud con firewalld habilitado en Red Hat Enterprise Linux (RHEL), los cambios en firewalld pueden eliminar las cadenas iptables de Cilium en la red del host. Las cadenas iptables las añade el pod anetd cuando se inicia. La pérdida de las cadenas de Cilium iptables provoca que el pod del nodo pierda la conectividad de red fuera del nodo.

Los cambios en firewalld que eliminan las cadenas iptables incluyen, entre otros:

• Reiniciando firewalld con systemctl

• Volver a cargar firewalld con el cliente de línea de comandos (firewall-cmd --reload)

Para aplicar los cambios de firewalld sin quitar las cadenas de iptables, reinicia anetd en el nodo:

1. Busca y elimina el pod anetd con los siguientes comandos para reiniciarlo: anetd

   kubectl get pods -n kube-system kubectl delete pods -n kube-system ANETD_XYZ
   

   Sustituye ANETD_XYZ por el nombre del anetd Pod.