View a markdown version of this page

Executando kube-proxy no modo nftables - Amazon EKS

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Executando kube-proxy no modo nftables

kube-proxyNo modo nftables, o Amazon EKS pode resolver o problema de latência de rede comum em grandes clusters com mais de 1.000 serviços executando kube-proxy no modo iptables. O modo Iptables processa as regras de filtragem de pacotes sequencialmente para o primeiro pacote de cada conexão, o que causa esse problema de desempenho. O nftables é o sucessor do iptables, e o kube-proxy backend do nftables resolve esse problema de latência processando pacotes em tempo quase constante, independentemente do tamanho do cluster. Para evitar esse problema, configure seu cluster para ser executado kube-proxy no modo nftables.

Visão geral do

O kube-proxy backend nftables está geralmente disponível (GA) desde a versão 1.33 do Kubernetes. Ele estava disponível como alfa na versão 1.29 e beta na versão 1.31. O backend iptables instala uma regra para cada serviço e avalia as regras sequencialmente. Isso resulta em um tempo de processamento do pacote O (n) que cresce com o número de serviços. Por outro lado, o nftables usa mapas de veredicto para despachar pacotes em aproximadamente O (1) tempo. Isso mantém a latência por pacote quase constante, mesmo em clusters com dezenas de milhares de serviços, fornecendo eficiência para clusters com milhares de nós e serviços.

nota

Embora o backend do nftables seja GA, iptables continua sendo o kube-proxy modo padrão por motivos de compatibilidade. Você deve optar explicitamente pelo modo nftables.

Ao contrário do back-end IPVS, que foi projetado como um balanceador de carga e expõe algoritmos de agendamento como round robin e least connections, o backend nftables não oferece algoritmos de agendamento configuráveis. Quando um serviço tem vários pods de apoio, o modo nftables seleciona um pod de back-end aleatoriamente.

Requisitos

O kube-proxy backend nftables requer o kernel Linux 5.13 ou posterior em seus nós de trabalho. O Amazon Linux 2023 e as versões atuais do Ubuntu atendem a esse requisito mínimo. Como kube-proxy os programas nftables governam diretamente por meio do subsistema netfilter do kernel, você não precisa de nenhum pacote de espaço de usuário adicional (comoipvsadm) ou carregamento de módulo do kernel além de um kernel compatível.

nota

O Kernel 5.13 é o mínimo necessário para executar o modo nftables. Para melhorar o desempenho da sincronização de regras em clusters grandes, recomendamos um kernel e uma kube-proxy versão mais recentes. Para obter mais informações, consulte Considerações de desempenho.

Importante

O backend nftables pode não ser compatível com todos os plug-ins de rede. Consulte a documentação do seu provedor CNI antes de ativar o modo nftables. O Amazon VPC CNI é compatível com o modo nftables a partir da versão. v1.23.0

Implementação

Configure seus clusters kube-proxy DaemonSet para serem executados no modo nftables definindo como. kube-proxy mode nftables

Atenção

Essa é uma mudança disruptiva. Recomendamos realizá-lo fora do horário comercial ou durante a criação inicial do cluster EKS para minimizar os impactos.

Você pode emitir um comando da AWS Command Line Interface (AWS CLI) para habilitar o nftables atualizando o EKS. kube-proxy Add-on Isso requer um cluster EKS executando o Kubernetes 1.33 ou posterior.

aws eks update-addon --cluster-name $CLUSTER_NAME --addon-name kube-proxy \ --configuration-values '{"mode": "nftables"}' \ --resolve-conflicts OVERWRITE

Ou você pode fazer isso modificando o kube-proxy-config ConfigMap em seu cluster.

kubectl -n kube-system edit cm kube-proxy-config

Encontre a mode configuração, cujo padrão éiptables, e altere o valor para. nftables O resultado de qualquer opção deve ser semelhante à configuração a seguir.

mode: "nftables" nftables: masqueradeAll: false masqueradeBit: 14 minSyncPeriod: 1s syncPeriod: 30s kind: KubeProxyConfiguration metricsBindAddress: 0.0.0.0:10249 nodePortAddresses: null oomScoreAdj: -998 portRange: ""

Se seus nós de trabalho foram unidos ao seu cluster antes de você fazer essas alterações, reinicie o DaemonSet kube-proxy.

kubectl -n kube-system rollout restart ds kube-proxy

Considerações sobre desempenho

Embora o modo nftables esteja geralmente disponível a partir da versão Kubernetesv1.33, recomendamos usar esse modo apenas começando com. v1.36 Na kube-proxy v1.36.0, o projeto Kubernetes fez muitos aprimoramentos de desempenho na forma como os mapas e regras do nftables são construídos. Essas mudanças reduzem significativamente o número de cadeias e goto regrasjump/, melhorando consideravelmente o desempenho da sincronização em grande escala.

Esses aprimoramentos beneficiam principalmente clusters com um grande número de endpoints (os pods que apoiam seus serviços). Antes da kube-proxy v1.36.0, clusters com centenas de milhares de endpoints podiam ter tempos de sincronização de regras nftables muito lentos e travamentos de software de CPU. Isso acontece porque o kernel Linux verifica se as cadeias e saltos kube-proxy gerados não contêm loops.

Esse comportamento também é afetado pela versão do kernel Linux. As melhorias subjacentes do kernel estão incluídas no kernel Linux 6.18 (e estão sendo transferidas para alguns kernels estáveis anteriores). Usar o modo nftables com versões anteriores do kernel Linux pode resultar em tempos de sincronização de regras mais lentos e possíveis travamentos de software da CPU. Para obter o melhor desempenho em clusters grandes, recomendamos executar um kernel Linux recente junto com a kube-proxy versão v1.36.0 ou posterior. Para obter mais informações, consulte o problema de desempenho do kube-proxy nftables (kubernetes/kubernetes#135639) no site. GitHub