Réseaux Kubernetes 101

NodePort, LoadBalancer, contrôleur d’entrée… oh mon Dieu !

Lorsque nous discutons avec les clients et la communauté de la manière de rendre Kubernetes de niveau production, l’une des questions les plus courantes est : ai-je besoin d’un contrôleur Ingress ? La réponse à cette question est rarement un simple oui ou non, mais implique plutôt une certaine formation sur les différentes manières dont vous pouvez générer du trafic vers vos pods. Dans ce blog, nous abordons les bases de la mise en réseau Kubernetes afin que vous puissiez prendre une décision éclairée quant à savoir si – et quand – vous avez besoin d'un contrôleur Ingress.

Kubernetes prend en charge plusieurs approches et couches possibles pour acheminer le trafic externe vers un pod, mais elles ne sont pas toutes égales. Le modèle par défaut est kube-proxy , qui n'est pas réellement un proxy et n'est pas conçu pour équilibrer la charge du trafic, contrôler les API ou surveiller les comportements des services.

Heureusement, il existe d’autres moyens de gérer le trafic externe, mais avant de continuer, passons rapidement en revue les composants de Kubernetes :

• Les déploiements Kubernetes sont constitués de nœuds , qui sont des machines physiques ou virtuelles.
• Les nœuds se rejoignent pour former un cluster .
• Chaque cluster gère des pods , qui constituent le plus petit dénominateur commun au niveau du réseau et de l'infrastructure dans Kubernetes. Un ou plusieurs pods constituent ensemble un service .
• À l'intérieur de chaque pod se trouvent un ou plusieurs conteneurs (selon la taille de l'application).

Kubernetes surveille les pods qui composent un service et les met à l'échelle si nécessaire pour répondre aux exigences de l'application. Mais comment générer du trafic vers les pods ? C'est là qu'interviennent deux types d'objets Kubernetes : les services et les contrôleurs d'entrée.

Qu'est-ce qu'un service Kubernetes ?

Selon la documentation Kubernetes , un service est « une manière abstraite d’exposer une application exécutée sur un ensemble de Pods ». Un service connecte des pods dans un cluster ou un réseau de conteneurs de telle sorte que leur emplacement sur un nœud spécifique ne soit pas pertinent. Cela signifie que le trafic externe peut être acheminé vers des pods spécifiques même lorsque leurs emplacements changent, ou même lorsqu'ils sont détruits et redémarrés. De cette façon, un service agit comme un proxy inverse très basique.

Il existe plusieurs types de services et de types d’objets de service pertinents pour le routage du trafic externe vers Kubernetes. On les confond souvent, mais en fait chacun fait des choses très différentes, il vaut donc la peine de passer en revue leurs fonctions, leurs utilisations et leurs inconvénients.

IP du cluster

ClusterIP est le service par défaut qui fournit un service dans Kubernetes auquel d'autres services du cluster peuvent accéder. Il n'est pas accessible depuis l'extérieur du cluster. La seule façon d’exposer un service ClusterIP est d’utiliser quelque chose comme kube-proxy , mais il existe peu de scénarios où cela a du sens. Les exemples limités incluent l'accès à un service sur votre ordinateur portable, le débogage d'un service ou l'examen de certaines mesures de surveillance.

NodePort

Un service NodePort ouvre un port spécifique sur chaque nœud du cluster et transfère tout trafic envoyé au nœud sur ce port vers l'application correspondante. Il s'agit d'une méthode très simple pour acheminer le trafic vers vos applications, mais elle présente de nombreuses limitations dans les cas d'utilisation réels de gestion du trafic. Vous ne pouvez avoir qu'un seul service par NodePort et vous ne pouvez utiliser que les ports compris entre 30 000 et 32 767. Même si 2 768 ports peuvent sembler beaucoup, les organisations exécutant Kubernetes à grande échelle en épuiseront rapidement la capacité. De plus, NodePort utilise des règles de routage de couche 4 et l’utilitaire Linux iptables , qui limite le routage de couche 7.

Outre les limitations de routage, l’utilisation de NodePort présente trois autres inconvénients majeurs :

