Container Service for Kubernetes:Get started with workload colocation

Prioridades de recursos

A prioridade de recursos define quanto da capacidade do nó um workload pode usar.

Recursos Product alocados, mas não utilizados, são automaticamente rebaixados para Batch para recuperação.

Classes de QoS

A classe de QoS determina a prioridade de agendamento e o isolamento quando os recursos estão restritos.

Funcionamento da recuperação de recursos

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

Os workloads BE consomem recursos que estariam ociosos, sem afetar o desempenho dos serviços online.

Combinações válidas

Embora a prioridade de recursos e a classe de QoS sejam independentes, apenas duas combinações são usadas na prática:

• Product + LS: Aplicações online sensíveis a latência (aplicações web, computação de fluxo)

• Batch + BE: Aplicações offline de menor prioridade (jobs Spark, jobs MapReduce, treinamento de IA)

Implante o workload LS (NGINX)

1. Crie o arquivo nginx-ls-pod.yaml. O rótulo koordinator.sh/qosClass: LS classifica este pod como sensível a latência:

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

2. Aplique o manifesto:

   kubectl apply -f nginx-ls-pod.yaml

Implante o workload BE (FFmpeg)

1. Crie o arquivo ffmpeg-be-pod.yaml. O rótulo koordinator.sh/qosClass: BE classifica este pod como best-effort. Os limites de recursos usam kubernetes.io/batch-cpu e kubernetes.io/batch-memory em vez de CPU e memória padrão:

   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"

2. Aplique o manifesto:

   kubectl apply -f ffmpeg-be-pod.yaml