Comment configurer une entrée Nginx sur DigitalOcean Kubernetes à l'aide de Helm
Introduction
Kubernetes Ingresses vous offre un moyen flexible d'acheminer le trafic au-delà de votre cluster vers les services Kubernetes internes. Ingress Resources sont des objets dans Kubernetes qui définissent des règles pour acheminer le trafic HTTP et HTTPS vers les services. Pour que ceux-ci fonctionnent, un Ingress Controller doit être présent ; son rôle est de mettre en œuvre les règles en acceptant le trafic (très probablement via un équilibreur de charge) et en le routant vers les services appropriés. La plupart des contrôleurs d'entrée n'utilisent qu'un seul équilibreur de charge global pour toutes les entrées, ce qui est plus efficace que de créer un équilibreur de charge pour chaque service que vous souhaitez exposer.
Helm est un gestionnaire de packages pour la gestion de Kubernetes. L'utilisation de Helm Charts avec votre Kubernetes offre une configurabilité et une gestion du cycle de vie pour mettre à jour, restaurer et supprimer une application Kubernetes.
Dans ce guide, vous allez configurer le Nginx Ingress Controller maintenu par Kubernetes à l'aide de Helm. Vous allez ensuite créer une ressource Ingress pour acheminer le trafic de vos domaines vers des exemples de services back-end Hello World. Une fois que vous avez configuré l'Ingress, vous installerez Cert Manager sur votre cluster pour pouvoir provisionner automatiquement les certificats Let's Encrypt TLS afin de sécuriser vos Ingress.
Conditions préalables
- Un cluster DigitalOcean Kubernetes 1.16+ avec votre configuration de connexion configurée comme
kubectldéfaut. Instructions sur la façon de configurerkubectlsont affichés sous l'étape Se connecter à votre cluster affichée lorsque vous créez votre cluster. Pour savoir comment créer un cluster Kubernetes sur DigitalOcean, consultez Kubernetes Quickstart. - Le gestionnaire de packages Helm 3 installé sur votre ordinateur local. Effectuez l'Étape 1 du didacticiel Comment installer un logiciel sur des clusters Kubernetes avec le gestionnaire de packages Helm 3.
- Un nom de domaine entièrement enregistré avec deux enregistrements A disponibles. Ce tutoriel utilisera
hw1.your_domainethw2.your_domainà travers. Vous pouvez acheter un nom de domaine sur Namecheap, en obtenir un gratuitement sur Freenom ou utiliser le bureau d'enregistrement de domaine de votre choix.
Étape 1 - Configuration des déploiements Hello World
Dans cette section, avant de déployer Nginx Ingress, vous allez déployer une application Hello World appelée hello-kubernetes pour disposer de certains services vers lesquels vous acheminerez le trafic. Pour confirmer que Nginx Ingress fonctionne correctement dans les étapes suivantes, vous allez le déployer deux fois, à chaque fois avec un message de bienvenue différent qui s'affichera lorsque vous y accéderez depuis votre navigateur.
Vous stockerez la configuration de déploiement sur votre ordinateur local. La première configuration de déploiement se trouvera dans un fichier nommé hello-kubernetes-first.yaml. Créez-le à l'aide d'un éditeur de texte :
nano hello-kubernetes-first.yaml
Ajoutez les lignes suivantes :
bonjour-kubernetes-first.yaml
apiVersion: v1
kind: Service
metadata:
name: hello-kubernetes-first
spec:
type: ClusterIP
ports:
- port: 80
targetPort: 8080
selector:
app: hello-kubernetes-first
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: hello-kubernetes-first
spec:
replicas: 3
selector:
matchLabels:
app: hello-kubernetes-first
template:
metadata:
labels:
app: hello-kubernetes-first
spec:
containers:
- name: hello-kubernetes
image: paulbouwer/hello-kubernetes:1.8
ports:
- containerPort: 8080
env:
- name: MESSAGE
value: Hello from the first deployment!
Cette configuration définit un déploiement et un service. Le déploiement se compose de trois répliques du paulbouwer/hello-kubernetes:1.7 image et une variable d'environnement nommée MESSAGE—vous verrez sa valeur lorsque vous accéderez à l'application. Le service ici est défini pour exposer le déploiement dans le cluster au port 80.
Enregistrez et fermez le fichier.
Ensuite, créez cette première variante du hello-kubernetes app dans Kubernetes en exécutant la commande suivante :
kubectl create -f hello-kubernetes-first.yaml
Vous recevrez la sortie suivante :
Outputservice/hello-kubernetes-first created deployment.apps/hello-kubernetes-first created
Pour vérifier la création du service, exécutez la commande suivante :
kubectl get service hello-kubernetes-first
La sortie sera la suivante :
OutputNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE hello-kubernetes-first ClusterIP 10.245.124.46 <none> 80/TCP 7s
Vous constaterez que le service nouvellement créé a un ClusterIP attribué, ce qui signifie qu'il fonctionne correctement. Tout le trafic qui lui est envoyé sera transmis au déploiement sélectionné sur le port 8080. Maintenant que vous avez déployé la première variante du hello-kubernetes app, vous travaillerez sur le second.
Ouvrez un fichier appelé hello-kubernetes-second.yaml pour l'édition :
nano hello-kubernetes-second.yaml
Ajoutez les lignes suivantes :
bonjour-kubernetes-second.yaml
apiVersion: v1
kind: Service
metadata:
name: hello-kubernetes-second
spec:
type: ClusterIP
ports:
- port: 80
targetPort: 8080
selector:
app: hello-kubernetes-second
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: hello-kubernetes-second
spec:
replicas: 3
selector:
matchLabels:
app: hello-kubernetes-second
template:
metadata:
labels:
app: hello-kubernetes-second
spec:
containers:
- name: hello-kubernetes
image: paulbouwer/hello-kubernetes:1.8
ports:
- containerPort: 8080
env:
- name: MESSAGE
value: Hello from the second deployment!
Enregistrez et fermez le fichier.
Cette variante a la même structure que la configuration précédente ; les seules différences résident dans les noms de déploiement et de service, pour éviter les collisions, et dans le message.
Créez-le maintenant dans Kubernetes avec la commande suivante :
kubectl create -f hello-kubernetes-second.yaml
La sortie sera :
Outputservice/hello-kubernetes-second created deployment.apps/hello-kubernetes-second created
Vérifiez que le deuxième service est opérationnel en répertoriant tous vos services :
kubectl get service
La sortie sera similaire à ceci :
OutputNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE hello-kubernetes-first ClusterIP 10.245.124.46 <none> 80/TCP 49s hello-kubernetes-second ClusterIP 10.245.254.124 <none> 80/TCP 10s kubernetes ClusterIP 10.245.0.1 <none> 443/TCP 65m
Tous les deux hello-kubernetes-first et hello-kubernetes-second sont répertoriés, ce qui signifie que Kubernetes les a créés avec succès.
Vous avez créé deux déploiements du hello-kubernetes application avec les services d'accompagnement. Chacun a un ensemble de messages différent dans la spécification de déploiement, ce qui vous permet de les différencier lors des tests. À l'étape suivante, vous installerez le contrôleur d'entrée Nginx lui-même.
Étape 2 - Installation du contrôleur d'entrée Kubernetes Nginx
Vous allez maintenant installer le Nginx Ingress Controller maintenu par Kubernetes à l'aide de Helm. Notez qu'il existe plusieurs entrées Nginx.
Le contrôleur d'entrée Nginx se compose d'un pod et d'un service. Le pod exécute le contrôleur, qui interroge constamment le /ingresses point de terminaison sur le serveur d'API de votre cluster pour les mises à jour des ressources Ingress disponibles. Le service est de type LoadBalancer, et parce que vous le déployez sur un cluster DigitalOcean Kubernetes, le cluster créera automatiquement un DigitalOcean Load Balancer, à travers lequel tout le trafic externe circulera vers le contrôleur. Le contrôleur acheminera ensuite le trafic vers les services appropriés, comme défini dans les ressources d'entrée.
Seul le service LoadBalancer connaît l'adresse IP de l'équilibreur de charge créé automatiquement. Certaines applications (telles que ExternalDNS) ont besoin de connaître son adresse IP, mais ne peuvent lire que la configuration d'un Ingress. Le contrôleur peut être configuré pour publier l'adresse IP sur chaque entrée en définissant le controller.publishService.enabled paramètre à true durant helm install. Il est recommandé d'activer ce paramètre pour prendre en charge les applications qui peuvent dépendre de l'adresse IP de l'équilibreur de charge.
Pour installer le contrôleur d'entrée Nginx sur votre cluster, vous devez d'abord ajouter son référentiel à Helm en exécutant :
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
La sortie sera :
Output"ingress-nginx" has been added to your repositories
Mise à jour pour informer Helm de ce qu'il contient :
helm repo update
Enfin, exécutez la commande suivante pour installer l'entrée Nginx :
helm install nginx-ingress ingress-nginx/ingress-nginx --set controller.publishService.enabled=true
Cette commande installe le contrôleur d'entrée Nginx à partir du stable référentiel de cartes, nomme la version de Helm nginx-ingress, et définit le publishService paramètre à true.
La sortie sera la suivante :
OutputNAME: nginx-ingress LAST DEPLOYED: Fri Apr 3 17:39:05 2020 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: ...
Helm a enregistré les ressources dans Kubernetes qu'il a créées dans le cadre de l'installation du graphique.
Vous pouvez regarder l'équilibreur de charge devenir disponible en exécutant :
kubectl --namespace default get services -o wide -w nginx-ingress-ingress-nginx-controller
Vous avez installé l'entrée Nginx gérée par la communauté Kubernetes. Il acheminera le trafic HTTP et HTTPS de l'équilibreur de charge vers les services principaux appropriés, configurés dans Ingress Resources. Dans l'étape suivante, vous allez exposer le hello-kubernetes déploiements d'applications à l'aide d'une ressource Ingress.
Étape 3 - Exposer l'application à l'aide d'une entrée
Vous allez maintenant créer une ressource Ingress et l'utiliser pour exposer le hello-kubernetes déploiements d'applications sur les domaines de votre choix. Vous le testerez ensuite en y accédant depuis votre navigateur.
Vous allez stocker l'Ingress dans un fichier nommé hello-kubernetes-ingress.yaml. Créez-le à l'aide de votre éditeur :
nano hello-kubernetes-ingress.yaml
Ajoutez les lignes suivantes à votre fichier :
bonjour-kubernetes-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: hello-kubernetes-ingress
annotations:
kubernetes.io/ingress.class: nginx
spec:
rules:
- host: "hw1.your_domain_name"
http:
paths:
- pathType: Prefix
path: "/"
backend:
service:
name: hello-kubernetes-first
port:
number: 80
- host: "hw2.your_domain_name"
http:
paths:
- pathType: Prefix
path: "/"
backend:
service:
name: hello-kubernetes-second
port:
number: 80
Vous définissez une ressource d'entrée avec le nom hello-kubernetes-ingress. Ensuite, vous spécifiez deux règles d'hôte, de sorte que hw1.your_domain est acheminé vers le hello-kubernetes-first Service, et hw2.your_domain est acheminé vers le service à partir du deuxième déploiement (hello-kubernetes-second).
Ensuite, vous devrez vous assurer que vos deux domaines pointent vers l'équilibreur de charge via des enregistrements A. Cela se fait via votre fournisseur DNS. Pour configurer vos enregistrements DNS sur DigitalOcean, consultez Comment gérer les enregistrements DNS.
N'oubliez pas de remplacer les domaines en surbrillance par les vôtres, puis enregistrez et fermez le fichier.
Créez-le dans Kubernetes en exécutant la commande suivante :
kubectl apply -f hello-kubernetes-ingress.yaml
Vous pouvez maintenant naviguer vers hw1.your_domain dans votre navigateur. Vous verrez ce qui suit :
La deuxième variante (hw2.your_domain) affichera un message différent :
Avec cela, vous avez vérifié que le contrôleur d'entrée achemine correctement les demandes ; dans ce cas, de vos deux domaines vers deux Services différents.
Vous avez créé et configuré une ressource d'entrée pour servir le hello-kubernetes déploiements d'applications sur vos domaines. À l'étape suivante, vous configurerez Cert-Manager afin de pouvoir sécuriser vos ressources Ingress avec des certificats TLS gratuits de Let's Encrypt.
Étape 4 - Sécurisation de l'entrée à l'aide de Cert-Manager
Pour sécuriser vos ressources Ingress, vous allez installer Cert-Manager, créer un ClusterIssuer pour la production et modifier la configuration de votre Ingress pour tirer parti des certificats TLS. Les ClusterIssuers sont des ressources Cert-Manager dans Kubernetes qui fournissent des certificats TLS pour l'ensemble du cluster. Une fois installée et configurée, votre application fonctionnera derrière HTTPS.
Avant d'installer Cert-Manager sur votre cluster via Helm, vous allez créer manuellement un espace de noms pour celui-ci en exécutant la commande suivante :
kubectl create namespace cert-manager
Vous devrez ajouter le référentiel Jetstack Helm à Helm, qui héberge le graphique Cert-Manager. Pour ce faire, exécutez la commande suivante :
helm repo add jetstack https://charts.jetstack.io
Helm affichera la sortie suivante :
Output"jetstack" has been added to your repositories
Ensuite, mettez à jour le cache des cartes de Helm :
helm repo update
Enfin, installez Cert-Manager dans le cert-manager namespace en exécutant la commande suivante :
helm install cert-manager jetstack/cert-manager --namespace cert-manager --version v1.2.0 --set installCRDs=true
Vous verrez la sortie suivante :
OutputNAME: cert-manager LAST DEPLOYED: Sun Dec 13 11:29:32 2020 NAMESPACE: cert-manager STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: cert-manager has been deployed successfully! ...
La sortie indique que l'installation a réussi. Comme indiqué dans le NOTES dans la sortie, vous devrez configurer un émetteur pour émettre des certificats TLS.
Vous allez maintenant en créer un qui émet des certificats Let's Encrypt, et vous allez stocker sa configuration dans un fichier nommé production_issuer.yaml. Créez-le et ouvrez-le pour le modifier :
nano production_issuer.yaml
Ajoutez les lignes suivantes :
production_issuer.yaml
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: letsencrypt-prod
spec:
acme:
# Email address used for ACME registration
email: your_email_address
server: https://acme-v02.api.letsencrypt.org/directory
privateKeySecretRef:
# Name of a secret used to store the ACME account private key
name: letsencrypt-prod-private-key
# Add a single challenge solver, HTTP01 using nginx
solvers:
- http01:
ingress:
class: nginx
Cette configuration définit un ClusterIssuer qui contacte Let's Encrypt afin d'émettre des certificats. Vous devrez remplacer your_email_address avec votre adresse e-mail afin de recevoir d'éventuels avis urgents concernant la sécurité et l'expiration de vos certificats.
Enregistrez et fermez le fichier.
Déroulez-le avec kubectl:
kubectl apply -f production_issuer.yaml
Vous verrez la sortie suivante :
Outputclusterissuer.cert-manager.io/letsencrypt-prod created
Une fois Cert-Manager installé, vous êtes prêt à introduire les certificats dans la ressource Ingress définie à l'étape précédente. Ouvert hello-kubernetes-ingress.yaml pour l'édition :
nano hello-kubernetes-ingress.yaml
Ajoutez les lignes en surbrillance :
bonjour-kubernetes-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: hello-kubernetes-ingress
annotations:
kubernetes.io/ingress.class: nginx
cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
tls:
- hosts:
- hw1.your_domain
- hw2.your_domain
secretName: hello-kubernetes-tls
rules:
- host: "hw1.your_domain_name"
http:
paths:
- pathType: Prefix
path: "/"
backend:
service:
name: hello-kubernetes-first
port:
number: 80
- host: "hw2.your_domain_name"
http:
paths:
- pathType: Prefix
path: "/"
backend:
service:
name: hello-kubernetes-second
port:
number: 80
La tls bloquer sous spec définit dans quel Secret les certificats de vos sites (répertoriés sous hosts) stockeront leurs certificats, que le letsencrypt-prod Problèmes d'émetteur de cluster. Cela doit être différent pour chaque Ingress que vous créez.
N'oubliez pas de remplacer le hw1.your_domain et hw2.your_domain avec vos propres domaines. Une fois la modification terminée, enregistrez et fermez le fichier.
Réappliquez cette configuration à votre cluster en exécutant la commande suivante :
kubectl apply -f hello-kubernetes-ingress.yaml
Vous verrez la sortie suivante :
Outputingress.networking.k8s.io/hello-kubernetes-ingress configured
Vous devrez attendre quelques minutes pour que les serveurs Let's Encrypt émettent un certificat pour vos domaines. En attendant, vous pouvez suivre sa progression en inspectant le résultat de la commande suivante :
kubectl describe certificate hello-kubernetes-tls
La fin de la sortie ressemblera à ceci :
OutputEvents: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Issuing 26s cert-manager Issuing certificate as Secret does not exist Normal Generated 26s cert-manager Stored new private key in temporary Secret resource "hello-kubernetes-tls2-nfsgp" Normal Requested 26s cert-manager Created new CertificateRequest resource "hello-kubernetes-tls2-wzl8z" Normal Issuing 24s cert-manager The certificate has been successfully issued
Lorsque votre dernière ligne de sortie lit The certificate has been successfully issued, vous pouvez quitter en appuyant sur CTRL + C. Accédez à l'un de vos domaines dans votre navigateur pour tester. Vous trouverez le cadenas à gauche de la barre d'adresse de votre navigateur, signifiant que votre connexion est sécurisée.
Dans cette étape, vous avez installé Cert-Manager à l'aide de Helm et créé un Let's Encrypt ClusterIssuer. Ensuite, vous avez mis à jour votre ressource Ingress pour tirer parti de l'émetteur pour générer des certificats TLS. Au final, vous avez confirmé que HTTPS fonctionne correctement en naviguant vers l'un de vos domaines dans votre navigateur.
Conclusion
Vous avez maintenant configuré avec succès le contrôleur d'entrée Nginx et Cert-Manager sur votre cluster DigitalOcean Kubernetes à l'aide de Helm. Vous pouvez maintenant exposer vos applications sur Internet, sur vos domaines, sécurisées à l'aide de certificats Let's Encrypt TLS.
Pour plus d'informations sur le gestionnaire de packages Helm, lisez cet article d'introduction.
