Valores predeterminados del nodo trabajador

De forma predeterminada, los nodos de trabajo cuentan con el sistema operativo y el hardware de cálculo propios del tipo de nodo de trabajo que elijas al crear el grupo de nodos de trabajo.

Modificación de la configuración del kernel de los nodos de trabajo para optimizar el rendimiento

Los nodos trabajadores de clúster se configuran para un nivel de estabilidad, optimización y rendimiento que se espera que satisfaga las necesidades de la mayoría de cargas de trabajo. Normalmente, no se recomienda cambiar los valores del kernel del nodo trabajador, ya que estos cambios pueden crear problemas inusuales y no deseados. Sin embargo, si la carga de trabajo tiene requisitos de optimización de rendimiento muy exclusivos que requieren cambios en los valores del kernel, se puede aplicar un daemonset Kubernetes personalizado para cambiar la configuración del kernel. Comprenda que estos cambios pueden tener consecuencias negativas significativas y que implementa cambios en la configuración de valores del kernel bajo su propia responsabilidad.

Si cambias la configuración del núcleo, asegúrate de documentar y guardar los cambios exactos que realices. Si abre una incidencia de soporte para cualquier problema relacionado con el clúster, debe especificar estos cambios. Estos cambios de configuración pueden ser responsables del problema y es posible que se le solicite que revierta los cambios como parte de la investigación del problema. En este caso, usted es responsable de revertir cualquier cambio de configuración del kernel que implemente.

Cambiar los valores predeterminados del kernel puede tener efectos negativos en el clúster. Realice estos cambios bajo su propio riesgo.

Puede cambiar los valores de kernel predeterminados aplicando un Kubernetes DaemonSet personalizado con un Contenedor de init al clúster. El conjunto de daemons modifica los valores de todos los nodos trabajadores existentes y aplica los valores a los nuevos nodos trabajadores que se suministran en el clúster. El contenedor init se asegura de que estas modificaciones se realicen antes de que se programen otros pods en el nodo de trabajo. Los pods no se ven afectados.

Debes disponer del rol de acceso al servicio IAM Manager IBM Cloud para todos los espacios de nombres a fin de ejecutar el ejemplo con privilegios initContainer. Después de inicializar los contenedores para los despliegues, se descartarán los privilegios.

Antes de empezar: Inicie una sesión en su cuenta. If applicable, target the appropriate resource group. Establezca el contexto para el clúster.

1. Guarde el siguiente conjunto de daemons en un archivo denominado worker-node-kernel-settings.yaml. En la sección spec.template.spec.initContainers, añada los campos y valores de los parámetros de sysctl que desea ajustar. Este conjunto de daemons de ejemplo cambia el número máximo predeterminado de conexiones permitidas en el entorno mediante el valor net.core.somaxconn y el rango de puertos efímeros mediante el valor 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 el conjunto de daemons a los nodos trabajadores. Los cambios se aplican inmediatamente.

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

Para restablecer los parámetros sysctl de tus nodos de trabajo a los valores predeterminados, sigue estos pasos.

1. Suprima el conjunto de daemons. Se eliminan los initContainers que han aplicado los valores personalizados.

   kubectl delete ds kernel-optimization
   

2. Rearranque todos los nodos trabajadores del clúster. Los nodos trabajadores vuelven a estar en línea con los valores predeterminados aplicados.

Optimización del rendimiento de pod

Si tiene demandas de carga de trabajo de rendimiento específicas, puede cambiar los valores predeterminados para los parámetros sysctl del kernel de Linux en los espacios de nombres de red de pod.

Para optimizar la configuración del núcleo de los pods de aplicaciones, puedes insertar un parche initContainer en el archivo YAML pod/ds/rs/deployment de cada implementación. El initContainer se añade a cada despliegue de app que se encuentra en el espacio de nombres de red de pod para el que desea optimizar el rendimiento.

Antes de empezar, asegúrate de que dispones del rol de acceso al servicio IAM IBM Cloud de Manager para todos los espacios de nombres, a fin de poder ejecutar el ejemplo con privilegios initContainer. Después de inicializar los contenedores para los despliegues, se descartarán los privilegios.

1. Guarde el siguiente parche de initContainer en un archivo denominado pod-patch.yaml y añada los campos y los valores de los parámetros de sysctl que desea ajustar. Este initContainer de ejemplo cambia el número máximo predeterminado de conexiones permitidas en el entorno mediante el valor net.core.somaxconn y el rango de puertos efímeros a través del valor 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. Aplique un parche a cada uno de los despliegues.

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

