logo

Przewodnik po aktualizacji klastra
Kubernetes – część 1

  1. Core Logic
  2. Baza wiedzy
  3. Artykuły
  4. Przewodnik po aktualizacji klastra Kubernetes – część 1

Każda ewolucja technologii przynosi ze sobą wyzwania, ale także nowe możliwości. W najnowszej wersji klastra Kubernetes, 1.25, odchodzi PodSecurityPolicy (PSP) na rzecz bardziej elastycznej i nowoczesnej metody, zwanej Pod Security Admission (PSA). W tym artykule omówiono kluczowe kroki, które należy podjąć przed aktualizacją klastra, skupiając się na usługach, które do tej pory korzystały z PSP.

Aktualizacja usług korzystających z PSP

1. Metallb – zarządzanie LoadBalancer

Metallb odgrywa kluczową rolę w zarządzaniu usługami LoadBalancer w klastrze. Przed migracją trzeba posiadać najnowszą wersję Metallb, zoptymalizowaną pod kątem współpracy z Pod Security Admission.

2. Portworx – zarządzanie storage

W przypadku korzystania z Portworx do zarządzania storage, należy posiadać najnowszą wersję, w pełni zgodną z nową polityką bezpieczeństwa.

3. Prometheus Stack – monitorowanie klastra

Jeśli używane są narzędzia z pakietu Prometheus do monitorowania klastra, trzeba zaktualizować prometheus-stack do najnowszej wersji, aby uniknąć problemów związanych z bezpieczeństwem.

4. Blackbox Exporter – monitorowanie zdalnych usług

Należy upewnić się, że blackbox-exporter, odpowiedzialny za monitorowanie zdalnych usług, jest zgodny z nowymi standardami bezpieczeństwa.

Listę koniecznych do aktualizacji zasobów można wyświetlić za pomocą polecania:

Gdzie:

  • px-operator = portworx,
  • speaker, controller = metallb,
  • monitoring  = prometheus,
  • blackbox-exporter = blackbox-exporter.

W tym artykule przeanalizowano aktualizację ArgoCD oraz Metallb.

Wykonanie pełnej kopii zapasowej klastra

Procedura backup jest analogiczna do procesu przygotowań do aktualizacji Kubernetes (k8s) do wersji 1.24.

Poniżej przedstawiono instrukcje dotyczące wykonywania kopii zapasowej klastra Kubernetes, obejmujące kopiowanie certyfikatów, manifestów oraz danych ETCD:

Aby zabezpieczyć certyfikaty oraz manifesty klastra Kubernetes, można skorzystać z narzędzia rsync:

Narzędzie rsync umożliwia skopiowanie folderów /etc/kubernetes/pki/ oraz /etc/kubernetes/manifests/ zachowując strukturę katalogów. Dodatkowo, można wykluczyć zbędne foldery, na przykład tmp.

Kopia ETCD

Przed wykonaniem kopii zapasowej ETCD, należy potwierdzić lokalizację certyfikatów oraz endpointu za pomocą polecenia:

Następnie można wykonać kopię zapasową ETCD, używając poniższego polecenia:

 

Powyższe polecenie tworzy kopię zapasową ETCD w pliku snapshot-pre-boot.db.

 

ArgoCD

ArgoCD to niezbędne narzędzie do bezpiecznej i kontrolowanej aktualizacji serwisów w klastrze Kubernetes. Dzięki ArgoCD istnieje możliwość wizualnej analizy różnic pomiędzy przygotowanym manifestem a obecnym stanem w środowisku. Jednak największą korzyścią jest elastyczna opcja szybkiego cofnięcia (rollback) do poprzedniej wersji, co czyni ArgoCD niezastąpionym narzędziem przy aktualizacji praktycznie każdego obiektu w klastrze.

Przygotowanie aplikacji w ArgoCD

W celu skonfigurowania aplikacji w ArgoCD, warto postępować deklaratywnie, opierając się na zdefiniowanym w repozytorium cloud-gitops zestawie manifestów. Choć panel ArgoCD umożliwia bezpośrednie tworzenie aplikacji, w artykule skupiono się na podejściu opartym na deklaracjach w repozytorium, co umożliwia spójne zarządzanie aplikacjami w różnych systemach.

