instruction: Explain Kubernetes concepts and implementation details
output: jest najmniejszą jednostką obliczeniową, którą można utworzyć i zarządzać nią w Kubernetesie.
  (w języku angielskim: jak w odniesieniu do grupy wielorybów lub strąka grochu) to grupa jednego lub więcej
  kontenerów
  , z współdzielonymi zasobami pamięci i sieci, oraz specyfikacją
  dotyczącą sposobu uruchamiania kontenerów. Wszystkie komponenty Poda są uruchamiane razem, współdzielą ten sam kontekst i są
  planowane do uruchomienia na tym samym węźle. Pod modeluje specyficznego dla aplikacji "logicznego hosta": zawiera jeden lub więcej
  kontenerów aplikacji, które są stosunkowo ściśle ze sobą powiązane. W kontekstach niechmurowych, aplikacje
  wykonane na tej samej maszynie fizycznej lub wirtualnej są analogiczne do aplikacji chmurowych wykonanych na tym samym logicznym hoście.
  Oprócz kontenerów aplikacyjnych, Pod może zawierać
  kontenery inicjalizujące
  uruchamiane
  podczas startu Pod. Możesz również
  wstrzyknąć
  kontenery efemeryczne
  do debugowania działającego Poda.
  Czym jest Pod?
  Informacja:
  Musisz zainstalować
  środowisko uruchomieniowe kontenerów
  na każdym węźle w klastrze, aby mogły tam działać Pody.
  Wspólny kontekst Poda to zestaw przestrzeni nazw Linux, cgroups i potencjalnie innych aspektów izolacji - te
  same elementy, które izolują
  kontener (ang. container)
  W obrębie kontekstu Poda, poszczególne aplikacje mogą mieć dodatkowo zastosowane dalsze sub-izolacje.
  Pod jest podobny do zestawu kontenerów z współdzielonymi przestrzeniami nazw i współdzielonymi woluminami systemu plików.
  Pody w klastrze Kubernetesa są używane na dwa główne sposoby:
  Pody, które uruchamiają pojedynczy kontener
  . Model
  "jeden-kontener-na-Poda" jest najczęstszym przypadkiem użycia; w tym przypadku
  możesz myśleć o Podzie jako o obudowie wokół pojedynczego kontenera; Kubernetes
  zarządza Podami, zamiast zarządzać kontenerami bezpośrednio.
  Pody, które uruchamiają wiele kontenerów, które muszą współdziałać
  Pod może zawierać aplikację składającą się z
  wielu współlokalizowanych kontenerów
  które są ściśle powiązane i muszą współdzielić
  zasoby. Te współlokalizowane kontenery tworzą jedną spójną jednostkę.
  Grupowanie wielu współlokalizowanych i współzarządzanych kontenerów w jednym
  Podzie jest stosunkowo zaawansowanym przypadkiem użycia. Ten wzorzec powinieneś używać
  tylko w określonych przypadkach, gdy twoje kontenery są ściśle powiązane.
  Nie musisz uruchamiać wielu kontenerów, aby zapewnić replikację
  (dla odporności lub pojemności); jeśli potrzebujesz wielu replik,
  zobacz
  zarządzanie workloadami
  Używanie Podów
  Poniżej znajduje się przykład Poda, który składa się z kontenera uruchamiającego obraz
  nginx:1.14.2
  pods/simple-pod.yaml
  apiVersion
  kind
  metadata
  name
  nginx
  spec
  containers
  name
  nginx
  image
  nginx:1.14.2
  ports
  containerPort
  Aby utworzyć Pod pokazany powyżej, uruchom następujące polecenie:
  kubectl apply -f https://k8s.io/examples/pods/simple-pod.yaml
  Pody zazwyczaj nie są tworzone bezpośrednio tylko przy użyciu
  specjalnych zadań (workload). Zobacz
  Praca z Podami
  uzyskać więcej informacji na temat tego, jak Pody są używane z zasobami workload.
  Zasoby workload do zarządzania podami
  Zazwyczaj nie musisz tworzyć Podów bezpośrednio, nawet pojedynczych Podów. Zamiast tego,
  twórz je używając zasobów workload, takich jak
  Deployment
  . Jeśli Twoje Pody muszą
  śledzić stan, rozważ użycie zasobu
  StatefulSet
  Każdy Pod ma na celu uruchomienie pojedynczej instancji danej aplikacji. Jeśli
  chcesz skalować swoją aplikację horyzontalnie (aby zapewnić więcej zasobów ogółem
  poprzez uruchomienie większej liczby instancji), powinieneś użyć wielu Podów,
  jednego dla każdej instancji. W Kubernetesie, operację tę zazwyczaj określa się
  mianem
  replikacji
  . Replikowane Pody są zazwyczaj tworzone i zarządzane jako grupa
  przez zasób workload i jego
  kontroler
  Zobacz
  Pody i kontrolery
  , aby uzyskać więcej
  informacji na temat tego, jak Kubernetes wykorzystuje zasoby workload oraz ich kontrolery
  do implementacji skalowania aplikacji i automatycznego naprawiania.
  Pody natywnie zapewniają dwa rodzaje zasobów współdzielonych dla ich
  składowych kontenerów:
  sieć
  przechowywanie
  Praca z Podami
  Rzadko będziesz tworzyć indywidualne Pody bezpośrednio w Kubernetesie - nawet
  pojedyncze Pody. Dzieje się tak, ponieważ Pody są zaprojektowane jako stosunkowo efemeryczne,
  jednorazowe obiekty. Kiedy Pod zostaje utworzony (bezpośrednio przez Ciebie lub pośrednio przez
  kontroller
  ), nowy Pod jest
  planowany do uruchomienia na
  węźle
  Twoim klastrze. Pod pozostaje na tym węźle, dopóki nie zakończy wykonywania, obiekt Poda
  nie zostanie usunięty, Pod nie zostanie
  usunięty
  z powodu braku zasobów lub węzeł ulegnie awarii.
  Informacja:
  Restartowanie kontenera w Podzie nie powinno być mylone z
  restartowaniem Poda. Pod nie jest procesem, ale środowiskiem do
  uruchamiania kontenera(-ów). Pod trwa, dopóki nie zostanie usunięty.
  Nazwa Poda musi być prawidłową wartością
  poddomeny DNS
  , ale może to
  powodować nieoczekiwane skutki w odniesieniu do jego nazwy hosta. Dla najlepszej kompatybilności,
  nazwa powinna spełniać bardziej restrykcyjne zasady dla
  etykiety DNS
  System operacyjny Poda
  STATUS FUNKCJONALNOŚCI:
  Kubernetes v1.25 [stable]
  Powinieneś ustawić pole
  .spec.os.name
  windows
  linux
  , aby wskazać system
  operacyjny, na którym chcesz uruchomić swojego Poda. Są to jedyne obsługiwane systemy
  operacyjne przez Kubernetesa w chwili obecnej. W przyszłości lista ta może zostać rozszerzona.
  W Kubernetesie v1.33, wartość
  .spec.os.name
  nie wpływa na to, w jaki
  sposób
  kube-scheduler
  wybiera węzeł do uruchomienia Poda. W każdym klastrze, w którym istnieje więcej niż jeden
  system operacyjny dla działających węzłów, powinieneś poprawnie ustawić etykietę
  kubernetes.io/os
  na każdym węźle
  i zdefiniować Pody z
  nodeSelector
  opartym na etykiecie systemu operacyjnego.
  Kube-scheduler przypisuje Pody do węzłów na podstawie określonych kryteriów, ale nie zawsze
  gwarantuje wybór węzła z właściwym systemem operacyjnym dla uruchamianych kontenerów.
  Standardy bezpieczeństwa Pod
  również używają tego
  pola, aby uniknąć wymuszania polityk, które nie mają zastosowania dla danego systemu operacyjnego.
  Pody i kontrolery
  Możesz użyć zasobów workload do tworzenia i zarządzania wieloma Podami. Kontroler
  dla zasobu obsługuje replikację, wdrażanie oraz automatyczne naprawianie
  w przypadku awarii Poda. Na przykład, jeśli węzeł ulegnie
  awarii, kontroler zauważa, że Pody na tym węźle przestały działać i
  tworzy zastępczego Poda. Scheduler umieszcza zastępczego Poda na zdrowym węźle.
  Oto kilka przykładów zasobów workload, które zarządzają Podami:
  Deployment
  StatefulSet
  - komponent Kubernetesa służący do zarządzania aplikacjami stateful. StatefulSet zapewnia zachowanie kolejności i spójności danych w ramach aplikacji, co jest kluczowe dla usług wymagających takiego funkcjonowania. StatefulSet śledzi, które identyfikatory Podów są skojarzone z określonymi zasobami pamięci masowej i w jakiej kolejności powinny być tworzone oraz usuwane.
  DaemonSet
  Szablony Poda
  Kontrolery zasobów
  workload
  tworzą Pody z
  szablonu poda
  i zarządzają tymi Podami w Twoim imieniu.
  PodTemplates to specyfikacje do tworzenia Podów, które są
  uwzględniane w zasobach workload, takich jak
  Deployments
  Jobs
  DaemonSets
  Każdy kontroler dla zasobu workload używa
  PodTemplate
  wewnątrz obiektu
  workload do tworzenia rzeczywistych Podów.
  PodTemplate
  jest częścią pożądanego
  stanu dowolnego zasobu workload, którego użyłeś do uruchomienia swojej aplikacji.
  Gdy tworzysz Pod, możesz uwzględnić
  zmienne środowiskowe
  szablonie Poda dla kontenerów, które działają w Podzie.
  Poniższy przykład to manifest dla prostego zadania (Job) z
  szablonem (template)
  , który
  uruchamia jeden kontener. Kontener w tym Podzie wyświetla komunikat, a następnie się zatrzymuje.
  apiVersion
  batch/v1
  kind
  metadata
  name
  hello
  spec
  template
  # This is the pod template
  spec
  containers
  name
  hello
  image
  busybox:1.28
  command
  'sh'
  '-c'
  'echo "Hello, Kubernetes!" && sleep 3600'
  restartPolicy
  OnFailure
  # The pod template ends here
  Modyfikacja szablonu poda lub przejście na nowy szablon poda nie ma bezpośredniego
  wpływu na już istniejące Pody. Jeśli zmienisz szablon poda dla zasobu workload, ten zasób
  musi utworzyć nowe, zamienne Pody, które korzystają ze zaktualizowanego szablonu.
  Na przykład kontroler StatefulSet zapewnia, że uruchomione Pody odpowiadają bieżącemu
  szablonowi Poda dla każdego obiektu StatefulSet. Jeśli edytujesz StatefulSet, aby zmienić jego szablon,
  StatefulSet zaczyna tworzyć nowe Pody na podstawie zaktualizowanego szablonu.
  Ostatecznie, wszystkie stare Pody zostają zastąpione nowymi Podami, a aktualizacja jest zakończona.
  Każdy zasób workload implementuje własne zasady dotyczące obsługi zmian w szablonie Pod. Jeśli
  chcesz dowiedzieć się więcej o StatefulSet, zapoznaj się z
  strategią aktualizacji
  w samouczku podstawy StatefulSet.
  Na poziomie węzłów
  kubelet
  nie kontroluje bezpośrednio szczegółów dotyczących
  szablonów Podów ani ich aktualizacji – są one zarządzane na wyższym
  poziomie abstrakcji. Taka separacja upraszcza działanie systemu i
  pozwala na rozszerzanie funkcjonalności klastra bez ingerencji w istniejący kod.
  Aktualizacja i wymiana Poda
  Jak wspomniano w poprzedniej sekcji, gdy szablon Poda dla zasobu
  workload zostaje zmieniony, kontroler tworzy nowe Pody na podstawie
  zaktualizowanego szablonu zamiast aktualizować lub łatać istniejące Pody.
  Kubernetes nie uniemożliwia bezpośredniego zarządzania Podami.
  Możliwe jest aktualizowanie niektórych pól działającego Poda, na
  miejscu. Jednak operacje aktualizacji Poda, takie jak
  patch
  , oraz
  replace
  mają pewne ograniczenia:
  Większość metadanych o Podzie jest niezmienna. Na przykład, nie
  można zmienić pól
  namespace
  name
  creationTimestamp
  Jeśli parametr
  metadata.deletionTimestamp
  jest
  ustawiony, nie można dodać nowego wpisu do listy
  metadata.finalizers
  Aktualizacje Podów nie mogą zmieniać pól innych niż
  spec.containers[*].image
  spec.initContainers[*].image
  spec.activeDeadlineSeconds
  spec.terminationGracePeriodSeconds
  spec.tolerations
  spec.schedulingGates
  . Dla
  spec.tolerations
  można jedynie dodawać nowe wpisy.
  Podczas aktualizacji pola
  spec.activeDeadlineSeconds
  dozwolone są dwa typy aktualizacji:
  ustawienie nieprzypisanego pola na liczbę dodatnią;
  aktualizacja pola z liczby
  dodatniej do mniejszej, nieujemnej liczby.
  Podzasoby Poda
  Powyższe zasady aktualizacji dotyczą standardowych zmian w Podach, jednak niektóre pola Poda mogą być aktualizowane za pomocą
  podzasobów
  Zmiana rozmiaru:
  Podzasób
  resize
  umożliwia aktualizację zasobów kontenera (
  spec.containers [*].resources
  ). Szczegółowe informacje znajdują się w sekcji
  Zmiana rozmiaru zasobów kontenera
  Kontenery efemeryczne:
  Podzasób
  ephemeralContainers
  umożliwia
  dodanie do Poda
  kontenera efemerycznego
  Aby uzyskać więcej szczegółów zobacz
  Kontenery efemeryczne
  Status:
  Podzasób
  status
  umożliwia aktualizację statusu poda. Zazwyczaj
  jest to używane tylko przez Kubelet i kontrolery systemowe.
  Przypisanie Poda do węzła:
  Podzasób
  binding
  umożliwia ustawienie
  spec.nodeName
  poda za pomocą żądania typu
  Binding
  . Zazwyczaj jest to używane tylko przez
  kube-scheduler
  Generacja poda
  Pole
  metadata.generation
  jest unikatowe. Zostanie automatycznie ustawione przez
  system w taki sposób, że nowe pody będą miały ustawioną wartość
  metadata.generation
  1, a każda aktualizacja pól zmiennych w specyfikacji poda zwiększy
  metadata.generation
  o 1.
  STATUS FUNKCJONALNOŚCI:
  Kubernetes v1.33 [alpha]
  (enabled by default: false)
  Pole
  observedGeneration
  znajduje się w sekcji
  status
  obiektu typu Pod. Gdy aktywna
  jest opcja
  PodObservedGenerationTracking
  , Kubelet aktualizuje
  status.observedGeneration
  aby odzwierciedlało ono numer generacji (
  metadata.generation
  ) poda w chwili raportowania
  jego statusu. Dzięki temu możliwe jest powiązanie aktualnego stanu poda z wersją jego specyfikacji.
  Informacja:
  Pole
  status.observedGeneration
  jest zarządzane przez kubelet i zewnętrzne kontrolery
  nie powinny modyfikować
  tego pola.
  Różne pola statusu mogą być powiązane z
  metadata.generation
  bieżącej pętli synchronizacji lub z
  metadata.generation
  poprzedniej pętli synchronizacji. Kluczowa różnica polega na tym, czy zmiana w
  spec
  jest bezpośrednio odzwierciedlona w
  status
  , czy jest pośrednim wynikiem działającego procesu.
  Bezpośrednie aktualizacje statusu
  Dla pól statusu, gdzie przydzielona specyfikacja jest odzwierciedlona bezpośrednio,
  observedGeneration
  będzie powiązane z bieżącym
  metadata.generation
  (Generacja N).
  To zachowanie dotyczy:
  Statusu zmiany przydzielonych zasobów
  : Status operacji zmiany rozmiaru zasobu.
  Przydzielonych zasobów
  : Zasoby przydzielone do Poda po zmianie rozmiaru.
  Kontenerów efemerycznych
  : Gdy nowy tymczasowy kontener zostaje dodany i znajduje się w stanie
  Waiting
  Pośrednie aktualizacje statusu
  Dla pól statusu, które są pośrednim wynikiem wykonania specyfikacji, pole
  observedGeneration
  będzie powiązane z wartością z
  metadata.generation
  z poprzedniej pętli synchronizacji (Generacja N-1).
  To zachowanie dotyczy:
  Obrazu Kontenera
  : pole
  ContainerStatus.ImageID
  odzwierciedla obraz z
  poprzedniej generacji do momentu pobrania nowego obrazu i zaktualizowania kontenera.
  Rzeczywiście używanych zasobów
  : Podczas trwającej zmiany rozmiaru,
  faktycznie wykorzystywane zasoby nadal odpowiadają żądaniu z poprzedniej generacji.
  Stanu kontenera
  : Podczas trwającej zmiany rozmiaru z wymaganą
  polityką restartu, stan kontenera odzwierciedla żądanie z poprzedniej generacji.
  activeDeadlineSeconds
  terminationGracePeriodSeconds
  oraz
  deletionTimestamp
  Zmiany w statusie poda wynikające z tych pól odnoszą się do specyfikacji z poprzedniej generacji.
  Udostępnianie zasobów i komunikacja
  Pody umożliwiają udostępnianie danych i
  komunikację pomiędzy swoimi składowymi kontenerami.
  Pamięć masowa w Podach
  Pod może określić zestaw współdzielonych zasobów pamięci masowej
  woluminów
  ). Wszystkie
  kontenery w Podzie mają dostęp do tych woluminów, co umożliwia im
  współdzielenie danych. Woluminy pozwalają również na utrzymanie danych w Podzie,
  nawet jeśli jeden z jego kontenerów wymaga ponownego uruchomienia. Zobacz
  sekcję
  Storage
  , aby dowiedzieć się więcej o
  tym, jak Kubernetes implementuje współdzieloną pamięć masową i udostępnia ją Podom.
  Sieci Poda
  Każdy Pod ma przypisany unikalny adres IP dla każdej rodziny adresów. Każdy kontener
  w Podzie dzieli przestrzeń nazw sieci, w tym adres IP i porty
  sieciowe. Wewnątrz Poda (i
  tylko
  wtedy) kontenery, które należą do Poda
  mogą komunikować się ze sobą za pomocą
  localhost
  . Kiedy kontenery w Podzie
  komunikują się z jednostkami
  poza Podem
  , muszą koordynować sposób
  korzystania ze wspólnych zasobów sieciowych (takich jak porty). W ramach Poda,
  kontenery dzielą adres IP i przestrzeń portów, i mogą znaleźć się nawzajem za
  pośrednictwem
  localhost
  . Kontenery w Podzie mogą również komunikować się
  między sobą za pomocą standardowych komunikatów międzyprocesowych, takich
  jak semafory SystemV lub współdzielona pamięć POSIX. Kontenery w różnych
  Podach mają różne adresy IP i nie mogą komunikować się poprzez IPC na poziomie systemu
  operacyjnego bez specjalnej konfiguracji. Kontenery, które chcą
  nawiązać interakcję z kontenerem działającym w innym Podzie, mogą używać sieci IP do komunikacji.
  Kontenery w ramach Pod mają tę samą nazwę hosta systemowego, co
  skonfigurowane
  name
  dla Pod. Więcej na ten temat znajduje się w sekcji
  sieci
  Ustawienia zabezpieczeń Poda
  Aby ustawić ograniczenia bezpieczeństwa na Podach i kontenerach, używasz
  pola
  securityContext
  w specyfikacji Poda. To pole daje Ci szczegółową
  kontrolę nad tym, co Pody lub poszczególne kontenery mogą robić. Na przykład:
  Usunąć specyficzne uprawnienia Linuxa, aby uniknąć podatności CVE.
  Wymusić, aby wszystkie procesy w Podzie były uruchamiane jako użytkownik
  nie-root lub jako określony ID użytkownika lub grupy.
  Ustawić konkretny profil seccomp.
  Ustawić opcje bezpieczeństwa systemu Windows, takie jak to, czy kontenery działają jako HostProcess.
  Uwaga:
  Możesz również użyć
  securityContext
  dla Poda, aby włączyć
  tryb uprzywilejowany
  kontenerach Linux. Tryb uprzywilejowany nadpisuje wiele innych ustawień
  bezpieczeństwa w
  securityContext
  . Unikaj używania tego ustawienia, chyba że nie
  możesz przyznać równoważnych uprawnień, korzystając z innych pól w
  securityContext
  . W Kubernetesie
  1.26 i nowszych, możesz uruchamiać kontenery Windows w podobnie
  uprzywilejowanym trybie, ustawiając flagę
  windowsOptions.hostProcess
  w kontekście
  bezpieczeństwa w specyfikacji Poda. Aby uzyskać szczegóły i instrukcje, zobacz
  Utwórz Pod HostProcess w Windows
  Aby dowiedzieć się o ograniczeniach bezpieczeństwa na poziomie jądra, które można użyć, zobacz
  Ograniczenia bezpieczeństwa jądra Linux dla Podów i kontenerów
  Aby dowiedzieć się więcej na temat kontekstu bezpieczeństwa Poda, zobacz
  Konfigurowanie kontekstu bezpieczeństwa dla Poda lub kontenera
  Statyczne Pody
  Statyczne Pody
  są zarządzane bezpośrednio przez demona kubelet na
  określonym węźle, bez nadzoru przez
  serwer API
  Podczas gdy większość Podów jest zarządzana przez warstwę
  sterowania (na przykład przez
  Deployment
  ), w przypadku statycznych Podów to kubelet
  bezpośrednio nadzoruje każdy statyczny Pod (i restartuje go, jeśli ulegnie awarii).
  Statyczne Pody są zawsze powiązane z jednym komponentem
  Kubelet
  na konkretnym węźle.
  Głównym zastosowaniem statycznych Podów jest uruchamianie samodzielnie hostowanej warstwy sterowania: innymi słowy, użycie
  kubeleta do nadzorowania poszczególnych
  komponentów warstwy sterowania
  Kubelet automatycznie próbuje utworzyć
  Pod lustrzany
  na serwerze API Kubernetesa dla każdego
  statycznego Poda. Oznacza to, że Pody działające na węźle są widoczne na serwerze
  API, ale nie mogą być z niego kontrolowane. Więcej informacji znajdziesz w
  przewodniku
  Tworzenie statycznych Podów
  Informacja:
  spec
  statycznego Poda nie może odwoływać się do innych obiektów
  API (np.
  ServiceAccount
  ConfigMap
  Secret
  , itp.).
  Pody z wieloma kontenerami
  Pody są zaprojektowane do obsługi wielu współpracujących procesów (jako
  kontenery), które tworzą spójną jednostkę usługi. Kontenery w Podzie są
  automatycznie współlokowane i współharmonogramowane na tej samej fizycznej
  lub wirtualnej maszynie w klastrze. Kontenery mogą współdzielić zasoby i
  zależności, komunikować się ze sobą oraz koordynować, kiedy i jak są zakończane.
  Pody w klastrze Kubernetesa są używane na dwa główne sposoby:
  Pody, które uruchamiają pojedynczy kontener
  . Model
  "jeden-kontener-na-Poda" jest najczęstszym przypadkiem użycia; w tym przypadku
  możesz myśleć o Podzie jako o obudowie wokół pojedynczego kontenera; Kubernetes
  zarządza Podami, zamiast zarządzać kontenerami bezpośrednio.
  Pody, które uruchamiają wiele kontenerów, które muszą współpracować
  Pod może zawierać aplikację składającą się z
  wielu współlokalizowanych kontenerów, które są ściśle
  powiązane i muszą współdzielić zasoby. Te współlokalizowane
  kontenery tworzą jedną spójną jednostkę usługi - na przykład,
  jeden kontener udostępniający dane przechowywane we
  współdzielonym wolumenie publicznym, podczas gdy osobny
  kontener sidecar
  odświeża
  lub aktualizuje te pliki. Pod łączy te kontenery,
  zasoby pamięci, oraz efemeryczną tożsamość sieciową razem jako jedną jednostkę.
  Na przykład, możesz mieć kontener, który działa jako serwer webowy dla
  plików we współdzielonym wolumenie oraz oddzielny
  kontener pomocniczy (ang. sidecar container)
  , który aktualizuje
  te pliki z zewnętrznego źródła, jak pokazano na poniższym diagramie:
  Niektóre Pody mają
  kontenery inicjujące
  oraz
  kontenery aplikacji
  . Domyślnie,
  kontenery inicjujące uruchamiają się i kończą przed startem kontenerów aplikacji.
  Możesz również mieć
  kontenery pomocnicze
  które świadczą usługi pomocnicze dla głównej aplikacji w Podzie.
  STATUS FUNKCJONALNOŚCI:
  Kubernetes v1.33 [stable]
  (enabled by default: true)
  Domyślnie włączona bramka funkcji
  SidecarContainers
  feature gate
  pozwala na określenie
  restartPolicy: Always
  dla kontenerów inicjalizacyjnych. Ustawienie
  polityki restartu
  Always
  zapewnia, że kontenery, dla których ją ustawisz, są
  traktowane jako
  sidecar
  i są utrzymywane w działaniu przez cały czas życia
  Poda. Kontenery, które określisz jako kontenery sidecar, uruchamiają się przed
  główną aplikacją w Podzie i pozostają uruchomione do momentu, gdy Pod zostanie zamknięty.
  Kontenerowe sondy (ang. Container probes)
  Sonda (ang. probe)
  to diagnostyka wykonywana okresowo przez kubelet na
  kontenerze. Aby przeprowadzić diagnostykę, kubelet może wywoływać różne akcje:
  ExecAction
  (wykonywane za pomocą środowiska uruchomieniowego kontenera)
  TCPSocketAction
  (sprawdzane bezpośrednio przez kubelet)
  HTTPGetAction
  (sprawdzane bezpośrednio przez kubelet)
  Możesz przeczytać więcej o
  sondach
  w dokumentacji cyklu życia Poda.
  Co dalej?
  Dowiedz się więcej o
  cyklu życia Poda
  Dowiedz się o
  RuntimeClass
  i o tym, jak
  możesz go użyć do konfigurowania różnych Podów z różnymi konfiguracjami runtime kontenerów.
  Przeczytaj o
  PodDisruptionBudget
  dowiedz się, jak możesz go używać do zarządzania dostępnością aplikacji podczas zakłóceń.
  Pod jest zasobem najwyższego poziomu w REST API
  Kubernetesa. Definicja obiektu
  opisuje szczegółowo ten obiekt.
  Toolkit systemu rozproszonego: Wzorce dla kontenerów złożonych
  wyjaśnia typowe układy dla Podów z więcej niż jednym kontenerem.
  Przeczytaj o
  ograniczeniach topologii Podów
  Aby zrozumieć kontekst, dlaczego Kubernetes opakowuje wspólne API Poda
  w inne zasoby (takie jak
  StatefulSets
  Deployments
  możesz przeczytać o wcześniejszych rozwiązaniach, w tym:
  Aurora
  Borg
  Marathon
  Omega
  Tupperware
  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 August 09, 2025 at 3:22 PM PST:
  [pl] sync with PR 51371 (bbe17fcc65)