Requisitos de rede

Este documento descreve os requisitos de rede para instalar e operar o Google Distributed Cloud.

Requisitos de rede externa

O Google Distributed Cloud requer uma conexão de Internet para fins operacionais. O Google Distributed Cloud recupera componentes de cluster do Container Registry, e o cluster é registrado no 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

O Google Distributed Cloud pode trabalhar com a conectividade da camada 2 ou da camada 3 entre nós do cluster. 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.

Quando você usa o balanceador de carga de camada 2 em pacote com MetalLB (spec.loadBalancer.mode: bundled e spec.loadBalancer.type: layer2), os nós do balanceador de carga exigem a adjacência da camada 2. O requisito de adjacência da camada 2 se aplica se você executa o balanceador de carga em nós do plano de controle ou em um conjunto dedicado de nós de balanceamento de carga. O balanceamento de carga em pacote com o BGP é compatível com o protocolo da camada 3. Portanto, a adjacência estrita da camada 2 não é necessária.

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

  • Para o balanceamento de carga em pacote da camada 2, todos os balanceadores de carga de um determinado cluster estão no mesmo domínio da camada 2. Os nós do plano de controle também precisam estar no mesmo domínio da camada 2.
  • Para o balanceamento de carga da camada 2 em pacote, todos os endereços IP virtuais (VIPs) 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 do balanceador de carga de entrada.

Redes de pods

O Google Distributed Cloud permite configurar até 250 pods por nó. O Kubernetes atribui um bloco de roteamento entre domínios sem classe (CIDR, na sigla em inglês) a cada nó para que cada pod possa ter 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. Esse método apresentou algumas desvantagens.

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

No diagrama a seguir, ilustramos vários conceitos de rede importantes para o Google Distributed Cloud em uma possível configuração de rede.

Configuração de rede típica do Google Distributed Cloud

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

Esta seção identifica os requisitos de porta para clusters do Google Distributed Cloud. As tabelas a seguir mostram como as portas UDP e TCP são usadas por componentes do Kubernetes em nós de cluster e de balanceador de carga.

Nós do plano de controle

Versão 1.28

Protocolo Direção Intervalo de portas Finalidade Usada por
TCP Entrada 22 Provisionamento e atualização de nós do cluster de administrador Estação de trabalho do administrador
TCP Entrada 2.379 a 2.381 API, métricas e integridade do cliente do servidor etcd kube-apiserver e etcd
TCP Entrada 2.382 a 2.384 API, métricas e integridade do cliente do servidor etcd kube-apiserver e etcd-events
TCP Ambos 4240 Verificação de integridade da CNI Tudo
UDP Entrada 6081 Encapsulamento GENEVE Só para mim
TCP Entrada 6444 Servidor da API Kubernetes Tudo
TCP Entrada 8443 e 8444 Serviço de identidade do GKE v2 Implantação ais em execução no namespace anthos-identity-service
TCP Entrada 9100 proxy de autenticação node-exporter
TCP Entrada 9101 Exibir métricas de nó somente no localhost

Requisito de porta adicionada para versão 1.28 e mais recentes.

node-exporter
TCP Entrada 9977 Receber evento de auditoria do servidor da API audit-proxy
TCP Entrada 10250 API kubelet Plano próprio e de controle
TCP Entrada 10256 Verificação de integridade do nó Tudo
TCP Entrada 10257 kube-controller-manager

O número da porta foi alterado para a versão 1.28 e mais recentes.

Só para mim
TCP Entrada 10259 kube-scheduler

O número da porta foi alterado para a versão 1.28 e mais recentes.

Só para mim
TCP Entrada 14443 Serviço de webhook do ANG kube-apiserver e ang-controller-manager

Versão 1.16

Protocolo Direção Intervalo de portas Finalidade Usada por
TCP Entrada 22 Provisionamento e atualização de nós do cluster de administrador Estação de trabalho do administrador
TCP Entrada 2.379 a 2.381 API, métricas e integridade do cliente do servidor etcd kube-apiserver e etcd
TCP Entrada 2.382 a 2.384 API, métricas e integridade do cliente do servidor etcd

Requisito para portas adicionadas para a versão 1.16 e mais recentes.

kube-apiserver e etcd-events
TCP Ambos 4240 Verificação de integridade da CNI Tudo
UDP Entrada 6081 Encapsulamento GENEVE Só para mim
TCP Entrada 6444 Servidor da API Kubernetes Tudo
TCP Entrada 9100 Veicular métricas node-exporter
TCP Entrada 9443 Métricas de exibição/proxy para componentes do plano de controle. Esse requisito de porta é para a versão 1.16 do cluster e anteriores. kube-control-plane-metrics-proxy
TCP Entrada 9977 Receber evento de auditoria do servidor da API audit-proxy
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 Entrada 14443 Serviço de webhook do ANG kube-apiserver e ang-controller-manager

Versão 1.15 e anteriores

Protocolo Direção Intervalo de portas Finalidade Usada por
TCP Entrada 22 Provisionamento e atualização de nós do cluster de administrador Estação de trabalho do administrador
TCP Entrada 2.379 a 2.381 API, métricas e integridade do cliente do servidor etcd kube-apiserver e etcd
TCP Ambos 4240 Verificação de integridade da CNI Tudo
UDP Entrada 6081 Encapsulamento GENEVE Só para mim
TCP Entrada 6444 Servidor da API Kubernetes Tudo
TCP Entrada 9100 Veicular métricas node-exporter
TCP Entrada 9443 Métricas de exibição/proxy para componentes do plano de controle. Esse requisito de porta é para a versão 1.16 do cluster e anteriores. kube-control-plane-metrics-proxy
TCP Entrada 9977 Receber evento de auditoria do servidor da API audit-proxy
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 Entrada 14443 Serviço de webhook do ANG kube-apiserver e ang-controller-manager

