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

Wczoraj, 9 grudnia, miał miejsce nastąpiła kolejna wersja Kubernetes — 1.17. Zgodnie z tradycją naszego bloga, relacjonujemy najważniejsze zmiany w nowej wersji.

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

Informacje wykorzystane do przygotowania tego materiału pochodzą z oficjalnego ogłoszenia, tabeli śledzenia ulepszeń Kubernetes, CHANGELOG-1.17 oraz odpowiednich zgłoszeń, pull requestów i propozycji ulepszeń Kubernetes (KEP). I co nowego?..

Routing z uwzględnieniem topologii

W społeczności Kubernetes długo czekano na tę funkcjonalność — Routing z uwzględnieniem topologii. Jeśli KEP pojawiała się od października 2018 roku, a oficjalne ulepszenie — 2 lata temu, więc zwykłe zgłoszenia (takie jak tego) — są nawet starsze o kilka lat…

Ogólny pomysł sprowadza się do zapewnienia możliwości realizacji „lokalnego” routingu dla usług znajdujących się w Kubernetes. „Lokalność” w tym przypadku oznacza „ten sam poziom topologii” (poziom topologii), którym może być:

ten sam węzeł dla usług,
ta sama szafa serwerowa,
ten sam region,
ten sam dostawca chmury,
…

Przykłady zastosowania tej funkcji:

oszczędności na transferze w chmurowych instalacjach z wieloma strefami dostępności (multi-AZ) — zob. nową ilustrację na przykładzie ruchu w jednym regionie, ale różnych AZ w AWS;
mniejsze opóźnienia w wydajności/lepsza przepustowość;
podzielona usługa, mająca lokalne informacje o węźle w każdym shardzie;
umieszczenie fluentd (lub odpowiedników) na jednym węźle z aplikacjami, z których zbierane są logi;
…

Taki routing, „znający” o topologii, nazywa się także rodzajem affinity sieciowej — analogicznie do node affinity, pod affinity/anti-affinity lub niedawno wprowadzonym Topology-Aware Volume Scheduling Volume Provisioning (i ). Aktualny poziom realizacjiServiceTopology w Kubernetes — wersja alfa. Szczegóły na temat tego, jak działa funkcjonalność i jak można z niej korzystać, znajdziesz w

od jednego z autorów. w tym artykule Wsparcie dla podwójnego stosu IPv4/IPv6

Znaczący postęp

został odnotowany w innej funkcji sieciowej: jednoczesnym wsparciu dwóch stosów IP, które po raz pierwszy zaprezentowano w K8s 1.16 . W szczególności nowa wersja przyniosła następujące zmiany:w kube-proxy

możliwość jednoczesnej pracy w obu trybach (IPv4 i IPv6); zrealizowano Pod.Status.PodIPs
do wsparcie downward API (w tym momencie w pojawiła się teraz wymaga dla hosta dodania także adresu IPv6); /etc/hosts wsparcie dla dwóch stosów w
(Kubernetes IN Docker) i KIND zaktualizowane testy e2e. kubeadm;
обновлённые e2e-тесты.

Kubernetes 1.17: przegląd głównych nowości
Ilustracja użycie podwójnego stosu IPV4/IPv6 w KIND

Postępy w zakresie CSI

Ogłoszono jako stabilną wsparcie topologii dla magazynów opartych na CSI, po raz pierwszy przedstawione w K8s 1.12.

Inicjatywa dotycząca migracji wtyczek do woluminów na CSI — Migracja CSI osiągnęła wersję beta. Ta funkcjonalność jest kluczowa, aby przenieść istniejące wtyczki magazynów (in-tree) na nowoczesny interfejs (CSI, out-of-tree) niewidocznie dla końcowych użytkowników Kubernetes. Administratorzy klastrów będą musieli tylko aktywować migrację CSI, a istniejące zasoby stateful i obciążenia robocze będą nadal „po prostu działać”… ale już z wykorzystaniem aktualnych sterowników CSI zamiast przestarzałych, wchodzących w skład jądra Kubernetes.