3. Si ha cambiado el valor net.core.somaxconn en los valores de kernel, la mayoría de las apps pueden utilizar automáticamente el valor actualizado. Sin embargo, es posible que en algunas apps se deba cambiar manualmente el valor correspondiente en el código de la app para que coincida con el valor del kernel. Por ejemplo, si va a ajustar el rendimiento de un pod en el que se ejecuta una app NGINX, debe cambiar el valor del campo backlog en el código de la app NGINX para que coincida. Para obtener más información, consulta esta entrada del blog NGINX.

Optimización de los valores de sysctl de estado activo de red

Si un pod tiene conexiones TCP de larga duración que se desconectan ocasionalmente cuando están inactivas durante un periodo de tiempo, podría ayudar cambiar la configuración de sysctl keepalive para el pod.

Actualmente no hay una forma de establecer estos valores de estado activo de sysctl en todos los pods de forma predeterminada en un clúster. La mejor forma de modificar los valores en todos los pods es utilizar un initContainer privilegiado. Revise el siguiente ejemplo de cómo configurar un initContainer para un despliegue en un espacio de nombres de test-ns.

Despliegue el ejemplo siguiente initContainer. Recuerde cambiar la sección containers: a sus propios contenedores de aplicaciones. A continuación, initContainer establece los valores de sysctl para todos los contenedores normales del pod porque todos ellos comparten el mismo espacio de nombres de red.

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

Ajuste de recursos del proveedor de métricas de clúster

El clúster tiene un servicio de métricas proporcionado por el despliegue de metrics-server en el espacio de nombres de kube-system. Las solicitudes de recursos de metrics-server se basan en el número de nodos del clúster y se optimizan para clústeres con 30 o menos pods por nodo de trabajador. El servicio de métrica coincide con los límites de memoria y CPU de las solicitudes de recursos.

Los contenedores de servicio de métricas pueden "agotar la memoria" si las solicitudes de memoria son demasiado bajas. Pueden responder con mucha lentitud o no superar las pruebas de disponibilidad y estado, debido a la limitación de la CPU si las solicitudes a la CPU son demasiado bajas.

El uso de memoria está basado en el número de pods del clúster. El uso de CPU lo controla el número de solicitudes de métricas (HPA, kubectl top nodes / pods, etc.) y las solicitudes de descubrimiento de API. El metrics-server proporciona una API de Kubernetes, de forma que los clientes como kubectl que utilizan el descubrimiento de API coloquen alguna carga en metrics-server, incluso si no utilizan métricas.

Los siguientes síntomas pueden indicar la necesidad de ajustar los recursos de metrics-server:

• El metrics-server se está reiniciando con frecuencia.

• La supresión de un espacio de nombres en el espacio de nombres que está atascado en un estado Terminating y kubectl describe namespace incluye una condición que informa de un error de descubrimiento de API de métricas.

• kubectl top pods, kubectl top nodes, otros mandatos de kubectl o aplicaciones que utilizan la API de Kubernetes para registrar errores de Kubernetes tales 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 (HPA) no escalan los despliegues.

• La ejecución de kubectl get apiservices v1beta1.metrics.k8s.io da como resultado un estado 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:         us.icr.io/armada-master/metrics-server:v0.4.4
    Image ID:      us.icr.io/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

Habilitación de páginas muy grandes

Infraestructura clásica Nube privada virtual

Puedes habilitar KubernetesHugePages Planificación en clústeres que ejecutan Kubernetes versión 1.19 o posterior. El único tamaño de página admitido es de 2 MB por página, que es el tamaño predeterminado de la puerta de la característica de Kubernetes.

La planificación de páginas muy grandes es una característica beta en IBM Cloud Kubernetes Service y está sujeta a cambios.

De forma predeterminada, la CPU de los nodos trabajadores asigna RAM en trozos, o páginas, de 4 KB. Cuando la app necesita más RAM, el sistema debe seguir buscando más páginas, lo que puede ralentizar el proceso. Con páginas muy grandes, puede aumentar el tamaño de la página a 2 MB para aumentar el rendimiento de las apps que requieren mucha RAM, como las bases de datos para inteligencia artificial (IA), Internet de las cosas (IoT) o las cargas de trabajo de aprendizaje automático. Para obtener más información sobre las páginas gigantes, consulta la documentación del núcleo Linux.

Puede reiniciar el nodo trabajador y la configuración de páginas muy grandes persiste. Sin embargo, la configuración de huge pages no se mantiene en ninguna otra operación del ciclo de vida de los nodos de trabajo. Debe repetir los pasos de habilitación cada vez que actualice, vuelva a cargar sustituya o añada nodos trabajadores.

