Konrad Kowalski (rootsher)Principal Platform & Reliability Architect000010110100100000110111000000101100010100000110

Worker Node i Data Plane

data
kategoria
Containers
czytanie
2 min / 416 słów

Control plane podejmuje decyzje, ale ktoś musi je jeszcze wykonać.

Tym właśnie zajmuje się data plane.

Najważniejszym elementem data plane jest worker node, czyli maszyna, na której uruchamiane są Pody i kontenery.

Na każdym node znajdziemy kilka kluczowych elementów:

  • kubelet,
  • container runtime,
  • komponenty sieciowe,
  • uruchomione Pody.

Kubelet: agent na każdym node

kubelet to proces działający na worker node.

Jego głównym zadaniem jest pilnowanie, aby Pody przypisane do tego node faktycznie działały.

Kubelet obserwuje stan klastra przez API Server i sprawdza, czy pojawiły się obiekty przypisane właśnie do jego node.

Można uprościć to do:

text
API Server
   |
   v
kubelet
   |
   v
container runtime

Jeśli scheduler zdecyduje:

text
Pod X -> Node 2

kubelet na Node 2 zobaczy tę informację i rozpocznie realizację zadania.

Co robi kubelet

Kubelet odpowiada m.in. za:

  • obserwowanie Podów przypisanych do node,
  • uruchamianie i zatrzymywanie kontenerów przez runtime,
  • raportowanie stanu node,
  • raportowanie statusu Podów,
  • wykonywanie części health checków,
  • pilnowanie zgodności lokalnego stanu z deklaracją.

Kubelet jest więc swego rodzaju lokalnym wykonawcą Kubernetes na każdej maszynie.

Container runtime

Kubelet sam nie uruchamia kontenera.

Do tego potrzebny jest container runtime.

Najczęściej spotykane rozwiązania to:

  • containerd,
  • CRI-O.

Runtime odpowiada za faktyczną obsługę cyklu życia kontenera:

  • utworzenie,
  • start,
  • stop,
  • usunięcie.

CRI: warstwa pomiędzy kubeletem a runtime

Kubernetes nie chce być bezpośrednio związany z jednym konkretnym runtime.

Dlatego używa CRI (Container Runtime Interface).

Schemat:

text
kubelet
  |
  v
 CRI
  |
  v
containerd / CRI-O

CRI jest kontraktem.

Kubelet mówi, czego potrzebuje, a runtime implementuje odpowiednie operacje.

Dzięki temu Kubernetes może działać z różnymi runtime'ami bez przebudowy całego systemu.

Kubernetes a Docker

To miejsce, w którym często pojawia się pytanie:

Czy Kubernetes używa Dockera?

Historycznie Docker był bardzo często używany w środowiskach Kubernetes.

Obecnie typowym runtime jest np. containerd.

To nie oznacza, że obrazy budowane przez Docker przestały działać.

Format obrazów opiera się na standardach OCI, więc obraz zbudowany narzędziem Docker może zostać uruchomiony przez containerd.

Warto rozdzielić:

text
Docker CLI
Docker Engine
container image
container runtime

To nie są dokładnie te same rzeczy.

Co dzieje się po przypisaniu Poda

Załóżmy, że scheduler wybrał node.

Dalej:

  1. informacja o przypisaniu znajduje się w API,
  2. kubelet na odpowiednim node ją zauważa,
  3. kubelet prosi runtime o przygotowanie kontenerów,
  4. networking zostaje skonfigurowany,
  5. kontenery są uruchamiane,
  6. kubelet raportuje status.

W skrócie:

text
scheduler
   |
   v
wybrany node
   |
   v
kubelet
   |
   v
container runtime
   |
   v
container

Czy worker node musi być VM?

Nie.

Worker node może być:

  • maszyną wirtualną,
  • fizycznym serwerem,
  • instancją w public cloud.

Dla Kubernetes najważniejsze jest to, że node działa jako maszyna wykonawcza i ma odpowiednie komponenty.

Co zapamiętać

Najprostszy podział wygląda tak:

text
scheduler
-> wybiera node

kubelet
-> pilnuje Poda na node

container runtime
-> uruchamia kontenery

Te trzy role są często mylone, ale odpowiadają za zupełnie inne etapy procesu.