Pod to najmniejsza jednostka, jaką możesz wdrożyć w Kubernetes. Nie wrzucasz tam pojedynczego kontenera „luzem” — zawsze pakujesz go w Poda, czyli opakowanie grupujące jeden lub więcej kontenerów, które współdzielą tę samą przestrzeń sieciową (jeden adres IP, te same porty) oraz wolumeny. Mówiąc obrazowo: kontener to lokator, a Pod to mieszkanie, w którym ten lokator faktycznie mieszka. Kubernetes nie zarządza kontenerami bezpośrednio — zarządza właśnie Podami.
Jak to działa
Kontenery w jednym Podzie dzielą localhost i mogą się ze sobą komunikować tak, jakby działały na tej samej maszynie. Dzielą też zamontowane wolumeny, więc łatwo wymieniają się plikami. To dlatego do Poda wkłada się rzeczy ściśle ze sobą powiązane — najczęściej jeden kontener główny plus pomocniczy (tzw. sidecar), na przykład aplikację i obok niej kontener zbierający jej logi.
Pod jest z założenia efemeryczny — to byt jednorazowy. Gdy padnie, Kubernetes nie reanimuje tego samego Poda, tylko tworzy nowy, z nowym IP. Dlatego w praktyce prawie nigdy nie tworzysz Podów ręcznie. Robisz to przez kontrolery wyższego poziomu — najczęściej Deployment, który pilnuje, żeby przez cały czas działała zadana liczba replik. Stałe wejście do aplikacji daje natomiast Service, bo na zmieniające się IP Podów nie ma co liczyć.
Przykład z praktyki
Najszybciej zobaczysz Poda tak. Uruchamiasz jednego nginx-a poleceniem kubectl run web --image=nginx, a potem sprawdzasz, co się dzieje, przez kubectl get pods. Zobaczysz status w stylu Running albo, gdy coś nie gra, klasyki typu CrashLoopBackOff czy ImagePullBackOff. Do podejrzenia szczegółów i zdarzeń służy kubectl describe pod web, a logi wyciągniesz przez kubectl logs web. W realnym projekcie Pody definiujesz jednak w pliku YAML jako szablon wewnątrz Deploymentu — nie klikasz ich pojedynczo.
Częste błędy i mity
Pierwszy mit: „Pod to to samo co kontener”. Nie — Pod może mieć kilka kontenerów, choć w zdecydowanej większości przypadków ma jeden. Drugi błąd: traktowanie Poda jak trwałej maszyny. Jeśli zapiszesz coś do lokalnego systemu plików kontenera i Pod się odtworzy, dane znikają — od tego są PersistentVolume. Trzeci klasyk: tworzenie Podów ręcznie zamiast przez Deployment. Taki „goły” Pod po awarii węzła nie wróci, bo nikt nad nim nie czuwa. I czwarty: wpychanie do jednego Poda usług, które wcale nie muszą żyć razem — wtedy nie da się ich skalować niezależnie.
Pojęcia powiązane
Warto kojarzyć Poda z: kontener, Deployment, ReplicaSet, Service, Node, kubectl, sidecar oraz namespace. To one tworzą codzienny krajobraz pracy z Kubernetesem.