🥇Kubernetes 1.16: przegląd najważniejszych nowości

Dziś, w środę, odbędzie się kolejna wersja Kubernetes — 1.16. Zgodnie z tradycją naszego bloga, po raz dziesiąty przedstawiamy najważniejsze zmiany w nowej wersji.

Informacje użyte do przygotowania tego materiału pochodzą z tabeli śledzenia ulepszeń Kubernetes, CHANGELOG-1.16 i odpowiadających kwestii, pull requestów oraz propozycji ulepszeń Kubernetes (KEP). Zaczynajmy!..

Węzły

Naprawdę duża liczba zauważalnych nowości (w wersji alfa) została przedstawiona po stronie węzłów klastrów K8s (Kubelet).

Po pierwsze, wprowadzono tzw. «efemeryczne kontenery» (Ephemeral Containers), mające na celu uproszczenie procesów debugowania w podach. Nowy mechanizm pozwala na uruchomienie specjalnych kontenerów, które startują w przestrzeni nazw istniejących podów i żyją tylko przez krótki czas. Ich celem jest interakcja z innymi podami i kontenerami w celu rozwiązania problemów i debugowania. Dla tej możliwości wdrożono nową komendę kubectl debug, podobną w swej istocie do kubectl exec: tylko zamiast uruchamiać proces w kontenerze (jak w przypadku exec) uruchamia kontener w podzie. Na przykład, taka komenda podłączy nowy kontener do podu:

kubectl debug -c debug-shell --image=debian target-pod -- bash

Szczegóły dotyczące efemerycznych kontenerów (i przykłady ich użycia) można znaleźć w odpowiednim KEP. Obecna realizacja (w K8s 1.16) to wersja alfa, a wśród kryteriów jej przejścia do wersji beta uwzględniono "testowanie Ephemeral Containers API przez co najmniej 2 wydania [Kubernetes]".

NB: Pod względem istoty i samej nazwy funkcja przypomina już istniejący plugin kubectl-debug, o którym niedawno opowiadaliśmy. już pisaliśmy. Zakłada się, że wraz z pojawieniem się efemerycznych kontenerów rozwój oddzielnego zewnętrznego pluginu zostanie wstrzymany.

Inną nowością jest PodOverhead , który ma na celu dostarczenie mechanizmu obliczania kosztów dodatkowych dla podów, które mogą się znacznie różnić w zależności od używanego środowiska wykonawczego (runtime). Jako przykład autorzy tego KEP podają Kata Containers, które wymagają uruchomienia gościnnego jądra, agenta kata, systemu init itp. Kiedy overhead staje się tak duży, że nie można go zignorować, konieczne staje się znalezienie sposobu na jego uwzględnienie podczas dalszego kwotowania, planowania itp. W celu jego realizacji w PodSpec dodano pole Overhead *ResourceList , które jest powiązane z danymi w RuntimeClass, jeśli taki jest używany).

Kolejną znaczącą nowością jest menedżer topologii węzła (Node Topology Manager), który ma na celu ujednolicenie podejścia do precyzyjnego dostosowywania przydzielania zasobów sprzętowych dla różnych komponentów w Kubernetes. Inicjatywa ta jest odpowiedzią na rosnące zapotrzebowanie współczesnych systemów (z dziedziny telekomunikacji, uczenia maszynowego, usług finansowych itp.) na wysokowydajne obliczenia równoległe oraz minimalizację opóźnień w realizacji operacji, w tym celu wykorzystują one zaawansowane możliwości CPU i przyspieszenia sprzętowego. Takie optymalizacje w Kubernetes były dotąd osiągane dzięki rozdzielnym komponentom (menedżer CPU, menedżer urządzeń, CNI), a teraz dodadzą wspólny interfejs wewnętrzny, który ujednolici podejście i uprości podłączanie nowych podobnych — tak zwanych topology-aware — komponentów po stronie Kubelet. Szczegóły znajdują się w odpowiednim KEP.

Schemat komponentów menedżera topologii

