Managed Kubernetes, Helm i Argo CD pełnią różne role. Managed Kubernetes zapewnia platformę do uruchamiania klastra, Helm służy do pakowania i wdrażania aplikacji, a Argo CD automatyzuje dostarczanie zmian zgodnie z podejściem GitOps. Porównując te rozwiązania, uwzględnij potrzeby zespołu, model GitOps oraz zakres wymaganej kontroli. Wybór zależy głównie od wielkości zespołu i tego, ile pracy operacyjnej chcecie wykonywać samodzielnie.
Spis treści
Najpierw rozdziel platformę od narzędzi
Kubernetes jest platformą, na której działają kontenery i aplikacje. Managed Kubernetes to usługa, w której dostawca zapewnia zarządzaną warstwę klastra. Zespół korzysta z Kubernetes bez budowania całej platformy od podstaw i bez przejmowania wszystkich zadań związanych z jej utrzymaniem. Przewodniki dotyczące platform Kubernetes opisują ten wybór jako decyzję o sposobie uruchamiania i zarządzania samą platformą CIOPages: Kubernetes Platforms.
Helm i Argo CD nie są zamiennikami managed Kubernetes. Są narzędziami używanymi na działającym klastrze. Helm porządkuje sposób pakowania aplikacji Kubernetes i pozwala opisywać ich wdrożenia jako powtarzalne pakiety. Argo CD koncentruje się na ciągłym dostarczaniu aplikacji z repozytorium Git, zgodnie z modelem GitOps Helm: What It Can Do and Where Is It Going? CIOPages: GitOps & Continuous Delivery.
Kiedy wybrać managed Kubernetes?
Managed Kubernetes pasuje do zespołu, który chce korzystać z Kubernetes, ale nie chce samodzielnie budować całej warstwy platformowej. Najważniejszą korzyścią operacyjną jest przesunięcie części obowiązków związanych z klastrem na dostawcę usługi. Zespół nadal odpowiada za aplikacje, ich konfigurację i proces wdrażania, ale nie musi zaczynać od samodzielnego tworzenia platformy.
To rozwiązanie warto rozważyć, gdy:
- zespół ma skupić się na aplikacjach, a nie na budowie platformy Kubernetes,
- potrzebny jest Kubernetes bez pełnego zakresu prac związanych z jego samodzielnym utrzymaniem,
- firma dopiero rozwija kompetencje platformowe i chce ograniczyć początkową złożoność.
Managed Kubernetes nie zastępuje narzędzi do pakowania ani dostarczania aplikacji. Po wyborze usługi nadal trzeba ustalić, jak aplikacje będą opisywane, wdrażane i aktualizowane.
Kiedy użyć Helm?
Helm jest właściwym wyborem, gdy głównym problemem jest uporządkowanie konfiguracji aplikacji Kubernetes. Zamiast utrzymywać wiele podobnych zestawów manifestów, zespół może używać pakietów Helm i dostosowywać je do środowiska. Zakres Helma dotyczy pakowania oraz wdrażania aplikacji, a nie zapewniania całego klastra.
Helm sprawdzi się jako pierwszy krok, gdy:
- aplikacja ma być wdrażana w kilku środowiskach,
- konfiguracja powinna być przechowywana i zmieniana w uporządkowany sposób,
- zespół potrzebuje standardu pakowania aplikacji Kubernetes, ale nie chce jeszcze wdrażać pełnego procesu GitOps.
Helm sam w sobie nie jest platformą Kubernetes ani kompletnym systemem ciągłego dostarczania. Może być jednak używany razem z narzędziem GitOps.
Kiedy dodać Argo CD?
Argo CD ma sens wtedy, gdy repozytorium Git ma być źródłem deklarowanej konfiguracji aplikacji, a wdrożenia mają być stale porównywane z tym stanem. Jest to wybór dla zespołów, które chcą wprowadzić GitOps i ciągłe dostarczanie do środowiska Kubernetes. GitOps i continuous delivery są opisywane jako osobny obszar narzędziowy względem samej platformy Kubernetes CIOPages: GitOps & Continuous Delivery.
Argo CD można połączyć z Helm. Helm odpowiada wtedy za opis i pakowanie aplikacji, a Argo CD za obserwowanie konfiguracji w Git oraz dostarczanie jej do klastra. Argo CD nie zastępuje managed Kubernetes, ponieważ nie zapewnia samej platformy klastra. Porównania narzędzi GitOps, w tym Argo CD i Flux CD, pokazują, że ich wybór dotyczy sposobu realizacji GitOps, a nie wyboru między narzędziem wdrożeniowym a platformą Kubernetes Argo CD vs Flux CD.
Porównanie odpowiedzialności i złożoności
| Element | Managed Kubernetes | Helm | Argo CD |
|---|---|---|---|
| Główna rola | Zapewnienie platformy klastra | Pakowanie i konfiguracja aplikacji | Ciągłe dostarczanie w modelu GitOps |
| Obsługa klastra | Część pracy przejmuje dostawca | Poza zakresem narzędzia | Poza zakresem narzędzia |
| GitOps | Nie jest główną funkcją | Może dostarczać pakiety dla GitOps | Jest głównym zastosowaniem |
| Wymagane kompetencje | Podstawy Kubernetes i obsługi usługi | Kubernetes oraz organizacja konfiguracji | Kubernetes, GitOps i zarządzanie procesem dostarczania |
Praktyczne zestawy dla zespołów
Mały zespół
Najbardziej proporcjonalnym wyborem jest zwykle managed Kubernetes oraz Helm. Taki zestaw oddziela utrzymanie platformy od pakowania aplikacji, bez dokładania pełnego procesu GitOps na początku. Argo CD warto dodać dopiero wtedy, gdy ręczne wdrożenia i kontrola zmian w wielu środowiskach stają się istotnym problemem.
Rosnąca firma
Praktyczny zestaw to managed Kubernetes, Helm i Argo CD. Dostawca ogranicza zakres pracy przy platformie, Helm porządkuje aplikacje, a Argo CD wprowadza powtarzalny proces dostarczania z Git. Zespół powinien wcześniej ustalić, które repozytorium zawiera konfigurację oraz kto odpowiada za jej zatwierdzanie.
Duża platforma
Duża organizacja może potrzebować wszystkich trzech elementów, ale także wyraźnego podziału odpowiedzialności. Managed Kubernetes stanowi bazę, Helm ujednolica sposób opisywania aplikacji, a Argo CD obsługuje dostarczanie zgodne z GitOps. W tym modelu kompetencje platformowe, bezpieczeństwo konfiguracji i proces zmian powinny być przypisane do konkretnych zespołów.
Jak podjąć decyzję
- Ustal, czy potrzebujesz platformy Kubernetes, czy tylko sposobu pakowania aplikacji.
- Jeśli chcesz ograniczyć pracę przy infrastrukturze klastra, zacznij od managed Kubernetes.
- Jeśli problemem jest powtarzalna konfiguracja aplikacji, dodaj Helm.
- Jeśli Git ma być źródłem stanu aplikacji i chcesz wdrożyć GitOps, dodaj Argo CD.
- Przed wdrożeniem ustal odpowiedzialność za aktualizacje platformy, konfigurację aplikacji i proces dostarczania.
Najczęściej nie wybiera się jednego narzędzia zamiast pozostałych. Managed Kubernetes, Helm i Argo CD tworzą różne warstwy stosu. Wybór powinien odpowiadać temu, czy największym wyzwaniem jest utrzymanie klastra, porządek w konfiguracji aplikacji czy automatyzacja dostarczania zmian.