Ajuste del rendimiento

Valores predeterminados del nodo trabajador

Por defecto, los nodos de trabajo tienen el sistema operativo y el hardware informático del tipo de nodo de trabajo que elijas al crear el grupo de trabajadores.

Modificación de la configuración del núcleo del nodo trabajador 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 cambia la configuración de la configuración del núcleo, asegúrese de documentar y guardar los cambios exactos que realice. 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 produzcan antes de que se programen otros pods en el nodo trabajador. Los pods no se ven afectados.

Debe tener el rol de acceso al servicio Manager IBM Cloud IAM para todos los espacios de nombres para ejecutar el ejemplo privilegiado 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 revertir los parámetros de sus nodos de trabajo sysctl a los valores por defecto, siga 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 kernel para los pods de aplicaciones, puede insertar un parche initContainer en el YAML de pod/ds/rs/deployment para cada despliegue. 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úrese de que dispone de la función de acceso al servicio IAM Manager IBM Cloud para todos los espacios de nombres en los que se ejecutará el ejemplo de initContainer con privilegios. 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 más información, consulte esta entrada del blog de NGINX.

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

Si un pod tiene conexiones TCP de larga ejecución que se desconectan ocasionalmente cuando están desocupadas durante un periodo de tiempo, puede ayudar a cambiar los valores de estado activo de sysctl 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.

```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
```

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. Es posible que respondan muy lentamente o que fallen las sondas de liveness y readiness, debido al estrangulamiento de la CPU si las peticiones de 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:         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

Habilitación de páginas muy grandes

Infraestructura clásica Virtual Private Cloud

Puede activar la programación de Kubernetes HugePages en clusters que ejecuten 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 más información sobre páginas enormes, consulte la documentación del kernel Linux.

Puede reiniciar el nodo trabajador y la configuración de páginas muy grandes persiste. Sin embargo, la configuración de páginas enormes no persiste en ninguna otra operación del ciclo de vida del nodo trabajador. 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? Etiquete y manche su grupo de trabajadores y, a continuación, añada reglas de afinidad al conjunto de demonios para que los pods se desplieguen únicamente en los nodos de trabajadores del grupo de trabajadores que especifique.

   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. Puedes reiniciar múltiples nodos trabajadores incluyendo múltiples opciones -w, pero asegúrate de dejar suficientes nodos trabajadores funcionando al mismo tiempo para que tus aplicaciones eviten una interrupción.

      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.

      kubectl exec -it <pod> /bin/sh
      

   3. Verifique que el pod puede ver los tamaños de las páginas muy grandes.

      ls /sys/kernel/mm/hugepages
      

      Salida de ejemplo

      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.

Modificación de la unidad máxima de transmisión (MTU) de Calico

Aumente o reduzca la unidad máxima de transmisión (MTU) del plugin de Calico para que se ajuste a los requisitos de rendimiento de red del entorno.

Estos pasos son aplicables a los clusters que ejecutan la versión 1.29 o posterior. Además, todos los nodos trabajadores de la VPC admiten tramas Jumbo, pero la infraestructura clásica sólo admite tramas Jumbo en los trabajadores bare metal.

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 sus nodos de trabajo siguen ejecutando el valor MTU predeterminado, aumente primero el valor MTU para sus nodos de trabajo antes de aumentar el valor MTU para el complemento Calico. Por ejemplo, puedes aplicar el siguiente daemon set para cambiar la MTU de tus nodos trabajadores 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 nodos trabajadores de VPC Gen 2: 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
      

   2. Inicie sesión en uno de los nodos. Especifique el nombre del nodo.

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

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

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

Inhabilitación del plugin de correlación de puertos

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 iptables puede provocar problemas de rendimiento para el complemento de mapa de puertos, y podría impedir futuras actualizaciones de reglas iptables o hacer que el contenedor calico-node se reinicie cuando no se reciba ningún bloqueo para realizar actualizaciones de reglas iptables en un tiempo 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.