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.
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
| Protocolo | Direção | Intervalo de portas | Finalidade | Usada por |
|---|---|---|---|---|
| UDP | Entrada | 6081 | Encapsulamento GENEVE | Só para mim |
| TCP | Entrada | 22 | Provisionamento e atualizações de nós de cluster de administrador | Estação de trabalho do administrador |
| TCP | Entrada | 6444 | Servidor da API Kubernetes | Tudo |
| TCP | Entrada | 2379 - 2380 | API do servidor etcd | kube-apiserver e etcd |
| TCP | Entrada | 10250 | API kubelet | Plano próprio e de controle |
| TCP | Entrada | 10251 | kube-scheduler | Só para mim |
| TCP | Entrada | 10252 | kube-controller-manager | Só para mim |
| TCP | Entrada | 10256 | Verificação de integridade do nó | Tudo |
| TCP | Ambos | 4240 | Verificação de integridade da CNI | Tudo |
Nós de trabalho
| Protocolo | Direção | Intervalo de portas | Finalidade | Usada por |
|---|---|---|---|---|
| TCP | Entrada | 22 | Provisionamento e atualizações de nós de clusters de usuário | Nós do cluster de administrador |
| UDP | Entrada | 6081 | Encapsulamento GENEVE | Só para mim |
| TCP | Entrada | 10250 | API kubelet | Plano próprio e de controle |
| TCP | Entrada | 10256 | Verificação de integridade do nó | Tudo |
| TCP | Entrada | 30000 - 32767 | NodePort serviço | Só para mim |
| TCP | Ambos | 4240 | Verificação de integridade da CNI | Tudo |
Nós do balanceador de carga
| Protocolo | Direção | Intervalo de portas | Finalidade | Usada por |
|---|---|---|---|---|
| TCP | Entrada | 22 | Provisionamento e atualizações de nós de clusters de usuário | Nós do cluster de administrador |
| UDP | Entrada | 6081 | Encapsulamento GENEVE | Só para mim |
| TCP | Entrada | 443* | Gerenciamento de clusters | Tudo |
| TCP | Ambos | 4240 | Verificação de integridade da CNI | Tudo |
| TCP | Entrada | 7946 | Verificação de integridade do LB de metal | nós do balanceador de carga |
| UDP | Entrada | 7946 | Verificação de integridade do LB de metal | nós do balanceador de carga |
| TCP | Entrada | 10256 | Verificaçã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.
| Protocolo | Direção | Intervalo de portas | Finalidade | Usada por |
|---|---|---|---|---|
| TCP | Entrada | 22 | Provisionamento e atualizações de nós do cluster | Todos os nós |
| TCP | Entrada | 443* | Servidor da API Kubernetes para o cluster adicionado | Nó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.