Nesta página, explicamos como controlar a comunicação entre os pods e os serviços do cluster usando a aplicação da política de rede do GKE.
Também é possível controlar o tráfego de saída dos pods para qualquer endpoint ou serviço fora do cluster usando políticas de rede de nome de domínio totalmente qualificado (FQDN, na sigla em inglês). Para mais informações, consulte Controlar a comunicação entre pods e serviços usando FQDNs.
Sobre a aplicação da política de rede do GKE
A aplicação da política de rede permite criar políticas de rede do Kubernetes no cluster. Por padrão, todos os pods em um cluster podem se comunicar livremente. As políticas de rede criam regras de firewall no nível do pod que determinam quais pods e serviços podem acessar um ao outro dentro do cluster.
Ao definir a política de rede, você ativa itens como defesa em profundidade quando o cluster estiver veiculando um aplicativo de vários níveis. Por exemplo, você pode criar uma política de rede para garantir que um serviço comprometido de front-end no aplicativo não possa se comunicar diretamente com um serviço de faturamento ou contabilidade vários níveis abaixo.
A política de rede também pode facilitar a hospedagem de dados de vários usuários simultaneamente por parte do seu aplicativo. Por exemplo, você pode fornecer multilocação segura definindo um modelo de inquilino por namespace. Nesse modelo, as regras de política de rede podem garantir que pods e serviços em um determinado namespace não acessem outros pods ou serviços em um namespace diferente.
Antes de começar
Antes de começar, verifique se você realizou as tarefas a seguir:
- Ativar a API Google Kubernetes Engine. Ativar a API Google Kubernetes Engine
- Se você quiser usar a Google Cloud CLI para essa tarefa,
instale e, em seguida,
inicialize a
CLI gcloud. Se você instalou a CLI gcloud anteriormente, instale a versão
mais recente executando
gcloud components update
.
Requisitos e limitações
Os requisitos e limitações a seguir se aplicam aos clusters do Autopilot e do Standard:- É preciso permitir a saída para o servidor de metadados.
- Se você especificar um campo
endPort
em uma política de rede em um cluster com o GKE Dataplane V2 ativado, ele poderá não entrar em vigor a partir da versão 1.22 do GKE. Para mais informações, consulte Os intervalos de portas da política de rede não entram em vigor. Nos clusters do Autopilot, o GKE Dataplane V2 está sempre ativado.
- É necessário permitir a saída para o servidor de metadados se você usar a política de rede com a federação de identidade da carga de trabalho para o GKE.
- Ativar a aplicação da política de rede aumenta o consumo de memória do
processo
kube-system
em aproximadamente 128 MB e requer aproximadamente 300 milicores de CPU. Isso significa que, se você ativar políticas de rede para um cluster atual, talvez seja necessário aumentar o tamanho do cluster para continuar executando as cargas de trabalho programadas. - A ativação da aplicação obrigatória da política de rede requer que os nós sejam recriados. Se o cluster tiver uma janela de manutenção ativa, os nós não serão recriados automaticamente até a próxima janela de manutenção. Se preferir, faça upgrade do cluster manualmente quando quiser.
- O tamanho mínimo recomendado do cluster para executar a aplicação da política de rede é
de três instâncias
e2-medium
. - A política de rede não é compatível com clusters com nós
f1-micro
oug1-small
porque os requisitos de recursos são muito altos.
Para mais informações sobre tipos de máquinas de nó e recursos alocáveis, consulte Arquitetura do cluster padrão - nós.
Ativar a aplicação da política de rede
A aplicação da política de rede é ativada por padrão para os clusters do Autopilot. Portanto, pule para Criar uma política de rede.
A aplicação da política de rede no GKE pode ser ativada usando a ferramenta gcloud, o Console do Google Cloud ou a API GKE.
A aplicação da política de rede é integrada ao GKE Dataplane V2. Não é necessário ativar a aplicação da política de rede nos clusters que usam o GKE Dataplane V2.
gcloud
-
In the Google Cloud console, activate Cloud Shell.
At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.
Para ativar a aplicação da política de rede ao criar um novo cluster, execute o comando a seguir:
gcloud container clusters create CLUSTER_NAME --enable-network-policy
Substitua
CLUSTER_NAME
pelo nome do novo cluster.Para ativar a aplicação da política de rede para um cluster existente, execute as tarefas a seguir:
Execute o comando a seguir para ativar o complemento:
gcloud container clusters update CLUSTER_NAME --update-addons=NetworkPolicy=ENABLED
Substitua
CLUSTER_NAME
pelo nome do cluster.Execute o comando a seguir para ativar a aplicação obrigatória da política de rede no cluster, que, por sua vez, recria os pools de nós do cluster com a aplicação da política de rede ativada:
gcloud container clusters update CLUSTER_NAME --enable-network-policy
Console
Para ativar a aplicação da política de rede ao criar um novo cluster:
Acesse a página Google Kubernetes Engine no Console do Google Cloud.
Clique em add_box Criar.
Na caixa de diálogo Criar cluster do GKE Standard, clique em Configurar.
Configure o cluster como preferir.
No painel de navegação, em Cluster, clique em Rede.
Marque a caixa de seleção Ativar política de rede.
Clique em Criar.
Para ativar a aplicação da política de rede para um cluster atual:
Acesse a página do Google Kubernetes Engine no Console do Google Cloud.
Na lista de clusters, clique no nome do cluster que você quer modificar.
Em Rede, no campo Política de rede, clique em edit Editar política de rede.
Marque a caixa de seleção Ativar a política de rede para mestre e clique em Salvar alterações.
Aguarde a aplicação das suas alterações e clique em edit Editar política de rede novamente.
Marque a caixa de seleção Ativar política de rede para nós.
Clique em Salvar alterações.
API
Para ativar a aplicação da política de rede, faça o seguinte:
Especifique o objeto
networkPolicy
dentro do objetocluster
fornecido para projects.zones.clusters.create ou projects.zones.clusters.update.O objeto
networkPolicy
requer um enum que especifique qual provedor de política de rede usar e um valor booleano que especifique se a política de rede será ativada. Se você ativar a política de rede, mas não definir o provedor, os comandoscreate
eupdate
retornarão um erro.
Desativar a aplicação da política de rede em um cluster padrão
Desative a aplicação da política de rede usando a gcloud CLI, o Console do Google Cloud ou a API GKE. Não é possível desativar a aplicação da política de rede em clusters do Autopilot ou clusters que usam o GKE Dataplane V2.
gcloud
-
In the Google Cloud console, activate Cloud Shell.
At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.
Para desativar a aplicação obrigatória da política de rede, execute as seguintes tarefas:
- Desative a aplicação obrigatória da política de rede no cluster:
gcloud container clusters update CLUSTER_NAME --no-enable-network-policy
Substitua
CLUSTER_NAME
pelo nome do cluster.Depois de executar o comando, o GKE recria os pools de nós do cluster com a aplicação obrigatória da política de rede desativada.
Verifique se todos os nós foram recriados:
kubectl get nodes -l projectcalico.org/ds-ready=true
Se a operação for bem-sucedida, a saída será semelhante a esta:
No resources found
Se a saída for semelhante a essa, será necessário aguardar o GKE terminar de atualizar os pools de nós:
NAME STATUS ROLES AGE VERSION gke-calico-cluster2-default-pool-bd997d68-pgqn Ready,SchedulingDisabled <none> 15m v1.22.10-gke.600 gke-calico-cluster2-np2-c4331149-2mmz Ready <none> 6m58s v1.22.10-gke.600
Quando você desativa a aplicação obrigatória da política de rede, o GKE talvez deixe de atualizar os nós imediatamente se o cluster tiver uma janela de manutenção ou exclusão configurada. Para ver mais informações, consulte Atualização lenta do cluster.
Após a recriação de todos os nós, desative o complemento:
gcloud container clusters update CLUSTER_NAME --update-addons=NetworkPolicy=DISABLED
Console
Para desativar a aplicação da política de rede em um cluster atual, faça o seguinte:
Acesse a página do Google Kubernetes Engine no Console do Google Cloud.
Na lista de clusters, clique no nome do cluster que você quer modificar.
Em Rede, no campo Política de rede, clique em edit Editar política de rede.
Desmarque a caixa de seleção Ativar política de rede para nós e clique em Salvar alterações.
Aguarde a aplicação das suas alterações e clique em edit Editar política de rede novamente.
Desmarque a caixa de seleção Ativar política de rede para mestre.
Clique em Salvar alterações.
API
Para desativar a aplicação da política de rede em um cluster atual, faça o seguinte:
Atualize o cluster para usar
networkPolicy.enabled: false
com a APIsetNetworkPolicy
.Verifique se todos os nós foram recriados usando a gcloud CLI:
kubectl get nodes -l projectcalico.org/ds-ready=true
Se a operação for bem-sucedida, a saída será semelhante a esta:
No resources found
Se a saída for semelhante a essa, será necessário aguardar o GKE terminar de atualizar os pools de nós:
NAME STATUS ROLES AGE VERSION gke-calico-cluster2-default-pool-bd997d68-pgqn Ready,SchedulingDisabled <none> 15m v1.22.10-gke.600 gke-calico-cluster2-np2-c4331149-2mmz Ready <none> 6m58s v1.22.10-gke.600
Quando você desativa a aplicação obrigatória da política de rede, o GKE talvez deixe de atualizar os nós imediatamente se o cluster tiver uma janela de manutenção ou exclusão configurada. Para ver mais informações, consulte Atualização lenta do cluster.
Atualize o cluster para usar
update.desiredAddonsConfig.NetworkPolicyConfig.disabled: true
com a APIupdateCluster
.
Criar uma política de rede
É possível criar uma política de rede usando a API Kubernetes Network Policy.
Para mais detalhes sobre como criar uma política de rede, consulte os tópicos a seguir na documentação do Kubernetes:
Política de rede e federação de identidade da carga de trabalho para o GKE
Se você usar a política de rede com a federação de identidade da carga de trabalho, precisará permitir a saída para os seguintes endereços IP para que seus pods possam se comunicar com o servidor de metadados do GKE.
- Para
clusters que executam o GKE versão 1.21.0-gke.1000 e posterior, permita
a saída para
169.254.169.252/32
na porta988
. - Para clusters que executam versões anteriores ao GKE 1.21.0-gke.1000, permita a saída para
127.0.0.1/32
na porta988
. - Para clusters que executam o GKE Dataplane V2, permita a saída para
169.254.169.254/32
na porta80
.
Se você não permitir a saída para esses endereços IP e portas, poderá enfrentar interrupções durante os upgrades automáticos.
Como migrar do Calico para o GKE Dataplane V2
Se você migrar as políticas de rede do Calico para o GKE Dataplane V2, considere as seguintes limitações:
Não é possível usar um endereço IP de pod ou de serviço no campo
ipBlock.cidr
de um manifestoNetworkPolicy
. Você precisa referenciar cargas de trabalho usando rótulos. Por exemplo, a seguinte configuração é inválida:- ipBlock: cidr: 10.8.0.6/32
Não é possível especificar um campo
ports.port
vazio em um manifestoNetworkPolicy
. Se você especificar um protocolo, também precisará especificar uma porta. Por exemplo, a seguinte configuração é inválida:ingress: - ports: - protocol: TCP
Como trabalhar com balanceadores de carga de aplicativo
Quando uma entrada é aplicada a um serviço para criar um balanceador de carga de aplicativo, você precisa configurar a política de rede aplicada aos pods atrás desse serviço para permitir os intervalos de IP apropriados da verificação de integridade do balanceador de carga de aplicativo. Se você estiver usando um balanceador de carga de aplicativo interno, também precisará configurar a política de rede para permitir a sub-rede somente proxy.
Se você não estiver usando o balanceamento de carga nativo de contêiner com grupos de endpoints
da rede, as portas de um serviço podem encaminhar conexões para pods
em outros nós, a menos que sejam impedidas de fazê-lo, definindo a configuração
externalTrafficPolicy
como Local
na definição do Serviço. Se externalTrafficPolicy
não estiver definido como Local
, a política de rede
também deverá permitir conexões de outros IPs de nó no cluster.
Inclusão de intervalos de IP do pod nas regras ipBlock
Para controlar o tráfego de pods específicos, sempre selecione pods por namespace ou identificadores usando os campos namespaceSelector
e podSelector
nas regras de entrada ou saída do NetworkPolicy. Não use o campo ipBlock.cidr
para selecionar intencionalmente intervalos de endereços IP do pod, que são temporários por natureza.
O projeto do Kubernetes não define explicitamente o comportamento do campo ipBlock.cidr
quando ele inclui intervalos de endereços IP do pod. Especificar intervalos amplos de CIDR nesse campo, como 0.0.0.0/0
(que inclui os intervalos de endereços IP do pod), pode ter resultados inesperados em diferentes implementações da NetworkPolicy.
Comportamento do ipBlock no GKE Dataplane V2
Com a implementação do NetworkPolicy do GKE Dataplane V2, o tráfego de pods nunca é coberto por uma regra ipBlock
. Portanto, mesmo que você defina uma regra ampla, como
cidr: '0.0.0.0/0'
, ela não incluirá o tráfego de pods. Isso é útil porque permite, por exemplo, permitir que pods em um namespace recebam tráfego da Internet, sem também permitir o tráfego dos pods. Para
incluir também o tráfego de pods, selecione os pods explicitamente usando um seletor extra de pod ou namespace
nas definições de regra de entrada ou saída da NetworkPolicy.
Comportamento do ipBlock no Calico
Para a implementação da NetworkPolicy no Calico, as regras ipBlock
cobrem o tráfego de pods. Com essa implementação, para configurar um intervalo CIDR amplo
sem permitir o tráfego do pod, exclua explicitamente o intervalo CIDR do pod do cluster,
como no exemplo a seguir:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-non-pod-traffic
spec:
ingress:
- from:
- ipBlock:
cidr: '0.0.0.0/0'
except: ['POD_IP_RANGE']
Neste exemplo, POD_IP_RANGE
é o intervalo de endereços IPv4 do
pod do cluster, por exemplo, 10.95.0.0/17
. Se você tiver vários intervalos de IP, eles poderão ser incluídos individualmente na matriz, por exemplo, ['10.95.0.0/17', '10.108.128.0/17']
.
Solução de problemas
Os pods não conseguem se comunicar com o plano de controle em clusters que usam o Private Service Connect
Os pods em clusters do GKE que usam o Private Service Connect podem ter problemas de comunicação com o plano de controle caso a saída do pod para o endereço IP interno do plano de controle esteja restrita nas políticas de rede de saída.
Para minimizar esse problema, confira essas informações:
Descubra se o cluster usa o Private Service Connect. Para mais informações, consulte Clusters públicos com o Private Service Connect. Nos clusters que usam o Private Service Connect, cada plano de controle é atribuído a um endereço IP interno da sub-rede do nó do cluster.
Configure a política de saída do cluster para permitir o tráfego para o endereço IP interno do plano de controle.
Para encontrar o endereço IP interno do plano de controle, faça o seguinte:
gcloud
Para procurar por
privateEndpoint
, execute o seguinte comando:gcloud container clusters describe CLUSTER_NAME
Substitua
CLUSTER_NAME
pelo nome do cluster.Esse comando recupera o
privateEndpoint
do cluster especificado.Console
Acesse a página Google Kubernetes Engine no console do Google Cloud.
No painel de navegação, em Clusters, clique no cluster que tem o endereço IP interno que você quer encontrar.
Em Noções básicas sobre o cluster, acesse
Internal endpoint
para conferir uma lista com o endereço IP interno.
Depois de localizar
privateEndpoint
ouInternal endpoint
, configure a política de saída do cluster a fim de permitir o tráfego para o endereço IP interno do plano de controle. Para saber mais, consulte Criar uma política de rede.
Atualização lenta do cluster
Quando você ativa ou desativa a aplicação obrigatória da política de rede em um cluster atual, o GKE talvez deixe de atualizar os nós imediatamente se o cluster tiver uma janela de manutenção ou exclusão configurada.
É possível fazer upgrade manual de um pool de nós definindo a sinalização--cluster-version
para a mesma versão do GKE em que o plano de controle está em execução. Use
a Google Cloud CLI para realizar essa operação. Para mais informações, consulte avisos sobre janelas de manutenção.
Pods implantados manualmente não programados
Quando você ativa a aplicação da política de rede no plano de controle do cluster existente, o GKE cancela a programação de qualquer pod de nó ip-masquerade-agent ou de calico que você implantou manualmente.
O GKE não reprograma esses pods até que a aplicação da política de rede esteja ativada nos nós do cluster e os nós sejam recriados.
Se você configurou uma janela ou exclusão de manutenção, isso pode causar uma interrupção estendida.
Para minimizar a duração dessa interrupção, é possível atribuir manualmente os seguintes rótulos aos nós do cluster:
node.kubernetes.io/masq-agent-ds-ready=true
projectcalico.org/ds-ready=true
A política de rede não está em vigor
Se uma NetworkPolicy não entrar em vigor, você poderá resolver os problemas seguindo estas etapas:
Confirme se a aplicação da política de rede está ativada. O comando a ser usado depende se o cluster tiver o GKE Dataplane V2 ativado.
Se o cluster estiver com o GKE Dataplane V2 ativado, execute o seguinte comando:
kubectl -n kube-system get pods -l k8s-app=cilium
Se a saída estiver vazia, a aplicação da política de rede não estará ativada.
Se o cluster do GKE Dataplane V2 não estiver ativado no cluster, execute o seguinte comando:
kubectl get nodes -l projectcalico.org/ds-ready=true
Se a saída estiver vazia, a aplicação da política de rede não estará ativada.
Verifique os rótulos do pod:
kubectl describe pod POD_NAME
Substitua
POD_NAME
pelo nome do pod.O resultado será assim:
Labels: app=store pod-template-hash=64d9d4f554 version=v1
Confirme se os identificadores da política correspondem aos identificadores do pod:
kubectl describe networkpolicy
O resultado será assim:
PodSelector: app=store
Nesta saída, os rótulos
app=store
correspondem aos rótulosapp=store
da etapa anterior.Verifique se há políticas de rede que selecionem suas cargas de trabalho:
kubectl get networkpolicy
Se a saída estiver vazia, nenhuma NetworkPolicy foi criada no namespace e nenhuma está selecionando suas cargas de trabalho. Se a saída não estiver vazia, verifique se a política seleciona as cargas de trabalho:
kubectl describe networkpolicy
O resultado será assim:
... PodSelector: app=nginx Allowing ingress traffic: To Port: <any> (traffic allowed to all ports) From: PodSelector: app=store Not affecting egress traffic Policy Types: Ingress
Problemas conhecidos
Encerramento de pod do StatefulSet com o Calico
Os clusters do GKE
com a política de rede da
Calico ativada podem ter um problema em que um pod do StatefulSet descarta conexões
atuais quando o pod é excluído. Depois que um pod entra no estado Terminating
,
a configuração terminationGracePeriodSeconds
na especificação do pod não é respeitada
e causa interrupções em outros aplicativos que têm uma conexão atual
com o pod do StatefulSet. Saiba mais sobre esse problema no
problema nº 4710 do Calico.
Esse problema afeta as seguintes versões do GKE:
- 1.18
- 1.19 a 1.19.16-gke.99
- 1.20 a 1.20.11-gke.1299
- 1.21 a 1.21.4-gke.1499
Para atenuar esse problema, faça upgrade do plano de controle do GKE para uma das seguintes versões:
- 1.19.16-gke.100 ou mais recente
- 1.20.11-gke.1300 ou mais recente
- 1.21.4-gke.1500 ou mais recente
Pod travado no estado containerCreating
Pode haver um cenário em que os clusters do GKE com a política de rede Calico ativada possam enfrentar um problema em que os pods ficam presos no estado containerCreating
.
Na guia Eventos do pod, você encontrará uma mensagem semelhante à seguinte:
plugin type="calico" failed (add): ipAddrs is not compatible with
configured IPAM: host-local
Para atenuar esse problema, use o ipam host local para Calico em vez de calico-ipam em clusters do GKE.