🥇Kubernetes 1.16: przegląd głównych innowacji

Dziś, w środę, odbędzie się kolejne wydanie Kubernetesa - 1.16. Zgodnie z tradycją, która rozwinęła się dla naszego bloga, to już dziesiąta rocznica, kiedy mówimy o najważniejszych zmianach w nowej wersji.

Informacje użyte do przygotowania tego materiału pochodzą z Tabele śledzenia ulepszeń Kubernetesa, DZIENNIK ZMIAN-1.16 i powiązane problemy, żądania ściągnięcia i propozycje ulepszeń Kubernetes (KEP). Więc chodźmy!..

Węzły

Naprawdę dużą liczbę godnych uwagi innowacji (w statusie wersji alfa) zaprezentowano po stronie węzłów klastra K8s (Kubelet).

Po pierwsze, tzw «efemeryczne pojemniki» (Pojemniki efemeryczne), zaprojektowany w celu uproszczenia procesów debugowania w zasobnikach. Nowy mechanizm pozwala na uruchamianie specjalnych kontenerów, które rozpoczynają się w przestrzeni nazw istniejących podów i żyją przez krótki czas. Ich celem jest interakcja z innymi podami i kontenerami w celu rozwiązywania problemów i debugowania. Dla tej funkcji zaimplementowano nowe polecenie kubectl debug, w istocie podobny do kubectl exec: tylko zamiast uruchamiać proces w kontenerze (jak w exec) uruchamia kontener w kapsule. Na przykład to polecenie połączy nowy kontener z kapsułą:

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

Szczegóły na temat pojemników efemerycznych (i przykłady ich użycia) znajdziesz w odpowiedni KEP. Obecna implementacja (w K8s 1.16) jest wersją alfa i wśród kryteriów jej przejścia do wersji beta znajduje się „testowanie interfejsu Ephemeral Containers API dla co najmniej 2 wydań [Kubernetes]”.

NB: W swojej istocie, a nawet nazwie, funkcja przypomina już istniejącą wtyczkę kubectl-debugo którym my już napisałem. Oczekuje się, że wraz z pojawieniem się efemerycznych kontenerów rozwój osobnej wtyczki zewnętrznej zakończy się.

Kolejna innowacja - PodOverhead - zaprojektowany, aby zapewnić mechanizm obliczania kosztów ogólnych dla podów, które mogą się znacznie różnić w zależności od używanego środowiska wykonawczego. Jako przykład autorzy ten KEP skutkują kontenerami Kata, które wymagają uruchomienia jądra gościa, agenta kata, systemu init itp. Kiedy koszty ogólne stają się tak duże, nie można ich zignorować, co oznacza, że musi istnieć sposób uwzględnienia ich przy ustalaniu dalszych limitów, planowaniu itp. Aby to wdrożyć w PodSpec pole dodane Overhead *ResourceList (w porównaniu z danymi w RuntimeClass, jeśli jest używany).

Kolejną godną uwagi innowacją jest menedżer topologii węzłów (Menedżer topologii węzłów), mający na celu ujednolicenie podejścia do dostrajania alokacji zasobów sprzętowych dla różnych komponentów w Kubernetesie. Inicjatywa ta wynika z rosnącego zapotrzebowania na różnorodne nowoczesne systemy (z zakresu telekomunikacji, uczenia maszynowego, usług finansowych itp.) na wysokowydajne obliczenia równoległe i minimalizację opóźnień w realizacji operacji, do których wykorzystują zaawansowane procesory i możliwości akceleracji sprzętowej. Takie optymalizacje w Kubernetesie były dotychczas osiągane dzięki odmiennym komponentom (menedżer procesora, menedżer urządzeń, CNI), a teraz zostanie dodany pojedynczy wewnętrzny interfejs, który ujednolica podejście i upraszcza podłączanie nowych podobnych – tzw. topologii- świadomy - komponenty po stronie Kubelet. Szczegóły – w odpowiedni KEP.

Schemat komponentów Menedżera topologii

