Configurações padrão do nó do trabalhador

Por padrão, os nós de trabalho têm o sistema operacional e o hardware de computação da variante de nó de trabalho que você escolhe ao criar o pool de trabalho.

Modificação das configurações do kernel do nó de trabalho para otimizar o desempenho

Os nós do trabalhador do cluster são configurados para um nível de estabilidade, otimização e desempenho que deve atender às necessidades da maioria das cargas de trabalho. Geralmente, não é recomendado mudar as configurações do kernel do nó do trabalhador, pois essas mudanças podem criar problemas incomuns e indesejados.. No entanto, se a sua carga de trabalho tiver requisitos de otimização de desempenho altamente exclusivos que necessitem de mudanças em suas configurações de kernel, um daemonset customizado do Kubernetes poderá ser aplicado para mudar a configuração do kernel Entenda que essas mudanças podem ter consequências negativas significativas e que você implementa as mudanças na configuração de configurações do kernel por sua conta e risco

Se você alterar a configuração de suas configurações de kernel, certifique-se de documentar e salvar as mudanças exatas feitas. Se você abrir um chamado de suporte para quaisquer problemas relacionados ao cluster, deverá especificar essas mudanças. Essas mudanças de configuração podem ser responsáveis pelo problema e você pode ser solicitado a reverter as mudanças como parte da investigação do problema. Nesse caso, você é responsável por reverter quaisquer mudanças na configuração do kernel implementadas.

A mudança das configurações do kernel padrão pode ter efeitos negativos em seu cluster Faça essas mudanças a seu próprio risco.

É possível mudar as configurações do kernel padrão aplicando um Kubernetes DaemonSet customizado com um init Container em seu cluster O conjunto do daemon modifica as configurações para todos os nós do trabalhador existentes e aplica as configurações a quaisquer novos nós do trabalhador que são provisionados no cluster. O contêiner init garante que essas modificações ocorram antes que outros pods sejam agendados no nó de trabalho. Nenhum pods é afetado.

Deve-se ter a função de acesso de serviço Gerenciador do IBM Cloud IAM de todos os namespaces para executar a amostra privilegiada initContainer. Após os contêineres para as implementações serem inicializados, os privilégios serão eliminados.

Antes de iniciar: efetue login na sua conta. If applicable, target the appropriate resource group. Configure o contexto para o seu cluster.

1. Salve o daemon a seguir configurado em um arquivo denominado worker-node-kernel-settings.yaml. Na seção spec.template.spec.initContainers, inclua os campos e valores para os parâmetros sysctl que você deseja ajustar. Esse conjunto de daemons de exemplo muda o número máximo padrão de conexões que são permitidas no ambiente por meio da configuração net.core.somaxconn e do intervalo de portas efêmeras por meio da configuração net.ipv4.ip_local_port_range.

   apiVersion: apps/v1
   kind: DaemonSet
   metadata:
     name: kernel-optimization
     namespace: kube-system
     labels:
       tier: management
       app: kernel-optimization
   spec:
     selector:
       matchLabels:
         name: kernel-optimization
     template:
       metadata:
         labels:
           name: kernel-optimization
       spec:
         hostNetwork: true
         hostPID: true
         hostIPC: true
         initContainers:
           - command:
               - sh
               - -c
               - sysctl -w net.ipv4.tcp_syn_retries="5"; sysctl -w net.ipv4.tcp_fin_timeout="15";
             image: us.icr.io/armada-master/network-alpine:latest
             imagePullPolicy: Always
             name: sysctl
             resources: {}
             securityContext:
               privileged: true
               capabilities:
                 add:
                   - NET_ADMIN
             volumeMounts:
               - name: modifysys
                 mountPath: /sys
         containers:
           - resources:
               requests:
                 cpu: 0.01
             image: us.icr.io/armada-master/network-alpine:latest
             name: sleepforever
             command: ["/bin/sh", "-c"]
             args:
               - >
                 while true; do
                   sleep 100000;
                 done
         volumes:
           - name: modifysys
             hostPath:
               path: /sys
   

2. Aplique o conjunto de daemons aos seus nós do trabalhador. As mudanças são aplicadas imediatamente.

   kubectl apply -f worker-node-kernel-settings.yaml
   

Para reverter os parâmetros dos nós de trabalho sysctl para os valores padrão, siga estas etapas.

1. Exclua o conjunto de daemon. Os initContainers que aplicaram as configurações customizadas são removidos.

   kubectl delete ds kernel-optimization
   

