Utiliser kubernetes
Ressoures générales
- Play with Kubernetes est un terrain de jeu qui permet aux utilisateurs d’exécuter des clusters K8s en quelques secondes. Il donne l’expérience d’avoir une machine virtuelle Alpine Linux gratuite dans le navigateur.
Forcer une synchronisation
Gitlab notifie Flux des push, lequel synchronise rapidement les modifications. Ce mécanisme n’est toutefois pas entièrement fiable, et soumis à des rate limits qui font que certains push ne sont pas immédiatement appliqués. Si attendre les 30 minutes de tour de boucle n’est pas au programme, simplement forcer une réconciliation :
flux -n kube-ops reconcile kustomization cluster --with-source
Ceci commence par pull la source (le dépôt Git Kity) puis mettre à jour la Kustomization
principale nommée cluster
, qui déploie tout le reste.
Mise à jour des images
Flux supporte la mise à jour automatique des configurations en inspectant les images Docker sur le repository. Ce comportement couplé à la CI Gitlab permet de déployer en continu sur Kity : en poussant la mise à jour, Gitlab construit l’image Docker en CI, puis Flux détecte la nouvelle image, met à jour la configuration, la réapplique et s’assure que le déploiement réussit.
Actuellement Flux ne supporte pas de colocaliser la configuration de mise à jour des images
avec la configuration de déploiement toutefois. La mise à jour des images est donc
intégralement configurée dans kube-ops/flux-images.yaml
, avec pour chaque image :
---
## Un repository qui déclare la source de l'image
apiVersion: image.toolkit.fluxcd.io/v1beta1
kind: ImageRepository
metadata:
name: element
spec:
image: docker.tedomum.net/tedomum/riot-web
interval: 10m0s
---
## Une policy qui déclare comment déterminer l'image la plus récente
apiVersion: image.toolkit.fluxcd.io/v1beta1
kind: ImagePolicy
metadata:
name: element
spec:
imageRepositoryRef:
name: element
policy:
semver:
range: "*"
---
## Une configuration de mise à jour qui détermine comment envoyer
## les commits
apiVersion: image.toolkit.fluxcd.io/v1beta1
kind: ImageUpdateAutomation
metadata:
name: element
spec:
interval: 10m0s
sourceRef:
kind: GitRepository
name: cluster
git:
commit:
author:
name: Kity
email: kity@tedomum.net
update:
path: .
strategy: Setters
Dans le code, n’importe quelle valeur peut être remplacée dynamiquement en indiquant le bon commentaire sur la ligne :
tag: v1.11.25 # {"$imagepolicy": "kube-ops:element:tag"}
Attention, la configuration de la ImagePolicy
est cruciale. Aujourd’hui notre politique
de tags Git indique d’employer les tags upstream en semver (v1.2.3
par exemple), suffixé
de +tedomum
(v1.2.3+tedomum
) par exemple. Pour ces images, la politique semver
proposée
en exemple fonctionne.
Réparer un déploiement en erreur
Pour identifier un déploiement en erreur, commencer par lister les HelmRelease
:
$ k get hr -A
NAMESPACE NAME AGE READY STATUS
tedomum-runner runner 6d17h True Release reconciliation succeeded
kube-monitoring prometheus 472d True Release reconciliation succeeded
kube-monitoring tempo 2d15h True Release reconciliation succeeded
tedomum-conference-beta jitsi-beta 130m False install retries exhausted
tedomum-chat element 519d False upgrade retries exhausted
Ici, les retries exhausted
indiquent des erreurs de déploiement : Flux tente de déployer une
HelmRelease
, attend que les services retournent un statut ok et la valide dans ce cas, sinon il
indique une erreur, et revient à la version précédente fonctionnelle dans le cas d’une mise à jour
(très pratique !) Il essaye plusieurs fois puis abandonne et ignore tout nouveau changement sur
l’objet.
La difficulté : comme il abandonne, voire rollback, le cluster ne contient plus les ressources en erreur, donc pas les logs d’erreur etc. Commencer par forcer à nouveau une mise à jour en réinitialisant l’état :
## Met l'objet en suspens (ne désinstalle pas), hr=HelmRelease
flux -n tedomum-chat suspend hr element
## Réactive l'objet en réinitialisant ses compteurs
flux -n tedomum-chat resume hr element
Observer le déploiement, les erreurs éventuelles, et corriger en conséquence. Afficher les détails
de l’objet HelmRelease
pour avoir les erreurs liés au helm
directement, et les logs des pods
pour les erreurs de fonctionnement.
Dans le cas où le déploiement échoue en indiquant another operation is in progress, cela signifie
que l’état du déploiement Helm, stocké dans des objets Secret
sur le cluster, est invalide, resté
en cours, par exemple parce que Flux a planté pendant un déploiement. Dans ce cas, descendre en
abstraction et manipuler Helm directement, en listant d’abord les déploiements passés pour l’objet :
helm -n tedomum-chat history element
Si une release est notée en cours mais manifestement plus en cours, noter le numéro de la dernière release fonctionnelle, puis rollback explicitement dessus :
helm -n tedomum-chat rollback element 1234
Dans le cas où le déploiement Helm semble définitivement perdu (des objets dans le cluster plus
gérés correctement par la HelmRelease
, aucun état remonté, etc.) et si la release n’est associée
à aucune donnée critique autre que les bases et objets stockés par ailleurs dans le cluster, supprimer
l’objet puis forcer une resynchro de la Kustomization
du cluster (attention ceci désinstalle le
déploiement) :
k -n tedomum-chat delete hr element
flux -n kube-ops reconcile kustomization cluster
En tout dernier recours, notamment si la HelmRelease
reste en état Terminating
après un delete
,
forcer la suppression en utilisant Helm directement :
helm -n tedomum-chat uninstall element