ProHoster > Blog > wiadomości internetowe > Wydanie Kubernetes 1.18, systemu do zarządzania klastrem izolowanych kontenerów

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

opublikowany wydanie platformy orkiestracji kontenerów Kubernetes 1.18, który pozwala zarządzać klastrem izolowanych kontenerów jako całością i zapewnia mechanizmy wdrażania, utrzymywania i skalowania aplikacji działających w kontenerach. Projekt został pierwotnie stworzony przez Google, ale następnie został przeniesiony na niezależny serwis nadzorowany przez Linux Foundation. Platforma pozycjonowana jest jako rozwiązanie uniwersalne, opracowane przez społeczność, niezależne od poszczególnych systemów i zdolne do współpracy z dowolną aplikacją w dowolnym środowisku chmurowym. Kod Kubernetesa jest napisany w Go i dystrybuowane przez na licencji Apache 2.0.

Zapewnia funkcje wdrażania i zarządzania infrastrukturą, takie jak konserwacja baz danych DNS, równoważenie obciążenia,
dystrybucja kontenerów pomiędzy węzłami klastra (migracja kontenerów w zależności od zmian obciążenia i potrzeb serwisowych), sprawdzanie kondycji na poziomie aplikacji, zarządzanie kontami, aktualizacja i dynamiczne skalowanie działającego klastra, bez jego zatrzymywania. Możliwe jest wdrażanie grup kontenerów z możliwością aktualizacji i cofania operacji jednocześnie dla całej grupy, a także logiczny podział klastra na części z podziałem zasobów. Obsługiwana jest dynamiczna migracja aplikacji, do przechowywania danych można wykorzystać zarówno magazyny lokalne, jak i sieciowe.

Wydanie Kubernetes 1.18 zawiera 38 zmian i ulepszeń, z czego 15 zostało przeniesionych do statusu stabilnego, a 11 do statusu beta. W fazie alfa zaproponowano 12 nowych zmian. Przygotowując nową wersję, równy wysiłek skupiono się zarówno na udoskonaleniu różnych funkcjonalności i ustabilizowaniu możliwości eksperymentalnych, jak i na dodaniu nowych rozwiązań. Główne zmiany:

  • Kubectl
    • Dodany Wersja alfa polecenia „kubectl debug”, która pozwala uprościć debugowanie w podach poprzez uruchamianie efemerycznych kontenerów z narzędziami do debugowania.
    • Deklarowany jako stabilny polecenie „kubectl diff”, które pozwala zobaczyć, co zmieni się w klastrze, jeśli zastosujesz manifest.
    • REMOVED wszystkie generatory polecenia „kubectl run”, z wyjątkiem generatora do uruchamiania pojedynczego zasobnika.
    • Zmieniono flaga „--dry-run” w zależności od jej wartości (klient, serwer i brak), próbne wykonanie polecenia odbywa się po stronie klienta lub serwera.
    • kod kubectl podświetlony do osobnego repozytorium. Umożliwiło to oddzielenie kubectl od wewnętrznych zależności Kubernetes i ułatwiło importowanie kodu do projektów innych firm.
  • Ingres
    • Rozpoczęty zmiana grupy API dla Ingress na networking.v1beta1.
    • Dodany nowe pola:
      • pathType, który pozwala określić sposób porównywania ścieżki w żądaniu
      • IngressClassName zastępuje adnotację kubernetes.io/ingress.class, która została uznana za przestarzałą. To pole określa nazwę obiektu specjalnego InressClass
    • обавлен obiekt IngressClass, który wskazuje nazwę kontrolera ingresu, jego dodatkowe parametry oraz znak jego domyślnego użycia
  • Usługi
    • обавлено pole AppProtocol, w którym możesz określić, z jakiego protokołu korzysta aplikacja
    • Przetłumaczony w stanie beta i domyślnie włączony EndpointSlicesAPI, który jest bardziej funkcjonalnym zamiennikiem zwykłych punktów końcowych.
  • Sieć
    • Wsparcie IPv6 został przeniesiony do wersji beta.
  • Dyski stałe. Następująca funkcjonalność została uznana za stabilną:
  • Konfiguracja aplikacji
    • Do obiektów ConfigMap i Secret dodany nowe pole „niezmienne”. Ustawienie wartości pola na true uniemożliwia modyfikację obiektu.
  • Planista
    • Dodany możliwość tworzenia dodatkowych profili dla kube-scheduler. Jeśli wcześniej konieczne było uruchomienie dodatkowych osobnych harmonogramów w celu wdrożenia niestandardowych algorytmów dystrybucji podów, teraz możliwe jest utworzenie dodatkowych zestawów ustawień dla standardowego harmonogramu i podanie jego nazwy w tym samym polu poda „.spec.schedulerName”. Stan - alfa.
    • Eksmisja na podstawie skażenia uznany za stabilny
  • skalowanie
    • Dodany możliwość określenia w manifeście HPA stopnia agresywności przy zmianie liczby uruchomionych podów, czyli przy wzroście obciążenia, uruchomienie N razy większej liczby instancji na raz.
  • kubelet
    • Menedżer topologii otrzymał status wersji beta. Ta funkcja umożliwia alokację NUMA, co pozwala uniknąć pogorszenia wydajności w systemach z wieloma gniazdami.
    • Stan wersji beta otrzymane Funkcja PodOverhead, która pozwala określić w RuntimeClass dodatkową ilość zasobów wymaganych do uruchomienia poda.
    • Rozszerzony obsługa HugePages, w stanie alfa dodano izolację na poziomie kontenera i obsługę wielu rozmiarów hugepages.
    • Usunięto punkt końcowy dla metryk /metrics/resource/v1alpha1, zamiast tego używany jest /metrics/resource
  • API
    • Wreszcie Usunięto możliwość korzystania z przestarzałych grup API apps/v1beta1 i rozszerzeń/v1beta1.
    • Zastosuj po stronie serwera uaktualniony do statusu beta2. To ulepszenie przenosi manipulację obiektami z kubectl na serwer API. Autorzy usprawnienia twierdzą, że naprawi to wiele istniejących błędów, których w obecnej sytuacji nie da się naprawić. Dodali także sekcję „.metadata.managedFields”, w której proponują przechowywanie historii zmian obiektów, ze wskazaniem kto, kiedy i co dokładnie uległ zmianie.
    • Ogłoszony stabilny interfejs API certyfikatu podpisywania certyfikatu.
  • Obsługa platformy Windows.

Źródło: opennet.ru

Dodaj komentarz