Dire la fortune

Kubernetes a déjà joué un rôle important dans mon travail, et à l'avenir, il deviendra encore plus important. Mais 2018 touche à sa fin, alors oubliez la modestie et faites une prédiction audacieuse:

L'avenir de Kubernetes, ce sont les machines virtuelles, pas les conteneurs

Selon l'horoscope chinois, 2018 était l'année du chien, mais dans la technologie, c'était l'année de Kubernetes. Nombreux sont ceux qui découvrent à présent cette technologie révolutionnaire, et les services informatiques du monde entier tentent de développer une «stratégie Kubernetes» [1]. Certaines organisations ont déjà transféré d'importantes charges de travail à Kubernetes.

[1] Si vous essayez de développer une stratégie Kubernetes, vous avez déjà échoué, mais c'est un sujet pour un autre article.

En d'autres termes, il y a beaucoup de gens chez Kubernetes à chaque étape du cycle de sensation Gartner. Certains sont coincés dans un creux de déception ou noyés dans un gouffre de désespoir.


Jeremykemp, Wikipedia . Creative Commons CC BY-SA 3.0

Je suis un grand fan des conteneurs et je ne dirai pas que les conteneurs sont morts . En 2013, Docker nous a offert un shell pour les conteneurs Linux: une nouvelle façon étonnante de créer, empaqueter, partager et déployer des applications. Il est apparu au bon moment, car nous avons commencé à prendre au sérieux la livraison continue. Leur modèle est devenu idéal pour la chaîne de livraison et a contribué à l'émergence de la plateforme PaaS puis CaaS.



Les ingénieurs de Google ont vu que la communauté informatique était enfin prête pour les conteneurs. Google utilise des conteneurs depuis très longtemps et, dans un sens, ils peuvent être considérés comme les inventeurs de la conteneurisation. Ils ont commencé à développer Kubernetes. Comme vous le savez maintenant, il s'agit de la réincarnation gratuite de la propre plateforme Borg de Google.

Bientôt, le support de Kubernetes a été fourni par tous les grands clouds (GKE, AKS, EKS). Les services sur site ont également rapidement augmenté les plateformes basées sur Kubernetes (Pivotal Container Service, Openshift, etc.).

Multi-location souple

Il était nécessaire de résoudre un problème ennuyeux, qui peut être considéré comme un manque de conteneurs ... il s'agit de la multi-location.

Les conteneurs Linux n'ont pas été créés en tant que sandbox sécurisés (comme les zones Solaris ou les prisons FreeBSD). Au lieu de cela, ils ont construit sur un modèle de noyau commun qui utilise les fonctions du noyau pour fournir une isolation de processus de base. Comme dirait Jesse Frazel , «les conteneurs ne sont pas la vraie chose».


Cette situation est aggravée par le fait que la plupart des composants de Kubernetes ne connaissent pas les locataires. Bien sûr, vous avez des espaces de noms Pod et des politiques de sécurité , mais il n'y a rien de tel dans l'API. Ainsi que dans les composants internes tels que kubelet ou kube-proxy . Cela conduit au fait que Kubernetes met en œuvre le modèle du «loyer modéré» (location modérée).


Architecture de Kubernetes

Les abstractions s'infiltrent davantage. Une plate-forme au-dessus des conteneurs hérite de nombreux aspects de la location modérée. Les plates-formes au-dessus des machines virtuelles multi-locataires héritent de ce bail sévère (VMware, Amazon Web Services, OpenStack, etc.).

Le modèle de location souple de Kubernetes place les fournisseurs de services et les distributions dans une position étrange. Le cluster Kubernetes lui-même est en train de devenir une ligne de «location ferme». Même au sein d'une même organisation, il existe de nombreuses raisons d'exiger un loyer ferme entre les utilisateurs (ou applications). Étant donné que les clouds publics fournissent Kubernetes entièrement géré en tant que service, les clients peuvent facilement prendre leur propre cluster et utiliser la limite du cluster comme point d'isolement.

Certaines distributions Kubernetes, telles que Pivotal Container Service (PKS) , sont bien conscientes de ce problème de location et utilisent un modèle similaire, fournissant le même Kubernetes qu'un service qui peut être obtenu à partir d'un cloud public, mais dans votre propre centre de données.

Cela a conduit à l'émergence du modèle «plusieurs grappes», au lieu de «une grande grappe commune». Souvent, les clients GKE de Google ont déployé des dizaines de clusters Kubernetes pour plusieurs équipes. Souvent, chaque développeur obtient son propre cluster. Ce comportement génère un nombre choquant d'instances (Kubesprawl).

Alternativement, les opérateurs élèvent leurs propres clusters Kubernetes dans leurs propres centres de données pour effectuer des travaux supplémentaires pour gérer plusieurs clusters, ou conviennent de louer à bail un ou deux grands clusters.

En règle générale, le plus petit cluster est composé de quatre machines (ou machines virtuelles). Un (ou trois pour HA) pour Kubernetes Master, trois pour Kubernetes Workers. Beaucoup d'argent est dépensé pour des systèmes qui, pour la plupart, sont inactifs.

