Meilleures pratiques pour stocker la configuration de Kubernetes dans le contrôle de code source
À plusieurs endroits sur le site de documentation de Kubernetes, ils vous recommandent de stocker vos fichiers YAML de configuration dans le contrôle de code source pour un suivi de version, une restauration et un déploiement faciles.
Mes collègues et moi sommes actuellement en train d'essayer de décider de la structure de notre référentiel git.
- Nous avons décidé que, puisque la configuration peut changer sans aucune modification du code de l'application, nous aimerions stocker les configurations dans un référentiel partagé séparé.
- Nous pouvons avoir besoin de plusieurs versions de certains composants fonctionnant côte à côte dans un environnement donné (cluster). Ces versions peuvent avoir des configurations différentes.
Il semble y avoir beaucoup de variations potentielles, et toutes ont des lacunes. Quelle est la manière acceptée de structurer un tel référentiel?
Il n'y a pas encore de norme établie, je crois. Je trouve les graphiques de Helm trop compliqués pour commencer, en particulier avec un autre composant non géré exécuté sur le cluster k8s. Il s'agit d'un flux de travail que nous suivons qui fonctionne assez bien pour une configuration de 15 microservices et 5 environnements différents (devx2, staging, qa, prod).
Les 2 idées clés:
- Stockez les configurations de kubernetes dans le même référentiel source que celui qui possède les autres outils de génération. Par exemple: à côté du code source du microservice qui a l'outillage pour construire/publier ce microservice particulier.
- Mettez en forme la configuration de kubernetes avec quelque chose comme jinja et affichez les modèles en fonction de l'environnement que vous ciblez.
L'outillage est assez simple à comprendre en assemblant quelques scripts bash ou en s'intégrant à un Makefile, etc.
EDIT: pour répondre à certaines des questions dans le commentaire
Le référentiel de code source de l'application est utilisé comme source unique de vérité. Cela signifie donc que si tout fonctionne comme il se doit, les modifications ne doivent jamais être déplacées du cluster kubernetes vers le référentiel.
Les modifications directement sur le serveur sont interdites dans notre workflow. Si cela se produit, nous devons nous assurer manuellement qu'ils pénètrent à nouveau dans le référentiel d'applications.
Encore une fois, je veux juste noter que les configurations stockées dans le code source sont en fait des modèles et utilisent secretKeyRef assez généreusement. Cela signifie que certaines configurations proviennent de l'outillage CI au fur et à mesure qu'elles sont rendues et d'autres proviennent de secrets qui ne vivent que sur le cluster (comme les mots de passe de base de données, les jetons d'API, etc.).
À mon avis, Helm est de kubernetes comme Docker-compose est de docker
Il n'y a aucune raison de craindre la barre, car c'est la fonctionnalité la plus basique, tout ce qu'elle fait est similaire à kubectl apply -f templates.
Une fois familiarisé avec Helm, vous pouvez commencer à utiliser values.yaml et en ajoutant des valeurs dans vos modèles kubernetes pour une flexibilité maximale.
values.yaml
name: my-name
à l'intérieur de templates/deployment.yaml
name: {{ .Values.name }}
Mon approche consiste à créer un sous-répertoire helm dans chaque projet, de la même manière que j'inclus un fichier docker-compose.yml.
en plus de cela, vous pouvez également maintenir un référentiel de barre pour tous vos projets qui référencent des images pré-construites