Política de CPU
Escenarios de aplicación
De forma predeterminada, kubelet utiliza cuotas de CFS para imponer límites de CPU de pod. Cuando el nodo ejecuta muchos pods unidos a CPU, la carga de trabajo puede moverse a diferentes núcleos de CPU dependiendo de si el pod está limitado y qué núcleos de CPU están disponibles en el tiempo de programación. Muchas cargas de trabajo no son sensibles a esta migración y, por lo tanto, funcionan bien sin ninguna intervención. Algunas aplicaciones son sensibles a la CPU. Son sensibles a:
- Estrangulamiento de la CPU
- Cambio de contexto
- Errores de caché del procesador
- Acceso a memoria entre sockets
- Hyperthreads que se espera que se ejecuten en la misma tarjeta de CPU física
Si sus cargas de trabajo son sensibles a cualquiera de estos elementos y la afinidad de caché de CPU y la latencia de programación afectan significativamente el rendimiento de la carga de trabajo, kubelet permite que las políticas de gestión de CPU alternativas determinen algunas preferencias de ubicación en el nodo. El gestor de CPU asigna preferentemente recursos en un socket y núcleos físicos completos para evitar interferencias.
Habilitación de la política de gestión de CPU
Una política de gestión de CPU es especificada por el indicador kubelet --cpu-manager-policy. De forma predeterminada, Kubernetes admite las siguientes políticas:
- Disabled (none): la política predeterminada. La política none habilita explícitamente el esquema de afinidad de CPU predeterminado existente, sin proporcionar afinidad más allá de lo que el programador del sistema operativo hace automáticamente.
- Enabled (static): La política static permite que contenedores en pods Guaranteed con solicitudes de GPU enteras obtenga una mayor afinidad de CPU y exclusividad en el nodo.
Al crear un clúster, puede configurar la política de gestión de CPU de Advanced Settings como se muestra en la siguiente figura.
También puede configurar la política en un grupo de nodos. La configuración cambiará el indicador de kubelet --cpu-manager-policy en el nodo. Inicie sesión en la consola de CCE, haga clic en el nombre del clúster, acceda a la página de detalles del clúster y elija Nodes en el panel de navegación. En la página mostrada, haga clic en la ficha Node Pools. Elija More > Manage en la columna Operation del grupo de nodos de destino y cambie el valor decpu-manager-policy a static.
Permitir que los pods usen exclusivamente los recursos de la CPU
Prerrequisitos:
- Habilite la política static en el nodo. Para obtener más información, véase Habilitación de la política de gestión de CPU.
- Tanto Request como Limit deben establecerse en la definición de pod y sus valores deben ser los mismos.
- Si un contenedor de inicio necesita utilizar exclusivamente la CPU, establezca su requests en el mismo que el del contenedor de servicio. De lo contrario, el contenedor de servicio no hereda el resultado de asignación de CPU del contenedor de inicio, y el administrador de CPU reserva más recursos de CPU de los supuestos. Para obtener más información, vea App Containers can't inherit Init Containers CPUs - CPU Manager Static Policy.
Puede usar Política de programación (afinidad/antiafinidad) para programar los pods configurados en los nodos donde está habilitada la política static. De esta manera, los pods pueden utilizar exclusivamente los recursos de CPU.
kind: Deployment
apiVersion: apps/v1
metadata:
name: test
spec:
replicas: 1
selector:
matchLabels:
app: test
template:
metadata:
labels:
app: test
spec:
containers:
- name: container-1
image: nginx:alpine
resources:
requests:
cpu: 2 # The value must be an integer and must be the same as that in limits.
memory: 2048Mi
limits:
cpu: 2 # The value must be an integer and must be the same as that in requests.
memory: 2048Mi
imagePullSecrets:
- name: default-secret