Struktura manifestu aplikacji

Deklaracja aplikacji powinna być dostosowana do ogólnej struktury manifestu, co umożliwi łatwą adaptację do konkretnych usług. W przypadku tego opisu, przyjęto, że metodologia używana w niniejszym przypadku wykorzystuje repozytorium cloud-gitops.

Sama deklaracja opiera się na stworzeniu nowego pliku\manifestu w ścieżce.

Manifest powinien zawierać następujący wpis:

Tak wygląda przykładowa deklaracja dla Metallb prod:

Warto tworzyć nowe aplikacje na osobnych branchach w repozytorium kodu GIT. To podejście pozwala zachować bezpieczeństwo pozostałych elementów klastra, gdy wprowadzane są zmiany w danym projekcie. Każda aplikacja powinna mieć swoją dedykowaną przestrzeń roboczą, co ułatwia kontrolę i monitorowanie zmian. W przypadku wcześniej stworzonych aplikacji, które są już dostępne w klastrze, zaleca się wyłączenie funkcji automatycznej synchronizacji (Auto-Sync). Warto także upewnić się, że Auto-Sync jest wyłączone lub w razie potrzeby, wyłączyć je ręcznie na stworzonym branchu. Można to zrobić poprzez modyfikację wartości {{target_app_repo_branch}} w definicji aplikacji.

 

Konieczne jest wówczas usunięcie wpisu:

Po wykonaniu koniecznych operacji można zsynchronizować główną aplikację ArgoCD.

Działania wstępne przed wdrożeniem MetalLB w ArgoCD

Aktualizacja MetalLB w kontekście ArgoCD wymaga odpowiedniego przygotowania klastra, szczególnie jeśli chodzi o przypisanie i zarządzanie adresami IP. Poniżej opisano kluczowe kroki oraz ważne uwagi dotyczące prawidłowego przypisywania adresów IP przed operacją wdrożenia Metallb.

Prawidłowe przypisanie Adresów IP

Przypisanie adresów IP dla usług w klastrze, szczególnie w kontekście ArgoCD, nie jest wymagane. Jednakże, zaleca się utrzymanie sztywnej konfiguracji adresów IP dla obiektów, które tego wymagają.

Warto weryfikować, które usługi wymagają stałego przypisania adresów IP, a które mogą korzystać z dynamicznie przydzielonych adresacji. Przed dalszymi krokami należy się upewnić czy klaster jest gotowy do aktualizacji. W przypadku MetalLB konieczne jest zadeklarowanie adresów IP dla serwisów, zwłaszcza jeśli są one wymagane na stałe.

Utrzymywanie stabilnych adresów IP

Warto upewnić się, że usługi mają przypisane na stałe adresy IP, szczególnie w przypadku serwisów korzystających z DNS lub posiadających zadeklarowane stałe adresy IP w innych serwisach.

W przypadku klastra, dla którego opisujemy proces aktualizacji, nie wszystkie usługi miały przypisane adresy IP przed aktualizacją, co skutkowało przypisaniem losowych adresów z puli. To może prowadzić do nieoczekiwanych zmian w przypadku usług opierających się na określonych adresach IP.

Możemy sprawdzić to za pomocą polecenia:

 

W przypadku braku adresu należy zdefiniować go manifeście, np.:

Manifest zmieniamy na:

W przypadku usługi ArgoCD adres należy przypisać ręcznie edytując manifest bezpośrednio na klastrze.

 

Przygotowanie deklaracji manifestów

Na początku konieczne jest stworzenie ścieżki zadeklarowanej w samej aplikacji ArgoCD, w tym przypadku stworzono strukturę folderów.

 

W kontekście opisywanego klastra korzystanie z narzędzia Kustomize przynosi dodatkową wartość, choć nie jest ono wymagane do poprawnej konfiguracji. Użycie Kustomize może znacząco zwiększyć przejrzystość i ułatwić pracę nad konfiguracją klastra.

Tak wygląda gotowa struktura plików.

 