Kolejną funkcją jest sprawdzanie kontenerów podczas ich uruchamiania (startup probe). Jak wiadomo, dla kontenerów, które długo się uruchamiają, trudno jest uzyskać aktualny status: either są 'zabijane' jeszcze przed rozpoczęciem rzeczywistego działania, albo przez długi czas wpadają w deadlock. Nowa kontrola (włączana poprzez feature gate o nazwie StartupProbeEnabled) znieś - a właściwie odkłada - działanie jakichkolwiek innych kontrolek do momentu, w którym pod zakończy swoje uruchamianie. Z tej przyczyny funkcję początkowo nazywano pod-startup liveness-probe holdoff. Dla podów, które długo się uruchamiają, można przeprowadzać zapytania o stan w stosunkowo krótkich odstępach czasu.

Dodatkowo, od razu w wersji beta wprowadzono ulepszenie dla RuntimeClass, które dodaje wsparcie dla 'heterogenicznych klastrów'. RuntimeClass Scheduling nie jest już konieczne, aby każdy węzeł miał wsparcie dla każdego RuntimeClass'a: dla podów można wybierać RuntimeClass bez myślenia o topologii klastra. Wcześniej, aby osiągnąć ten cel — aby pody znajdowały się na węzłach z pełnym wsparciem dla wszystkiego, czego potrzebują — trzeba było przypisywać odpowiednie zasady do NodeSelector i tolerations. W KEP opisano przykłady zastosowania oraz, oczywiście, szczegóły realizacji.

Sieć

Dwie znaczące funkcje sieciowe, które pojawiły się po raz pierwszy (w wersji alfa) w Kubernetes 1.16 — to:

Wsparcie podwójny stos sieciowy — IPv4/IPv6 — i jego „rozumienie” na poziomie podów, węzłów, usług. Obejmuje to interakcję IPv4-to-IPv4 i IPv6-to-IPv6 między podami, z podów do zewnętrznych usług, referencyjnych implementacji (w ramach wtyczek Bridge CNI, PTP CNI i Host-Local IPAM), a także zapewnia zgodność wsteczną z klastrami Kubernetes działającymi tylko w trybie IPv4 lub IPv6. Szczegóły implementacji znajdują się w KEP.
Przykład wyświetlania adresów IP dwóch typów (IPv4 i IPv6) na liście podów:
```
kube-master# kubectl get pods -o wide
NAZWA              GOTOWY    STATUS     RESTARTY   WIEK       IP                          WĘZEŁ
nginx-controller   1/1        Działa    0          20m       fd00:db8:1::2,192.168.1.3   kube-minion-1
kube-master#
```
Nowe API dla Endpoint — EndpointSlice API. Rozwiązuje problemy istniejącego API Endpoint w zakresie wydajności/skali, które dotyczą różnych komponentów w control-plane (apiserver, etcd, endpoints-controller, kube-proxy). Nowe API zostanie dodane do grupy API Discovery i będzie w stanie obsługiwać dziesiątki tysięcy endpointów backendowych na każdym serwisie w klastrze składającym się z tysięcy węzłów. W tym celu każdy Service jest mapowany na N obiektów EndpointSlice, z których każdy domyślnie ma nie więcej niż 100 endpointów (wartość konfigurowana). W API EndpointSlice przewidziano również możliwości przyszłego rozwoju: obsługa wielu adresów IP dla każdego poda, nowe stany dla endpointów (nie tylko Gotowy i NotReady), dynamiczne podzbiory dla endpointów.

Do wersji beta doszedł zaprezentowany w poprzednim wydaniu finalizer, nazwany service.kubernetes.io/load-balancer-cleanup i przypisany do każdego serwisu typu LoadBalancer. W momencie usunięcia takiego serwisu zapobiega faktycznemu usunięciu zasobu, dopóki nie zakończy się „czyszczenie” wszystkich odpowiadających mu zasobów balansownika.

API Machinery

Rzeczywisty „kamień milowy stabilizacji” został odnotowany w obszarze API serwera Kubernetes i interakcji z nim. W dużej mierze udało się to dzięki przeniesieniu statusu na stable dla wymagających specjalnej reprezentacji CustomResourceDefinitions (CRD), które miały status beta od czasów odległych Kubernetes 1.7 (a to czerwiec 2017 roku!). Ta sama stabilizacja dotyczyła również powiązanych z nimi funkcji:

„podzasobów” (subresources) z /status i /scale dla CustomResources;
przekształcenie wersji dla CRD, oparte na zewnętrznym webhooku;
niedawno przedstawione (w K8s 1.15) wartości domyślne (defaulting) i automatyczne usuwanie pól (pruning) dla CustomResources;
możliwość zastosowanie schemy OpenAPI v3 do tworzenia i publikacji dokumentacji OpenAPI, wykorzystywanej do walidacji zasobów CRD po stronie serwera.

