Requisitos de red

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

Esta página está destinada a administradores, arquitectos, operadores y especialistas en herramientas de redes que administran el ciclo de vida de la infraestructura tecnológica subyacente y diseñan la red para su organización. Para obtener más información sobre los roles comunes y las tareas de ejemplo a las que hacemos referencia en el contenido deGoogle Cloud , consulta Tareas y roles comunes de los usuarios de GKE Enterprise.

Requisitos de red externa

Google Distributed Cloud requiere una conexión a Internet para fines operativos. Google Distributed Cloud recupera componentes de los clústeres de Container Registry, y los clústeres se registran con el agente de Connect.

Puedes conectarte a Google mediante la Internet pública a través de 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 usan 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 de Cómo instalar detrás de un proxy.

Requisitos de red interna

Google Distributed Cloud puede funcionar con conectividad de capa 2 o capa 3 entre nodos de clúster. Los nodos del balanceador de cargas pueden ser los nodos del plano de control o un conjunto de nodos dedicado. Para obtener más información, consulta Elige y configura los balanceadores de cargas.

Cuando usas el balanceo de cargas de la capa 2 en paquetes con MetalLB (spec.loadBalancer.mode: bundled y spec.loadBalancer.type: layer2), los nodos del balanceador de cargas requieren adyacencia de la capa 2. El requisito de adyacencia de capa 2 se aplica si ejecutas el balanceador de cargas en nodos del plano de control o en un conjunto dedicado de nodos de balanceo de cargas. El balanceo de cargas en paquetes con BGP admite el protocolo de capa 3, por lo que no se requiere una adyacencia estricta de capa 2.

Los requisitos para las máquinas del balanceador de cargas son los siguientes:

  • En el caso del balanceo de cargas de la capa 2 en paquetes, todos los balanceadores de cargas 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.
  • Para el balanceo de cargas de capa 2 agrupado, todas las direcciones IP virtuales (VIP) deben estar en la subred de la máquina del balanceador de cargas y se deben poder enrutar a la puerta de enlace de la subred.
  • Los usuarios son responsables de permitir el tráfico de balanceador de cargas de entrada.

Redes de Pods y servicios

Los rangos 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 analizan las restricciones mínimas y máximas para los rangos de direcciones y algunos de los factores relacionados que debes tener en cuenta cuando planificas la instalación de tu clúster.

La cantidad de Pods y Services que puedes tener en tus clústeres se controla mediante la siguiente configuración:

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

Rangos de direcciones IP para Pods y servicios

Especificas un rango de direcciones IP como un bloque de enrutamiento entre dominios sin clases (CIDR) que se usará para los pods y otro bloque de CIDR que se usará para las direcciones ClusterIP de los servicios de Kubernetes. Usa direcciones IP en el espacio de direcciones privadas, como se describe en la RFC 1918. El archivo de configuración del clúster se completa previamente con valores que se encuentran dentro de los límites que se describen en la siguiente tabla:

Límite Pods Servicios
Rango mínimo Valor de máscara de /18 (16,384 direcciones) Valor de máscara de /24 (256 direcciones)
Rango completado previamente Valor de enmascaramiento de /16 (65,536 direcciones) Valor de máscara de /20 (4,096 direcciones)
Rango máximo Valor de máscara de /8 (16,777,216 direcciones) Valor de máscara de /12 (1,048,576 direcciones)

Para evitar la superposición con las direcciones IP a las que se pueda acceder en tu red, es posible que debas usar rangos CIDR diferentes de los valores prepropagados. En particular, los rangos de Service y Pod no deben superponerse con lo siguiente:

  • Direcciones IP de nodos en cualquier clúster

  • VIP que usan los balanceadores de cargas y los nodos del plano de control

  • Direcciones IP de los servidores DNS o NTP

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

Puedes aumentar el rango de la red de servicio (clusterNetwork.services.cidrBlocks) después de crear un clúster, pero no puedes reducir la cantidad 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 la cantidad de direcciones IP.

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

Cantidad máxima de pods por nodo

En Bare Metal, Google Distributed Cloud te permite configurar hasta 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 del pod corresponde a la cantidad máxima de pods por nodo.

En la siguiente tabla, se muestra el tamaño del bloque CIDR que Kubernetes asigna a cada nodo en función de los pods máximos configurados por nodo:

Cantidad máxima de pods por nodo Bloque CIDR por nodo Cantidad de direcciones IP
32 /26 64
33-64 /25 128
65-128 /24 256
129-250 /23 512

