Helm on Zwindler's Reflection

Pourquoi Helm 2 doit disparaître

Mon, 19 Apr 2021 07:59:14 +0000

Deployer sur Kubernetes avec Helm, c’est vraiment se faire du mal

Je ne sais plus qui parmi vous écrivait il y a peu « Avec Kubernetes, c’est un peu une love/hate relationship ». J’adore Kubernetes, particulièrement dans les contextes où il résout des « million-dollar problems ». Mais alors… QU’EST CE QUE JE DETESTE HELM.

Je rage / shitpost régulièrement sur Helm, mais malheureusement il n’y a pas tant d’alternatives pour déployer facilement dans Kubernetes (oui je sais qu’il y en a, ce n’est pas le but du post).

Mais attend, tu parles de Helm 2 dans ton titre ?

Ça fait des années que j’ai ce brouillon en attente sur le blog (encore un, me direz-vous). Je commençais à me dire que ce n’avait plus vraiment d’intérêt de le poster maintenant que Helm 2 est officiellement déprécié et remplacé par Helm 3 depuis quasiment 1 an.

Mais j’ai lu un chouette article de serveur410 il y a quelques jours qui m’a décomplexé de poster des articles anachroniques (et je vous invite à aller lire cet article, que vous ayez un blog ou non).

Donc oui, je vais parler d’une techno dépréciée depuis plus d’un an et dont le remplaçant qui est censé magiquement régler tous les problèmes est apparu en 2019.

Pour autant, ce n’est pas parce que cet article va parler de Helm 2, de ses bugs que j’ai rencontrés et de comment on se sort de chaque situation pourrie. Le plus simple étant de passer à Helm 3, même sil est pété lui aussi (on en reparlera sûrement).

Déployer avec Helm2, quel enfer !

Mais revenons à Helm 2. En 2018/2019, je déploie en production des applications dans un Kubernetes managé qu’on manage nous-même (trop long à expliquer ;-p).

On avait la « flemme » de migrer de Helm 2 à Helm 3 et franchement on a vraiment eu tort. Je vais vous faire une petite histoire vraie de ce qui s’est passé lorsque j’ai essayé de redéployer un prometheus.

La genèse

Pour une raison qui m’échappe (car le brouillon est beaucoup trop vieux), j’ai commencé par supprimer la release helm plutôt que d’upgrade mon déploiement (la release devait être dans un état foireux, et comme Helm 2 ne supporte pas le 3-way merge…).

Je supprime donc ma release.

zwindler$ helm delete prometheus
release "prometheus" deleted

Je ne peux donc plus « upgrade » ma release puisqu’elle n’existe plus.

zwindler$ helm upgrade prometheus stable/prometheus
Error: UPGRADE FAILED: "prometheus" has no deployed releases

So far, so good

J’essaye donc de la réinstaller

zwindler$ helm install prometheus stable/prometheus
Error: This command needs 1 argument: chart name

Ah ! Et oui, la commande est différente selon qu’on upgrade ou qu’on install une release. Pratique.

Vous allez me dire « bah, pourquoi tu ne fais pas un upgrade –install, comme ça la commande est la même que tu upgrade ou que tu installes ?

Tout simplement car cette commande ne marchait PLUS pendant longtemps (genre 2 ans), comme le témoigne cette issue sur Github et ce tweet rageur d’un certain zwindler

Enfin bon…

zwindler$ helm install --name prometheus stable/prometheus
Error: a release named prometheus already exists.

Là, par contre, on est d’accord que Helm se fiche vraiment de moi ?

Donc, dans ce genre de souci, vous pouvez sortir l’artillerie lourde avec le « –purge », qui fini par devenir la norme (en gros, je le mettais à chaque fois).

zwindler$ helm delete prometheus --purge
release "prometheus" deleted

Et là on peut réinstaller sa release…

zwindler$ helm install --name prometheus stable/prometheus -f prom-values-with-thanos.yaml
NAME: prometheus
LAST DEPLOYED: Thu Oct 10 15:12:39 2019
NAMESPACE: monitoring
STATUS: DEPLOYED

Bon… et la prochaine fois que vous voudrez mettre à jour les valeurs de votre déploiement, n’oubliez pas de refaire des « upgrade » et pas « install », sinon il va vous conseiller de la delete ;)

zwindler$ helm install --name prometheus stable/prometheus -f prom-values-with-thanos.yaml
Error: a release named prometheus already exists.
Run: helm ls --all prometheus; to check the status of the release
Or run: helm del --purge prometheus; to delete it

Et c’est pas fini !

