Implementacja i aktualizacja narzędzi w klastrze Kubernetes to proces złożony, wymagający starannego przygotowania i ścisłego przestrzegania procedur. W niniejszym artykule przedstawiono kluczowe kroki oraz zalecenia dotyczące implementacji oraz aktualizacji dwóch istotnych komponentów w klastrze Kubernetes: Portworx oraz prometheus-stack. W pierwszej części artykułu omówiono aktualizację MetalLB oraz ArgoCD.

Przed rozpoczęciem implementacji Portworx w klastrze Kubernetes z wykorzystaniem ArgoCD, istnieje kilka kroków wstępnych, które warto przeprowadzić.

Aby skutecznie zarządzać Portworx za pomocą ArgoCD, zaleca się stworzenie osobnej aplikacji dedykowanej tej usłudze. W tym celu warto utworzyć strukturę plików zgodną ze ścieżką zadeklarowaną w konfiguracji aplikacji ArgoCD.

Podczas organizowania struktury plików dla Portworx, należy sprawdzić, czy ścieżka jest zgodna z tą zadeklarowaną w konfiguracji aplikacji ArgoCD. W powyższym przykładzie stworzono folder portworx, zawierający plik kustomization.yaml oraz strukturę dla ewentualnych overlay’ów. Plik portworx.yaml będzie zawierał specyficzne konfiguracje dla Portworx.

Jeśli Portworx wcześniej nie był zarządzany przez ArgoCD, konieczne jest odtworzenie aktualnego środowiska. Podobnie, jak w przypadku MetalLB, ten krok pozwoli nam utworzyć punkt przywracania. W przypadku istnienia wcześniejszej konfiguracji, wskazane jest przeprowadzenie niezbędnej czynności w celu przywrócenia środowiska.

W następnym kroku trzeba uruchomić proces synchronizacji aplikacji w ArgoCD, aby wprowadzić zmiany zdefiniowane w plikach konfiguracyjnych.

Jeśli proces wdrożenia oraz potencjalne wcześniejsze aktualizacje zostały poprawnie wykonane, manifest dla StorageCluster powinien być dostępny do pobrania z panelu Portworx. Poniżej znajdują się niezbędne czynności do wykonania manifestu oraz ewentualnej aktualizacji usługi.

W panelu Portworx, w zakładce „Install and Run”, warto skorzystać z opcji „Download”, dostępnej poprzez kliknięcie przycisku „Actions”.

Po pobraniu manifestu, trzeba upewnić się, czy wartość dla wpisu portworx.io/install-source ma zgodne wartości dla kluczy user= oraz c=, a następnie, czy wpis name: jest zbieżny z portworx.io/install-source c=

W przypadku różnic, zaleca się pobranie danych bezpośrednio z klastra i nadpisanie ich w manifeście. Gotowy manifest należy zapisać w pliku /portwrox/overlays/dev/storage-cluster.yml.

W przypadku aktualizacji usługi Portworx, wystarczy dokonać zmian w odpowiednich sekcjach manifestu.

Zmiana wersji Kubernetes (kbver=):

Weryfikacja wpisów (name:):

Weryfikacja sekcji (user=):

Po dokonaniu tych zmian, manifest usługi Portworx jest gotowy do zastosowania w klastrze Kubernetes. Trzeba pamiętać o sprawdzeniu poprawności konfiguracji i zastosowaniu zmian zgodnie z procedurami aktualizacyjnymi.

W panelu Portworx należy przejść do zakładki „Install and Run” i kontynuować klikając przycisk „Next” aż do ostatniego kroku. W sekcji „Portworx Operator” należy kliknąć na ikonę oka obok manifestu operatora, skopiować manifest Portworx Operatora, przejść do katalogu /portworx/base/ w projekcie i utworzyć plik portworx-operator.yml. Następnie należy wkleić skopiowany manifest Portworx Operatora do nowego pliku.

