Pojęcia

Edit This Page

Składniki Kubernetes

W wyniku instalacji Kubernetes otrzymujesz klaster.

Klaster to zestaw maszyn, nazywanych węzłami, na których uruchamiane są aplikacje zarządzane przez Kubernetes. Klaster posiada przynajmniej jeden węzeł roboczy (node) i jeden węzeł typu master (master node).

Na węźle (lub węzłach) roboczych rozmieszczane są pody, które są częściami składowymi aplikacji. Węzeł (lub węzły) typu master zarządzają węzłami roboczymi i podami należącymi do klastra. Zwielokrotnione węzły typu master zapewniają większą niezawodność i odporność klastra na awarie.

W tym dokumencie opisujemy składniki niezbędne do zbudowania kompletnego, poprawnie działającego klastra Kubernetes.

Poniższy rysunek przedstawia klaster Kubernetes i powiązania pomiędzy jego różnymi częściami składowymi.

Składniki Kubernetes

Master — częsci składowe

Komponenty master odpowiadają za warstwę sterowania klastra. Podejmują ogólne decyzje dotyczące klastra (np. zlecanie zadań), wykrywają i reagują na zdarzenia w klastrze (przykładowo, start nowego podaThe smallest and simplest Kubernetes object. A Pod represents a set of running containers on your cluster. , kiedy wartość replicas dla deploymentu nie zgadza się z faktyczną liczbą replik).

Komponenty master mogą być uruchomione na dowolnej maszynie w klastrze. Dla uproszczenia skrypty instalacyjne zazwyczaj startują wszystkie składniki na tej samej maszynie i jednocześnie nie pozwalają na uruchamianie na niej kontenerów użytkowników. Na stronie Tworzenie Wysoko Dostępnych Klastrów jest więcej informacji o konfiguracji typu multi-master-VM.

kube-apiserver

Składnik master udostępniający API Kubernetes. Służy jako front-end dla warstwy sterowania Kubernetes. Serwer API jest składnikiem warstwy sterowaniaThe container orchestration layer that exposes the API and interfaces to define, deploy, and manage the lifecycle of containers. Kubernetes, który udostępnia API. Server API służy jako front-end warstwy sterowania Kubernetes.

Podstawowa implementacją serwera API Kubernetes jest kube-apiserver. kube-apiserver został zaprojektowany w taki sposób, aby móc skalować się horyzontalnie — to oznacza, że zwiększa swoją wydajność poprzez dodawanie kolejnych instancji. Można uruchomić kilka instancji kube-apiserver i rozkładać między nimi ruch od klientów.

etcd

Magazyn typu klucz-wartość (key/value store), zapewniający spójność i wysoką dostępność, używany do przechowywania wszystkich danych o klastrze Kubernetes.

Jeśli Twój klaster Kubernetes używa etcd do przechowywania swoich danych, upewnij się, że masz opracowany plan tworzenia kopii zapasowych tych danych.

Szczegółowe informacje na temat etcd można znaleźć w oficjalnej dokumentacji.

kube-scheduler

Składnik master, który monitoruje tworzenie nowych podów i przypisuje im węzły, na których powinny zostać uruchomione.

Przy podejmowaniu decyzji o wyborze węzła brane pod uwagę są wymagania indywidualne i zbiorcze odnośnie zasobów, ograniczenia wynikające z polityk sprzętu i oprogramowania, wymagania affinity i anty-affinity, lokalizacja danych, zależności między zadaniami i wymagania czasowe.

kube-controller-manager

Składnik master odpowiedzialny za uruchamianie kontrolerówA control loop that watches the shared state of the cluster through the apiserver and makes changes attempting to move the current state towards the desired state. .

Z poziomu podziału logicznego, każdy kontrolerA control loop that watches the shared state of the cluster through the apiserver and makes changes attempting to move the current state towards the desired state. jest oddzielnym procesem, ale w celu zmniejszenia złożoności, wszystkie kontrolery są skompilowane do jednego programu binarnego i uruchamiane jako jeden proces.

Kontrolerami są:

  • Node Controller: Odpowiada za rozpoznawanie i reagowanie na sytuacje, kiedy węzeł staje się z jakiegoś powodu niedostępny.
  • Replication Controller: Odpowiada za utrzymanie prawidłowej liczby podów dla każdego obiektu typu ReplicationController w systemie.
  • Endpoints Controller: Dostarcza informacji do obiektów typu Endpoints (tzn. łączy ze sobą Serwisy i Pody).
  • Service Account & Token Controllers: Tworzy domyślne konta i tokeny dostępu API dla nowych przestrzeni nazw (namespaces).

cloud-controller-manager