Ejecutar 250 pods por nodo requiere que Kubernetes reserve un bloque CIDR /23 para cada nodo. Si suponemos que tu clúster usa el valor predeterminado de /16 para el campo clusterNetwork.pods.cidrBlocks, tu clúster tiene un límite de (2(23-16))=128 nodos.

Si planeas aumentar el clúster más allá de este límite, te recomendamos que establezcas clusterNetwork.pods.cidrBlocks en un bloque de CIDR de pod mucho más grande que el valor prepropagado.

Para obtener más información sobre cómo la cantidad de Pods y servicios, y otros factores, afectan la escalabilidad del clúster, consulta Escala verticalmente los clústeres de Google Distributed Cloud.

Implementación de clúster de usuario único con alta disponibilidad

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

Configuración de red típica de Google Distributed Cloud

Considera la siguiente información para cumplir con los requisitos de red:

  • Los nodos del plano de control ejecutan los balanceadores de cargas y todos tienen conectividad de capa 2, mientras que otras conexiones, incluidos los nodos trabajadores, solo requieren conectividad de capa 3.
  • Los archivos de configuración definen las direcciones IP para los grupos de nodos trabajadores. Los archivos de configuración también definen las VIP para los siguientes fines:
    • Servicios
    • Entrada
    • Controla el acceso al plano a través de la API de Kubernetes
  • Necesitas una conexión a Google Cloud.

Uso de puertos

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

Nodos de plano de control

Versión 1.29

Protocolo Dirección Intervalo de puerto Objetivo Usado por
TCP Entrante 22 Aprovisionamiento y actualizaciones de los nodos del clúster de administrador Estación de trabajo de administrador
TCP Entrante 2379 - 2381 API, métricas y estado del cliente del servidor de etcd kube-apiserver y etcd
TCP Entrante 2382 - 2384 API, métricas y estado del cliente del servidor de etcd-events kube-apiserver y etcd-events
TCP Ambos 4240 Verificación de estado de CNI Todos
UDP Entrante 6081 Encapsulamiento GENEVE Propio
TCP Entrante 6444 Servidor de API de Kubernetes Todos
TCP Entrante 9100 Proxy de autenticación node-exporter
TCP Entrante 9101 Publica métricas de nodos solo en localhost

(se aplica a la versión 1.28 y versiones posteriores)

node-exporter
TCP Entrante 9977 Cómo recibir un evento de auditoría del servidor de la API audit-proxy
TCP Entrante 10250 API kubelet Plano de control y propio
TCP Entrante 10256 Verificación de estado del nodo Todos
TCP Entrante 10257 kube-controller-manager

(cambio de número de puerto para la versión 1.28 y versiones posteriores)

Propia
TCP Entrante 10259 kube-scheduler

(cambio de número de puerto para la versión 1.28 y versiones posteriores)

Propia
TCP Entrante 11002 El contenedor principal de GKE Identity Service se vincula al puerto a través de hostPort

(se aplica a la versión 1.29 y versiones posteriores)

Propia
TCP Entrante 14443 Servicio de webhooks de ANG kube-apiserver y ang-controller-manager

Versión 1.28

Protocolo Dirección Intervalo de puerto Objetivo Usado por
TCP Entrante 22 Aprovisionamiento y actualizaciones de los nodos del clúster de administrador Estación de trabajo de administrador
TCP Entrante 2379 - 2381 API, métricas y estado del cliente del servidor de etcd kube-apiserver y etcd
TCP Entrante 2382 - 2384 API, métricas y estado del cliente del servidor de etcd-events kube-apiserver y etcd-events
TCP Ambos 4240 Verificación de estado de CNI Todos
UDP Entrante 6081 Encapsulamiento GENEVE Propio
TCP Entrante 6444 Servidor de API de Kubernetes Todos
TCP Entrante 8444 El contenedor principal de GKE Identity Service se vincula al puerto a través de hostPort.

(solo se aplica a la versión 1.28)

Todos
TCP Entrante 9100 Proxy de autenticación node-exporter
TCP Entrante 9101 Publica métricas de nodos solo en localhost

(se aplica a la versión 1.28 y versiones posteriores)

node-exporter
TCP Entrante 9977 Cómo recibir un evento de auditoría del servidor de la API audit-proxy
TCP Entrante 10250 API kubelet Plano de control y propio
TCP Entrante 10256 Verificación de estado del nodo Todos
TCP Entrante 10257 kube-controller-manager

(cambio de número de puerto para la versión 1.28 y versiones posteriores)

