Wydanie Kubernetes 1.18, systemu zarządzania klastrami izolowanych kontenerów

Opublikowano wydanie platformy orkiestracji kontenerów Kubernetes 1.18, umożliwiającej zarządzanie klastrem z izolowanych kontenerów jako jedną całością oraz dostarczającej mechanizmy do wdrażania, utrzymania i skalowania aplikacji działających w kontenerach. Projekt został pierwotnie stworzony przez firmę Google, ale następnie przeniesiony na niezależną platformę, nadzorowaną przez organizację Linux Foundation. Platforma jest promowana jako rozwijane przez społeczność uniwersalne rozwiązanie, niewiążące się z konkretnymi systemami, które może działać z dowolnymi aplikacjami w różnych środowiskach chmurowych. Kod Kubernetes został napisany w języku Go i rozpowszechniany na licencji Apache 2.0.

oferuje funkcje do wdrażania i zarządzania infrastrukturą, takie jak zarządzanie bazą DNS, równoważenie obciążenia,
przydzielanie kontenerów na węzły klastra (migracja kontenerów na podstawie zmieniającego się obciążenia i potrzeb usług), sprawdzanie stanu aplikacji, zarządzanie kontami, aktualizacja i dynamiczne skalowanie działającego klastra, bez jego zatrzymywania. Możliwe jest wdrażanie grup kontenerów z wykonywaniem operacji aktualizacji i cofania zmian jednocześnie dla całej grupy, a także logiczne podzielenie klastra na części z podziałem zasobów. Obsługiwana jest dynamiczna migracja aplikacji, dla których do przechowywania danych mogą być stosowane zarówno lokalne, jak i sieciowe systemy przechowywania.

Wydanie Kubernetes 1.18 zawiera 38 zmian i ulepszeń, z czego 15 zostało przeniesionych do statusu stabilnego, a 11 do statusu beta. 12 nowych zmian zostało zaproponowanych w statusie alfa. Przy przygotowywaniu nowej wersji skoncentrowano się zarówno na udoskonaleniu różnych funkcji i stabilizacji eksperymentalnych możliwości, jak i na dodaniu nowych rozwiązań. Główne zmiany:

• Kubectl
  • Dodano stabilna wersja komendy „kubectl debug”, która upraszcza debugowanie w podach poprzez uruchamianie efemerycznych kontenerów z narzędziami do debugowania.
  • Ogłoszono jako stabilną komendę „kubectl diff”, która pozwala zobaczyć, co zmieni się w klastrze po zastosowaniu manifestu.
  • Usunięto wszystkie generatory komendy „kubectl run”, z wyjątkiem generatora uruchamiania pojedynczego poda.
  • Zmodyfikowano Flaga „–dry-run”, w zależności od jego wartości (client, server i none) próba wykonania polecenia jest realizowana po stronie klienta lub serwera.
  • Kod kubectl został wyodrębniony do osobnego repozytorium. Umożliwiło to oddzielenie kubectl od wewnętrznych zależności Kubernetes i uprościło import kodu do zewnętrznych projektów.
• Ingress
  • Zaczęło się zmiana grupy API dla Ingress na networking.v1beta1.
  • Dodano nowe pola:
    • pathType, umożliwiające określenie, w jaki sposób będzie porównywana ścieżka w żądaniu
    • IngressClassName — zastępuje adnotację kubernetes.io/ingress.class, która została oznaczona jako przestarzała. W tym polu podaje się nazwę specjalnego obiektu IngressClass
  • Dodano obiekt IngressClass, w którym określa się nazwę kontrolera ingresses, dodatkowe parametry i oznaczenie użycia domyślnego
• Service
  • Dodano pole AppProtocol, w którym można określić, jaki protokół wykorzystuje aplikacja
  • Przeniesiono do statusu beta i włączono domyślnie EndpointSlicesAPI, które jest bardziej funkcjonalnym zamiennikiem zwykłych Endpoints.
• Sieć
  • Wsparcie IPv6 przeszła do statusu beta.
• Dyski stałe. Ogłoszono stabilną następującą funkcjonalność:
  • Klonowanie PVC
  • Użycie niesieciowych raw-urządzeń w roli dysków stałych
  • Wsparcie dla raw-urządzeń w CSI
  • Przekazywanie informacji o podzie, który zażądał podłączenia dysku, do sterownika CSI
• Konfigurowanie aplikacji
  • W obiektach ConfigMap i Secret dodano nowe pole „immutable”. Ustawienie wartości pola na true zabrania zmiany obiektu.
• Harmonogram
  • Dodano możliwość tworzenia dodatkowych profili dla kube-scheduler. Jeśli wcześniej wymagało to uruchomienia oddzielnych planistów do realizacji niestandardowych algorytmów rozdzielania poda, teraz można stworzyć dodatkowe zestawy ustawień dla standardowego planisty i wskazać jego nazwę w tym samym polu podu „.spec.schedulerName”. Status — alfa.
  • Eviction na podstawie Taint ogłoszona jako stabilna
• Skalowanie
  • Dodano możliwość wskazania w manifeście HPA stopnia agresywności przy zmianie liczby uruchomionych podów, co oznacza, że przy zwiększonej obciążalności uruchamiać natychmiast w N razy więcej instancji.
• Kubelet
  • Menedżer Topologii uzyskał status beta. Funkcja obejmuje dystrybucję NUMA, co pozwala uniknąć degradacji wydajności w systemach wieloprocesorowych.
  • Status beta otrzymał funkcja PodOverhead, umożliwiająca wskazanie w RuntimeClass dodatkowej ilości zasobów potrzebnych do uruchomienia poda.
  • Rozszerzono wsparcie HugePages, w wersji alfa dodano izolację na poziomie kontenera oraz wsparcie dla różnych rozmiarów hugepages.
  • Usunięto punkt końcowy dla metryk /metrics/resource/v1alpha1, zamiast niego używa się /metrics/resource
• API
  • Ostatecznie usunięto możliwość korzystania z przestarzałych grup API apps/v1beta1 i extensions/v1beta1.
  • ServerSide Apply podniesiono do statusu beta2. To ulepszenie przenosi manipulację obiektami z kubectl do API-serwera. Autorzy ulepszenia twierdzą, że pozwoli to naprawić wiele istniejących błędów, których nie da się poprawić w obecnej sytuacji. Dodano również sekcję „.metadata.managedFields”, w której proponują przechowywanie historii zmian obiektu, wskazując kto, kiedy i co dokładnie zmienił.
  • Ogłoszono stabilne API CertificateSigningRequest.
• Wsparcie dla platformy Windows.
  • Wsparcie dla węzłów Windows nadal się rozszerza. Dodano wersje alfa:
    • Wsparcie dla CRI-Containerd
    • Implementacja RuntimeClass
    • CSI proxy
  • Wsparcie przeszło do statusu stabilnego
    • Zarządzane konto usługi grupowej
    • RunAsUserName

Źródło: opennet.ru