Na ten moment w wersji beta gotowa jest migracja dla sterowników AWS EBS (kubernetes.io/aws-ebs) oraz GCE PD (kubernetes.io/gce-pd). Prognozy dotyczące innych magazynów są następujące:

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

O tym, jak „tradycyjne” wsparcie magazynów w K8s przeszło do CSI, opowiadaliśmy w w tym artykule. A przejściu migracji CSI do wersji beta poświęcona jest osobna publikacja w blogu projektu.

Ponadto status wersji beta (tj. włączenie domyślne) w wydaniu Kubernetes 1.17 osiągnęła inna znacząca funkcjonalność w kontekście CSI, która wywodzi się (od wersji alfa) z K8s 1.12, — tworzenie migawk i przywracanie z nich. Pośród zmian w Kubernetes Volume Snapshot na drodze do wydania beta:

rozbicie sidecara CSI external-snapshotter na dwa kontrolery,
dodanie sekretu do usunięcia (secredu do usunięcia) jako adnotacji do zawartości migawki woluminu,
nowy finilzator (finalizer) w celu zapobieżenia usunięciu obiektu API migawki przy istnieniu pozostałych powiązań.

W momencie wydania 1.17 funkcja była wspierana przez trzy sterowniki CSI: GCE Persistent Disk CSI Driver, Portworx CSI Driver oraz NetApp Trident CSI Driver. Więcej informacji na temat jej wdrożenia i użycia można znaleźć w tej publikacji blogu.

Etykiety dostawcy chmury

Etykiety, które automatycznie przypisywane są do tworzonych węzłów i woluminów w zależności od używanego dostawcy chmury,były dostępne w Kubernetes jako wersja beta od bardzo dawna — począwszy od wydania K8s 1.2 (kwiecień 2016 roku!). Biorąc pod uwagę ich szerokie zastosowanie przez tak długi czas, deweloperzy postanowili, uznali, że nadszedł czas ogłosić funkcję stabilną (GA).

Dlatego wszystkie zostały odpowiednio przemianowane (według topologii):

beta.kubernetes.io/instance-type → node.kubernetes.io/instance-type
failure-domain.beta.kubernetes.io/zone → topology.kubernetes.io/zone
failure-domain.beta.kubernetes.io/region → topology.kubernetes.io/region

… ale nadal są dostępne pod swoimi starymi nazwami (dla zachowania kompatybilności). Z drugiej strony, wszystkim administratorom zaleca się przejście na aktualne etykiety. Odpowiednia dokumentacja K8s została zaktualizowana.

Strukturalny wynik kubeadm

Po raz pierwszy zaprezentowano w wersji alfa strukturalny wynik dla narzędzia kubeadm. Obsługiwane formaty: JSON, YAML, szablon Go.

Motywacja do wdrożenia tej funkcji (zgodnie z KEP) jest następująca:

Choć Kubernetes może być wdrażany ręcznie, de facto standardem (jeśli nie de iure) dla tej operacji jest użycie kubeadm. Popularne narzędzia do zarządzania systemem, takie jak Terraform, polegają na kubeadm do deployowania Kubernetes. Planowane ulepszenia w Cluster API obejmują składany pakiet do bootstrapowania Kubernetes z kubeadm i cloud-init.
Bez strukturalnego wyniku nawet najmniej nieznaczne zmiany mogą złamać Terraform, Cluster API i inne oprogramowanie korzystające z wyników pracy kubeadm.

W najbliższych planach przewidziano wsparcie (w formie strukturalnego wyniku) dla następujących komend kubeadm:

alpha certs
config images list
init
token create
token list
upgrade plan
version

Ilustracja odpowiedzi JSON na komendę kubeadm init -o json:

{
  "node0": "192.168.20.51:443",
  "caCrt": "sha256:1f40ff4bd1b854fb4a5cf5d2f38267a5ce5f89e34d34b0f62bf335d74eef91a3",
  "token": {
    "id":          "5ndzuu.ngie1sxkgielfpb1",
    "ttl":         "23h",
    "expires":     "2019-05-08T18:58:07Z",
    "usages":      [
      "authentication",
      "signing"
    ],
    "description": "Domyślny token bootstrapowy wygenerowany przez 'kubeadm init'.",
    "extraGroups": [
      "system:bootstrappers:kubeadm:default-node-token"
    ]
  },
  "raw": "Rm9yIHRoZSBhY3R1YWwgb3V0cHV0IG9mIHRoZSAia3ViZWFkbSBpbml0IiBjb21tYW5kLCBwbGVhc2Ugc2VlIGh0dHBzOi8vZ2lzdC5naXRodWIuY29tL2FrdXR6LzdhNjg2ZGU1N2JmNDMzZjkyZjcxYjZmYjc3ZDRkOWJhI2ZpbGUta3ViZWFkbS1pbml0LW91dHB1dC1sb2c="
}

Stabilizacja innych nowości

W ogóle, wydanie Kubernetes 1.17 miało hasło „Stabilność”. To było możliwe, ponieważ bardzo wiele funkcji w nim (ich ogólna liczba — 14) uzyskało status GA. Wśród nich:

„znaczniki” węzłów według określonych warunków (TaintNodesByCondition), która pojawiła się w K8s 1.8;
Watch Bookmarks — nowy typ zdarzeń, charakteryzujących się tym, że wszystkie obiekty do pewnej wersji (resourceVersion) zostały już przetworzone przez watch’a;
domyślne wartości (defaulting) dla Custom Resources;
dzielone pomiędzy kontenerami w pod’zie process namespaces;
ScheduleDaemonSetPods — planowanie pod’ów w DaemonSet za pomocą kube-scheduler (zamiast kontrolera DaemonSet);
dynamiczne limity na liczbę woluminów w zależności od typu węzła;
wsparcie dla zmiennych środowiskowych dla nazw katalogów montowanych jako subPath;
przenoszenie heartbeatów Kubeleta w specjalizowanym Lease API;
„ochrona finalizatora” (Ochrona Finalizatora) dla load balancerów (weryfikacja odpowiednich zasobów Service przed usunięciem zasobów LoadBalancer);
optymalizacja kube-apiserver w wydajności przy pracy z wieloma obserwacjami, monitorującymi identyczne zestawy obiektów — osiągnięta dzięki unikaniu ponownej serializacji tych samych obiektów dla każdego obserwatora.

Inne zmiany

Pełna lista nowości w Kubernetes 1.17 oczywiście nie ogranicza się do wymienionych powyżej. Oto niektóre inne z nich (a dla pełniejszej listy — zob. CHANGELOG):

do wersji beta „dorosła” zaprezentowana w poprzednim wydaniu funkcja RunAsUserName dla systemu Windows.;
analogiczna zmiana osiągnęła EndpointSlice API (również z K8s 1.16), jednak to rozwiązanie poprawiające wydajność/skalowalność Endpoint API nie jest domyślnie aktywowane;
krytyczne dla działania klastra pod’y mogą być tworzone nie tylko w przestrzeniach nazw kube-system (szczegóły w dokumentacji dotyczącej Limit Priority Class consumption);
nowa opcja dla kubelet — --reserved-cpus — pozwala wyraźnie określić listę CPU zarezerwowanych dla systemu;
do kubectl logs zaprezentowano nowa flaga --prefix, dodająca nazwę pod’a i źródłowego kontenera do każdej linii logu;
do label.Selector dodali RequiresExactMatch;
wszystkie kontenery w kube-dns teraz uruchamiane są z mniejszymi uprawnieniami;
hyperkube wyodrębnił się do odrębnego repozytorium na GitHubie i nie będzie już dołączany do wydań Kubernetes;
znacząco poprawiona wydajność kube-proxy dla portów nie-UDP.

Zmiany w zależnościach:

wersja CoreDNS w składzie kubeadm — 1.6.5;
wersja crictl zaktualizowana do v1.16.1;
CSI 1.2.0;
etcd 3.4.3;
ostatnia zatwierdzona wersja Dockera podniesiona do 19.03;
minimalna wersja Go wymagana do kompilacji Kubernetes 1.17 — 1.13.4.

P.S.

Przeczytaj także na naszym blogu:

Źródło: habr.com