2. Reinicialize todos os nós do trabalhador no cluster. Os nós do trabalhador voltam on-line, com os valores padrão aplicados.

Otimizando o desempenho do pod

Se você tiver demandas de carga de trabalho de desempenho específicas, será possível mudar as configurações padrão para os parâmetros sysctl do kernel do Linux em namespaces de rede de pod.

Para otimizar as configurações do kernel para os pods do app, é possível inserir uma correção initContainer no YAML pod/ds/rs/deployment para cada implementação. O initContainer é incluído em cada implementação de app que está no namespace de rede do pod para o qual você deseja otimizar o desempenho.

Antes de começar, assegure-se de que você tenha a função de acesso de serviço Gerenciador do IBM Cloud para todos os namespaces para executar a amostra privilegiada initContainer. Após os contêineres para as implementações serem inicializados, os privilégios serão eliminados.

1. Salve a correção initContainer a seguir em um arquivo denominado pod-patch.yaml e inclua os campos e valores para os parâmetros sysctl que você deseja ajustar. Este exemplo initContainer muda o número máximo padrão de conexões permitidas no ambiente por meio da configuração net.core.somaxconn e do intervalo de portas efêmeras por meio da configuração net.ipv4.ip_local_port_range.

   spec:
     template:
       spec:
         initContainers:
         - command:
           - sh
           - -c
           - sysctl -e -w net.core.somaxconn=32768;  sysctl -e -w net.ipv4.ip_local_port_range="1025 65535";
           image: alpine:3.6
           imagePullPolicy: IfNotPresent
           name: sysctl
           resources: {}
           securityContext:
             privileged: true
   

2. Corrigir cada uma de suas implementações.

   kubectl patch deployment <deployment_name> --patch pod-patch.yaml
   

3. Se você mudou o valor net.core.somaxconn nas configurações do kernel, a maioria dos apps poderá usar automaticamente o valor atualizado. No entanto, alguns apps podem requerer que você mude manualmente o valor correspondente em seu código de app para corresponder ao valor de kernel. Por exemplo, se estiver ajustando o desempenho de um pod no qual um app NGINX executa, deverá mudar o valor do campo backlog no código de app do NGINX para correspondência. Para obter mais informações, consulte esta Postagem do blog do NGINX.

Otimizando configurações de sysctl keepalive da rede

Se um pod tiver conexões TCP de longa execução que são ocasionalmente desconectadas quando elas estão inativas por um período de tempo, isso pode ajudar a mudar as configurações de keep-alive do sysctl para o pod

Atualmente, não há uma maneira de definir essas configurações de keep-alive do sysctl em todos os pods por padrão em um cluster A melhor maneira de modificar as configurações em todos os pods é usar um initContainer privilegiado Revise o exemplo a seguir de como configurar um initContainer para uma implementação em um namespace test-ns.

Implemente o seguinte exemplo initContainer. Lembre-se de mudar a seção containers: para os seus próprios contêineres de aplicativos O initContainer então define as configurações de sysctl para todos os contêineres regulares no pod porque todos eles compartilham o mesmo namespace de rede.

```sh {: pre}
kubectl apply -f - << EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: test-sysctl
  namespace: test-ns
  labels:
    run: test-sysctl
spec:
  replicas: 2
  selector:
    matchLabels:
      run: test-sysctl
  template:
    metadata:
      labels:
        run: test-sysctl
    spec:
      initContainers:
      - command:
        - sh
        - -c
        - sysctl -e -w net.ipv4.tcp_keepalive_time=40; sysctl -e -w net.ipv4.tcp_keepalive_intvl=15; sysctl -e -w net.ipv4.tcp_keepalive_probes=6;
        image: us.icr.io/armada-master/alpine:latest
        imagePullPolicy: IfNotPresent
        name: sysctl-init
        resources: {}
        securityContext:
          privileged: true
      containers:
      - name: test-sysctl
        image: us.icr.io/armada-master/alpine:latest
        command: ["sleep", "2592000"]
  EOF
```

Ajustando os recursos do provedor de métricas do cluster

O cluster possui um serviço de métricas fornecido pela implementação metrics-server no espaço de nomes kube-system. As solicitações de recursos metrics-server são baseadas no número de nós no cluster e otimizadas para clusters com 30 ou menos pods por nó do trabalhador. O serviço de métrica corresponde aos limites de memória e CPU das solicitações de recursos.

