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 o kube-proxy no modo IPVS
O EKS no modo IP Virtual Server (IPVS) resolve o [problema de latência de rede](https://docs.aws.amazon.com/eks/latest/best-practices/control-plane.html#reliability_cprunning_large_clusters) 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](https://kubernetes.io/docs/reference/networking/virtual-ips/#proxy-mode-nftables) 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 do
O IPVS, que é GA desde a [versão 1.11 do Kubernetes](https://kubernetes.io/blog/2018/07/09/ipvs-based-in-cluster-load-balancing-deep-dive/), 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](https://kubernetes.io/docs/reference/networking/virtual-ips/#proxy-mode-ipvs), 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 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](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html) 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
```
**nota**
Este exemplo de saída vem de um cluster EKS com um intervalo de endereços IP de serviço de`10.100.0.0/16`.