Następna funkcja — sprawdzanie kontenerów w trakcie ich pracy (sonda startowa). Jak wiadomo, w przypadku kontenerów, których uruchomienie zajmuje dużo czasu, trudno jest uzyskać aktualny status: albo zostają „zabite”, zanim faktycznie zaczną działać, albo przez długi czas znajdują się w impasie. Nowe sprawdzenie (włączone przez bramkę funkcji o nazwie StartupProbeEnabled) anuluje – lub raczej odkłada – efekt wszelkich innych kontroli do momentu, w którym kapsuła zakończy działanie. Z tego powodu funkcja ta została pierwotnie nazwana wstrzymanie sondy żywotności pod-uruchamiania. W przypadku zasobników, których uruchomienie zajmuje dużo czasu, można sondować stan w stosunkowo krótkich odstępach czasu.

Ponadto ulepszenie RuntimeClass jest natychmiast dostępne w wersji beta, dodając obsługę „klastrów heterogenicznych”. C Planowanie klas wykonawczych Teraz nie jest wcale konieczne, aby każdy węzeł obsługiwał każdą klasę RuntimeClass: w przypadku podów możesz wybrać klasę RuntimeClass bez myślenia o topologii klastra. Wcześniej, aby to osiągnąć – aby pody trafiały na węzły ze wsparciem wszystkiego, czego potrzebują – konieczne było przypisanie odpowiednich reguł do NodeSelectora i tolerancji. W KEP Opowiada o przykładach użycia i oczywiście szczegółach implementacji.

Sieć

Dwie istotne 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 odpowiadające mu „zrozumienie” na poziomie podów, węzłów, usług. Obejmuje interoperacyjność IPv4 na IPv4 i IPv6 na IPv6 pomiędzy podami, od podów po usługi zewnętrzne, implementacje referencyjne (w ramach wtyczek Bridge CNI, PTP CNI i Host-Local IPAM), a także odwrotność. Zgodność z działającymi klastrami Kubernetes Tylko IPv4 lub IPv6. Szczegóły realizacji są w środku KEP.
Przykład wyświetlenia adresów IP dwóch typów (IPv4 i IPv6) na liście podów:
```
kube-master# kubectl get pods -o wide
NAME               READY     STATUS    RESTARTS   AGE       IP                          NODE
nginx-controller   1/1       Running   0          20m       fd00:db8:1::2,192.168.1.3   kube-minion-1
kube-master#
```
Nowe API dla punktu końcowego - Interfejs API EndpointSlice. Rozwiązuje problemy z wydajnością/skalowalnością istniejącego Endpoint API, które wpływają na różne komponenty na płaszczyźnie kontrolnej (apiserver, itp., kontroler punktów końcowych, kube-proxy). Nowe API zostanie dodane do grupy Discovery API i będzie w stanie obsłużyć dziesiątki tysięcy backendowych punktów końcowych w każdej usłudze w klastrze składającym się z tysięcy węzłów. W tym celu każda usługa jest mapowana na N obiektów EndpointSlice, z których każdy domyślnie ma nie więcej niż 100 punktów końcowych (wartość można konfigurować). EndpointSlice API zapewni także możliwości jego przyszłego rozwoju: obsługę wielu adresów IP dla każdego podu, nowe stany dla punktów końcowych (nie tylko Ready и NotReady), dynamiczne podzbiór punktów końcowych.

Ta zaprezentowana w ostatniej wersji osiągnęła wersję beta finalizator, o imieniu service.kubernetes.io/load-balancer-cleanup i dołączone do każdej usługi z typem LoadBalancer. W momencie usunięcia takiej usługi uniemożliwia ona faktyczne usunięcie zasobu do czasu zakończenia „czyszczenia” wszystkich odpowiednich zasobów Balancera.

Maszyny API

Prawdziwym „kamieniem milowym stabilizacji” jest obszar serwera Kubernetes API i interakcja z nim. Stało się to w dużej mierze dzięki przeniesienie do statusu stabilnego tych, którzy nie potrzebują specjalnego wprowadzenia Niestandardowe definicje zasobów (CRD), które miały status beta od czasów Kubernetesa 1.7 (a to jest czerwiec 2017!). Ta sama stabilizacja dotyczyła powiązanych funkcji:

"podzasoby" poprzez /status и /scale dla zasobów niestandardowych;
transformacja wersje dla CRD, oparte na zewnętrznym webhooku;
niedawno zaprezentowany (w K8s 1.15) wartości domyślne (domyślnie) i automatyczne usuwanie pola (przycinanie) dla zasobów niestandardowych;
okazja wykorzystanie schematu OpenAPI v3 do tworzenia i publikowania dokumentacji OpenAPI służącej do walidacji zasobów CRD po stronie serwera.

