KubernetesIngresses vous permet d'acheminer de manière flexible le trafic de l'extérieur de votre cluster Kubernetes vers les services à l'intérieur de votre cluster. Ceci est accompli à l'aide d'IngressResources, qui définissent les règles de routage du trafic HTTP et HTTPS vers les services Kubernetes, et d'IngressControllers, qui implémentent les règles en équilibrant la charge du trafic et en l'acheminant vers les services backend appropriés. Les contrôleurs d'entrée les plus courants incluentNginx,Contour,HAProxy etTraefik. Les entrées offrent une alternative plus efficace et flexible à la configuration de plusieurs services LoadBalancer, chacun utilisant son propre Load Balancer dédié.

Dans ce guide, nous allons configurer lesNginx Ingress Controller gérés par Kubernetes et créer des ressources Ingress pour acheminer le trafic vers plusieurs services backend factices. Une fois que nous aurons configuré Ingress, nous installeronscert-manager dans notre cluster pour gérer et provisionner des certificats TLS pour chiffrer le trafic HTTP vers Ingress.

Avant de commencer avec ce guide, vous devez disposer des éléments suivants:

Une fois ces composants configurés, vous êtes prêt à commencer par ce guide.

[[step-1 -—- setting-up-dummy-backend-services]] == Étape 1 - Configuration des services de backend factices

Avant de déployer Ingress Controller, nous allons d'abord créer et déployer deux services d'écho factices vers lesquels nous acheminerons le trafic externe à l'aide d'Ingress. Les services d'écho exécuteront le conteneur du serveur Web dehashicorp/http-echo, qui renvoie une page contenant une chaîne de texte transmise au lancement du serveur Web. Pour en savoir plus surhttp-echo, consultez sesGitHub Repo, et pour en savoir plus sur les services Kubernetes, consultezServices dans la documentation officielle de Kubernetes.

Sur votre machine locale, créez et modifiez un fichier appeléecho1.yaml à l'aide denano ou de votre éditeur préféré:

Collez le manifeste de service et de déploiement suivant:

echo1.yaml

Dans ce fichier, nous définissons un service appeléecho1 qui achemine le trafic vers les pods avec le sélecteur d'étiquetteapp: echo1. Il accepte le trafic TCP sur le port80 et l’achemine vers le port5678, le port par défaut dehttp-echo.

Nous définissons ensuite un déploiement, également appeléecho1, qui gère les pods avec lesapp: echo1Label Selector. Nous spécifions que le déploiement doit avoir 2 réplicas de pod et que les pods doivent démarrer un conteneur appeléecho1 exécutant l'imagehashicorp/http-echo. Nous passons le paramètretext et le définissons surecho1, de sorte que le serveur Web dehttp-echo renvoieecho1. Enfin, nous ouvrons le port5678 sur le conteneur Pod.

Une fois que vous êtes satisfait de votre manifeste factice de service et de déploiement, enregistrez et fermez le fichier.

Ensuite, créez les ressources Kubernetes en utilisantkubectl create avec l'indicateur-f, en spécifiant le fichier que vous venez d'enregistrer en tant que paramètre:

Vous devriez voir la sortie suivante:

Vérifiez que le service a démarré correctement en confirmant qu'il dispose d'un ClusterIP, l'adresse IP interne sur laquelle le service est exposé:

Vous devriez voir la sortie suivante:

Cela indique que le serviceecho1 est désormais disponible en interne à10.245.222.129 sur le port80. Il transférera le trafic vers containerPort5678 sur les pods qu'il sélectionne.

Maintenant que le serviceecho1 est opérationnel, répétez ce processus pour le serviceecho2.

Créez et ouvrez un fichier appeléecho2.yaml:

echo2.yaml

Ici, nous utilisons essentiellement le même manifeste de service et de déploiement que ci-dessus, mais nommez et renommez le service et le déploiementecho2. De plus, pour créer un peu de variété, nous créons un seul réplica de pod. Nous nous assurons de définir le paramètretext surecho2 afin que le serveur Web renvoie le texteecho2.

Enregistrez et fermez le fichier, puis créez les ressources Kubernetes à l'aide dekubectl:

Vous devriez voir la sortie suivante:

Encore une fois, vérifiez que le service est opérationnel:

Vous devriez voir les servicesecho1 etecho2 avec des ClusterIP attribués:

Maintenant que nos faux services Web d'écho sont opérationnels, nous pouvons maintenant déployer le contrôleur Nginx Ingress.

[[step-2 -—- setting-up-the-kubernetes-nginx-ingress-controller]] == Étape 2 - Configuration du contrôleur d'entrée Kubernetes Nginx

Dans cette étape, nous déploieronsv0.24.1 desNginx Ingress Controller gérés par Kubernetes. Notez qu'il existe des contrôleurs d'entrée Nginxseveral; la communauté Kubernetes maintient celle utilisée dans ce guide et Nginx Inc. maintientkubernetes-ingress. Les instructions de ce didacticiel sont basées sur celles du contrôleur d'entrée Kubernetes Nginx officielInstallation Guide.

Nginx Ingress Controller consiste en un pod qui exécute le serveur Web Nginx et surveille le plan de contrôle Kubernetes à la recherche d'objets nouveaux et mis à jour. Une ressource ingress est essentiellement une liste de règles de routage de trafic pour les services backend. Par exemple, une règle Ingress peut spécifier que le trafic HTTP arrivant au chemin/web1 doit être dirigé vers le serveur Web principal deweb1. En utilisant Ingress Resources, vous pouvez également effectuer un routage basé sur l'hôte: par exemple, acheminer les requêtes qui atteignentweb1.your_domain.com vers le backend Kubernetes Serviceweb1.

Dans ce cas, étant donné que nous déployons Ingress Controller sur un cluster DigitalOcean Kubernetes, le contrôleur crée un service LoadBalancer qui optimise un équilibreur de charge DigitalOcean vers lequel tout le trafic externe sera dirigé. Cet équilibreur de charge acheminera le trafic externe vers le module Ingress Controller Pod exécutant Nginx, qui le transmettra ensuite aux services principaux appropriés.

Nous allons commencer par créer les ressources Kubernetes requises par Nginx Ingress Controller. Il s’agit de ConfigMaps contenant la configuration du contrôleur, les rôles de contrôle d’accès en fonction des rôles (RBAC) pour accorder au contrôleur l’accès à l’API Kubernetes et le déploiement réel du contrôleur d’entrée qui utilisev0.24.1 de l’image du contrôleur d’entrée Nginx. Pour afficher la liste complète de ces ressources requises, consultez lesmanifest du dépôt GitHub de Kubernetes Nginx Ingress Controller.

Pour créer ces ressources obligatoires, utilisezkubectl apply et l'indicateur-f pour spécifier le fichier manifeste hébergé sur GitHub:

Nous utilisons iciapply au lieu decreate pour qu'à l'avenir, nous puissions incrémenter les modificationsapply des objets Ingress Controller au lieu de les écraser complètement. Pour en savoir plus surapply, consultezManaging Resources dans la documentation officielle de Kubernetes.

Vous devriez voir la sortie suivante:

Cette sortie sert également de résumé pratique de tous les objets Ingress Controller créés à partir du manifestemandatory.yaml.

Nous allons ensuite créer le service Ingress Controller LoadBalancer, qui créera un équilibreur de charge DigitalOcean qui équilibrera la charge et acheminera le trafic HTTP et HTTPS vers le module de contrôle Ingress déployé dans la commande précédente.

Pour créer le service LoadBalancer, à nouveaukubectl apply un fichier manifeste contenant la définition du service:

Vous devriez voir la sortie suivante:

Maintenant, confirmez que l'équilibreur de charge DigitalOcean a été créé avec succès en récupérant les détails du service aveckubectl:

Vous devriez voir une adresse IP externe, correspondant à l'adresse IP de DigitalOcean Load Balancer:

Notez l’adresse IP externe de Load Balancer, car vous en aurez besoin ultérieurement.

[.note] #Note: Par défaut, le service Nginx Ingress LoadBalancer aservice.spec.externalTrafficPolicy défini sur la valeurLocal, qui achemine tout le trafic de l'équilibreur de charge vers les nœuds exécutant Nginx Ingress Pods. Les autres nœuds échoueront délibérément aux vérifications de l'état de l'équilibreur de charge afin que le trafic d'entrée ne soit pas acheminé vers eux. Les politiques de trafic externe sortent du cadre de ce didacticiel, mais pour en savoir plus, vous pouvez consulterA Deep Dive into Kubernetes External Traffic Policies etSource IP for Services with Type=LoadBalancer à partir de la documentation officielle de Kubernetes.
#

Cet équilibreur de charge reçoit le trafic sur les ports HTTP et HTTPS 80 et 443 et le transmet au pod du contrôleur Ingress. Ingress Controller acheminera ensuite le trafic vers le service backend approprié.

Nous pouvons maintenant pointer nos enregistrements DNS vers cet équilibreur de charge externe et créer des ressources Ingress pour implémenter des règles de routage du trafic.

[[step-3 -—- creating-the-ingress-resource]] == Étape 3 - Création de la ressource Ingress

Commençons par créer une ressource d’entrée minimale pour acheminer le trafic dirigé vers un sous-domaine donné vers un service principal correspondant.

Dans ce guide, nous utiliserons le domaine de testexample.com. Vous devriez le remplacer par le nom de domaine que vous possédez.

Nous allons d'abord créer une règle simple pour acheminer le trafic dirigé versecho1.example.com vers le service backend deecho1 et le trafic dirigé versecho2.example.com vers le service backendecho2.

Commencez par ouvrir un fichier appeléecho_ingress.yaml dans votre éditeur préféré:

Collez dans la définition d'entrée suivante:

echo_ingress.yaml

Lorsque vous avez terminé d’éditer vos règles d’entrée, enregistrez et fermez le fichier.

Ici, nous avons spécifié que nous souhaitons créer une ressource d'entrée appeléeecho-ingress et acheminer le trafic en fonction de l'en-tête Host. Un en-tête d'hôte de requête HTTP spécifie le nom de domaine du serveur cible. Pour en savoir plus sur les en-têtes de demande d'hôte, consultez le Mozilla Developer Networkdefinition page. Les demandes avec l'hôteecho1.example.com seront dirigées vers le backend deecho1 configuré à l'étape 1, et les demandes avec l'hôteecho2.example.com seront dirigées vers le backend deecho2.

Vous pouvez maintenant créer l'entrée en utilisantkubectl:

Vous verrez la sortie suivante confirmant la création d'Ingress:

Pour tester Ingress, accédez à votre service de gestion DNS et créez des enregistrements A pourecho1.example.com etecho2.example.com pointant vers l'adresse IP externe de l'équilibreur de charge DigitalOcean. L'adresse IP externe de l'équilibreur de charge est l'adresse IP externe du serviceingress-nginx, que nous avons récupérée à l'étape précédente. Si vous utilisez DigitalOcean pour gérer les enregistrements DNS de votre domaine, consultezHow to Manage DNS Records pour savoir comment créer des enregistrements A.

Une fois que vous avez créé les enregistrements DNSecho1.example.com etecho2.example.com nécessaires, vous pouvez tester le contrôleur d'entrée et la ressource que vous avez créés à l'aide de l'utilitaire de ligne de commandecurl.

Depuis votre machine locale,curl le serviceecho1:

Vous devriez obtenir la réponse suivante du serviceecho1:

Cela confirme que votre demande àecho1.example.com est correctement acheminée via l'entrée Nginx vers le service backend deecho1.

Maintenant, effectuez le même test pour le serviceecho2:

Vous devriez obtenir la réponse suivante du serviceecho2:

Cela confirme que votre demande àecho2.example.com est correctement acheminée via l'entrée Nginx vers le service backend deecho2.

À ce stade, vous avez correctement configuré une base Nginx Ingress pour effectuer un routage basé sur un hôte virtuel. À l'étape suivante, nous installeronscert-manager à l'aide de Helm pour provisionner des certificats TLS pour notre entrée et activer le protocole HTTPS plus sécurisé.

