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 trabajador con los archivos MachineConfig en Red Hat OpenShift, puede modificar el host con un archivo daemonset. Para obtener más información, consulte Modificación de la MTU Calico o Ajuste del rendimiento para nodos trabajadores Red Hat CoreOS.

Valores predeterminados del nodo trabajador

Por defecto, los nodos de los trabajadores tienen el sistema operativo y el hardware de computación del tipo de nodo de trabajador que elijas al crear el grupo de trabajadores.

Personalización del sistema operativo

Puede encontrar una lista de sistemas operativos soportados por versión de clúster en la información de versión deRed Hat OpenShift on IBM Cloud. 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 persistan a lo largo de las operaciones del ciclo de vida del nodo trabajador, 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.

Cree una agrupación de nodos trabajadores. Las instrucciones varían en función del tipo de infraestructura del clúster, como clásica, VPC o Satellite. Para obtener más información, consulte Adición de nodos trabajadores a clústeres clásicos o Adición de nodos trabajadores a clústeres de VPC.
Actualice el tipo en el clúster creando una agrupación de nodos trabajadores y eliminando la agrupación de nodos trabajadores anterior.

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: acceda al clúster de Red Hat OpenShift.

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, consulte la documentación deRed 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

Aplique el conjunto de daemons a los nodos trabajadores. Los cambios se aplican inmediatamente.
```
oc 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.

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

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

```sh {: pre}
oc adm policy add-scc-to-groupl 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.

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

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.

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

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
```
2. Inicie sesión en uno de los nodos. Especifique el nombre del nodo.
```
oc debug node/<NODE_NAME>
```
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>
```

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

Aplica el daemonset para cambiar el valor MTU del nodo.
```
  oc apply -f <file_name>
```
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>
```
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.
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.
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.

Edite el recurso de instalación de Calico default.
```
oc edit installation default -n calico-system
```

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: registry.ng.bluemix.net/armada-master/
  variant: Calico
status:
  variant: Calico

Guarde y cierre el archivo. Los cambios se aplican automáticamente.