Po wykonaniu tych kroków, manifest Portworx Operatora będzie dostępny w lokalnym repozytorium, gotowy do użycia w konfiguracji klastra Kubernetes. Trzeba sprawdzić poprawności skopiowanego manifestu oraz zastosowaniu go zgodnie z wymaganiami aplikacji.

Aby uzyskać dostęp do manifestu StorageClass dla Portworx, należy uruchomić poniższą komendę w terminalu, aby otrzymać YAML manifestu StorageClass.

W wyniku tej operacji manifest zostanie wyświetlony w konsoli. Alternatywnie, można bezpośrednio zapisać manifest do pliku, wykonując komendę:

Ten krok zapisze manifest StorageClass do pliku o nazwie portworx-storageclass.yml.

Po wykonaniu tych kroków, będzie dostępny manifest StorageClass dla Portworx, który można edytować lub użyć w innych procesach konfiguracyjnych. Niezbędne jest monitorowanie i weryfikacja zawartości manifestu przed jego zastosowaniem.

Aby zaktualizować manifesty za pomocą panelu Portworx, należy zalogować się do platformy i wybrać aktualną specyfikację w zakładce „Install and Run”. Następnie sklonować ją, definiując nowe wersje dla Portworxa i klastra.

Konieczne jest zdefiniowane nowej wersji, zarówno Portworxa, jak i samego klastra. W dalszych krokach konieczne jest dostosowanie specyfikacji do naszych potrzeb.

Wynikiem końcowym jest znany widok, z którego można pobrać wszystkie potrzebne nam manifesty.

Po sklonowaniu, należy pobrać manifesty, a następnie umieścić manifest StorageCluster w dedykowanej ścieżce dla swojego środowiska, np. /portworx/overlays/dev/. Na ostatnim ekranie podsumowującym znajduje się informacja dotyczącą utworzenia obiektu typu Secret.

W przypadku posiadania odpowiedniego obiektu Secret, ponowne jego tworzenie nie jest konieczne. Dzięki tym krokom można zaktualizować manifesty Portworx, dostosowując je do bieżących potrzeb z zachowaniem spójność konfiguracji klastra Kubernetes.

W tym etapie niezapomniane jest również przeprowadzenie weryfikacji oraz ewentualne dostosowanie zmian. Dane te są kluczowe, a w przypadku potrzeby, należy pamiętać o ich podmianie. Dodatkowo, konieczne jest utworzenie i dodanie odpowiedniego obiektu Secret, o którym wcześniej wspomniano.

Aby to zrealizować, można skopiować obiekt Secret bezpośrednio z klastra za pomocą polecenia:

Następnie należy dodać skopiowane dane do pliku w dedykowanej ścieżce, na przykład /portworx/overlays/px-essential-secret.env. Warto pamiętać, aby nie umieszczać Secret w takiej formie w systemie kontroli wersji, takim jak GIT. To dotyczy wszystkich obiektów Secret, nie tylko tego konkretnego. Jeśli konieczne jest dodanie do repozytorium, zaleca się zaszyfrowanie go za pomocą klucza GPG.

Przed przystąpieniem do aktualizacji, konieczne jest przygotowanie plików kustomization.yml, które połączą wszystkie wcześniej utworzone manifesty. Każdy z folderów (/base/, /overlays/dev/, /overlays/prod) musi posiadać swój plik /portworx/base/kustomization.yml.

Folder /base/ nomen omen wykorzystywany jest jako baza. Manifesty zadeklarowane w kustomization.yml tego folderu są bazą dla manifestów z folderu /overlays/.

/portworx/overlays/kustomization.yml

Po wykonaniu tych operacji można porównać manifest z klastrem. Porównanie to możemy dokonać poprzez ArgoCD po wcześniejszym przesłaniu zmian do repozytorium GIT. Zaleca się unikanie opcji Sync i ograniczanie się do korzystania jedynie z opcji Refresh oraz App Diff.

Jeśli ArgoCD nie wykazuje błędów lub zmian, które wpływają na działanie klastra, możemy przystąpić do synchronizacji aplikacji ArgoCD. Zmiany możemy obserwować po stronie klastra za pomocą polecenia:

