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.
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.
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 |
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 |
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 |
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 |
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 |
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:
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
oenp2s0
.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 zonapublic
:... public (active) target: default icmp-block-inversion: no interfaces: eno1 sources: ...
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.
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:
Ejecuta el siguiente comando de Network Mapper para ver qué puertos están abiertos:
nmap localhost
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
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
consystemctl
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:
Ubica y borra el Pod
anetd
con los siguientes comandos para reiniciaranetd
:kubectl get pods -n kube-system kubectl delete pods -n kube-system ANETD_XYZ
Reemplaza ANETD_XYZ con el nombre del pod
anetd
.