Requisitos de rede

Requisitos de rede externa

Os clusters do Anthos em bare metal exigem uma conexão com a Internet para fins operacionais. Os clusters do Anthos em bare metal recuperam componentes de clusters do Container Registry, e o cluster é registrado com o Connect.

É possível se conectar ao Google usando a Internet pública por HTTPS, uma rede privada virtual (VPN) ou uma conexão de Interconexão dedicada.

Se as máquinas que você está usando para a estação de trabalho de administrador e os nós do cluster usam um servidor proxy para acessar a Internet, o servidor proxy precisa permitir algumas conexões específicas. Para saber mais detalhes, consulte a seção de pré-requisitos de Instalar por trás de um proxy.

Requisitos de rede interna

Os clusters do Anthos em bare metal podem funcionar com a conectividade de Camada 2 ou de Camada 3 entre nós do cluster, mas exigem que os nós do balanceador de carga tenham a conectividade de Camada 2. Os nós do balanceador de carga podem ser os nós do plano de controle ou um conjunto dedicado de nós. Saiba mais em Como escolher e configurar balanceadores de carga.

O requisito de conectividade de Camada 2 se aplica se você executar o balanceador de carga no pool de nós do plano de controle ou em um conjunto de nós dedicado.

Os requisitos para máquinas do balanceador de carga são:

  • Todos os balanceadores de carga de um determinado cluster estão no mesmo domínio da Camada 2.
  • Todos os endereços IP virtuais (VIPs, na sigla em inglês) precisam estar na sub-rede da máquina do balanceador de carga e ser roteáveis para o gateway da sub-rede.
  • Os usuários são responsáveis por permitir o tráfego de entrada no balanceador de carga.

Redes de pods

Os clusters do Anthos nas versões bare metal 1.7.0 e posteriores permitem que você configure até 250 pods por nó. O Kubernetes atribui um bloco de roteamento entre domínios sem classe (CIDR, na sigla em inglês) para cada nó. Assim, cada pod tem um endereço IP exclusivo. O tamanho do bloco CIDR corresponde ao número máximo de Pods por nó. A tabela a seguir lista o tamanho do bloco CIDR que o Kubernetes atribui a cada nó com base no máximo de pods configurados por nó:

Número máximo de pods por nó Bloco de CIDR por nó Número de endereços IP
32 /26 64
33 – 64 /25 128
65 – 128 /24 256
129 - 250 /23 512

A execução de 250 pods por nó exige que o Kubernetes reserve um bloco CIDR /23 para cada nó. Supondo que seu cluster use o valor padrão de /16 para o campo clusterNetwork.pods.cidrBlocks, seu cluster tem um limite de (2(23-16))=128 nós. Se você pretende expandir o cluster além desse limite, aumente o valor de clusterNetwork.pods.cidrBlocks ou reduza o valor de nodeConfig.podDensity.maxPodsPerNode.

Implantação de cluster de usuário único com alta disponibilidade

No diagrama a seguir, ilustramos vários conceitos de rede importantes para os clusters Anthos em bare metal em uma configuração de rede possível.

Clusters do Anthos na configuração de rede típica bare metal

Considere as seguintes informações para atender aos requisitos de rede:

  • Os nós do plano de controle executam os balanceadores de carga. Todos têm conectividade de Camada 2, enquanto outras conexões, inclusive nós de trabalho, exigem apenas conectividade de Camada 3.
  • Os arquivos de configuração definem endereços IP para pools de nós de trabalho. Os arquivos de configuração também definem VIPs para as seguintes finalidades:
    • Serviços
    • Entrada
    • Acesso do plano de controle pela API Kubernetes
  • Você precisa de uma conexão com o Google Cloud.

Uso da porta

Nesta seção, mostramos como as portas UDP e TCP são usadas nos nós do balanceador de carga e de cluster.

Nós do plano de controle

