Les entrées/sorties des clusters Kubernetes sont un véritable gâchis, mais de l'aide est en route.

La prolifération d'interfaces, d'API et d'abstractions pour l'entrée et la sortie de Kubernetes a conduit à divers défis dans le monde de l'orchestration de conteneurs.  

Il n'y a pas d'autre façon de décrire la vaste prolifération d'interfaces et d'abstractions pour contrôler le trafic réseau entrant et sortant, également appelé entrées et sorties (E/S), dans les clusters Kubernetes. C'est un véritable gâchis.  

La bonne nouvelle, c'est que la communauté en est consciente et qu'elle s'efforce d'améliorer la situation.

Dans ce blog, nous parlerons de la prolifération et des efforts déployés pour simplifier le paysage.  

Comment en sommes-nous arrivés là ? Brève histoire des entrées/sorties de cluster Kubernetes

Au début, il n'y avait qu'une seule ressource officielle de contrôle d'entrée en amont pour Kubernetes, connue simplement sous le nom d'"ingress". Il était simple et présentait des caractéristiques minimales, ce qui a conduit à la création et au déploiement de plusieurs autres ressources de contrôleurs d'entrée dotées de caractéristiques et d'API différentes permettant d'interagir avec elles.  

La ressource ingress originale de Kubernetes est actuellement en cours de dépréciation en faveur d'une ressource et d'une API de passerelle plus récentes qui ont été développées dans le groupe de travail Kubernetes SIG Network spécifiquement pour répondre à la prolifération d'implémentations similaires, mais différentes, des fonctionnalités ingress.  

Les passerelles API et les réseaux de services partagent la fonctionnalité d'entrée.

Lorsque les solutions de gestion des API ont migré vers le cloud et les solutions Kubernetes sous la forme de passerelles API, un autre contrôle a été ajouté, qui est fonctionnellement un contrôleur d'entrée. Outre la douzaine de contrôleurs d'entrée de Kubernetes, il existe une douzaine de passerelles API Kubernetes qui ajoutent une autre dimension de complexité et de confusion pour les utilisateurs de Kubernetes.  

Et puis il y a les nombreuses implémentations et API de maillage de services qui sont en fait une autre interface d'entrée (dans le réseau maillé mis en œuvre par les mandataires distribués).  Les mêmes besoins fonctionnels que ceux des contrôleurs d'entrée et des passerelles API sont nécessaires pour contrôler le trafic entrant et sortant des passerelles de maillage de service où les E/S des clusters se produisent dans de nombreux réseaux de production.  

En résumé, l'état actuel de la prolifération des interfaces et des API autour des IO de grappes est la somme de toutes ces différentes implémentations dans toutes les différentes catégories de solutions.

Les inconvénients de la prolifération

Cette prolifération présente deux inconvénients majeurs :

• La croissance rapide des interfaces et des API a entraîné une augmentation de la surface d'attaque, les vulnérabilités des API devenant de plus en plus fréquentes.
• Le grand nombre de solutions disponibles pour les contrôleurs d'entrée, les passerelles API et les fonctionnalités de maillage de services crée de la confusion et des complications pour les utilisateurs finaux. Cela a conduit à un environnement où les fournisseurs et les utilisateurs doivent parler plusieurs langues "" pour fournir un support Kubernetes complet pour la politique de sécurité.

À mesure que de nouvelles solutions émergent dans l'écosystème Kubernetes, les fonctionnalités des différentes catégories d'entrée et de sortie se chevauchent de plus en plus. Ce chevauchement est source de confusion pour les personnes qui choisissent des outils et ajoute de la complexité à un paysage déjà difficile.

Pourquoi l'écosystème complexe de Kubernetes a besoin d'une normalisation des politiques.

L'interface de réseau de conteneurs (CNI) définit l'API pour l'envoi du trafic réseau intracluster entre les pods, et il existe un certain nombre d'implémentations interopérables populaires, y compris OVN, Calico, Cilium, etc. Bien qu'il existe des extensions uniques dans les différents produits, ils partagent un noyau commun de capacités de politique de réseau qui permet aux opérateurs de plateforme de spécifier quelles entités activées par le réseau peuvent communiquer et comment.  

Les politiques de réseau sont optimisées pour fournir un environnement d'interdiction par défaut où les règles d'autorisation sont des exceptions à ce comportement basé sur l'identification du trafic en fonction des étiquettes, des espaces de noms, des déploiements et d'autres attributs de métadonnées natifs du nuage. C'est exactement le type de fonctions primitives qui constitueraient une bonne base pour le filtrage du trafic entrant et sortant des clusters Kubernetes. Cependant, la CNI n'a pas de portée extra-cluster et il n'y a donc pas eu de partage de cette approche normalisée dans le monde des contrôleurs d'entrée et des passerelles API.  

