Łatwo jest postawić wiele klastrów z Kubernetesem, zapuścić kilka manifestów, dograć Helm Charty i odtrąbić sukces.
W codziennym, szarym życiu liczy się bardziej to co dzieje się później. W użytkowaniu platformy bardzo duży wpływ ma dostępność nowych wersji Kubernetesa oraz łatanie dziur i podatności. To jak obsługiwana jest platforma dla aplikacji jest widoczne bardziej dla organizacji i jej klientów niż jakieś nowinki technologiczne.
Tym razem przyjrzę się tematowi aktualizacji klastrów.

Wersjonowanie Kubernetesa

Czy wiesz jak jest wersjonowany kubernetes? Podlega on konwencji wersjonowania semantycznego i każda wersja zawiera trzy człony:

MAJOR.MINOR.PATCH

• MAJOR – niezmieniona od 2015 wersja główna. Obecnie jest to “1” i tylko przy naprawdę olbrzymich zmianach będzie ona podniesiona. Nie zapowiada się jednak, aby nastąpiło to w najbliższych latach.
• MINOR – mniejsze aktualizacje wprowadzające czasem dość istotne zmiany, ale w dużym stopniu zachowujące kompatybilność wsteczną. Projekt Kubernetes wypuszcza trzy takie wersje w ciągu roku.
• PATCH –  to małe, wręcz znikome zmiany które łatają dziury nie zmieniając przy tym samego API. Każda wersja minor dostarcza takie patche w okresie do jednego roku od jej wypuszczenia. Oznacza to, że musisz zaktualizować klaster przynajmniej raz w roku, bo w przeciwnym wypadku zostaniesz z wersją, do której już nie ma aktualizacji (również takich które mogą wprowadzić realne niebezpieczeństwo dla twoich danych!).

Te poszczególne wersje są wykorzystywane przez kanały aktualizacji.

Czym są kanały aktualizacji

Ten koncept dzieli sposób dostarczania aktualizacji w zależności od potrzeb używania nowych funkcjonalności Kubernetesa, a przede wszystkim od akceptowalnego poziomu ryzyka jakie to niesie ze sobą.
Niektóre usługi kubernetesa w chmurze oraz dystrybucje on-prem obsługują takie kanały. Koncepcja jest bardzo podobna, chociaż nazewnictwo kanałów może być różne.
Wyróżniamy z reguły trzy kanały aktualizacji, które mogą być przypisane do klastra. Są to:

• RAPID –  kanał progresywny, który dostarczy aktualizacje najszybciej jak tylko dostawca przygotuje odpowiednie paczki dla usługi lub dystrybucji z najnowszą wydaną przez projekt wersją

• STABLINY –  kanał standardowy, który nowe wersje minor kubernetesa dostarczy z pewnym opóźnieniem, a do tego czasu dostarczy poprawki, czyli najnowsze wersje patch
• KONSERWATYWNY –  jak nazwa sugeruje jest to kanał skupiający się głównie na dostarczaniu najnowszych wersji patch. Klaster z tak podpiętym kanałem będzie najdłużej utrzymywał wersję major i tym samym będzie doskonałym kandydatem dla wersji produkcyjnych.

A które platformy wspierają kanały aktualizacji?
Z dużych graczy są to GKE i AKS, ale nie EKS co jest wręcz szokujące 🤯
Z popularnych dystrybucji dla on-prem to oczywiście OpenShift od Red Hata i RKE2 od Ranchera/SuSe. 

Kiedy użyć autoaktualizacji

Moja rekomendacja to aktualizować automatycznie jeśli tylko jest taka możliwość. Największą przeszkodą może być bardzo konserwatywne i unikające nawet najmniejszego ryzyka podejście stosowane w danej organizacji. Są takie sektory, gdzie zmiana musi być naprawdę solidnie przetestowana, aby mogła dojść do produkcji czy nawet stage.
Moim zdaniem tam również jest to możliwe do osiągnięcia poprzez dobre zarządzenie procesem aktualizacji. Zatem jeśli masz więcej niż jeden klaster i w szczególności gdy jest on w chmurze (no chyba, że masz EKS…) to nie wahałbym się zbyt długo i użyłbym kanałów aktualizacji w trybie automatycznym.
A jaką wtedy strategię wybrać?

Jaka strategia aktualizacji jest najlepsza

Duża część zacznie pewnie od ręcznej  aktualizacji, aby sprawdzić jej działanie i wyłapać ewentualne problemy. To może być pierwszy krok przed włączeniem automatu ale również wersja dla super ostrożnych. Tutaj jednak pojawia się ryzyko utknięcia w błędnym kole.
Widziałem to już wielokrotnie i sam byłem tego ofiarą. Na czym ono polega?

Na początku opóźniasz nieznacznie wprowadzenie nowej wersji, bo boisz się, że ona coś zepsuje. Mija więcej czasu, pojawiają się nowe wersje, które wprowadzają jeszcze więcej zmian. Twój strach o to, że one coś zepsują jeszcze bardziej narasta. Powoduje on, że masz jeszcze więcej powodów na to aby nie zaktualizować do kolejnej wersji. I tak tkwisz w tym błędnym kole dotąd aż coś lub ktoś zmusi cię do aktualizacji i zamiast obsłużyć to małymi krokami zmuszony jesteś do wykonania jednej WIELKIEJ zmiany. I zgadnij co. –  wtedy spełni się twoja przepowiednia i faktycznie coś może pójść nie tak bo zmian będzie już zdecydowanie więcej niż gdybyś robił to regularnie.

W przypadku automatycznego aktualizowania polecam strategię waterfall. Polega ona na przypisaniu różnych kanałów do różnych klastrów tak, aby klastry nieprodukcyjne aktualizowały się nowszymi wersjami wcześniej niż klastry typu stage lub prod. Pozwala to na przetestowanie zmian i wprowadzenie ewentualnych modyfikacji do manifestów.

A co jeśli nie ma kanałów aktualizacji

Nie musisz od razu wpadać w panikę, ale też pamiętaj aby nie wpaść w błędne koło. Zaplanuj samodzielnie harmonogram aktualizacji i poinformuj o tym wszystkie zainteresowane strony. Na początku może być opór, ale musisz się tego trzymać, aby przyzwyczaić organizację do tych zmian i przede wszystkim zadbać o sprawne funkcjonowanie platformy.

Jeśli brak kanałów aktualizacji wynika z początkowej decyzji co do wyboru dystrybucji to może być to okazja do jej zmiany w przypadku kolejnych projektów. Pamiętaj, że kompatybilność będzie zachowana –  to gwarantuje specyfikacja API kubernetesa.
A jeśli masz EKSa to nie pozostaje nic innego jak pisać do AWS petycję o wprowadzenie tej podstawowej  funkcjonalności dla dojrzałych usług Kubernetesa w chmurze.