Wenn Sie ein Diagramm mit Helm installieren, erwartet es im Allgemeinen jede Version einen eigenen, in sich geschlossenen Satz von Kubernetes-Objekten zu haben. In dem einfachen Beispiel, das Sie zeigen, würde ich Kubernetes Service-Objekte mit dem Namen „
“ erwartenrelease-a-application-a
release-a-redis
release-b-application-b
release-b-redis
Es gibt eine allgemeine Konvention, dass Objekte mit {{ .Release.Name }} benannt werden , also sind die beiden Redises getrennt.
Dies ist eigentlich ein erwartetes Setup. Eine typische Regel beim Erstellen von Microservices lautet, dass jeder Dienst seinen eigenen isolierten Speicher enthält und dass Dienste niemals Speicher gemeinsam nutzen. Dieses Helm-Muster unterstützt dies, und es gibt keinen wirklichen Nachteil bei diesem Setup.
Wenn Sie wirklich möchten, dass sich die beiden Diagramme eine einzige Redis-Installation teilen, können Sie ein „Umbrella“-Diagramm schreiben, das nichts von sich aus tut, sondern von den beiden Anwendungsdiagrammen abhängt. Das Diagramm hätte eine Chart.yaml Datei und (in Helm 2) eine requirements.yaml Datei, die auf die beiden anderen Diagramme verweist, aber nicht auf templates eigenes Verzeichnis. Das würde dazu führen, dass Helm zu dem Schluss kommt, dass ein einzelnes Redis beide Anwendungen unterstützen könnte, und Sie würden so etwas wie
umbrella-application-a
umbrella-application-b
umbrella-redis
(Meiner Erfahrung nach tun Sie das normalerweise nicht wollen dies – Sie tun ein separates Redis pro Anwendung haben möchten – und daher funktioniert der Versuch, mehrere Installationen mithilfe eines Umbrella-Diagramms zu verwalten, nicht besonders gut.)
