Considérations relatives à l’isolation des pods sur Azure Kubernetes Service (AKS)

L’isolation des pods sur Azure Kubernetes Service (AKS) implique des considérations liées à la gestion des ressources, de la mémoire et du processeur, ainsi qu’à la sécurité.

Gestion des ressources dans le sandboxing de pod

Passez en revue ces considérations lorsque vous spécifiez des ressources pour un déploiement, en particulier pour les charges de travail volumineuses ou sensibles aux ressources.

Composants Kata

Un déploiement Kata inclut des composants qui s’exécutent sur le nœud AKS et les composants qui s’exécutent à l’intérieur de la machine virtuelle pod. Ce fractionnement hôte et invité détermine la façon dont l’utilisation de la mémoire et du processeur est prise en compte.

Gestion de la mémoire dans sandboxing de pod

Définissez la limite de mémoire de la machine virtuelle pod suffisamment élevée pour prendre en charge votre charge de travail et les composants invités Kata sans allouer de mémoire inutilisée.

Taille de mémoire de la machine virtuelle pod

Chaque machine virtuelle de pod dispose de mémoire pour la charge de travail et tous les composants invités de Kata. Incluez la mémoire au-delà de la consommation de charge de travail attendue pour les composants invités tels que l’agent Kata et le noyau de machine virtuelle. Consultez les valeurs d’utilisation de référence pour les valeurs de mémoire classiques.

La limite de mémoire des pods Kubernetes détermine la taille de la mémoire de la machine virtuelle de pod. Modifiez la limite de mémoire du pod pour changer la taille de mémoire de la machine virtuelle du pod.

RuntimeClass la surcharge de mémoire augmente généralement avec la taille de mémoire de la machine virtuelle de pod.

RuntimeClass surcharge mémoire

Les charges de travail de sandboxing de pod sont fournies avec un RuntimeClass kata (kata-vm-isolation) par défaut qui inclut des valeurs de surcharge de ressources par défaut. Pour un contrôle plus fin des quotas de ressources, configurez un RuntimeClass personnalisé avec des surcharges en ressources spécifiques. La limite de mémoire du pod détermine la mémoire disponible côté invité pour la VM du pod. RuntimeClass l’overhead réserve la capacité du nœud pour les composants Kata du côté hôte et n’a pas à tenir compte de la consommation mémoire attendue des composants du côté invité.

Vous pouvez créer un runtime spécialisé et spécifier la surcharge de mémoire via le overhead champ de votre RuntimeClass manifeste. Par exemple, le manifeste suivant crée un runtime pour les charges de travail censées avoir une consommation de ressources inférieure :

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

La valeur memory: "120Mi" ajoute 120Mi de surcharge fixe pour le pod lorsque Kubernetes programme le pod et dimensionne son cgroup. La handler: kata valeur doit correspondre au gestionnaire d’exécution Kata configuré sur les nœuds AKS.

Avant d’utiliser un RuntimeClass personnalisé, exécutez kubectl get runtimeclass et vérifiez que son gestionnaire est pris en charge dans votre cluster AKS.

La spécification de la surcharge n’est pas nécessaire, mais il est recommandé si vous souhaitez un contrôle plus précis sur les ressources réservées à vos charges de travail. Si vous utilisez la valeur par défaut kata-vm-isolationRuntimeClass et que vous ne spécifiez pas de limite de mémoire de pod, la taille de la machine virtuelle de pod est définie par défaut sur 512Mi. La valeur par défaut RuntimeClass ajoute environ 88Mi de surcharge de mémoire pour les composants hôtes, ce qui entraîne une limite de pod cgroup 600Mi.

Charges de travail utilisateur

Votre charge de travail Kata peut utiliser la taille de mémoire de la VM de pod configurée, déduction faite de la mémoire consommée par les composants du système invité, tels que l’agent Kata et le noyau de la VM invitée.

Pour estimer la mémoire que ces composants utilisent :

1. Connectez-vous à la machine virtuelle de pod (via kubectl exec ou kubectl debug pour ouvrir un interpréteur de commandes à l’intérieur de votre pod).
2. Exécutez la commande free.
3. Inspectez la colonne utilisée pour estimer la mémoire consommée par le noyau invité et l’agent Kata.

Groupes de mémoire

Lorsque Kubernetes planifie un pod Kata, kubelet affecte le pod à une mémoire cgroup. Le cgroup applique les requêtes et les limites de mémoire du pod afin de définir les ressources disponibles pour le pod.

La mémoire cgroup comporte deux champs importants :

À tout moment, si la memory.current valeur dépasse celle de memory.max, le noyau peut déclencher un OOMKill sur le pod si la pression de la mémoire est détectée.

Consulter les valeurs d'utilisation

Utilisez les valeurs suivantes comme exemples d’utilisation standard de la mémoire. Les tailles de mémoire des machines virtuelles pod inférieures à 128 Mio ne sont pas prises en charge.

Guide pratique pour lire ce tableau : memory.current inclut l’allocation de mémoire de la machine virtuelle de pod et l’utilisation actuelle des composants hôtes. Le kubelet calcule memory.max à partir de la limite de mémoire du pod et plus la surcharge RuntimeClass. La différence entre ces valeurs indique la capacité disponible pour une utilisation supplémentaire des composants hôtes.

Meilleures pratiques de gestion de la mémoire

