W niniejszym artykule omówimy kluczowe kroki oraz zalecenia dotyczące implementacji oraz aktualizacji komponentu w klastrze Blackbox Exporter oraz aktualizację właściwego Kubernetesa. W pierwszej oraz drugiej części artykułu zostały omówione MetalLB, ArgoCD, Portworx oraz prometheus-stack.

W przypadku klastra, podniesienie wersji Blackbox Exporter okazało się niezbędne dla zachowania stabilności i efektywności usług monitorujących. Proces aktualizacji Blackbox Exportera nie różni się znacząco od standardowej procedury aktualizacji aplikacji, jednak istotną różnicą jest fakt, że nie było konieczności budowy osobnej aplikacji w celu implementacji zmian.

W kontekście architektury monitoringu, Blackbox Exporter pełni kluczową rolę, umożliwiając zbieranie i analizę danych dotyczących stanu oraz dostępności usług. Z tego powodu warto skorzystać z istniejącej aplikacji do monitoringu, która została zaprojektowana i dostosowana do potrzeb aktualizacji całego wachlarza narzędzi monitorujących, w tym również prometheus-stack.

Dzięki wykorzystaniu aplikacji do monitoringu, która została już skonfigurowana i zoptymalizowana pod kątem wymagań, proces aktualizacji Blackbox Exportera mógł być przeprowadzony sprawnie i zminimalizowano ryzyko wystąpienia ewentualnych komplikacji czy niezgodności w środowisku monitorującym. W ten sposób zapewniono ciągłość działania monitoringu oraz wysoką jakość usług dostarczanych przez klaster.

W celu przygotowania manifestu dla aktualizacji Blackbox Exportera, warto oprzeć się na pliku values.yaml oraz wykorzystaniu narzędzia Helm.

Aby wygenerować gotowy, pełny manifest, należy zastosować polecenie:

W powyższym poleceniu {{target-version}} odnosi się do aktualnej wersji Blackbox Exportera na klastrze, korzystając z pliku values-blackbox.yml.

Dzięki tej operacji, zgodnie z wymaganiami, osiągnięto gotowość do wdrożenia manifestu, który uwzględnia specyfikacje środowiska monitorującego i zapewnia zgodność z wymaganiami klastra.

Podobnie, jak w poprzednich przypadkach, konieczne jest dokładne dostosowanie pliku do wymagań i konfiguracji klastra. W celu identyfikacji niezbędnych zmian, ponownie warto skorzystać z narzędzia AppDiff dostępnego w ArgoCD, które umożliwia porównanie różnic między repozytorium a aktualnym stanem klastra.

Celem jest porównanie manifestu ArgoCD z rzeczywistym stanem klastra, aby upewnić się, że konfiguracje są zgodne. Procedura ta nie różni się znacząco od wcześniejszych działań.

Po zidentyfikowaniu różnic i wprowadzeniu niezbędnych zmian, nowo utworzony manifest należy dodać do pliku /prometheus-stack/base/kustomization.yml.

Ostateczna struktura pliku w folderze głównym prezentuje się następująco:

Po przeprowadzeniu porównania repozytorium z aktualnym stanem środowiska, możemy przystąpić do synchronizacji aplikacji za pośrednictwem ArgoCD. Dzięki temu uzyskano punkt odzyskiwania oraz zapewniono spójność i zgodność konfiguracji aplikacji z wymaganiami i oczekiwaniami dotyczącymi klastra.

Po zaktualizowaniu wszystkich komponentów, należy przystąpić do aktualizacji Kubernetesa. Pierwszym krokiem jest aktualizacja węzłów kontrolnych.

Aby przeprowadzić aktualizację, najpierw należy ustalić odpowiednią wersję, którą chcemy zainstalować. Następnie, po wybraniu odpowiedniej wersji, można zainstalować ją poprzez:

Po zainstalowaniu odpowiedniej wersji narzędzia kubeadm, należy przygotować plan aktualizacji poprzez wykonanie:

Następnie, trzeba wykonać aktualizację klastra Kubernetesa poprzez:

Po aktualizacji narzędzia kubeadm, trzeba zaktualizować również kubelet oraz kubectl. Przed aktualizacją warto wyciągnąć ich blokadę, a po aktualizacji – ponownie ją nałożyć. Procedurę uaktualnienia kubelet i kubectl można przeprowadzić za pomocą następujących kroków.

Po wyznaczeniu węzła do aktualizacji, najpierw wyeliminowano go z zadań i zapewniono poprawność informacji.

Następnie zaktualizowano kubelet oraz kubectl.

Po zainstalowaniu nowych wersji, trzeba zrestartować usługę kubelet:

Na koniec, warto upewnić się, że węzeł został ponownie udostępniony do pracy poprzez wykonanie poniższego polecenia. Dodatkowo trzeba uzyskać zapewnienie, że <node-to-drain> to nazwa węzła, który został wcześniej zaktualizowany.

Aktualizacja węzłów roboczych odbywa się za pomocą playbooka Ansible, który został podzielony na dwa osobne pliki:

Należy pamiętać, że operacje należy wykonywać pojedynczo, węzeł po węźle, aby uniknąć przerw w dostępności usług.

Ten artkuł kończy serię trzech artykułów na temat migracji Kubernetesa z wersji 1.25 do wersji 1.26. Zachęcamy do zapoznania się z częścią pierwszą oraz drugą. W tej części poruszaliśmy aktualizację komponentów Blackbox Exporter oraz samego Kubernetesa, a w pozostałych aktualizację pisaliśmy o MetalLB, ArgoCD, Portworx oraz prometheus-stack.

W najnowszej wersji klastra Kubernetes, dokonano przejścia z mechanizmu PodSecurityPolicy (PSP) na bardziej elastyczną i nowoczesną metodę, zwaną Pod Security Admission (PSA). To istotna zmiana, która wymaga starannego przygotowania i ścisłego przestrzegania procedur podczas implementacji i aktualizacji narzędzi w klastrze. Artykuł omawiał kluczowe kroki przed aktualizacją klastra, skupiając się na usługach, które wcześniej korzystały z PSP.

Podsumowując, artykuł stanowi kompleksowe omówienie kluczowych aspektów związanych z aktualizacją klastra Kubernetes, podkreślając konieczność uwzględnienia zmian w mechanizmie zabezpieczeń oraz przestrzegania procedur aktualizacji dla każdego z komponentów klastra. Należy zapoznać się z poprzednimi częściami serii w celu pełnego zrozumienia procesu migracji i uniknięcia potencjalnych problemów podczas aktualizacji.