Propia
TCP Entrante 10259 kube-scheduler

(cambio de número de puerto para la versión 1.28 y versiones posteriores)

Propia
TCP Entrante 14443 Servicio de webhooks de ANG kube-apiserver y ang-controller-manager

Versión 1.16

Protocolo Dirección Intervalo de puerto Objetivo Usado por
TCP Entrante 22 Aprovisionamiento y actualizaciones de los nodos del clúster de administrador Estación de trabajo de administrador
TCP Entrante 2379 - 2381 API, métricas y estado del cliente del servidor de etcd kube-apiserver y etcd
TCP Entrante 2382 - 2384 API, métricas y estado del cliente del servidor de etcd-events

(se aplica a la versión 1.16 y versiones posteriores)

kube-apiserver y etcd-events
TCP Ambos 4240 Verificación de estado de CNI Todos
UDP Entrante 6081 Encapsulamiento GENEVE Propio
TCP Entrante 6444 Servidor de API de Kubernetes Todos
TCP Entrante 9100 Publica métricas node-exporter
TCP Entrante 9443 Métricas de servicio/proxy para componentes del plano de control (Este requisito de puerto es para la versión 1.16 del clúster y versiones anteriores). kube-control-plane-metrics-proxy
TCP Entrante 9977 Cómo recibir un evento de auditoría del servidor de la API audit-proxy
TCP Entrante 10250 API kubelet Plano de control y propio
TCP Entrante 10251 kube-scheduler Propio
TCP Entrante 10252 kube-controller-manager Propio
TCP Entrante 10256 Verificación de estado del nodo Todos
TCP Entrante 14443 Servicio de webhooks de ANG kube-apiserver y ang-controller-manager

(versión 1.15 o inferior)

Protocolo Dirección Intervalo de puerto Objetivo Usado por
TCP Entrante 22 Aprovisionamiento y actualizaciones de los nodos del clúster de administrador Estación de trabajo de administrador
TCP Entrante 2379 - 2381 API, métricas y estado del cliente del servidor de etcd kube-apiserver y etcd
TCP Ambos 4240 Verificación de estado de CNI Todos
UDP Entrante 6081 Encapsulamiento GENEVE Propio
TCP Entrante 6444 Servidor de API de Kubernetes Todos
TCP Entrante 9100 Publica métricas node-exporter
TCP Entrante 9443 Métricas de servicio/proxy para componentes del plano de control (Este requisito de puerto es para la versión 1.16 del clúster y versiones anteriores). kube-control-plane-metrics-proxy
TCP Entrante 9977 Cómo recibir un evento de auditoría del servidor de la API audit-proxy
TCP Entrante 10250 API kubelet Plano de control y propio
TCP Entrante 10251 kube-scheduler Propio
TCP Entrante 10252 kube-controller-manager Propio
TCP Entrante 10256 Verificación de estado del nodo Todos
TCP Entrante 14443 Servicio de webhooks de ANG kube-apiserver y ang-controller-manager

Nodos trabajadores

Versión 1.29

Protocolo Dirección Intervalo de puerto Objetivo Usado por
TCP Entrante 22 Aprovisionamiento y actualizaciones de nodos de clústeres de usuarios Nodos del clúster del administrador
TCP Ambos 4240 Verificación de estado de CNI Todos
UDP Entrante 6081 Encapsulamiento GENEVE Propio
TCP Entrante 9100 Proxy de autenticación node-exporter
TCP Entrante 9101 Publica métricas de nodos solo en localhost

(se aplica a la versión 1.28 y versiones posteriores)

node-exporter
TCP Entrante 10250 API kubelet Plano de control y propio
TCP Entrante 10256 Verificación de estado del nodo Todos
TCP Entrante 30000: 32767 NodePort servicios Propia

Versión 1.28

Protocolo Dirección Intervalo de puerto Objetivo Usado por
TCP Entrante 22 Aprovisionamiento y actualizaciones de nodos de clústeres de usuarios Nodos del clúster del administrador
TCP Ambos 4240 Verificación de estado de CNI Todos
UDP Entrante 6081 Encapsulamiento GENEVE Propio
TCP Entrante 9100 Proxy de autenticación node-exporter
TCP Entrante 9101 Publica métricas de nodos solo en localhost

(se aplica a la versión 1.28 y versiones posteriores)

node-exporter
TCP Entrante 10250 API kubelet Plano de control y propio
TCP Entrante 10256 Verificación de estado del nodo Todos
TCP Entrante 30000: 32767 NodePort servicios Propia