Dans les bugs rigolos de Helm 2, on a aussi le flag DEBUG, souvent utilisé dans les Charts pour activer le mode debug du logiciel que vous essayez de déployer, qui est AUSSI utilisé par Helm pour passer en debug et qui vous crache du caca dans votre CI.

Client: &amp;version.Version{SemVer:"v2.4.1", GitCommit:"46d9ea82e2c925186e1fc620a8320ce1314cbb02", GitTreeState:"clean"}
2017/05/06 16:11:47 (0xc42088e210) (0xc4204be000) Create stream
2017/05/06 16:11:47 (0xc42088e210) (0xc4204be000) Stream added, broadcasting: 1
2017/05/06 16:11:47 (0xc42088e210) Reply frame received for 1
2017/05/06 16:11:47 (0xc4204be000) (1) Writing data frame
2017/05/06 16:11:47 (0xc42088e210) (0xc4204be140) Create stream
2017/05/06 16:11:47 (0xc42088e210) (0xc4204be140) Stream added, broadcasting: 3
...

github.com/helm/helm/issues/2401

Ah oui tient, c’est marrant ça, on devrait peut être changer DEBUG en HELM_DEBUG ?No shit, sherlock

Ou bien les ConfigMap trop grandes (lol) qui font planter tiller

[storage] 2020/01/14 15:00:16 getting release history for "airflow"
[storage/driver] 2020/01/14 15:00:16 create: failed to create: ConfigMap "airflow.v1" is invalid: []: Too long: must have at most 1048576 characters
[tiller] 2020/01/14 15:00:16 warning: Failed to record release airflow: ConfigMap "airflow.v1" is invalid: []: Too long: must have at most 1048576 characters
[kube] 2020/01/14 15:00:16 building resources from manifest
[kube] 2020/01/14 15:00:16 creating 21 resource(s)
[kube] 2020/01/14 15:00:18 beginning wait for 21 resources with timeout of 5m0s
[kube] 2020/01/14 15:00:20 Pod is not ready: airflow/airflow-worker-0
[kube] 2020/01/14 15:00:38 Pod is not ready: airflow/airflow-worker-0
[kube] 2020/01/14 15:00:40 Pod is not ready: airflow/airflow-worker-1
[kube] 2020/01/14 15:00:42 Pod is not ready: airflow/airflow-worker-1
[kube] 2020/01/14 15:00:44 Pod is not ready: airflow/airflow-worker-1
[kube] 2020/01/14 15:00:46 Pod is not ready: airflow/airflow-worker-1
[tiller] 2020/01/14 15:01:40 executing 0 post-install hooks for airflow
[tiller] 2020/01/14 15:01:40 hooks complete for post-install airflow
[storage] 2020/01/14 15:01:40 updating release "airflow.v1"
[storage/driver] 2020/01/14 15:01:40 update: failed to update: configmaps "airflow.v1" not found
[tiller] 2020/01/14 15:01:40 warning: Failed to update release airflow: configmaps "airflow.v1" not found

github.com/helm/helm/issues/1413

Ou enfin, les timeouts de tiller quand vous avez trop déployé (lol) et que du coup les commandes « helm list » timeout… ce qui nous avait obligé à installer un tiller par namespace et modifier notre CI pour gérer tout ce bazar.

Non, vraiment, Helm 2 est vraiment un chouette logiciel !

Se simplifier Kubernetes avec Helm et les Charts

Tue, 06 Feb 2018 12:45:16 +0000

Helm, Tiller, Charts : c’est quoi tout ça ?

Ceux qui suivent un peu le blog savent que je bidouille pas mal avec Kubernetes en ce moment. Dans mon travail précédent on commençait à peut être se dire que Swarm n’allait pas être suffisant (ahaha) et j’avais donc décidé de prendre les devants histoire de savoir de quoi je parle au moment où la décision serait prise de foncer ;-). Et rapidement je me suis rendu compte, qu’avec Kubernetes, on se retrouve vite à devoir écrire du YAML à tour de bras pour configurer nos ressources (« petit » exemple avec XWiki, une application Tomcat + SGBDr). C’est là que Helm (et Tiller) et les Charts entrent en jeu.

L’idée derrière Helm et les Charts ? Avoir un magasin en ligne d’applications multi-tiers déployables en une seule ligne de commande.

The package manager for Kubernetes

Il faut voir celà comme un magasin un peu sur la philosophie de Dockerhub (applications officielles ou fournies par la communauté), permettant de déployer sur notre cluster des applications potentiellement complexes et/ou multi-tiers de manière automatique (un peu comme un docker-compose mais pour Kubernetes).

Avant d’aller plus loin, un peu de terminologie :

