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:

• clusterNetwork.pods.cidrBlocks especifica la cantidad de Pods permitidos en tu clúster.

• clusterNetwork.services.cidrBlocks especifica la cantidad de servicios permitidos en tu clúster.

• nodeConfig.podDensity.maxPodsPerNode especifica la cantidad máxima de Pods que pueden ejecutarse 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

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.

Nota: Los bloques CIDR de Pod y Service del clúster se dividen en rangos de direcciones IP más pequeños para cada nodo del clúster. Google Distributed Cloud usa la traducción de direcciones de red (NAT) para asignar estos rangos de direcciones IP de Pod a la dirección IP del nodo. Si alguna de estas direcciones IP del Pod corresponde a una dirección IP externa, se considera que esa dirección externa no se puede alcanzar desde el clúster.

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.

Nota: El parámetro de configuración maxPodsPerNode solo tiene en cuenta los pods en ejecución, es decir, los que usan recursos. Por ejemplo, un trabajo de Kubernetes crea uno o más pods para realizar una tarea específica. Por lo general, los pods se ejecutan hasta que completan la tarea (o fallan) y se detienen. Por lo general, estos pods detenidos no se limpian automáticamente, por lo que aparecen en el nodo cuando ejecutas kubectl get pods. Sin embargo, como los pods detenidos no consumen ningún recurso, incluidas las direcciones IP, no contribuyen al total máximo 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.

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

Nota: Un error en algunos kernels de Linux para Red Hat Enterprise Linux (RHEL) 9.2 podría generar descargas de imágenes muy lentas. Para obtener más información, incluidas las instrucciones para la solución, consulta Descargas lentas dentro de contenedores en RHEL 9.2.

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.