Como configurar a visibilidade intranós

Neste guia, veja como configurar a visibilidade intranós em um cluster do Google Kubernetes Engine (GKE).

A visibilidade intranós configura a rede em cada nó no cluster. Assim, o tráfego enviado de um pod para outro pode ser processado pela rede da nuvem privada virtual (VPC, na sigla em inglês) do cluster, mesmo que os pods estejam no mesmo nó.

A visibilidade intranós é desativada por padrão nos clusters Standard e ativada por padrão nos clusters do Autopilot.

Arquitetura

A visibilidade intranós garante que os pacotes enviados entre pods sejam sempre processados pela rede VPC, garantindo que as regras de firewall, as rotas, os registros de fluxo e as configurações de espelhamento de pacotes sejam aplicadas aos pacotes.

Quando um pod envia um pacote para outro pod no mesmo nó, o pacote é retirado do nó e processado pela rede do Google Cloud. Depois, o pacote é imediatamente enviado de volta ao mesmo nó e encaminhado ao pod de destino.

A visibilidade intranós implanta o DaemonSet netd.

Vantagens

A visibilidade intranós oferece os seguintes benefícios:

• consultar registros de fluxo de todo o tráfego entre pods, incluindo pods que estão no mesmo nó;
• criar regras de firewall que se apliquem a todo o tráfego entre os pods, inclusive pods no mesmo nó;
• usar o espelhamento de pacotes para clonar o tráfego, incluindo o tráfego entre pods no mesmo nó, e encaminhá-lo para análise.

Requisitos e limitações

A visibilidade intranós tem os seguintes requisitos e limitações:

• Seu cluster precisa estar na versão 1.15 ou mais recente do GKE.
• Observação: a visibilidade intranós não é compatível com os pools de nós do Windows Server.
• Se você ativar a visibilidade intranós e usar o ip-masq-agent configurado com o parâmetro nonMasqueradeCIDRs, inclua o intervalo CIDR do pod em nonMasqueradeCIDRs para evitar problemas de conectividade intranós.

Regras de firewall

Ao ativar a visibilidade intranós, a rede VPC processa todos os pacotes enviados entre pods, incluindo aqueles enviados entre pods no mesmo nó. Isso significa que as regras de firewall da VPC e as políticas hierárquicas de firewall se aplicam de maneira consistente à comunicação entre pods, independentemente da localização deles.

Se você configurar regras de firewall personalizadas para comunicação no cluster, avalie com cuidado as necessidades de rede do cluster para determinar o conjunto de regras de permissão de saída e entrada. Use testes de conectividade para garantir que o tráfego legítimo não seja bloqueado. Por exemplo, a comunicação entre pods é necessária para que a política de rede funcione.

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.

Ativar a visibilidade intranós em um novo cluster

Crie um cluster com visibilidade intranós ativada usando a gcloud CLI ou o Console do Google Cloud.

gcloud container clusters create CLUSTER_NAME \
    --region=COMPUTE_REGION \
    --enable-intra-node-visibility

Ativar a visibilidade intranós em um cluster atual

É possível ativar a visibilidade intranós em um cluster atual usando a gcloud CLI ou o Console do Google Cloud.

Quando você ativa a visibilidade intranós em um cluster atual, o GKE reinicia os componentes no plano de controle e nos nós de trabalho.

gcloud container clusters update CLUSTER_NAME \
    --enable-intra-node-visibility

Desativar a visibilidade intranós

É possível desativar a visibilidade intranós em um cluster usando a gcloud CLI ou o Console do Google Cloud.

Quando você desativa a visibilidade intranós em um cluster atual, o GKE reinicia os componentes no plano de controle e nos nós de trabalho.

gcloud container clusters update CLUSTER_NAME \
    --no-enable-intra-node-visibility

Exercício: verificar a visibilidade intranós

Este exercício mostra as etapas necessárias para ativar a visibilidade intranós e confirmar se ele está funcionando para o cluster.

Neste exercício, você realizará as seguintes etapas:

1. Ativar os registros de fluxo para a sub-rede padrão na região us-central1.
2. Crie um cluster de nó único com visibilidade intranós ativada na zona us-central1-a.
3. Criar dois pods no cluster.
4. Enviar uma solicitação HTTP de um pod para outro.
5. Ver a entrada do registro de fluxo da solicitação entre pods.

