Migrer NGINX à partir du dépôt « stable » charts Helm avec ChartCenter
MISE À JOUR : depuis le 1er mai 2021, le dépôt central ChartCenter a été mis hors service et toutes les fonctionnalités sont obsolètes. Pour en savoir plus sur la mise hors service des centres, lisez l’article de blog sur la dépréciation des centres
Au cours des quatre dernières années, quiconque souhaitait déployer le contrôleur Ingress NGINX pour Kubernetes trouvait son chart Helm officiel. nginx-ingress dans le dépôt stable géré par le projet Helm.
Cette époque est révolue. Et pas seulement pour NGINX, le contrôleur Ingress le plus populaire utilisé comme proxy inverse et équilibreur de charge, mais pour toutes les applications K8s open source.
Avec l’avènement de Helm 3, le projet Helm déprécie les dépôts stable À partir de novembre 2019, aucun nouveau chart ne devait être accepté dans stable car les propriétaires de charts effectuent une transition vers des dépôts individuels. Cette période de transition est maintenant terminée, les dépôts — stable ont été retirés de la liste de Helm Hub, et seront officiellement obsolètes en novembre prochain.
Qu’est-ce que cela signifie pour les installateurs et les responsables des déploiements NGINX ? Pour commencer, le projet NGINX maintient désormais un nouveau chart ingress-nginx Helm dans les dépôts GitHub pour Kubernetes. Toute personne qui installe ou met à jour un déploiement de NGINX Ingress Controller doit désormais utiliser le chart de ce dépôt.
Même si le nouveau chart déploie actuellement la même version de l’application NGINX, il n’est pas identique au chart dans stable.. Cela nécessite quelques ajustements lors de la mise à jour d’une installation NGINX en place avec l nouveau chart.
Voyons ce que cela implique, et comment JFrog ChartCenter peut vous aider à la transition.
Un dépôt central Helm
L’ensemble stable de charts Helm signifiait que les charts officiels de nombreuses applications Kubernetes populaires pouvaient toujours être trouvés dans un dépôt central. Il suffisait d’ajouter le dépôt stable au client Helm :
$ helm repo add stable https://kubernetes-charts.storage.googleapis.com/
À partir de ce dépôt stable unique, vous pouviez déployer en toute confiance nginx-ingress en utilisant le dernier chart Helm approuvé par l’auteur.
Comme le dépôt stable est pratiquement obsolète, il n’est plus disponible en tant que source unique pour les charts Helm connus. NGINX vous demande maintenant d’ajouter ingress-nginx individuellement au client Helm :
$ helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
Sans un dépôt central, vous devez exécuter un helm repo add distinct chaque fois que vous devez mettre à jour une application K8s différente.
Existe-t-il un meilleur moyen ?
Ingress NGINX Controller dans ChartCenter
JFrog ChartCenter est un dépôt central gratuit de charts Helm qui a été conçu pour aider la communauté Helm à trouver des charts immuables, sécurisés et fiables, et à disposer d’une même analyse pour proxyer tous les charts à partir d’un seul emplacement. Il peut être utilisé comme un dépôt Helm central à partir du client Helm, ce qui vous évite d’ajouter de nombreux dépôts Helm publics, mais vous permet d’en utiliser un seul.
Grâce à ChartCenter, plus de 30 000 charts Helm versionnés sont disponibles, et de nombreux charts d’applications populaires – y compris pour le contrôleur NGINX Ingress – sont présentés sur sa page d’accueil afin que vous puissiez les localiser facilement.
Grâce à la recherche de ChartCenter, nous pouvons trouver le chart stable nginx-ingress:
Nous pouvons également localiser le chart actuelingress-nginxdans ChartCenter :
Utilisation de ChartCenter
Une fois que nous avons ajouté ChartCenter à notre client Helm, nous pouvons l’utiliser comme dépôt central pour tous nos charts Helm, y compris les deux dépôts NGINX que nous utiliserons dans notre démonstration.
Étape 1 : Ajouter ChartCenter en tant que dépôt Helm
Configurez votre client Helm pour qu’il utilise le dépôt ChartCenter comme emplacement central unique pour consommer les charts à partir de :
$ helm repo add center https://repo.chartcenter.io
$ helm repo update
Étape 2 : Utilisation de ChartCenter en tant que dépôt
Maintenant, vérifions les charts nginx-ingress et ingress-nginx à partir du client helm :
$ helm search repo center/stable/nginx-ingress
NOM VERSION DU CHART VERSION DE L’APP DESCRIPTION
center/stable/nginx-ingress 1.41.2 v0.34.1 Un nginx Ingress controller qui utilise ConfigMap...
$ helm search repo center/kubernetes-ingress-nginx/ingress-nginx
NOM VERSION DU CHART VERSION DE L’APP DESCRIPTION
center/kubernetes-ingress-nginx/ingress-nginx 2.11.2 0.34.1 Ingress controller pour Kubernetes à l’aide de NGINX a...
Bien, nous voyons la même version de charts que dans ChartCenter UI.
Et ici, vous pouvez voir à quel point il est plus facile d’utiliser un dépôt Helm central pour des charts provenant de différents dépôts Helm.
Installation du chart nginx-ingress Helm
Pour tester d’abord la mise à niveau, nous devons installer un dépôt nginx-ingress . Je vais utiliser un petit script shell nginx-ingress.sh qui crée un fichier de valeurs de remplacement, et installe ensuite nginx-ingress.
nginx-ingress.sh a un nom et une version de chart, et une IP statique pour l’équilibreur de charge :
#!/bin/bash
NOM_CHART = "center/stable/nginx-ingress"
VERSION_CHART = "1.41.2"
VERSION = nginx-ingress
ESPACE DE NOMS = nginx-ingress
FICHER_VALEURS = nginx-ingress.yaml
IP_STATIQUE_LB = 35.197.192.35
generateValues() {
cat << EOF > "${VALUES_FILE}"
# Valeurs de remplacement pour nginx-ingress
contrôleur :
## Utiliser les ports hôtes 80 et 443
daemonset :
utiliser le port de l’hôte : vrai
type : DaemonSet
service :
## Définir l’adresse IP statique pour LoadBalancer
IP équilibreur de charge : ${LB_STATIC_IP}
Politique de trafic externe : locale
stats :
activées : vrai
mesures :
activées : vrai
Fin de fichier
}
génère des valeurs
kubectl create ns nginx-ingress || true
écho
helm upgrade --install ${RELEASE} -n ${NAMESPACE} ${CHART_NAME} --version ${CHART_VERSION} -f ${VALUES_FILE}
écho
kubectl -n ${NAMESPACE} get all
Exécutons nginx-ingress.sh pour installer nginx-ingress:
$ ./nginx-ingress.sh
namespace/nginx-ingress created
La version « nginx-ingress » n’existe pas. Installez-la maintenant.
NOM : nginx-ingress
DERNIER DÉPLOIEMENT : Lun 10 août 17:27:13 2020
ESPACE DE NOMS : nginx-ingress
ÉTAT : déployé
RÉVISION : 1
SUITE DE TESTS : aucune
REMARQUES :
Le contrôleur nginx-ingress a été installé.
La disponibilité de l’adresse IP LoadBalancer peut prendre quelques minutes.
Vous pouvez vérifier l’état en exécutant « kubectl --namespace nginx-ingress get services -o wide -w nginx-ingress-controller »
Un exemple d’Ingress qui utilise le contrôleur :
Version d’API : extensions/v1beta1
type : Ingress
métadonnées :
annotations :
kubernetes.io/ingress.class : nginx
nom : exemple
espace de noms : foo
spéc :
règle :
- hôte : www.example.com
http :
chemins :
- backend :
nom de service : exampleService
port de service : 80
chemin : /
# Cette section n’est requise que si TLS doit être activé pour Ingress
tls :
- hôtes :
- www.example.com
nom secret : exemple-tls
Si TLS est activé pour Ingress, un secret contenant le certificat et la clé doit également être fourni :
Version d’API : v1
type : secret
métadonnées :
nom : exemple-tls
espace de noms : foo
données :
cert tls :
clé tls :
type : kubernetes.io/tls
NOM PRÊT ÉTAT REDÉMARRAGES ANTÉRIORITÉ
pod/nginx-ingress-controller-rrsl9 0/1 ContainerCreating 0 1 s
pod/nginx-ingress-default-backend-5b967cf596-wrrfl 0/1 ContainerCreating 0 1 s
NOM TYPE IP-CLUSTER IP-EXTERNE PORT(S) ANTÉRIORITÉ
service/nginx-ingress-controller LoadBalancer 10.242.2.213 80:30643/TCP,443:31622/TCP 2 s
service/nginx-ingress-controller-metrics IP Cluster 10.242.10.112 9913/TCP 2 s
service/nginx-ingress-default-backend IP Cluster 10.242.11.172 80/TCP 2 s
NOM SOUHAITÉ ACTUEL PRÊT À JOUR DISPONIBLE SÉLECTEUR DE NŒUDS ANTÉRIORITÉ
daemonset.apps/nginx-ingress-controller 1 1 0 1 0 3 s
NOM PRÊT À JOUR DISPONIBLE ANTÉRIORITÉ
deployment.apps/nginx-ingress-default-backend 0/1 1 0 2 s
NOM SOUHAITÉ ACTUEL PRÊT ANTÉRIORITÉ
replicaset.apps/nginx-ingress-default-backend-5b967cf596 1 1 0 2 s
Et vérifions les pods et le service :
$ kubectl -n nginx-ingress get pods
NOM PRÊT ÉTAT REDÉMARRAGES ANTÉRIORITÉ
nginx-ingress-controller-rrsl9 1/1 Exécution 0 78 s
nginx-ingress-default-backend-5b967cf596-wrrfl 1/1 Exécution 0 78 s
$ kubectl -n nginx-ingress get svc
NOM TYPE IP-CLUSTER IP-EXTERNE PORT(S) ANTÉRIORITÉ
nginx-ingress-controller LoadBalancer 10.242.2.213 35.197.192.35 80:30643/TCP,443:31622/TCP 89 s
nginx-ingress-controller-metrics IP Cluster 10.242.10.112 9913/TCP 89 s
nginx-ingress-default-backend IP Cluster 10.242.11.172 80/TCP 89 s
Bien, le pod NGINX Ingress Controller est en place, et son service s’est vu attribuer une IP externe par l’équilibreur de charge.
Ok, nous avons réussi à installer le chart nginx-ingress passons à sa mise à jour.
Mise à niveau vers le chart ingress-nginx Helm
Essayons de mettre à niveau NGINX Ingress Controller en utilisant le chart le plus actuel.
Encore une fois, nous allons utiliser un script shell cette fois avec le nom différent ingress-nginx.sh.
ingress-nginx.sh a un nom et une version de chart différents, ainsi que le même nom de version Helm et la même adresse IP statique pour l’équilibreur de charge.
#!/bin/bash
NOM_CHART = "center/kubernetes-ingress-nginx/ingress-nginx"
VERSION_CHART = "2.11.1"
VERSION = nginx-ingress
ESPACE DE NOMS = nginx-ingress
FICHER_VALEURS = ingress-nginx.yaml
IP_STATIQUE_LB = 35.197.192.35
generateValues() {
cat << EOF > "${VALUES_FILE}"
# Valeurs de remplacement pour ingress-nginx
contrôleur :
## Utiliser les ports hôtes 80 et 443
port de l’hôte :
activées : vrai
type : DaemonSet
service :
## Définir l’adresse IP statique pour LoadBalancer
IP équilibreur de charge : ${LB_STATIC_IP}
Politique de trafic externe : locale
stats :
activées : vrai
mesures :
activées : vrai
admissionWebhooks :
activée : faux
defaultBackend :
activé : vrai
Fin de fichier
}
génère des valeurs
écho
helm upgrade --install ${RELEASE} -n ${NAMESPACE} ${CHART_NAME} --version ${CHART_VERSION} -f ${VALUES_FILE}
écho
kubectl -n ${NAMESPACE} get all
ingress-nginx.sh présente quelques différences par rapport à nginx-ingress.sh:
contrôleur :
## Utiliser les ports hôtes 80 et 443
daemonset :
utiliser le port de l’hôte : vrai
comme certaines valeurs ont été modifiées à :
contrôleur :
## Utiliser les ports hôtes 80 et 443
port de l’hôte :
activé : vrai
type : DaemonSet
et d’autres ont été ajoutées :
admissionWebhooks :
activé : faux
defaultBackend :
activé : vrai
Dans ce scénario de mise à niveau, nous n’utilisons pas admissionWebhooks donc nous le désactivons, et nous activons defaultBackend comme dans le chart nginx-ingress il est activé par défaut. Et bien sûr, vous pouvez modifier les valeurs en fonction de vos besoins.
Exécutons ingress-nginx.sh pour mettre à niveau nginx-ingress:
La version « nginx-ingress » a été mise à niveau. Bonne chance !
NOM : nginx-ingress
DERNIER DÉPLOIEMENT : Lun 10 août 18:00:31 2020
ESPACE DE NOMS : nginx-ingress
ÉTAT : déployé
RÉVISION : 2
SUITE DE TESTS : aucune
REMARQUES :
Le contrôleur ingress-nginx a été installé.
La disponibilité de l’adresse IP LoadBalancer peut prendre quelques minutes.
Vous pouvez vérifier l’état en exécutant « kubectl --namespace nginx-ingress get services -o wide -w nginx-ingress-ingress-nginx-controller »
Un exemple d’Ingress qui utilise le contrôleur :
Version d’API : networking.k8s.io/v1beta1
type : Ingress
métadonnées :
annotations :
kubernetes.io/ingress.class : nginx
nom : exemple
espace de noms : foo
spéc :
règle :
- hôte : www.example.com
http :
chemins :
- backend :
nom de service : exampleService
port de service : 80
chemin : /
# Cette section n’est requise que si TLS doit être activé pour Ingress
tls :
- hôtes :
- www.example.com
nom secret : exemple-tls
Si TLS est activé pour Ingress, un secret contenant le certificat et la clé doit également être fourni :
Version d’API : v1
type : secret
métadonnées :
nom : exemple-tls
espace de noms : foo
données :
cert tls :
clé tls :
type : kubernetes.io/tls
NOM PRÊT ÉTAT REDÉMARRAGES ANTÉRIORITÉ
pod/nginx-ingress-controller-rrsl9 1/1 Fin d’exécution 0 33 m
pod/nginx-ingress-default-backend-5b967cf596-wrrfl 0/1 Fin d’exécution 0 33 m
pod/nginx-ingress-ingress-nginx-controller-f9ztr 0/1 En attente 0 5 s
pod/nginx-ingress-ingress-nginx-defaultbackend-845f7cfd46-56grw 1/1 Exécution 0 5 s
NOM TYPE IP-CLUSTER IP-EXTERNE PORT(S) ANTÉRIORITÉ
service/nginx-ingress-controller LoadBalancer 10.242.2.213 35.197.192.35 80:30643/TCP,443:31622/TCP 33m
service/nginx-ingress-ingress-nginx-controller LoadBalancer 10.242.13.184 80:30601/TCP,443:30644/TCP 6 s
service/nginx-ingress-ingress-nginx-controller-metrics IP Cluster 10.242.12.190 9913/TCP 6 s
service/nginx-ingress-ingress-nginx-defaultbackend IP Cluster 10.242.11.112 80/TCP 5 s
NOM SOUHAITÉ ACTUEL PRÊT À JOUR DISPONIBLE SÉLECTEUR DE NŒUDS ANTÉRIORITÉ
daemonset.apps/nginx-ingress-ingress-nginx-controller 1 1 0 1 0 6 s
NOM PRÊT À JOUR DISPONIBLE ANTÉRIORITÉ
deployment.apps/nginx-ingress-ingress-nginx-defaultbackend 1/1 1 1 6 s
NOM SOUHAITÉ ACTUEL PRÊT ANTÉRIORITÉ
replicaset.apps/nginx-ingress-ingress-nginx-defaultbackend-845f7cfd46 1 1 1 6 s
Maintenant, vérifions les pods et le service :
$ kubectl -n nginx-ingress get pods
NOM PRÊT ÉTAT REDÉMARRAGES ANTÉRIORITÉ
nginx-ingress-ingress-nginx-controller-f9ztr 0/1 Exécution 0 34 s
nginx-ingress-ingress-nginx-defaultbackend-845f7cfd46-56grw 1/1 Exécution 0 34 s
$ kubectl -n nginx-ingress get svc
NOM TYPE IP-CLUSTER IP-EXTERNE PORT(S) ANTÉRIORITÉ
nginx-ingress-controller LoadBalancer 10.242.2.213 35.197.192.35 80:30643/TCP,443:31622/TCP 34m
nginx-ingress-ingress-nginx-controller LoadBalancer 10.242.13.184 80:30601/TCP,443:30644/TCP 40 s
nginx-ingress-ingress-nginx-controller-metrics IP Cluster 10.242.12.190 9913/TCP 40 s
nginx-ingress-ingress-nginx-defaultbackend IP Cluster 10.242.11.112 80/TCP 39 s
Vous voyez ici que les pods sont mis à jour et nous voyons deux services, un ancien et un nouveau.
Exécutons kubectl -n nginx-ingress get svc encore :
$ kubectl -n nginx-ingress get svc
NOM TYPE IP-CLUSTER IP-EXTERNE PORT(S) ANTÉRIORITÉ
nginx-ingress-ingress-nginx-controller LoadBalancer 10.242.13.184 35.197.192.35 80:30601/TCP,443:30644/TCP 3m26 s
nginx-ingress-ingress-nginx-controller-metrics IP Cluster 10.242.12.190 9913/TCP 3 m 26 s
nginx-ingress-ingress-nginx-defaultbackend IP Cluster 10.242.11.112 80/TCP 3 m 25 s
Voila, l’ancien service a été supprimé et le nouveau créé juste en exécutant helm upgrade et sans utiliser d’autre magie avec kubectl. Bien entendu, le remplacement du service entraîne une certaine indisponibilité, car le nouvel équilibreur de charge doit être créé pour le nouveau service.
Merci, et bonne chance
Assez facile, non ? Un grand merci aux responsables du chart NGINX Ingress Controller pour une mise à jour aussi transparente entre deux charts différents !
Avec un peu de chance, la transition vers des dépôts de cartes individuels pour vos autres applications K8s se fera également en douceur. L’utilisation de ChartCenter en tant que dépôt central de charts Helm peut vous aider à effectuer ces mises à jour.
Joyeux Ingressing
See what JFrog & GitHub can do together
