En este documento, se describen los requisitos de red para instalar y operar GKE en Bare Metal.
Requisitos de red externa
GKE en Bare Metal requiere una conexión a Internet para fines operativos. GKE en Bare Metal recupera los componentes del clúster de Container Registry y el clúster se registra con 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 la estación de trabajo de administrador y los nodos del clúster usan un servidor proxy a fin de acceder a Internet, el servidor proxy debe permitir algunas conexiones específicas. Para obtener más información, consulta la sección de requisitos previos de Instala detrás de un proxy.
Requisitos de red interna
GKE en Bare Metal puede funcionar con conectividad de capa 2 o capa 3 entre nodos del clúster. Los nodos del balanceador de cargas pueden ser los nodos del plano de control o un conjunto Para obtener más información, consulta Elige y configura los balanceadores de cargas.
Cuando usas el balanceo de cargas agrupado de capa 2 con MetalLB (spec.loadBalancer.mode: bundled y spec.loadBalancer.type: layer2), los nodos del balanceador de cargas requieren adyacencia de capa 2. El requisito de proximidad de capa 2 se aplica si ejecutas el balanceador de cargas en los 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 balanceo de cargas de 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 en paquetes, todas las direcciones IP virtuales (VIP) deben estar en la subred de la máquina del balanceador de cargas y enrutarse a la puerta de enlace de la subred.
- Los usuarios son responsables de permitir el tráfico del balanceador de cargas de entrada.
Herramientas de redes de Pods
GKE en Bare Metal te permite configurar hasta 250 Pods por nodo. Kubernetes asigna un bloque de enrutamiento entre dominios sin clases (CIDR) a cada nodo para que cada pod pueda tener una dirección IP única. El tamaño del bloque CIDR corresponde al número 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, puedes aumentar el valor de clusterNetwork.pods.cidrBlocks o disminuir el valor de nodeConfig.podDensity.maxPodsPerNode. Este método tenía algunas desventajas.
Implementación de clúster de usuario único con alta disponibilidad
En el siguiente diagrama, se ilustra una serie de conceptos clave de herramientas de redes para GKE en Bare Metal en una configuración de red posible.
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
- Ingress
- 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 puerto para los clústeres de GKE en Bare Metal. 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.28
| Protocolo | Dirección | Intervalo de puerto | Objetivo | Usado por |
|---|---|---|---|---|
| TCP | Entrante | 22 | Aprovisionamiento y actualización de nodos del clúster de administrador | Estación de trabajo de administrador |
| TCP | Entrante | 2379 a 2381 | API del cliente del servidor de etcd, métricas y estado | kube-apiserver y etcd |
| TCP | Entrante | 2382 a 2384 | API del cliente del servidor de etcd-events, métricas y estado | 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 | 8443 y 8444 | GKE Identity Service v2 | Deployment de ais que se ejecuta en el espacio de nombres anthos-identity-service |
| TCP | Entrante | 9100 | proxy de autenticación | node-exporter |
| TCP | Entrante | 9101 | Entrega métricas de nodos solo en localhost (Requisito de puerto agregado para la versión 1.28 y posteriores). |
node-exporter |
| TCP | Entrante | 9977 | Recibir eventos 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 | All |
| TCP | Entrante | 10257 | kube-controller-manager (se cambió el número de puerto para la versión 1.28 y posteriores). |
Propio |
| TCP | Entrante | 10259 | kube-scheduler (se cambió el número de puerto para la versión 1.28 y posteriores). |
Propio |
| TCP | Entrante | 14443 | Servicio de webhook 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 actualización de nodos del clúster de administrador | Estación de trabajo de administrador |
| TCP | Entrante | 2379 a 2381 | API del cliente del servidor de etcd, métricas y estado | kube-apiserver y etcd |
| TCP | Entrante | 2382 a 2384 | API del cliente del servidor de etcd-events, métricas y estado (Requisito para puertos agregados a la versión 1.16 y 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 | Métricas de publicación | node-exporter |
| TCP | Entrante | 9443 | Métricas de entrega o proxy para los 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 | Recibir eventos 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 | All |
| TCP | Entrante | 14443 | Servicio de webhook de ANG | kube-apiserver y ang-controller-manager |
Versión 1.15 y anteriores
| Protocolo | Dirección | Intervalo de puerto | Objetivo | Usado por |
|---|---|---|---|---|
| TCP | Entrante | 22 | Aprovisionamiento y actualización de nodos del clúster de administrador | Estación de trabajo de administrador |
| TCP | Entrante | 2379 a 2381 | API del cliente del servidor de etcd, métricas y estado | 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 | Métricas de publicación | node-exporter |
| TCP | Entrante | 9443 | Métricas de entrega o proxy para los 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 | Recibir eventos 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 | All |
| TCP | Entrante | 14443 | Servicio de webhook de ANG | kube-apiserver y ang-controller-manager |
Nodos trabajadores
Versión 1.28
| Protocolo | Dirección | Intervalo de puerto | Objetivo | Usado por |
|---|---|---|---|---|
| TCP | Entrante | 22 | Aprovisionamiento y actualización de nodos del clúster de usuario | 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 | Entrega métricas de nodos solo en localhost (Requisito de puerto agregado para la versión 1.28 y posteriores). |
node-exporter |
| TCP | Entrante | 10250 | API kubelet |
Plano de control y propio |
| TCP | Entrante | 10256 | Verificación de estado del nodo | All |
| TCP | Entrante | 30000: 32767 | NodePort servicios |
Propio |
Versión 1.16
| Protocolo | Dirección | Intervalo de puerto | Objetivo | Usado por |
|---|---|---|---|---|
| TCP | Entrante | 22 | Aprovisionamiento y actualización de nodos del clúster de usuario | 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 | Métricas de publicación | node-exporter |
| TCP | Entrante | 10250 | API kubelet |
Plano de control y propio |
| TCP | Entrante | 10256 | Verificación de estado del nodo | All |
| TCP | Entrante | 30000: 32767 | NodePort servicios |
Propio |
Versión 1.15 y anteriores
| Protocolo | Dirección | Intervalo de puerto | Objetivo | Usado por |
|---|---|---|---|---|
| TCP | Entrante | 22 | Aprovisionamiento y actualización de nodos del clúster de usuario | Nodos del clúster del administrador |
| TCP | Ambos | 4240 | Verificación de estado de CNI | Todos |
| UDP | Entrante | 6081 | Encapsulamiento GENEVE | Propio |
| TCP | Entrante | 10250 | API kubelet |
Plano de control y propio |
| TCP | Entrante | 10256 | Verificación de estado del nodo | All |
| TCP | Entrante | 30000: 32767 | NodePort servicios |
Propio |
Nodos del balanceador de cargas
Versión 1.28
| Protocolo | Dirección | Intervalo de puerto | Objetivo | Usado por |
|---|---|---|---|---|
| TCP | Entrante | 22 | Aprovisionamiento y actualización de nodos del clúster de usuario | Nodos del clúster del administrador |
| TCP | Entrante | 443 | Administración de clústeres Este puerto se puede establecer en la configuración del clúster mediante el campo |
Todos |
| TCP | Ambos | 4240 | Verificación de estado de CNI | Todos |
| UDP | Entrante | 6081 | Encapsulamiento GENEVE | Propio |
| 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 |
Versión 1.16
| Protocolo | Dirección | Intervalo de puerto | Objetivo | Usado por |
|---|---|---|---|---|
| TCP | Entrante | 22 | Aprovisionamiento y actualización de nodos del clúster de usuario | Nodos del clúster del administrador |
| TCP | Entrante | 443 | Administración de clústeres Este puerto se puede establecer en la configuración del clúster mediante 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 y anteriores
| Protocolo | Dirección | Intervalo de puerto | Objetivo | Usado por |
|---|---|---|---|---|
| TCP | Entrante | 22 | Aprovisionamiento y actualización de nodos del clúster de usuario | Nodos del clúster del administrador |
| TCP | Entrante | 443 | Administración de clústeres Este puerto se puede establecer en la configuración del clúster mediante 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 actualización de nodos del clúster | 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 con el campo |
Plano de control y nodos del balanceador de cargas |
Configura puertos con firewalld
No es necesario que inhabilites el firewall para ejecutar GKE en Bare Metal en Red Hat Enterprise Linux (RHEL). Para usar firewalld, debes abrir los puertos UDP y TCP que usan los nodos del plano de control, trabajador y del balanceador de cargas como se describe en Uso de puertos 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=10250-10252/tcp
firewall-cmd --permanent --zone=public --add-port=10256/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
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
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
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.
Confirma la configuración de tu puerto
Para verificar la configuración del puerto, sigue estos pasos en el plano de control, el trabajador y los nodos del balanceador de cargas:
Ejecuta el siguiente comando Network Mapper para ver qué puertos están abiertos:
nmap localhostEjecuta los siguientes comandos para obtener los ajustes de configuración del firewall:
firewall-cmd --zone=public --list-all-policies firewall-cmd --zone=public --list-ports firewall-cmd --zone=public --list-services firewall-cmd --zone=k8s-pods --list-all-policies firewall-cmd --zone=k8s-pods --list-ports firewall-cmd --zone=k8s-pods --list-servicesSi es necesario, vuelve a ejecutar los comandos de las secciones anteriores para configurar los nodos de forma correcta. Es posible que debas ejecutar los comandos como usuario raíz.
Problema conocido de firewalld
Cuando ejecutas GKE en Bare Metal con firewalld habilitado en Red Hat Enterprise Linux (RHEL), los cambios en firewalld pueden quitar las cadenas iptables de Cilium en la red host. El Pod anetd agrega las cadenas iptables cuando se inicia. La pérdida de las cadenas iptables de Cilium hace que el Pod del nodo pierda conectividad de red fuera del nodo.
Entre los cambios en firewalld que quitan las cadenas de iptables, se incluyen los siguientes:
Reinicio de
firewalldconsystemctlVuelve a cargar
firewalldcon el cliente de línea de comandos (firewall-cmd --reload)
Para aplicar cambios de firewalld sin quitar las cadenas de iptables, reinicia anetd en el nodo:
Ubica y borra el Pod
anetdcon los siguientes comandos para reiniciaranetd:kubectl get pods -n kube-system kubectl delete pods -n kube-system ANETD_XYZReemplaza ANETD_XYZ con el nombre del pod
anetd.