Accueil du blog

Migrer NGINX à partir du dépôt « stable » charts Helm avec ChartCenter

Par Rimas Mocevicius

11 min read

 

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

Popular Tags