Automatyczna aktualizacja klastra Kubernetes w NSIS OpenStack Magnum
Ostrzeżenie
W chwili pisania tego tekstu szablony klastrów z możliwością aktualizacji są dostępne tylko w regionie NSIS WAW4-1.
Klastry OpenStack Magnum utworzone w NSIS mogą być automatycznie aktualizowane do kolejnej mniejszej wersji Kubernetes. Ta funkcja jest dostępna dla klastrów od wersji 1.29 Kubernetes.
W tym artykule zademonstrujemy aktualizację klastra Magnum Kubernetes z wersji 1.29 do wersji 1.30.
Co będziemy omawiać?
Jak aktualizacja działa automatycznie w Magnum
Magnum zarządza klastrami Kubernetes za pomocą szablonów klastrów i automatyzuje proces aktualizacji za pomocą mechanizmu rolling upgrade. Począwszy od wersji 1.29/1.30, Magnum:
W pierwszej kolejności aktualizowane są węzły płaszczyzny sterowania.
Uaktualnia węzły robocze** jeden po drugim, aby zminimalizować przestoje.
Dodatkowy węzeł jest dodawany przed aktualizacją węzła (oprócz węzłów określonych przez użytkownika w specyfikacji klastra).
Zachowuje kompatybilność API podczas aktualizacji, a tym samym zapewnia płynne działanie istniejących obciążeń.
Nie jest możliwe pominięcie pomniejszych wersji podczas aktualizacji.
Wymagania wstępne
Nr 1 Hosting
Potrzebne jest konto hostingowe NSIS z interfejsem Horizon https://horizon.cloudferro.com.
Nr 2 Dostęp do chmury i klastra
Polecenia openstack i kubectl muszą być uruchomione:
Jak zainstalować klientów OpenStack i Magnum dla interfejsu wiersza poleceń w NSIS Horizon?
Jak uzyskać dostęp do klastra Kubernetes po wdrożeniu przy użyciu Kubectl na NSIS OpenStack Magnum?
Nr 3 Dostępność szablonów klastrów z możliwością aktualizacji (wersje 1.29/1.30).
Istnieje bezpośrednia zgodność między szablonami klastrów dostępnymi w NSIS a wersjami Kubernetes z identycznymi numerami wersji minor:
Wersje Kubernetes z możliwością aktualizacji |
calico cluster template |
szablon klastra krzemowego |
|---|---|---|
1.29 |
k8s-v1.29.13-1.1.0 |
k8s-v1.29.13-1.1.0-cilium |
1.30 |
k8s-v1.30.10-1.1.0 |
k8s-v1.30.10-1.1.0-cilium |
Obecnie tylko wersja 1.29 Kubernetes jest automatycznie aktualizowana do wersji 1.30. Wersja 1.30 zostanie automatycznie uaktualniona do wersji 1.31, gdy odpowiednie wersje szablonów klastrów staną się dostępne w NSIS.
Aby przetestować działanie, można utworzyć nowy klaster z szablonem w wersji cilium 1.29. Polecenie może wyglądać następująco:
openstack coe cluster create \
--cluster-template k8s-v1.29.13-1.1.0-cilium \
--docker-volume-size 50 \
--labels eodata_access_enabled=false,floating-ip-enabled=true \
--merge-labels \
--keypair sshkey \
--master-count 3 \
--node-count 5 \
--timeout 190 \
--master-flavor eo2a.large \
--flavor eo2a.medium \
cilium-129
Nr 4 Zapewnienie kompatybilności aplikacji z docelową wersją K8s
W tym konkretnym przypadku należy sprawdzić Kubernetes 1.30 Release Notes, aby upewnić się, że aplikacje są kompatybilne. Pamiętaj, aby zawsze sprawdzać informacje o wersji dla docelowej wersji Kubernetes, do której aktualizujesz klaster.
Utwórz kopię zapasową i obserwuj stan klastra przed aktualizacją.
Musimy porównać stan klastra
przed,
podczas i
po aktualizacji.
W idealnej sytuacji wszystko powinno działać od razu po wyjęciu z pudełka, jednak lepiej jest to sprawdzić i zweryfikować.
Kopia zapasowa klastra Kubernetes
Zdecydowanie zaleca się wykonanie kopii zapasowej klastra 1.29 przed aktualizacją. Zobacz Kopia zapasowa klastra Kubernetes przy użyciu Velero.
Ta kopia zapasowa będzie służyć jako stan „przed” aktualizacją.
Monitorowanie procesu aktualizacji za pomocą pulpitu nawigacyjnego klastra
Najprostszym sposobem obserwowania klastra jest korzystanie z pulpitu nawigacyjnego klastra. Zobacz Korzystanie z pulpitu nawigacyjnego w celu uzyskania dostępu do klastra Kubernetes po wdrożeniu w NSIS OpenStack Magnum.
Aby zobaczyć wersje węzłów, wybierz opcję Węzły w menu po lewej stronie, kliknij nazwę węzła i przewiń nieco w dół, aby znaleźć wersję kubeletu:
Inne narzędzia do porównywania klastrów mogą obejmować testy CI/CD, obserwowanie klastrów za pomocą Prometheus i Grafana, przechowywanie statystyk klastrów w bazie danych jako szeregów czasowych i tak dalej.
Przygotowanie aktualizacji
Weryfikacja wersji klastra
Poniższe polecenie wyświetla wersję klastra:
echo $(openstack coe cluster show cilium-129 | awk '/ coe_version /{print $4}')
W tym artykule wersja przed aktualizacją to 1.29.13.
Identyfikator klastra
Pobierz identyfikator klastra Kubernetes, który chcesz uaktualnić:
openstack coe cluster list
Przykładowe dane wyjściowe:
Nazwa klastra to cilium-129, a identyfikator klastra, uuid, to 10447c96-904f-41e7-9d96-62894071f6d6.
W kolejnych poleceniach możemy użyć nazwy lub uuid klastra.
Uruchamianie aktualizacji
Polecenie inicjujące automatyczną aktualizację to:
openstack coe cluster upgrade <cluster-id> <template-version>
W naszym przypadku:
openstack coe cluster upgrade 10447c96-904f-41e7-9d96-62894071f6d6 k8s-v1.30.10-1.1.0-cilium
Z tabeli w Wymaganiach wstępnych nr 3 widzimy, że ponieważ klaster cilium-129 został utworzony przy użyciu szablonu k8s-v1.29.13-1.1.0-cilium, do aktualizacji musimy użyć szablonu k8s-v1.30.10-1.1.0-cilium.
W następnym wierszu powinien pojawić się komunikat, że aktualizacja do tego klastra została zaakceptowana:
I odwrotnie, jeśli popełnisz błąd w, powiedzmy, nazwie szablonu, otrzymasz komunikat 404:
Polecenia do monitorowania postępu aktualizacji
Sposobem GUI na monitorowanie procesu aktualizacji byłoby użycie pulpitu nawigacyjnego dla klastra, jak wspomniano powyżej. Sposób CLI polegałby na wydawaniu określonych poleceń, na przykład:
Pokaż tylko wersję klastra
echo $(openstack coe cluster show cilium-129 | awk '/ coe_version /{print $4}')
Podczas aktualizacji pole health_status może tymczasowo przejść do stanu UNHEALTHY, aż do zatrzymania aktualizacji. Niezależnie od tego, klaster pozostaje responsywny przez cały proces aktualizacji.
Monitoruj węzły
kubectl get nodes -o wide
Gdy wszystkie węzły będą w wersji 1.30.10, aktualizacja zostanie zakończona w następujący sposób:
Z reguły można założyć, że aktualizacja każdego węzła zajmie kilka minut. Rzeczywisty czas będzie zależał od zbyt wielu czynników, aby je wymienić, a rozważanie tego wykracza poza zakres tego artykułu.
Weryfikacja aktualizacji
Jeśli wykonałeś obie czynności
kopia zapasowa starego klastra i
zaktualizowana do następnej mniejszej wersji Kubernetes,
Będziesz miał dwa klastry i będziesz mógł je porównać.
Użyj pulpitu nawigacyjnego, aby porównać wyniki „przed” i „po”. Znajdź ewentualne różnice, dowiedz się, co oznaczają i, jeśli to konieczne, rozwiąż je.
Jeśli coś nadal nie jest w porządku, sprawdź, czy w kodzie nie zaszły jakieś przełomowe zmiany od wersji 1.29 do wersji 1.30.