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

Tej nocy odbędzie się kolejna wersja Kubernetes — 1.14. Zgodnie z tradycją naszego bloga, opowiemy o kluczowych zmianach w nowej wersji tego wspaniałego produktu Open Source.

Informacje użyte do przygotowania tego materiału pochodzą z tabeli śledzenia ulepszeń Kubernetes, CHANGELOG-1.14 i odpowiednich zgłoszeniach, pull requestach, propozycjach ulepszeń Kubernetes (KEP).

Zacznijmy od ważnego wprowadzenia od SIG cluster-lifecycle: dynamiczne klastry odporne na awarie Kubernetes (a mówiąc dokładniej, self-hosted HA deployments) można teraz tworzyć za pomocą znanych (w kontekście klastrów z jednym węzłem) komend kubeadm (init i join). Krótko mówiąc, w tym celu:

• certyfikaty używane przez klaster są przenoszone do tajemnic;
• aby umożliwić korzystanie z klastru etcd wewnątrz klastra K8s (tj. pozbycie się dotychczasowej zewnętrznej zależności), wdrożono etcd-operator;
• dokumentowane są zalecane ustawienia dla zewnętrznego load balancera, który zapewnia konfigurację odporną na awarie (w przyszłości planuje się możliwość rezygnacji z tej zależności, ale nie na tym etapie).

Architektura klastra HA Kubernetes, stworzonego z kubeadm

Szczegóły dotyczące wdrożenia można znaleźć w propozycji projektowej. Ta funkcja była naprawdę długo oczekiwana: wersja alfa była oczekiwana już w K8s 1.9, ale pojawiła się dopiero teraz.

API

Zespół apply i w ogóle deklaratywne zarządzanie obiektami wyrzucone z kubectl w apiserverze. Sami deweloperzy krótko wyjaśniają swoje rozwiązanie tym, że kubectl apply jest podstawowym elementem pracy z konfiguracjami w Kubernetes, jednak „jest pełne błędów i trudno poddaje się poprawkom”, dlatego tę funkcjonalność należy doprowadzić do porządku i przenieść do control plane. Proste i przejrzyste przykłady istniejących dzisiaj problemów:

Szczegóły dotyczące wdrożenia znajdują się w KEP. Bieżąca gotowość — wersja alfa (promocja do bety planowana jest na następne wydanie Kubernetes).

W wersji alfa udostępniono możliwość użycie schemy OpenAPI v3 do tworzenia i publikowania dokumentacji OpenAPI dla CustomResources (CR), które są używane do walidacji (po stronie serwera) zasobów K8s definiowanych przez użytkownika (CustomResourceDefinition, CRD). Publikacja OpenAPI dla CRD pozwala klientom (na przykład, kubectl) przeprowadzać walidację po swojej stronie (w ramach kubectl create i kubectl apply) oraz dostarczać dokumentację dotyczącą schemy (kubectl explain). Szczegóły — w KEP.

Istniejące wcześniej logi są teraz otwierane z flagą O_APPEND (a nie O_TRUNC) aby uniknąć utraty logów w niektórych sytuacjach oraz dla wygody truncowania logów za pomocą zewnętrznych narzędzi do rotacji.

W kontekście API Kubernetes można również zauważyć, że PodSandbox i PodSandboxStatus dodano pole runtime_handler dla uwzględnienia informacji o RuntimeClass podzie (więcej na ten temat można przeczytać w tekście o wydaniu Kubernetes 1.12, gdzie ta klasa została wprowadzona jako wersja alfa), a w Admission Webhooks zrealizowano istnieje możliwość określenia, które wersje AdmissionReview są wspierane. W końcu w zasadach Admission Webhooks można teraz ograniczać zakres ich stosowania za pomocą namespace'ów i ram klastra.

Przechowalnie

PersistentLocalVolumes, które miały status wersji beta od wydania K8s 1.10, zostały ogłoszone stabilnymi (GA): ta brama cechowa nie jest już wyłączana i zostanie usunięta w Kubernetes 1.17.