Po ustabilizowaniu się stanu klastra, aktualizacja została zakończona.

Aktualizacja prometheus-stack w klastrze może być jednym z bardziej czasochłonnych i wymagających procesów. Jest to głównie związane z kompleksowością samego prometheus-stack, który składa się z wielu komponentów, a także koniecznością jego odtworzenia poprzez ArgoCD od podstaw.

Mimo konieczności poświęcenia wielu godzin na wdrożenie prometheus-stack przez ArgoCD, jest to decyzja uzasadniona i wręcz niezbędna, szczególnie w kontekście długoterminowego rozwoju klastra oraz przyszłych aktualizacji.

Przed rozpoczęciem aktualizacji należy pamiętać o kilku kluczowych krokach. Można upewnić się, że stworzona aplikacja w ArgoCD nosi nazwę „monitoring”, a definicja tej aplikacji znajduje się w pliku monitoring.yml dostępnym w repozytorium.

Warto również zapewnić odpowiednią strukturę plików zgodną z wymaganiami dla klastra oraz upewnić się, że wszystkie niezbędne pliki i konfiguracje są dostępne przed przystąpieniem do aktualizacji. Dokładając staranności na etapie przygotowań, można zminimalizować trudności i zapewnić płynne przejście przez proces aktualizacji prometheus stack w klastrze.

W pierwszym etapie należy przygotować skrypt ułatwiający generację manifestu Prometheus-Stack, wykorzystując narzędzie Helm.

Przed generacją pierwszego manifestu warto zdefiniować wersję, która obecnie jest używana w klastrze. Dzięki temu otrzymuje się „czysty” manifest dla aktualnej wersji. Ze względu na złożoność i rozmiar prometheus-stack, korzystne (a czasem nawet konieczne) jest wykorzystanie pliku values.yml.

Poniżej znajduje się polecenie Helm, które generuje manifest, biorąc pod uwagę wartości z pliku values.yml oraz wersję docelową ({{target-version}}):

Przed generacją warto zapoznać się z dokumentacją pliku values.yml. Plik ten pozwoli dostosować manifest do specyfiki klastra i działających na nim usług, poprzez predefiniowanie części zmiennych.

Dzięki temu proces generowania manifestu staje się bardziej elastyczny i dostosowany do indywidualnych potrzeb oraz specyfiki konkretnego klastra.

Z uwagi na duży rozmiar manifestu prometheus-stack, efektywnym podejściem jest lokalne porównywanie zmian. Realizacja tego zadania po stronie ArgoCD staje się trudna z powodu ilości danych, które trzeba przetworzyć i wyświetlić w przeglądarce.

W przypadku klastra, należy postępować inaczej, wykonując lokalne porównywanie zmian. Jednak wcześniej warto utworzyć punkt odzyskiwania, do którego porównamy nowo utworzone manifesty. Obejmuje to manualne przygotowanie lub pobranie manifestu prometheus-stack z klastra.

Zadanie to warto przygotować od surowego manifestu dla aktualnej wersji na klastrze. Warto wykorzystać wcześniej przygotowany skrypt lub polecenie do generacji template. Jednakże, trzeba wykonać to polecenie z opcją –include-crds=false, co znacznie zmniejszy rozmiar pliku.

Teraz można przejść do dalszych kroków przygotowania punktu odzyskiwania i lokalnego porównywania zmian w manifestach dla prometheus-stack.

Przygotowanie surowego manifestu dla aktualnej wersji dostępnej na klastrze może być zrealizowane za pomocą wcześniej przygotowanego skryptu lub polecenia do generacji template. Jednak wskazane jest wykonać to polecenie z opcją –include-crds=false, co znacząco zmniejszy rozmiar pliku.

Gdy jest dostępny surowy manifest, warto przystąpić do tworzenia backupu. Zadanie to polega na stworzeniu pliku zawierającego te same obiekty, co surowy manifest. Innymi słowy, należy utworzyć kopię surowego manifestu, pobierając obiekty bezpośrednio z klastra.