Charts : Collection de fichiers YAML variabilisés décrivant des ressources qui, misent bout à bout, donnent une application déployable sur Kubernetes
Helm : Client permettant de récupérer des Charts et de les appliquer sur un cluster Kubernetes
Tiller : Partie serveur permettant à un client Helm donner des ordres au cluster Kubernetes visé

Installation de Helm

Ne faisons pas durer le suspens plus longtemps et attaquons nous à l’installation des composants nécessaires !

A noter, je pars du principe que vous disposez d’un cluster Kubernetes fonctionnel et que celui ci tourne sous Linux. Si ce n’est pas le cas je vous propose de lire mes tutoriels sur le déploiement de cluster Kubernetes, soit avec Ansible (Kubespray) soit avec l’outil Kubeadm.

A l’heure où j’écris ces lignes, l’outil Helm est disponible à sa version 2.8.0. Vous pouvez retrouver la documentation officielle sur le Github et sur le site de Helm.

En réalité, il s’agit simplement d’une copie du binaire.

curl -o helm.tar.gz https://kubernetes-helm.storage.googleapis.com/helm-v2.8.0-linux-amd64.tar.gz
tar xzf helm.tar.gz
mv linux-amd64/helm /usr/local/bin

Contexte

Dans le cas où vous ne seriez pas directement sur une des machines du cluster, il est nécessaire de disposer de kubectl et surtout d’avoir correctement configuré son « contexte ».

Dans le cas où le contexte n’est pas configuré vous aurez le message suivant :

kubectl config current-context
error: current-context is not set

Cependant, si vous vous mettez en SSH directement sur un serveur qui est master, cette étape est potentiellement inutile (le contexte par défaut est administrateur dans ce cas).

On vérifie qu’on arrive bien à requêter le cluster :

kubectl cluster-info
Kubernetes master is running at http://localhost:8080
KubeDNS is running at http://localhost:8080/api/v1/namespaces/kube-system/services/kube-dns/proxy

Tiller

Maintenant qu’on dispose d’un client Helm ayant accès au contexte de notre cluster, on peut installer Tiller. Utiliser la commande « helm init ». Attention : Tiller sera installé dans le contexte courant, ne vous trompez pas de cluster ;-).

helm init
Creating /root/.helm
Creating /root/.helm/repository
Creating /root/.helm/repository/cache
Creating /root/.helm/repository/local
Creating /root/.helm/plugins
Creating /root/.helm/starters
Creating /root/.helm/cache/archive
Creating /root/.helm/repository/repositories.yaml
Adding stable repo with URL: https://kubernetes-charts.storage.googleapis.com
Adding local repo with URL: http://127.0.0.1:8879/charts
$HELM_HOME has been configured at /root/.helm.
Tiller (the Helm server-side component) has been installed into your Kubernetes Cluster.
Happy Helming!

Et maintenant, on fait quoi ?

Maintenant qu’on a installé tous les composants dont nous avions besoin (et oui déjà), on va se contenter de dans un premier temps de suivre les exemples fournis. La documentation officielle nous propose de déployer une base MySQL.

Bonne idée, voyons ce que ça donne !

La première étape qu’on nous demande de faire est de mettre à jour la liste des Charts disponibles sur le dépôt officiel :

helm repo update #mettre à jour la liste des charts disponibles sur le store officiel
Hang tight while we grab the latest from your chart repositories...
...Skip local chart repository
...Successfully got an update from the "stable" chart repository
Update Complete. ⎈ Happy Helming!⎈

J’adore le petit caractère « barre de navigateur » ;-)

Plus sérieusement, l’étape d’après est simplement de faire un helm install, qui va se charger de récupérer tous les YAML nécessaires pour déployer MySQL. La liste des composants Kubernetes créés apparaitra ensuite à l’écran (et vous pouvez les retrouver sur votre cluster avec un kubectl).

helm install stable/mysql
NAME: silly-moose
LAST DEPLOYED: Tue Dec 5 10:12:58 2017
NAMESPACE: default
STATUS: DEPLOYED
RESOURCES:
==> v1/Secret
NAME TYPE DATA AGE
silly-moose-mysql Opaque 2 1m
==> v1/PersistentVolumeClaim
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
silly-moose-mysql Pending 1m
==> v1/Service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
silly-moose-mysql ClusterIP 10.233.54.164 3306/TCP 1m
==> v1beta1/Deployment
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
silly-moose-mysql 1 1 1 0 1m
==> v1/Pod(related)
NAME READY STATUS RESTARTS AGE
silly-moose-mysql-3998799777-hk5fj 0/1 Pending 0 1m

Sans surprise on retrouve un Secret (le mot de passe de votre utilisateur), un PersistentVolumeClaim (pour stocker vos données), un Service de type ClusterIP pour accéder et un Deployment pour MySQL lui même.