ProtocoloDireçãoIntervalo de portasFinalidadeUsada por
UDPEntrada6081Encapsulamento GENEVESó para mim
TCPEntrada22Provisionamento e atualizações de nós de cluster de administradorEstação de trabalho do administrador
TCPEntrada6444Servidor da API KubernetesTudo
TCPEntrada2379 - 2380API do servidor etcdkube-apiserver e etcd
TCPEntrada10250API kubeletPlano próprio e de controle
TCPEntrada10251kube-schedulerSó para mim
TCPEntrada10252kube-controller-managerSó para mim
TCPEntrada10256Verificação de integridade do nóTudo
TCPAmbos4240Verificação de integridade da CNITudo

Nós de trabalho

ProtocoloDireçãoIntervalo de portasFinalidadeUsada por
TCPEntrada22Provisionamento e atualizações de nós de clusters de usuárioNós do cluster de administrador
UDPEntrada6081Encapsulamento GENEVESó para mim
TCPEntrada10250API kubeletPlano próprio e de controle
TCPEntrada10256Verificação de integridade do nóTudo
TCPEntrada30000 - 32767NodePort serviçoSó para mim
TCPAmbos4240Verificação de integridade da CNITudo

Nós do balanceador de carga

ProtocoloDireçãoIntervalo de portasFinalidadeUsada por
TCPEntrada22Provisionamento e atualizações de nós de clusters de usuárioNós do cluster de administrador
UDPEntrada6081Encapsulamento GENEVESó para mim
TCPEntrada443*Gerenciamento de clustersTudo
TCPAmbos4240Verificação de integridade da CNITudo
TCPEntrada7946Verificação de integridade do LB de metalnós do balanceador de carga
UDPEntrada7946Verificação de integridade do LB de metalnós do balanceador de carga
TCPEntrada10256Verificação de integridade do nóTudo

* Essa porta pode ser configurada na configuração do cluster usando o campo controlPlaneLBPort.

Requisitos de porta de vários clusters

Em uma configuração de vários clusters, os clusters adicionados precisam incluir as portas a seguir para se comunicar com o cluster de administrador.

ProtocoloDireçãoIntervalo de portasFinalidadeUsada por
TCPEntrada22Provisionamento e atualizações de nós do clusterTodos os nós
TCPEntrada443*Servidor da API Kubernetes para o cluster adicionadoNós do plano de controle e do balanceador de carga

* Essa porta pode ser configurada na configuração do cluster usando o campo controlPlaneLBPort.

Configurar portas de firewall

Não é necessário desativar o firewall para executar clusters do Anthos em Bare Metal no Red Hat Enterprise Linux (RHEL) ou no CentOS. Para usar o firewalld, abra as portas UDP e TCP usadas pelo plano de controle, o worker e o balanceador de carga, conforme descrito em Uso da porta nesta página. As seguintes configurações de exemplo mostram como você pode abrir portas com firewall-cmd, o utilitário de linha de comando do firewalld.

Configuração de exemplo de nós do plano de controle

O bloco de comandos a seguir mostra um exemplo de como abrir as portas necessárias em servidores que executam nós do plano de controle:

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

Substitua PODS_CIDR pelos blocos CIDR reservados para os pods configurados no campo clusterNetwork.pods.cidrBlocks. O bloco CIDR padrão para pods é 192.168.0.0/16.

Configuração de exemplo de nó de trabalho

O bloco de comandos a seguir mostra um exemplo de como abrir as portas necessárias em servidores que executam nós de trabalho:

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

Substitua PODS_CIDR pelos blocos CIDR reservados para os pods configurados no campo clusterNetwork.pods.cidrBlocks. O bloco CIDR padrão para pods é 192.168.0.0/16.

Configuração de exemplo de nó do balanceador de carga

O bloco de comandos a seguir mostra um exemplo de como abrir as portas necessárias em servidores que executam nós do balanceador de carga:

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

Substitua PODS_CIDR pelos blocos CIDR reservados para os pods configurados no campo clusterNetwork.pods.cidrBlocks. O bloco CIDR padrão para pods é 192.168.0.0/16.