Kolejny mechanizm, który stał się już znany administratorom Kubernetes: webhook zatwierdzający — przez długi czas był w wersji beta (od K8s 1.9) i teraz został uznany za stabilny.

Dwie inne funkcje osiągnęły wersję beta: zastosowanie po stronie serwera i zakładki obserwacji.

A jedyną istotną nowością w wersji alfa była rezygnacja od SelfLink — specjalny URI, reprezentujący dany obiekt i będący częścią ObjectMeta i ListMeta (tj. częścią każdego obiektu w Kubernetes). Dlaczego z niego rezygnują? Motywacja "w prostych słowach" brzmi jak brak rzeczywistych (nieprzezwyciężalnych) powodów, aby to pole wciąż istniało. Bardziej formalne powody to optymalizacja wydajności (usunięcie zbędnego pola) i uproszczenie pracy generic-apiserver, który musi przetwarzać to pole w szczególny sposób (to jedyne pole, które jest ustawiane bezpośrednio przed serializacją obiektu). Prawdziwe „deprecjonowanie” (w ramach wersji beta) SelfLink nastąpi w wersji Kubernetes 1.20, a ostateczne — 1.21.

Przechowywanie danych

Główna praca w obszarze storage, podobnie jak w poprzednich wydaniach, koncentruje się na wsparciu CSI. Główne zmiany obejmują:

po raz pierwszy (w wersji alfa) pojawiła się wsparcie dla wtyczek CSI dla węzłów roboczych z Windows: aktualny sposób pracy z magazynami, który tutaj zastąpi wtyczki in-tree w jądrze Kubernetes i wtyczki FlexVolume od Microsoftu oparte na Powershell;

Schemat realizacji wtyczek CSI w Kubernetes dla Windows
możliwość zmiana rozmiaru wolumenów CSI, przedstawiony jeszcze w K8s 1.12, osiągnął wersję beta;
podobne „podwyższenie” (z wersji alfa do beta) osiągnęła możliwość użycia CSI do tworzenia lokalnych efemerycznych wolumenów (Wsparcie dla wolumenów CSI Inline).

Wprowadzona w poprzedniej wersji Kubernetes funkcja klonowania wolumenów (użycie istniejących PVC jako DataSource do tworzenia nowych PVC) również uzyskała status wersji beta.

Harmonogram

Dwie zauważalne zmiany w planowaniu (oba w wersji alfa):

EvenPodsSpreading — możliwość używania podów zamiast logicznych jednostek aplikacji dla „uczciwego rozkładu” obciążeń (takich jak Deployment i ReplicaSet) oraz regulacja tego rozkładu (jako wymóg ścisły lub jako wymaganie elastyczne, tj. priorytet). Ta funkcja rozszerzy istniejące możliwości rozkładu zaplanowanych podów, obecnie ograniczone opcjami PodAffinity i PodAntiAffinity, dając administratorom bardziej precyzyjną kontrolę w tej kwestii, a tym samym - lepszą dostępność i zoptymalizowane zużycie zasobów. Szczegóły - w KEP.
Użycie Polityka BestFit do Funkcja Priorytetu RequestedToCapacityRatio podczas planowania podów, co umożliwi stosować pakowanie binarne („pakowanie w kontenery”) zarówno dla zasobów podstawowych (CPU, pamięć), jak i rozszerzonych (takich jak GPU). Więcej informacji w KEP.

Planowanie podów: przed zastosowaniem polityki best fit (bezpośrednio przez default scheduler) i z jej zastosowaniem (przez scheduler extender)

Ponadto, została zaprezentowana możliwość tworzenia własnych wtyczek do planista poza głównym drzewem rozwoju Kubernetes (out-of-tree).

Inne zmiany

Również w wydaniu Kubernetes 1.16 warto zauważyć inicjatywę mającą na celu dostosowanie istniejących metryk do pełnego porządku, a dokładniej - do zgodności z oficjalnymi wytycznymi do instrumentacji K8s. W gruncie rzeczy opierają się one na odpowiedniej dokumentacji Prometheus. Niespójności powstały z różnych powodów (na przykład niektóre metryki zostały po prostu utworzone przed pojawieniem się bieżących instrukcji), a deweloperzy uznali, że nadszedł czas, aby wszystko doprowadzić do jednego standardu, „w zgodności z resztą ekosystemu Prometheus”. Obecna realizacja tej inicjatywy jest w wersji alfa, która będzie sukcesywnie podnoszona w kolejnych wersjach Kubernetes do bety (1.17) i stabilnej (1.18).

