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
W tym artykule zademonstrujemy aktualizację klastra Magnum Kubernetes z wersji 1.29 do wersji 1.30.
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 aktualizuje węzły płaszczyzny kontrolnej.
Aktualizuje węzły robocze jeden po drugim, aby zminimalizować przestoje.
Dodaje dodatkowy 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ń.
Podczas aktualizacji nie można pominąć pomniejszych wersji.
Wymagania wstępne
Nr 1 Hosting
Wymagane 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. patrz artykuły:
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 |
cilium cluster template |
|---|---|---|
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ą.
Należy porównać stan klastra
przed,
podczas i
po aktualizacji.
W idealnej sytuacji wszystko powinno działać od razu, jednak lepiej jest to sprawdzić i zweryfikować.
Kopia zapasowa klastra Kubernetes
Zdecydowanie zaleca się wykonanie kopii zapasowej klastra 1.29 przed aktualizacją. Zobacz artykuł Tworzenie kopii zapasowych 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 artykuł Korzystanie z dashboardu w celu uzyskania dostępu do klastra Kubernetes po wdrożeniu OpenStack Magnum w NSIS Cloud.
Aby zobaczyć wersje węzłów, wybierz opcję Nodes w menu po lewej stronie, kliknij nazwę węzła i przewiń nieco w dół, aby znaleźć pozycję kubelet version:
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.
Sprawdzenie identyfikatora 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.
Uruchom aktualizację
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 sekcji Wymagania wstępne nr3 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 na przykład w nazwie szablonu, otrzymasz komunikat 404:
Polecenia do monitorowania postępu aktualizacji
Jak wspomniano powyżej, GUI monitoruje proces aktualizacji za pomocą pulpitu nawigacyjnego klastra. Sposób z użyciem CLI polega na wydanii określonych poleceń, na przykład:
Wyświetlanie tylko wersji klastra
echo $(openstack coe cluster show cilium-129 | awk '/ coe_version /{print $4}')
Podczas aktualizacji pole health_status może tymczasowo mieć status UNHEALTHY, aż do zatrzymania aktualizacji. Niezależnie od tego, klaster pozostaje responsywny przez cały proces aktualizacji.
Monitorowanie węzłów
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 zostały wykonane obie te czynności:
kopia zapasowa starego klastra i
aktualizacja do następnej wersji minor Kubernetes,
będziesz mieć dwa klastry i będzie można je porównać.
Użyj pulpitu nawigacyjnego, aby porównać wyniki „przed” i „po” aktualizacji . Znajdź ewentualne różnice, sprawdź, co oznaczają i, jeśli to konieczne, rozwiąż problemy.
Jeśli coś nadal jest nie tak, sprawdź, czy w kodzie nie zaszły jakieś znaczące zmiany od wersji 1.29 do wersji 1.30.