• Rol de acceso a la plataforma de Operador y rol de acceso al servicio de Gestor para el clúster en IBM Cloud IAM

Antes de empezar: Inicie una sesión en su cuenta. If applicable, target the appropriate resource group. Establezca el contexto para el clúster.

1. Cree un archivo de configuración hugepages-ds.yaml para habilitar páginas muy grandes. En el siguiente archivo YAML de ejemplo se utiliza un conjunto de daemons para ejecutar el pod en cada nodo trabajador del clúster. Puede definir la asignación de páginas muy grandes que están disponibles en el nodo trabajador mediante el parámetro vm.nr_hugepages. En este ejemplo se asignan 512 páginas a 2 MB por página, para 1 GB de RAM total asignada exclusivamente para páginas muy grandes.

   ¿Desea habilitar páginas muy grandes solo para determinados nodos trabajadores, como por ejemplo una agrupación de nodos trabajadores que utiliza para apps con gran consumo de RAM? Asigna etiquetas y marcas a tu grupo de trabajadores y, a continuación, añade reglas de afinidad al conjunto de demonios para que los pods se desplieguen únicamente en los nodos de trabajo del grupo de trabajadores que especifiques.

   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 el archivo que ha creado anteriormente.

   kubectl apply -f hugepages-ds.yaml
   

3. Verifique que los pods están en ejecución (Running).

   kubectl get pods
   

4. Reinicie el kubelet que se ejecuta en cada nodo trabajador reiniciando los nodos trabajadores. No vuelva a cargar el nodo trabajador para reiniciar el kubelet. Si se vuelve a cargar el nodo trabajador antes de que el kubelet adopte la habilitación de las páginas muy grandes, la habilitación falla.

   1. Obtenga una lista de los nodos trabajadores del clúster.

       ibmcloud ks worker ls -c CLUSTER_NAME_OR_ID
       ```
   2. Rearranque los nodos trabajadores. Puede reiniciar varios nodos de trabajo incluyendo varias `-w` opciones, pero asegúrese de dejar en funcionamiento al mismo tiempo un número suficiente de nodos de trabajo para que sus aplicaciones no sufran interrupciones.
   ```sh {: pre}
       ibmcloud ks worker reboot -c CLUSTER_NAME_OR_ID -w WORKER1_ID -w WORKER2_ID
       ```
   

5. Cree un pod de prueba hugepages-test.yaml que monte páginas muy grandes como un volumen y que utilice límites de recursos y solicitudes para establecer la cantidad de recursos de páginas muy grandes que utiliza el pod. Nota: si ha utilizado etiquetas, marcas y reglas de afinidad para habilitar páginas muy grandes solo en nodos trabajadores seleccionados, incluya estas mismas reglas en el pod de prueba.

   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 el archivo del pod que ha creado anteriormente.

   kubectl apply -f hugepages-pod.yaml
   

7. Verifique que el pod utiliza los recursos de páginas muy grandes.

   1. Compruebe que el pod se esté ejecutando (Running). El pod no se ejecuta si no hay nodos trabajadores con páginas muy grandes disponibles.

       kubectl get pods
       ```
   2. Inicie sesión en el pod.
   ```sh {: pre}
       kubectl exec -it <pod> /bin/sh
       ```
   3. Verifique que el pod puede ver los tamaños de las páginas muy grandes.
   ```sh {: pre}
       ls /sys/kernel/mm/hugepages
       ```
       Salida de ejemplo
       ```sh {: screen}
       hugepages-1048576kB  hugepages-2048kB
       ```
   

8. Opcional: Elimine el conjunto de daemons de habilitación. Tenga en cuenta que debe volver a crear el conjunto de daemons si necesita actualizar, volver a cargar, sustituir o añadir nodos trabajadores con páginas muy grandes más adelante.

   kubectl -n kube-system delete daemonset hugepages-enablement
   

9. Repita estos pasos siempre que actualice, vuelva a cargar, sustituya o añada nodos trabajadores.

Para resolver problemas de nodos trabajadores con páginas muy grandes, solo puede rearrancar el nodo trabajador. La configuración de páginas muy grandes no persiste en cualquier otra operación del ciclo de vida del nodo trabajador, como por ejemplo actualizar, volver a cargar, sustituir o añadir nodos trabajadores. Para eliminar la configuración de páginas muy grandes del clúster, puede actualizar, volver a cargar o sustituir todos los nodos trabajadores.