Versión 1.16

Protocolo Dirección Intervalo de puerto Objetivo Usado por
TCP Entrante 22 Aprovisionamiento y actualizaciones de nodos de clústeres de usuarios Nodos del clúster del administrador
TCP Ambos 4240 Verificación de estado de CNI Todos
UDP Entrante 6081 Encapsulamiento GENEVE Propio
TCP Entrante 9100 Publica métricas node-exporter
TCP Entrante 10250 API kubelet Plano de control y propio
TCP Entrante 10256 Verificación de estado del nodo Todos
TCP Entrante 30000: 32767 NodePort servicios Propia

(versión 1.15 o inferior)

Protocolo Dirección Intervalo de puerto Objetivo Usado por
TCP Entrante 22 Aprovisionamiento y actualizaciones de nodos de clústeres de usuarios Nodos del clúster del administrador
TCP Ambos 4240 Verificación de estado de CNI Todos
UDP Entrante 6081 Encapsulamiento GENEVE Propio
TCP Entrante 9100 Publica métricas node-exporter
TCP Entrante 10250 API kubelet Plano de control y propio
TCP Entrante 10256 Verificación de estado del nodo Todos
TCP Entrante 30000: 32767 NodePort servicios Propia

Nodos del balanceador de cargas

Versión 1.29

Protocolo Dirección Intervalo de puerto Objetivo Usado por
TCP Entrante 22 Aprovisionamiento y actualizaciones de nodos de clústeres de usuarios Nodos del clúster del administrador
TCP Entrante 443 Administración de clústeres

Este puerto se puede configurar en el archivo de configuración del clúster con el campo controlPlaneLBPort.

Todos
TCP Ambos 4240 Verificación de estado de CNI Todos
UDP Entrante 6081 Encapsulamiento GENEVE Propia
TCP y UDP Entrante 7946 Verificación de estado de MetalLB Nodos del balanceador de cargas
TCP Entrante 10256 Verificación de estado del nodo Todos
TCP Entrante 11000 Puerto de escucha para las métricas de HAProxy (inmutable)

(se aplica a la versión 1.29 y versiones posteriores)

Todos
TCP Entrante 11001 Puerto de escucha de GKE Identity Service (inmutable)

(se aplica a la versión 1.29 y versiones posteriores)

Todos

Versión 1.28

Protocolo Dirección Intervalo de puerto Objetivo Usado por
TCP Entrante 22 Aprovisionamiento y actualizaciones de nodos de clústeres de usuarios Nodos del clúster del administrador
TCP Entrante 443 Administración de clústeres

Este puerto se puede configurar en el archivo de configuración del clúster con el campo controlPlaneLBPort.

Todos
TCP Ambos 4240 Verificación de estado de CNI Todos
UDP Entrante 6081 Encapsulamiento GENEVE Propia
TCP y UDP Entrante 7946 Verificación de estado de MetalLB Nodos del balanceador de cargas
TCP Entrante 8443 Puerto de escucha de GKE Identity Service (inmutable)

(solo se aplica a la versión 1.28)

Todos
TCP Entrante 10256 Verificación de estado del nodo Todos

Versión 1.16

Protocolo Dirección Intervalo de puerto Objetivo Usado por
TCP Entrante 22 Aprovisionamiento y actualizaciones de nodos de clústeres de usuarios Nodos del clúster del administrador
TCP Entrante 443 Administración de clústeres

Este puerto se puede configurar en el archivo de configuración del clúster con el campo controlPlaneLBPort.

Todos
TCP Ambos 4240 Verificación de estado de CNI Todos
UDP Entrante 6081 Encapsulamiento GENEVE Propio
TCP Entrante 7946 Verificación de estado de MetalLB Nodos del balanceador de cargas
TCP Entrante 10256 Verificación de estado del nodo Todos

(versión 1.15 o inferior)

Protocolo Dirección Intervalo de puerto Objetivo Usado por
TCP Entrante 22 Aprovisionamiento y actualizaciones de nodos de clústeres de usuarios Nodos del clúster del administrador
TCP Entrante 443 Administración de clústeres

Este puerto se puede configurar en el archivo de configuración del clúster con el campo controlPlaneLBPort.

Todos
TCP Ambos 4240 Verificación de estado de CNI Todos
UDP Entrante 6081 Encapsulamiento GENEVE Propio
TCP Entrante 7946 Verificación de estado de MetalLB Nodos del balanceador de cargas
TCP Entrante 10256 Verificación de estado del nodo Todos