Ponadto warto zauważyć następujące zmiany:

Rozwój wsparcia dla Windows z pojawieniem się narzędzia Kubeadm dla tego systemu operacyjnego (wersja alfa), możliwość RunAsUserName dla kontenerów Windows (wersja alfa), ulepszeniem wsparcie kont grupowych Managed Service Account (gMSA) do wersji beta, wsparciem mount/attach dla wolumenów vSphere.
Przebudowany mechanizm kompresji danych w odpowiedziach API. Wcześniej do tych celów używano filtra HTTP, który nakładał szereg ograniczeń, utrudniających jego domyślne włączenie. Teraz działa „przezroczysta kompresja żądań”: klienci wysyłający Accept-Encoding: gzip w nagłówku otrzymują odpowiedź skompresowaną w GZIP, jeśli jej rozmiar przekraczał 128 Kb. Klienci działający na Go automatycznie wspierają kompresję (wysyłają odpowiedni nagłówek), więc od razu zauważą spadek ruchu. (Dla innych języków mogą być potrzebne drobne modyfikacje.)
Możliwe stało się skalowanie HPA z/do zerowego ilości podów na podstawie zewnętrznych metrykJeżeli skalowanie odbywa się na podstawie obiektów/zewnętrznych metryk, to w momencie, gdy obciążenia robocze są w stanie spoczynku, można automatycznie skalować do 0 replik, aby zaoszczędzić zasoby. Ta funkcja powinna okazać się szczególnie przydatna w przypadkach, gdy workerzy żądają zasobów GPU, a liczba różnych typów bezczynnych workerów przewyższa liczbę dostępnych GPU.
Nowy klient — k8s.io/client-go/metadata.Client — do „ogólnego” dostępu do obiektów. Jest on przeznaczony do łatwego uzyskiwania metadanych (tj. podsieci metadata) z zasobów klastra i wykonywania operacji typu sprzątanie i kwotowanie.
Zbieranie Kubernetes jest teraz możliwe bez przestarzałych („wbudowanych” w in-tree) dostawców chmur (wersja alfa).
W narzędziu kubeadm dodali została dodana eksperymentalna (wersja alfa) możliwość stosowania poprawek kustomize podczas operacji init, join i upgrade. Więcej informacji na temat używania flagi --experimental-kustomize, patrz w KEP.
Nowy endpoint dla apiserver — readyz, — który pozwala na eksportowanie informacji o jego gotowości (readiness). API-server otrzymał także flagę --maximum-startup-sequence-duration, umożliwiającą regulację jego restartów.
Dwie funkcje dla Azure zostały ogłoszone stabilnymi: wsparcie dla stref dostępności (Availability Zones) oraz cross resource group (RG). Ponadto, w Azure dodano:
- wsparcie dla uwierzytelniania AAD i ADFS;
- adnotację service.beta.kubernetes.io/azure-pip-name do wskazania publicznego IP dla balancera obciążenia;
- możliwość ustawienia LoadBalancerName i LoadBalancerResourceGroup.
AWS otrzymał wsparcie dla EBS w Windows oraz optymalizacje wywołań API EC2 DescribeInstances.
Kubeadm teraz samodzielnie migracje konfiguracji CoreDNS podczas aktualizacji wersji CoreDNS.
Pliki binarne etcd w odpowiednim obrazie Docker przeprowadzili są world-executable, co pozwala na uruchamianie tego obrazu bez potrzeby posiadania uprawnień root. Ponadto, obraz migracji etcd zaprzestała obsługuje wersję etcd2.
W Cluster Autoscaler 1.16.0 przeszedł na użycie distroless jako bazowego obrazu, poprawił wydajność, dodał nowych dostawców chmur (DigitalOcean, Magnum, Packet).
Aktualizacje używanego/uzależnionego oprogramowania: Go 1.12.9, etcd 3.3.15, CoreDNS 1.6.2.

P.S.

Przeczytaj także na naszym blogu:

Źródło: habr.com

Kubernetes 1.16: przegląd głównych nowości