Utilisation de Helm
Ce guide présente les bases de l'utilisation de Helm pour gérer des paquets sur votre cluster Kubernetes. Il suppose que vous avez déjà installé le client Helm.
Si vous souhaitez simplement exécuter quelques commandes rapides, vous pouvez commencer par le guide de démarrage rapide. Ce chapitre détaille les commandes Helm et explique comment utiliser Helm.
Ce guide suppose que vous connaissez les charts, les dépôts et les releases. Pour une présentation de ces composants, consultez Introduction à Helm.
'helm search' : trouver des charts
Helm dispose d'une commande de recherche puissante. Elle permet de chercher dans deux types de sources :
helm search hubcherche dans Artifact Hub, qui référence des charts Helm provenant de dizaines de dépôts différents.helm search repocherche dans les dépôts que vous avez ajoutés à votre client Helm local (avechelm repo add). Cette recherche porte sur des données locales et ne nécessite aucune connexion au réseau public.
Vous pouvez trouver des charts publics en exécutant helm search hub :
$ helm search hub wordpress
URL CHART VERSION APP VERSION DESCRIPTION
https://hub.helm.sh/charts/bitnami/wordpress 7.6.7 5.2.4 Web publishing platform for building blogs and ...
https://hub.helm.sh/charts/presslabs/wordpress-... v0.6.3 v0.6.3 Presslabs WordPress Operator Helm Chart
https://hub.helm.sh/charts/presslabs/wordpress-... v0.7.1 v0.7.1 A Helm chart for deploying a WordPress site on ...
La commande ci-dessus recherche tous les charts wordpress sur Artifact Hub.
Sans filtre, helm search hub affiche tous les charts disponibles.
helm search hub affiche l'URL de la page sur artifacthub.io, mais pas celle du dépôt Helm lui-même. helm search hub --list-repo-url affiche l'URL réelle du dépôt Helm, ce qui est pratique pour ajouter un nouveau dépôt : helm repo add [NAME] [URL].
Avec helm search repo, vous pouvez trouver le nom des charts présents dans les dépôts
que vous avez déjà ajoutés :
$ helm repo add brigade https://brigadecore.github.io/charts
"brigade" has been added to your repositories
$ helm search repo brigade
NAME CHART VERSION APP VERSION DESCRIPTION
brigade/brigade 1.3.2 v1.2.1 Brigade provides event-driven scripting of Kube...
brigade/brigade-github-app 0.4.1 v0.2.1 The Brigade GitHub App, an advanced gateway for...
brigade/brigade-github-oauth 0.2.0 v0.20.0 The legacy OAuth GitHub Gateway for Brigade
brigade/brigade-k8s-gateway 0.1.0 A Helm chart for Kubernetes
brigade/brigade-project 1.0.0 v1.0.0 Create a Brigade project
brigade/kashti 0.4.0 v0.4.0 A Helm chart for Kubernetes
La recherche de Helm utilise un algorithme de correspondance approximative : vous pouvez donc saisir des parties de mots ou d'expressions :
$ helm search repo kash
NAME CHART VERSION APP VERSION DESCRIPTION
brigade/kashti 0.4.0 v0.4.0 A Helm chart for Kubernetes
La recherche est un bon moyen de trouver les paquets disponibles. Une fois que vous avez
trouvé le paquet à installer, vous pouvez l'installer avec helm install.
'helm install' : installer un paquet
Pour installer un nouveau paquet, utilisez la commande helm install. Dans sa forme la
plus simple, elle prend deux arguments : un nom de release que vous choisissez et le nom
du chart à installer.
$ helm install happy-panda bitnami/wordpress
NAME: happy-panda
LAST DEPLOYED: Tue Jan 26 10:27:17 2021
NAMESPACE: default
STATUS: deployed
REVISION: 1
NOTES:
** Please be patient while the chart is being deployed **
Your WordPress site can be accessed through the following DNS name from within your cluster:
happy-panda-wordpress.default.svc.cluster.local (port 80)
To access your WordPress site from outside the cluster follow the steps below:
1. Get the WordPress URL by running these commands:
NOTE: It may take a few minutes for the LoadBalancer IP to be available.
Watch the status with: 'kubectl get svc --namespace default -w happy-panda-wordpress'
export SERVICE_IP=$(kubectl get svc --namespace default happy-panda-wordpress --template "{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}")
echo "WordPress URL: http://$SERVICE_IP/"
echo "WordPress Admin URL: http://$SERVICE_IP/admin"
2. Open a browser and access WordPress using the obtained URL.
3. Login with the following credentials below to see your blog:
echo Username: user
echo Password: $(kubectl get secret --namespace default happy-panda-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode)
Le chart wordpress est maintenant installé. Notez que l'installation d'un chart crée un
nouvel objet release. La release ci-dessus s'appelle happy-panda. (Si vous voulez que
Helm génère un nom pour vous, omettez le nom de release et utilisez
--generate-name.)
Pendant l'installation, le client helm affiche des informations utiles : les ressources
créées, l'état de la release, et les éventuelles étapes de configuration supplémentaires
que vous pouvez ou devez effectuer.
Helm installe les ressources dans l'ordre suivant :
- Namespace
- NetworkPolicy
- ResourceQuota
- LimitRange
- PodSecurityPolicy
- PodDisruptionBudget
- ServiceAccount
- Secret
- SecretList
- ConfigMap
- StorageClass
- PersistentVolume
- PersistentVolumeClaim
- CustomResourceDefinition
- ClusterRole
- ClusterRoleList
- ClusterRoleBinding
- ClusterRoleBindingList
- Role
- RoleList
- RoleBinding
- RoleBindingList
- Service
- DaemonSet
- Pod
- ReplicationController
- ReplicaSet
- Deployment
- HorizontalPodAutoscaler
- StatefulSet
- Job
- CronJob
- Ingress
- APIService
- MutatingWebhookConfiguration
- ValidatingWebhookConfiguration
Helm n'attend pas que toutes les ressources soient en cours d'exécution pour rendre la main. De nombreux charts nécessitent des images Docker de plus de 600 Mo, qui peuvent mettre longtemps à s'installer dans le cluster.
Pour suivre l'état d'une release ou relire ses informations de configuration, vous
pouvez utiliser helm status :
$ helm status happy-panda
NAME: happy-panda
LAST DEPLOYED: Tue Jan 26 10:27:17 2021
NAMESPACE: default
STATUS: deployed
REVISION: 1
NOTES:
** Please be patient while the chart is being deployed **
Your WordPress site can be accessed through the following DNS name from within your cluster:
happy-panda-wordpress.default.svc.cluster.local (port 80)
To access your WordPress site from outside the cluster follow the steps below:
1. Get the WordPress URL by running these commands:
NOTE: It may take a few minutes for the LoadBalancer IP to be available.
Watch the status with: 'kubectl get svc --namespace default -w happy-panda-wordpress'
export SERVICE_IP=$(kubectl get svc --namespace default happy-panda-wordpress --template "{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}")
echo "WordPress URL: http://$SERVICE_IP/"
echo "WordPress Admin URL: http://$SERVICE_IP/admin"
2. Open a browser and access WordPress using the obtained URL.
3. Login with the following credentials below to see your blog:
echo Username: user
echo Password: $(kubectl get secret --namespace default happy-panda-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode)
La commande ci-dessus affiche l'état actuel de votre release.
Personnaliser le chart avant l'installation
Une installation comme celle ci-dessus n'utilise que les options de configuration par défaut du chart. Bien souvent, vous voudrez personnaliser le chart pour appliquer votre propre configuration.
Pour voir les options configurables d'un chart, utilisez helm show values :
$ helm show values bitnami/wordpress
## Global Docker image parameters
## Please, note that this will override the image parameters, including dependencies, configured to use the global value
## Current available global Docker image parameters: imageRegistry and imagePullSecrets
##
# global:
# imageRegistry: myRegistryName
# imagePullSecrets:
# - myRegistryKeySecretName
# storageClass: myStorageClass
## Bitnami WordPress image version
## ref: https://hub.docker.com/r/bitnami/wordpress/tags/
##
image:
registry: docker.io
repository: bitnami/wordpress
tag: 5.6.0-debian-10-r35
[..]
Vous pouvez ensuite surcharger n'importe lequel de ces paramètres dans un fichier au format YAML, puis passer ce fichier lors de l'installation.
$ echo '{mariadb.auth.database: user0db, mariadb.auth.username: user0}' > values.yaml
$ helm install -f values.yaml bitnami/wordpress --generate-name
La commande ci-dessus crée un utilisateur MariaDB par défaut nommé user0 et lui donne
accès à une base de données user0db nouvellement créée, tout en conservant toutes les
autres valeurs par défaut du chart.
Il existe deux façons de transmettre des données de configuration lors de l'installation :
--values(ou-f) : indique un fichier YAML contenant les surcharges. Cette option peut être répétée, et c'est le fichier le plus à droite qui a la priorité.--set: indique les surcharges en ligne de commande.
Si les deux sont utilisées, les valeurs de --set sont fusionnées dans celles de
--values avec une priorité plus élevée. Les surcharges indiquées avec --set sont
conservées dans un Secret. Pour une release donnée, les valeurs définies avec --set
peuvent être consultées avec
helm get values <release-name>. Elles peuvent être effacées en exécutant
helm upgrade avec l'option --reset-values.
Le format et les limites de --set
L'option --set accepte zéro ou plusieurs paires nom/valeur. Dans sa forme la plus
simple, elle s'utilise ainsi : --set name=value. L'équivalent en YAML est :
name: value
Plusieurs valeurs se séparent par le caractère ,. Ainsi, --set a=b,c=d devient :
a: b
c: d
Des expressions plus complexes sont acceptées. Par exemple, --set outer.inner=value
se traduit par :
outer:
inner: value
Les listes s'expriment en entourant les valeurs de { et }. Par exemple, --set name={a, b, c} se traduit par :
name:
- a
- b
- c
Certains noms ou clés peuvent être définis à null ou à un tableau vide []. Par exemple, --set name=[],a=null transforme
name:
- a
- b
- c
a: b
en
name: []
a: null
Depuis Helm 2.5.0, il est possible d'accéder aux éléments d'une liste avec la syntaxe
d'indice de tableau. Par exemple, --set servers[0].port=80 devient :
servers:
- port: 80
Plusieurs valeurs peuvent être définies de cette façon. La ligne --set servers[0].port=80,servers[0].host=example devient :
servers:
- port: 80
host: example
Il arrive que vous deviez utiliser des caractères spéciaux dans vos lignes --set. Vous
pouvez les échapper avec une barre oblique inverse : --set name=value1\,value2 devient :
name: "value1,value2"
De la même façon, vous pouvez échapper les points, ce qui peut être utile lorsque des
charts utilisent la fonction toYaml pour analyser des annotations, des labels ou des
sélecteurs de nœuds. La syntaxe --set nodeSelector."kubernetes\.io/role"=master
devient :
nodeSelector:
kubernetes.io/role: master
Les structures de données profondément imbriquées peuvent être difficiles à exprimer avec
--set. Les concepteurs de charts sont invités à tenir compte de l'usage de --set
lorsqu'ils conçoivent le format d'un fichier values.yaml (pour en savoir plus, consultez
Fichiers de valeurs).
Autres méthodes d'installation
La commande helm install peut installer depuis plusieurs sources :
- Un dépôt de charts (comme vu ci-dessus)
- Une archive de chart locale (
helm install foo foo-0.1.1.tgz) - Un répertoire de chart décompressé (
helm install foo path/to/foo) - Une URL complète (
helm install foo https://example.com/charts/foo-1.2.3.tgz)
'helm upgrade' et 'helm rollback' : mettre à niveau une release et revenir en arrière après un échec
Quand une nouvelle version d'un chart est publiée, ou quand vous voulez modifier la
configuration de votre release, vous pouvez utiliser la commande helm upgrade.
Une mise à niveau prend une release existante et la met à niveau selon les informations que vous fournissez. Comme les charts Kubernetes peuvent être volumineux et complexes, Helm essaie d'effectuer la mise à niveau la moins invasive possible. Il ne met à jour que ce qui a changé depuis la dernière release.
$ helm upgrade -f panda.yaml happy-panda bitnami/wordpress
Dans l'exemple ci-dessus, la release happy-panda est mise à niveau avec le même chart,
mais avec un nouveau fichier YAML :
mariadb.auth.username: user1
Nous pouvons utiliser helm get values pour vérifier que ce nouveau paramètre a bien été
pris en compte.
$ helm get values happy-panda
mariadb:
auth:
username: user1
La commande helm get est un outil utile pour examiner une release dans le cluster.
Comme nous le voyons ci-dessus, elle montre que les nouvelles valeurs de panda.yaml ont
bien été déployées dans le cluster.
Si quelque chose ne se passe pas comme prévu lors d'une release, il est facile de revenir
à une release précédente avec helm rollback [RELEASE] [REVISION].
$ helm rollback happy-panda 1
La commande ci-dessus ramène notre happy-panda à sa toute première version de release.
Chaque version de release correspond à un numéro de révision incrémenté. À chaque installation, mise à
niveau ou restauration (rollback), le numéro de révision augmente de 1. Le premier numéro de
révision est toujours 1. La commande helm history [RELEASE] affiche les
numéros de révision d'une release donnée.
Si une release a été créée par une restauration, passez --show-rollback-revision à
helm history pour ajouter une colonne ROLLBACK à la sortie. Cette colonne indique la
révision ciblée par chaque restauration.
Options utiles pour l'installation, la mise à niveau et la restauration
Plusieurs autres options utiles permettent de personnaliser le comportement de Helm lors
d'une installation, d'une mise à niveau ou d'une restauration. Notez que cette liste des options de la CLI
n'est pas exhaustive. Pour la description de toutes les options, exécutez simplement
helm <command> --help.
--timeout: une durée Go pendant laquelle attendre la fin des commandes Kubernetes. La valeur par défaut est5m0s.--wait: attend que tous les Pods soient prêts, que les PVC soient liés, que les Deployments aient le nombre minimal de Pods prêts (DesiredmoinsmaxUnavailable) et que les Services aient une adresse IP (et une adresse d'entrée s'il s'agit d'un ServiceLoadBalancer) avant de marquer la release comme réussie. L'attente dure au maximum la valeur de--timeout. Si ce délai est atteint, la release est marquéeFAILED. Remarque : si un Deployment areplicasà 1 et quemaxUnavailablen'est pas à 0 dans sa stratégie de mise à jour progressive,--waitconsidère la release prête dès que le nombre minimal de Pods prêts est atteint.--no-hooks: n'exécute pas les hooks pour la commande
'helm uninstall' : désinstaller une release
Quand il est temps de désinstaller une release du cluster, utilisez la commande helm uninstall :
$ helm uninstall happy-panda
Cette commande supprime la release du cluster. Vous pouvez voir les releases
actuellement déployées avec la commande helm list --deployed :
$ helm list --deployed
NAME VERSION UPDATED STATUS CHART
inky-cat 1 Wed Sep 28 12:59:46 2016 DEPLOYED alpine-0.1.0
La sortie ci-dessus montre que la release happy-panda a bien été
désinstallée.
Dans les versions précédentes de Helm, la suppression d'une release laissait une trace de
cette suppression. Depuis Helm 3, la suppression efface aussi l'enregistrement de la release.
Si vous souhaitez conserver cet enregistrement, utilisez helm uninstall --keep-history. helm list --uninstalled n'affiche que les releases
désinstallées avec l'option --keep-history.
Sans option, helm list affiche tous les enregistrements de releases que Helm a
conservés, quel que soit leur état, y compris ceux des releases en échec ou supprimées
(si --keep-history a été utilisé) :
$ helm list
NAME VERSION UPDATED STATUS CHART
happy-panda 2 Wed Sep 28 12:47:54 2016 UNINSTALLED wordpress-10.4.5.6.0
inky-cat 1 Wed Sep 28 12:59:46 2016 DEPLOYED alpine-0.1.0
kindred-angelf 2 Tue Sep 27 16:16:10 2016 UNINSTALLED alpine-0.1.0
Notez que, comme les releases sont désormais supprimées par défaut, il n'est plus possible de restaurer une ressource désinstallée.
'helm repo' : gérer les dépôts
Helm 3 n'est plus livré avec un dépôt de charts par défaut. Le groupe de commandes
helm repo permet d'ajouter, de lister et de supprimer des dépôts.
Vous pouvez voir les dépôts configurés avec helm repo list :
$ helm repo list
NAME URL
stable https://charts.helm.sh/stable
mumoshu https://mumoshu.github.io/charts
Vous pouvez ajouter de nouveaux dépôts avec helm repo add [NAME] [URL] :
$ helm repo add dev https://example.com/dev-charts
Comme les dépôts de charts changent souvent, vous pouvez à tout moment vous assurer que
votre client Helm est à jour en exécutant helm repo update.
Les dépôts peuvent être supprimés avec helm repo remove.
Créer vos propres charts
Le guide de développement des charts explique comment
développer vos propres charts. Mais vous pouvez démarrer rapidement avec la commande helm create :
$ helm create deis-workflow
Creating deis-workflow
Un chart se trouve maintenant dans ./deis-workflow. Vous pouvez le modifier et créer vos
propres templates.
Pendant que vous modifiez votre chart, vous pouvez vérifier qu'il est bien formé en
exécutant helm lint.
Quand il est temps d'empaqueter le chart pour le distribuer, vous pouvez exécuter la
commande helm package :
$ helm package deis-workflow
deis-workflow-0.1.0.tgz
Ce chart peut maintenant être facilement installé avec helm install :
$ helm install deis-workflow ./deis-workflow-0.1.0.tgz
...
Les charts empaquetés peuvent être publiés dans des dépôts de charts. Consultez la documentation sur les dépôts de charts Helm pour plus de détails.
Conclusion
Ce chapitre a présenté les usages de base du client helm : recherche, installation,
mise à niveau et désinstallation. Il a aussi présenté des commandes utilitaires comme
helm status, helm get et helm repo.
Pour plus d'informations sur ces commandes, consultez l'aide intégrée de Helm :
helm help.
Dans le chapitre suivant, nous verrons comment développer des charts.