Ativar registros de fluxo

1. Ative os registros de fluxo para a sub-rede padrão:

   gcloud compute networks subnets update default \
       --region=us-central1 \
       --enable-flow-logs
   

2. Verifique se a sub-rede padrão tem os registros de fluxo ativados:

   gcloud compute networks subnets describe default \
       --region=us-central1
   

   A saída mostra que os registros de fluxo estão ativados, como no exemplo a seguir:

   ...
   enableFlowLogs: true
   ...
   

Criar um cluster

1. Criar um único cluster de nó com visibilidade intranós ativada:

   gcloud container clusters create flow-log-test \
       --zone=us-central1-a \
       --num-nodes=1 \
       --enable-intra-node-visibility
   

2. Veja as credenciais do cluster:

   gcloud container clusters get-credentials flow-log-test \
       --zone=us-central1-a
   

Criar dois pods

1. Crie um pod.

   Salve o seguinte manifesto em um arquivo chamado pod-1.yaml:

   apiVersion: v1
   kind: Pod
   metadata:
     name: pod-1
   spec:
     containers:
     - name: container-1
       image: google/cloud-sdk:slim
       command:
       - sh
       - -c
       - while true; do sleep 30; done
   

2. Aplique o manifesto ao cluster:

   kubectl apply -f pod-1.yaml
   

3. Crie um segundo pod.

   Salve o seguinte manifesto em um arquivo chamado pod-2.yaml:

   apiVersion: v1
   kind: Pod
   metadata:
     name: pod-2
   spec:
     containers:
     - name: container-2
       image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:2.0
   

4. Aplique o manifesto ao cluster:

   kubectl apply -f pod-2.yaml
   

5. Veja os pods:

   kubectl get pod pod-1 pod-2 --output wide
   

   A saída mostra os endereços IP dos pods, semelhantes aos seguintes:

   NAME      READY     STATUS    RESTARTS   AGE       IP           ...
   pod-1     1/1       Running   0          1d        10.52.0.13   ...
   pod-2     1/1       Running   0          1d        10.52.0.14   ...
   

   Anote os endereços IP de pod-1 e pod-2.

Enviar uma solicitação

1. Abra um shell para o contêiner em pod-1:

   kubectl exec -it pod-1 -- sh
   

2. No shell, envie uma solicitação para pod-2:

   curl -s POD_2_IP_ADDRESS:8080
   

   Substitua POD_2_IP_ADDRESS pelo endereço IP de pod-2.

   A saída mostra a resposta do contêiner em execução em pod-2.

   Hello, world!
   Version: 2.0.0
   Hostname: pod-2
   

3. Digite "exit" para sair do shell e retornar ao seu ambiente de linha de comando principal.

Visualizar entradas no registro de fluxo

Para visualizar uma entrada de registro de fluxo, use o seguinte comando:

gcloud logging read \
    'logName="projects/PROJECT_ID/logs/compute.googleapis.com%2Fvpc_flows" AND jsonPayload.connection.src_ip="POD_1_IP_ADDRESS" AND jsonPayload.connection.dest_ip="POD_2_IP_ADDRESS"'

Substitua:

• PROJECT_ID: o ID do projeto.
• POD_1_IP_ADDRESS: o endereço IP de pod-1.
• POD_2_IP_ADDRESS: o endereço IP de pod-2.

A saída mostra uma entrada de registro de fluxo para uma solicitação entre pod-1 e pod-2. Neste exemplo, pod-1 tem o endereço IP 10.56.0.13 e pod-2 tem o endereço IP 10.56.0.14.

...
jsonPayload:
  bytes_sent: '0'
  connection:
    dest_ip: 10.56.0.14
    dest_port: 8080
    protocol: 6
    src_ip: 10.56.0.13
    src_port: 35414
...

Limpar

Para evitar cobranças indesejadas na conta, execute as seguintes etapas para remover os recursos criados:

1. Exclua o cluster:

   gcloud container clusters delete -q flow-log-test
   

2. Desative os registros de fluxo para a sub-rede padrão:

   gcloud compute networks subnets update default --no-enable-flow-logs
   

A seguir

• Saiba como controlar a comunicação entre os pods e os Services do cluster ao criar uma política de rede do cluster.
• Saiba mais sobre os benefícios dos clusters nativos de VPC.