Nós de trabalho

Versão 1.28

Protocolo Direção Intervalo de portas Finalidade Usada por
TCP Entrada 22 Provisionamento e atualização de nós de cluster de usuário Nós do cluster de administrador
TCP Ambos 4240 Verificação de integridade da CNI Tudo
UDP Entrada 6081 Encapsulamento GENEVE Só para mim
TCP Entrada 9100 proxy de autenticação node-exporter
TCP Entrada 9101 Exibir métricas de nó somente no localhost

Requisito de porta adicionada para versão 1.28 e mais recentes.

node-exporter
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

Versão 1.16

Protocolo Direção Intervalo de portas Finalidade Usada por
TCP Entrada 22 Provisionamento e atualização de nós de cluster de usuário Nós do cluster de administrador
TCP Ambos 4240 Verificação de integridade da CNI Tudo
UDP Entrada 6081 Encapsulamento GENEVE Só para mim
TCP Entrada 9100 Veicular métricas node-exporter
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

Versão 1.15 e anteriores

Protocolo Direção Intervalo de portas Finalidade Usada por
TCP Entrada 22 Provisionamento e atualização de nós de cluster de usuário Nós do cluster de administrador
TCP Ambos 4240 Verificação de integridade da CNI Tudo
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

Nós do balanceador de carga

Versão 1.28

Protocolo Direção Intervalo de portas Finalidade Usada por
TCP Entrada 22 Provisionamento e atualização de nós de cluster de usuário Nós do cluster de administrador
TCP Entrada 443 Gerenciamento do cluster

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

Tudo
TCP Ambos 4240 Verificação de integridade da CNI Tudo
UDP Entrada 6081 Encapsulamento GENEVE Só para mim
TCP e UDP Entrada 7946 Verificação de integridade do MetalLB Nós do balanceador de carga
TCP Entrada 10256 Verificação de integridade do nó Tudo

Versão 1.16

Protocolo Direção Intervalo de portas Finalidade Usada por
TCP Entrada 22 Provisionamento e atualização de nós de cluster de usuário Nós do cluster de administrador
TCP Entrada 443 Gerenciamento do cluster

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

Tudo
TCP Ambos 4240 Verificação de integridade da CNI Tudo
UDP Entrada 6081 Encapsulamento GENEVE Só para mim
TCP Entrada 7946 Verificação de integridade do MetalLB nós do balanceador de carga
TCP Entrada 10256 Verificação de integridade do nó Tudo

Versão 1.15 e anteriores

Protocolo Direção Intervalo de portas Finalidade Usada por
TCP Entrada 22 Provisionamento e atualização de nós de cluster de usuário Nós do cluster de administrador
TCP Entrada 443 Gerenciamento do cluster

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

Tudo
TCP Ambos 4240 Verificação de integridade da CNI Tudo
UDP Entrada 6081 Encapsulamento GENEVE Só para mim
TCP Entrada 7946 Verificação de integridade do MetalLB nós do balanceador de carga
TCP Entrada 10256 Verificação de integridade do nó Tudo

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ção de nós do cluster Todos os nós
TCP Entrada 443 Servidor da API Kubernetes para o cluster adicionado

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

Nós do plano de controle e do balanceador de carga

Configurar portas de firewall

Você não precisa desativar o firewall para executar o Google Distributed Cloud no Red Hat Enterprise Linux (RHEL). Para usar com firewall, é preciso abrir as portas UDP e TCP usadas pelos nós do plano de controle, de trabalho e do 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. Execute os comandos como o usuário raiz.

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.

Confirmar a configuração da porta

Para verificar a configuração da porta, use as seguintes etapas nos nós do plano de controle, do worker e do balanceador de carga:

  1. Execute o seguinte comando do Network Mapper para ver quais portas estão abertas:

    nmap localhost
    
  2. Execute os seguintes comandos para receber as configurações de firewall:

    firewall-cmd --zone=public --list-all-policies
    firewall-cmd --zone=public --list-ports
    firewall-cmd --zone=public --list-services
    firewall-cmd --zone=k8s-pods --list-all-policies
    firewall-cmd --zone=k8s-pods --list-ports
    firewall-cmd --zone=k8s-pods --list-services
    
  3. Se necessário, execute novamente os comandos das seções anteriores para configurar os nós corretamente. Talvez seja necessário executar os comandos como o usuário raiz.

Problema conhecido de firewall

Ao executar o Google Distributed Cloud com firewalld ativado no Red Hat Enterprise Linux (RHEL), as alterações em firewalld podem remover as cadeias iptables do Cilium na rede do host. As cadeias iptables são adicionadas pelo pod anetd quando ele é iniciado. A perda das cadeias iptables do Cilium faz com que o pod no nó perca a conectividade de rede fora dele.

As mudanças em firewalld que removem as cadeias de iptables incluem, entre outras:

  • Reiniciando firewalld, usando systemctl

  • Como recarregar firewalld com o cliente de linha de comando (firewall-cmd --reload)

Para aplicar mudanças de firewalld sem remover cadeias de iptables, reinicie anetd no nó:

  1. Localize e exclua o pod anetd com os seguintes comandos para reiniciar anetd:

    kubectl get pods -n kube-system kubectl delete pods -n kube-system ANETD_XYZ
    

    Substitua ANETD_XYZ pelo nome do pod anetd.