Cambio de la unidad máxima de transmisión (MTU) para clusters que utilizan Calico

Puede aumentar o reducir la unidad máxima de transmisión (MTU) del nodo de trabajo y del complemento Calico para cumplir con los requisitos de rendimiento de red de su entorno.

Todos los nodos trabajadores de la VPC admiten hasta 9000 MTU, y los nodos trabajadores bare metal clásicos también admiten hasta 9000 MTU. Los servidores virtuales clásicos sólo admiten la MTU estándar 1500, por lo que si su clúster tiene algún nodo trabajador de servidor virtual clásico, no aumente ni la MTU del nodo trabajador ni la de Calico.

Cambiar los valores de la unidad máxima de transmisión (MTU) puede tener resultados inesperados, especialmente en entornos de red complejos. Para evitar interrupciones en su flujo de trabajo, se recomienda encarecidamente que pruebe estos cambios en un clúster de desarrollo antes de realizar cualquier cambio en sus clústeres de producción.

Por defecto, el complemento de red Calico de su clúster IBM Cloud Kubernetes Service tiene una MTU de 1450 bytes para los clústeres Satellite y de 1480 bytes para los clústeres que no son Satellite. En la mayoría de los casos, este valor de MTU por defecto Calico es suficiente para evitar la caída y fragmentación de paquetes. Dado que la mayoría de los hosts utilizan un valor MTU de 1.500, estos valores predeterminados proporcionan a los clústeres Satellite 50 bytes adicionales para las cabeceras VXLAN y proporcionan a los clústeres Satellite satélite 20 bytes adicionales para las cabeceras IP utilizadas en parte del tráfico de red de clúster pod a pod. Tenga en cuenta que todos los nodos trabajadores del clúster deben utilizar el mismo valor de MTU Calico.

Revise los casos siguientes en los que es posible que tenga que modificar la MTU predeterminada de Calico:

• Si necesita mejorar el rendimiento de su red pod-a-pod y los nodos de su cluster son capaces de utilizar una MTU de host más alta, entonces puede incrementar tanto la MTU del host como la de Calico. Esto se denomina utilizar "tramas jumbo". La MTU típica de una trama jumbo es de 9000. En este caso, puedes configurar la interfaz de red privada del host con un valor de MTU de 9000 y la MTU de Calico con un valor ligeramente inferior -- 8950 para clusters Satellite y 8980 para clusters no Satellite. Tenga en cuenta que es posible que algunos recursos o hardware de proveedores de nube, como las máquinas virtuales Azure, no admitan tramas jumbo o sólo admitan un valor de MTU de hasta 4000.
• Si tiene una conexión VPN configurada para el clúster, algunas conexiones de VPN requieren una MTU de Calico menor que la predeterminada. Consulte con el proveedor de servicio de VPN para determinar si se necesita una MTU de Calico menor.

Antes de empezar

Si tus nodos de trabajo siguen utilizando el valor predeterminado de MTU, aumenta primero el valor de MTU de tus nodos de trabajo antes de aumentar el valor de MTU del complemento Calico. Por ejemplo, puedes aplicar el siguiente conjunto de daemons para cambiar el MTU de tus nodos de trabajo a 9000 bytes. Tenga en cuenta que los nombres de interfaz que se utilizan en el mandato ip link varían en función del tipo de los nodos trabajadores.

• Mandato de ejemplo para nodos trabajadores nativos: ip link set dev bond0 mtu 9000;ip link set dev bond1 mtu 9000;
• Ejemplo de comando Nodos trabajadores VPC: ip link set dev ens3 mtu 9000;

