Wczoraj, 9 grudnia, odbyła się kolejne wydanie Kubernetesa - 1.17. Zgodnie z tradycją, która rozwinęła się na naszym blogu, mówimy o najważniejszych zmianach w nowej wersji.
Informacje użyte do przygotowania niniejszego materiału pochodzą z oficjalnego komunikatu, Tabele śledzenia ulepszeń Kubernetesa, DZIENNIK ZMIAN-1.17 i powiązane problemy, żądania ściągnięcia i propozycje ulepszeń Kubernetes (KEP). Więc co nowego?..
Routing uwzględniający topologię
Społeczność Kubernetes czekała na tę funkcję od dawna - Routing usług uwzględniający topologię. Jeśli KEP pochodzi z października 2018 r. i jest oficjalny wzmocnienie — 2 lata temu, zwykłe problemy (tak jak to) - i jeszcze kilka lat starszy...
Ogólną ideą jest zapewnienie możliwości implementacji „lokalnego” routingu dla usług rezydujących w Kubernetesie. „Lokalność” w tym przypadku oznacza „ten sam poziom topologiczny” (poziom topologii), Które może być:
węzeł identyczny dla usług,
ta sama szafa serwerowa,
ten sam region
ten sam dostawca usług w chmurze,
...
Przykłady wykorzystania tej funkcji:
oszczędności na ruchu w instalacjach chmurowych z wieloma strefami dostępności (multi-AZ) – patrz. świeża ilustracja na przykładzie ruchu z tego samego regionu, ale różnych AZ w AWS;
mniejsze opóźnienia wydajności/lepsza przepustowość;
usługa dzielona, która zawiera lokalne informacje o węźle w każdym fragmencie;
umieszczenie fluentd (lub analogów) w tym samym węźle z aplikacjami, których logi są gromadzone;
Aby uzyskać szczegółowe informacje na temat działania tej funkcji i sposobu, w jaki można już z niej korzystać, przeczytaj ten artykuł od jednego z autorów.
Obsługa podwójnego stosu IPv4/IPv6
Znaczący postęp naprawił w innej funkcji sieciowej: jednoczesna obsługa dwóch stosów IP, która została po raz pierwszy wprowadzona w K8s 1.16. W szczególności nowe wydanie przyniosło następujące zmiany:
w kube-proxy wdrożone możliwość jednoczesnej pracy w obu trybach (IPv4 i IPv6);
в Pod.Status.PodIPspojawił się obsługa API w dół (w tym samym czasie co w /etc/hosts teraz wymagają od hosta dodania adresu IPv6);
obsługa podwójnego stosu UPRZEJMY (Kubernetes IN Docker) i kubeadm;
zaktualizowane testy e2e.
Ilustracja przy użyciu podwójnego stosu IPV4/IPv6 w KIND
Postęp w CSI
Deklarowany jako stabilny obsługa topologii do przechowywania danych w oparciu o CSI, wprowadzony po raz pierwszy w K8s 1.12.
Inicjatywa dla migracja wtyczek wolumenowych do CSI - Migracja CSI - osiągnięto wersję beta. Ta funkcja ma kluczowe znaczenie przy tłumaczeniu istniejących wtyczek pamięci masowej (w drzewie) do nowoczesnego interfejsu (CSI, poza drzewem) niewidoczny dla użytkowników końcowych Kubernetes. Administratorzy klastrów będą musieli jedynie włączyć CSI Migration, po czym istniejące zasoby stanowe i obciążenia będą nadal „po prostu działać”… ale korzystając z najnowszych sterowników CSI zamiast przestarzałych zawartych w rdzeniu Kubernetes.
W tej chwili migracja sterowników AWS EBS jest gotowa w wersji beta (kubernetes.io/aws-ebs) i GCE PD (kubernetes.io/gce-pd). Prognozy dla pozostałych obiektów magazynowych przedstawiają się następująco:
Rozmawialiśmy o tym, jak „tradycyjna” obsługa pamięci masowej w K8 pojawiła się w CSI ten artykuł. I dedykowane jest przejście migracji CSI do statusu beta osobna publikacja na blogu projektu.
Dodatkowo kolejna istotna funkcjonalność w kontekście CSI, która wywodzi się (implementacja alfa) w K1.17s 8, osiągnęła status beta (tj. domyślnie włączona) w wydaniu Kubernetes 1.12 - tworzenie migawek i wyzdrowienie z nich. Wśród zmian wprowadzonych w Kubernetes Volume Snapshot w drodze do wersji beta:
podzielenie wózka bocznego z zewnętrznym migawką CSI na dwa kontrolery,
dodano sekret do usunięcia (tajemnica usunięcia) jako adnotacja do zawartości migawki woluminu,
nowy finalizator (finalizator) aby zapobiec usunięciu obiektu API migawki, jeśli istnieją pozostałe połączenia.
W chwili wydania 1.17 funkcja jest obsługiwana przez trzy sterowniki CSI: sterownik CSI GCE Persistent Disk, sterownik Portworx CSI i sterownik CSI NetApp Trident. Więcej szczegółów na temat jego wdrożenia i stosowania można znaleźć w tę publikację na blogu.
Etykiety dostawcy chmury
Oznacza to automatycznie przypisane do utworzonych węzłów i woluminów w zależności od używanego dostawcy chmury, są dostępne w Kubernetesie w wersji beta już od bardzo dawna – od wydania K8s 1.2 (kwiecień 2016!). Biorąc pod uwagę ich szerokie zastosowanie przez tak długi czas, programiści zdecydowany, że nadszedł czas, aby ogłosić, że funkcja jest stabilna (GA).
Dlatego wszystkie zostały odpowiednio przemianowane (według topologii):
... ale nadal są dostępne pod starymi nazwami (w celu zapewnienia kompatybilności wstecznej). Jednak wszystkim administratorom zaleca się przejście na obecne etykiety. Powiązana dokumentacja K8s został zaktualizowany.
Chociaż Kubernetes można wdrożyć ręcznie, de facto (jeśli nie de iure) standardem dla tej operacji jest użycie kubeadm. Popularne narzędzia do zarządzania systemami, takie jak Terraform, korzystają z kubeadm przy wdrażaniu Kubernetes. Planowane ulepszenia interfejsu Cluster API obejmują komponowalny pakiet do ładowania Kubernetes za pomocą kubeadm i cloud-init.
Bez uporządkowanego wyjścia nawet najbardziej nieszkodliwe zmiany na pierwszy rzut oka mogą zepsuć Terraform, Cluster API i inne oprogramowanie korzystające z wyników kubeadm.
Nasze najbliższe plany obejmują obsługę (w formie ustrukturyzowanych wyników) następujących poleceń kubeadm:
alpha certs
config images list
init
token create
token list
upgrade plan
version
Ilustracja odpowiedzi JSON na polecenie kubeadm init -o json:
Generalnie wydanie Kubernetesa 1.17 odbyło się pod hasłem „stabilność" Ułatwiło to fakt, że wiele zawartych w nim funkcji (ich łączna liczba wynosi 14) otrzymał status GA. Pomiędzy nimi:
Obejrzyj Zakładki - nowy typ wydarzeń, które mają etykietę informującą, że wszystkie obiekty są do określonej wersji (resourceVersion) zostały już przetworzone przez zegarek;
„ochrona finalizatora” (Ochrona finalizatora) dla modułów równoważenia obciążenia (sprawdzanie odpowiednich zasobów Usługi przed usunięciem zasobów LoadBalancer);
optymalizacja kube-apiserver wydajność podczas pracy z wieloma zegarkami monitorującymi identyczne zestawy obiektów - osiągnięta poprzez uniknięcie powtarzającej się serializacji tych samych obiektów dla każdego obserwatora.
Inne zmiany
Pełna lista nowości w Kubernetesie 1.17 nie ogranicza się oczywiście do tych wymienionych powyżej. Oto kilka innych (a pełniejsza lista znajduje się w CHANGELOG):
podobna zmiana przydarzyło się EndpointSlice API (również od K8s 1.16), jednak na razie to rozwiązanie poprawiające wydajność/skalowalność Endpoint API nie jest domyślnie włączone;
zasobniki mają teraz kluczowe znaczenie dla działania klastra można stworzyć nie tylko w przestrzeniach nazw kube-system(szczegółowe informacje można znaleźć w dokumentacji dot Ogranicz zużycie klasy priorytetowej);
nowa opcja dla kubelet - --reserved-cpus — umożliwia jednoznaczne zdefiniowanie listy procesorów zarezerwowanych dla systemu;
dla kubectl logsprzedstawione nowa flaga --prefix, dodając nazwę poda i kontenera źródłowego do każdej linii dziennika;