W opisywanym klastrze dotychczas MetalLB nie był wdrożony za pomocą ArgoCD, co wymaga teraz pełnej odbudowy konfiguracji oraz skonfrontowania jej z aktualnym stanem zarządzanym przez ArgoCD.

oraz IPAddressPool

Aby przygotować klaster do aktualizacji, istnieją pewne niezbędne kroki dotyczące konfiguracji, takie jak przygotowanie configmap oraz IPAddressPool. Ważne jest, że są one niezbędne do aktualizacji klastra, nie trzeba ich wykonywać podczas porównywania ArgoCD do k8s.

W nowej wersji jednak ta konfiguracja uległa zmianie. Teraz nowa metoda przypisywania adresów wymaga przygotowania configmap oraz IPAddressPool. Aby dostosować się do tych zmian, niezbędne jest zaznajomienie się z nowymi procedurami zarządzania adresacją. Warto podkreślić, że te kroki są konieczne do prawidłowej aktualizacji klastra, ale nie są wymagane podczas operacji porównywania ArgoCD do k8s.

W kontekście zmian w sposobie przypisywania i zarządzania adresacją po aktualizacji, warto zaznaczyć, że w poprzedniej wersji opierało się to na configmapie, którą można było przejrzeć za pomocą polecenia:

 

Prezentuje się ona następująco:

W wyniku wprowadzonych zmian konieczne jest zastosowanie dwóch dodatkowych manifestów, które modyfikują sposób zarządzania adresami. W opisywanym przypadku konieczne było otwarcie dodatkowego portu, bez którego jeden z webhooków nie będzie działał. Opisywana powyżej operacja była wymagana tylko w przypadku opisywanego klastra i wynika bezpośrednio z jego specyfiki oraz funkcjonujących usług.

W celu stworzono dwa dodatkowe manifesty w ścieżce /metallb/overlays/prod/configmap.yml zawierający kopię ConigMapy:

 

Oraz manifest zawierający nowe deklaracje i adresację conifg.yml:

kind: L2Advertisement wymaga wcześniejszego wdrożenia pliku /metallb/base/crds.yml. Bez wcześniejszej deklaracji CustomResourceDefinition zawierającej ten wpis nie będzie on działał.

Jak zostało wspomniane powyżej w przypadku opisywanego klastra konieczna była deklaracja menifestu otwierająca dodatkowy port 9443 bez którego nie zadziałałby jeden z WebHooków Przykład deklaracji w poniższym pliku config.yml

Ostatecznie konieczne jest zadeklarowanie nowych plików w /metallb/overlays/prod/kustomization.yml

Przyrównanie ArgoCD do środowiska

Pierwszym krokiem jest konieczność przygotowania manifestu dla aktualnej wersji MetalLB. Jest to niezbędne, ponieważ w opisywanym przypadku brakowało manifestu dla tej aplikacji po stronie Repozytorium jak i ArgoCD. Bez tego nie będziemy w stanie bezpiecznie i sprawnie cofnąć operacji czyli przeprowadzić operacji „rollback”.

W ArgoCD rollback polega na przekształceniu do poprzedniego, stabilnego stanu z ostatniego commitu wskazanego repozytorium.

Najskuteczniejszym sposobem na porównanie środowisk jest wygenerowanie szablonu dla konkretnej aplikacji za pomocą Helma. Należy określić aktualną wersję MetalLB i wygenerować szablon za pomocą:

Ten proces umożliwi dokładne określenie różnic między obecnym stanem a wcześniejszą wersją aplikacji MetalLB, co jest kluczowe w celu ewentualnego wykonania skutecznej i bezpiecznej operacji rollback.

Aktualną wersję można określić opisując pod controller lub speaker:

 
 

Praktyką zalecaną jest podzielenie manifestu na dwa osobne pliki. Jeden z nich powinien zawierać wszystkie wpisy dotyczące CustomResourceDefinition, a drugi – pozostałe obiekty. Ostatnim etapem jest dodanie odpowiednich wpisów do pliku /metallb/base/kustomization.yml.

Uwaga!

