Consideraciones sobre el espacio aislado de pods en Azure Kubernetes Service (AKS)

El aislamiento de pods en Azure Kubernetes Service (AKS) implica consideraciones sobre la gestión de recursos, la gestión de la memoria, la gestión de la CPU y la seguridad.

Administración de recursos en el entorno de sandbox de pods

Revise estas consideraciones al especificar recursos para una implementación, especialmente para cargas de trabajo grandes o sensibles a recursos.

Componentes Kata

Una implementación de Kata incluye componentes que se ejecutan en el nodo de AKS y los componentes que se ejecutan dentro de la máquina virtual (VM) del pod. Esta distinción entre anfitrión e invitado determina cómo se contabiliza el uso de la memoria y la CPU.

Administración de memoria en el entorno de sandbox de pods

Establezca el límite de memoria de la VM del pod lo suficientemente alto como para soportar la carga de trabajo y los componentes invitados de Kata sin asignar memoria no utilizada.

Tamaño de memoria de máquina virtual de pod

Cada máquina virtual de pod obtiene memoria para la carga de trabajo y todos los componentes invitados de Kata. Incluya memoria más allá del consumo de carga de trabajo esperado para componentes invitados, como el agente kata y el kernel de máquina virtual. Consulte los valores de uso de referencia de los valores de memoria típicos.

El límite de memoria del pod de Kubernetes determina el tamaño de memoria de la máquina virtual del pod. Cambie el límite de memoria del pod para cambiar el tamaño de memoria de la máquina virtual del pod.

RuntimeClass La sobrecarga de memoria suele aumentar con el tamaño de memoria de la máquina virtual del pod.

RuntimeClass sobrecarga de memoria

Las cargas de trabajo de sandboxing de pods incluyen un Kata predeterminado RuntimeClass (kata-vm-isolation) que contiene valores predeterminados de sobrecarga de recursos. Para un control más preciso de las cuotas de recursos, configure uno personalizado RuntimeClass con valores específicos de sobrecarga de recursos. El límite de memoria del pod determina la cantidad de memoria del lado del invitado disponible para la máquina virtual del pod. La RuntimeClass sobrecarga reserva capacidad del nodo para los componentes de Kata del lado del host y no tiene que tener en cuenta el consumo de memoria previsto de los componentes del invitado.

Puede crear un entorno de ejecución especializado y especificar la sobrecarga de memoria a través del overhead campo del RuntimeClass manifiesto. Por ejemplo, el siguiente manifiesto crea un entorno de ejecución para las cargas de trabajo que se espera que tengan un menor consumo de recursos:

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: small-kata-pods
handler: kata
overhead:
  podFixed:
    memory: "120Mi"

El valor de memory: "120Mi" añade 120Mi de sobrecarga fija del pod cuando Kubernetes planifica el pod y determina el tamaño de su cgroup. El valor de handler: kata debe coincidir con el controlador del entorno de ejecución de Kata configurado en los nodos de AKS.

Antes de usar un personalizado RuntimeClass, ejecute kubectl get runtimeclass y compruebe que su controlador es compatible con el clúster de AKS.

No es necesario especificar la sobrecarga, pero se recomienda si desea un control más preciso sobre los recursos reservados para las cargas de trabajo. Si utiliza el valor predeterminado kata-vm-isolationRuntimeClass y no especifica un límite de memoria para el pod, el tamaño de VM del pod será de 512 Mi de forma predeterminada. El valor predeterminado RuntimeClass agrega aproximadamente 88Mi de sobrecarga de memoria para los componentes host, lo que da como resultado un límite de pods cgroup de 600Mi.

Cargas de trabajo de usuario

La carga de trabajo de Kata puede usar el tamaño de memoria de la máquina virtual del pod configurado, menos la memoria que consumen los componentes invitados, como el agente de Kata y el kernel de la máquina virtual invitada.

Para calcular la memoria que usan estos componentes:

1. Conéctese a la máquina virtual del pod (ya sea a través de kubectl exec o kubectl debug para abrir un shell dentro del pod).
2. Ejecute el comando free.
3. Inspeccione la columna usada para calcular la memoria que consume el kernel invitado y el agente kata.

Grupos de control de memoria

Cuando Kubernetes programa un pod de Kata, kubelet asigna el pod a un recurso de memoria cgroup. El cgroup garantiza el cumplimiento de las solicitudes y los límites de memoria del pod, lo que permite definir los recursos disponibles para el pod.

La memoria cgroup tiene dos campos importantes:

En cualquier momento, si el valor memory.current supera el de memory.max, el kernel podría activar un OOMKill en el pod si se detecta presión sobre la memoria.

Valores de uso de referencia

Use los valores siguientes como ejemplos típicos de uso de memoria. No se admiten tamaños de memoria de máquina virtual de pod inferiores a 128 MiB.

Cómo leer esta tabla: memory.current incluye la asignación de memoria de la máquina virtual de pod y el uso actual del componente host. El kubelet calcula memory.max a partir del límite de memoria del pod más la sobrecarga de RuntimeClass. La diferencia entre estos valores indica la capacidad disponible para el uso adicional de componentes host.

Procedimientos recomendados de administración de memoria

• Especifique los tamaños de memoria de máquina virtual de pod estableciendo limits.memory en los manifiestos y defina las cuotas de recursos adecuadas para todas las implementaciones.
  • Utilice una solicitud de memoria del pod distinta de cero para reservar la capacidad del nodo para la VM del pod antes de que se inicie la VM. La solicitud debe tener en cuenta la máquina virtual del pod y los contenedores que se ejecutan en ella.
  • Utilice una sobrecarga de memoria RuntimeClass distinta de cero para tener en cuenta la capacidad del nodo que consumen los componentes de host de Kata.
