Nesta página, você verá como ativar o GKE Dataplane V2 para clusters do Google Kubernetes Engine (GKE).
Os novos clusters do Autopilot têm o GKE Dataplane V2 ativado nas versões 1.22.7-gke.1500 e posteriores e nas versões 1.23.4-gke.1500 e posteriores. Se você tiver problemas ao usar o GKE Dataplane V2, pule para a Solução de problemas.
Como criar um cluster do GKE com o GKE Dataplane V2
É possível ativar o GKE Dataplane V2 ao criar novos clusters com a versão 1.20.6-gke.700 e mais recentes do GKE e usando a gcloud CLI ou a API Kubernetes Engine. Também é possível ativar o GKE Dataplane V2 em Visualização ao criar novos clusters com a versão 1.17.9 e mais recentes do GKE
Console
Para criar um novo cluster com o GKE Dataplane V2, realize as seguintes tarefas:
Acesse a página Google Kubernetes Engine no console do Google Cloud.
Clique em add_box Criar.
Clique em Configurar para configurar um cluster padrão.
Na seção "Rede", marque a caixa de seleção Ativar DataPlane V2. A opção Ativar política de rede do Kubernetes é desativada quando você seleciona Ativar GKE Dataplane V2, porque a aplicação da política de rede é integrada ao Dataplane V2.
Clique em Criar.
gcloud
Para criar um novo cluster com o GKE Dataplane v2, use o seguinte comando:
gcloud container clusters create CLUSTER_NAME \
--enable-dataplane-v2 \
--enable-ip-alias \
--release-channel CHANNEL_NAME \
--location COMPUTE_LOCATION
Substitua:
CLUSTER_NAME: o nome do novo cluster;CHANNEL_NAME: um canal de lançamento que inclui a versão 1.20.6-gke.700 ou posterior do GKE. Se você preferir não usar um canal de lançamento, use a sinalização--cluster-versionem vez de--release-channel, especificando a versão 1.20.6-gke.700 ou posterior.COMPUTE_LOCATION: o local do Compute Engine para o novo cluster.
API
Para criar um novo cluster com o GKE Dataplane V2, especifique o
campo datapathProvider no
objeto networkConfig
em sua solicitação
create do cluster.
No seguinte snippet JSON, mostramos a configuração necessária para ativar o GKE Dataplane V2:
"cluster":{
"initialClusterVersion":"VERSION",
"ipAllocationPolicy":{
"useIpAliases":true
},
"networkConfig":{
"datapathProvider":"ADVANCED_DATAPATH"
},
"releaseChannel":{
"channel":"CHANNEL_NAME"
}
}
Substitua:
- VERSION: a versão do cluster, que precisa ser GKE 1.20.6-gke.700 ou posterior.
- CHANNEL_NAME: um canal de lançamento que inclui a versão 1.20.6-gke.700 ou posterior do GKE.
Solução de problemas com o GKE Dataplane V2
Nesta seção, mostramos como investigar e resolver problemas com o GKE Dataplane V2.
Confirme se o GKE Dataplane V2 está ativado:
kubectl -n kube-system get pods -l k8s-app=cilium -o wideSe o GKE Dataplane V2 estiver em execução, a saída incluirá pods com o prefixo
anetd-. O anetd é o controlador de rede do GKE Dataplane V2.Se o problema for com a aplicação da política de serviços ou rede, verifique os registros do pod
anetd: Use os seguintes seletores de registros no Cloud Logging:resource.type="k8s_container" labels."k8s-pod/k8s-app"="cilium" resource.labels.cluster_name="CLUSTER_NAME"Se a criação do pod falhar, verifique as dicas nos registros do kubelet. Use os seguintes seletores de registros no Cloud Logging:
resource.type="k8s_node" log_name=~".*/logs/kubelet" resource.labels.cluster_name="CLUSTER_NAME"Substitua
CLUSTER_NAMEpelo nome do cluster ou remova-o completamente para visualizar os registros de todos os clusters.
Problemas conhecidos
Os intervalos de porta da política de rede não têm efeito
Se você especificar um campo endPort em uma política de rede em um cluster com o
GKE Dataplane V2 ativado, ele não terá efeito.
A partir do GKE 1.22, a API Kubernetes Network Policy permite especificar um intervalo de portas em que a política de rede é aplicada. Essa API é compatível com clusters com a Política de rede do Calico, mas não com clusters que têm o GKE Dataplane V2.
Para verificar o comportamento dos objetos NetworkPolicy, leia-os
depois de serem gravados no servidor da API. Se o objeto ainda contiver o campo
endPort, o recurso será aplicado. Se o campo endPort estiver
ausente, o recurso não será aplicado. Em todos os casos, o objeto armazenado no
servidor de API é a fonte da verdade da política de rede.
Saiba mais em KEP-2079: política de rede compatível com intervalos de portas.
Os pods exibem a mensagem de erro failed to allocate for range 0: no IP addresses available in range set
Versões afetadas do GKE: de 1.22 a 1.25
Os clusters do GKE que executam pools de nós que usam containerd e têm o GKE Dataplane V2 ativado podem ter problemas de vazamento de endereço IP e esgotar todos os endereços de IP do pod em um nó. Um pod programado em um nó afetado exibe uma mensagem de erro semelhante a esta:
failed to allocate for range 0: no IP addresses available in range set: 10.48.131.1-10.48.131.62
Saiba mais consultando o problema 5768 do containerd.
Versões corrigidas
Para corrigir esse problema, faça upgrade do cluster para uma das seguintes versões do GKE:
- 1.22.17-gke.3100 ou mais recente.
- 1.23.16-gke.200 ou mais recente.
- 1.24.9-gke.3200 ou mais recente.
- 1.25.6-gke.200 ou mais recentes.
Soluções alternativas para clusters padrão do GKE
Para atenuar esse problema, exclua os endereços IP do pod com vazamentos no nó.
Para excluir os endereços IP do pod com vazamento, consiga credenciais de autenticação para o cluster e execute as etapas a seguir para limpar um único nó, se você souber o nome dele.
Salve o seguinte script de shell em um arquivo chamado
cleanup.sh:for hash in $(sudo find /var/lib/cni/networks/gke-pod-network -iregex '/var/lib/cni/networks/gke-pod-network/[0-9].*' -exec head -n1 {} \;); do hash="${hash%%[[:space:]]}"; if [ -z $(sudo ctr -n k8s.io c ls | grep $hash | awk '{print $1}') ]; then sudo grep -ilr $hash /var/lib/cni/networks/gke-pod-network; fi; done | sudo xargs -r rmExecute o script em um nó do cluster:
gcloud compute ssh --zone "ZONE" --project "PROJECT" NODE_NAME --command "$(cat cleanup.sh)"Substitua
NODE_NAMEpelo nome do nó.
Também é possível executar uma versão do DaemonSet desse script para execução paralela em todos os nós de uma só vez:
Salve o seguinte manifesto em um arquivo chamado
cleanup-ips.yaml:apiVersion: apps/v1 kind: DaemonSet metadata: name: cleanup-ipam-dir namespace: kube-system spec: selector: matchLabels: name: cleanup-ipam template: metadata: labels: name: cleanup-ipam spec: hostNetwork: true securityContext: runAsUser: 0 runAsGroup: 0 containers: - name: cleanup-ipam image: gcr.io/gke-networking-test-images/ubuntu-test:2022 command: - /bin/bash - -c - | while true; do for hash in $(find /hostipam -iregex '/hostipam/[0-9].*' -mmin +10 -exec head -n1 {} \; ); do hash="${hash%%[[:space:]]}" if [ -z $(ctr -n k8s.io c ls | grep $hash | awk '{print $1}') ]; then grep -ilr $hash /hostipam fi done | xargs -r rm echo "Done cleaning up /var/lib/cni/networks/gke-pod-network at $(date)" sleep 120s done volumeMounts: - name: host-ipam mountPath: /hostipam - name: host-ctr mountPath: /run/containerd volumes: - name: host-ipam hostPath: path: /var/lib/cni/networks/gke-pod-network - name: host-ctr hostPath: path: /run/containerdExecute o daemonset no cluster:
kubectl apply -f cleanup-ips.yamlVocê precisa ter acesso ao kubectl como administrador do cluster para executar este comando.
Verifique os registros do DaemonSet em execução:
kubectl -n kube-system logs -l name=cleanup-ipam
A política de rede descarta uma conexão devido à pesquisa incorreta de acompanhamento de conexão
Quando um pod cliente se conecta a si mesmo por meio de um serviço ou endereço IP virtual de um balanceador de carga de rede de passagem interno, o pacote de resposta não é identificado como parte de uma conexão devido a uma pesquisa de conntrack incorreta no plano de dados. Isso significa que uma política de rede que restringe o tráfego de entrada do pod é aplicada incorretamente no pacote.
O impacto desse problema depende do número de pods configurados para o serviço. Por exemplo, se o serviço tiver um pod de back-end, a conexão sempre falhará. Se o serviço tiver dois pods de back-end, a conexão falhará 50% do tempo.
Versões corrigidas
Para corrigir esse problema, faça upgrade do cluster para uma das seguintes versões do GKE:
- 1.28.3-gke.1090000 ou mais recente.
Alternativas
É possível atenuar esse problema configurando port e containerPort
no manifesto do serviço com o mesmo valor.
Quedas de pacotes para fluxos de conexão com alça de cabelo
Quando um pod cria uma conexão TCP com ele mesmo, de modo que o pod é a origem e o destino da conexão, o rastreamento de conexão eBPF do GKE Dataplane V2 rastreia incorretamente os estados de conexão, levando a um vazamento{101 }conntrack entradas.
Quando uma tupla de conexão (protocolo, IP de origem/destino e porta de origem/destino) vaza, novas conexões que usam a mesma tupla de conexão podem resultar no descarte de pacotes de retorno.
Versões corrigidas
Para corrigir esse problema, faça upgrade do cluster para uma das seguintes versões do GKE:
- 1.28.3-gke.1090000 ou mais recente
- 1.27.11-gke.1097000 ou mais recente
Alternativas
Use uma das seguintes soluções alternativas:
Ative a reutilização de TCP (sinal de atividade) para aplicativos em execução em pods que podem se comunicar com eles mesmos usando um serviço. Isso impede que a sinalização TCP FIN seja emitida e evita o vazamento da entrada do conntrack.
Ao usar conexões de curta duração, exponha o pod usando um balanceador de carga de proxy, como o Gateway, para expor o serviço. Isso faz com que o destino da solicitação de conexão seja definido como o endereço IP do balanceador de carga, impedindo que o GKE Dataplane V2 execute SNAT no endereço IP de loopback.
A seguir
- Use a geração de registros de política de rede para gravar quando as conexões com pods forem permitidas ou negadas pelas políticas de rede do cluster.
- Saiba como funciona o GKE Dataplane V2.