Ho due cluster Kubernetes separati che verranno utilizzati rispettivamente per un ambiente di produzione temporanea e un ambiente di produzione. Voglio avere manifesti YAML per gli oggetti API Kubernetes che invierò a ciascun cluster, ma alcuni degli oggetti avranno configurazioni leggermente diverse tra i due ambienti.Uso dei valori dinamici nei manifesti di Kubernetes
Come esempio completo ma illustrativo, immagina di eseguire un registro Docker interno su ciascun cluster, uno che utilizza S3 come back-end di archiviazione e uno che utilizza il back-end GCS. Il contenitore del registro può accettare questi valori di configurazione come variabili di ambiente o leggere da un file, entrambi i quali manifesta il supporto di Kubernetes, ma come dovrei popolare questi valori per ciascun ambiente?
Essenzialmente quello che voglio è un modo per avere un manifesto che sembra qualcosa di simile, in cui la sintassi $() è l'interpolazione variabile che sarebbe accaduto sul server al momento della presentazione del manifesto:
---
apiVersion: v1
kind: Pod
metadata:
name: foo
spec:
containers:
- name: foo
image: foo
env:
- name: bar
value: $(etcdctl get /path/to/bar)
Potrei scrivere modelli che utilizzano segnaposti per i valori e quindi elaborano il modello, inserendo valori reali da una fonte esterna, per produrre il manifest finale che viene effettivamente inviato al cluster. Comunque, ho pensato di chiederlo per prima cosa nel caso in cui uno strumento che fa questo già esista, o ci sia qualche modo benedetto da Kubernetes per fare ciò di cui non sono a conoscenza. Sembra certamente qualcosa che molte persone dovranno fare per usare Kubernetes.
Altre idee che ho avuto includono l'utilizzo di una combinazione di etcd, confd e script sui nodi host, ma questo inizia ad entrare nel regno della gestione della configurazione dell'host che voglio evitare a tutti i costi. Sto usando CoreOS e gli host sono forniti interamente tramite coreos-cloudinit. In altre parole, nulla viene manipolato sul sistema host che non è definito al momento della creazione del nodo, quindi i tradizionali strumenti di gestione della configurazione come Ansible sono fuori.
Sono a conoscenza del sistema dei segreti di Kubernetes, ma alcuni di questi valori variabili potrebbero essere piuttosto grandi e molti di loro non sono segreti.
Sono l'autore di questo! ;) –
Bene, allora ti consiglio seriamente di provarlo. Haha! – eosrei