Kiedy instalujesz wykres za pomocą Helma, zazwyczaj oczekuje on każdego wydania mieć własny, niezależny zestaw obiektów Kubernetes. W podstawowym przykładzie, który pokazujesz, spodziewałbym się zobaczyć obiekty usługi Kubernetes o nazwie podobnej do
release-a-application-a
release-a-redis
release-b-application-b
release-b-redis
Istnieje ogólna konwencja, zgodnie z którą obiekty są nazywane zaczynając od {{ .Release.Name }} , więc te dwie wersje są oddzielne.
To jest właściwie oczekiwana konfiguracja. Typowa zasada budowania mikrousług polega na tym, że każda usługa zawiera własny wyizolowany magazyn, a usługi nigdy nie współużytkują magazynu. Ten wzorzec Helm to obsługuje, a ta konfiguracja nie ma żadnej wady.
Jeśli naprawdę chcesz, aby te dwa wykresy współdzieliły pojedynczą instalację Redis, możesz napisać wykres „parasolowy”, który sam niczego nie robi, ale zależy od dwóch wykresów aplikacji. Wykres miałby Chart.yaml plik i (w Helm 2) requirements.yaml plik, który odwołuje się do dwóch pozostałych wykresów, ale nie do templates własny katalog. To spowodowałoby, że Helm doszedłby do wniosku, że pojedynczy Redis może obsługiwać obie aplikacje, a ty masz coś takiego
umbrella-application-a
umbrella-application-b
umbrella-redis
(Z mojego doświadczenia wynika, że zwykle nie) tego chcesz – robisz chcesz osobnego Redisa dla każdej aplikacji – dlatego próba zarządzania wieloma instalacjami za pomocą wykresu parasolowego nie działa szczególnie dobrze.)
