Składniki Kubernetes
W wyniku instalacji Kubernetes otrzymujesz klaster.
Klaster Kubernetes to zestaw maszyn roboczych, nazywanych węzłami, na których uruchamiane są aplikacje w kontenerach. Każdy klaster musi posiadać przynajmniej jeden węzeł.
Na węźle (lub węzłach) roboczych rozmieszczane są podyThe smallest and simplest Kubernetes object. A Pod represents a set of running containers on your cluster. , które są częściami składowymi aplikacji. Warstwa sterowaniaThe container orchestration layer that exposes the API and interfaces to define, deploy, and manage the lifecycle of containers. zarządza węzłami roboczymi i podami należącymi do klastra. W środowisku produkcyjnym warstwa sterowania rozłożona jest zazwyczaj na kilka maszyn, a klaster uruchomiony jest na wielu węzłach zapewniając większą niezawodność i odporność 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.
Częsci składowe warstwy sterowania
Komponenty warstwy sterowania podejmują ogólne decyzje dotyczące klastra (np. zlecanie zadań), a także 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 warstwy sterowania mogą być uruchomione na dowolnej maszynie w klastrze. Dla uproszczenia jednak 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 warstwy sterowania, który śledzi tworzenie nowych podówThe smallest and simplest Kubernetes object. A Pod represents a set of running containers on your cluster. i przypisuje im węzłyA node is a worker machine in Kubernetes. , 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 warstwy sterowania 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ęźleA node is a worker machine in Kubernetes. klastra. Odpowiada za uruchamianie kontenerówA lightweight and portable executable image that contains software and all of its dependencies. w ramach podaThe smallest and simplest Kubernetes object. A Pod represents a set of running containers on your cluster. .
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ęźleA node is a worker machine in Kubernetes. klastra i uczestniczy w tworzeniu serwisuA 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: DockerDocker is a software technology providing operating-system-level virtualization also known as containers. , containerdA container runtime with an emphasis on simplicity, robustness and portability , CRI-OA lightweight container runtime specifically for Kubernetes 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:
- Więcej o Węzłach
- Więcej o Kontrolerach
- Więcej o kube-scheduler
- Oficjalna dokumentacja etcd
Twoja opinia
Czy ta strona była przydatna?
Dziękujemy za informację zwrotną. Jeśli masz konkretne pytanie dotyczące użycia Kubernetesa, odwiedź Stack Overflow. Otwórz zgłoszenie w repozytorium GitHub, jeśli chcesz zgłosić problem lub zaproponować poprawkę.