Requisitos de red externa
Anthos en equipos físicos requiere una conexión a Internet para fines operativos. Anthos en equipos físicos recupera componentes de los clústeres de Container Registry, y los clústeres se registran 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 la instalación detrás de un proxy.
Requisitos de red interna
Los clústeres de Anthos en equipos físicos pueden funcionar con conectividad de capa 2 o capa 3 entre nodos del clúster, pero requieren que los nodos del balanceador de cargas tengan conectividad de capa 2. 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.
El requisito de conectividad de capa 2 se aplica si ejecutas el balanceador de cargas en el grupo de nodos del plano de control o en un conjunto dedicado de nodos.
Los requisitos para las máquinas del balanceador de cargas son los siguientes:
- Todos los balanceadores de cargas de un clúster determinado se encuentran en el mismo dominio de capa 2.
- Todas las direcciones IP virtuales (VIP) deben estar en la subred de la máquina del balanceador de cargas y pueden enrutarse a la puerta de enlace de la subred.
- Los usuarios son responsables de permitir el tráfico de balanceador de cargas de entrada.
Herramientas de redes de pods
Los clústeres de Anthos en equipos físicos 1.7.0 y versiones posteriores te permiten 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.
Implementación de clúster de usuario único con alta disponibilidad
En el siguiente diagrama, se ilustran varios conceptos clave de red para Anthos en equipos físicos 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
- 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 muestra cómo se usan los puertos UDP y TCP en los nodos del clúster y del balanceador de cargas.
Nodos de plano de control
| Protocolo | Dirección | Intervalo de puerto | Objetivo | Usado por |
|---|---|---|---|---|
| UDP | Entrante | 6081 | Encapsulamiento GENEVE | Propio |
| TCP | Entrante | 22 | Aprovisionamiento y actualizaciones de los nodos del clúster de administrador | Estación de trabajo de administrador |
| TCP | Entrante | 6444 | Servidor de API de Kubernetes | Todas |
| TCP | Entrante | 2379 - 2380 | API del cliente del servidor de etcd | kube-apiserver y etcd |
| 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 | Ambos | 4240 | Verificación de estado de CNI | Todas |
Nodos trabajadores
| 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 |
| 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 |
| TCP | Ambos | 4240 | Verificación de estado de CNI | Todas |
Nodos del balanceador de cargas
| 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 |
| UDP | Entrante | 6081 | Encapsulamiento GENEVE | Propio |
| TCP | Entrante | 443* | Administración de clústeres | Todas |
| TCP | Ambos | 4240 | Verificación de estado de CNI | Todas |
| TCP | Entrante | 7946 | Verificación de estado de Metal LB | Nodos del balanceador de cargas |
| UDP | Entrante | 7946 | Verificación de estado de Metal LB | Nodos del balanceador de cargas |
| TCP | Entrante | 10256 | Verificación de estado del nodo | All |
* Este puerto se puede configurar en la configuración del clúster mediante el campo controlPlaneLBPort.
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 | Plano de control y nodos del balanceador de cargas |
* Este puerto se puede configurar en la configuración del clúster mediante el campo controlPlaneLBPort.
Configura puertos con firewalld
No es necesario que inhabilites el firewall para ejecutar clústeres de Anthos en equipos físicos en Red Hat Enterprise Linux (RHEL) o CentOS. 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.
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.