Les E/S du cluster Kubernetes sont un véritable gâchis, mais de l'aide est en route

La prolifération des interfaces, des API et des abstractions pour l'entrée et la sortie de Kubernetes a entraîné de nombreux défis dans le monde de l'orchestration des conteneurs.

Il n'y a pas d'autre moyen de décrire la vaste prolifération d'interfaces et d'abstractions permettant de contrôler le trafic réseau entrant et sortant, également appelé entrées et sorties (E/S), dans les clusters Kubernetes. C'est un gros bordel.

La bonne nouvelle, c'est que la communauté en est consciente et qu'elle travaille pour améliorer les choses.

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

Comment en sommes-nous arrivés là ? Bref historique des E/S du cluster Kubernetes

Au début, il n'existait qu'une seule ressource officielle de contrôle des entrées en amont pour Kubernetes, connue simplement sous le nom d' « entrée ». Il était simple et comportait des fonctionnalités minimales qui ont conduit à la création et au déploiement de plusieurs autres ressources de contrôleur d'entrée dotées de fonctionnalités et d'API différentes pour interagir avec elles.

La ressource d'entrée Kubernetes d'origine est actuellement en passe de devenir obsolète au profit d'une ressource de passerelle et d'une API plus récentes qui ont été développées au sein du groupe de travail Kubernetes SIG Network spécifiquement pour faire face à la prolifération d'implémentations similaires mais différentes des fonctionnalités d'entrée.

Les passerelles API et les maillages de services partagent les mêmes fonctionnalités d'entrée

Au fur et à mesure de la migration des solutions de gestion des API vers le cloud et des 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 Kubernetes, il existe une douzaine de passerelles API Kubernetes qui ajoutent une autre dimension de complexité et de confusion aux utilisateurs de Kubernetes.

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

En résumé, l'état actuel de la prolifération des interfaces et des API autour du cluster IO est la somme de toutes ces différentes implémentations dans 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, avec des vulnérabilités d'API de plus en plus répandue.
• Le grand nombre de solutions disponibles pour les contrôleurs d'entrée, les passerelles API et la fonctionnalité de maillage de services crée de la confusion et des complications pour les utilisateurs finaux. Cela a conduit à un environnement dans lequel les fournisseurs et les utilisateurs doivent parler plusieurs « langues » pour fournir une assistance complète à Kubernetes en matière de politique de sécurité.

À mesure que de nouvelles solutions apparaissent 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 crée de la confusion chez 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 standardisation des politiques

L'interface réseau de conteneurs (CNI) définit l'API pour envoyer du trafic réseau intra-cluster entre les pods, et il existe un certain nombre d'implémentations interopérables populaires, notamment OVN, Calico, Cilium, etc. Bien que les différents produits comportent des extensions uniques, ils partagent un noyau commun de fonctionnalités de politique réseau qui permettent aux opérateurs de plateformes de spécifier quelles entités connectées au réseau peuvent communiquer et comment.

Les politiques réseau sont optimisées pour fournir un environnement de refus par défaut dans lequel les règles d'autorisation constituent des exceptions à ce comportement en fonction de l'identification du trafic sur la base d'étiquettes, d'espaces de noms, de déploiements et d'autres attributs de métadonnées natifs du cloud. 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, le CNI n'a pas de portée extra-cluster et cette approche standardisée n'a donc pas été partagée dans le monde des contrôleurs d'entrée et des passerelles API.

Les maillages de services ont tendance à utiliser des outils de politique de filtrage du trafic similaires qui n'ont pas d'approche standardisée par rapport à la politique réseau définie pour les CNI. Service Mesh introduit également un filtrage de couche 7 et des listes d'autorisations qui n'étaient pas considérés comme relevant du champ d'application des API CNI et dont l'adoption n'a pas encore progressé au sein du groupe de travail CNI.

Efforts de standardisation déployés par la communauté Kubernetes

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

Groupe de travail Gateway

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 le API Kubernetes Gateway qui est conçu pour fournir une API plus flexible et plus expressive pour configurer le trafic entrant et sortant de Kubernetes6]. En proposant une API standardisée, le Gateway Working Group vise à simplifier le processus de déploiement et de gestion des composants réseau Kubernetes.

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

API Kubernetes Gateway V1.0

L'API Kubernetes Gateway est conçue pour résoudre certains problèmes et limites liés à la ressource d'entrée d'origine. Ces améliorations répondent aux limites de la ressource d'entrée d'origine et proposent une approche plus efficace et plus 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, accédez à ces ressources :

• Présentation de l'API Kubernetes Gateway
• Guide rapide de la nouvelle passerelle API Kubernetes

Initiative GAMMA

Le Initiative GAMMA (API de passerelle, maillage et intergiciel) est le fruit d'une collaboration entre les différents SIG de Kubernetes et les parties prenantes du secteur. Son objectif est de consolider et de standardiser les API et les interfaces utilisées pour le trafic entrant et sortant 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 Kubernetes.

Groupe de travail sur les politiques de réseau

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 d'un cluster Kubernetes. Il prend actuellement en charge un ensemble complet d'outils pour spécifier le trafic réseau. Il est largement mis en œuvre par les CNI les plus populaires et n'est donc pas un outil appliqué au trafic entrant/sortant des clusters.

