Getting started - Container Service for Kubernetes - Centre de documentation Alibaba Cloud

Prérequis

Assurez-vous de disposer des éléments suivants :

Un cluster ACK Pro
ack-koordinator version 0.8.0 ou ultérieure installée (anciennement ack-slo-manager)
(Recommandé) Des instances ECS Bare Metal exécutant Alibaba Cloud Linux

Concepts clés

ack-koordinator utilise la priorité des ressources et la classe QoS pour contrôler le partage des nœuds entre les charges de travail en ligne et hors ligne.

Priorités des ressources

La priorité des ressources détermine la part de capacité du nœud qu'une charge de travail peut utiliser.

Priorité	Calcul des ressources	Nom de la ressource
Product	Équivalent aux ressources physiques du nœud	CPU et mémoire signalés par le nœud
Batch	Calcul dynamique : ressources physiques totales − ressources Product utilisées. Consultez la rubrique Surcommitment dynamique des ressources.	`kubernetes.io/batch-cpu` et `kubernetes.io/batch-memory` (ressources étendues dans les métadonnées du nœud)

Les ressources Product allouées mais inutilisées sont automatiquement rétrogradées vers le niveau Batch pour récupération.

Classes QoS

La classe QoS détermine la priorité de planification et le niveau d'isolation en cas de pénurie de ressources.

Classe QoS	Charges de travail typiques	Comportement
LS (Latency Sensitive)	Services web, microservices, calcul de flux sensible à la latence	Priorité élevée pour la planification du CPU, le cache L3 et la bande passante mémoire ; la mémoire est récupérée en priorité sur les charges BE
BE (Best Effort)	Jobs Spark par lots, jobs MapReduce, jobs d'entraînement IA, transcodage vidéo	Priorité CPU inférieure à celle des charges LS ; cache L3 et bande passante mémoire limités ; la mémoire est récupérée avant celle des charges LS

Fonctionnement de la récupération des ressources

Node capacity
├── Product limit      ← Resources requested by LS pods
│   └── Actual usage  ← Varies over time (often well below limit)
│       └── Reclaimable = limit − usage ← Available for BE pods
└── BE pods run on reclaimable resources

Les charges de travail BE consomment les ressources autrement inactives sans affecter les performances des services en ligne.

Combinaisons valides

La priorité des ressources et la classe QoS sont indépendantes, mais seules deux combinaisons sont utilisées en pratique :

Product + LS : Applications en ligne sensibles à la latence (applications web, calcul de flux)
Batch + BE : Applications hors ligne de priorité inférieure (jobs Spark, jobs MapReduce, entraînement IA)

Activer les politiques de colocalisation

ack-koordinator lit les politiques de colocalisation depuis la ConfigMap ack-slo-config dans le namespace kube-system.

Créez le fichier configmap.yaml avec le contenu suivant :

# Example of the ack-slo-config ConfigMap.
apiVersion: v1
kind: ConfigMap
metadata:
  name: ack-slo-config
  namespace: kube-system
data:
  colocation-config: |-
    {
      "enable": true
    }
  resource-qos-config: |-
    {
      "clusterStrategy": {
        "lsClass": {
          "cpuQOS": {
            "enable": true
          },
          "memoryQOS": {
            "enable": true
          },
          "resctrlQOS": {
            "enable": true
          }
        },
        "beClass": {
          "cpuQOS": {
            "enable": true
          },
          "memoryQOS": {
            "enable": true
          },
          "resctrlQOS": {
            "enable": true
          }
        }
      }
    }
  resource-threshold-config: |-
    {
      "clusterStrategy": {
        "enable": true
      }
    }

La ConfigMap inclut trois politiques :

Clé de politique	Fonction
`colocation-config`	Active la surveillance en temps réel de la charge des nœuds et identifie les ressources susceptibles d'être surcommittées. Consultez la rubrique Surcommitment dynamique des ressources.
`resource-qos-config`	Active la gestion fine des ressources pour les charges de travail LS et BE, y compris la QoS CPU, la QoS mémoire et l'isolation du cache L3 et MBA.
`resource-threshold-config`	Limite dynamiquement les ressources BE en fonction des seuils d'utilisation des nœuds. Consultez la rubrique Limite élastique des ressources.

Appliquez la ConfigMap :
```
kubectl apply -f configmap.yaml
```

Déployer des charges de travail

Déployez une charge de travail LS (en ligne) et une charge de travail BE (hors ligne) sur le même nœud en utilisant le label de pod koordinator.sh/qosClass.

Déployer la charge de travail LS (NGINX)

Créez le fichier nginx-ls-pod.yaml. Le label koordinator.sh/qosClass: LS indique que ce pod est sensible à la latence :

---
# Nginx application configuration
apiVersion: v1
data:
  config: |-
    user  nginx;
    worker_processes  80;  # The number of Nginx worker processes, which affects concurrency.

    events {
        worker_connections  1024;  # Default value is 1024.
    }

    http {
        server {
            listen  8000;

            gzip off;
            gzip_min_length 32;
            gzip_http_version 1.0;
            gzip_comp_level 3;
            gzip_types *;
        }
    }

    #daemon off;
kind: ConfigMap
metadata:
  name: nginx-conf

---
# Manifest for the nginx-ls-pod.
apiVersion: v1
kind: Pod
metadata:
  labels:
    koordinator.sh/qosClass: LS
    app: nginx
  name: nginx
spec:
  containers:
    - image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
      imagePullPolicy: IfNotPresent
      name: nginx
      ports:
        - containerPort: 8000
          hostPort: 8000 # The host port that will receive requests for load testing.
          protocol: TCP
      resources:
        limits:
          cpu: '8'
          memory: 1Gi
        requests:
          cpu: '8'
          memory: 1Gi
      volumeMounts:
        - mountPath: /apps/nginx/conf
          name: config
  hostNetwork: true
  restartPolicy: Never
  volumes:
    - configMap:
        items:
          - key: config
            path: nginx.conf
        name: nginx-conf
      name: config

Appliquez le manifeste :
```
kubectl apply -f nginx-ls-pod.yaml
```

Déployer la charge de travail BE (FFmpeg)

Créez le fichier ffmpeg-be-pod.yaml. Le label koordinator.sh/qosClass: BE indique que ce pod fonctionne en mode best-effort. Les limites de ressources utilisent kubernetes.io/batch-cpu et kubernetes.io/batch-memory au lieu des ressources CPU et mémoire standard :

apiVersion: v1
kind: Pod
metadata:
  labels:
    koordinator.sh/qosClass: BE
  name: be-ffmpeg
spec:
  containers:
    - command:
        - start-ffmpeg.sh
        - '30'
        - '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:
        limits:
          # Unit: millicores.
          kubernetes.io/batch-cpu: "70k"
          kubernetes.io/batch-memory: "22Gi"
        requests:
          # Unit: millicores.
          kubernetes.io/batch-cpu: "70k"
          kubernetes.io/batch-memory: "22Gi"

Appliquez le manifeste :
```
kubectl apply -f ffmpeg-be-pod.yaml
```

Étapes suivantes

Une fois les deux pods en cours d'exécution, explorez les fonctionnalités de colocalisation d'ACK :

Voir en action

Colocaliser des services en ligne et des applications de transcodage vidéo — un exemple de bout en bout utilisant cette configuration

Gestion des ressources

Contrôle du CPU