Kolejny mechanizm, który od dawna jest znany administratorom Kubernetesa: webhook wstępu - również pozostawał w wersji beta przez długi czas (od K8s 1.9) i obecnie jest uznany za stabilny.

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

Jedyną znaczącą innowacją w wersji alfa była brak od SelfLink — specjalny URI reprezentujący określony obiekt i będący jego częścią ObjectMeta и ListMeta (tj. część dowolnego obiektu w Kubernetesie). Dlaczego to porzucają? Motywacja w prosty sposób brzmi jako brak rzeczywistych (przytłaczających) powodów, dla których ta dziedzina nadal istnieje. Powody bardziej formalne to optymalizacja wydajności (poprzez usunięcie niepotrzebnego pola) oraz uproszczenie pracy generycznego-apiservera, który zmuszony jest do obsługi takiego pola w specjalny sposób (jest to jedyne pole, które jest ustawiane tuż przed obiektem jest serializowany). Prawdziwe starzenie się (w wersji beta) SelfLink stanie się to w wersji Kubernetes 1.20, a finalnej – 1.21.

Przechowywanie danych

Główne prace w obszarze magazynowania, podobnie jak w poprzednich odsłonach, obserwuje się w okolicy Wsparcie CSI. Główne zmiany tutaj były następujące:

po raz pierwszy (w wersji alfa) pojawił się Obsługa wtyczek CSI dla węzłów roboczych systemu Windows: obecny sposób pracy z pamięcią masową zastąpi także wtyczki in-tree w rdzeniu Kubernetes oraz wtyczki FlexVolume firmy Microsoft oparte na Powershell;

Schemat implementacji wtyczek CSI w Kubernetes dla Windows
okazja zmiana rozmiaru woluminów CSI, wprowadzony w K8s 1.12, urósł do wersji beta;
Podobną „promocję” (z wersji alfa do wersji beta) osiągnięto dzięki możliwości wykorzystania CSI do tworzenia lokalnych wolumenów efemerycznych (Obsługa głośności w trybie CSI Inline).

Wprowadzono w poprzedniej wersji Kubernetes funkcja klonowania woluminów (przy użyciu istniejącego PCV jako DataSource do tworzenia nowego PVC) również otrzymało status wersji beta.

Planista

Dwie znaczące zmiany w harmonogramie (obie w wersji alfa):

EvenPodsSpreading - możliwość używaj zasobników zamiast logicznych jednostek aplikacji w celu „sprawiedliwego podziału” obciążeń (jak Deployment i ReplicaSet) i dostosowanie tej dystrybucji (jako twarde wymaganie lub jako warunek miękki, tj. priorytet). Ta funkcja rozszerzy istniejące możliwości dystrybucji planowanych podów, obecnie ograniczone opcjami PodAffinity и PodAntiAffinity, dając administratorom lepszą kontrolę w tym zakresie, co oznacza lepszą wysoką dostępność i zoptymalizowane zużycie zasobów. Szczegóły – w KEP.
Używać Polityka BestFit в Funkcja priorytetu RequestedToCapacityRatio podczas planowania strąków, co pozwoli zastosuj pakowanie do kosza („pakowanie w kontenery”) zarówno zasobów podstawowych (procesor, pamięć), jak i rozszerzonych (np. GPU). Więcej szczegółów znajdziesz w KEP.

Planowanie podów: przed użyciem polityki najlepszego dopasowania (bezpośrednio poprzez domyślny harmonogram) i podczas jej użycia (poprzez moduł harmonogramu)

RљSЂRѕRјRμ S, RѕRіRѕ, reprezentowany przez możliwość tworzenia własnych wtyczek harmonogramujących poza głównym drzewem programistycznym Kubernetes (poza drzewem).

Inne zmiany

Można to zauważyć również w wydaniu Kubernetes 1.16 inicjatywa dla przynoszący dostępne metryki w pełnej kolejności, a dokładniej zgodnie z oficjalne przepisy do oprzyrządowania K8. W dużej mierze opierają się na odpowiednich Dokumentacja Prometeusza. Niespójności powstały z różnych powodów (np. niektóre metryki zostały po prostu stworzone przed pojawieniem się aktualnych instrukcji), a twórcy uznali, że nadszedł czas, aby wszystko ujednolicić w jeden standard, „zgodny z resztą ekosystemu Prometheus”. Obecne wdrożenie tej inicjatywy jest w fazie alfa, która będzie stopniowo promowana w kolejnych wersjach Kubernetesa do wersji beta (1.17) i stabilnej (1.18).

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

