Container Service for Kubernetes:Enable container memory QoS

Ventajas frente al QoS de memoria de Kubernetes de código abierto

La función memory QoS de Kubernetes upstream (Kubernetes 1.22+) solo admite cgroup v2, requiere configuración manual de kubelet y carece de granularidad por pod o por namespace.

ack-koordinator mejora la implementación upstream en dos aspectos:

• Mayor compatibilidad con el kernel: Admite cgroup v1 y v2, respaldado por funciones del kernel de Alinux como la recuperación asíncrona de backend de memcg y la clasificación de marca de agua mínima. Consulte Overview of kernel features and interfaces.

• Configuración detallada: Configure el QoS de memoria por pod, namespace o clúster mediante anotaciones de pod o ConfigMaps.

Mecanismo de configuración

ack-koordinator utiliza cuatro parámetros de cgroup para el QoS de memoria. Cada uno se asigna a opciones de configuración en Advanced parameters:

Prioridad de configuración

Cuando varias fuentes de configuración aplican al mismo pod, ack-koordinator utiliza el siguiente orden de prioridad (de mayor a menor):

1. Anotación de pod (koordinator.sh/memoryQOS)

2. ConfigMap a nivel de namespace (ack-slo-pod-config)

3. ConfigMap a nivel de clúster (ack-slo-config)

Asignación de clases de QoS

Si un pod no tiene la etiqueta koordinator.sh/qosClass, ack-koordinator asigna automáticamente las clases de QoS de Kubernetes:

Ejecutar la prueba

1. Cree el archivo redis-demo.yaml:

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: redis-demo-config
   data:
     redis-config: |
       appendonly yes
       appendfsync no
   ---
   apiVersion: v1
   kind: Pod
   metadata:
     name: redis-demo
     labels:
       koordinator.sh/qosClass: 'LS'
     annotations:
       koordinator.sh/memoryQOS: '{"policy": "auto"}'
   spec:
     containers:
     - name: redis
       image: redis:5.0.4
       command:
         - redis-server
         - "/redis-master/redis.conf"
       env:
       - name: MASTER
         value: "true"
       ports:
       - containerPort: 6379
       resources:
         limits:
           cpu: "2"
           memory: "6Gi"
         requests:
           cpu: "2"
           memory: "2Gi"
       volumeMounts:
       - mountPath: /redis-master-data
         name: data
       - mountPath: /redis-master
         name: config
     volumes:
       - name: data
         emptyDir: {}
       - name: config
         configMap:
           name: redis-demo-config
           items:
           - key: redis-config
             path: redis.conf
     nodeName: # Set to the name of the node running Redis.
   ---
   apiVersion: v1
   kind: Service
   metadata:
     name: redis-demo
   spec:
     ports:
     - name: redis-port
       port: 6379
       protocol: TCP
       targetPort: 6379
     selector:
       name: redis-demo
     type: ClusterIP

2. Despliegue Redis:

   kubectl apply -f redis-demo.yaml

3. Simule el sobrecompromiso de memoria con la herramienta Stress. Cree el archivo stress-demo.yaml:

   apiVersion: v1
   kind: Pod
   metadata:
     name: stress-demo
     labels:
       koordinator.sh/qosClass: 'BE'
     annotations:
       koordinator.sh/memoryQOS: '{"policy": "auto"}'
   spec:
     containers:
       - args:
           - '--vm'
           - '2'
           - '--vm-bytes'
           - 11G
           - '-c'
           - '2'
           - '--vm-hang'
           - '2'
         command:
           - stress
         image: polinux/stress
         imagePullPolicy: Always
         name: stress
     restartPolicy: Always
     nodeName: # Set to the same node as redis-demo.

4. Despliegue la carga de trabajo de estrés:

   kubectl apply -f stress-demo.yaml

5. Compruebe la marca de agua mínima global antes de ejecutar la prueba de rendimiento.

   Importante

   En escenarios de sobrecompromiso de memoria, una marca de agua mínima global baja provoca que el eliminador OOM se ejecute antes de la recuperación de memoria. Para un nodo de 32 GB, establezca este valor en 4,000,000 KB como mínimo.

   cat /proc/sys/vm/min_free_kbytes

   Salida esperada:

   4000000

6. Despliegue memtier-benchmark para enviar solicitudes al pod de Redis:

   apiVersion: v1
   kind: Pod
   metadata:
     labels:
       name: memtier-demo
     name: memtier-demo
   spec:
     containers:
       - command:
           - memtier_benchmark
           - '-s'
           - 'redis-demo'
           - '--data-size'
           - '200000'
           - "--ratio"
           - "1:4"
         image: 'redislabs/memtier_benchmark:1.3.0'
         name: memtier
     restartPolicy: Never
     nodeName: # Set to the name of the node sending requests.

7. Revise los resultados de la prueba de rendimiento:

   kubectl logs -f memtier-demo

8. Para comparar, deshabilite el QoS de memoria en ambos pods y repita la prueba:

   apiVersion: v1
   kind: Pod
   metadata:
     name: redis-demo
     labels:
       koordinator.sh/qosClass: 'LS'
     annotations:
       koordinator.sh/memoryQOS: '{"policy": "none"}'
   spec:
     ...
   ---
   apiVersion: v1
   kind: Pod
   metadata:
     name: stress-demo
     labels:
       koordinator.sh/qosClass: 'BE'
     annotations:
       koordinator.sh/memoryQOS: '{"policy": "none"}'

Resultados de la prueba

Habilitar el QoS de memoria redujo la latencia de Redis en un 7.9% y aumentó el throughput en un 8.7% bajo condiciones de sobrecompromiso de memoria.

¿Sigue siendo válida la configuración de QoS de memoria de ack-slo-manager después de actualizar a ack-koordinator?

Sí. ack-koordinator es retrocompatible con el protocolo basado en anotaciones utilizado en ack-slo-manager 0.8.0 y versiones anteriores:

• alibabacloud.com/qosClass — establece la clase de QoS

• alibabacloud.com/memoryQOS — configura el QoS de memoria

La siguiente tabla muestra qué protocolos admite cada versión:

El soporte para el protocolo alibabacloud.com finalizó el 30 de julio de 2023. Migre al protocolo koordinator.sh.