Configurar a visibilidade intranodal

Autopilot Padrão

Este guia mostra como configurar a visibilidade intranó num cluster do Google Kubernetes Engine (GKE).

A configuração de visibilidade intranodal configura a rede em cada nó no cluster para que o tráfego enviado de um pod para outro pod seja processado pela rede de nuvem privada virtual (VPC) do cluster, mesmo que os pods estejam no mesmo nó.

A visibilidade intranodal está desativada por predefinição nos clusters padrão e ativada por predefinição nos clusters do Autopilot.

Arquitetura

A visibilidade intranodal garante que os pacotes enviados entre pods são sempre processados pela rede VPC, o que garante que as regras de firewall, as rotas, os registos de fluxo e as configurações de espelhamento de pacotes se aplicam aos pacotes.

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

A visibilidade intranó implementa o DaemonSet netd.

Vantagens

A visibilidade intranó oferece as seguintes vantagens:

• Veja registos de fluxo para todo o tráfego entre pods, incluindo o tráfego entre pods no mesmo nó.
• Crie regras de firewall que se apliquem a todo o tráfego entre Pods, incluindo o tráfego entre Pods no mesmo nó.
• Use a duplicação de pacotes para clonar o tráfego, incluindo o tráfego entre pods no mesmo nó, e encaminhá-lo para exame.

Requisitos e limitações

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

• O cluster tem de ter a versão 1.15 ou posterior do GKE.
• A visibilidade intranodal não é suportada com pools de nós do Windows Server.
• Para evitar problemas de conetividade, quando usar a flag ip-masq-agent com visibilidade intranode, a sua lista personalizada nonMasqueradeCIDRs tem de incluir os intervalos de endereços IP de nós e pods do cluster.

Regras de firewall

Quando ativa a visibilidade intranodal, a rede VPC processa todos os pacotes enviados entre Pods, incluindo pacotes enviados entre Pods no mesmo nó. Isto significa que as regras de firewall da VPC e as políticas de firewall hierárquicas aplicam-se de forma consistente à comunicação de pod para pod, independentemente da localização do pod.

Se configurar regras de firewall personalizadas para a comunicação no cluster, avalie cuidadosamente as necessidades de rede do cluster para determinar o conjunto de regras de permissão de saída e entrada. Pode usar testes de conetividade para garantir que o tráfego legítimo não é obstruído. Por exemplo, a comunicação de pod para pod é necessária para o funcionamento da política de rede.

Antes de começar

Antes de começar, certifique-se de que realizou as seguintes tarefas:

• Ative a API Google Kubernetes Engine.
Ative a API Google Kubernetes Engine
• Se quiser usar a CLI gcloud para esta tarefa, instale-a e, em seguida, inicialize-a. Se instalou anteriormente a CLI gcloud, execute o comando gcloud components update para obter a versão mais recente. As versões anteriores da CLI gcloud podem não suportar a execução dos comandos neste documento.
  Nota: para instalações existentes da CLI gcloud, certifique-se de que define a compute/region propriedade. Se usar principalmente clusters zonais, defina o compute/zone. Ao definir uma localização predefinida, pode evitar erros na CLI gcloud, como os seguintes: One of [--zone, --region] must be supplied: Please specify location. Pode ter de especificar a localização em determinados comandos se a localização do seu cluster for diferente da predefinição que definiu.

Ative a visibilidade intranó em um novo cluster

Pode criar um cluster com a visibilidade intranodal ativada através da CLI gcloud ou da Google Cloud consola.

gcloud

Para criar um cluster de nó único com visibilidade intranodal ativada, use a flag --enable-intra-node-visibility:

gcloud container clusters create CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --enable-intra-node-visibility

Substitua o seguinte:

• CLUSTER_NAME: o nome do novo cluster.
• CONTROL_PLANE_LOCATION: a localização do Compute Engine do plano de controlo do seu cluster. Indique uma região para clusters regionais ou uma zona para clusters zonais.

Consola

Para criar um cluster de nó único com visibilidade intranodal ativada, siga estes passos:

1. Aceda à página do Google Kubernetes Engine na Google Cloud consola.

   Aceda ao Google Kubernetes Engine

2. Clique em Criar.

3. Introduza o Nome do cluster.

4. Na caixa de diálogo Configurar cluster, junto a GKE Standard, clique em Configurar.

5. Configure o cluster conforme necessário.

6. No painel de navegação, em Cluster, clique em Rede.

7. Selecione a caixa de verificação Ativar visibilidade intranó.

8. Clique em Criar.

Ative a visibilidade intranós num cluster existente

Pode ativar a visibilidade intranós num cluster existente através da CLI gcloud ou da consola Google Cloud .

Quando ativa a visibilidade intranodal para um cluster existente, o GKE reinicia os componentes no plano de controlo e nos nós de trabalho.

gcloud

Para ativar a visibilidade intranodal num cluster existente, use a flag --enable-intra-node-visibility:

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

Substitua CLUSTER_NAME pelo nome do seu cluster.

Consola

Para ativar a visibilidade intranós num cluster existente, siga os seguintes passos:

1. Aceda à página do Google Kubernetes Engine na Google Cloud consola.

   Aceda ao Google Kubernetes Engine

