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

Por padrão, seus nós de trabalho possuem o sistema operacional e o hardware de computação correspondentes ao tipo de nó de trabalho que você escolhe ao criar o pool de nós 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 das definições do kernel, certifique-se de documentar e salvar as alterações 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 começar: acesse o seu cluster do Red Hat OpenShift.

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.

   Dependendo das configurações systctl que você tentar mudar, talvez queira configurar o contexto de segurança. Para obter mais informações, consulte a documentação do Red Hat OpenShift.

   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.

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

Para restaurar os parâmetros d sysctl s dos seus nós de trabalho 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.

   oc 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 as configurações de keepalive de rede sysctl

Se um pod tiver conexões TCP de longa duração que são ocasionalmente desconectadas quando ficam ociosas por um período de tempo, pode ser útil alterar as configurações de keepalive 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.

Permitir o privilegiado initContainers no espaço de nomes test-ns:

oc adm policy add-scc-to-group privileged system:serviceaccounts:test-ns

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

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

Alteração da unidade máxima de transmissão (MTU) para clusters que usam Calico

Você pode aumentar ou diminuir a unidade máxima de transmissão (MTU) do nó de trabalho e do plug- Calico, a fim de atender aos requisitos de taxa de transferência de rede do seu ambiente.

Todos os nós de trabalho da VPC suportam até 9000 MTUs, e os nós de trabalho bare metal clássicos também suportam até 9000 MTUs. Os servidores virtuais clássicos suportam somente a MTU padrão de 1500, portanto, se o seu cluster tiver nós de trabalho de servidor virtual clássico, não aumente a MTU do nó de trabalho nem a do Calico.

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 Red Hat OpenShift on IBM Cloud 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 seus nós de trabalho ainda estiverem utilizando o valor padrão de MTU, aumente primeiro o valor de MTU desses nós antes de aumentar o valor de MTU do plug-in “ Calico ”. Por exemplo, você pode aplicar o seguinte conjunto de daemons para alterar o MTU dos seus nós de trabalho para 9.000 bytes. Observe os nomes de interface que são usados no comando ip link variam de acordo com o tipo de nós do trabalhador.

• Exemplo de comando para nós do trabalhador Bare Metal: ip link set dev bond0 mtu 9000;ip link set dev bond1 mtu 9000;
• Exemplo de comando de nós de trabalho da VPC: 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.

       oc get nodes -o wide
       ```
   1. Faça login em um dos nós. Especifique o nome do nó.
   
   
   ```sh {: pre}
       oc debug node/<NODE_NAME>
       ```
   
   
   
   1. 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.
   ```sh {: pre}
       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ó.

     oc 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.

   oc debug node/<NODE_NAME>
   

   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 de MTU do Calico, recomendamos que você verifique 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.

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

   Você também pode editar o recurso diretamente executando ' oc 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, recomenda-se 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 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.

Desativar o plug-in do mapa de portas em Calico

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 causar problemas de desempenho no plug-in do port map e pode impedir futuras atualizações das regras do iptables ou fazer com que o contêiner do calico-node seja reiniciado caso não seja recebido um bloqueio para realizar as atualizações das regras do iptables dentro de um prazo 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.

1. Edite o recurso de instalação default do Calico.

   oc edit installation default -n calico-system
   

2. Na seção spec.calicoNetwork, mude o valor de hostPorts para Disabled.

   ...
   spec:
     calicoNetwork:
       hostPorts: Disabled
       ipPools:
         - cidr: 172.30.0.0/16
           encapsulation: IPIPCrossSubnet
           natOutgoing: Enabled
           nodeSelector: all()
       mtu: 1480
       nodeAddressAutodetectionV4:
         interface: (^bond0$|^eth0$|^ens6$|^ens3$)
     kubernetesProvider: OpenShift
     registry: us.icr.io/armada-master/
     variant: Calico
   status:
     variant: Calico
   

3. Salve e feche o arquivo. Suas mudanças são aplicadas automaticamente.