Les mailles de service ont tendance à avoir des outils similaires de filtrage du trafic qui n'ont pas d'approche normalisée par rapport à la politique de réseau définie pour les CNI. Le maillage de services introduit également le filtrage de la couche 7 et les listes d'autorisation, qui n'ont pas été considérés comme faisant partie du champ d'application des API de la CNI et dont l'adoption n'a pas encore progressé au sein du groupe de travail de la CNI.  

Les efforts de normalisation de la communauté Kubernetes

Pour résoudre ces problèmes, des groupes prennent diverses initiatives pour normaliser les interfaces et les API d'entrée et de sortie. Il s'agit notamment de plusieurs efforts importants sous la direction du groupe d'intérêt spécial (SIG) du réseau Kubernetes, notamment le groupe de travail sur la politique du réseau, le groupe de travail sur la passerelle et l'initiative GAMMA.

Groupe de travail sur la passerelle

Le groupe de travail Gateway est chargé de développer une API unifiée pour gérer le trafic entrant et sortant dans les clusters Kubernetes. Le projet principal du groupe est l'API Kubernetes Gateway qui est conçue pour fournir une API plus flexible et expressive pour configurer le trafic d'entrée et de sortie deKubernetes6]]. En proposant une API standardisée, le groupe de travail Gateway vise à simplifier le processus de déploiement et de gestion des composants réseau de Kubernetes.

En proposant une API standardisée, le groupe de travail Gateway vise à simplifier le processus de déploiement et de gestion des composants réseau de Kubernetes.

API de la passerelle Kubernetes V1.0

L'API de la passerelle Kubernetes est conçue pour répondre à certaines des limitations et des problèmes associés à la ressource d'entrée d'origine. Ces améliorations répondent aux limites de la ressource d'entrée d'origine et fournissent une approche plus efficace et conviviale de la gestion du trafic réseau dans les environnements Kubernetes.

Pour en savoir plus sur les principales améliorations apportées par le groupe, consultez les ressources suivantes :

• Kubernetes Gateway API Overview
• Guide rapide de la nouvelle passerelle API Kubernetes

Initiative GAMMA

L'initiative GAMMA (Gateway API, Mesh, and Middleware) est un effort de collaboration entre différents SIG Kubernetes et des acteurs de l'industrie. Son objectif est de consolider et de normaliser les API et les interfaces utilisées pour le trafic d'entrée et de sortie de Kubernetes. Cette initiative vise à réduire la confusion et la complexité pour les utilisateurs finaux, en facilitant le déploiement et la gestion des composants réseau de Kubernetes.

Groupe de travail sur la politique des réseaux

Le groupe de travail sur les politiques réseau se concentre sur la définition et la mise en œuvre de politiques réseau pour Kubernetes afin d'améliorer la sécurité et l'isolation entre les pods, les services et les autres entités réseau dans un cluster Kubernetes. Il est largement mis en œuvre par les CNI les plus répandus et n'est donc pas un outil appliqué au trafic d'entrée et de sortie des clusters.  

Le groupe travaille actuellement sur plusieurs projets :

• Politique administrative du réseau : Permet aux administrateurs de clusters de mieux contrôler les politiques de réseau en introduisant un niveau d'abstraction plus élevé. Cela permet aux administrateurs de définir des politiques globales à l'échelle du cluster qui peuvent être appliquées de manière cohérente dans tous les espaces de noms.
• Politique de réseau V2 : Cette version répond aux limites de la mise en œuvre actuelle de la politique de réseau en introduisant de nouvelles fonctionnalités et en étendant l'API existante, telles que la prise en charge du filtrage du trafic de sortie, l'amélioration des capacités de correspondance des politiques et l'amélioration de l'application de la politique pour une meilleure sécurité.

• NetworkPolicy++ : Introduction de fonctionnalités avancées de politique de réseau en étendant l'API de politique de réseau existante. Cela permet un contrôle plus granulaire de la gestion du trafic, de la sécurité et de l'isolation, permettant aux utilisateurs de créer des politiques sophistiquées adaptées à leurs besoins spécifiques.  

L'adoption communautaire remplace les organismes de normalisation

Plus haut dans ce blog, il est fait référence aux efforts de normalisation des abstractions et des API, mais il ne s'agit pas nécessairement d'une approbation de cette normalisation par les organisations traditionnelles de normalisation telles que l'IETF, l'ITU, l'IEEE, etc. Les communautés open-source votent avec le temps de leurs développeurs et leur base de code, de sorte que l'obtention d'une "normalisation" de facto en raison du déploiement généralisé de la communauté est la mesure la plus importante du succès.  

L'introduction de l'API Kubernetes Gateway et la suppression de la ressource ingress est un exemple d'une communauté qui se consacre à l'amélioration de sa plateforme d'infrastructure et qui se réunit pour apporter des changements à grande échelle sans tirer d'avantage concurrentiel de cet investissement.  