Rozwój obsługi systemu Windows с wygląd Narzędzia Kubeadm dla tego systemu operacyjnego (wersja alfa), możliwość RunAsUserName dla kontenerów Windows (wersja alfa), poprawa Obsługa konta usług zarządzanych przez grupę (gMSA) aż do wersji beta, wsparcie zamontuj/dołącz dla woluminów vSphere.
Z recyklingu mechanizm kompresji danych w odpowiedziach API. Wcześniej do tych celów wykorzystywano filtr HTTP, który narzucał szereg ograniczeń uniemożliwiających jego domyślne włączenie. „Przejrzysta kompresja żądań” teraz działa: klienci wysyłają Accept-Encoding: gzip w nagłówku otrzymują odpowiedź skompresowaną w formacie GZIP, jeśli jej rozmiar przekracza 128 KB. Klienci Go automatycznie obsługują kompresję (wysyłanie wymaganego nagłówka), dzięki czemu od razu zauważą zmniejszenie ruchu. (W przypadku innych języków mogą być potrzebne niewielkie modyfikacje.)
Stało się możliwe skalowanie HPA od/do zerowych podów w oparciu o metryki zewnętrzne. Jeśli skalujesz w oparciu o obiekty/metryki zewnętrzne, gdy obciążenia są bezczynne, możesz automatycznie skalować do 0 replik, aby oszczędzać zasoby. Ta funkcja powinna być szczególnie przydatna w przypadkach, gdy pracownicy żądają zasobów GPU, a liczba różnych typów bezczynnych procesów roboczych przekracza liczbę dostępnych procesorów graficznych.
Nowy klient - k8s.io/client-go/metadata.Client — dla „uogólnionego” dostępu do obiektów. Ma na celu łatwe pobieranie metadanych (tj. podsekcji metadata) z zasobów klastra i wykonywać na nich operacje usuwania elementów bezużytecznych i przydziałów.
Zbuduj Kubernetesa teraz możesz bez starszych („wbudowanych” w drzewo) dostawców usług w chmurze (wersja alfa).
Do narzędzia kubeadm dodany eksperymentalna (wersja alfa) możliwość stosowania łatek dostosowanych podczas operacji init, join и upgrade. Dowiedz się więcej o tym, jak używać flagi --experimental-kustomize, widzieć w KEP.
Nowy punkt końcowy dla apiserver - readyz, - umożliwia eksport informacji o jego gotowości. Serwer API również ma teraz flagę --maximum-startup-sequence-duration, co pozwala regulować jego ponowne uruchomienie.
dwa funkcje dla platformy Azure zadeklarowany jako stabilny: wsparcie strefy dostępności (Strefy dostępności) i międzygrupowa grupa zasobów (RG). Ponadto Azure dodał:
- wsparcie uwierzytelniania AAD i ADFS;
- adnotacja service.beta.kubernetes.io/azure-pip-name aby określić publiczny adres IP modułu równoważenia obciążenia;
- okazja настройки LoadBalancerName и LoadBalancerResourceGroup.
AWS teraz ma wsparcie dla EBS w systemie Windows i zoptymalizowany Wywołania API EC2 DescribeInstances.
Kubeadm jest teraz niezależny migruje Konfiguracja CoreDNS podczas aktualizacji wersji CoreDNS.
Pliki binarne itd w odpowiednim obrazie Dockera zrobiłem world-executable, który pozwala na uruchomienie tego obrazu bez konieczności posiadania praw roota. Również obraz migracji itp przestał obsługa wersji etcd2.
В Automatyczne skalowanie klastrów 1.16.0 przełączył się na używanie Distroless jako obrazu podstawowego, poprawił wydajność, dodał nowych dostawców usług w chmurze (DigitalOcean, Magnum, Packet).
Aktualizacje używanego/zależnego oprogramowania: Go 1.12.9, etcd 3.3.15, CoreDNS 1.6.2.

PS

Przeczytaj także na naszym blogu:

Źródło: www.habr.com

Kubernetes 1.16: przegląd głównych innowacji