Azure Kubernetes Service i aktualizacje

Azure Kubernetes Service jest usługą typu zarządzanego, ale mamy w niej większą kontrolę, niż w typowych usługach typu PaaS. Jednym ze szczegółów, który jest istotny, to sposób zrozumienia zarządzania wersją i poprawkami bezpieczeństwa.

Poprawki bezpieczeństwa

W AKS możemy aktualizować dwie rzeczy, jeśli chodzi o poprawki bezpieczeństwa: wersja Kubernetes oraz nody (czyli systemy operacyjne w serwery AKS widoczne w naszej subskrypcji, na których są odpalane nasze kontenery). O aktualizacji wersji Kubernetes napisałem poniżej.

Na samych nodach poprawki bezpieczeństwa w systemach instalowane są automatycznie w godzinach nocnych. Nie mamy wpływu na to, co jest instalowane, ale to my jesteśmy odpowiedzialni za wykonanie restartów serwerów, jeśli jest to wymagane. Możemy przeprowadzić to na 3 sposoby.

Pierwszym sposobem jest ręczny restart z wykorzystaniem portalu Azure lub Azure CLI. Prawidłowo, należy zrobić to poprzez drain usług na serwer za pomocą kubectl, restart i włączenie serwera z powrotem do użytku w K8S. Szczerze, odradzam tę metodę.

Kolejnym sposobem jest wykonanie wymiany maszyn wirtualnych na wersje z nowszym obrazem z już wgranymi aktualizacjami. Proces ten wykonuje się za pomocą Azure CLI i komendy az aks upgrade bez dokonywania zmiany wersji Kubernetes. Metoda ta jest o wiele lepszym rozwiązaniem. Działa ona na zasadzie automatycznego dodania nowej maszyny wirtualnej do klastra, a następnie na usunięciu starej, aż do wymiany wszystkich maszyn w klastrze. Co ważne, w trakcie tego procesu kontenery są przenoszone prawidłowo ze starych maszyn przed skasowaniem, na nowe z wykorzystaniem cordon i drain w K8S.

Możemy też skonfigurować w pełni automatyczne restarty z wykorzystaniem kured od weaveworks. Kured to skrót od Kubernetes Reboot Daemon. Jest to rozwiązanie na licencji Apache 2.0, które automatyzuje właśnie restarty po instalacji aktualizacji. Kured sprawdza czy na serwerze istnieje plik /var/run/reboot-required i jeśli go znajdzie, to dokonuje restartu serwera. Tak jak w przypadku poprzedniej metody jest restartowany serwer po serwerze wraz z wykonaniem cordon i drain w K8S, aby restart był przyjazny dla kontenerów. W kured są różne opcje konfiguracji opisane w repozytorium na GitHub, jedną z nich są powiadomienia o restartach na Slacku.

Dla dociekliwych plik /var/run/reboot-required występuje między innymi w Ubuntu, który tworzy go automatycznie, jeśli zainstalowane aktualizacje wymagają restartu. Microsoft w AKS wykorzystuje właśnie Ubuntu w wersji LTS.

Wersja Kubernetes

Za wybranie wersji Kubernetes jesteśmy odpowiedzialni sami i to my wskazujemy ją w trakcie tworzenia klastra jak i podczas aktualizacji. Microsoft nie aktualizuje za nas jego wersji.

Więc, jeśli z jakichś przyczyn chcemy korzystać z nowszej wersji K8S, należy ręcznie przeprowadzić aktualizację. Tę operację możemy wykonać między innymi za pomocą polecenie az aks upgrade wskazując wersję do której chcemy się zaktualizować. Tak jak w przypadku wymiany obrazu proces ten wymienia serwer po serwerze, aby zapewnić jak najkrótsze przestoje aplikacji.

Szczegółowe informacje na ten temat znajdziesz w dokumentacji do Azure Kubernetes Service, a dokładniej w FAQ ;-)