Kubernetes 1.14: przegląd głównych innowacji

Tej nocy odbędzie się kolejna wersja Kubernetesa - 1.14. Zgodnie z tradycją, która rozwinęła się na naszym blogu, mówimy o kluczowych zmianach w nowej wersji tego wspaniałego produktu Open Source.

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

Zacznijmy od ważnego wprowadzenia z cyklu życia klastra SIG: dynamiczne klastry pracy awaryjnej Kubernetes (a dokładniej wdrażanie HA na własnym serwerze) jest teraz dostępne możesz stworzyć przy użyciu znanych (w kontekście klastrów jednowęzłowych) poleceń kubeadm (init и join). W skrócie za to:

• certyfikaty wykorzystywane przez klaster przekazywane są do sekretów;
• za możliwość wykorzystania klastra etcd wewnątrz klastra K8s (czyli pozbycie się istniejącej wcześniej zależności zewnętrznej) operator etcd;
• Dokumentuje zalecane ustawienia zewnętrznego modułu równoważenia obciążenia zapewniającego konfigurację odporną na błędy (w przyszłości planowane jest wyeliminowanie tej zależności, ale nie na tym etapie).

Architektura klastra Kubernetes HA stworzona za pomocą kubeadm

Szczegóły realizacji można znaleźć w propozycja projektu. Ta funkcja była naprawdę długo oczekiwana: wersja alfa spodziewana była już w K8 1.9, ale pojawiła się dopiero teraz.

API

Zespół apply i ogólnie mówiąc deklaratywne zarządzanie obiektami przeszedł z kubectl w apiserverze. Sami deweloperzy krótko tłumaczą swoją decyzję tymi słowami kubectl apply - zasadniczy element pracy z konfiguracjami w Kubernetesie jednak „jest pełen błędów i trudny do naprawienia” dlatego też trzeba tę funkcjonalność przywrócić do normy i przenieść na płaszczyznę sterującą. Proste i jasne przykłady problemów, które istnieją dzisiaj:

Szczegóły dotyczące realizacji znajdują się w KEP. Obecna gotowość to alfa (promocja do wersji beta planowana jest w kolejnym wydaniu Kubernetes).

Udostępnione w wersji alfa okazja przy użyciu schematu OpenAPI v3 dla tworzenie i publikowanie dokumentacji OpenAPI dla CustomResources (CR) używany do sprawdzania (po stronie serwera) zasobów zdefiniowanych przez użytkownika K8 (CustomResourceDefinition, CRD). Publikacja OpenAPI dla CRD pozwala klientom (np. kubectl) wykonaj walidację po swojej stronie (w obrębie kubectl create и kubectl apply) i wystawiać dokumentację według schematu (kubectl explain). Szczegóły – w KEP.

Istniejące dzienniki teraz się otwierają z flagą O_APPEND (ale nie O_TRUNC), aby uniknąć utraty kłód w niektórych sytuacjach i dla wygody obcinania kłód za pomocą zewnętrznych narzędzi w celu rotacji.

Również w kontekście Kubernetes API można zauważyć, że w PodSandbox и PodSandboxStatus dodany pole runtime_handler zapisywać informacje o RuntimeClass w kapsule (więcej na ten temat przeczytasz w tekście o Wersja Kubernetesa 1.12, gdzie ta klasa pojawiła się w wersji alfa) oraz w Admission Webhooks wdrożone możliwość określenia, które wersje AdmissionReview oni wspierają. Wreszcie obowiązują zasady Admission Webhooks może być ograniczone stopień ich wykorzystania przez przestrzenie nazw i struktury klastrów.

Skarbce

PersistentLocalVolumes, który od czasu wydania miał status wersji beta K8s 1.10, ogłoszony stabilny (GA): ta bramka funkcji nie jest już wyłączona i zostanie usunięta w Kubernetes 1.17.

Okazja za pomocą zmiennych środowiskowych tzw API w dół (na przykład nazwa pod) dla nazw katalogów zamontowanych jako subPath, został opracowany – w postaci nowego pola subPathExpr, który jest teraz używany do określenia żądanej nazwy katalogu. Funkcja początkowo pojawiła się w Kubernetes 1.11, ale w wersji 1.14 pozostała w wersji alfa.

Podobnie jak w przypadku poprzedniej wersji Kubernetes, wprowadzono wiele istotnych zmian dla aktywnie rozwijającego się CSI (Container Storage Interface):

CSI

Stał się dostępny (w ramach wersji alfa) wsparcie zmiana rozmiaru woluminów CSI. Aby z niego skorzystać, musisz włączyć bramkę funkcji o nazwie ExpandCSIVolumes, a także obecność obsługi tej operacji w konkretnym sterowniku CSI.

Kolejna funkcja CSI w wersji alfa - okazja odnoszą się bezpośrednio (tj. bez użycia PV/PVC) do wolumenów CSI w specyfikacji kapsuły. Ten usuwa ograniczenie wykorzystania CSI jako wyłącznie zdalnego przechowywania danychotwierając przed nimi drzwi na świat lokalne woluminy efemeryczne. Do użycia (przykład z dokumentacji) musi być włączone CSIInlineVolume brama funkcyjna.

Nastąpił także postęp w „wewnętrznych elementach” Kubernetesa związanych z CSI, które nie są tak widoczne dla użytkowników końcowych (administratorów systemu)… Obecnie programiści zmuszeni są wspierać dwie wersje każdej wtyczki pamięci masowej: jedną – „w old way” w bazie kodu K8s (w drzewie), a drugi - w ramach nowego CSI (więcej na ten temat przeczytasz m.in tutaj). Powoduje to zrozumiałe niedogodności, którymi należy się zająć w miarę stabilizacji samego CSI. Nie jest możliwe po prostu wycofanie interfejsu API wtyczek wewnętrznych (w drzewie) z powodu odpowiednią politykę Kubernetes.

Wszystko to doprowadziło do tego, że osiągnięto wersję alfa proces migracji wewnętrzny kod wtyczki, zaimplementowane jako in-tree, we wtyczkach CSI, dzięki czemu zmartwienia programistów zostaną zredukowane do obsługi jednej wersji ich wtyczek, a kompatybilność ze starymi API pozostanie i w zwykłym scenariuszu można je uznać za przestarzałe. Oczekuje się, że do następnej wersji Kubernetes (1.15) wszystkie wtyczki dostawców usług w chmurze zostaną poddane migracji, wdrożenie otrzyma status wersji beta i będzie domyślnie aktywowane w instalacjach K8. Aby uzyskać szczegółowe informacje, zobacz propozycja projektu. Ta migracja spowodowała również brak z limitów wolumenowych określonych przez konkretnych dostawców usług chmurowych (AWS, Azure, GCE, Cinder).

Dodatkowo obsługa urządzeń blokowych z CSI (CSIBlockVolume) przeniesiony do wersji beta.

Węzły/Kubelet

Przedstawiono wersję alfa nowy punkt końcowy w Kubelecie, przeznaczony dla zwracaj wskaźniki dotyczące kluczowych zasobów. Ogólnie rzecz biorąc, jeśli wcześniej Kubelet otrzymywał statystyki wykorzystania kontenera od cAdvisor, teraz dane te pochodzą ze środowiska uruchomieniowego kontenera poprzez CRI (Container Runtime Interface), ale zachowana jest także kompatybilność do pracy ze starszymi wersjami Dockera. Wcześniej statystyki zbierane w Kubelecie przesyłane były poprzez REST API, ale teraz punkt końcowy zlokalizowany jest pod adresem /metrics/resource/v1alpha1. Długoterminowa strategia deweloperów składa się jest zminimalizowanie zestawu metryk dostarczanych przez Kubelet. Nawiasem mówiąc, same te wskaźniki teraz dzwonią nie „podstawowe wskaźniki”, ale „metryki zasobów” i są opisywane jako „zasoby pierwszej klasy, takie jak procesor i pamięć”.

Bardzo ciekawy niuans: pomimo wyraźnej przewagi wydajnościowej punktu końcowego gRPC w porównaniu z różnymi przypadkami użycia formatu Prometheus (zobacz wynik jednego z poniższych benchmarków), autorzy woleli format tekstowy Prometeusza ze względu na wyraźne przywództwo tego systemu monitorowania w społeczności.

„GRPC nie jest kompatybilny z głównymi potokami monitorowania. Endpoint będzie przydatny tylko do dostarczania metryk do Metrics Server lub komponentów monitorowania, które integrują się bezpośrednio z nim. Wydajność formatu tekstowego Prometheus podczas korzystania z buforowania na serwerze Metrics wystarczająco dobry abyśmy woleli Prometeusza od gRPC, biorąc pod uwagę szerokie przyjęcie Prometeusza w społeczności. Gdy format OpenMetrics stanie się bardziej stabilny, będziemy mogli zbliżyć się do wydajności gRPC w formacie proto”.