Surowy manifest może zawierać różne obiekty, na przykład Service, który może wyglądać następująco:

Stworzenie backupu polega na skopiowaniu obiektów tego typu z klastra i zapisaniu ich w pliku, który będzie stanowił punkt odzyskiwania w przypadku potrzeby przywrócenia konkretnych konfiguracji.

Wskazane jest pobranie manifestu obiektu Service o nazwie monitoring-kube-prometheus-kube-controller-manager z klastra za pomocą polecenia:

Zaznaczone sekcje można sukcesywnie usuwać. Będą jedynie przeszkadzać w procesie porównywania plików.

Należy powtórzyć tę czynność dla każdego obiektu w surowym manifeście, zgodnie z ich kolejnością. Każdy obiekt z manifestu powinien być skopiowany z klastra i zapisany w odpowiednim pliku, tworząc tym samym punkt odzyskiwania dla konkretnych konfiguracji.

Po skopiowaniu wszystkich obiektów, trzeba przystąpić do całościowego porównania plików. Przydatnym rozwiązaniem ułatwiającym pracę jest porównywanie obiektów natychmiast po ich zapisaniu do pliku prometheus-stack-old.yml. Dzięki temu jest możliwość dokonywania zmian i poprawek w pliku values.yaml na bieżąco.

Podobnie, jak w przypadku poprzednich aplikacji, ten krok jest konieczny tylko wtedy, gdy prometheus-stack nie jest dostępny po stronie ArgoCD. W takiej sytuacji konieczne jest przyrównanie aplikacji do obecnego stanu w klastrze.

Niestety, nie wszystkie zmienne można zdefiniować w opisywanym wcześniej pliku values.yaml. Część ustawień nie znajduje tam swojego odpowiednika, co może wymagać alternatywnego podejścia do ich zdefiniowania.

W tej sytuacji sięgamy po narzędzie kustomize, które pozwala na elastyczne dodawanie dodatkowych konfiguracji, a nawet całych manifestów.

Plik kustomization.yml jest definiowany w następujący sposób:

Mechanizm patchesStrategicMerge pozwala elastycznie nadpisywać tylko te zmienne lub konfiguracje, które są interesujące, pozostawiając resztę nienaruszoną. Dzięki temu są aktualizowane wcześniejsze wpisy, zamiast całkowicie je zastępować.

Wpis w surowym manifeście:

Zawartość patch.yml.

Wynik kustomize build.

Dodatkowo, konieczne jest dodanie obiektu typu Secret. Zadanie to należy zrealizować podobnie jak w przypadku „Portworx Secret”.

Proces aktualizacji przebiega analogicznie, jak do poprzednich usług. Aby zaktualizować, należy wygenerować manifest dla najnowszej wersji, uwzględniając pliki values.yml, patch.yml oraz secrets.yml.

Polecenie do wygenerowania manifestu prezentuje się następująco:

W trakcie generowania manifestu dla nowej wersji, ważne jest zmienienie przełącznika –include-crds na true oraz rozdzielenie manifestów, zgodnie z dotychczasową praktyką.

Następnie przystąpiono do porównania zmian za pomocą narzędzia App Diff w ArgoCD. To pozwala na wyłapanie nawet drobnych zmian, które mogły zostać pominięte wcześniej. Po zakończeniu tego procesu i upewnieniu się, że nie ma kluczowych różnic ani błędów, należy przystąpić do synchronizacji aplikacji w ArgoCD.

Jeśli App Diff nie wykrywa istotnych różnic, można bezpiecznie kontynuować i rozpocząć synchronizację aplikacji, zapewniając spójność i zgodność konfiguracji z oczekiwaniami i wymaganiami dotyczącymi klastra.

To był drugi fragment wpisu dotyczącego aktualizacji klastra Kubernetes do wersji 1.26. W tej części zostały omówione procesy aktualizacji usług Portworx oraz Prometheus Stack. W następnym wpisie przedstawimy kroki związane z aktualizacją usług Blackbox Exporter oraz samego Kubernetesa.