cloud-controller-manager uruchamia kontroler, który komunikuje się z usługami dostawcy chmury, na których zbudowany jest klaster. Oprogramowanie cloud-controller-manager, wprowadzone w Kubernetes 1.6 ma status rozwojowy beta.

cloud-controller-manager wykonuje tylko pętle sterowania konkretnych dostawców usług chmurowych. Wykonywanie tych pętli sterowania musi być wyłączone w kube-controller-manager. Wyłączenie następuje poprzez ustawienie opcji --cloud-provider jako external przy starcie kube-controller-manager.

cloud-controller-manager umożliwia rozwój oprogramowania dostawców usług chmurowych niezależnie od samego oprogramowania Kubernetes. W poprzednich wersjach, główny kod Kubernetes był zależny od kodu dostarczonego przez zewnętrznych dostawców różnych usług chmurowych. W przyszłych wydaniach, oprogramowanie związane z dostawcami chmurowymi będzie utrzymywane przez nich samych i podłączane do cloud-controller-managera w trakcie uruchamiana Kubernetes.

Następujące kontrolery zależą od dostawców usług chmurowych:

  • Node Controller: Aby sprawdzić u dostawcy usługi chmurowej, czy węzeł został skasowany po tym, jak przestał odpowiadać
  • Route Controller: Aby ustawić trasy (routes) w niższych warstwach infrastruktury chmurowej
  • Service Controller: Aby tworzyć, aktualizować i kasować cloud load balancers
  • Volume Controller: Aby tworzyć, podłączać i montować woluminy oraz zarządzać nimi przez dostawcę usług chmurowych

Składniki węzłów

Składniki węzłów uruchomiane są na każdym węźle. Utrzymują pody w działaniu i ustawiają środowisko uruchomieniowe Kubernetes.

kubelet

Agent, który działa na każdym węźle klastra. Odpowiada za uruchamianie kontenerów w ramach poda.

Kubelet korzysta z dostarczanych na różne sposoby PodSpecs i gwarantuje, że kontenery opisane przez te PodSpecs są uruchomione i działają poprawnie. Kubelet nie zarządza kontenerami, które nie zostały utworzone przez Kubernetes.

kube-proxy

kube-proxy to proxy sieciowe, które uruchomione jest na każdym węźle klastra i uczestniczy w tworzeniu ServiceA way to expose an application running on a set of Pods as a network service. .

kube-proxy utrzymuje reguły sieciowe na węźle. Dzięki tym regułom sieci na zewnątrz i wewnątrz klastra mogą komunikować się z Podami.

kube-proxy używa warstwy filtrowania pakietów dostarczanych przez system operacyjny, o ile taka jest dostępna. W przeciwnym przypadku, kube-proxy samo zajmuje sie przekazywaniem ruchu sieciowego.

Container Runtime

Container runtime to oprogramowanie zajmujące się uruchamianiem kontenerów.

Kubernetes obsługuje różne container runtimes: Docker, containerd, cri-o, rktlet oraz każdą implementację zgodną z Kubernetes CRI (Container Runtime Interface).

Dodatki (Addons)

Dodatki korzystają z podstawowych obiektów Kubernetes (DaemonSetEnsures a copy of a Pod is running across a set of nodes in a cluster. , DeploymentAn API object that manages a replicated application. , itp.), aby rozszerzyć funkcjonalności klastra. Ponieważ są to funkcjonalności obejmujące cały klaster, zasoby te należą do przestrzeni nazw (namespace) kube-system.

Wybrane dodatki opisano poniżej. Rozszerzona lista dostępnych dodatków jest w części Dodatki.

DNS

Mimo, że inne dodatki nie są bezwzględnie wymagane, wszystkie klastry Kubernetes powinny mieć cluster DNS, ponieważ wiele przykładów z niego korzysta.

Cluster DNS to serwer DNS, który uzupełnienia inne serwery DNS z twojego środowiska, dostarczając informacje o rekordach DNS dla usług Kubernetes.

Kontenery uruchomione przez Kubernetes automatycznie przeszukują ten serwer DNS.

Interfejs użytkownika (Dashboard)

Dashboard to webowy interfejs ogólnego zastosowania przeznaczony dla użytkowników klastra Kubernetes. Umożliwia zarządzanie i rozwiązywanie problemów związanych z aplikacjami uruchamianymi na klastrze, a także z samym klastrem.

Monitorowanie zasobów w kontenerach

Container Resource Monitoring zapisuje serie czasowe podstawowych metryk kontenerów w centralnej bazie danych i oferuje interfejs użytkownika do przeglądania tych danych.

Logowanie na poziomie klastra

Mechanizm logowania na poziomie klastra odpowiada za zapisywanie logów pochodzących z poszczególnych kontenerów do wspólnego magazynu, który posiada interfejs do przeglądania i przeszukiwania.

Następne:

Twoja opinia