Możliwość użycia zmiennych środowiskowych tzw. Downward API (na przykład, nazwy pod'a) do nazw katalogów montowanych jako subPath, zyskała rozwój — w postaci nowego pola subPathExpr, za pomocą którego teraz określa się potrzebną nazwę katalogu. Ta funkcja pojawiła się pierwotnie w Kubernetes 1.11, ale pozostała w statusie wersji alfa dla 1.14.

Podobnie jak w poprzednim wydaniu Kubernetes, wprowadzono wiele znaczących zmian dla prężnie rozwijającego się CSI (Container Storage Interface):

CSI

Stała się dostępna (w ramach wersji alfa) wsparcie zmiana rozmiaru dla woluminów CSI. Aby z niej skorzystać, trzeba włączyć bramę cechową pod nazwą ExpandCSIVolumes, a także zapewnić wsparcie tej operacji w konkretnym sterowniku CSI.

Jeszcze jedna funkcja dla CSI w wersji alfa — możliwość bezpośrednie odniesienie (czyli bez użycia PV/PVC) do woluminów CSI w specyfikacji pod'ów. To usuwa ograniczenie w stosowaniu CSI jako wyłącznie zdalnych przechowalni danych, otwierając przed nimi drzwi do świata local ephemeral volumes. Aby z niej skorzystać (przykład z dokumentacji) należy włączyć CSIInlineVolume bramę cechową.

Zauważono postęp także we „wnętrzach” Kubernetes, których zmiany dotyczące CSI nie są tak zauważalne dla ostatecznych użytkowników (administratorów systemów)… Obecnie programiści zmuszeni są utrzymywać dwie wersje każdej wtyczki przechowalni: jedna — „w starym stylu”, wewnątrz bazy kodu K8s (in-tree), a druga — w ramach nowego CSI (więcej na ten temat przeczytaj, na przykład, w tutaj). To powoduje zrozumiałe niedogodności, które należy usunąć w miarę stabilizacji CSI jako całości. Po prostu ogłoszenie wewnętrznych (in-tree) API wtyczek jako przestarzałych (deprecated) nie jest możliwe z powodu odpowiedniej polityki Kubernetes.

Wszystko to doprowadziło do tego, że wersje alfa osiągnęły proces migracji wewnętrznego kodu wtyczek, realizowanych jako in-tree, w wtyczkach CSI, dzięki czemu troski programistów będą ograniczone do wspierania jednej wersji ich wtyczek, a zgodność ze starymi interfejsami API zostanie zachowana i będą mogły być uznane za przestarzałe według normalnego scenariusza. Oczekuje się, że do następnej wersji Kubernetes (1.15) nastąpi migracja wszystkich wtyczek dostawców chmur, implementacja uzyska status wersji beta i zostanie aktywowana w instalacjach K8s domyślnie. Szczegóły w propozycji projektowej. Następstwem tej migracji było także rezygnacja zniesienie ograniczeń dla wolumenów określonych przez konkretne dostawców chmur (AWS, Azure, GCE, Cinder).

Ponadto, wsparcie dla urządzeń blokowych z CSI (CSIBlockVolume) wprowadzono do wersji beta.

Węzły / Kubelet

Zaprezentowano wersję alfa nowego endpointu w Kubelet, przeznaczonego do przekazywania metryk dotyczących podstawowych zasobów. Ogólnie rzecz biorąc, jeśli wcześniej Kubelet otrzymywał statystyki dotyczące użycia kontenerów z cAdvisor, to teraz dane te pochodzą z środowiska wykonywalnego kontenera przez CRI (Container Runtime Interface), jednak zachowano również zgodność z wcześniejszymi wersjami Dockera. Statystyki zebrane w Kubelet były wcześniej przekazywane przez REST API, a teraz do tego celu używany jest endpoint zlokalizowany pod adresem /metrics/resource/v1alpha1. Długoterminową strategią programistów polega jest minimalizacja zestawu metryk, które Kubelet udostępnia. Notabene, te metryki nazwano teraz nie «core metrics», ale «resource metrics», i opisują jako «pierwszorzędne zasoby, takie jak CPU i pamięć».

Bardzo ciekawy niuans: mimo wyraźnej przewagi wydajności endpointu gRPC w porównaniu z różnymi użyciami formatu Prometheus wynik jednego z benchmarkingów znajdziesz poniżej, autorzy preferowali tekstowy format Prometheus ze względu na wyraźne prowadzenie tego systemu monitorowania w społeczności.

«gRPC nie jest zgodny z głównymi pipeline'ami monitorowania. Endpoint ten będzie użyteczny tylko do dostarczania metryk do Metrics Server lub komponentów monitorowania, które integrują się bezpośrednio z nim. Przy użyciu pamięci podręcznej w Metrics Server wydajność tekstowego formatu Prometheus jest wystarczająco dobra abyśmy wybrali Prometheus zamiast gRPC, biorąc pod uwagę szeroką popularność Prometheus w społeczności. Gdy format OpenMetrics stanie się bardziej stabilny, będziemy mogli zbliżyć się do wydajności gRPC przy użyciu formatu opartego na proto.

Jednym z porównawczych testów wydajności korzystania z formatów gRPC i Prometheus w nowym endpoint’cie Kubelet do metryk. Więcej wykresów i innych szczegółów można znaleźć w KEP.

Wśród innych zmian:

• Kubelet teraz (jednorazowo) próbuje zatrzymać kontenery w stanie nieznanym (unknown) przed operacjami restartu i usunięcia.
• Podczas korzystania z PodPresets teraz init-kontenerowi . Aby pozbyć się tej dodatkowej ścieżki, postanowiliśmy dodać ta sama informacja, co dla zwykłego kontenera.
• Kubelet zaczął używać usageNanoCores z dostawcy statystyk CRI, a dla węzłów i kontenerów w Windows dodano statystyka sieciowa.
• Informacja o systemie operacyjnym i architekturze jest teraz zapisywana w etykietach kubernetes.io/os i kubernetes.io/arch obiektów Node (przeniesione z bety do GA).
• Możliwość wskazania konkretnej grupy użytkowników systemu dla kontenerów w pod’zie (RunAsGroup, została wprowadzona w K8s 1.11) przesunęła się do wersji beta (włączonej domyślnie).
• du i find, używane w cAdvisor, zostały zastąpione na implementacje w Go.

CLI

W cli-runtime i kubectl dodano flaga -k do integracji z kustomize (nawiasem mówiąc, jego rozwój jest teraz prowadzony w osobnym repozytorium), czyli do przetwarzania dodatkowych plików YAML z specjalnych katalogów kustomizacji (szczegóły dotyczące ich użycia w KEP):

Przykład prostego użycia pliku kustomization (możliwe jest też bardziej złożone zastosowanie kustomize w ramach overlays)

Ponadto:

• Dodano nowa komenda kubectl create cronjob, której nazwa mówi sama za siebie.
• W kubectl logs jest teraz możliwe łączyć flagi -f (--follow do strumieniowania logów) i -l (--selector do zapytania o etykietę).
• kubectl nauczyliśmy kopiować pliki wybierane za pomocą wild card.
• Do zespołu kubectl wait dodali flaga --all do wybrania wszystkich zasobów w przestrzeni nazw określonego typu zasobów.

Inne

Stabilny (GA) status uzyskali następujące możliwości:

• ReadinessGate, używany w specyfikacji pod’a do określenia dodatkowych warunków uwzględnianych w gotowości pod’a;
• Wsparcie dla dużych stron (feature gate o nazwie HugePages);
• CustomPodDNS;
• PriorityClass API, Pod Priority & Preemption.

Inne zmiany wprowadzone w Kubernetes 1.14:

• Domyślnie polityka RBAC nie daje już dostępu do API discovery i access-review użytkownikom bez uwierzytelnienia (unauthenticated).
• Oficjalne wsparcie dla CoreDNS jest zapewniane. tylko dla systemów Linux, dlatego podczas używania kubeadm do jego (CoreDNS) wdrażania w klastrze węzły muszą działać tylko na Linuxie (do tego ograniczenia używane są nodeSelectors).
• Domyślna konfiguracja CoreDNS teraz używa wtyczka forward zamiast proxy. Ponadto, w CoreDNS dodano readinessProbe, zapobiegająca balansowaniu obciążenia na odpowiednich (nieprzygotowanych do obsługi) podach.
• W kubeadm, w fazach init lub upload-certs, stało się możliwe przesyłanie certyfikatów wymaganych do podłączenia nowego control-plane do sekretu kubeadm-certs (używany jest znacznik --experimental-upload-certs).
• Dla instalacji Windows pojawiła się wersja alfa obsługi gMSA (Group Managed Service Account) — specjalne konta w Active Directory, które mogą być używane również przez kontenery.
• Dla GCE włączono szyfrowanie mTLS między etcd a kube-apiserver.
• Aktualizacje w używanym/zależnym oprogramowaniu: Go 1.12.1, CSI 1.1, CoreDNS 1.3.1, wsparcie dla Dockera 18.09 w kubeadm, a minimalną wspieraną wersją Docker API stała się 1.26.

P.S.

Przeczytaj także na naszym blogu:

• «Kubernetes 1.13: przegląd najważniejszych nowości»;
• «Kubernetes 1.12: przegląd najważniejszych nowości»;
• «Kubernetes 1.11: przegląd najważniejszych nowości»;
• «Kubernetes 1.10: przegląd najważniejszych nowości».

Źródło: habr.com