Requisitos de los puertos para varios clústeres

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

Protocolo Dirección Intervalo de puerto Objetivo Usado por
TCP Entrante 22 Aprovisionamiento y actualizaciones de nodos de clústeres Todos los nodos
TCP Entrante 443 Servidor de la API de Kubernetes para el clúster agregado

Este puerto se puede configurar en la configuración del clúster mediante el campo controlPlaneLBPort.

Plano de control y nodos del balanceador de cargas

Configura puertos con firewalld

No es necesario que inhabilites firewalld para ejecutar Google Distributed Cloud en Red Hat Enterprise Linux (RHEL). Para usar un firewall, debes abrir los puertos UDP y TCP que usan los nodos del plano del control, trabajador y balanceador de cargas, como se describe en Uso del puerto en esta página. En los siguientes parámetros de configuración de ejemplo, se muestra cómo puedes abrir puertos con firewall-cmd, la utilidad de línea de comandos de firewall. Debes ejecutar los comandos como el usuario raíz.

Configuración de ejemplo del nodo del plano de control

En el siguiente bloque de comandos, se 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 conocer los requisitos de puertos específicos de la versión del clúster que deseas usar, consulta la sección Uso de puertos anterior. Actualiza los comandos de muestra según corresponda.

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

Configuración de ejemplo del nodo trabajador

En el siguiente bloque de comandos, se muestra un ejemplo de cómo puedes abrir los puertos necesarios en servidores que ejecutan nodos trabajadores:

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 conocer los requisitos de puertos específicos de la versión del clúster que deseas usar, consulta la sección Uso de puertos anterior. Actualiza los comandos de muestra según corresponda.

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

Configuración de ejemplo de nodo del balanceador de cargas

En el siguiente bloque de comandos, se muestra un ejemplo de cómo puedes abrir los puertos necesarios en servidores que ejecutan nodos del balanceador de cargas:

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 conocer los requisitos de puertos específicos de la versión del clúster que deseas usar, consulta la sección Uso de puertos anterior. Actualiza los comandos de muestra según corresponda.

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

Configuración complementaria para RHEL 9.2 y 9.4

Red Hat Enterprise Linux (RHEL) 9.2 y 9.4 son compatibles como versión GA en las versiones 1.29.400 y posteriores. Con las versiones 9.2 y 9.4 de RHEL, debes realizar una configuración adicional de firewalld en los nodos para que tus servicios y pods funcionen correctamente:

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

    firewall-cmd --list-interfaces
    

    Según las convenciones de nombres para las interfaces de máquinas de Linux, el nombre de la interfaz principal podría ser uno de los siguientes: eth0, eno1, ens1 o enp2s0.

  2. Enumera las zonas del nodo para encontrar la que 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 detalles personalizados de la zona y la política para 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
    

    Reemplaza IN_ZONE por uno de los siguientes valores, según lo que hayas encontrado en los pasos anteriores:

    • public: Es una zona predefinida para usar en áreas públicas en las que solo se aceptan conexiones entrantes seleccionadas.
    • trusted: Es una zona predefinida en un entorno controlado en el que se aceptan todas las conexiones de red.
    • Es el nombre de una zona personalizada que definiste.
  4. Sigue la documentación del proveedor para configurar tu solución de almacenamiento.

    Por ejemplo, si usas Portworx para administrar cargas de trabajo con estado, los requisitos de red de Portworx enumeran los puertos que deben permanecer abiertos.

    Para cada uno de los puertos que se indican en la documentación del proveedor, ejecuta el siguiente comando:

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

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

Confirma la configuración de puertos

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

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

    nmap localhost
    
  2. Ejecuta los siguientes comandos para obtener la 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. Es posible que debas ejecutar los comandos como el usuario raíz.

Problema conocido para firewalld

Cuando ejecutas Google Distributed Cloud con firewalld habilitado en Red Hat Enterprise Linux (RHEL), los cambios en firewalld pueden quitar las cadenas de iptables de Cilium en la red de host. El pod anetd agrega las cadenas de iptables cuando se inicia. La pérdida de las cadenas de iptables de Cilium hace que el pod en el nodo pierda conectividad de red fuera del nodo.

Entre los cambios en firewalld que quitarán las cadenas de iptables, se incluyen los siguientes:

  • Reinicio de firewalld con systemctl

  • Cómo 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. Ubica y borra el Pod anetd con los siguientes comandos para reiniciar anetd:

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

    Reemplaza ANETD_XYZ con el nombre del pod anetd.