1. Ejecute los siguientes comandos para iniciar sesión en un nodo de trabajo del clúster y hacer ping de un nodo a otro. Como la MTU de tu nodo sólo está configurada a 1500 o 1480, se espera que este intento falle. En los pasos siguientes, puede volver a ejecutar estos comandos para verificar que los cambios se han realizado correctamente.

   1. Obtenga una lista de los nodos del clúster. Guarde los nombres y las direcciones IP de dos nodos sanos.

       kubectl get nodes -o wide
       ```
   1. Inicie sesión en uno de los nodos. Especifique el nombre del nodo.
   
   
   
   ```sh {: pre}
       kubectl debug --image=us.icr.io/armada-master/network-alpine -it node/<NODE_NAME> -- sh
       ```
   
   
   1. Ejecuta el comando para hacer ping de un nodo al otro. Especifique la dirección IP del nodo al que no hizo referencia en el paso anterior.
   ```sh {: pre}
       ping -c1 -Mdo -s 8972 <OTHER_HOST_IP>
       ```
   

2. Cambie la MTU del nodo con el siguiente daemonset de ejemplo. Este valor de MTU se aplica al tráfico de nodo a nodo. Modifique la línea - ip link set dev ens3 mtu <MTU_VALUE> para incluir su valor de MTU (el ejemplo utiliza un valor de MTU de 9000). Tenga en cuenta que también podría tener que cambiar el nombre de la interfaz ' ens3 ' si ens3 no es apropiado para sus nodos.

   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. Aplica el daemonset para cambiar el valor MTU del nodo.

     kubectl apply -f <file_name>
   

4. Vuelva a ejecutar los comandos para iniciar sesión en un nodo y hacer ping de un host a otro, utilizando un tamaño de paquete grande. Ahora que ha incrementado el valor MTU del nodo, se espera que el comando ' ping ' tenga éxito.

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

   ping -c1 -Mdo -s 8972 <OTHER_HOST_IP>
   

5. Tómese su tiempo para probar su cluster con el nuevo valor de MTU de nodo. Antes de continuar con el cambio del valor MTU de Calico, se recomienda que compruebe que sus aplicaciones siguen funcionando como se espera.

6. Ejecute el comando para actualizar los valores de MTU Calico para que el tráfico de pod a pod también pueda utilizar el MTU mayor. Para clusters Satellite Core OS, el valor MTU de Calico debe ser 50 bytes menor que el valor MTU del nodo. Para todos los demás clusters, el valor MTU Calico debe ser 20 bytes menor. Por ejemplo, si especificó 9000 para la MTU de nodo, su MTU Calico debería ser 8950 para los clusters Satellite Core OS o 8980 para todos los demás clusters.

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

   También puedes editar el recurso directamente ejecutando ' kubectl edit installation.operator.tigera.io default.

7. Aplique estos cambios a todos sus nodos reiniciando cuidadosamente todos los nodos. Asegúrese de haber probado este proceso en un clúster de desarrollo antes de continuar con este paso, ya que estos cambios podrían causar interrupciones en su carga de trabajo. Para reiniciar los nodos, se recomienda acordonar, drenar y reiniciar los nodos uno a uno.

Si está completando estos pasos en un clúster de producción, debe utilizar el mismo proceso que utiliza para actualizar o sustituir nodos de producción. Se recomienda encarecidamente que pruebe todo este proceso en un clúster de prueba antes de completar estos pasos en un clúster de producción.

Durante el proceso de reinicio, algunos pods utilizan la nueva MTU más grande y otros pods siguen teniendo la MTU original, más pequeña. Normalmente, este escenario no causa problemas porque ambos lados negocian el tamaño máximo correcto de los paquetes. Sin embargo, si bloquea los paquetes ICMP, es posible que la negociación no funcione y que su clúster experimente problemas de conexión de pods hasta que se hayan completado todos los reinicios. Es fundamental que este proceso se pruebe primero en un clúster de desarrollo.

Desactivación del complemento de mapa de puertos en Calico

El plugin portmap correspondiente a la interfaz de red de contenedor (CNI) de Calico le permite utilizar un hostPort para exponer los pods de su app en un puerto determinado en el nodo trabajador. Para evitar problemas de rendimiento de iptables, elimine el plugin de correlación de puertos de la configuración de CNI de Calico del clúster.

Cuando tiene muchos servicios en el clúster, por ejemplo, más de 500 servicios, o muchos puertos en los servicios, por ejemplo, más de 50 puertos por servicio para 10 o más servicios, se generan muchas reglas iptables para las políticas de red de Calico y Kubernetes de estos servicios. El uso de muchas reglas de iptables puede provocar problemas de rendimiento en el complemento de asignación de puertos y podría impedir futuras actualizaciones de las reglas de iptables o provocar que el contenedor calico-node se reinicie si no se recibe un bloqueo para realizar las actualizaciones de las reglas de iptables dentro de un plazo determinado. Para evitar estos problemas de rendimiento, puede inhabilitar el plugin de correlación de puertos eliminándolo de la configuración de CNI de Calico del clúster.

Si debe utilizar hostPorts, no inhabilite el plugin de correlación de puertos.

1. Edite el recurso de instalación de Calico default.

   kubectl edit installation default -n calico-system
   

2. En la sección spec.calicoNetwork, cambie el valor de hostPorts por 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. Guarde y cierre el archivo. Los cambios se aplican automáticamente.