Os contêineres de serviço de métricas podem ser "encerrados por falta de memória" se as solicitações de memória forem muito baixas. Eles podem responder muito lentamente ou falhar em análise de vivacidade e prontidão devido à limitação de CPU se as solicitações de CPU forem muito baixas.

O uso e memória é impulsionado pelo número de pods no cluster. O uso da CPU é orientado pelo número de solicitações para métricas (HPAs, kubectl top nodes / pods, etc.) e por solicitações de descoberta de API. O metrics-server fornece uma API de Kubernetes para que clientes como kubectl que usam descoberta API coloquem carga no metrics-server, mesmo que não usem métricas.

Os sintomas a seguir podem indicar uma necessidade de ajustar os recursos metrics-server:

• O metrics-server está reiniciando com frequência.

• A exclusão de um espaço de nomes faz com que ele fique preso em um estado Terminating e kubectl describe namespace inclui uma condição relatando um erro de descoberta de API de métricas.

• kubectl top pods, kubectl top nodes, outros comandos kubectl ou aplicativos que usam a API de Kubernetes para registrar erros de Kubernetes como:

The server is currently unable to handle the request (get pods.metrics.k8s.io)

Discovery failed for some groups, 1 failing: unable to retrieve the complete list of server APIs: metrics.k8s.io/v1beta1: the server is currently unable to handle the request

• HorizontalPodAutoscalers (HPAs) não escala implementações.

• A execução de kubectl get apiservices v1beta1.metrics.k8s.io resulta em um status como:

NAME                     SERVICE                      AVAILABLE                      AGE
v1beta1.metrics.k8s.io   kube-system/metrics-server   False (FailedDiscoveryCheck)   139d

cpuRequest = baseCPU + cpuPerNode * number_of_nodes
memoryRequest = baseMemory + memoryPerNode * number_of_nodes

apiVersion: v1
kind: ConfigMap
metadata:
  labels:
    addonmanager.kubernetes.io/mode: EnsureExists
    kubernetes.io/cluster-service: "true"
  name: metrics-server-config
  namespace: kube-system
data:
  NannyConfiguration: |-
    apiVersion: nannyconfig/v1alpha1
    kind: NannyConfiguration

apiVersion: v1
kind: ConfigMap
metadata:
  labels:
    addonmanager.kubernetes.io/mode: EnsureExists
    kubernetes.io/cluster-service: "true"
  name: metrics-server-config
  namespace: kube-system
data:
  NannyConfiguration: |-
    apiVersion: nannyconfig/v1alpha1
    kind: NannyConfiguration
    baseCPU: 200m
    cpuPerNode: 1m
    baseMemory: 40Mi
    memoryPerNode: 6Mi

baseCPU: 200m
cpuPerNode: 1m
baseMemory: 40Mi
memoryPerNode: 6Mi

kubectl edit cm metrics-server-config -n kube-system

kubectl delete cm metrics-server-config -n kube-system

kubectl get pod -n kube-system -l k8s-app=metrics-server
NAME                             READY   STATUS    RESTARTS   AGE
metrics-server-9fb4947d6-s6sgl   3/3     Running   0          2d4h
kubectl describe pod -n kube-system metrics-server-9fb4947d6-s6sgl

Containers:
  metrics-server:
    Container ID:  containerd://fe3d07c9a2541242d36da8097de3896f740c1363f6d2bfd01b8d96a641192b1b
    Image:         registry.ng.bluemix.net/armada-master/metrics-server:v0.4.4
    Image ID:      registry.ng.bluemix.net/armada-master/metrics-server@sha256:c2c63900d0e080c2413b5f35c5a59b5ed3b809099355728cf47527aa3f35477c
    Port:          4443/TCP
    Host Port:     0/TCP
    Command:
      /metrics-server
      --metric-resolution=45s
      --secure-port=4443
      --tls-cert-file=/etc/metrics-server-certs/tls.crt
      --tls-private-key-file=/etc/metrics-server-certs/tls.key
    State:          Running
      Started:      Fri, 10 Sep 2021 17:31:39 +0000
    Last State:     Terminated
      Reason:       OOMKilled
      Exit Code:    137
      Started:      Fri, 10 Sep 2021 05:59:51 +0000
      Finished:     Fri, 10 Sep 2021 17:31:37 +0000
    Ready:          True
    Restart Count:  36

Last State:     Terminated
  Reason:       OOMKilled
  Exit Code:    137

