Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
À mesure que les clusters AKS gagnent en taille et hébergent des charges de travail de plusieurs équipes ou clients, l’infrastructure partagée peut compliquer davantage l’isolation. Il se peut que vous ayez besoin d’une isolation plus forte pour empêcher les charges de travail gourmandes en ressources ou à pics d’activité de perturber les charges de travail prévisibles. Vous devrez peut-être également isoler les charges de travail sensibles pour répondre aux exigences de sécurité.
Pour répondre à ces exigences, vous pouvez isoler vos charges de travail par le biais de stratégies d’isolation logique ou physique. Pour une isolation logique, utilisez des espaces de noms Kubernetes pour séparer les ressources et les déploiements. Les espaces de noms partagent l’infrastructure de cluster sous-jacente. Ils ne fournissent donc pas la même limite d’isolation physique que les clusters distincts. Bien que les clusters distincts fournissent une limite physique, cette stratégie peut augmenter les coûts lorsque les clusters n’utilisent pas leur capacité totale.
Le sandboxing des pods dans AKS introduit la possibilité d’exécuter vos charges de travail dans des machines virtuelles de pod légères distinctes. Chaque machine virtuelle de pod fournit une limite d’isolation de calcul : la charge de travail s’exécute avec son propre noyau invité et est isolée du noyau hôte et des charges de travail dans d’autres machines virtuelles de pod.
L’isolation des pods en bac à sable repose sur le projet open source Kata Containers.
Important
La frontière de la VM de pod assure uniquement l’isolation des ressources de calcul. Il n’isole pas le plan de contrôle AKS, le stockage ou les chemins de données, ni les actions effectuées par les utilisateurs disposant d’un accès administrateur de cluster. L’isolation des pods, à elle seule, ne permet pas d’assurer une isolation forte et complète entre locataires. Pour un déploiement multilocataire, passez en revue les conseils AKS pour les solutions mutualisées et appliquez les contrôles d’identité, de réseau, de stockage et de gouvernance requis.
Architecture et composants
Le sandboxing des pods utilise l’environnement d’exécution Kata Containers pour créer une machine virtuelle de pod légère pour chaque pod mis en sandbox. Le diagramme suivant montre comment les composants côté hôte créent et gèrent la machine virtuelle de pod isolé et comment les composants côté invité exécutent la charge de travail.
- Dans le manifeste de pod, définissez
runtimeClassName: kata-vm-isolationpour sélectionner le runtime Kata Containers. - Containerd appelle le shim Kata (
containerd-shim-kata-v2) au lieu du shim de runtime standard. - Le shim Kata démarre le moniteur de machine virtuelle (VMM) Cloud Hypervisor, qui crée une VM de pod avec un noyau invité distinct et l’agent Kata.
- L’agent Kata crée et gère les conteneurs et les processus de charge de travail à l’intérieur de la machine virtuelle pod.
- Lorsque la VM de pod est supprimée, le shim Kata arrête la VM de pod et restitue ses ressources à l’hôte de conteneurs.
Avantages et cas d’usage
Le sandboxing des pods isole chaque pod mis en sandbox dans une machine virtuelle de pod légère avec son propre noyau invité. Cette limite de calcul sépare la charge de travail du noyau hôte et des charges de travail dans d’autres machines virtuelles pod. Associez l’isolation des pods à des contrôles tels que les politiques réseau et Azure Policy afin d’atténuer les risques liés au réseau et à la gouvernance que le périmètre d’isolation de la machine virtuelle du pod ne couvre pas. Pour obtenir des conseils sur la sélection de contrôles pour les déploiements multilocataires, consultez les instructions AKS pour les solutions multilocataires.
Cas d’utilisation courants
Le bac à sable de pod peut vous aider à :
- Hébergez des charges de travail provenant de différents clients sur le même cluster AKS, tout en fournissant une limite d’isolation des ressources de calcul distincte pour chaque pod isolé en bac à sable.
- Isoler les charges de travail non approuvées du noyau hôte et des charges de travail dans d’autres machines virtuelles pod tout en continuant à utiliser la capacité de cluster partagée.
- Protégez les charges de travail sensibles ou à valeur élevée contre les charges de travail exécutées dans d’autres machines virtuelles de pod.
- Réduisez l’effet des charges de travail gourmandes en ressources ou en rafale sur d’autres pods en bac à sable en appliquant des demandes de processeur et de mémoire et des limites à chaque machine virtuelle pod.
- Limitez l’impact sur les ressources de calcul d’une défaillance de charge de travail à sa VM de pod.
Isolation des charges de travail
Le bac à sable des pods vous permet de colocaliser des charges de travail sur des nœuds de cluster partagés tout en conservant une limite d’isolation de calcul distincte pour chaque pod en bac à sable.
Vous pouvez déclarer des demandes de ressources et des limites pour vos charges de travail. AKS applique les valeurs par défaut lorsque vous les omettez. La machine virtuelle de pod limite une charge de travail gourmande en ressources au processeur et à la mémoire allouée à cette machine virtuelle. Si une charge de travail provoque l’échec de sa machine virtuelle pod, la limite d’isolation de calcul protège les charges de travail dans d’autres machines virtuelles de pod contre cette défaillance.
Flexibilité
Vous pouvez exécuter des pods en bac à sable et standard dans le même cluster. Cette flexibilité vous permet d’appliquer l’isolation des machines virtuelles de pod uniquement aux charges de travail qui en ont besoin.
Composants open source
L’isolation des pods utilise des composants open source, notamment le VMM Cloud Hypervisor et l’environnement d’exécution Kata Containers. Le développement ouvert assure la transparence dans les composants d’isolation et permet l’examen de la communauté. L’architecture sépare également le noyau invité dans chaque machine virtuelle de pod du noyau hôte Linux Azure.
Migrer des charges de travail existantes
Pour un déploiement de base, ajoutez la classe d’exécution Kata à une spécification de pod existante pour exécuter la charge de travail dans une machine virtuelle de pod. Cette modification de manifeste ne garantit pas le comportement identique à un pod qui utilise le runtime standard runc . Avant la migration, validez le comportement opérationnel de la charge de travail et la compatibilité avec les fonctionnalités de Kubernetes, et tenez compte du dimensionnement des ressources de la machine virtuelle de pod ainsi que de sa surcharge. Pour plus d’informations, consultez Considérations relatives au bac à sable de pod.
Étapes suivantes
- Passez en revue les considérations relatives à l’isolation des pods avant le déploiement.
- Déployez le bac à sable de pod sur AKS.