Como configurar a visibilidade intranós

Neste guia, mostramos como configurar a visibilidade intranós em um cluster do Google Kubernetes Engine (GKE) para que todo o tráfego de rede do seu cluster seja visto pela rede do Google Cloud.

A visibilidade intranós permite:

  • 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 entre os pods no mesmo nó e encaminhá-lo para a análise.

Quando um pacote é enviado de um pod para outro no mesmo nó, ele é 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 é desativada por padrão.

Ela é necessária se você quiser que o cluster use uma rede VPC em que a MTU seja de 1.500 bytes. Além disso, a versão do GKE do cluster precisa ser de 1.15 ou superior. Para mais informações sobre redes VPC com MTU de 1.500 bytes, consulte Unidade máxima de transmissão na documentação da VPC.

Considerações

Maior volume de registros

Quando a visibilidade intranós é ativada, o volume de registro de fluxo pode aumentar com mais tráfego sendo capturado pela VPC. Ajuste as definições de geração de registro para gerenciar os custos associados com a geração de registo de fluxo.

Todo o tráfego entre pods está sujeito a firewalls

Todo o tráfego entre pods, incluindo pods implantados no nó de nome, é visível para a VPC quando a visibilidade intranós é ativada. A ativação da visibilidade intranós pode fazer com que o tráfego anteriormente irrestrito fique sujeito a regras de firewall. Avalie seus firewalls no nível do nó usando os Testes de Conectividade para garantir que o tráfego legítimo não seja bloqueado.

Antes de começar

Antes de começar, verifique se você realizou as tarefas a seguir:

Defina as configurações padrão da gcloud usando um dos métodos a seguir:

  • Use gcloud init se quiser orientações para definir os padrões.
  • Use gcloud config para definir individualmente a região, a zona e o ID do projeto.

Como usar o gcloud init

Se você receber o erro One of [--zone, --region] must be supplied: Please specify location, conclua esta seção.

  1. Execute gcloud init e siga as instruções:

    gcloud init

    Se você estiver usando SSH em um servidor remoto, utilize a sinalização --console-only para impedir que o comando inicie um navegador:

    gcloud init --console-only
  2. Siga as instruções para autorizar a gcloud a usar sua conta do Google Cloud.
  3. Crie uma nova configuração ou selecione uma atual.
  4. Escolha um projeto do Google Cloud.
  5. Escolha uma zona padrão do Compute Engine para clusters zonais ou uma região para clusters regionais ou do Autopilot.

Como usar o gcloud config

  • Defina o ID do projeto padrão:
    gcloud config set project PROJECT_ID
  • Se você estiver trabalhando com clusters zonais, defina a zona do Compute padrão:
    gcloud config set compute/zone COMPUTE_ZONE
  • Se você estiver trabalhando com clusters do Autopilot ou regionais, defina a região do Compute padrão:
    gcloud config set compute/region COMPUTE_REGION
  • Atualize gcloud para a versão mais recente:
    gcloud components update

Visão geral das tarefas

Esta é uma visão geral das tarefas que você executa e que demonstra a configuração da visibilidade intranós:

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

Os exemplos neste guia usam:

  • us-central1 como a região padrão.
  • us-central1-a como a zona padrão.

Como ativar registros de fluxo de uma sub-rede

É possível ativar os registros de fluxo para uma sub-rede usando a ferramenta gcloud ou o Console do Google Cloud.

gcloud

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

    gcloud compute networks subnets update default --region us-central1 \
        --enable-flow-logs
    
  2. Verifique se a sub-rede tem 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:

    ...
    enableFlowLogs: true
    ...
    ipCidrRange: 10.128.0.0/20
    region: https://www.googleapis.com/compute/v1/projects/abc-712099/regions/us-central1
    

Console

  1. Acesse a página de redes VPC do Google Kubernetes Engine no Console do Cloud.

    Acessar a página de redes VPC

  2. Na linha us-central1, clique em padrão.

  3. Na página Detalhes da sub-rede, clique em Editar.

  4. Em Registros de fluxo, selecione Ativar.

  5. Clique em Salvar.

Como criar um cluster com visibilidade intranós ativada

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

gcloud

Crie um cluster de nó único com visibilidade intranós ativada:

gcloud container clusters create cluster-name \
    --zone us-central1-a \
    --num-nodes 1 \
    --enable-intra-node-visibility

Console

  1. Acesse o menu do Google Kubernetes Engine no Console do Cloud.

    Acesse o menu do Google Kubernetes Engine

  2. Clique em Criar.

  3. Insira o Nome do cluster.

  4. Em Tipo de local, selecione Por zona.

  5. Na lista suspensa Zona, selecione us-central1-a.

  6. No painel de navegação, em Pools de nós, clique em default-pool.

  7. Insira um Nome para o pool de nós.

  8. Para nós de versão estática, escolha a Versão do nó.

  9. Para o Número de nós, insira 1.

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

  11. Selecione a caixa de seleção Ativar visibilidade intranós.

  12. Clique em Criar.

Como receber credenciais para o cluster

Receba as credenciais do novo cluster:

gcloud container clusters get-credentials cluster-name \
    --zone us-central1-a

As credenciais são salvas no arquivo kubeconfig, que normalmente está em $HOME/.kube/config.

Como criar dois pods

  1. Para o primeiro pod, crie um arquivo chamado pod-1.yaml com base no exemplo de manifesto a seguir:

    apiVersion: v1
    kind: Pod
    metadata:
      name: pod-1
    spec:
      containers:
      - name: container-1
        image: gcr.io/google-samples/hello-app:2.0
    
  2. Crie o pod executando o seguinte comando:

    kubectl apply -f pod-1.yaml
    
  3. Para o segundo pod, crie um arquivo chamado pod-2.yaml com base no exemplo de manifesto a seguir:

    apiVersion: v1
    kind: Pod
    metadata:
      name: pod-2
    spec:
      containers:
      - name: container-2
        image: gcr.io/google-samples/node-hello:1.0
    
  4. Crie o pod executando o seguinte comando:

    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. Anote esses endereços.

    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   ...
    

Como enviar uma solicitação de pod-1 para pod-2

  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:

    wget -qO- pod-2-ip-address:8080
    

    em que pod-2-ip-address é o endereço IP de pod-2 que você anotou anteriormente.

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

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

Como ver as entradas do registro de fluxo

É possível ver as entradas de registro flog usando a ferramenta gcloud ou o Console do Google Cloud.

gcloud

Veja uma entrada de registro de fluxo para a solicitação de pod-1 para pod-2:

gcloud logging read \
    'logName="projects/project-id/logs/compute.googleapis.com%2Fvpc_flows" AND jsonPayload.connection.src_ip="pod-1-ip-address"'

em que:

  • project-id é o ID do projeto;
  • pod-1-ip-address é o endereço IP de pod-1.

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
...

Console

  1. Acesse a página de registros do Stackdriver do Google Kubernetes Engine no Console do Cloud.

    Acessar a página de registros do Stackdriver

  2. No campo de filtro, clique em e em Converter em filtro avançado.

  3. Substitua qualquer texto no campo de filtro pelo seguinte:

    resource.type="gce_subnetwork"
    logName="projects/project-id/logs/compute.googleapis.com%2Fvpc_flows"
    jsonPayload.connection.src_ip="pod-1-ip-address"
    

    Substitua:

    • project-id é o ID do projeto.
    • pod-1-ip-address é o endereço IP de pod-1.
  4. Expanda a entrada de registro exibida. Em jsonPayload é possível ver que a solicitação foi enviada de pod-1 a pod-2. No exemplo a seguir, o pod-1 tem um endereço IP 10.56.0.13 e o pod-2, 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
    

Lembre-se de que o cluster tem apenas um nó. Portanto, pod-1 e pod-2 estão no mesmo nó. Mesmo assim, as entradas do registro de fluxo estão disponíveis na comunicação intranós entre pod-1 e pod-2.

Como ativar a visibilidade intranós em um cluster atual

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

gcloud

gcloud beta container clusters update cluster-name \
    --enable-intra-node-visibility

em que cluster-name é o nome do cluster atual.

Console

  1. Acesse o menu do Google Kubernetes Engine no Console do Cloud.

    Acessar o menu do Google Kubernetes Engine

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

  3. Em Rede, ao lado do campo Visibilidade intranós, clique em Editar visibilidade intranós.

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

  5. Clique em Salvar alterações.

Quando você ativa a visibilidade intranós em um cluster atual, os componentes no painel de controle e nos nós de worker são reiniciados.

Depois de ativar esse recurso, confirme se ele está ativado examinando as regras de roteamento no seu nó:

  1. Mostre as regras de IP:

    ip rule show
    

    A saída será semelhante a esta:

    0:  from all lookup local
    30001:  from all fwmark 0x4000/0x4000 lookup main
    30002:  from all iif lo lookup main
    30003:  not from all iif eth0 lookup 1
    32766:  from all lookup main
    32767:  from all lookup default
    
  2. Mostre as rotas IP:

    ip route show table 1
    

    A saída será semelhante a esta:

    default via GKE-node-subnet-gw dev eth0
    

Como desativar a visibilidade intranós

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

gcloud

gcloud beta container clusters update cluster-name \
    --no-enable-intra-node-visibility

em que cluster-name é o nome do cluster atual.

Console

  1. Acesse a página do Google Kubernetes Engine no Console do Cloud.

    Acessar a página do Google Kubernetes Engine

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

  3. Em Rede, ao lado do campo Visibilidade intranós, clique em Editar visibilidade intranós.

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

  5. Clique em Salvar alterações.

Quando você desativa a visibilidade intranós em um cluster atual, os componentes no painel de controle e nos nós de worker são reiniciados.

Restrições

Os clusters com visibilidade intranós ativada têm as seguintes restrições:

  • Se você ativar a visibilidade intranós e usar ip-masq-agent configurado com o parâmetro nonMasqueradeCIDRs, o nonMasqueradeCIDRs precisará incluir o CIDR do pod. Caso contrário, você terá problemas de conectividade intranós.

A seguir