Workload

• 1: Pod
• 2: Zarządzanie Workloadem

1 - Pod

Pod jest najmniejszą jednostką obliczeniową, którą można utworzyć i zarządzać nią w Kubernetesie.

Pod (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?

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: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80

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 aby 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 lub Job. 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ć i 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 w 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.

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

Powinieneś ustawić pole .spec.os.name na windows lub 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 i 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 w 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: Job
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, uid ani creationTimestamp; pole generation jest unikalne. Akceptuje tylko aktualizacje, które zwiększają bieżącą wartość pola.

• 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 lub spec.tolerations. Dla spec.tolerations można jedynie dodawać nowe wpisy.

• Podczas aktualizacji pola spec.activeDeadlineSeconds dozwolone są dwa typy aktualizacji:

  1. ustawienie nieprzypisanego pola na liczbę dodatnią;
  2. aktualizacja pola z liczby dodatniej do mniejszej, nieujemnej liczby.

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.

• 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ć mirror Pod 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.

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.

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 i 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 Pod 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 lub Deployments), możesz przeczytać o wcześniejszych rozwiązaniach, w tym:

• Aurora
• Borg
• Marathon
• Omega
• Tupperware.

2 - Zarządzanie Workloadem

Kubernetes udostępnia kilka wbudowanych interfejsów API do deklaratywnego zarządzania Twoim workloadem oraz jego komponentami.

Twoje aplikacje działają jako kontenery wewnątrz Podów; jednakże zarządzanie pojedynczymi Podami wiąże się z dużym wysiłkiem. Na przykład, jeśli jeden Pod ulegnie awarii, prawdopodobnie będziesz chciał uruchomić nowy Pod, aby go zastąpić. Kubernetes może to zrobić za Ciebie.

Używasz API Kubernetesa aby utworzyć obiekt zadania (workload), który reprezentuje wyższy poziom abstrakcji niż Pod, a następnie warstwa sterowania Kubernetesa automatycznie zarządza obiektami Pod w Twoim imieniu, na podstawie specyfikacji zdefiniowanego przez Ciebie obiektu tego workloadu.

Wbudowane interfejsy API do zarządzania workloadami to:

Deployment (oraz pośrednio ReplicaSet), to najczęstszy sposób uruchamiania aplikacji w klastrze. Deployment jest odpowiedni do zarządzania aplikacją bezstanową w klastrze, gdzie każdy Pod w Deployment jest wymienny i może być zastąpiony w razie potrzeby. (Deploymenty zastępują przestarzałe ReplicationController API).

StatefulSet pozwala na zarządzanie jednym lub wieloma Podami – wszystkie uruchamiają ten sam kod aplikacji – gdzie Pody opierają się na posiadaniu unikalnej tożsamości. Jest to inne niż w przypadku Deployment, gdzie oczekuje się, że Pody są wymienne. Najczęstszym zastosowaniem StatefulSet jest możliwość powiązania jego Podów z ich trwałą pamięcią masową. Na przykład, można uruchomić StatefulSet, który kojarzy każdy Pod z PersistentVolume. Jeśli jeden z Podów w StatefulSet ulegnie awarii, Kubernetes tworzy zastępczy Pod, który jest połączony z tym samym PersistentVolume.

DaemonSet definiuje Pody, które zapewniają funkcje lokalne dla określonego węzła; na przykład sterownik, który umożliwia kontenerom na tym węźle dostęp do systemu przechowywania danych. DaemonSet jest wykorzystywany w sytuacjach, gdy sterownik lub inna usługa na poziomie węzła musi działać na konkretnym węźle. Każdy Pod w DaemonSet pełni rolę podobną do demona systemowego na klasycznym serwerze Unix / POSIX. DaemonSet może być kluczowy dla działania twojego klastra, na przykład jako wtyczka, która pozwala temu węzłowi uzyskać dostęp do sieci klastrowej, może pomóc w zarządzaniu węzłem albo zapewnia mniej istotne funkcje, które wzbogacają używaną platformę kontenerową. Możesz uruchamiać DaemonSety (i ich pody) na każdym węźle w twoim klastrze, lub tylko na podzbiorze (na przykład instalując sterownik GPU tylko na węzłach, które mają zainstalowany GPU).

Możesz użyć Job i/lub CronJob do zdefiniowania zadań, które działają do momentu ukończenia, a następnie się zatrzymują. Job reprezentuje jednorazowe zadanie, podczas gdy każdy CronJob powtarza się zgodnie z harmonogramem.

Inne tematy w tej sekcji: