instruction: Explain Architektura klastra
output: Architektura klastra
  Podstawowe założenia architektury Kubernetesa.
  Klaster Kubernetesa składa się z warstwy sterowania oraz zestawu maszyn roboczych, zwanych węzłami, które
  uruchamiają konteneryzowane aplikacje. Każdy klaster potrzebuje co najmniej jednego węzła roboczego, aby obsługiwać Pody.
  Węzeł roboczy hostuje Pody, które są komponentami
  workload
  aplikacji. Warstwa
  sterowania zarządza węzłami roboczymi oraz Podami w klastrze. W środowiskach
  produkcyjnych, warstwa sterowania zazwyczaj działa na wielu komputerach, a klaster
  zazwyczaj działa na wielu węzłach, zapewniając odporność na awarie i wysoką dostępność.
  Ten dokument opisuje różne komponenty, które musisz posiadać, aby mieć kompletny i działający klaster Kubernetesa.
  Rysunek 1. Komponenty klastra Kubernetesa.
  About this architecture
  Diagram na Rysunku 1 przedstawia przykładową referencyjną architekturę klastra Kubernetesa.
  Rzeczywisty rozkład komponentów może różnić się w zależności od specyficznych konfiguracji klastra i wymagań.
  Na schemacie każdy węzeł uruchamia komponent
  kube-proxy
  Potrzebujesz komponentu sieciowego proxy na każdym węźle, aby
  zapewnić, że API
  Service
  związane z nim zachowania są dostępne w sieci klastra. Niektóre wtyczki
  sieciowe jednak dostarczają własne, zewnętrzne implementacje proxy. Kiedy
  korzystasz z tego rodzaju wtyczki sieciowej, węzeł nie musi uruchamiać
  kube-proxy
  Komponenty warstwy sterowania
  Komponenty warstwy sterowania podejmują globalne decyzje dotyczące klastra (na
  przykład harmonogramowanie), a także wykrywają i reagują na zdarzenia klastra (na
  przykład uruchamianie nowego
  poda
  gdy nie
  zgadza się liczba
  replik
  Deploymentu.
  Elementy warstwy sterowania mogą być uruchamiane na dowolnej maszynie w klastrze. Jednakże, dla uproszczenia, skrypty
  instalacyjne zazwyczaj uruchamiają wszystkie elementy warstwy sterowania na tej samej maszynie i nie uruchamiają kontenerów
  użytkownika na tej maszynie. Zobacz
  Tworzenie klastrów o wysokiej dostępności za pomocą kubeadm
  dla przykładowej konfiguracji warstwy sterowania, która działa na wielu maszynach.
  kube-apiserver
  Serwer API jest składnikiem
  warstwy sterowania
  Kubernetesa, który udostępnia API.
  Server API służy jako front-end warstwy sterowania Kubernetesa.
  Podstawową implementacją serwera API Kubernetesa 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 Kubernetesa.
  Jeśli Twój klaster Kubernetesa 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ó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
  anty-affinity
  , lokalizacja danych,
  zależności między zadaniami i wymagania czasowe.
  kube-controller-manager
  Składnik warstwy sterowania odpowiedzialny za uruchamianie
  kontrolerów
  Z poziomu podziału logicznego, każdy
  kontroler
  jest oddzielnym procesem, ale w celu zmniejszenia złożoności, wszystkie kontrolery są skompilowane do jednego programu binarnego i uruchamiane jako jeden proces.
  Istnieje wiele różnych typów kontrolerów. Niektóre z nich to:
  Kontroler węzłów (ang. Node controller): Odpowiada za zauważanie i reagowanie, gdy węzły przestają działać.
  Kontroler zadania (ang. Job controller): Monitoruje obiekty zadania (Job), które reprezentują jednorazowe zadania, a następnie tworzy Pody, aby wykonały te zadania do końca.
  Kontroler EndpointSlice: Uzupełnia obiekty EndpointSlice (aby zapewnić połączenie między Services a Pods).
  Kontroler ServiceAccount: Tworzenie domyślnych obiektów ServiceAccount dla nowych przestrzeni nazw.
  Powyższa lista nie jest wyczerpującą.
  cloud-controller-manager
  Element składowy
  warstwy sterowania
  Kubernetesa,
  który zarządza usługami realizowanymi po stronie chmur obliczeniowych. Cloud controller manager umożliwia
  połączenie Twojego klastra z API operatora usług chmurowych i rozdziela składniki operujące na platformie
  chmurowej od tych, które dotyczą wyłącznie samego klastra.
  Manager 'cloud-controller' uruchamia tylko kontrolery specyficzne dla dostawcy
  chmury. Jeśli uruchamiasz Kubernetesa w swojej siedzibie lub w środowisku do
  nauki na swoim komputerze osobistym, klaster nie posiada managera 'cloud-controller'.
  Podobnie jak kube-controller-manager, cloud-controller-manager łączy kilka logicznie niezależnych
  pętli kontrolnych w jedną binarkę, którą uruchamiasz jako pojedynczy proces. Możesz go skalować
  horyzontalnie (uruchamiając więcej niż jedną kopię), aby poprawić wydajność lub pomóc w tolerowaniu awarii.
  Następujące kontrolery mogą mieć zależności od dostawcy chmury:
  Kontroler węzłów (ang. Node controller): Do sprawdzania dostawcy chmury w
  celu ustalenia, czy węzeł został usunięty w chmurze po tym, jak przestaje odpowiadać.
  Kontroler tras (ang. Route controller): Do konfiguracji tras w podstawowej infrastrukturze chmurowej.
  Kontroler usługi (ang. Service controller): Do tworzenia, aktualizowania i usuwania load balancerów dostawcy chmury.
  Komponenty węzła
  Komponenty węzła działają na każdym węźle, utrzymując działające pody i zapewniając środowisko wykonawcze Kubernetesa.
  kubelet
  Agent, który działa na każdym
  węźle
  klastra. Odpowiada za uruchamianie
  kontenerów
  w ramach
  poda
  kubelet
  korzysta z dostarczanych (różnymi metodami)
  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 Kubernetesa.
  kube-proxy
  (opcjonalne)
  kube-proxy to
  proxy
  sieciowe, które uruchomione jest na każdym
  węźle
  klastra
  i uczestniczy w tworzeniu
  serwisu
  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.
  Jeśli
  używasz
  wtyczki sieciowej
  , która samodzielnie
  implementuje przekazywanie pakietów dla Usług i zapewnia równoważne działanie
  do kube-proxy, to nie musisz uruchamiać kube-proxy na węzłach w swoim klastrze.
  Środowisko uruchomieniowe kontenera
  Podstawowy komponent umożliwiający efektywne uruchamianie kontenerów w Kubernetesie.
  Odpowiada za zarządzanie uruchamianiem i cyklem życia kontenerów w środowisku Kubernetes.
  Kubernetes obsługuje różne
  container runtimes
  containerd
  CRI-O
  oraz każdą implementację zgodną z
  Kubernetes CRI (Container Runtime
  Interface)
  Dodatki
  Dodatki (ang. Addons) wykorzystują zasoby Kubernetesa
  DaemonSet
  Deployment
  itp.) do wdrażania funkcji klastra. Ponieważ zapewniają one
  funkcje na poziomie klastra, zasoby te należą do przestrzeni nazw
  kube-system
  Wybrane dodatki są opisane poniżej; aby uzyskać rozszerzoną listę
  dostępnych dodatków, zobacz
  Dodatki
  Podczas gdy inne dodatki nie są ściśle wymagane, wszystkie klastry Kubernetes powinny mieć
  DNS klastra
  , ponieważ wiele elementów na nim polega.
  Cluster DNS to serwer DNS, będący uzupełnieniem dla innych serwerów
  DNS w Twoim środowisku, który obsługuje rekordy DNS dla usług Kubernetes.
  Kontenery uruchamiane przez Kubernetesa automatycznie uwzględniają ten serwer DNS w swoich wyszukiwaniach DNS.
  Interfejs Web UI (Dashboard)
  Dashboard
  to uniwersalny interfejs
  internetowy dla klastrów Kubernetesa. Umożliwia użytkownikom zarządzanie
  i rozwiązywanie problemów z aplikacjami działającymi w klastrze, a także samym klastrem.
  Monitorowanie zasobów kontenerów
  Monitorowanie Zasobów Kontenera
  rejestruje ogólne
  metryki dotyczące kontenerów w centralnej bazie danych i udostępnia interfejs użytkownika do przeglądania tych danych.
  Rejestrowanie na poziomie klastra
  Mechanizm
  logowania na poziomie klastra
  jest
  odpowiedzialny za zapisywanie logów z kontenerów w centralnym magazynie logów z interfejsem do przeszukiwania/przeglądania.
  Wtyczki sieciowe
  Wtyczki sieciowe
  są komponentami oprogramowania, które implementują
  specyfikację interfejsu sieciowego kontenera (CNI). Są odpowiedzialne za
  przydzielanie adresów IP do podów i umożliwianie im komunikacji między sobą w klastrze.
  Warianty architektury
  Podczas gdy podstawowe komponenty Kubernetesa pozostają niezmienne, sposób ich
  wdrażania i zarządzania może się różnić. Zrozumienie tych wariacji jest kluczowe dla
  projektowania i utrzymania klastrów Kubernetesa, które spełniają określone potrzeby operacyjne.
  Opcje wdrażania warstwy sterowania
  Komponenty warstwy sterowania mogą być wdrażane na kilka sposobów:
  Tradycyjna implementacja: : Komponenty warstwy sterowania działają bezpośrednio na
  dedykowanych maszynach lub maszynach wirtualnych (VM), często zarządzane jako usługi systemd.
  Statyczne Pody: : Komponenty warstwy sterowania są wdrażane jako
  statyczne Pody, zarządzane przez kubelet na określonych węzłach.
  Jest to powszechne podejście stosowane przez narzędzia takie jak kubeadm.
  Samodzielnie hostowane : Warstwa sterowania działa jako Pody
  wewnątrz samego klastra Kubernetes, zarządzane
  przez Deploymenty i StatefulSety lub inne obiekty Kubernetesa.
  Zarządzane usługi Kubernetesa: Dostawcy usług chmurowych zazwyczaj
  ukrywają warstwę kontrolną, zarządzając jej elementami w ramach swoich usług.
  Rozważania dotyczące umieszczania workloadów
  Umiejscowienie workloadów, w tym komponentów warstwy sterowania, może różnić się w
  zależności od wielkości klastra, wymagań dotyczących wydajności i polityk operacyjnych:
  W mniejszych klastrach lub klastrach deweloperskich, komponenty warstwy sterowania i workloady użytkowników mogą działać na tych samych węzłach.
  Większe klastry produkcyjne często dedykują określone węzły dla
  komponentów warstwy sterowania, oddzielając je od workloadów użytkowników.
  Niektóre organizacje uruchamiają krytyczne dodatki lub narzędzia monitorujące na węzłach warstwy sterowania.
  Narzędzia do zarządzania klastrem
  Narzędzia takie jak kubeadm, kops i Kubespray oferują różne podejścia do wdrażania i
  zarządzania klastrami, z których każde ma własną metodę rozmieszczenia i zarządzania komponentami.
  Elastyczność architektury Kubernetesa umożliwia organizacjom dostosowanie ich klastrów do
  specyficznych potrzeb, balansując czynniki takie jak złożoność operacyjna, wydajność i narzut na zarządzanie.
  Dostosowywanie i rozszerzalność
  Architektura Kubernetesa pozwala na szeroką konfigurację:
  Niestandardowe schedulery mogą być wdrażane do pracy wraz z domyślnym schedulerem Kubernetesa lub aby całkowicie go zastąpić.
  Serwery API mogą być rozszerzane za pomocą CustomResourceDefinitions i agregacji API.
  Dostawcy chmury mogą mocno integrować się z Kubernetesem używając
  cloud-controller-manager
  Elastyczność architektury Kubernetesa umożliwia organizacjom dostosowanie ich klastrów do
  specyficznych potrzeb, balansując czynniki takie jak złożoność operacyjna, wydajność i narzut na zarządzanie.
  Co dalej?
  Dowiedz się więcej na temat:
  Węzły
  ich komunikacja
  warstwą sterowania.
  Kontrolery Kubernetesa
  kube-scheduler
  , czyli domyślny scheduler dla Kubernetesa.
  Oficjalna
  dokumentacja
  Etcd.
  Wiele
  środowisk uruchomieniowych kontenerów
  w Kubernetesie.
  Integracja z dostawcami chmury za pomocą
  cloud-controller-manager
  Polecenia
  kubectl
  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
  Zgłoś problem w
  repozytorium GitHuba
  , jeśli chcesz
  zgłosić problem
  Zaproponuj ulepszenie
  Ostatnia modyfikacja February 16, 2025 at 8:51 AM PST:
  [pl] docs/concepts/architecture/_index.md (77ed50249f)