Ajuste del rendimiento

Si tiene requisitos de optimización de rendimiento específicos, puede cambiar los valores predeterminados para algunos componentes de clúster en Red Hat® OpenShift® on IBM Cloud®.

Si decide cambiar los valores predeterminados, lo hace por su cuenta y riesgo. Usted es el responsable de ejecutar pruebas en cualquier configuración modificada y de cualquier interrupción potencial ocasionada por los valores modificados en el entorno.

En lugar de ajustar el rendimiento del nodo de trabajo con MachineConfig archivos en Red Hat OpenShift, puede modificar el host con un daemonset archivo. Para obtener más información, consulte Cambiar la Calico MTU o Ajustar el rendimiento de los Red HatCoreOS nodos de trabajo.

Valores predeterminados del nodo trabajador

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

Personalización del sistema operativo

Puede encontrar una lista de los sistemas operativos compatibles por versión de clúster en la Red Hat OpenShift on IBM Cloud información de la versión. El clúster no puede mezclar sistemas operativos ni utilizar sistemas operativos diferentes.

Para optimizar los nodos trabajadores, tenga en cuenta la siguiente información.

  • Actualizaciones de imagen y versión: las actualizaciones de nodos trabajadores, como los parches de seguridad para la imagen o versiones de Red Hat OpenShift los proporciona IBM. Sin embargo, debe elegir cuándo aplicar las actualizaciones a los nodos trabajadores. Para obtener más información, consulte Actualización de clústeres, nodos trabajadores y componentes de clúster.
  • Modificaciones temporales: si inicia una sesión en un pod o si utiliza algún otro proceso para modificar un valor de nodo trabajador, las modificaciones son temporales. Las operaciones del ciclo de vida del nodo trabajador, como la recuperación automática, la recarga, la actualización o la sustitución de un nodo trabajador, cambian las modificaciones a los valores predeterminados.
  • Modificaciones persistentes: Para que las modificaciones se mantengan durante las operaciones del ciclo de vida de los nodos de trabajo, crea un conjunto de demonios que utilice un contenedor « init ». Para obtener más información, consulte Modificación de los valores predeterminados del nodo trabajador para optimizar el rendimiento.

No se da soporte a las modificaciones en el sistema operativo. Si modifica los valores predeterminados, es responsable de depurar y resolver los problemas que se pueden producir.

Cambios en el hardware

Para cambiar el hardware de cálculo, como por ejemplo la CPU y la memoria por nodo trabajador, elija entre las opciones siguientes.

Modificación de la configuración del núcleo 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 » garantiza 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 « IBM Cloud »(Administrador ) para todos los espacios de nombres a fin de poder ejecutar el ejemplo « initContainer » (Acceso con privilegios). Después de inicializar los contenedores para los despliegues, se descartarán los privilegios.

Antes de empezar: acceda al clúster de Red Hat OpenShift.

  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.

    En función de los valores de systctl que intenta cambiar, es posible que desee configurar el contexto de seguridad. Para obtener más información, consulta la documentación de 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 el conjunto de daemons a los nodos trabajadores. Los cambios se aplican inmediatamente.

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

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

  1. Suprima el conjunto de daemons. Se eliminan los initContainers que han aplicado los valores personalizados.
    oc 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 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.

Permitir initContainers privilegiado en el espacio de nombres test-ns:

oc adm policy add-scc-to-group privileged system:serviceaccounts: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

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

Puedes aumentar o reducir la unidad máxima de transmisión (MTU) del nodo de trabajo y del complemento « Calico » para adaptarte a los requisitos de rendimiento de red de tu 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 Red Hat OpenShift on IBM Cloud tiene una MTU de 1450 bytes para los clústeres Satellite y de 1480 bytes para los clústeres no 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. Ten en cuenta que todos los nodos trabajadores del cluster 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 mayor, 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.
        oc get nodes -o wide
    ```
1. Inicie sesión en uno de los nodos. Especifique el nombre del nodo.


```sh {: pre}
    oc debug node/<NODE_NAME>
    ```



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.

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

    oc debug node/<NODE_NAME>

    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.

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

    También puedes editar el recurso directamente ejecutando ' oc 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 un gran número de reglas de iptables puede provocar problemas de rendimiento en el complemento «port map» y podría impedir futuras actualizaciones de las reglas de iptables o provocar que el contenedor « calico-node » se reinicie si no se recibe ningún 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.

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