Exécutez votre solution InterSystems dans votre environnement Kubernetes avec une qualité de service garantie

Une qualité de service (QoS) est attribuée à tous les pods. Trois niveaux de priorité sont attribués aux pods d'un nœud. Ces niveaux sont les suivants :

1) Garanti : Priorité élevée

2) Évolutif : Priorité moyenne

3) Meilleur effort : Priorité faible

Il s'agit d'indiquer au kubelet quelles sont vos priorités sur un nœud donné si des ressources doivent être récupérées. Ce superbe GIF d'Anvesh Muppeda ci-dessous l'explique.

Si des ressources doivent être libérées, les pods avec une QoS « Meilleur effort » seront d'abord évincés, puis ceux avec une QoS « Évolutif », et enfin ceux avec une QoS garantie. L'idée est qu'en évinçant les pods de priorité inférieure, nous récupérerons suffisamment de ressources sur le nœud pour éviter d'avoir à évincer les pods avec une QoS garantie.

Nous souhaitons donc que nos applications critiques fonctionnent avec une qualité de service garantie, et les pods InterSystems en font sans aucun doute partie.

Consultez Open Exchange Application / Github Repo ci-joint pour obtenir un modèle expliquant comment mettre à niveau votre cluster IrisCluster afin de bénéficier d'une qualité de service garantie pour tous vos pods InterSystems.

Jusqu'à présent, vous avez peut-être déployé en spécifiant les ressources dans le podTemplate :

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

mais en supposant que vous utilisez les éléments suivants dans votre fichier IKO values.yaml (c'est le comportement par défaut) :

useIrisFsGroup: false 

Vous ignorez alors les initContainers et un éventuel side-car, et votre pod ne bénéficiera que d'une QoS évolutive.

Conformément à la documentation Kubernetes sur la QoS, pour qu'un pod obtienne une classe de QoS garantie :

• Chaque conteneur du pod doit avoir une limite de mémoire et une demande de mémoire.
• Pour chaque conteneur du pod, la limite de mémoire doit être égale à la demande de mémoire.
• Chaque conteneur du pod doit avoir une limite de CPU et une demande de CPU.
• Pour chaque conteneur du pod, la limite de CPU doit être égale à la demande de CPU.

Cela inclut les initContainers et les side-cars. Pour spécifier les ressources de l'initContainer, vous devez le remplacer :

      podTemplate:
        spec:
          initContainers:
          - command:
            - sh
            - -c
            - /bin/chown -R 51773:51773 /irissys/*
            image: busybox
            name: iriscluster-init
            resources:
              requests:
                memory: "1Gi"
                cpu: "1"
              limits:
                memory: "1Gi"
                cpu: "1"
            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"

Consultez un exemple complet d'IrisCluster incluant initContainers et side-cars dans l'application Open Exchange ci-jointe.

Vous pouvez également modifier le comportement par défaut d'IKO dans values.yaml comme suit :

useIrisFsGroup: true 

pour éviter les initContainers dans certains cas, mais des complications peuvent survenir et useIrisFsGroup mériterait un article à part entière. Je compte en parler prochainement.