[[step-4 -—- install-and-configuring-cert-manager]] == Étape 4 - Installation et configuration de Cert-Manager

Dans cette étape, nous utiliserons Helm pour installer cert-manager dans notre cluster. cert-manager est un service Kubernetes qui fournit des certificats TLS à partir deLet’s Encrypt et d'autres autorités de certification et gère leurs cycles de vie. Les certificats peuvent être demandés et configurés en annotant les ressources Ingress avec l'annotationcertmanager.k8s.io/issuer, en ajoutant une sectiontls à la spécification Ingress et en configurant un ou plusieursIssuers pour spécifier votre autorité de certification préférée. Pour en savoir plus sur les objets Issuer, consultez la documentation officielle de cert-manager surIssuers.

[.note] #Note: Assurez-vous que vous utilisez Helm v2.12.1 ou version ultérieure avant d'installer cert-manager. Pour vérifier la version de Helm que vous avez installée, exécutezhelm version sur votre ordinateur local.
#

Avant d'utiliser Helm pour installer cert-manager dans notre cluster, nous devons créer le cert-managerCustom Resource Definitions (CRD). Créez-les en les appliquant directement depuis le gestionnaire de certificatsGitHub repository:

Vous devriez voir la sortie suivante:

Ensuite, nous ajouterons une étiquette à l'espace de nomskube-system, où nous installerons cert-manager, pour activer la validation avancée des ressources à l'aide d'unwebhook:

Maintenant, nous allons ajouter lesJetstack Helm repository à Helm. Ce référentiel contient les cert-managerHelm chart.

Enfin, nous pouvons installer le graphique dans l'espace de nomskube-system:

Vous devriez voir la sortie suivante:

Cela indique que l'installation de cert-manager a réussi.

Avant de commencer à émettre des certificats pour nos hôtes Ingress, nous devons créer un émetteur, qui spécifie l'autorité de certification à partir de laquelle les certificats x509 signés peuvent être obtenus. Dans ce guide, nous utiliserons l’autorité de certification Let’s Encrypt, qui fournit des certificats TLS gratuits et offre à la fois un serveur de transfert pour tester la configuration de votre certificat et un serveur de production pour le déploiement de certificats TLS vérifiables.

Créons un émetteur test pour s’assurer que le mécanisme d’approvisionnement en certificats fonctionne correctement. Ouvrez un fichier nomméstaging_issuer.yaml dans votre éditeur de texte préféré:

Collez dans le manifeste ClusterIssuer suivant:

staging_issuer.yaml

Ici, nous spécifions que nous souhaitons créer un objet ClusterIssuer appeléletsencrypt-staging et utiliser le serveur de transfert Let’s Encrypt. Nous utiliserons ensuite le serveur de production pour déployer nos certificats, mais le serveur de production peut limiter le nombre de requêtes émises, ainsi, il est préférable d’utiliser l’URL intermédiaire pour les tests.

Nous spécifions ensuite une adresse e-mail pour enregistrer le certificat et créons un KubernetesSecret appeléletsencrypt-staging pour stocker la clé privée du compte ACME. Nous activons également le mécanisme de challengeHTTP-01. Pour en savoir plus sur ces paramètres, consultez la documentation officielle de cert-manager surIssuers.

Déployez le ClusterIssuer en utilisantkubectl:

Vous devriez voir la sortie suivante:

Maintenant que nous avons créé notre émetteur de préparation Let’s Encrypt, nous sommes prêts à modifier la ressource Ingress que nous avons créée ci-dessus et à activer le chiffrement TLS pour les cheminsecho1.example.com etecho2.example.com.

Ouvrez à nouveauecho_ingress.yaml dans votre éditeur préféré:

Ajoutez ce qui suit au manifeste de ressource d’entrée:

echo_ingress.yaml

Ici, nous ajoutons quelques annotations pour spécifier lesingress.class, qui déterminent le contrôleur d'entrée à utiliser pour implémenter les règles d'entrée. De plus, nous définissons lescluster-issuer comme étantletsencrypt-staging, l'émetteur de certificat que nous venons de créer.

