Pod

• Podstawowa, najniższa zarządzana jednostka
• Składa sięz jednego lub wielu kontenerów, które współdzielą między sobą sieć
• Każdy pod ma unikalny adres IP w ramach klastra
• kontenery które znajdują się w podzie współdzielą sieć/zakres portów, storage, reasource na nodzie na którym się znajdują (jak np ilośc procesora, pamięć RAM), na zewnątrz udostępniają porty
• usunięcie poda spowoduje usunięcie kontenerów w nim się znajdujących
• nie da się usuwać kontenerów z poda, należy usunąć całego poda
• jest efemeryczny - nietrwały

Cykl życia podów

• Pending Kubernetes przyjął definicję ale trwa tworzenie obiektu/przydzielanie do serwera
• Running W pełni działający pod, kontenery wewnątrz poda działają, conajmniej jeden kontener działa
• Succeeded Exit code=0 zwrócone do konsoli, wszystki kontenery zakończyły pracą
• Failed Wystąpił problem w przynajmniej jednym kontenerze w podzie (zakończył pracę ze złym kodem)

• Unknown Nieokreślony, nieznany stan poda

• Typy w PodStatus (wartości: true/false):
  • PodScheduled pod został przypisany do węzła
  • Ready pod jest gotowy do przyjęcia ruchu
  • Initialized wszystkie kontenery typu Init wystartowały
  • Unschedulable nie można przypisać poda do węzła
  • ContainersReady wszystkie kontenery w podzie wystartowały i są gotowe

Default grace period

• kontener dostaje sygnał SIGTERM przy jego usuwaniu
• kiedy minie grace period (domyślnie 30s) to wszystkie procesy są zabijane za pomocą sygnału SIGKILL
• czas graceperiod można zmienić za pomocą terminationGracePeriodSeconds w definicji poda

Init Containers

• Specjalne kontenery uruchamiane przed uruchomieniem kontenerów w podzie
• Uruchomienie każdego z nich musi zakończyć się sukcesem
• Wykorzystywane przy np. pobieranie danych repo/konfiguracji/modelu ML, uruchomienie migracji schematu bazy danych
• Przykładowy plik YAML z Init Containers

Container Probes

Diagnowstyka uruchamiana okreowo przez kubelet na kontenerze. W celu wykonania diagnostyki, kubelet odpytuje Handler zaimplementowany przez kontener Zapewnia, że proces jest uruchomiony. Jeśli zauważy, że kontener nie jest w stanie Running lub Succeded automatycznie wykona jego restart.

Stany: Success, Failure, Unknown

Typy:

• ExecAction wykonuje określoną komendę w kontenerze i sprawdza czy exit code==0
• TCPSocketAction odpytanie TCP do określonego adresu oraz portu kontenera i sprawdza czy port jest otwarty
• HTTPGetAction wykonuje zapytanie do określonego IP, portu oraz ścieżki w kontenerze. Zapytanie uważane jest za udane jeśli kod odpowiedzie mieści się pomiędzy <200,400).

Konfiguracja sond:

• initialDelaySeconds czas jaki musi minąć po uruchomieniu kontenera/aplikacji do inicjalizacji Liveness/Readiness Probe
• periodSeconds czas pomiędzy kolejnymi testami [10s] [min. 1s]
• timeoutSeconds timeout próby [1s] [min. 1s]
• successTreshold minimalna ilość prób do określenia statusu success
• failureTreshold ilość prób restartu

Liveness Probe

Określa czy kontener działa. Definicję sondy dołączamy do definicji poda i dotyczyć może każdego z naszych kontenerów. Jeśli próbka nie powiedzie się to Kubernetes automatycznie zrestartuje kontener.

Readiness Probe

Sprawdza czy kontener jest w stanie dostarczać odpowiedzi (przyjąć ruch przychodzący). Jeśli nie jego, to kontener jest odpinany z serwisu ponad podem i ruch nie jest do niego kierowany.

Kubelet

• Zajmuje się wywołaniami health ckeck
• Odpowiada za wszystko co dzieje się na węźle
• Jedyny komponent, który nie jest zainstalowany w kontenerze
• Agent zainstalowany na każdym z nodów
• Polityka PodSpec restartów restartPolicy:
  • Always domyślnie - niezależnie od kodu
  • OnFailure kod wyjścia inny niż 0
  • Never
• restartPolicy odnosi się do restartowania kontenerów przez kubelet tylko na tym samym nodzie, restart jest wykładniczy 10s, 20, 40s, ograniczony do 5 min.

Labels

Odpowiednik tagów w Azure.

• key:value

• pod_labels.yaml
• kubectl apply -f pod_labels.yaml
• kubectl get pods --show-labels wyświetlenie podów z labelkami
• kubectl get pod -l env=dev --show-labels filtrowanie zasobów
• kubectl delete pod -l env=dev

Annotations

• pozwalają przechowywać dane w postaci key:value
• nie identyfikuje obiektu, a bardziej określa jego pochodzenie lub przeznaczenie
• zacząć od adnotacji i jeśli będzie konieczne aby wpisy były wykorzystywane w mechanizmah selektujących wtedy należy je przenieść do labeli

YAML

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80

• apiVersion wersja API Kubernetesa
• kind Typ obiektu
• spec Specyfikacja określająca jaki kontener (lub kilka) chcemy uruchomić w naszym środowisku
• imagePullPolicy w jaki sposób pobrać obraz:
  • IfNotPresent (domyślne)
  • Always
  • Never
• resources limity zasobów dla kontenera
• ports udostępniane porty na zewnątrz
• command przekazanie polecenia

kubectl create -f pod.yaml Utworzenie poda z pliku

kubectl create -f pod.yaml --save-config=true utworzenie poda z pliku z zapamiętaną konfiguracją - konfiguracja obiektu zostanie zapisana w annotacjach, pozwala na zaktualizowanie definicji

kubectl apply -f pod.yaml Utworzenie lub update poda z pliku

kubectl replace -f pod.yaml zamiana poda, usuwa obecny i tworzy nowy

Praca imperatywna

kubectl run NAME --image=IMAGE --generator=run-pod/v1

kubectl run NAME --image=IMAGE --restart=Never

kubectl run busybox --image=busybox --restart=Never --dry-run -o yaml > pod2.yaml

Kubernetes pods life

lifecycle:
  postStart:
    exec:
      command: komenda
  preStop:
    exec:
      command: komenda

Zasoby

• Requests zasoby potrzebne do startu kontenera
• Limits maksymalne zasoby przydzielone kontenerowi
  • CPU - jaką część procesora przydzielić. 1 oznacza cały widoczny rdzeń w systemie operacyjnym. Min=0.1
  • RAM - wyrażany w bajtach.

Quality of Service

• Guaranteed gwarantowana
• Burstable mogąca powiększać swoje zasoby do określonego limitu
• BestEffort Kubernetes postara się przydzielić jak najlepiej zasoby aplikacji