Last State:     Terminated
  Reason: Error
  Exit Code: 137

Events:
Warning Unhealthy 46m (x5 over 80m) kubelet Liveness probe failed: Get "https://198.18.68.236:4443/livez": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
Warning Unhealthy 26m (x65 over 89m) kubelet Liveness probe failed: Get "https://198.18.68.236:4443/livez": net/http: TLS handshake timeout
Warning Unhealthy 21m (x10 over 76m) kubelet Readiness probe failed: Get "https://198.18.68.236:4443/readyz": net/http: request canceled (Client.Timeout exceeded while awaiting headers)
Warning Unhealthy 115s (x93 over 90m) kubelet Readiness probe failed: Get "https://198.18.68.236:4443/readyz": net/http: TLS handshake timeout

Ativando páginas muito grandes

Infraestrutura clássica Virtual Private Cloud

É possível ativar o Planejamento de HugePages do Kubernetes em clusters que executam o Kubernetes versão 1.19 ou mais recente. O único tamanho de página suportado é 2 MB por página, que é o tamanho padrão da porta de recurso do Kubernetes.

O planejamento de páginas muito grandes é um recurso beta no IBM Cloud Kubernetes Service e está sujeito a mudanças.

Por padrão, a CPU de seus nós do trabalhador aloca a RAM em chunks, ou páginas, de 4 KB. Quando seu app requer mais RAM, o sistema deve continuar a consultar mais páginas, o que pode desacelerar o processamento. Com páginas muito grandes, é possível aumentar o tamanho da página para 2 MB a fim de aumentar o desempenho de seus apps com uso intensivo de RAM, como bancos de dados para inteligência artificial (IA), Internet das Coisas (IoT) ou cargas de trabalho de aprendizado de máquina. Para obter mais informações sobre páginas enormes, consulte a documentação do kernel Linux.

É possível reinicializar o nó do trabalhador e persistir a configuração de páginas muito grandes. No entanto, a configuração das páginas enormes não persiste em nenhuma outra operação do ciclo de vida do nó de trabalho. As etapas de ativação deverão ser repetidas cada vez que você atualizar, recarregar, substituir ou incluir nós do trabalhador.

• Função de acesso à plataforma Operador e função de acesso ao serviço Gerenciador para o cluster no IBM Cloud IAM

Antes de iniciar: efetue login na sua conta. If applicable, target the appropriate resource group. Configure o contexto para o seu cluster.

1. Crie um arquivo de configuração hugepages-ds.yaml para ativar páginas muito grandes. O YAML de amostra a seguir usa um daemon configurado para executar o pod em cada nó do trabalhador em seu cluster. É possível configurar a alocação de páginas muito grandes que estão disponíveis no nó do trabalhador usando o parâmetro vm.nr_hugepages. Este exemplo aloca 512 páginas a 2 MB por página, para 1 GB de RAM total alocado exclusivamente para páginas muito grandes.

   Deseja ativar páginas muito grandes somente para determinados nós do trabalhador, como um conjunto de trabalhadores usado para apps com uso intensivo de RAM? Rotule e contamine seu conjunto de trabalhadores e, em seguida, inclua regras de afinidade no conjunto de daemons para que os pods sejam implementados somente nos nós do trabalhador do conjunto de trabalhadores que você especificar.

   apiVersion: apps/v1
   kind: DaemonSet
   metadata:
     name: hugepages-enablement
     namespace: kube-system
     labels:
       tier: management
       app: hugepages-enablement
   spec:
     selector:
       matchLabels:
         name: hugepages-enablement
     template:
       metadata:
         labels:
           name: hugepages-enablement
       spec:
         hostPID: true
         initContainers:
           - command:
               - sh
               - -c
               # Customize allocated Hugepages by providing the value
               - "echo vm.nr_hugepages=512 > /etc/sysctl.d/90-hugepages.conf"
             image: alpine:3.6
             imagePullPolicy: IfNotPresent
             name: sysctl
             resources: {}
             securityContext:
               privileged: true
             volumeMounts:
               - name: modify-sysctld
                 mountPath: /etc/sysctl.d
         containers:
           - resources:
               requests:
                 cpu: 0.01
             image: alpine:3.6
             # once the init container completes, keep the pod running for worker node changes
             name: sleepforever
             command: ["/bin/sh", "-c"]
             args:
               - >
                 while true; do
                     sleep 100000;
                 done
         volumes:
           - name: modify-sysctld
             hostPath:
               path: /etc/sysctl.d
   