Enfin, nous ajoutons un bloctls pour spécifier les hôtes pour lesquels nous voulons acquérir des certificats, et spécifions unsecretName. Ce secret contiendra la clé privée TLS et le certificat émis.

Une fois les modifications apportées, enregistrez et fermez le fichier.

Nous allons maintenant mettre à jour la ressource Ingress existante à l'aide dekubectl apply:

Vous devriez voir la sortie suivante:

Vous pouvez utiliserkubectl describe pour suivre l'état des modifications Ingress que vous venez d'appliquer:

Une fois que le certificat a été créé avec succès, vous pouvez exécuter undescribe supplémentaire dessus pour confirmer davantage sa création réussie:

Vous devriez voir la sortie suivante dans la sectionEvents:

Cela confirme que le certificat TLS a été émis avec succès et que le cryptage HTTPS est maintenant actif pour les deux domaines configurés.

Nous sommes maintenant prêts à envoyer une requête à un serveur backendecho pour vérifier que HTTPS fonctionne correctement.

Exécutez la commandewget suivante pour envoyer une requête àecho1.example.com et imprimer les en-têtes de réponse dansSTDOUT:

Vous devriez voir la sortie suivante:

Cela indique que le protocole HTTPS a été activé avec succès, mais le certificat ne peut pas être vérifié car il s’agit d’un faux certificat temporaire émis par le serveur de transfert Let’s Encrypt.

Maintenant que nous avons testé que tout fonctionne avec ce faux certificat temporaire, nous pouvons déployer des certificats de production pour les deux hôtesecho1.example.com etecho2.example.com.

[[step-5 -—- rolling-out-production-issuer]] == Étape 5 - Rolling Out Production Issuer

Au cours de cette étape, nous allons modifier la procédure utilisée pour fournir des certificats de transfert et générer un certificat de production valide et vérifiable pour nos hôtes Ingress.

Pour commencer, nous allons d’abord créer un certificat de production ClusterIssuer.

Ouvrez un fichier appeléprod_issuer.yaml dans votre éditeur préféré:

Collez dans le manifeste suivant:

prod_issuer.yaml

Notez les différentes URL du serveur ACME et le nom de la clé secrèteletsencrypt-prod.

Lorsque vous avez terminé, enregistrez et fermez le fichier.

Maintenant, déployez cet émetteur en utilisantkubectl:

Vous devriez voir la sortie suivante:

Mettez à jourecho_ingress.yaml pour utiliser ce nouvel émetteur:

Apportez les modifications suivantes au fichier:

echo_ingress.yaml

Ici, nous mettons à jour le ClusterIssuer et le nom secret enletsencrypt-prod.

Une fois que vous êtes satisfait de vos modifications, enregistrez et fermez le fichier.

Déployez les modifications en utilisantkubectl apply:

Attendez quelques minutes que le serveur de production Let’Secrypt envoie le certificat. Vous pouvez suivre sa progression en utilisantkubectl describe sur l'objetcertificate:

Une fois que vous voyez la sortie suivante, le certificat a été délivré avec succès:

Nous allons maintenant effectuer un test à l'aide decurl pour vérifier que HTTPS fonctionne correctement:

Vous devriez voir ce qui suit:

Cela indique que les requêtes HTTP sont redirigées pour utiliser HTTPS.

Exécutezcurl surhttps://echo1.example.com:

Vous devriez maintenant voir le résultat suivant:

Vous pouvez exécuter la commande précédente avec l'indicateur détaillé-v pour approfondir la négociation du certificat et vérifier les informations du certificat.

À ce stade, vous avez correctement configuré le protocole HTTPS à l’aide d’un certificat Let’s Encrypt pour votre Nginx Ingress.

Dans ce guide, vous configurez Nginx Ingress pour équilibrer la charge et acheminer les demandes externes vers les services backend à l’intérieur de votre cluster Kubernetes. Vous avez également sécurisé Ingress en installant le fournisseur de certificats de cert-manager et en configurant un certificat Let’s Encrypt pour deux chemins d’hôte.

Il existe de nombreuses alternatives au contrôleur Nginx Ingress. Pour en savoir plus, consultezIngress controllers de la documentation officielle de Kubernetes.