Verwenden von dynamischen Werten in Kubernetes-Manifesten

Question

Ich habe zwei separate Kubernetes-Cluster, die für eine Staging- bzw. eine Produktionsumgebung verwendet werden. Ich möchte YAML-Manifeste für die Kubernetes-API-Objekte haben, die ich an jeden Cluster senden werde, aber einige der Objekte werden leicht unterschiedliche Konfigurationen zwischen den beiden Umgebungen haben.

Stellen Sie sich vor, Sie führen ein internes Docker-Registry auf jedem Cluster aus, wobei S3 als Speicher-Back-End und One das GCS-Back-End verwenden. Der Registrierungscontainer kann diese Konfigurationswerte als Umgebungsvariablen akzeptieren oder aus einer Datei lesen, die beide von Kubernetes unterstützt werden. Wie aber sollte ich diese Werte für jede Umgebung angeben?

Im Wesentlichen will, was ich ist ein Weg, ein Manifest zu haben, die etwa wie folgt aussieht, wo die $() Syntax Variable Interpolation ist, die auf dem Server passieren würden, wenn das Manifest vorgelegt wird:

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

Ich könnte schreiben Vorlagen, die Platzhalter für die Werte verwenden und dann die Vorlage verarbeiten, wobei echte Werte aus einer externen Quelle abgerufen werden, um das endgültige Manifest zu erstellen, das tatsächlich an den Cluster gesendet wird. Allerdings dachte ich, ich würde zuerst fragen, für den Fall, dass ein Werkzeug, das das schon tut, existiert, oder es gibt eine Kubernetes-gesegnete Art, dies zu tun, was mir nicht bewusst ist. Es scheint sicherlich etwas zu sein, was viele Leute tun müssen, um Kubernetes zu benutzen.

Andere Ideen, die ich hatte, mit einer Kombination von etcd, confd und Skripten auf den Host-Knoten, aber dies beginnt in das Reich der Host-Konfigurations-Management, die ich zu fast allen Kosten vermeiden möchte. Ich benutze CoreOS und die Hosts werden komplett über coreos-cloudinit bereitgestellt. Mit anderen Worten, auf dem Hostsystem, das zum Zeitpunkt der Erstellung des Knotens nicht definiert ist, wird nichts manipuliert, so dass herkömmliche Konfigurationsverwaltungstools wie Ansible nicht verfügbar sind.

Ich kenne Kubernetes Geheimnis-System, aber einige dieser Variablenwerte könnten ziemlich groß sein, und die meisten von ihnen sind keine Geheimnisse.

Answer 1

Sie können das jetzt nicht wirklich tun. Die Frage zu folgen, wenn Sie in Templating interessiert ist https://github.com/kubernetes/kubernetes/issues/11492

Auch dies ist derzeit ein heißes Thema in der Konfiguration SIG https://groups.google.com/forum/#!forum/kubernetes-sig-config

Ich würde vorschlagen, Sie Ihr Interesse an der Funktion in einem Register von diesen Orten.

Answer 2

Dies kann für Sie arbeiten: ktmpl ist ein Werkzeug für die Verarbeitung von Kubernetes Manifest Vorlagen. Es ist eine sehr einfache clientseitige Implementierung des Templates + Parameterization proposal.

https://github.com/InQuicker/ktmpl

Answer 3

ansible arbeitet wirklich gut für uns aus. sehr einfach zu schablonieren und yaml-dateien zu generieren, aber es gibt auch ein modul zum direkt generieren von ressourcen http://docs.ansible.com/ansible/kubernetes_module.html