• En el caso de las cargas de trabajo que consumen muchos recursos, establezca un límite de memoria de pod que proporcione suficiente memoria para la carga de trabajo y los componentes invitados.
• Establece una sobrecarga de memoria RuntimeClass lo suficientemente alta para los componentes del host de Kata sin reservar una capacidad de nodo sustancialmente superior a la que necesitan.

Administración de la CPU en el entorno de sandboxing de pods

Asigna recursos de CPU a las cargas de trabajo de Kata estableciendo límites de CPU para los pods y la sobrecarga RuntimeClass. Sin un límite de CPU, los componentes del host kata pueden usar cualquier capacidad de CPU disponible en el nodo.

Reserva de CPU

Establezca uno o ambos de los siguientes campos para reservar capacidad de CPU para sus cargas de trabajo de Kata:

• Sobrecarga de la RuntimeClass CPU
• Límite de CPU del pod

Cuando se especifica al menos uno de los dos valores, el plano de control reserva el número especificado de CPU en el nodo para la carga de trabajo. Otros pods del mismo nodo no pueden acceder a esta capacidad reservada.

Límite de CPU de pod

Define el límite de CPU del pod en el manifiesto de tu aplicación. El límite controla cuántas CPU pueden usar los contenedores de la máquina virtual de pod asociada.

Si no declara un límite de CPU de pod, AKS asigna una vCPU a la máquina virtual de pod cuando el nodo tiene suficiente capacidad. Los componentes del host kata no tienen ningún límite de consumo de CPU.

RuntimeClass Sobrecarga de CPU

Especifique la RuntimeClass sobrecarga para reservar capacidad del nodo para los componentes del host de Kata antes de desplegar una carga de trabajo.

Puede especificar la sobrecarga de CPU a través del overhead campo del RuntimeClass manifiesto. Por ejemplo:

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: custom-kata-runtime
handler: kata
overhead:
  podFixed:
    cpu: "250m"

El valor cpu: "250m" añade 0,25 vCPU de sobrecarga fija del pod cuando Kubernetes programa el pod y determina su tamaño cgroup. Ajuste este valor según el consumo de CPU esperado de los componentes del host de Kata.

Procedimientos recomendados de administración de CPU

• Si el nodo normalmente tiene una gran cantidad de capacidad gratuita de CPU, es posible que estas reservas sean innecesarias.
• Si los nodos operan frecuentemente al límite con el consumo de CPU, una reserva distinta de cero garantiza que tus pods se puedan ejecutar de forma más fiable.
  • Las solicitudes de CPU de los pods ayudan al planificador de Kubernetes a reservar capacidad suficiente en los nodos para una carga de trabajo. La capacidad reservada para una carga de trabajo específica no está disponible para otras cargas de trabajo en el nodo.
• Especifique las solicitudes de CPU que su infraestructura puede admitir. Si la capacidad disponible se aproxima a cero o la solicitud es demasiado grande, es posible que las cargas de trabajo no lleguen a iniciarse.
• Alinee las solicitudes de CPU con los límites de CPU. Las solicitudes de recursos afectan a la planificación de Kubernetes, pero el shim de Kata no las utiliza para dimensionar la máquina virtual del pod. El límite de CPU determina la asignación de vCPU de la máquina virtual del pod. Si no se declara ningún límite de CPU, la VM del pod recibe una vCPU y los componentes del host de Kata no tienen límite de consumo de CPU.

Declaraciones de ejemplo

Consideraciones de seguridad para el aislamiento de Pods

El aislamiento de los pods aísla las cargas de trabajo de otras cargas de trabajo y del host, pero debe considerar los siguientes riesgos de seguridad.

Pods con privilegios

Algunas cargas de trabajo requieren pods con privilegios. Puede crear pods con privilegios, pero los dispositivos host no están conectados a los pods.

El uso de contenedores con privilegios proporciona acceso raíz en la máquina virtual invitada, pero los contenedores permanecen aislados del host.

Utilice pods privilegiados solo cuando sea necesario, incluso con aislamiento de pods. Permitir que solo los usuarios de confianza administren pods con privilegios.

Volúmenes de almacenamiento de rutas de acceso de host

Montar volúmenes hostPath en pods de Kata expone parte del sistema de archivos del host directamente al contenedor y puede debilitar el aislamiento del entorno aislado del pod. Aplica las directrices de seguridad de origen hostPath a las cargas de trabajo en entornos aislados de pods.

Los archivos en /dev son una excepción porque se montan en el contenedor desde el sistema invitado en lugar del sistema host. Este comportamiento mantiene el aislamiento del pod si una carga de trabajo necesita esta ruta.

Bloquear volúmenes hostPath con Azure Policy

Azure Policy proporciona medidas de seguridad y aplicación centralizadas y coherentes para los componentes del clúster.

AKS proporciona definiciones de directivas integradas que aplican los procedimientos recomendados. Asigna la directiva Los pods del clúster de Kubernetes solo deben utilizar tipos de volumen permitidos con el Denyefecto, y excluye hostPath de los tipos de volumen permitidos para bloquear los pods que intenten montar hostPath volúmenes.

Pasos siguientes

Aprende a implementar el aislamiento de pods en AKS.