Utiliser kubernetes

Ressoures générales

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