Executando o kube-proxy no modo IPVS

Modo de foco

Executando o kube-proxy no modo IPVS - Amazon EKS

O EKS no modo IP Virtual Server (IPVS) resolve o problema de latência de rede frequentemente visto ao executar grandes clusters com mais de 1.000 serviços com o kube-proxy em execução no modo iptables legado. Esse problema de desempenho é o resultado do processamento sequencial das regras de filtragem de pacotes iptables para cada pacote. Esse problema de latência foi resolvido no nftables, o sucessor do iptables. No entanto, no momento em que este artigo foi escrito, o kube-proxy ainda estava em desenvolvimento para fazer uso de nftables. Para contornar esse problema, você pode configurar seu cluster para ser executado kube-proxy no modo IPVS.

Visão geral

O IPVS, que é GA desde a versão 1.11 do Kubernetes, usa tabelas de hash em vez de pesquisa linear para processar pacotes, fornecendo eficiência para clusters com milhares de nós e serviços. O IPVS foi projetado para balanceamento de carga, tornando-o uma solução adequada para problemas de desempenho de rede do Kubernetes.

O IPVS oferece várias opções para distribuir tráfego para pods de back-end. Informações detalhadas de cada opção podem ser encontradas na documentação oficial do Kubernetes, mas uma lista simples é mostrada abaixo. Round Robin e Least Connections estão entre as opções mais populares de balanceamento de carga IPVS no Kubernetes.

- rr (Round Robin)
- wrr (Weighted Round Robin)
- lc (Least Connections)
- wlc (Weighted Least Connections)
- lblc (Locality Based Least Connections)
- lblcr (Locality Based Least Connections with Replication)
- sh (Source Hashing)
- dh (Destination Hashing)
- sed (Shortest Expected Delay)
- nq (Never Queue)

Implementação

São necessárias apenas algumas etapas para habilitar o IPVS em seu cluster EKS. A primeira coisa que você precisa fazer é garantir que as imagens do nó de trabalho do EKS tenham o ipvsadm pacote de administração do Linux Virtual Server instalado. Para instalar esse pacote em uma imagem baseada no Fedora, como o Amazon Linux 2023, você pode executar o seguinte comando na instância do node de trabalho.


sudo dnf install -y ipvsadm

Em uma imagem baseada no Debian, como o Ubuntu, o comando de instalação ficaria assim.


sudo apt-get install ipvsadm

Em seguida, você precisa carregar os módulos do kernel para as opções de configuração do IPVS listadas acima. Recomendamos gravar esses módulos em um arquivo dentro do /etc/modules-load.d/ diretório para que sobrevivam à reinicialização.


sudo sh -c 'cat << EOF > /etc/modules-load.d/ipvs.conf
ip_vs
ip_vs_rr
ip_vs_wrr
ip_vs_lc
ip_vs_wlc
ip_vs_lblc
ip_vs_lblcr
ip_vs_sh
ip_vs_dh
ip_vs_sed
ip_vs_nq
nf_conntrack
EOF'

Você pode executar o comando a seguir para carregar esses módulos em uma máquina que já esteja em execução.


sudo modprobe ip_vs
sudo modprobe ip_vs_rr
sudo modprobe ip_vs_wrr
sudo modprobe ip_vs_lc
sudo modprobe ip_vs_wlc
sudo modprobe ip_vs_lblc
sudo modprobe ip_vs_lblcr
sudo modprobe ip_vs_sh
sudo modprobe ip_vs_dh
sudo modprobe ip_vs_sed
sudo modprobe ip_vs_nq
sudo modprobe nf_conntrack

nota

É altamente recomendável executar essas etapas do nó de trabalho como parte do processo de inicialização do nó de trabalho por meio do script de dados do usuário ou em qualquer script de construção executado para criar uma AMI personalizada do nó de trabalho.

Em seguida, você configurará o cluster kube-proxy DaemonSet para ser executado no modo IPVS. Isso é feito definindo kube-proxy mode para ipvs e ipvs scheduler para uma das opções de balanceamento de carga listadas acima, por exemplo: rr para Round Robin.

Atenção

Essa é uma mudança disruptiva e deve ser realizada fora do horário comercial. Recomendamos fazer essas alterações durante a criação inicial do cluster EKS para minimizar os impactos.

Você pode emitir um comando da AWS CLI para habilitar o IPVS atualizando o kube-proxy complemento EKS.


aws eks update-addon --cluster-name $CLUSTER_NAME --addon-name kube-proxy \
  --configuration-values '{"ipvs": {"scheduler": "rr"}, "mode": "ipvs"}' \
  --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 scheduler configuração abaixo ipvs e defina o valor para uma das opções de balanceamento de carga do ipvs listadas acima, por exemplo: rr para Round Robin. Encontre a mode configuração, cujo padrão éiptables, e altere o valor para. ipvs O resultado de qualquer uma das opções deve ser semelhante à configuração abaixo.


  iptables:
    masqueradeAll: false
    masqueradeBit: 14
    minSyncPeriod: 0s
    syncPeriod: 30s
  ipvs:
    excludeCIDRs: null
    minSyncPeriod: 0s
    scheduler: "rr"
    syncPeriod: 30s
  kind: KubeProxyConfiguration
  metricsBindAddress: 0.0.0.0:10249
  mode: "ipvs"
  nodePortAddresses: null
  oomScoreAdj: -998
  portRange: ""
  udpIdleTimeout: 250ms

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


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

Validação

Você pode validar se o cluster e os nós de trabalho estão sendo executados no modo IPVS emitindo o seguinte comando em um dos seus nós de trabalho.


sudo ipvsadm -L

No mínimo, você deve ver um resultado semelhante ao abaixo, mostrando entradas para o serviço Kubernetes API Server em e 10.100.0.1 o serviço CoreDNS em. 10.100.0.10


IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  ip-10-100-0-1.us-east-1. rr
  -> ip-192-168-113-81.us-eas Masq        1      0          0
  -> ip-192-168-162-166.us-ea Masq        1      1          0
TCP  ip-10-100-0-10.us-east-1 rr
  -> ip-192-168-104-215.us-ea Masq        1      0          0
  -> ip-192-168-123-227.us-ea Masq        1      0          0
UDP  ip-10-100-0-10.us-east-1 rr
  -> ip-192-168-104-215.us-ea Masq        1      0          0
  -> ip-192-168-123-227.us-ea Masq        1      0          0