Au moment de la publication de ce blog, 19 projets open-source de contrôleurs d'entrée et de maillage de services se trouvaient à différents stades de développement de leur API de passerelle pour remplacer leur précédente implémentation sur mesure. La majorité d'entre eux sont actuellement en version bêta et plusieurs sont en disponibilité générale (GA).  

La mise en œuvre rapide et partagée est la nouvelle façon de normaliser les interfaces logicielles à la vitesse du développement communautaire. Le travail effectué dans le cadre du SIG Réseau n'est pas un travail académique ; la communauté a montré sa volonté de contribuer aux interfaces et API communes définies dans les groupes de travail et de les adopter par la suite. Tout le monde peut participer et contribuer comme il l'entend.  

Vous avez encore des progrès à faire ?

Les travaux actuellement en cours au sein du SIG Réseau permettront de mettre de l'ordre dans la prolifération qui existe actuellement en matière d'E/S en grappes. Cependant, d'autres dimensions de la confusion et de la complexité n'ont pas été ciblées pour être alignées par la communauté.  

Les travaux de l'initiative GAMMA visant à partager les caractéristiques et les API d'entrée avec les travaux du groupe de travail sur les API de passerelle contribuent largement à reconnaître que les exigences fonctionnelles du maillage de services peuvent être très similaires à celles d'un CNI, où l'entrée traditionnelle a lieu pour le maillage de non services.  

Malgré ce travail, il existe toujours un chevauchement fonctionnel entre CNI et service-mesh qui n'est pas aligné. Dans les premiers temps, le CNI a mis en œuvre des politiques de réseau de couches pour filtrer le trafic aux couches 3 et 4 et le service mesh filtrait exclusivement un sous-ensemble de ce trafic en examinant uniquement les éléments de protocole de la couche 7.  

Le groupe de travail sur les politiques de réseau est en train d'évoluer et de normaliser l'API qui sera adoptée par tous les fournisseurs de CNI, mais la plupart des solutions populaires de maillage de services disposent également d'une forme non normalisée d'API de politique de filtrage des couches 3 et 4. Aucun ne prévoit d'aligner cela sur les travaux du groupe de travail sur la politique des réseaux.  

Dans le même temps, il n'existe pas de groupe équivalent essayant de normaliser les API pour le filtrage de la couche 7 qui sont mises en œuvre différemment par les différents réseaux de services (bien que leur utilisation commune du proxy Envoy open-source pour l'application du filtrage aboutisse à une grande uniformité). Sur le plan organisationnel, il pourrait être difficile d'unifier les abstractions entre les différents artefacts logiciels (CNIs vs. maillages de services) parce qu'il n'y a pas de projet chargé de s'en préoccuper et de le mettre en œuvre. D'un point de vue architectural, cela a du sens, mais l'unification pourrait nécessiter une perspective de leadership de la CNCF plutôt qu'une perspective centrée sur le projet.  

Où tout cela finira-t-il ?

En admettant qu'un chevauchement fonctionnel continu entre les CNI et les maillages de services est inévitable, l'objectif du Network SIG devrait être en fin de compte de définir une API commune pour les fonctions pertinentes de sécurité, de gestion du trafic et de routage, qu'elles soient mises en œuvre dans un produit présenté sous la forme d'un CNI, d'un maillage de services ou d'une autre manière d'offrir une abstraction de réseau virtuel.  

Les experts de l'infrastructure Kubernetes soulèveront quelques bonnes objections fondées sur les principes architecturaux qui différencient un CNI d'un maillage de services et dictent une séparation logique des fonctionnalités et des normes. Mais du point de vue de l'interface utilisateur, il y a un risque d'être sourd et d'exposer les utilisateurs du système à une interface ascendante, centrée sur le développeur du système, qui expose les "boutons de nerd".  

S'il est naturel pour les utilisateurs de penser qu'un fournisseur de CNI et un maillage de services mettent en œuvre leur pile de réseaux et leurs fonctions, l'attrait de la plateforme pourrait être renforcé par le partage d'abstractions et d'API plus communes.  La politique de réseau dispose d'un riche ensemble de primitives de filtrage pour sélectionner le trafic et effectuer des actions conditionnelles. Il pourrait être étendu et amélioré pour gérer toutes les règles de correspondance/action abstraites et conscientes de Kubernetes pour les réseaux intra-cluster, inter-cluster et extra-cluster.  

Faites-nous savoir ce que vous pensez de la valeur des abstractions communes dans tous les cas d'utilisation du traitement du trafic. Si vous vous intéressez à ce sujet, gardez un œil sur ce travail qui progresse rapidement et qui affectera beaucoup d'utilisateurs de Kubernetes.  

Pour en savoir plus sur Illumio, contactez-nous dès aujourd'hui.