Este documento descreve os requisitos de rede para instalar e operar o Google Distributed Cloud.
Esta página é destinada a administradores, arquitetos, operadores e especialistas em redes que gerenciam o ciclo de vida da infraestrutura de tecnologia subjacente e projetam e arquitetam a rede para a organização. Para saber mais sobre papéis comuns e tarefas de exemplo referenciados no conteúdo do Google Cloud, consulte Tarefas e funções de usuário comuns do GKE Enterprise.
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 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
O Google Distributed Cloud pode funcionar com a conectividade da camada 2 ou da camada 3 entre os 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) 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. Esse método apresentou algumas desvantagens.
Implantação de cluster de usuário único com alta disponibilidade
O diagrama a seguir ilustra vários conceitos de rede importantes para o Google Distributed Cloud em uma possível configuração de rede.
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 pelos componentes do Kubernetes nos nós do balanceador de carga e do cluster.
Nós do plano de controle
Versão 1.29
| Protocolo | Direção | Intervalo de portas | Finalidade | Usada por |
|---|---|---|---|---|
| TCP | Entrada | 22 | Provisionamento e atualizações de nós de cluster de administrador | Estação de trabalho do administrador |
| TCP | Entrada | 2379 - 2381 | API do cliente do servidor etcd, métricas e integridade | kube-apiserver e etcd |
| TCP | Entrada | 2382 - 2384 | API do cliente do servidor etcd-events, métricas e integridade | kube-apiserver e etcd-events |
| TCP | Ambos | 4240 | Verificação de integridade da CNI | Todas |
| UDP | Entrada | 6081 | Encapsulamento GENEVE | Só para mim |
| TCP | Entrada | 6444 | Servidor da API Kubernetes | Todas |
| TCP | Entrada | 9100 | auth-proxy | node-exporter |
| TCP | Entrada | 9101 | Fornecer métricas de nó somente no localhost
(aplica-se à versão 1.28 e mais recentes) |
node-exporter |
| TCP | Entrada | 9977 | Receber um 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ó | Todas |
| TCP | Entrada | 10257 | kube-controller-manager
(mudança de número da porta para a versão 1.28 e mais recentes) |
Só para mim |
| TCP | Entrada | 10259 | kube-scheduler
(mudança de número da porta para a versão 1.28 e mais recentes) |
Só para mim |
| TCP | Entrada | 11002 | O contêiner principal do GKE Identity Service se vincula à porta por hostPort
(aplica-se à versão 1.29 e mais recentes) |
Só para mim |
| TCP | Entrada | 14443 | Serviço de webhook do ANG | kube-apiserver e ang-controller-manager |
Versão 1.28
| Protocolo | Direção | Intervalo de portas | Finalidade | Usada por |
|---|---|---|---|---|
| TCP | Entrada | 22 | Provisionamento e atualizações de nós de cluster de administrador | Estação de trabalho do administrador |
| TCP | Entrada | 2379 - 2381 | API do cliente do servidor etcd, métricas e integridade | kube-apiserver e etcd |
| TCP | Entrada | 2382 - 2384 | API do cliente do servidor etcd-events, métricas e integridade | kube-apiserver e etcd-events |
| TCP | Ambos | 4240 | Verificação de integridade da CNI | Todas |
| UDP | Entrada | 6081 | Encapsulamento GENEVE | Só para mim |
| TCP | Entrada | 6444 | Servidor da API Kubernetes | Todas |
| TCP | Entrada | 8444 | O contêiner principal do GKE Identity Service se vincula à porta por hostPort
(aplicável apenas à versão 1.28) |
Todas |
| TCP | Entrada | 9100 | auth-proxy | node-exporter |
| TCP | Entrada | 9101 | Fornecer métricas de nó somente no localhost
(aplica-se à versão 1.28 e mais recentes) |
node-exporter |
| TCP | Entrada | 9977 | Receber um 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ó | Todas |
| TCP | Entrada | 10257 | kube-controller-manager
(mudança de número da porta para a versão 1.28 e mais recentes) |
Só para mim |
| TCP | Entrada | 10259 | kube-scheduler
(mudança de número da porta 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ções de nós de cluster de administrador | Estação de trabalho do administrador |
| TCP | Entrada | 2379 - 2381 | API do cliente do servidor etcd, métricas e integridade | kube-apiserver e etcd |
| TCP | Entrada | 2382 - 2384 | API do cliente do servidor etcd-events, métricas e integridade
(aplica-se à versão 1.16 e mais recentes) |
kube-apiserver e etcd-events |
| TCP | Ambos | 4240 | Verificação de integridade da CNI | Todas |
| UDP | Entrada | 6081 | Encapsulamento GENEVE | Só para mim |
| TCP | Entrada | 6444 | Servidor da API Kubernetes | Todas |
| TCP | Entrada | 9100 | Exibir métricas | node-exporter |
| TCP | Entrada | 9443 | Métricas de servidor/proxy para componentes do plano de controle. Esse requisito de porta é para a versão 1.16 e anteriores do cluster. | kube-control-plane-metrics-proxy |
| TCP | Entrada | 9977 | Receber um 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ó | Todas |
| TCP | Entrada | 14443 | Serviço de webhook do ANG | kube-apiserver e ang-controller-manager |
Versão 1.15 e inferior
| Protocolo | Direção | Intervalo de portas | Finalidade | Usada por |
|---|---|---|---|---|
| TCP | Entrada | 22 | Provisionamento e atualizações de nós de cluster de administrador | Estação de trabalho do administrador |
| TCP | Entrada | 2379 - 2381 | API do cliente do servidor etcd, métricas e integridade | kube-apiserver e etcd |
| TCP | Ambos | 4240 | Verificação de integridade da CNI | Todas |
| UDP | Entrada | 6081 | Encapsulamento GENEVE | Só para mim |
| TCP | Entrada | 6444 | Servidor da API Kubernetes | Todas |
| TCP | Entrada | 9100 | Exibir métricas | node-exporter |
| TCP | Entrada | 9443 | Métricas de servidor/proxy para componentes do plano de controle. Esse requisito de porta é para a versão 1.16 e anteriores do cluster. | kube-control-plane-metrics-proxy |
| TCP | Entrada | 9977 | Receber um 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ó | Todas |
| TCP | Entrada | 14443 | Serviço de webhook do ANG | kube-apiserver e ang-controller-manager |
Nós de trabalho
Versão 1.29
| Protocolo | Direção | Intervalo de portas | Finalidade | Usada por |
|---|---|---|---|---|
| TCP | Entrada | 22 | Provisionamento e atualizações de nós de cluster de usuário | Nós do cluster de administrador |
| TCP | Ambos | 4240 | Verificação de integridade da CNI | Todas |
| UDP | Entrada | 6081 | Encapsulamento GENEVE | Só para mim |
| TCP | Entrada | 9100 | auth-proxy | node-exporter |
| TCP | Entrada | 9101 | Fornecer métricas de nó somente no localhost
(aplica-se à 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ó | Todas |
| TCP | Entrada | 30000 - 32767 | NodePort serviços |
Só para mim |
Versão 1.28
| Protocolo | Direção | Intervalo de portas | Finalidade | Usada por |
|---|---|---|---|---|
| TCP | Entrada | 22 | Provisionamento e atualizações de nós de cluster de usuário | Nós do cluster de administrador |
| TCP | Ambos | 4240 | Verificação de integridade da CNI | Todas |
| UDP | Entrada | 6081 | Encapsulamento GENEVE | Só para mim |
| TCP | Entrada | 9100 | auth-proxy | node-exporter |
| TCP | Entrada | 9101 | Fornecer métricas de nó somente no localhost
(aplica-se à 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ó | Todas |
| TCP | Entrada | 30000 - 32767 | NodePort serviços |
Só para mim |
Versão 1.16
| Protocolo | Direção | Intervalo de portas | Finalidade | Usada por |
|---|---|---|---|---|
| TCP | Entrada | 22 | Provisionamento e atualizações de nós de cluster de usuário | Nós do cluster de administrador |
| TCP | Ambos | 4240 | Verificação de integridade da CNI | Todas |
| UDP | Entrada | 6081 | Encapsulamento GENEVE | Só para mim |
| TCP | Entrada | 9100 | Exibir métricas | node-exporter |
| TCP | Entrada | 10250 | API kubelet |
Plano próprio e de controle |
| TCP | Entrada | 10256 | Verificação de integridade do nó | Todas |
| TCP | Entrada | 30000 - 32767 | NodePort serviços |
Só para mim |
Versão 1.15 e inferior
| Protocolo | Direção | Intervalo de portas | Finalidade | Usada por |
|---|---|---|---|---|
| TCP | Entrada | 22 | Provisionamento e atualizações de nós de cluster de usuário | Nós do cluster de administrador |
| TCP | Ambos | 4240 | Verificação de integridade da CNI | Todas |
| UDP | Entrada | 6081 | Encapsulamento GENEVE | Só para mim |
| TCP | Entrada | 9100 | Exibir métricas | node-exporter |
| TCP | Entrada | 10250 | API kubelet |
Plano próprio e de controle |
| TCP | Entrada | 10256 | Verificação de integridade do nó | Todas |
| TCP | Entrada | 30000 - 32767 | NodePort serviços |
Só para mim |
Nós do balanceador de carga
Versão 1.29
| Protocolo | Direção | Intervalo de portas | Finalidade | Usada por |
|---|---|---|---|---|
| TCP | Entrada | 22 | Provisionamento e atualizações de nós de cluster de usuário | Nós do cluster de administrador |
| TCP | Entrada | 443 | Gerenciamento de clusters Essa porta pode ser configurada no arquivo de configuração do cluster
com o campo |
Todas |
| TCP | Ambos | 4240 | Verificação de integridade da CNI | Todas |
| 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ó | Todas |
| TCP | Entrada | 11000 | Porta de detecção para métricas do HAProxy (imutável)
(aplica-se à versão 1.29 e mais recentes) |
Todas |
| TCP | Entrada | 11001 | Porta de escuta para o serviço de identidade do GKE (imutável)
(aplica-se à versão 1.29 e mais recentes) |
Todas |
Versão 1.28
| Protocolo | Direção | Intervalo de portas | Finalidade | Usada por |
|---|---|---|---|---|
| TCP | Entrada | 22 | Provisionamento e atualizações de nós de cluster de usuário | Nós do cluster de administrador |
| TCP | Entrada | 443 | Gerenciamento de clusters Essa porta pode ser configurada no arquivo de configuração do cluster
com o campo |
Todas |
| TCP | Ambos | 4240 | Verificação de integridade da CNI | Todas |
| 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 | 8443 | Porta de escuta para o serviço de identidade do GKE (imutável)
(aplicável apenas à versão 1.28) |
Todas |
| TCP | Entrada | 10256 | Verificação de integridade do nó | Todas |
Versão 1.16
| Protocolo | Direção | Intervalo de portas | Finalidade | Usada por |
|---|---|---|---|---|
| TCP | Entrada | 22 | Provisionamento e atualizações de nós de cluster de usuário | Nós do cluster de administrador |
| TCP | Entrada | 443 | Gerenciamento de clusters Essa porta pode ser configurada no arquivo de configuração do cluster
com o campo |
Todas |
| TCP | Ambos | 4240 | Verificação de integridade da CNI | Todas |
| 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ó | Todas |
Versão 1.15 e inferior
| Protocolo | Direção | Intervalo de portas | Finalidade | Usada por |
|---|---|---|---|---|
| TCP | Entrada | 22 | Provisionamento e atualizações de nós de cluster de usuário | Nós do cluster de administrador |
| TCP | Entrada | 443 | Gerenciamento de clusters Essa porta pode ser configurada no arquivo de configuração do cluster
com o campo |
Todas |
| TCP | Ambos | 4240 | Verificação de integridade da CNI | Todas |
| 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ó | Todas |
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 configurada na configuração do cluster usando o
campo |
Nós do plano de controle e do balanceador de carga |
Configurar portas de firewall
Não é necessário desativar o firewall para executar o Google Distributed Cloud no Red
Hat Enterprise Linux (RHEL). 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. 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=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 porta específicos da versão do cluster que você pretende usar, consulte a seção Uso da porta anterior. Atualize os comandos de exemplo conforme necessário.
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
Para ver os requisitos de porta específicos da versão do cluster que você pretende usar, consulte a seção Uso da porta anterior. Atualize os comandos de exemplo conforme necessário.
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
Para ver os requisitos de porta específicos da versão do cluster que você pretende usar, consulte a seção Uso da porta anterior. Atualize os comandos de exemplo conforme necessário.
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 extra para o RHEL 9.2 e 9.4
O Red Hat Enterprise Linux (RHEL) versão 9.2 e 9.4 tem suporte como GA nas versões 1.29.400 e mais recentes. Com as versões 9.2 e 9.4 do RHEL, é necessário realizar uma configuração de firewall adicional nos nós para que os serviços e pods funcionem corretamente:
Liste as interfaces ativas do nó para encontrar a interface do nó principal:
firewall-cmd --list-interfacesCom base nas convenções de nomenclatura para interfaces de máquina Linux, o nome da interface principal pode ser um dos seguintes:
eth0,eno1,ens1ouenp2s0.Liste as zonas do nó para encontrar qual zona a interface principal usa:
firewall-cmd --list-all-zonesPor exemplo, se a interface principal for
eno1, a seção a seguir da resposta indica que a interface principal está na zonapublic:... public (active) target: default icmp-block-inversion: no interfaces: eno1 sources: ...Execute os comandos de firewall a seguir para configurar detalhes de zona e política personalizados 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 --reloadSubstitua
IN_ZONEpor um dos seguintes valores, com base no que você encontrou nas etapas anteriores:public: zona predefinida para uso em áreas públicas, em que apenas conexões de entrada selecionadas são aceitas.trusted: zona predefinida em um ambiente controlado em que todas as conexões de rede são aceitas.- O nome de uma zona personalizada que você definiu.
Siga a documentação do fornecedor para configurar sua solução de armazenamento.
Por exemplo, se você estiver usando o Portworx para gerenciar cargas de trabalho com estado, os requisitos de rede do Portworx listam as portas que precisam permanecer abertas.
Para cada uma das portas listadas na documentação do fornecedor, execute o seguinte comando:
firewall-cmd --permanent --zone=public --add-port=PORT_INFOSubstitua
PORT_INFOpelo número de porta ou intervalo de números de porta seguido pelo protocolo. Por exemplo,10250-10252/tcp.
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:
Execute o seguinte comando do Network Mapper para ver quais portas estão abertas:
nmap localhostExecute os seguintes comandos para receber as configurações de firewall:
firewall-cmd --info-zone=public firewall-cmd --info-zone=k8s-pods firewall-cmd --list-all-policiesSe 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 do 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 do iptables do Cilium faz com que
o pod no nó perca a conectividade de rede fora do nó.
As alterações em firewalld que removerão as cadeias de iptables incluem, mas não estão limitadas a:
Reiniciando
firewalld, usandosystemctlComo atualizar o
firewalldcom o cliente da linha de comando (firewall-cmd --reload)
Para aplicar as mudanças de firewalld sem remover as cadeias de iptables, reinicie anetd
no nó:
Localize e exclua o pod
anetdcom os seguintes comandos para reiniciaranetd:kubectl get pods -n kube-system kubectl delete pods -n kube-system ANETD_XYZSubstitua ANETD_XYZ pelo nome do pod
anetd.