A noter : par défaut, Kubernetes donne un petit nom aléatoire à nos composants pour les rendre uniques, car nous n’avons pas donné de nom en arguments.

On remarquera la délicate attention des gens qui ont écrit le Chart et qui affiche, une fois le déploiement terminé, les étapes suivantes pour vérifier que tout fonctionne et se connecter une première fois.

NOTES:
MySQL can be accessed via port 3306 on the following DNS name from within your cluster:
silly-moose-mysql.default.svc.cluster.local
To get your root password run:
kubectl get secret --namespace default silly-moose-mysql -o jsonpath="{.data.mysql-root-password}" | base64 --decode; echo
To connect to your database:
1. Run an Ubuntu pod that you can use as a client:
kubectl run -i --tty ubuntu --image=ubuntu:16.04 --restart=Never -- bash -il
2. Install the mysql client:
$ apt-get update && apt-get install mysql-client -y
3. Connect using the mysql cli, then provide your password:
$ mysql -h silly-moose-mysql -p

OK je teste alors !

Et normalement, si vous essayez, ça ne marchera pas !

Pourquoi ça ? On a bien tous les composants pour faire marcher MySQL.

Tous ?

Non ! Un irréductible gaulois résiste à l’envahisseur. Vous l’avez trouvé ?

Et oui ! La documentation nous dit juste de faire un helm install… sans nous rappeler que le PersistentVolumeClaim qui sera créé nécessite … un PersistentVolume ! Pour ceux qui n’auraient pas révisé leur terminologie Kubernetes, en gros MySQL attend qu’un disque se libère mais aucun n’est disponible.

Le Deployment se bloque donc à l’étape de Claim et y restera indéfiniment tant qu’un PV compatible n’est pas disponible.

On doit donc créer un PV. Personnellement j’ai créé un volume gluster parce que j’aime bien GlusterFS et j’ai créé le PV manquant dans Kubernetes.

gluster volume create gluster-pv-mysql replica 3 node01:/brick/gluster-pv-mysql node02:/brick/gluster-pv-mysql node03:/brick/gluster-pv-mysql force
volume create: gluster-pv-mysql: success: please start the volume to access data
gluster volume start gluster-pv-mysql
volume start: gluster-pv-mysql: success
cat > gluster-pv-mysql.yaml << EOF
apiVersion: v1
kind: PersistentVolume
metadata:
name: gluster-pv-mysql
spec:
capacity:
storage: 20Gi
accessModes:
- ReadWriteOnce
glusterfs:
endpoints: gluster-cluster
path: /gluster-pv-mysql
readOnly: false
persistentVolumeReclaimPolicy: Delete
EOF
kubectl apply -f gluster-pv-mysql.yaml

A partir de là, votre Deployment devrait reprendre la main.

Facile, hein ?

Ouais ok mais moi je veux modifier le nom de ma base MySQL

Ok on est capable de déployer MySQL, super. Mais généralement on veut personnaliser les composants qu’on déploie !

C’est bien évidemment prévu par les Charts, c’est même leur but premier.

Pour savoir ce qui peut être personnalisé et qui dépendra de chaque Chart que vous utiliserez, pas le choix : il faut aller lire la documentation du Chart de MySQL (ici sur Github).

Pour vous donner un petit exemple de ce qu’on peut faire avec notre MySQL, voici quelques arguments utiles que vous pouvez personnaliser :

helm install --name test \
--set mysqlLRootPassword=secretpassword,mysqlUser=zwindler,mysqlPassword=supermotdepasse,mysqlDatabase=zwindlerdb \
stable/mysql

Après déploiement, on peut retester la connexion via un container ubuntu temporaire (comme la fois d’avant), et s’assurer qu’on peut se connecter sur notre base MySQL avec notre nouvel utilisateur zwindler et son supermotdepasse !

[root@node01 ~]# kubectl run -i --tty ubuntu --image=ubuntu:16.04 --restart=Never -- bash -il
If you don't see a command prompt, try pressing enter.
root@ubuntu:/#
root@ubuntu:/# apt-get update && apt-get install mysql-client -y
[…]
mysql -h test-mysql -u zwindler -p
#supermotdepasse

Et on nettoie tout : supprimer un Chart

Dans le cas où vous voudriez tout nettoyer d’un coup, vous pouvez utiliser Helm pour supprimer en même temps tous les composants que vous auriez déployés via un « helm install mon-chart ».

Ici, je peux supprimer l’ensemble des composants qui ont été créés dans cet exemple « silly-moose-mysql ».

helm delete silly-moose-mysql
release "silly-moose-mysql" deleted