Unsere Anwendungen sind wie folgt organisiert:
- Ein einzelner „Kern“-Satz von Diensten, der von einem
coreHelm-Diagramm bereitgestellt wird - Mehrere einzelne Anwendungen, die über eigene Helm-Charts bereitgestellt werden
- Nennen wir sie A, B und C
Die normale Installationsreihenfolge ist also:
helm install core
helm install A... gefolgt von B und C, aber es ist möglich, dass Sie bei einer bestimmten Installation nicht das gesamte Alphabet haben.
Ich habe eine vom coreDiagramm bereitgestellte gemeinsam genutzte Komponente und möchte, dass jedes der App-Diagramme A, B und C eine Konfiguration zu dieser Komponente beitragen kann.
Ich weiß, dass ich eine Annotation für Kubernetes angeben configMapund die Kernkomponente veranlassen könnte, eine Kubernetes-Überwachung einzurichten oder regelmäßig nach neuen ConfigMaps zu suchen, aber ich möchte in diese Komponente lieber kein Kubernetes-Wissen einbauen müssen.
Wenn die Konfiguration eine einzelne ConfigMap wäre, könnte ich sie als Datei/Dateiverzeichnis in das Pod der Kernkomponente einbinden und das wäre in Ordnung. Es kann jedoch keine einzelne ConfigMap sein, da mehrere Diagramme (A, B und C) optional dazu beitragen müssen.
Gibt es eine Möglichkeit, dieses Muster zu erreichen, ohne dass die Kernkomponente Kubernetes-APIs aufruft, um ihre Konfiguration nachzuschlagen?