• Spécifiez les tailles de mémoire des VM de pod en définissant limits.memory dans vos manifestes, et définissez des quotas de ressources appropriés pour tous les déploiements.
  • Utilisez une requête de mémoire de pod différente de zéro pour réserver la capacité du nœud pour la machine virtuelle de pod avant le démarrage de la machine virtuelle. La requête doit tenir compte de la machine virtuelle du pod et des conteneurs qui s’y exécutent.
  • Utilisez une surcharge mémoire RuntimeClass non nulle pour tenir compte de la capacité du nœud consommée par les composants hôtes de Kata.
• Pour les charges de travail gourmandes en ressources, définissez une limite de mémoire de pod qui fournit suffisamment de mémoire pour la charge de travail et les composants invités.
• Définissez une RuntimeClass surcharge mémoire à un niveau suffisamment élevé pour les composants hôte de Kata, sans réserver une capacité de nœud sensiblement supérieure à leurs besoins.

Gestion du processeur dans le sandboxing de pod

Allouez des ressources CPU aux charges de travail Kata en définissant les limites de CPU du pod et la surcharge RuntimeClass. En l’absence de limite de CPU, les composants hôtes Kata peuvent utiliser toute la capacité CPU disponible sur le nœud.

Réservation du processeur

Définissez l’un ou les deux champs suivants pour réserver la capacité du processeur pour vos charges de travail Kata :

• Le RuntimeClass surcoût processeur
• Limite CPU du pod

Quand au moins l’une des deux valeurs est spécifiée, le plan de contrôle réserve le nombre spécifié de processeurs sur le nœud pour votre charge de travail. D’autres pods sur le même nœud ne peuvent pas accéder à cette capacité réservée.

Limite de CPU du pod

Déclarez la limite CPU du pod dans le manifeste de votre application. La limite contrôle le nombre de processeurs que les conteneurs de la machine virtuelle pod associée peuvent utiliser.

Si vous ne définissez pas de limite CPU pour le pod, AKS alloue un vCPU à la machine virtuelle du pod lorsque le nœud dispose d’une capacité suffisante. Les composants hôtes Kata n’ont aucune limite de consommation du processeur.

RuntimeClass Surcharge du processeur

Spécifiez la surcharge RuntimeClass pour réserver la capacité de nœud pour les composants hôtes Kata avant de déployer une charge de travail.

Vous pouvez spécifier la surcharge du processeur via le overhead champ de votre RuntimeClass manifeste. Par exemple :

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

La valeur cpu: "250m" ajoute une surcharge fixe de 0,25 vCPU pour le pod lorsque Kubernetes programme le pod et dimensionne son cgroup. Ajustez cette valeur en fonction de la consommation d’UC attendue des composants hôtes Kata.

Meilleures pratiques de gestion du processeur

• Si votre nœud dispose généralement de beaucoup de capacité CPU libre, ces réservations pourraient être superflues.
• Si vos nœuds atteignent généralement la limite de consommation de processeur, une réservation non nulle garantit que vos pods peuvent être exécutés avec davantage de fiabilité.
  • Les requêtes de processeur des pods aident le planificateur de Kubernetes à réserver une capacité suffisante sur les nœuds pour exécuter une charge de travail. La capacité réservée pour une charge de travail spécifique n’est pas disponible pour d’autres charges de travail sur le nœud.
• Spécifiez les demandes d’UC que votre infrastructure peut prendre en charge. Si votre capacité disponible approche de zéro, ou si votre requête est trop importante, vos charges de travail risquent de ne pas démarrer.
• Alignez vos requêtes de CPU avec vos limites de CPU. Les demandes de ressources affectent l’ordonnancement de Kubernetes, mais le shim Kata ne les utilise pas pour dimensionner la machine virtuelle du pod. La limite de CPU détermine l’allocation en vCPU de la VM de pod. Si aucune limite de CPU n’est déclarée, la VM du pod reçoit un vCPU, et les composants hôtes de Kata n’ont aucune limite de consommation CPU.

Exemples de déclarations

Considérations relatives à la sécurité pour le bac à sable pod

L’isolation par bac à sable des pods isole les charges de travail des autres charges de travail et de l’hôte, mais vous devez toujours prendre en compte les risques de sécurité suivants.

Pods privilégiés

Certaines charges de travail nécessitent des pods privilégiés. Vous pouvez créer des pods privilégiés, mais les appareils hôtes ne sont pas attachés aux pods.

L’utilisation de conteneurs privilégiés donne un accès racine dans la machine virtuelle invitée, mais les conteneurs restent isolés de l’hôte.

Utilisez des pods privilégiés uniquement lorsque cela est nécessaire, même avec le mécanisme d’isolation des pods. Autoriser uniquement les utilisateurs approuvés à gérer des pods privilégiés.

Volumes de stockage de chemin d’hôte

Le montage de volumes hostPath dans les pods Kata expose directement au conteneur une partie du système de fichiers de l’hôte et peut affaiblir l’isolation du bac à sable des pods. Appliquez les recommandations de sécurité en amonthostPath aux charges de travail de sandboxing de pod.

Les fichiers sous /dev sont une exception, car ils sont montés dans le conteneur à partir du système invité au lieu du système hôte. Ce comportement maintient l’isolation des pods lorsqu’une charge de travail nécessite ce chemin d’accès.

Bloquer les volumes hostPath avec Azure Policy

Azure Policy fournit une mise en œuvre centralisée, cohérente et des protections pour vos composants de cluster.

AKS fournit des définitions de stratégie intégrées qui appliquent les meilleures pratiques. Attribuez la stratégie Les pods de cluster Kubernetes ne doivent utiliser que les types de volumes autorisés avec l’effet Deny, et excluez hostPath des types de volumes autorisés pour bloquer les pods qui tentent de monter des volumes hostPath.

Étapes suivantes

Découvrez comment déployer le bac à sable pod sur AKS.