Le groupe travaille actuellement sur plusieurs projets :

• Stratégie réseau administrative : permet aux administrateurs de clusters de mieux contrôler les politiques 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.
• Network Policy V2 : pallie les limites de la mise en œuvre actuelle de la politique réseau en introduisant de nouvelles fonctionnalités et en étendant l'API existante, telles que la prise en charge du filtrage du trafic sortant, des fonctionnalités améliorées de correspondance des politiques et une meilleure application des politiques pour une meilleure sécurité.

• NetworkPolicy++ : Présentation de fonctionnalités avancées de politique réseau en étendant l'API Network Policy existante. Cela permet un contrôle plus précis 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 à des efforts visant à standardiser les abstractions et les API, mais cela ne signifie pas nécessairement que les organisations de normalisation traditionnelles telles que l'IETF, l'UIT, l'IEEE, etc. Les communautés open source votent en fonction du temps de leurs développeurs et de leur base de code. Réaliser une « standardisation » de facto grâce à un déploiement communautaire généralisé est donc la mesure de réussite la plus importante.

L'introduction de l'API Kubernetes Gateway et la dépréciation de la ressource d'entrée sont un exemple de communauté dédiée à l'amélioration de sa plate-forme d'infrastructure qui s'est réunie pour apporter des changements de grande envergure sans tirer aucun avantage concurrentiel de cet investissement.

Au moment de la publication de ce blog, 19 projets de contrôleurs d'entrée et de maillage de services open source en étaient à différents stades de développement de l'implémentation 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 le nouveau moyen de standardiser les interfaces logicielles au rythme du développement communautaire. Le travail effectué dans le Network SIG 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, puis de les adopter. Tout le monde peut participer et contribuer comme bon lui semble.

Y a-t-il encore matière à amélioration ?

Les travaux actuellement en cours au sein du Network SIG permettront de remédier en grande partie au problème de prolifération qui existe actuellement en ce qui concerne les E/S des clusters. Cependant, d'autres aspects de confusion et de complexité n'ont pas été ciblés par la communauté.

Les travaux de l'initiative GAMMA visant à partager les fonctionnalités d'entrée et les API avec les travaux du groupe de travail sur les API de passerelle contribuent dans une large mesure à reconnaître que les exigences fonctionnelles du maillage de services peuvent être très similaires à celles d'un CNI, où l'entrée traditionnelle se produit pour un maillage hors service.

Malgré ces travaux, il existe toujours un chevauchement fonctionnel entre le CNI et le maillage de services qui n'est pas aligné. Au début, le CNI a mis en œuvre des politiques de réseau de couches pour filtrer le trafic aux couches 3 et 4 et le maillage de services filtrait exclusivement un sous-ensemble de ce trafic en examinant uniquement les éléments du protocole de couche 7.

Le groupe de travail sur les politiques réseau évolue et normalise l'API qui sera adoptée par les différents fournisseurs CNI, mais la plupart des solutions de maillage de services les plus populaires disposent également d'une forme non standardisée d'API de politique de filtrage des couches 3 et 4. Aucun n'a l'intention d'aligner cela sur les travaux du groupe de travail sur la politique des réseaux.

Dans le même temps, aucun groupe équivalent n'essaie de normaliser les API pour le filtrage de couche 7 qui sont mises en œuvre différemment par les différents maillages de services (bien que leur utilisation partagée du proxy Envoy open source pour l'application du filtrage se traduise par une grande uniformité). Sur le plan organisationnel, il peut être difficile d'unifier les abstractions entre les différents artefacts logiciels (CNI ou maillages de services) car aucun projet n'est chargé de s'en occuper et de le mettre en œuvre. D'un point de vue architectural, cela est logique, mais l'unification pourrait prendre une perspective de direction de la CNCF plutôt que d'une perspective centrée sur le projet.

Où tout cela va-t-il aboutir ?

Accepter que le chevauchement fonctionnel continu entre les CNI et les maillages de services est inévitable signifie que l'objectif du Network SIG devrait finalement être de définir une API commune pour les fonctionnalités de sécurité, de gestion du trafic et de routage pertinentes, qu'elles soient implémentées dans un package sous forme de CNI, de maillage de services ou d'un autre moyen de fournir une abstraction réseau virtuelle.

Les experts de l'infrastructure de Kubernetes soulèveront quelques bonnes objections sur la base des 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'expérience utilisateur, il existe un risque de 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 nerd ».

S'il est naturel pour les utilisateurs de penser à la fois à un fournisseur CNI et à un maillage de services pour implémenter leur pile réseau et leurs fonctionnalités, cela pourrait améliorer l'attrait de la plate-forme pour partager des abstractions et des API plus courantes. La politique réseau comprend un ensemble complet de primitives de filtrage permettant de sélectionner le trafic et d'effectuer des actions conditionnelles. Il pourrait être étendu et amélioré pour gérer toutes les règles de match/action abstraites et compatibles avec Kubernetes pour les réseaux intra-clusters, inter-clusters et extra-clusters.

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

En savoir plus sur Illumio par en nous contactant aujourd'hui.