• Les clients en aval doivent connaître l’adresse IP de chaque nœud pour s’y connecter. Cela devient problématique si l’adresse IP du nœud ou l’hôte de la machine virtuelle change.

• NodePort ne peut pas acheminer le trafic vers plusieurs adresses IP.

• Comme le montre le diagramme, NodePort ne fournit pas d’équilibrage de charge au sein des clusters Kubernetes, le trafic est donc réparti de manière aléatoire entre les services. Cela peut entraîner une surcharge de service et un épuisement des ports.

  

Équilibreur de charge

Un service LoadBalancer accepte le trafic externe mais nécessite un équilibreur de charge externe comme interface pour ce trafic. Cela prend en charge le routage de couche 7 (vers les adresses IP des pods), à condition que l'équilibreur de charge externe soit correctement réglé et reconfiguré pour être mappé aux pods en cours d'exécution. LoadBalancer est l’un des moyens les plus populaires d’exposer des services en externe. Il est le plus souvent utilisé sur une plateforme cloud et constitue un bon choix pour les petits déploiements statiques.

Si vous utilisez un service Kubernetes géré, vous obtenez automatiquement l'équilibreur de charge sélectionné par le fournisseur de cloud. Par exemple, sur Google Cloud Platform, vous pouvez créer un équilibreur de charge réseau à l'aide du type de service LoadBalancer, tandis qu'Application Load Balancer (ALB) est la valeur par défaut dans AWS. Chaque service que vous exposez obtient sa propre adresse IP publique qui transfère tout le trafic, mais sans aucun filtrage ni routage, ce qui signifie que vous pouvez envoyer presque n'importe quel type de trafic (HTTP, TCP/UDP, WebSocket, etc.). Alternativement, si vous ne souhaitez pas utiliser les outils du fournisseur de cloud (par exemple si vous avez besoin de fonctionnalités supérieures ou d'un outil indépendant de la plateforme), vous pouvez le remplacer par quelque chose comme F5 BIG-IP (en tant qu'équilibreur de charge externe) et F5 Container Ingress Services (en tant qu'opérateur agissant en tant que LoadBalancer). Pour plus d’informations sur ce modèle, consultez Déploiement de BIG-IP et NGINX Ingress Controller dans la même architecture sur notre blog.

L’utilisation de LoadBalancer pour exposer vos applications devient un défi dans les environnements dynamiques où vos pods d’applications doivent évoluer pour répondre aux niveaux de demande changeants. Étant donné que chaque service dispose de sa propre adresse IP, une application populaire peut avoir des centaines, voire des milliers, d’adresses IP à gérer. Dans la plupart des cas, l’équilibreur de charge externe se connecte aux services via NodePort comme indiqué dans le diagramme suivant. Bien que cela garantisse une répartition uniforme du trafic entre les nœuds, l’équilibrage de la charge entre les services n’est toujours pas possible, ce qui entraîne toujours une surcharge de service et un épuisement des ports.

Qu'est-ce qu'un contrôleur d'entrée Kubernetes ?

Selon la documentation de Kubernetes , « les contrôleurs sont des boucles de contrôle qui surveillent l'état de votre cluster, puis effectuent ou demandent des modifications si nécessaire. Chaque contrôleur essaie de rapprocher l’état actuel du cluster de l’état souhaité. Les contrôleurs sont utilisés pour gérer l'état dans Kubernetes pour de nombreuses tâches : attribuer correctement les ressources, désigner le stockage persistant et gérer les tâches cron.

Dans le contexte du routage, un contrôleur Ingress est le moyen de surmonter les limitations de NodePort et LoadBalancer.

Un contrôleur d'entrée est utilisé pour configurer et gérer les interactions externes avec des pods étiquetés pour un service spécifique. Les contrôleurs d’entrée sont conçus pour traiter le routage dynamique de couche 7 comme un citoyen de première classe. Cela signifie que les contrôleurs Ingress offrent un contrôle et une gestion beaucoup plus précis avec moins de travail. Vous pouvez facilement utiliser un contrôleur d’entrée non seulement pour contrôler le trafic entrant, mais également pour fournir des mesures de performances au niveau du service et dans le cadre d’une politique de sécurité. Les contrôleurs d'entrée présentent de nombreuses fonctionnalités des équilibreurs de charge externes traditionnels, comme la terminaison TLS, la gestion de plusieurs domaines et espaces de noms et, bien sûr, l'équilibrage de la charge du trafic. Les contrôleurs d'entrée peuvent équilibrer la charge du trafic au niveau de chaque demande plutôt qu'au niveau de chaque service, ce qui offre une vue plus utile du trafic de couche 7 et constitue un bien meilleur moyen d'appliquer les SLA.

Et il y a un autre bonus ! Les contrôleurs d'entrée peuvent également appliquer des règles de sortie qui autorisent le trafic sortant de certains pods uniquement vers des services externes spécifiques, ou garantir que le trafic est mutuellement chiffré à l'aide de mTLS. L'exigence de mTLS est essentielle pour fournir des services réglementés dans des secteurs tels que la santé, la finance, les télécommunications et le gouvernement - et c'est un élément clé d'une stratégie de cryptage de bout en bout (E2EE). Le contrôle du trafic sortant à partir du même outil simplifie également l’application de la logique métier aux services. Il est beaucoup plus facile de configurer des règles de ressources appropriées lorsque l’entrée et la sortie sont liées dans le même plan de contrôle.

Le diagramme suivant montre comment un contrôleur Ingress réduit la complexité pour le client, qui n’a plus besoin de connaître l’adresse IP ou le port d’un service. La répartition du trafic entre les services est garantie. Certains contrôleurs Ingress prennent en charge plusieurs algorithmes d’équilibrage de charge pour plus de flexibilité et de contrôle.

Déploiement d'un équilibreur de charge avec un contrôleur d'entrée

Comme nous le voyons dans Déploiement de BIG-IP et NGINX Ingress Controller dans la même architecture , de nombreuses organisations ont des cas d’utilisation qui bénéficient du déploiement d’un équilibreur de charge externe avec un contrôleur Ingress (ou dans la plupart des cas, plusieurs instances de contrôleur Ingress). Cela est particulièrement courant lorsque les organisations doivent faire évoluer Kubernetes ou fonctionner dans des environnements à haute conformité. Les outils sont généralement gérés par différentes équipes et utilisés à des fins différentes :

• Équilibreur de charge (ou ADC) :

  • Propriétaire: Une équipe NetOps (ou peut-être SecOps)
  • Cas d'utilisation : En dehors de Kubernetes comme seul point de terminaison public pour les services et applications fournis aux utilisateurs en dehors du cluster. Utilisé comme un appareil plus générique conçu pour faciliter la sécurité et fournir une gestion de réseau de niveau supérieur.

• Contrôleur d'entrée :

  • Propriétaire: Une équipe Platform Ops ou DevOps
  • Cas d'utilisation : À l'intérieur de Kubernetes pour un équilibrage de charge précis du trafic nord-sud (HTTP2, HTTP/HTTPS, terminaison SSL/TLS, TCP/UDP, WebSocket, gRPC), des fonctions de passerelle API et une sécurité et une identité centralisées.

Ce diagramme montre la répartition de la gestion du trafic par l'équilibreur de charge sur plusieurs clusters, tandis que les clusters disposent de contrôleurs d'entrée pour assurer une répartition égale des services.

Prochaines étapes

Si vous avez lu tout cela et que vous vous grattez toujours la tête, consultez le webinaire de la Linux Foundation Pourquoi vous avez besoin d'un contrôleur d'entrée et comment en choisir un , où les experts de NGINX fournissent une introduction à la mise en réseau Kubernetes, plongent en profondeur dans les contrôleurs d'entrée et discutent du paysage des contrôleurs d'entrée.

Pour en savoir plus sur la façon dont vous pouvez utiliser un contrôleur Ingress et comment choisir celui qui répond le mieux à vos besoins, lisez Guide pour choisir un contrôleur Ingress, partie 1 : Identifiez vos besoins sur notre blog.