2. Aplique o arquivo criado anteriormente.

   kubectl apply -f hugepages-ds.yaml
   

3. Verifique se os pods estão Em execução.

   kubectl get pods
   

4. Reinicie o kubelet que é executado em cada nó do trabalhador por meio da reinicialização dos nós do trabalhador. Não recarregue o nó do trabalhador para reiniciar o kubelet. O recarregamento do nó do trabalhador antes que o kubelet retome a ativação de páginas muito grandes faz com que a ativação falhe.

   1. Liste os nós do trabalhador em seu cluster.

      ibmcloud ks worker ls -c <cluster_name_or_ID>
      

   2. Reinicialize os nós do trabalhador. Você pode reinicializar vários nós de trabalho incluindo várias opções de -w, mas certifique-se de deixar um número suficiente de nós de trabalho em execução ao mesmo tempo para que seus aplicativos evitem uma interrupção.

      ibmcloud ks worker reboot -c <cluster_name_or_ID> -w <worker1_ID> -w <worker2_ID>
      

5. Crie um pod de teste hugepages-test.yaml que monte páginas muito grandes como um volume e use limites de recursos e solicitações para configurar a quantidade de recursos de páginas muito grandes que o pod usa. Nota: se você tiver usado rótulos, contaminações e regras de afinidade para ativar páginas muito grandes somente em nós do trabalhador selecionados, inclua essas mesmas regras em seu pod de teste.

   apiVersion: v1
   kind: Pod
   metadata:
     name: hugepages-example
   spec:
     containers:
     - name: hugepages-example
       image: fedora:34
       command:
       - sleep
       - inf
       volumeMounts:
       - mountPath: /hugepages-2Mi
         name: hugepage-2mi
       resources:
         limits:
           hugepages-2Mi: 100Mi
           memory: 100Mi
         requests:
           memory: 100Mi
     volumes:
     - name: hugepage-2mi
       emptyDir:
         medium: HugePages-2Mi
   

6. Aplique o arquivo pod criado anteriormente.

   kubectl apply -f hugepages-pod.yaml
   

7. Verifique se seu pod usa os recursos de páginas muito grandes.

   1. Verifique se seu pod está Em execução. O pod não será executado se nenhum nó do trabalhador com páginas muito grandes estiver disponível.

      kubectl get pods
      

   2. Efetue login no pod.

      kubectl exec -it <pod> /bin/sh
      

   3. Verifique se o seu pod pode visualizar os tamanhos das páginas muito grandes.

      ls /sys/kernel/mm/hugepages
      

      Saída de exemplo

      hugepages-1048576kB  hugepages-2048kB
      

8. Opcional: remova o daemon de ativação configurado. Tenha em mente que o daemon configurado deverá ser recriado se for necessário atualizar, recarregar, substituir ou incluir nós do trabalhador com páginas muito grandes posteriormente.

   kubectl -n kube-system delete daemonset hugepages-enablement
   

9. Repita essas etapas sempre que atualizar, recarregar, substituir ou incluir nós do trabalhador.

Para solucionar problemas de nós do trabalhador com páginas muito grandes, é possível reinicializar somente o nó do trabalhador. A configuração de páginas muito grandes não persiste em nenhuma outra operação de ciclo de vida do nó do trabalhador, como atualização, recarregamento, substituição ou inclusão de nós do trabalhador. Para remover a configuração de páginas muito grandes de seu cluster, é possível atualizar, recarregar ou substituir todos os nós do trabalhador.

Mudando a unidade de transmissão máxima do Calico (MTU)

Aumente ou diminua a unidade de transmissão máxima do plug-in do Calico (MTU) para atender aos requisitos de rendimento de rede de seu ambiente.

Essas etapas são aplicáveis a clusters que executam a versão 1.29 ou posterior. Além disso, todos os nós de trabalho da VPC oferecem suporte a jumbo frames, mas a infraestrutura clássica só oferece suporte a jumbo frames em trabalhadores bare metal.

A alteração dos valores da unidade máxima de transmissão (MTU) pode ter resultados inesperados, especialmente em ambientes de rede complexos. Para evitar a interrupção do seu fluxo de trabalho, é altamente recomendável testar essas alterações em um cluster de desenvolvimento antes de fazer qualquer alteração nos clusters de produção.

