Versión 1.7. Ya no se admite esta versión. Para obtener más información, consulta la política de asistencia de la versión. Para obtener información sobre cómo actualizar a la versión 1.8, consulta Actualiza Anthos en equipos físicos en la documentación de la versión 1.8.

Versiones disponibles: 1.10  |   1.9  |   1.8

Requisitos de red

Requisitos de red

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 con la Internet pública (con HTTPS), a través de una red privada virtual (VPN) o a través de una interconexión dedicada.

Requisitos de red interna

Los clústeres de Anthos alojados en equipos físicos pueden funcionar con conectividad de capa 2 o capa 3 entre nodos de clúster y requieren que los nodos del balanceador de cargas estén en el mismo dominio de capa 2. Los nodos del balanceador de cargas pueden ser los nodos del plano de control o un conjunto de nodos dedicado. Consulta Elige y configura balanceadores de cargas para obtener información sobre la configuración.

El requisito de red de capa 2 se aplica si ejecutas el balanceador de cargas en el grupo de nodos del plano de control o en un conjunto de nodos dedicado.

Los requisitos para las máquinas de 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.
  • Todos los VIP deben estar en la subred de 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.

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 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 el clusterNetwork.pods.cidrBlocks del clúster está configurado en el valor predeterminado de /16, esto permite que el clúster tenga 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.

Configuración típica de red de Anthos en equipos físicos

  • Los nodos del plano de control ejecutan balanceadores de cargas y todos están en la misma red 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
  • También se requiere 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 principales

ProtocoloDirecciónIntervalo de puertoObjetivoUsado por
UDPEntrante6081Encapsulamiento GENEVEPropio
TCPEntrante22Aprovisionamiento y actualizaciones de los nodos del clúster de administradorEstación de trabajo de administrador
TCPEntrante6444Servidor de API de KubernetesTodos
TCPEntrante2379 - 2380API del cliente del servidor de etcdkube-apiserver, etcd
TCPEntrante10250API de kubeletUso propio, plano de control
TCPEntrante10251kube-schedulerPropio
TCPEntrante10252kube-controller-managerPropio
TCPAmbos4240Verificación de estado de CNITodos

Nodos trabajadores

ProtocoloDirecciónIntervalo de puertoObjetivoUsado por
TCPEntrante22Aprovisionamiento y actualizaciones de nodos de clústeres de usuariosNodos del clúster del administrador
UDPEntrante6081Encapsulamiento GENEVEPropio
TCPEntrante10250API de kubeletUso propio, plano de control
TCPEntrante30000: 32767Servicios de NodePortPropio
TCPAmbos4240Verificación de estado de CNITodos

Nodos del balanceador de cargas

ProtocoloDirecciónIntervalo de puertoObjetivoUsado por
TCPEntrante22Aprovisionamiento y actualizaciones de nodos de clústeres de usuariosNodos del clúster del administrador
UDPEntrante6081Encapsulamiento GENEVEPropio
TCPEntrante443*Administración de clústeresTodas
TCPAmbos4240Verificación de estado de CNITodos
TCPEntrante7946Verificación de estado de Metal LBNodos de LB
UDPEntrante7946Verificación de estado de Metal LBNodos de LB

* 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.

ProtocoloDirecciónIntervalo de puertoObjetivoUsado por
TCPEntrante22Aprovisionamiento y actualizaciones de nodos de clústeresTodos los nodos
TCPEntrante443*Servidor de la API de Kubernetes para el clúster agregadoPlano de control, nodos de LB

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

Configura puertos con firewalld

A partir de los clústeres de Anthos en un equipo físico 1.7.0, no es necesario que inhabilites la 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 de instancia principal, 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, el cliente de línea de comandos de firewall.

Configuración de ejemplo de nodo principal

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

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=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, 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 de ejemplo, se muestra cómo puedes abrir los puertos necesarios en los 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=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, 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 de ejemplo, se muestra cómo puedes abrir los puertos necesarios en los 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=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 --reloadfirewall-cmd --reload

Reemplaza PODS_CIDR por los bloques CIDR reservados para los Pods, clusterNetwork.pods.cidrBlocks. El bloque CIDR predeterminado para los pods es 192.168.0.0/16.