Container Service for Kubernetes:Colocate an online service with a video transcoding application

Contexte

La colocalisation de workloads en ligne et hors ligne sur le même nœud est judicieuse car leurs besoins en ressources sont complémentaires : les services en ligne présentent une charge variable et consomment les ressources par à-coups, tandis que les travaux par lots hors ligne s'exécutent en continu et peuvent tolérer une priorité de ressource plus faible.

ack-koordinator utilise des classes de qualité de service (QoS) pour gérer la priorité des ressources entre les workloads colocalisés. Les deux classes utilisées dans cette rubrique sont :

Fonctionnement

Dans cette rubrique, un service NGINX (classe QoS LS) et une application de transcodage vidéo FFmpeg (classe QoS BE) s'exécutent sur le même nœud. Deux fonctionnalités de colocalisation travaillent conjointement pour protéger les performances de NGINX :

• Réutilisation des ressources : les workloads BE peuvent utiliser les ressources allouées aux workloads LS mais actuellement inactives, améliorant ainsi l'utilisation des ressources du cluster. Pour plus d'informations, consultez Dynamic resource overcommitment.

• Isolation des ressources : divers mécanismes limitent l'utilisation des ressources par les workloads BE et donnent la priorité à la demande de ressources des workloads LS. Pour plus d'informations, consultez CPU QoS, CPU Suppress et Resource isolation based on the L3 cache and MBA.

Cette rubrique déploie les applications selon trois modes et compare les résultats :

Prérequis

Avant de commencer, assurez-vous de disposer des éléments suivants :

• Un cluster ACK Pro avec deux nœuds :

  • Nœud 1 (machine de test) : exécute le service NGINX et l'application FFmpeg. Pour des performances de colocalisation optimales, utilisez une instance Bare Metal Elastic Compute Service (ECS) avec Alibaba Cloud Linux comme système d'exploitation.

  • Nœud 2 (machine de test de charge) : exécute l'outil de test de charge wrk et envoie des requêtes au service NGINX.

  • Pour les étapes de création du cluster, consultez Create an ACK Pro cluster.

• ack-koordinator (anciennement ack-slo-manager) installé avec les politiques de colocalisation activées. Consultez Getting started. Cette rubrique utilise ack-koordinator 0.8.0.

La fonctionnalité CPU QoS nécessite Alibaba Cloud Linux comme système d'exploitation du nœud. L'isolation des ressources basée sur le cache L3 et MBA nécessite une instance ECS Bare Metal.

Déployer le service NGINX et wrk

Déployez le service NGINX sur la machine de test et l'outil de test de charge wrk sur la machine de test de charge.

wget -O wrk-4.2.0.tar.gz https://github.com/wg/wrk/archive/refs/tags/4.2.0.tar.gz && tar -xvf wrk-4.2.0.tar.gz
cd wrk-4.2.0 && make && chmod +x ./wrk

Déployer l'application FFmpeg

Déployez l'application hors ligne de transcodage vidéo FFmpeg sur la machine de test. La configuration YAML diffère légèrement entre le mode de colocalisation Kubernetes par défaut et le mode de colocalisation sensible aux SLO ; les commentaires pertinents dans le fichier expliquent chaque différence.

1. Créez un fichier nommé be-ffmpeg.yaml avec le contenu suivant :

   Afficher le contenu du fichier YAML

   # Pod for the offline FFmpeg video transcoding application (BE QoS class)
   apiVersion: v1
   kind: Pod
   metadata:
     name: be-ffmpeg
     labels:
       app: ffmpeg
     # Default Kubernetes colocation mode: remove the koordinator.sh/qosClass: BE label.
     # SLO-aware colocation mode: keep the koordinator.sh/qosClass: BE label.
       koordinator.sh/qosClass: BE
   spec:
     containers:
       # Increase the process count to control CPU utilization of the transcoding application.
       # Default: 25 processes, each with 2 parallel threads.
       - command:
           - start-ffmpeg.sh
           - '25'
           - '2'
           - /apps/ffmpeg/input/HD2-h264.ts
           - /apps/ffmpeg/
         image: 'registry.cn-zhangjiakou.aliyuncs.com/acs/ffmpeg-4-4-1-for-slo-test:v0.1'
         imagePullPolicy: Always
         name: ffmpeg
         resources:
         # Default Kubernetes colocation mode: remove the kubernetes.io/batch-cpu and
         # kubernetes.io/batch-memory extended resources.
         # SLO-aware colocation mode: keep them, sized to your node's resource spec.
           limits:
             kubernetes.io/batch-cpu: 70k
             kubernetes.io/batch-memory: 22Gi
           requests:
             kubernetes.io/batch-cpu: 70k
             kubernetes.io/batch-memory: 22Gi
     hostNetwork: true
     restartPolicy: Never
     nodeName: cn-beijing.192.168.2.93  # Replace with the node name of your tested machine.

2. Déployez l'application FFmpeg :

   kubectl apply -f be-ffmpeg.yaml

3. Vérifiez que le pod est en cours d'exécution :

   kubectl get pod -l app=ffmpeg -o wide

   Sortie attendue :

   NAME        READY   STATUS    RESTARTS   AGE    IP               NODE                      NOMINATED NODE   READINESS GATES
   be-ffmpeg   1/1     Running   0          15s    11.162.XXX.XXX   cn-beijing.192.168.2.93   <none>           <none>

Exécuter les tests de charge

Exécutez des tests dans chaque mode de colocalisation et comparez les résultats. Les métriques clés sont :

• Percentiles du temps de réponse (RT) : RT-P90 correspond au temps maximal pour traiter 90 % des requêtes ; RT-P99 couvre 99 % des requêtes. Des valeurs plus faibles indiquent de meilleures performances NGINX.

• Utilisation moyenne du processeur : mesurée avec kubectl top node.

Résultats des tests

Le tableau suivant compare le temps de réponse NGINX et l'utilisation du processeur du nœud dans les trois modes.

Observations clés :

• Colocalisation Kubernetes par défaut par rapport à la référence : l'utilisation du processeur augmente de 29,6 % à 65,1 %, mais le RT-P90 de NGINX augmente de 7,7 % et le RT-P99 de 16 %. La distribution de la latence présente une longue traîne.

• Colocalisation sensible aux SLO par rapport à la référence : l'utilisation du processeur augmente de 29,6 % à 64,8 %, tandis que le RT-P90 n'augmente que de 2,8 % et le RT-P99 que de 3,2 %.

• Colocalisation sensible aux SLO par rapport à la colocalisation Kubernetes par défaut : l'utilisation du processeur est similaire (~65 %), mais les temps de réponse NGINX sont nettement inférieurs et proches de la référence de déploiement exclusif.

La colocalisation sensible aux SLO permet d'obtenir à peu près la même amélioration de l'utilisation du processeur que la colocalisation standard, tout en maintenant la latence NGINX beaucoup plus proche de la référence sans colocalisation.

FAQ

Étapes suivantes

• Dynamic resource overcommitment

• CPU QoS for containers

• CPU Suppress

• CPU Burst

• Memory QoS for containers

• Resource isolation based on the L3 cache and MBA