Requisitos de rede

Este documento descreve os requisitos de rede para instalar e operar o Google Distributed Cloud (apenas software) em bare metal.

Esta página destina-se a administradores e arquitetos, operadores e especialistas em redes que gerem o ciclo de vida da infraestrutura tecnológica subjacente e concebem e arquitetam a rede para a respetiva organização. Para saber mais sobre as funções comuns e as tarefas de exemplo que referimos no Google Cloud conteúdo, consulte Funções e tarefas comuns do utilizador do GKE.

Requisitos de rede externos

O Google Distributed Cloud requer uma ligação à Internet para fins operacionais. O Google Distributed Cloud obtém componentes do cluster do Artifact Registry e o cluster é registado no Connect Agent.

Pode ligar-se à Google através da Internet pública através de HTTPS, uma rede privada virtual (VPN) ou uma ligação Dedicated Interconnect.

Se as máquinas que está a usar para a estação de trabalho de administração e os nós do cluster usarem um servidor proxy para aceder à Internet, o servidor proxy tem de permitir algumas ligações específicas. Para ver detalhes, consulte a secção de pré-requisitos do artigo Instale através de um proxy.

Requisitos da rede interna

O Google Distributed Cloud pode funcionar com a conetividade da camada 2 ou da camada 3 entre os nós do cluster. Os nós do equilibrador de carga podem ser os nós do plano de controlo ou um conjunto dedicado de nós. Para mais informações, consulte o artigo Escolher e configurar balanceadores de carga.

Quando usa o balanceamento de carga da camada 2 agrupado com o MetalLB (spec.loadBalancer.mode: bundled e spec.loadBalancer.type: layer2), os nós do balanceador de carga requerem a adjacência da camada 2. O requisito de adjacência da camada 2 aplica-se quer execute o equilibrador de carga em nós do plano de controlo ou num conjunto dedicado de nós de equilíbrio de carga. O equilíbrio de carga integrado com BGP suporta o protocolo de camada 3, pelo que a adjacência estrita da camada 2 não é necessária.

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

• Para o balanceamento de carga de camada 2 agrupado, todos os balanceadores de carga para um determinado cluster estão no mesmo domínio de camada 2. Os nós do plano de controlo também têm de estar no mesmo domínio da camada 2.
• Para o balanceamento de carga da camada 2 agrupado, todos os endereços IP virtuais (VIPs) têm de estar na sub-rede da máquina do balanceador de carga e encaminháveis para o gateway da sub-rede.
• Os utilizadores são responsáveis por permitir o tráfego do equilibrador de carga de entrada.

Networking de pods e serviços

Os intervalos de endereços IP disponíveis para serviços e pods são especificados no ficheiro de configuração do cluster. As secções seguintes abordam as restrições mínimas e máximas para os intervalos de endereços, bem como alguns dos fatores relacionados que tem de considerar ao planear a instalação do cluster.

O número de pods e serviços que pode ter nos seus clusters é controlado pelas seguintes definições:

• clusterNetwork.pods.cidrBlocks especifica o número de pods permitidos no seu cluster.

• clusterNetwork.services.cidrBlocks especifica o número de serviços permitidos no seu cluster.

• nodeConfig.podDensity.maxPodsPerNode especifica o número máximo de pods que podem ser executados num único nó.

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: admin-basic
  namespace: cluster-admin-basic
spec:
  type: admin
  profile: default
  ...
  clusterNetwork:
    pods:
      cidrBlocks:
      - 192.168.0.0/16
    services:
      cidrBlocks:
      - 10.96.0.0/20
  ...
  nodeConfig:
    podDensity:
      maxPodsPerNode: 250

Intervalos de endereços IP para pods e serviços

Especifica um intervalo de endereços IP como um bloco CIDR (Classless Inter-Domain Routing) a ser usado para Pods e outro bloco CIDR a ser usado para os endereços ClusterIP dos serviços Kubernetes. Use endereços IP no espaço de endereços privados, conforme descrito na RFC 1918. O ficheiro de configuração do cluster é pré-preenchido com valores que se enquadram nos limites descritos na tabela seguinte:

Para evitar a sobreposição com endereços IP acessíveis na sua rede, pode ter de usar intervalos CIDR diferentes dos valores pré-preenchidos. Em particular, os intervalos de serviços e agrupamentos não podem sobrepor-se ao seguinte:

• Endereços IP de nós em qualquer cluster

• VIPs usados por nós do plano de controlo e balanceadores de carga

• Endereços IP de servidores DNS ou servidores NTP

As verificações prévias bloqueiam a criação e as atualizações de clusters se forem identificados endereços IP sobrepostos.

Pode aumentar o intervalo da rede de serviços (clusterNetwork.services.cidrBlocks) depois de criar um cluster, mas não pode reduzir o número de endereços IP atribuídos nem alterá-los. Só pode alterar o sufixo do bloco CIDR, reduzindo o valor da máscara para aumentar o número de endereços IP.

Ambos os parâmetros clusterNetwork.pods.cidrBlocks e nodeConfig.podDensity.maxPodsPerNode (descritos na secção seguinte) são imutáveis, pelo que deve planear cuidadosamente o crescimento futuro do cluster para evitar ficar sem capacidade de nós. Para ver os máximos recomendados para pods por cluster, pods por nó e nós por cluster com base em testes, consulte o artigo Limites.

Máximo de agrupamentos por nó

No bare metal, o Google Distributed Cloud permite-lhe configurar um máximo de 250 pods por nó. O Kubernetes atribui um bloco CIDR a cada nó para que cada pod possa ter um endereço IP exclusivo. O tamanho do bloco CIDR do pod corresponde ao número máximo de pods por nó.

A tabela seguinte indica o tamanho do bloco CIDR que o Kubernetes atribui a cada nó com base no número máximo de pods configurado por nó:

A execução de 250 pods por nó requer que o Kubernetes reserve um bloco CIDR para cada nó./23 Partindo do princípio de que o seu cluster usa o valor predefinido de /16 para o campo clusterNetwork.pods.cidrBlocks, o seu cluster tem um limite de (2^(23-16))=128 nós.

Se pretender expandir o cluster para além deste limite, recomendamos vivamente que defina clusterNetwork.pods.cidrBlocks para um bloco CIDR de pods significativamente maior do que o valor pré-preenchido.

Para mais informações sobre como o número de pods e serviços, bem como outros fatores, afetam a escalabilidade do cluster, consulte o artigo Aumente a escala dos clusters do Google Distributed Cloud.

Implementação de cluster de utilizador único com alta disponibilidade

O diagrama seguinte ilustra vários conceitos de rede importantes para o Google Distributed Cloud numa possível configuração de rede.

Considere as seguintes informações para cumprir os requisitos de rede:

• Os nós do plano de controlo executam os balanceadores de carga e têm todos conetividade da camada 2, enquanto outras ligações, incluindo nós de trabalho, só requerem conetividade da camada 3.
• Os ficheiros de configuração definem os endereços IP para os conjuntos de nós de trabalho. Os ficheiros de configuração também definem VIPs para os seguintes fins:
  • Serviços
  • Entrada
  • Acesso ao plano de controlo através da API Kubernetes
• Precisa de uma ligação a Google Cloud.

Utilização de portas

Esta secção identifica os requisitos de portas para clusters do Google Distributed Cloud. As tabelas seguintes mostram como as portas UDP e TCP são usadas pelos componentes do Kubernetes nos nós do cluster e do equilibrador de carga.

Nós do plano de controlo

Nós trabalhadores

Nós do balanceador de carga

Requisitos de portas de vários clusters

Numa configuração com vários clusters, os clusters adicionados têm de incluir as seguintes portas para comunicar com o cluster de administrador.

Configure as portas do firewalld

Não tem de desativar o firewalld para executar o Google Distributed Cloud no Red Hat Enterprise Linux (RHEL). Para usar o firewalld, tem de abrir as portas UDP e TCP usadas pelos nós do plano de controlo, do trabalhador e do equilibrador de carga, conforme descrito em Utilização de portas nesta página. As configurações de exemplo seguintes mostram como pode abrir portas com firewall-cmd, o utilitário de linha de comandos firewalld. Deve executar os comandos como utilizador root.

Exemplo de configuração do nó do plano de controlo

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

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=10256/tcp
firewall-cmd --permanent --zone=public --add-port=10257/tcp
firewall-cmd --permanent --zone=public --add-port=10259/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

Para ver os requisitos de portas específicos da versão do cluster que pretende usar, consulte a secção Utilização de portas anterior. Atualize os comandos de exemplo em conformidade.

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

Exemplo de configuração do nó trabalhador

O bloco de comandos seguinte mostra um exemplo de como pode 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

Para ver os requisitos de portas específicos da versão do cluster que pretende usar, consulte a secção Utilização de portas anterior. Atualize os comandos de exemplo em conformidade.

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

Exemplo de configuração do nó do balanceador de carga

O bloco de comandos seguinte mostra um exemplo de como pode abrir as portas necessárias em servidores que executam nós do equilibrador 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

Para ver os requisitos de portas específicos da versão do cluster que pretende usar, consulte a secção Utilização de portas anterior. Atualize os comandos de exemplo em conformidade.

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

Configuração suplementar para o RHEL 9.2 e 9.4

O Red Hat Enterprise Linux (RHEL) versão 9.2 e 9.4 é suportado como GA nas versões 1.29.400 e superiores. Com as versões 9.2 e 9.4 do RHEL, tem de fazer uma configuração adicional do firewalld nos nós para que os seus serviços e pods funcionem corretamente:

1. Liste as interfaces ativas do nó para encontrar a interface do nó principal:

   firewall-cmd --list-interfaces
   

   Com base nas convenções de nomenclatura das interfaces de máquinas Linux, o nome da sua interface principal pode ser semelhante a um dos seguintes: eth0, eno1, ens1 ou enp2s0.

2. Liste as zonas do nó para saber que zona a interface principal usa:

   firewall-cmd --list-all-zones
   

   Por exemplo, se a sua interface principal for eno1, a secção seguinte da resposta indica que a interface principal está na zona public:

   ...
   public (active)
     target: default
     icmp-block-inversion: no
     interfaces: eno1
     sources:
     ...
   

3. Execute os seguintes comandos firewalld para configurar detalhes personalizados da zona e da política para o RHEL 9.2 ou 9.4:

   firewall-cmd --permanent --new-zone=cilium
   firewall-cmd --permanent --zone=cilium --add-interface=cilium_host
   firewall-cmd --permanent --zone=cilium --set-target ACCEPT
   firewall-cmd --permanent --zone=cilium --add-masquerade
   firewall-cmd --permanent --zone=cilium --add-forward
   firewall-cmd --permanent --new-policy cilium-host-port-forwarding
   firewall-cmd --permanent --policy cilium-host-port-forwarding --add-ingress-zone IN_ZONE
   firewall-cmd --permanent --policy cilium-host-port-forwarding --add-egress-zone cilium
   firewall-cmd --permanent --policy cilium-host-port-forwarding --set-target ACCEPT
   firewall-cmd --reload
   

   Substitua IN_ZONE por um dos seguintes valores, com base no que encontrou nos passos anteriores:

   • public: zona predefinida para utilização em áreas públicas onde apenas são aceites ligações recebidas selecionadas.
   • trusted: zona predefinida num ambiente controlado onde todas as ligações de rede são aceites.
   • O nome de uma zona personalizada que definiu.

4. Siga a documentação do fornecedor para configurar a sua solução de armazenamento.

   Por exemplo, se estiver a usar o Portworx para gerir cargas de trabalho com estado, os requisitos de rede do Portworx indicam as portas que têm de permanecer abertas.

   Para cada uma das portas indicadas na documentação do fornecedor, execute o seguinte comando:

   firewall-cmd --permanent --zone=public --add-port=PORT_INFO
   

   Substitua PORT_INFO pelo número da porta ou pelo intervalo de números de porta, seguido do protocolo. Por exemplo, 10250-10252/tcp.

Confirme a configuração de portas

Para validar a configuração da porta, use os seguintes passos nos nós do plano de controlo, do trabalhador e do balanceador de carga:

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

   nmap localhost
   

2. Execute os seguintes comandos para obter as definições de configuração do firewalld:

   firewall-cmd --info-zone=public
   firewall-cmd --info-zone=k8s-pods
   firewall-cmd --list-all-policies
   

3. Se necessário, volte a executar os comandos das secções anteriores para configurar os nós corretamente. Pode ter de executar os comandos como utilizador root.

Problema conhecido do firewalld

Quando executa o Google Distributed Cloud com o firewalld ativado no Red Hat Enterprise Linux (RHEL), as alterações ao firewalld podem remover as cadeias iptables na rede do anfitrião. As cadeias iptables são adicionadas pelo dispositivo anetd Pod quando é iniciado. A perda das cadeias iptables do Cilium faz com que o pod no nó perca a conetividade de rede fora do nó.

As alterações a firewalld que removem as cadeias de iptables incluem, entre outras:

• A reiniciar firewalld com o systemctl

• Atualizar o firewalld com o cliente de linha de comandos (firewall-cmd --reload)

Para aplicar as alterações firewalld sem remover as cadeias iptables, reinicie anetd no nó:

1. Localize e elimine o anetd pod 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.