Que sont les conteneurs isolés - Container Service for Kubernetes

Informations générales

Les conteneurs isolés conviennent aux scénarios tels que l'isolation des applications non fiables, l'isolation des pannes, l'isolation des performances et l'isolation des charges de travail multi-locataires. Ils renforcent la sécurité avec un impact minimal sur les performances et offrent la même expérience utilisateur que les conteneurs Docker pour des fonctionnalités telles que la journalisation, la surveillance et la mise à l'échelle élastique.

Par rapport à Kata Containers, les conteneurs isolés améliorent le stockage, la mise en réseau et la stabilité.

Architecture

Principaux avantages

Sandboxed Container V2 est le runtime de conteneur sécurisé de nouvelle génération d'Alibaba Cloud, basé sur la technologie de machine virtuelle légère. Par rapport à la version V1, il maintient une isolation forte tout en réduisant la surcharge de 90 %, en triplant la vitesse de démarrage et en décuplant la densité par machine.

Assure une isolation robuste entre les environnements isolés grâce à des machines virtuelles légères.
Offre une compatibilité applicative avec les conteneurs runC traditionnels.
Fournit jusqu'à 90 % des performances des applications de conteneurs runC.
Prend en charge le montage et le partage de volumes NAS, de disques cloud et OSS via virtiofs. Le NAS prend également en charge l'attachement direct.
Propose une expérience utilisateur cohérente avec runC pour la surveillance, la journalisation et le stockage.
Prend en charge RuntimeClass (runC et runV).
Facile à utiliser, sans nécessiter d'expertise technique approfondie.
Offre une stabilité supérieure à celle des Kata Containers de la communauté.

Conteneurs isolés ACK vs. Kata Containers

Performances	Catégorie de performance	ACK Sandboxed Container V2	Kata Containers communautaire
Vitesse de démarrage du bac à sable		Environ 150 ms	Environ 500 ms
Surcharge supplémentaire du bac à sable		Faible	Élevée
RootFS du conteneur		virtio-fs, Performance : ☆☆☆☆	9pfs, Performance : ☆ virtio-fs, Performance : ☆☆☆☆
Volumes de conteneur	HostPath/EmptyDir	virtio-fs, Performance : ☆☆☆☆
	Stockage par blocs de disque cloud	virtio-fs, Performance : ☆☆☆☆ Ne prend pas en charge des fonctionnalités telles que la mise à l'échelle en ligne (Resize), la surveillance des E/S du conteneur, les périphériques block/raw ou les paramètres de file d'attente des disques cloud.
	Stockage de fichiers NAS	virtio-fs (par défaut), Performance : ☆☆☆☆ Attachement direct au bac à sable, Performance : ☆☆☆☆☆ Ne prend pas en charge des fonctionnalités telles que le montage et le démontage Samba, la corbeille, le contrôle de capacité Quota, la surveillance de la capacité/des E/S ou la mise à l'échelle en ligne.
	Stockage d'objets OSS	virtio-fs, Performance : ☆☆☆☆
Plugin réseau		Terway : Améliore les performances réseau de 20 à 30 % par rapport à Flannel. Prend en charge NetworkPolicy, la limitation de bande passante, etc. Flannel : Prend en charge le routage Virtual Private Cloud (VPC).	Flannel
Surveillance et alertes		Métriques de surveillance améliorées pour les disques et le réseau des pods de conteneurs isolés. S'intègre par défaut à Alibaba Cloud Cloud Monitor, simplifiant la configuration de la surveillance et des alertes du cluster.	Manque de métriques de surveillance des disques et du réseau pour les pods de conteneurs isolés.
Stabilité		☆☆☆☆☆	☆☆

Cas d'utilisation

Scénario 1 : Isoler les applications non fiables avec des conteneurs isolés (runV)

