Requisitos de rede

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 (com HTTPS), por meio de uma rede privada virtual (VPN) ou por meio de uma Interconexão dedicada.

Requisitos de rede interna

Os clusters do Anthos em bare metal podem funcionar com conectividade L2 ou L3 entre nós do cluster e exigem que os nós do balanceador de carga estejam no mesmo domínio L2. Os nós do balanceador de carga podem ser os nós do plano de controle ou um conjunto dedicado de nós. Para informações de configuração, consulte Como escolher e configurar balanceadores de carga.

O requisito de rede L2 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 com balanceador de carga são:

  • Todos os balanceadores de carga para um determinado cluster estão no mesmo domínio L2.
  • Todos os VIPs precisam estar na sub-rede da máquina do balanceador de carga e 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.

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

  • Os nós do plano de controle executam balanceadores de carga e todos estão na mesma rede L2, enquanto outras conexões, incluindo nós de trabalho, só precisam de conectividade L3.
  • Os arquivos de configuração definem endereços IP para pools de nós de trabalho, bem como endereços IP virtuais para serviços, entrada e acesso ao plano de controle (API Kubernetes).
  • Também é necessário ter 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 mestres

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
TCPEntrada443Gerenciamento de clustersNós do cluster de administrador
TCPEntrada6443Servidor da API KubernetesTudo
TCPEntrada6444HA do plano de controleTudo
TCPEntrada2379 - 2380API do servidor etcdkube-apiserver e etcd
TCPEntrada10250API kubeletPlano de controle
TCPEntrada10251kube-schedulerSó para mim
TCPEntrada10252kube-controller-managerSó para mim
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 de controle
TCPEntrada30000 - 32767Serviços NodePortSó para mim
TCPAmbos4240Verificação de integridade da CNITudo

Nós do balanceador de carga

ProtocoloDireçãoIntervalo de portasFinalidadeUsada por
UDPEntrada6081Encapsulamento GENEVESó para mim
TCPEntrada6444Servidor da API KubernetesTudo
TCPAmbos4240Verificação de integridade da CNITudo
TCPEntrada7946Verificação de integridade do LB de metalNós de LB
UDPEntrada7946Verificação de integridade do LB de metalNós de LB