Niezwykle istotne jest, aby w kolejnych etapach nie dokonywać synchronizacji aplikacji po stronie ArgoCD. Obecnie naszym celem jest jedynie weryfikacja różnic i porównanie manifestu w ArgoCD z rzeczywistym stanem w klastrze. Po stronie ArgoCD ograniczono się do korzystania jedynie z dwóch przycisków: „Refresh” oraz „App Diff”.

 

Przycisk „App Diff” jest kluczowy do porównania zmian między ArgoCD a Klastrem. Zaleca się skorzystanie z opcji „Compact diff”, dostępnej w górnym prawym rogu, aby uprościć analizę różnic.

Naszym zadaniem jest eliminacja wszelkich różnic poprzez modyfikacje bezpośrednio w manifeście, a następnie wykonanie commita i pusha do repozytorium. Warto również regularnie porównywać zmiany za pomocą „App Diff”.

W przypadku MetalLB można również wykorzystać plik values.yaml, który może być używany podczas generowania szablonu, dodając flagę -f values.yaml do polecenia. Warto jednak zauważyć, że funkcjonalność ta może być ograniczona w przypadku MetalLB, a plik values.yaml będzie bardziej użyteczny przy aktualizacji prometheus-stack.

Po skutecznym porównaniu ArgoCD z klastrze i upewnieniu się, że „App Diff” nie wykazuje znaczących zmian, można przystąpić do synchronizacji za pomocą przycisku „Sync”. Dzięki temu procesowi zyskujemy punkty przywracania, a samo wdrożenie MetalLB przez ArgoCD zostaje zakończone sukcesem.

Przygotowanie manifestu

Procedura ta przeważnie nie różni się znacząco od porównywania ArgoCD do środowiska. Kluczową modyfikacją jest przede wszystkim generacja pliku szablonu z najnowszą wersją MetalLB za pomocą polecenia:

Należy pamiętać o konieczności wykonania pozostałych operacji opisanych w poprzednim etapie. Warto jednak zauważyć, że ze względu na aktualizację wersji mogą wystąpić istotne zmiany, co będzie widoczne w wynikach narzędzia App Diff.

Istotne jest, aby kluczowe elementy, takie jak 'name’ czy 'namespace’, zachowały swoje pierwotne wartości. W praktyce oznacza to, że nawet w przypadku znacznych modyfikacji wersji, te kluczowe atrybuty powinny pozostać niezmienione.

Pamiętajmy, że różnice w App Diff mogą być dość znaczące, dlatego istnieje potrzeba świadomego monitorowania tych zmian i ewentualnej ręcznej korekty, aby zapewnić spójność i poprawność konfiguracji środowiska.

Aktualizacja MetalLB

Po wygenerowaniu manifestu dla nowej wersji, przystępujemy ostatecznie do synchronizacji aplikacji w ArgoCD.

Warto pamiętać, że przed wprowadzeniem aktualizacji konieczne jest przygotowanie konfiguracji dla configmap oraz IPAddressPool. Zaleca się rozpoczęcie od synchronizacji obiektów CRD, ponieważ są one niezbędne do konfiguracji i warto je wdrożyć przed aktualizacją.

CRD często są kompatybilne wstecz, co oznacza, że ich aktualizacja nie powinna wpływać negatywnie na działanie klastra czy usług. Jednakże, w przypadku CRD, istnieje konieczność wykonania synchronizacji z opcją przełącznika „Replace”. Pominięcie tego kroku może prowadzić do błędów synchronizacji w ArgoCD.

Po zsynchronizowaniu obiektów CRD, można przejść do synchronizacji pozostałych elementów. Po zakończeniu tego procesu w ArgoCD, zaleca się monitorowanie stanu podów w namespace metallb-system za pomocą polecenia:

Podsumowanie

To był pierwszy fragment wpisu dotyczącego aktualizacji klastra Kubernetes do wersji 1.25.x. W tej części omówiono proces aktualizacji usług Argo CD oraz MetalLB. W następnym wpisie przedstawimy kroki związane z aktualizacją usług Portworx, prometheus-stack oraz Blackbox Exporter.