Risques de sécurité des conteneurs runC
- Les conteneurs utilisant l'isolation par namespace et cgroup présentent une surface d'attaque importante.
- Tous les conteneurs d'un nœud partagent le noyau de l'hôte. Si une vulnérabilité du noyau est exploitée, un code malveillant peut s'échapper vers l'hôte, pénétrer le réseau privé, exécuter du code privilégié, perturber les services et voler des données.
- Les vulnérabilités des applications peuvent également permettre aux attaquants de pénétrer le réseau privé.
Atténuez les risques de sécurité des conteneurs runC avec les mesures suivantes :
- Seccomp : Filtrer les appels système.
- SELinux : Restreindre les autorisations pour les processus, les fichiers et les utilisateurs du conteneur.
- Capability : Limiter les capacités des processus du conteneur.
- Mode Rootless : Empêcher l'exécution du runtime de conteneur et des conteneurs en tant que root.
Ces mesures renforcent la sécurité des conteneurs runC, mais ne peuvent pas empêcher les évasions de conteneurs qui exploitent les vulnérabilités du noyau de l'hôte.
Isoler les risques de sécurité avec des conteneurs isolés (runV)

Les applications dans un bac à sable VM s'exécutent sur un noyau OS invité indépendant. Même si le noyau invité est compromis, l'impact reste confiné à ce bac à sable et n'affecte pas l'hôte ni les autres conteneurs. Combinez les conteneurs isolés (runV) avec Terway NetworkPolicy pour configurer des politiques d'accès au niveau du pod afin d'assurer une isolation complète du système, des données et du réseau.

Scénario 2 : Résoudre les problèmes liés aux conteneurs runC, tels que l'amplification des pannes, la contention des ressources et les interférences de performances

Kubernetes co-localise les conteneurs sur les nœuds, mais les cgroups ne résolvent pas entièrement la contention des ressources. Les applications gourmandes en ressources, telles que les charges de travail intensives en CPU ou en E/S, entrent en concurrence pour les ressources, provoquant des fluctuations du temps de réponse. Des problèmes tels que les fuites de mémoire ou les vidages sur incident (core dumps) augmentent la charge du nœud. Un conteneur qui déclenche un bogue du noyau de l'hôte peut faire planter le nœud, et les pannes peuvent se propager à l'ensemble du cluster. Les conteneurs isolés (runV) utilisent des noyaux OS invités indépendants et des hyperviseurs pour résoudre l'amplification des pannes, la contention des ressources et les interférences de performances dans les conteneurs runC.

Scénario 3 : Services multi-locataires

Les entreprises disposant de plusieurs lignes métier (LOB) ou départements nécessitent souvent une isolation forte des locataires. Par exemple, les charges de travail financières peuvent requérir des environnements dédiés, séparés des applications non sensibles à la sécurité. Les conteneurs runC traditionnels ne peuvent pas empêcher efficacement les risques de sécurité provenant d'applications non fiables. Les approches courantes incluent :

Plusieurs clusters mono-locataires : Séparer les clusters financiers des clusters non sensibles à la sécurité.
Un seul cluster multi-locataire : Séparer les applications LOB dans des namespaces avec des nœuds dédiés par LOB. L'isolation multi-locataire repose sur des quotas de ressources, des politiques réseau et d'autres fonctionnalités. Cette approche utilise moins de plans de contrôle et engendre des coûts de gestion inférieurs à ceux de plusieurs clusters, mais ne résout pas le gaspillage des ressources des nœuds dû à une faible utilisation par certains locataires.

Les conteneurs isolés (runV) isolent les applications non fiables dans des bacs à sable VM, éliminant les risques d'évasion de conteneurs et permettant des charges de travail mixtes sur tous les nœuds :

Réduit la complexité de la planification des ressources.
Les nœuds servent plusieurs activités métier, réduisant la fragmentation des ressources, améliorant l'utilisation et abaissant les coûts du cluster.
Les conteneurs isolés (runV) utilisent des machines virtuelles légères et offrent des performances comparables à celles de runC.