Como ejecutar vuestra solución de InterSystems en un entorno de Kubernetes con garantía de calidad de servicio

Todos los pods reciben una asignación de Calidad de Servicio (QoS). Existen tres niveles de prioridad dentro de un nodo:

1. Guaranteed: Alta prioridad
2. Burstable: Prioridad media
3. BestEffort: Baja prioridad

Es una forma de indicar al kubelet cuáles son vuestras prioridades en un nodo si es necesario recuperar recursos. Este fantástico GIF de Anvesh Muppeda lo explica.

Si es necesario liberar recursos, primero se expulsarán los pods con QoS BestEffort, luego los Burstable y, por último, los Guaranteed. La idea es que, al eliminar los pods de menor prioridad, se recuperen suficientes recursos en el nodo para evitar la expulsión de los pods Guaranteed.

Por ello, queremos que nuestras aplicaciones críticas se ejecuten con Guaranteed Quality of Service, y los pods de InterSystems definitivamente entran en esta categoría.

Consultad la aplicación de Open Exchange o el repositorio de GitHub adjunto para encontrar una plantilla que os ayude a actualizar vuestro IrisCluster y garantizar QoS Guaranteed para todos los pods de InterSystems.

Hasta ahora, es posible que hayáis estado desplegando mediante recursos específicos en el podTemplate:

podTemplate:
  spec:
    resources:
      requests:
        memory: "8Gi"
        cpu: "2"
      limits:
        memory: "8Gi"
        cpu: "2"

Pero, suponiendo que estáis utilizando lo siguiente en vuestro archivo values.yaml de IKO (este es el comportamiento predeterminado):

useIrisFsGroup: false 

Entonces, estaréis ignorando los initContainers y cualquier posible side-car, lo que hará que vuestro pod tenga únicamente Burstable QoS.

Según la documentación de Kubernetes sobre QoS:
Para que un pod reciba la clase de QoS Guaranteed, deben cumplirse las siguientes condiciones:

• Cada contenedor dentro del pod debe tener un límite de memoria y una solicitud de memoria.
• Para cada contenedor, el límite de memoria debe ser igual a la solicitud de memoria.
• Cada contenedor dentro del pod debe tener un límite de CPU y una solicitud de CPU.
• Para cada contenedor, el límite de CPU debe ser igual a la solicitud de CPU.

Esto incluye tanto los initContainers como los side-cars. Para especificar los recursos del initContainer, debéis sobrescribirlo:

      podTemplate:
        spec:
          initContainers:
          - command:
            - sh
            - -c
            - /bin/chown -R 51773:51773 /irissys/*
            image: busybox
            name: iriscluster-init
            resources:
              requests:
                memory: "8Gi"
                cpu: "2"
              limits:
                memory: "8Gi"
                cpu: "2"
            securityContext:
              runAsGroup: 0
              runAsNonRoot: false
              runAsUser: 0
            volumeMounts:
            - mountPath: /irissys/data/
              name: iris-data
            - mountPath: /irissys/wij/
              name: iris-wij
            - mountPath: /irissys/journal1/
              name: iris-journal1
            - mountPath: /irissys/journal2/
              name: iris-journal2
          resources:
            requests:
              memory: "8Gi"
              cpu: "2"
            limits:
              memory: "8Gi"
              cpu: "2"

Consultad un ejemplo completo de IrisCluster, incluyendo initContainers y side-cars, en la aplicación de Open Exchange adjunta.

Como alternativa, podéis considerar cambiar el comportamiento predeterminado de IKO en el archivo values.yaml a:

useIrisFsGroup: true 

para evitar initContainers en algunos escenarios, aunque pueden surgir complicaciones. Además, useIrisFsGroup realmente merece un artículo propio. Planeo escribir sobre ello próximamente.