Por padrão, o plug-in de rede do Calico em seu cluster IBM Cloud Kubernetes Service tem um MTU de 1450 bytes para clusters Satellite e 1480 bytes para clusters não Satellite. Na maioria dos casos, esse valor padrão Calico MTU é suficiente para evitar quedas e fragmentação de pacotes. Como a maioria dos hosts usa um valor de MTU de 1500, esses valores padrão fornecem aos clusters Satellite 50 bytes extras para os cabeçalhos VXLAN e fornecem aos clusters não Satellite 20 bytes extras para os cabeçalhos IP usados em alguns tráfegos de rede de cluster de pod para pod. Observe que todos os nós de trabalho no cluster devem usar o mesmo valor de MTU Calico.

Revise os casos a seguir nos quais você pode precisar modificar a MTU do Calico padrão:

• Se você precisar melhorar a taxa de transferência da rede pod a pod e os nós do cluster puderem usar uma MTU de host mais alta, poderá aumentar a MTU do host e Calico. Isso é chamado de uso de "jumbo frames". O MTU típico do jumbo frame é 9000. Nesse caso, você pode definir a interface de rede privada do host com um valor de MTU de 9000 e o MTU Calico com um valor um pouco menor: 8950 para clusters Satellite e 8980 para clusters não Satellite. Observe que alguns recursos ou hardware do provedor de nuvem, como as máquinas virtuais Azure, podem não suportar quadros jumbo ou podem suportar apenas um valor de MTU de até 4000.
• Se você tiver uma conexão VPN configurada para seu cluster, algumas conexões VPN requererão uma MTU Calico menor que o padrão. Verifique com o provedor de serviços de VPN para determinar se é necessária uma MTU do Calico menor.

Antes de Iniciar

Se os nós de trabalho ainda executarem o valor padrão de MTU, aumente o valor de MTU dos nós de trabalho antes de aumentar o valor de MTU do plug-in Calico. Por exemplo, você pode aplicar o seguinte conjunto de daemons para alterar a MTU dos nós de trabalho para 9000 bytes. Observe que os nomes de interface usados no comando ip link variam dependendo do tipo de seus nós do trabalhador.

• Comando de exemplo para nós do trabalhador Bare Metal: ip link set dev bond0 mtu 9000;ip link set dev bond1 mtu 9000;
• Exemplo de nós do trabalhador do VPC Gen 2: ip link set dev ens3 mtu 9000;

1. Execute os seguintes comandos para fazer login em um nó de trabalho do cluster e fazer ping de um nó para outro. Como o MTU de seu nó está definido apenas como 1500 ou 1480, espera-se que essa tentativa falhe. Nas etapas a seguir, você pode executar esses comandos novamente para verificar se as alterações foram bem-sucedidas.

   1. Liste os nós em seu cluster. Salve os nomes e os endereços IP de dois nós íntegros.

      kubectl get nodes -o wide
      

   2. Faça login em um dos nós. Especifique o nome do nó.

      kubectl debug --image=us.icr.io/armada-master/network-alpine -it node/<NODE_NAME> -- sh
      

   3. Execute o comando para executar o ping de um nó para o outro. Especifique o endereço IP do nó ao qual você não fez referência na etapa anterior.

      ping -c1 -Mdo -s 8972 <OTHER_HOST_IP>
      

2. Altere o MTU do nó com o daemonset de exemplo a seguir. Esse valor de MTU se aplica ao tráfego nó a nó. Modifique a linha - ip link set dev ens3 mtu <MTU_VALUE> para incluir seu valor de MTU (o exemplo usa um valor de MTU de 9000). Observe que talvez você também precise alterar o nome da interface ' ens3 se ens3 não for adequado para seus nós.

   apiVersion: apps/v1
   kind: DaemonSet
   metadata:
     labels:
       app: set-host-mtu
     name: set-host-mtu
     namespace: kube-system
   spec:
     selector:
       matchLabels:
         name: set-host-mtu
     template:
       metadata:
         labels:
           name: set-host-mtu
       spec:
         containers:
         - args:
           - |
             while true; do
               sleep 100000;
             done
           command:
           - /bin/sh
           - -c
           image: us.icr.io/armada-master/network-alpine:latest
           imagePullPolicy: IfNotPresent
           name: sleepforever
           resources:
             requests:
               cpu: 10m
         hostNetwork: true
         initContainers:
         - command:
           - sh
           - -c
           - ip link set dev ens3 mtu 9000
           image: us.icr.io/armada-master/network-alpine:latest
           imagePullPolicy: IfNotPresent
           name: set-host-mtu
           securityContext:
             capabilities:
               add:
               - NET_ADMIN
             privileged: true
           volumeMounts:
           - mountPath: /sys
             name: modifysys
         restartPolicy: Always
         terminationGracePeriodSeconds: 2
         tolerations:
         - operator: Exists
         volumes:
         - hostPath:
             path: /sys
             type: ""
           name: modifysys
     updateStrategy:
       rollingUpdate:
         maxSurge: 0
         maxUnavailable: 1
       type: RollingUpdate
   

3. Aplique o conjunto de daemons para alterar o valor de MTU do nó.

     kubectl apply -f <file_name>
   

4. Execute novamente os comandos para fazer login em um nó e executar ping de um host para outro, usando um pacote de tamanho grande. Agora que você aumentou o valor do MTU do nó, espera-se que o comando " ping seja bem-sucedido.

   kubectl debug --image=us.icr.io/armada-master/network-alpine -it node/<NODE_NAME> -- sh
   

   ping -c1 -Mdo -s 8972 <OTHER_HOST_IP>
   

5. Reserve um tempo para testar seu cluster com o novo valor de MTU do nó. Antes de continuar a alterar o valor do MTU Calico, é recomendável verificar se os aplicativos ainda funcionam conforme o esperado.

6. Execute o comando para atualizar os valores de MTU Calico de modo que o tráfego de pod para pod também possa usar o MTU maior. Para clusters do Satellite Core OS, o valor do MTU Calico deve ser 50 bytes menor que o valor do MTU do nó. Para todos os outros clusters, o valor do Calico MTU deve ser 20 bytes menor. Por exemplo, se você especificou 9000 para o MTU do nó, o MTU Calico deverá ser 8950 para clusters Satellite Core OS ou 8980 para todos os outros clusters.

   kubectl patch installation.operator.tigera.io default --type='merge' -p '{"spec":{"calicoNetwork":{"mtu":<MTU_VALUE>}}}'
   

   Você também pode editar o recurso diretamente executando ' kubectl edit installation.operator.tigera.io default.

7. Aplique essas alterações a todos os seus nós reiniciando-os cuidadosamente. Certifique-se de ter testado esse processo em um cluster de desenvolvimento antes de continuar com esta etapa, pois essas alterações podem causar interrupções na sua carga de trabalho. Para reinicializar os nós, é recomendável que você faça o isolamento, a drenagem e a reinicialização dos nós, um a um.

Se estiver concluindo essas etapas em um cluster de produção, deverá usar o mesmo processo utilizado para atualizar ou substituir os nós de produção. É altamente recomendável que você teste todo esse processo em um cluster de teste antes de concluir essas etapas em um cluster de produção.

Durante o processo de reinicialização, alguns pods usam a nova MTU maior e alguns pods ainda têm a MTU original e menor. Normalmente, esse cenário não causa problemas porque ambos os lados negociam o tamanho máximo correto do pacote. No entanto, se você bloquear os pacotes ICMP, a negociação poderá não funcionar e o cluster poderá ter problemas de conexão do pod até que todas as reinicializações sejam concluídas. É fundamental que esse processo seja testado primeiro em um cluster de desenvolvimento.

Desativando o plug-in do mapa da porta

O plug-in portmap para a interface de rede de contêineres do Calico (CNI) permite que você use um hostPort para expor seus pods de app em uma porta específica no nó do trabalhador. Evite problemas de desempenho do IPtables removendo o plug-in do mapa da porta da configuração da CNI do Calico de seu cluster.

Quando você tem muitos serviços no cluster, como mais de 500, ou muitas portas em serviços, como mais de 50 portas por serviço para 10 ou mais serviços, muitas regras de iptables são geradas para as políticas de rede do Calico e Kubernetes para esses serviços. O uso de muitas regras do iptables pode levar a problemas de desempenho do plug-in do mapa de portas e pode impedir futuras atualizações das regras do iptables ou fazer com que o contêiner calico-node seja reiniciado quando nenhum bloqueio for recebido para fazer atualizações das regras do iptables dentro de um tempo especificado. Para evitar esses problemas de desempenho, é possível desativar o plug-in do mapa da porta removendo-o da configuração da CNI do Calico de seu cluster.

Se tiver que usar hostPorts, não desative o plug-in do mapa da porta.