När du installerar ett diagram med hjälp av Helm förväntar det sig vanligtvis varje release att ha sin egen fristående uppsättning Kubernetes-objekt. I det grundläggande exemplet du visar skulle jag förvänta mig att se Kubernetes Service-objekt som heter något liknande
release-a-application-a
release-a-redis
release-b-application-b
release-b-redis
Det finns en allmän konvention att objekt namnges som börjar med {{ .Release.Name }} , så de två Redises är separata.
Detta är faktiskt en förväntad installation. En typisk regel för att bygga mikrotjänster är att varje tjänst innehåller sin egen isolerade lagring, och att tjänster aldrig delar lagring med varandra. Det här rodermönstret stöder det, och det finns egentligen ingen nackdel med att ha den här inställningen.
Om du verkligen vill att de två diagrammen ska dela en enda Redis-installation kan du skriva ett "paraply"-diagram som inte gör något på egen hand utan beror på de två applikationsdiagrammen. Diagrammet skulle ha en Chart.yaml fil och (i Helm 2) en requirements.yaml fil som refererar till de två andra diagrammen, men inte en templates sin egen katalog. Det skulle få Helm att dra slutsatsen att en enda Redis kunde stödja båda applikationerna, och du skulle sluta med något liknande
umbrella-application-a
umbrella-application-b
umbrella-redis
(Min erfarenhet är att du vanligtvis inte vill ha detta – du gör vill ha en separat Redis per applikation – och så att försöka hantera flera installationer med hjälp av ett paraplydiagram fungerar inte särskilt bra.)