Utilisation de valeurs dynamiques dans les manifestes Kubernetes

Question

J'ai deux clusters Kubernetes distincts qui seront utilisés respectivement pour un environnement intermédiaire et un environnement de production. Je veux avoir des manifestes YAML pour les objets API Kubernetes que je soumettrai à chaque cluster, mais certains des objets auront des configurations légèrement différentes entre les deux environnements. A titre d'illustration, mais imaginatif, imaginez l'exécution d'un registre Docker interne sur chaque cluster, l'un utilisant S3 comme backend de stockage et l'autre utilisant le backend GCS. Le conteneur de registre peut accepter ces valeurs de configuration en tant que variables d'environnement ou lire à partir d'un fichier, les deux Kubernetes étant pris en charge, mais comment dois-je renseigner ces valeurs pour chaque environnement?

Essentiellement ce que je veux est un moyen d'avoir un manifeste qui ressemble à quelque chose comme ça, où la syntaxe $() est une interpolation variable qui se produirait sur le serveur lorsque le manifeste est soumis:

--- 
apiVersion: v1 
kind: Pod 
metadata: 
    name: foo 
spec: 
    containers: 
    - name: foo 
     image: foo 
     env: 
     - name: bar 
      value: $(etcdctl get /path/to/bar) 

Je pourrais écrire modèles qui utilisent des espaces réservés pour les valeurs, puis traitent le modèle, en extrayant des valeurs réelles à partir d'une source externe, pour produire le manifeste final qui est réellement soumis au cluster. Cependant, j'ai pensé que je demanderais d'abord au cas où un outil qui existe déjà existe, ou il y a une certaine façon de faire cela que je ne connais pas Kubernetes. Cela semble certainement être quelque chose que beaucoup de gens devront faire pour utiliser Kubernetes. D'autres idées que j'ai eues comprennent l'utilisation d'une combinaison de fichiers etcD, confd et scripts sur les nœuds hôtes, mais cela commence à entrer dans le domaine de la gestion de la configuration de l'hôte que je veux éviter à peu près tous les coûts. J'utilise CoreOS et les hôtes sont provisionnés entièrement via coreos-cloudinit. En d'autres termes, rien n'est manipulé sur le système hôte qui n'est pas défini au moment de la création du nœud, de sorte que les outils de gestion de configuration traditionnels comme Ansible sont sortis. Je connais le système de secrets de Kubernetes, mais certaines de ces valeurs peuvent être assez grandes et la plupart d'entre elles ne sont pas secrètes.

Answer 1

Vous ne pouvez pas vraiment faire cela maintenant. La question à suivre si vous êtes intéressé par templating est https://github.com/kubernetes/kubernetes/issues/11492

En outre, c'est actuellement un sujet de discussion dans la configuration SIG https://groups.google.com/forum/#!forum/kubernetes-sig-config

Je vous suggère de vous inscrire votre intérêt pour la fonction dans un de ces endroits.

Answer 2

Cela peut fonctionner pour vous: ktmpl est un outil pour le traitement des modèles de manifeste Kubernetes. C'est une implémentation côté client très simple du Templates + Parameterization proposal.

https://github.com/InQuicker/ktmpl

Answer 3

Ansible travaille pour nous vraiment bien. très facile à modéliser et à générer des fichiers yaml, mais il y a aussi un module pour générer des ressources directement http://docs.ansible.com/ansible/kubernetes_module.html