Architektura Kubernetes

Witamy w Kubernetes! To wydajny system do zarządzania skonteneryzowanymi aplikacjami na wielu maszynach.

Zanim przejdziemy do uruchamiania aplikacji, należy zrozumieć podstawową strukturę Kubernetes. Można to porównać do poznania budowy samochodu przed rozpoczęciem jazdy!

U podstaw Kubernetes działa jako klaster. Klaster to grupa współpracujących ze sobą maszyn nazywanych węzłami.

Węzły dzielą się na dwa główne typy:

• Control Plane (Master Node): Mózg klastra.
• Worker Nodes: Maszyny robocze uruchamiające aplikacje.

Control Plane (w starszej dokumentacji często nazywany Master Node) odpowiada za zarządzanie klastrem.

Podejmuje globalne decyzje dotyczące klastra, takie jak planowanie uruchamiania aplikacji, oraz wykrywa zdarzenia w klastrze i reaguje na nie, na przykład ponownie uruchamiając aplikację, która uległa awarii. Nie uruchamia bezpośrednio aplikacji.

API Server to komponent front-endu Kubernetes Control Plane. Jest jedynym komponentem, który komunikuje się bezpośrednio z użytkownikiem (za pośrednictwem kubectl).

Udostępnia Kubernetes API i obsługuje całą komunikację wewnątrz klastra, sprawdzając poprawność danych oraz konfigurując dane obiektów API, takich jak Pody i Usługi.

etcd to spójny i wysoce dostępny magazyn klucz-wartość. Można go uznać za trwałą pamięć klastra.

Przechowuje wszystkie dane klastra, w tym konfigurację, stan i metadane. Jeśli etcd przestanie działać, klaster utraci pamięć i nie będzie mógł działać prawidłowo!

Scheduler obserwuje nowo utworzone Pody (instancje aplikacji), które nie mają przypisanego węzła workera.

Następnie wybiera najlepszy węzeł do uruchomienia każdego Poda, uwzględniając takie czynniki jak wymagania dotyczące zasobów, ograniczenia sprzętowe i zasady.

Controller Manager uruchamia różne kontrolery, czyli działające w tle pętle regulujące stan klastra.

Na przykład Node Controller monitoruje stan węzłów, a Replication Controller dba o uruchomienie właściwej liczby Podów. Nieustannie stara się dopasować stan oczekiwany do stanu bieżącego.

Węzły workerów (w starszej dokumentacji nazywane również Minions) to maszyny, na których uruchamiane są właściwe aplikacje skonteneryzowane (spakowane w Pody).

Każdy węzeł workera ma komponenty umożliwiające komunikację z Control Plane oraz zarządzanie uruchomionymi na nim kontenerami.

Na każdym węźle workera:

• Kubelet: Agent, który dba o uruchomienie kontenerów w Podzie. Otrzymuje instrukcje od API Server i zarządza Podami.
• Container Runtime: Oprogramowanie odpowiedzialne za uruchamianie kontenerów (np. Docker, containerd, CRI-O). Kubelet używa go do pobierania obrazów i uruchamiania aplikacji.

Kube-proxy działa na każdym węźle workera i obsługuje funkcję proxy sieciowego dla usług Kubernetes.

Utrzymuje reguły sieciowe na węźle, umożliwiając komunikację sieciową z Podami zarówno z wnętrza klastra, jak i spoza niego. Dzięki temu aplikacje są dostępne.

Na podstawie zdobytej wiedzy proszę wskazać, które z poniższych komponentów należą do Control Plane Kubernetes.

Świetna praca! Ma Pan już podstawową wiedzę o architekturze Kubernetes.

• Control Plane (API Server, etcd, Scheduler, Controller Manager) zarządza klastrem.
• Worker Nodes (Kubelet, Container Runtime, Kube-proxy) uruchamiają aplikacje.

W dalszej części omówimy najmniejszą jednostkę, którą można wdrożyć w Kubernetes: Pods!