Par conséquent, vous devez en quelque sorte déplacer Kubernetes vers une multi-location rigide. La communauté Kubernetes est bien consciente de ce besoin. Un groupe de travail à baux multiples a déjà été formé. Elle travaille dur sur cette question, et ils ont plusieurs modèles et suggestions sur la façon de travailler avec chaque modèle.

Jesse Frazel a écrit un blog sur ce sujet, et c'est génial parce qu'elle est beaucoup plus intelligente que moi, donc je peux me référer à elle et me sauver de dix années d'études intenses, en essayant d'atteindre son niveau. Si vous n'avez pas lu cet article, lisez-le maintenant.

Juste de très petites machines virtuelles optimisées pour la vitesse ...

Kata Containers est un projet open source et une communauté travaillant à créer une implémentation standard de machines virtuelles légères qui ressemblent et fonctionnent comme des conteneurs mais offrent une isolation de la charge de travail et des avantages de sécurité pour les machines virtuelles.

Jesse suggère d'utiliser la technologie de conteneur VM, comme les conteneurs Kata . Ils offrent une isolation de niveau VM, mais fonctionnent comme des conteneurs. Cela permet à Kubernetes de donner à chaque "locataire" (nous supposons que le locataire dans l'espace de noms) son propre ensemble de services système Kubernetes s'exécutant dans des conteneurs de VM imbriqués (le conteneur de VM à l'intérieur de la machine virtuelle fournie par l'infrastructure IaaS).


Image de Jesse Frasel: multi-location à Kubernetes

Il s'agit d'une élégante solution multi-location Kubernetes. Sa proposition va encore plus loin pour que Kubernetes utilise des conteneurs de VM imbriqués pour les charges de travail (Pods) fonctionnant sur Kubernetes, ce qui permet une augmentation significative de l'utilisation des ressources.

Il nous reste au moins une optimisation. Créez le bon hyperviseur pour le fournisseur d'infrastructure sous-jacent ou le fournisseur de cloud. Si le conteneur VM est une abstraction de premier niveau fournie par IaaS, nous augmenterons encore l'utilisation des ressources. Le nombre minimum de VM pour démarrer un cluster Kubernetes est réduit à une machine (ou trois pour HA) pour héberger le système de gestion Kubernetes, qui est disponible pour le "superutilisateur".

Hébergement multiclient optimisé en termes de ressources (coût)

Un déploiement Kubernetes avec deux espaces de noms et plusieurs applications en cours d'exécution ressemblera à ceci:

Remarque: il existe d'autres charges sur la même infrastructure IaaS. Étant donné qu'il s'agit de conteneurs de VM, ils ont le même niveau d'isolement que les VM de cloud conventionnelles. Par conséquent, ils peuvent travailler sur le même hyperviseur avec un risque minimal.

Au départ, aucune infrastructure n'est déployée dans le cloud, donc pour un superutilisateur les coûts sont nuls.

Un superutilisateur demande un cluster Kubernetes à partir du cloud. Le fournisseur de services cloud crée une machine virtuelle avec un conteneur (ou trois pour HA) qui exécute les principales API Kubernetes et les services système. Le superutilisateur peut déployer des modules dans l'espace de noms du système ou créer de nouveaux espaces pour déléguer l'accès à d'autres utilisateurs.

Le superutilisateur crée deux espaces de noms foo et bar . Kubernetes demande deux conteneurs de VM à partir du cloud pour chaque niveau de gestion des espaces de noms (Kubernetes API et System Services). Le superutilisateur délègue l'accès à ces espaces de noms à certains utilisateurs, chacun d'eux lance des charges de travail (modules), et les conteneurs VM demandent ces conteneurs pour ces charges de travail.

À toutes les étapes, le superutilisateur ne paie que pour les ressources réellement consommées. Le fournisseur de services cloud contrôle ces ressources et elles sont disponibles pour tout utilisateur de cloud.

Je ne dis rien de nouveau ...

Les fournisseurs de services cloud travaillent déjà dans cette direction. Vous pouvez le vérifier en regardant les événements de la communauté (Amazon a peut-être déjà fait cela tranquillement avec Fargate).

Le premier conseil est Virtual Kubelet , un outil open source conçu pour se déguiser en kubelet. Il connecte Kubernetes à d'autres API, ce qui permet à Kubernetes de demander des conteneurs de VM à un planificateur standard dans le cloud.

D'autres indices sont un grand nombre de nouvelles technologies pour la conteneurisation de VM, comme les conteneurs Kata déjà mentionnés, ainsi que Firecracker d'Amazon et le conseiller de Google.

Conclusion

Si vous implémentez correctement des améliorations dans le modèle d'un loyer dur, vous trouverez la virtualisation Holy Graal of Kubernetes. Isolation complète des charges de travail et sans frais supplémentaires.

Si vous n'utilisez pas le cloud public, vous bénéficiez toujours des avantages d'une utilisation plus élevée des ressources, ce qui est payant avec des exigences matérielles plus faibles.

Espérons que VMware et OpenStack prêtent attention et libèrent des hyperviseurs basés sur des conteneurs de VM légers et les implémentations correspondantes de Virtual Kubelet.