2. Na lista de clusters, clique no nome do cluster que quer modificar.

3. Em Rede, clique em Editar visibilidade intranó.

4. Selecione a caixa de verificação Ativar visibilidade intranó.

5. Clique em Guardar alterações.

Esta alteração requer a recriação dos nós, o que pode causar interrupções nas suas cargas de trabalho em execução. Para ver detalhes acerca desta alteração específica, encontre a linha correspondente na tabela alterações manuais que recriam os nós através de uma estratégia de atualização de nós e respeitam as políticas de manutenção. Para saber mais sobre as atualizações de nós, consulte o artigo Planeamento de interrupções de atualizações de nós.

Importante: o GKE respeita as políticas de manutenção quando recria os nós para esta alteração através da estratégia de atualização de nós e depende da disponibilidade de recursos. A desativação das atualizações automáticas dos nós não impede esta alteração. Para aplicar manualmente as alterações aos nós, use a CLI gcloud para chamar o comando gcloud container clusters upgrade, transmitindo a flag --cluster-version com a mesma versão do GKE que o conjunto de nós já está a executar.

Desative a visibilidade intranó

Pode desativar a visibilidade intranós num cluster através da CLI gcloud ou da consola Google Cloud .

Quando desativa a visibilidade intranodal para um cluster existente, o GKE reinicia os componentes no plano de controlo e nos nós de trabalho.

gcloud

Para desativar a visibilidade intranodal, use a flag --no-enable-intra-node-visibility:

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

Substitua CLUSTER_NAME pelo nome do seu cluster.

Consola

Para desativar a visibilidade intranó, siga estes passos:

1. Aceda à página do Google Kubernetes Engine na Google Cloud consola.

   Aceda ao Google Kubernetes Engine

2. Na lista de clusters, clique no nome do cluster que quer modificar.

3. Em Rede, clique em Editar visibilidade intranodal.

4. Desmarque a caixa de verificação Ativar visibilidade intranós.

5. Clique em Guardar alterações.

Esta alteração requer a recriação dos nós, o que pode causar interrupções nas suas cargas de trabalho em execução. Para ver detalhes acerca desta alteração específica, encontre a linha correspondente na tabela alterações manuais que recriam os nós através de uma estratégia de atualização de nós e respeitam as políticas de manutenção. Para saber mais sobre as atualizações de nós, consulte o artigo Planeamento de interrupções de atualizações de nós.

Importante: o GKE respeita as políticas de manutenção quando recria os nós para esta alteração através da estratégia de atualização de nós e depende da disponibilidade de recursos. A desativação das atualizações automáticas dos nós não impede esta alteração. Para aplicar manualmente as alterações aos nós, use a CLI gcloud para chamar o comando gcloud container clusters upgrade, transmitindo a flag --cluster-version com a mesma versão do GKE que o conjunto de nós já está a executar.

Exercício: valide a visibilidade intranó

Este exercício mostra os passos necessários para ativar a visibilidade intranodal e confirmar que está a funcionar para o seu cluster.

Neste exercício, vai realizar os seguintes passos:

1. Ative os registos de fluxo para a sub-rede predefinida na região us-central1.
2. Crie um cluster de nó único com a visibilidade intranodal ativada na zona us-central1-a.
3. Crie dois pods no seu cluster.
4. Envie um pedido HTTP de um pod para outro pod.
5. Veja a entrada do registo de fluxo para o pedido de pod a pod.

Ative os registos de fluxo

1. Ative os registos de fluxo para a sub-rede predefinida:

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

2. Verifique se a sub-rede predefinida tem registos de fluxo ativados:

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

   O resultado mostra que os registos de fluxo estão ativados, semelhante ao seguinte:

   ...
   enableFlowLogs: true
   ...
   

Crie um cluster

1. Crie um cluster de nó único com a visibilidade intranodal ativada:

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

2. Obtenha as credenciais do seu cluster:

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

Crie dois Pods

1. Crie um grupo.

   Guarde o seguinte manifesto num ficheiro com o nome 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.

   Guarde o seguinte manifesto num ficheiro com o nome 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 agrupamentos:

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

   A saída mostra os endereços IP dos seus 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   ...
   

   Tome nota dos endereços IP de pod-1 e pod-2.

Envie uma solicitação

1. Obtenha um shell para o contentor em pod-1:

   kubectl exec -it pod-1 -- sh
   

2. Na shell, envie um pedido 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 contentor em execução em pod-2.

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

3. Escreva exit para sair da shell e regressar ao ambiente de linha de comandos principal.

Veja entradas do registo de fluxo

Para ver uma entrada do registo 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 o seguinte:

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

O resultado mostra uma entrada do registo de fluxo para um pedido de pod-1 para 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 incorrer em cobranças indesejadas na sua conta, siga os passos abaixo para remover os recursos que criou:

1. Elimine o cluster:

   gcloud container clusters delete -q flow-log-test
   

2. Desative os registos de fluxo para a sub-rede predefinida:

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

O que se segue?

• Saiba como controlar a comunicação entre os pods e os serviços do cluster criando uma política de rede do cluster.
• Saiba mais sobre as vantagens dos clusters nativos da VPC.