Écrit en Go, Kubernetes est un système open source qui vise à fournir une plateforme permettant d'automatiser le déploiement, la montée en charge et la mise en œuvre de conteneurs d'application sur des clusters de serveurs. Kubernetes aide à gérer facilement et efficacement des clusters au sein desquels des groupes d'hôtes exécutant des conteneurs Linux sont rassemblés. Bien que Kubernetes prenne en charge les clusters exclusivement IPv6 depuis la version 1.18, la migration d'IPv4 vers IPv6 n'était pas encore possible les administrateur système DevOps demandent la prise en charge d'IPv6 dans les clusters Kubernetes. Bridget Kromhout, responsable des programmes chez Microsoft, a annoncé le 8 décembre sur le blog de Kubernetes la mise en réseau d’IPv4/IPv6 en double pile sur la version 1.23 de Kubernetes.À l'origine, la plateforme Kubernetes a été développée et conçue par des ingénieurs de Google. Google était l'un des premiers contributeurs aux technologies de conteneurs Linux, et a d'ailleurs expliqué publiquement que tout dans l'entreprise fonctionnait dans des conteneurs (il s'agit de la technologie à la base des services cloud de Google). Google déploie plus de 2 milliards de conteneurs par semaine via une plateforme interne nommée Borg. Cette plateforme est la « grande sœur » de Kubernetes et toute l'expérience acquise au fil des ans lors du développement de Borg a servi de fondation à la technologie Kubernetes.
Rappelons que Kubernetes permet d'éliminer de nombreux processus manuels associés au déploiement et à la mise à l'échelle des applications conteneurisées. Les clusters peuvent couvrir des hôtes situés dans des clouds publics, privés ou hybrides. Afin de prendre en charge la double pile dans les clusters, Kubernetes doit connaître et prendre en charge les adresses à double pile pour les nœuds.
Mises à jour de l'API de service pour les doubles pile
Les services étaient à pile unique avant la version 1.20. L'utilisation des deux familles d'adresses IP impliquait donc la création d'un service par famille d'adresses IP. L'expérience de l'utilisateur a été simplifiée dans la version 1.20, lorsque les services ont été réimplémentés pour permettre les deux familles d'IP, ce qui signifie qu'un seul service peut gérer les charges de travail IPv4 et IPv6. L'équilibrage de charge à double pile est possible entre les services exécutant toute combinaison d'IPv4 et d'IPv6.
L'API de service comporte désormais de nouveaux champs qui remplacent le champ unique ipFamily pour la prise en charge de la double pile :
- Il est possible de sélectionner un choix de famille IP en définissant ipFamilyPolicy sur l'une des trois options suivantes : SingleStack, PreferDualStack, ou RequireDualStack. Un service peut être modifié entre single-stack et dual-stack (dans certaines limites) ;
- clusterIPs comprend la précédente clusterIP mais permet des entrées multiples, il n'est donc plus nécessaire d'exécuter des services en double, un dans chacune des deux familles IP. Au lieu de cela, il est possible d’attribuer des adresses IP de cluster dans les deux familles d'IP.
Le comportement par défaut reste mono-pile
À partir de la version 1.20, avec la réimplémentation des services double pile en tant qu'alpha, la mise en réseau sous-jacente de Kubernetes a inclus le dual-stack, qu'un cluster soit configuré ou non avec l'indicateur de fonctionnalité pour activer le dual-stack.
Kubernetes permet de résoudre de nombreux problèmes courants liés à la prolifération des conteneurs en les triant au sein d'un « pod ». Ces pods ajoutent une couche d'abstraction aux groupes de conteneurs, ce qui aide à planifier les charges de travail et à fournir les services nécessaires (réseau, stockage, etc.) à ces conteneurs. D'autres composants de Kubernetes aident à équilibrer la charge sur ces pods et à assurer que l’utilisateur dispose de suffisamment de conteneurs pour exécuter les charges de travail.
Kubernetes doit pouvoir s'intégrer aux services de mise en réseau, de stockage, de sécurité, de télémétrie, entre autres, pour fournir une infrastructure de conteneurs complète. La sécurité des conteneurs comporte plusieurs couches et peut être complexe. Kubernetes offre les outils d'orchestration et de gestion requis pour déployer des conteneurs, à grande échelle, pour ces charges de travail. Les fonctionnalités d'orchestration de Kubernetes permettent de créer des services applicatifs sur plusieurs conteneurs, de planifier l'exécution de ces conteneurs dans un cluster, de les mettre à l'échelle et de gérer leur intégrité au fil du temps.
Double pile IPv4/IPv6
Afin de prendre en charge la double pile dans les clusters, Kubernetes doit connaître et prendre en charge les adresses à double pile pour les pods et les nœuds. Voici un résumé de la proposition (les détails suivent dans les sections suivantes) :
- Kubernetes doit être informé de l'existence de plusieurs adresses IP par pod (limitées à une adresse IPv4 et une adresse IPv6 par pod au maximum) ;
- les adresses locales de liaison (LLA) sur un pod resteront implicites (Kubernetes n'affichera ni ne suivra ces adresses) ;
- Service Cluster IP Range --service-cluster-ip-range= prendra en charge la configuration d'un bloc d'adresses IPv4 et d'un bloc d'adresses IPV6) ;
- les IPs du service seront allouées à partir d'une ou des deux familles d'IPs comme demandé par la spécification du service ou à partir de la première plage d'adresses configurée si le service n'exprime rien au sujet des familles d'IPs ;
- les adresses des points d'extrémité (et non des tranches d'extrémité) correspondront à la première famille d'adresses attribuée au service (par exemple, une IP de service IPv6 n'aura que des points d'extrémité IPv6).
Plan de mise en œuvre
Compte tenu de la portée de cette amélioration, il avait été prévu de diviser la mise en œuvre en phases distinctes qui peuvent être réparties sur plusieurs cycles de publication. Les phases sont les suivantes :
- Phase 1 (Kubernetes 1.16)
- Modifications des types d'API
- Types Kubernetes
- Types de CRI
- mise en réseau des pods à double pile (pods multi-IP)
- support multi-familles de Kubernetes
- Phase 2 (Kubernetes 1.16)
- Services multi-familles incluant kube-proxy
- Collaboration avec un fournisseur CNI pour permettre le support dual-stack
- Mise à jour des drapeaux des composants pour supporter les --bind-address multiples.
- Phase 3 (prévue pour Kubernetes 1.17)
- Support iptables de Kube-proxy pour dual-stack
- Support de l'API descendante pour Pod.Status.PodIPs
- Test du support du plugin CNI e2e pour la double pile
- Prise en charge de Pod hostfile pour l'adresse d'interface IPv6
- Prise en charge de Kind pour la pile double
- Test e2e
- Support de l'API EndpointSlice dans kube-proxy pour dual-stack (IPVS et iptables)
- Support dual-stack pour kubeadm
- Extension du support des runtime de conteneurs (containerd, CRI-O)
- Phase 4 et suivantes
- Adaptation aux retours d'expérience des phases précédentes
- Dépendances externes, par exemple fournisseur de cloud, CNI, CRI, CoreDNS etc...
Pod Security passe en version bêta
Avec la sortie de Kubernetes v1.23, Pod Security est désormais en version bêta. Pod Security est un contrôleur d'admission intégré qui évalue les spécifications des pods par rapport à un ensemble prédéfini de normes de sécurité pour les pods et détermine s'il faut autoriser ou refuser l'exécution du pod. Pod Security est le successeur de PodSecurityPolicy qui a été déprécié dans la version v1.21 et sera supprimé dans Kubernetes v1.25. Il est recommmendé aus administrateurs DevOps et les développeurs d’utiliser ce nouveau mécanisme pour appliquer des valeurs par défaut sécurisées à leurs charges de travail.
Pourquoi Pod Security
L'objectif général de Pod Security est d'isoler les charges de travail. Il est possible de gérer un cluster qui exécute différentes charges de travail et, sans ajouter d'outils tiers supplémentaires, mettre en œuvre des contrôles qui obligent les Pods d'une charge de travail à limiter leurs propres privilèges à un ensemble défini. Pod Security comble les principales lacunes du mécanisme PodSecurityPolicy (PSP) de Kubernetes, existant mais obsolète :
- modèle d'autorisation des politiques, difficile à déployer avec les contrôleurs ;
- Risques liés à la commutation, l'absence de fonctionnalités d'essai/audit a rendu difficile l'activation de PodSecurityPolicy ;
- API incohérente et non bornée, la grande surface de configuration et les contraintes évolutives ont conduit à une API complexe et déroutante.
Les défauts de PodSecurityPolicy l'ont rendu très difficile à utiliser, ce qui a conduit la communauté à réévaluer si une meilleure implémentation pouvait atteindre les mêmes objectifs. L'un de ces objectifs était de fournir une solution prête à l'emploi pour appliquer les meilleures pratiques de sécurité. Pod Security est livré avec des niveaux de sécurité prédéfinis qu'un administrateur de cluster peut configurer en fonction de la posture de sécurité souhaitée.
Il est important de noter que Pod Security ne dispose pas de toutes les fonctionnalités de PodSecurityPolicy, qui a été abandonné. Plus précisément, il n'a pas la capacité de muter ou de modifier les ressources Kubernetes pour remédier automatiquement à une violation de la politique au nom de l'utilisateur. De plus, elle ne fournit pas de contrôle fin sur chaque champ et valeur autorisés dans une spécification de pod ou toute autre ressource Kubernetes.
Pod Security adhère également aux meilleures pratiques de Kubernetes en matière de gestion déclarative des objets en refusant les ressources qui violent la politique. Cela exige que les ressources soient mises à jour dans les dépôts de sources et que les outils soient mis à jour avant d'être déployés dans Kubernetes.
Pod Security est un contrôleur d'admission intégré à partir de Kubernetes 1.22, mais il peut également être exécuté en tant que webhook autonome. Les contrôleurs d'admission fonctionnent en interceptant les demandes dans l’API de Kubernetes avant leur persistance dans le stockage. Ils peuvent soit admettre soit refuser une demande. Dans le cas de la sécurité des pods, les spécifications des pods seront évaluées par rapport à une politique configurée sous la forme d'une norme de sécurité des pods. Cela signifie que les champs sensibles à la sécurité dans une spécification de pod ne seront autorisés à avoir que des valeurs spécifiques.
Source : Kubernetes
Et vous ?
Que pensez vous de Kubernetes ? Quel est votre avis sur la mise en réseau d’IPv4/IPv6 en double pile sur la version 1.23 ?Voir aussi :
Kubernetes 1.18 est disponible et apporte la prise en charge de ContainerD sous Windows, Canonical a déjà annoncé la prise en charge de cette version Canonical introduit Micro-Kubernetes à haute disponibilité, un cluster Kubernetes léger pour les postes de travail, les appareils IdO et l'Edge Computing L'attrait des développeurs pour les conteneurs et Kubernetes est principalement motivé par l'évolution de leur carrière, selon une étude de Red Hat Les dépenses liées à la plateforme d'orchestration de containers Kubernetes sont difficilement maîtrisées, selon un nouveau rapport de la CNCF en collaboration avec a Fondation FinOps