Jeden z porównawczych testów wydajności użycia formatów gRPC i Prometheus w nowym punkcie końcowym Kubelet dla metryk. Więcej wykresów i innych szczegółów można znaleźć w KEP.

Wśród innych zmian:

• Kubelet teraz (jeden raz) próbuję przestać kontenery w nieznanym stanie przed ponownym uruchomieniem i operacjami usuwania.
• Podczas korzystania z PodPresets teraz do kontenera init jest dodany takie same informacje jak w przypadku zwykłego pojemnika.
• kubelet zaczął używać usageNanoCores od dostawcy statystyk CRI oraz dla węzłów i kontenerów w systemie Windows dodany statystyki sieci.
• Informacje o systemie operacyjnym i architekturze są teraz zapisywane na etykietach kubernetes.io/os и kubernetes.io/arch Obiekty węzłowe (przeniesione z wersji beta do GA).
• Możliwość określenia konkretnej grupy użytkowników systemu dla kontenerów w pod (RunAsGroup, pojawił się w K8s 1.11) zaawansowany przed wersją beta (domyślnie włączone).
• du i znajdź używane w cAdvisor, zastąpiony wdrożenie w Go.

CLI

W środowisku wykonawczym cli i kubectl dodany -k flaga do integracji z dostosować (nawiasem mówiąc, jego rozwój odbywa się teraz w osobnym repozytorium), tj. do przetwarzania dodatkowych plików YAML ze specjalnych katalogów kustomizacji (więcej informacji na temat ich używania znajdziesz w KEP):

Przykład prostego użycia pliku dostosowywanie (możliwe jest bardziej złożone zastosowanie kustomize Nakładki)

Ponadto:

• Dodany Nowa drużyna kubectl create cronjob, którego nazwa mówi sama za siebie.
• В kubectl logs teraz możesz łączyć flagi -f (--follow do przesyłania strumieniowego dzienników) i -l (--selector dla zapytania o etykietę).
• kubectl nauczał skopiuj pliki wybrane za pomocą symbolu wieloznacznego.
• Do zespołu kubectl wait dodany flaga --all aby wybrać wszystkie zasoby w przestrzeni nazw określonego typu zasobu.

Inne

Następujące możliwości otrzymały status stabilny (GA):

• ReadinessGate, używany w specyfikacji kapsuły do ​​określenia dodatkowych warunków branych pod uwagę przy gotowości kapsuły;
• Obsługa dużych stron (brama funkcji tzw HugePages);
• NiestandardowyPodDNS;
• Interfejs API klasy priorytetowej Priorytet i wywłaszczanie podów.

Inne zmiany wprowadzone w Kubernetes 1.14:

• Domyślne zasady RBAC nie umożliwiają już dostępu do interfejsu API discovery и access-review użytkowników bez uwierzytelnienia (nieuwierzytelnione).
• Oficjalna obsługa CoreDNS ubezpieczony Tylko Linux, więc w przypadku korzystania z kubeadm do wdrożenia go (CoreDNS) w klastrze węzły mogą działać tylko w systemie Linux (w tym ograniczeniu używane są selektory węzłów).
• Domyślna konfiguracja CoreDNS jest teraz używa wtyczka do przodu zamiast proxy. Również w CoreDNS dodany ReadinessProbe, który zapobiega równoważeniu obciążenia na odpowiednich (niegotowych do obsługi) podach.
• W kubeadm, na fazach init lub upload-certs, stało się możliwe załaduj certyfikaty wymagane do połączenia nowej płaszczyzny kontrolnej z sekretem kubeadm-certs (użyj flagi --experimental-upload-certs).
• Pojawiła się wersja alfa dla instalacji Windows wsparcie gMSA (Group Managed Service Account) – specjalne konta w Active Directory, z których mogą korzystać także kontenery.
• Dla G.C.E. aktywowany Szyfrowanie mTLS pomiędzy etcd i kube-apiserver.
• Aktualizacje używanego/zależnego oprogramowania: Go 1.12.1, CSI 1.1, CoreDNS 1.3.1, obsługa Docker 18.09 w kubeadm, a minimalna obsługiwana wersja Docker API to teraz 1.26.

PS

Przeczytaj także na naszym blogu:

• «Kubernetes 1.13: przegląd głównych innowacji";
• «Kubernetes 1.12: przegląd głównych innowacji";
• «Kubernetes 1.11: przegląd głównych innowacji";
• «Kubernetes 1.10: przegląd głównych innowacji".

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