4 najważniejsze zmiany w Kubernetes v1.25

W tym artykule przedstawię Ci cztery najważniejsze moim zdaniem zmiany w związku z najnowszą wersją Kubernetes – v1.25. Zmian jest więcej, jednak te są moim zdaniem najbardziej kluczowe.


Kubernetes 1.25 wjeżdża na salony klastry

W sierpniu pojawiła się nowa wersja Kubernetes – v1.25. Wybieram subiektywnie 4 najbardziej interesujące zmiany. Na początek nie skupimy się na tym co zostało dodane, lecz na tym co zostało usunięte w wersji 1.25. 

Wakacje się skończyły (a u niektórych dopiero się kończą), więc powiemy sobie co się kończy w Kubernetesie, a później przejdziemy do tego co się zaczyna.


1) Usunięcie Pod Security Policy (PSP)

Mechanizm PSP uznany jako deprecated od wersji 1.21 znika całkowicie z Kubernetesa. Strata nie wielka, bo PSP miało ograniczone funkcjonalności i nawet jak człowiek chciał prawilnie skonfigurować security na klastrze, to za pomocą PSP nie dało się zrobić wszystkiego.

W miejsce PSP wprowadzono nowy mechanizm – Pod Security Admission. Wygląda obiecująco, aczkolwiek nie jestem do niego w 100% przekonany. Dlaczego? Mam pewne przypadki biznesowe, które wymagają czegoś więcej niż kontroli nad Podami. Może kiedyś się nimi podzielę.


2) Usunięcie API dla popularnych obiektów

CronJob batch/v1beta1
EndpointSlice discovery.k8s. io/v1beta1
Event events.k8s io/v1beta1
HorizontalPodAutoscaler autoscaling/v2beta1
PodDisruptionBudget policy/v1beta1
PodSecurityPolicy policy/v1beta1
RuntimeClass node.k8s. io/v1beta

Moja rekomendacja: Przejrzyj swoje Kubernetesowe repozytorium i poszukaj w/w (na czerwono) API, które zostały usunięte w wersji 1.25. A jeśli takowe znajdziesz, zaktualizuj do wspieranych wersji.


3) Bardziej rozbudowana kontrola nad restartami Job’ów 

Obecnie jedyną dostępną opcją na kontrolę restartu Joba jest użycie .spec.backoffLimit. Definiujemy w ten sposób maksymalną liczbę restartów, po których Job zostanie uznany jako “Failed”.

To jednak nie pozwala nam wykryć przyczyn restartu kontenerów. Jeśli znamy kod błędu (np. Exit 126 albo Exit 127) – wskazane byłoby od razu oznaczenie Joba jako “Failed”, zamiast wykonywania takiej ilości restartów,  jaką określimy w backoffLimit. 

Jak to wygląda w praktyce?

1. Jeśli wewnątrz aplikacji uruchamianej w ramach Joba pojawi się błąd (identyfikujemy go za pomocą zwracanego kodu) – to nie ma sensu wykonywać restartu. No bo błąd w kodzie aplikacji, albo problem z uprawnieniami po restarcie sam się nie naprawi.

2. Jeśli Job został przerwany z niezależnych od nas przyczyn np. infrastruktury – wtedy powinien zostać ponownie uruchomiony

Nowo wprowadzoną funkcjonalność znajdziemy w definicji .spec.backoffPolicy. Dzięki niej możemy kontrolować czy w przypadku błędu Job powinien zostać uruchomiony ponowione, czy też ma zostać uznany jako “Failed”. Warto dodać, że obecnie ta funkcjonalność jest w fazie alpha (czyt. nie jest zalecana na produkcję).


Szkolenie, które nauczy Cię wdrażać aplikacje na produkcji

Kurs Kubernetes Maestro

Kurs Kubernetes Maestro przeznaczony jest dla osób chcących nauczyć się KUBERNETES od PODSTAW i/lub poszerzyć dotychczasową wiedzę o dobre praktyki. Dla Programistów, DevOps-ów oraz wszystkich osób, które chcą:

nauczyć się od podstaw Kubernetes i zrozumieć orkiestrację kontenerów

poszerzyć swoją wiedzę związaną z kontenerami o:
bezpieczeństwo, dobre praktyki,  dodatkowe narzędzia ułatwiające pracę z Kubernetes

✅ dowiedzieć się jak w pełni wykorzystać możliwości Kubernetes

Odbierz kurs Kubernetes Maestro

Wykonasz dużo praktycznych ćwiczeń oraz poznasz Kubernetes “Best Practices” 

Kurs Kubernetes Maestro zawiera dużo praktycznych ćwiczeń, od prostych deploymentów, aż po ZAAWANSOWANE schematy pokrywające bezpieczeństwo kontenerów czy konfigurację sieciową pomiędzy kontenerami

✅ Przetestujesz w praktyce zagadnienia takie jak: Rolling update, Blue-green deployment czy Canary release

✅ Nauczysz się jak zapewnić stabilność aplikacjom działającym w Kubernetes poprzez przydzielanie odpowiednich limitów oraz wymuszeń

Więcej szczegółów znajdziesz na stronie KubernetesMaestro.pl.


4) Wsparcie dla User namespaces (security 🥷🏻)

Można by rzec – WRESZCIE! (no dobra, może nie każdy tak powie, ale wiesz pewnie, że temat security kontenerów to mój konik).

Skorzystanie z User namespaces pozwala na bardzo ciekawą rzecz. Rozważmy to na przykładzie uruchamiania kontenerów jako użytkownik root.


Jeśli zastosujemy User namespace, to proces wewnątrz kontenera będzie myślał, że działa jako ROOT, a w rzeczywistości z perspektywy systemu operacyjnego (worker node) będzie działał jako NON ROOT. To rozwiązanie nie tylko jest dobre ze względów bezpieczeństwa, ale także ma wpływ na elastyczność tego co uruchamiamy w kontenerach.


Dlaczego to jest fajne?

Bo każdy spec od bezpieczeństwa powie Ci, że nie możesz uruchamiać kontenerów w trybie roota, albo nie możesz włączać CAP_SYS_ADMIN.

Niestety są jeszcze technologie/narzędzia, które mogą wymagać czegoś niezgodnego z dobrymi praktykami np. wspomnianego już CAP_SYS_ADMIN. W takiej sytuacji, gdy w firmie/projekcie mamy wprowadzone polityki bezpieczeństwa, które sprawdzają co i jak uruchamiamy na klastrze – może się zdarzyć, że nie będziemy mogli skorzystać z wybranej technologii/narzędzia.

Wykorzystując User namespace wilk będzie syty i owca cała. Ponieważ proces w kontenerze będzie myśleć, że jest rootem, a tak naprawdę nim nie będzie. Aby skorzystać z tego mechanizmu, należy w definicji Poda ustawić spec.hostUsers: false. Domyślnie jest to ustawione na true.

WAŻNE: w tej chwili to rozwiązanie jest w fazie alpha i nie jest rekomendowane na produkcję. Czekamy zatem na rozwój wydarzeń (przejście do beta, a później do stable).


5) Jakie jeszcze zmiany w Kubernetes v1.25?

Empheral Containers oraz cgroups (v2) przeszły do stable
zmigrowano kod wielu Storage Drivers do osobnych repozytoriów.

A po resztę zmian zapraszam do poniższych artykułów:

1) Więcej na temat zmian w Kubernetes v1.25:
2) Więcej na temat zmian w Kubernetes v1.25:






.

Leave a Comment

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *