Kubernetes objekty

Úvod

Kubernetes obsahuje mnoho objektů, které slouží pro chod celého Kubernetes clusteru. Pro plné využití potenciálu Kubernetes clusteru je vhodné mít alespoň základní přehled o hlavních objektech, se kterými budete pracovat. V tomto článku si projdeme některé z nich společně s jejich základní definicí.

Pod

Základní stavební kámen všech dalších objektů. Pokud přecházíte z Dockeru, tak se může hodit přirovnání ke kontejneru. Je zde ovšem jeden zásadní rozdíl, a to ten, že pod může obsahovat množinu těchto kontejnerů, a navíc obsahuje i sdílenou síť, případně i storage. Pod se umisťuje vždy na logického hosta kvůli úzké komunikaci komponent v rámci podu. Komunikace mezi kontejnery v podu pak může, mimo jiné, probíhat i přes localhost. Vystihující vlastností podu je pak jeho neperzistentnost/efemérnost. Pokud dojde k jeho ukončení, tak vždy dojde při jeho novém vytvoření „ke startu od začátku“, zahrnující i nové UUID podu.

Volumes

Základní vlastností je sdílení datového úložiště napříč kontejnery v podu. Životnost volume je stejná jako životnost podu. V K8s existuje několik druhů volumes, které dokážou být i perzistentní. Pod může navíc použít hned několik volumes zároveň.

Zajímavým typem je Kubernetes Secret Volume. Ten slouží pro uchování důvěrných dat jako jsou například uživatelské klíče, hesla, sessiony atd. Jedná se o bezpečnější způsob, jak zahrnnout do aplikace citlivé údaje a vyhnout se jejich umístění například přímo v podu. Protože jednotlivé secret objekty existují nezávisle na podech, hrozí minimální riziko narušení bezpečnosti uchovávaných informací během práce s pody.

Dalším často používaným volume typem je Kubernetes ConfigMap. Slouží pro zahrnutí definované konfigurace do podu. Stačí tedy jednoduše na úrovni podu/deploymentu nastavit jméno naši ConfigMapy a dojde k zahrnutí do konfigurace podu do specifikovaného umístění.

Nemůžeme vynechat ani PersistentVolumeClaim, který mountuje PersistentVolume napřímo do podů. Je tedy ve většině mezičlánkem mezi persistentním uložištěm (NFS/iSCSI/Fibre channel, …) a koncovým připojením do cíleného podu.

ReplicaSet

Hlavním úkolem ReplicaSet kontroleru je spravovat konkrétní počet běžících podů. Jinak řečeno slouží pro zajištění běhu specifikovaného počtu identických podů. Zajišťuje tedy jak dostupnost, tak i výkon. Jeho použití je typicky až na vyšší úrovni než na přímo.

Deployments

Deployment kontroler nám umožňuje souhrnně spravovat pody a ReplicaSet, tedy jejich počet. Jednoduchým navýšením konfigurace replicas okamžitě docílíte navýšením počtu podů, tedy základní funkcionalitu škálovatelnosti vaší aplikace. Toto je pouze základní použití. Deployment můžeme použít k mnoha dalším operacím jako je například hromadný update podů, rollback na předchozí verzi, hromadné zastavení podů a další.

DaemonSets

DaemonSet je nástrojem, kterým lze jednoduše docílit běhu podu na všech Kubernetes nodech clusteru. Případně toho lze docílit i přes pravidla běhu na námi definovaných nodech. Pokud připojíme do běžícího clusteru další Kubernetes node, tak dojde k automatickému přidání podu na tyto nody. V opačném případě dochází společně s odebráním nodu z clusteru i ke smazání bežícího podu. Typické použití je například běh log daemona pro zajištění logů kompletně z celého clusteru.

Kubernetes Services

Service je abstrakce, která definuje logický shluk podů a pravidla, jak na ně přistoupit. Je to uživatelsky jednoduchá cesta jak vystavit aplikaci jako síťově dostupnou službu. Zároveň pracuje jako chytrý balancer mezi pody, které jsou nestálé – dynamicky se mění jejich počet a stav. Kubernetes totiž automaticky přiřazuje podu vlastní interní IP adresu a záznam v DNS pro podmnožinu podů. Mezi nimi poté dochází k balancingu provozu a v základním pohledu i zajišťuje jejich samotnou dostupnost. V samotné specifikaci poté určujete, na který port aplikace (podu) se má service připojovat a na druhé straně hlavně, na kterém portu chcete mít aplikaci přes service dostupný. Pokud tedy chcete měnit port aplikace, nemusíte zasahovat přímo do ní, ale můžete úpravu provést na této úrovni komunikace.

Existují 4 typy services: ClusterIP, NodePort, LoadBalancer a ExternalName. Nejpoužívanější jsou právě ClusterIP a NodePort. Pojďme projít jejich vlastnosti a praktické využití v provozu.

Kubernetes ClusterIP

Jak je patrné z názvu Kubernetes ClusterIP, jestlá se o IP adresu, která může být využita pouze uvnitř clusteru. ClusterIP představuje interní IP v Kubernetes clusteru a slouží vždy po celou životnost vytvořené service. Automaticky loabalancuje mezi pody, které jsou členy tohoto service.

Kubernetes NodePort

Jeden ze dvou základních způsobů jak vystavit service na externí IP adresu. Prakticky při nastavení service typu NodePort dojde přes kube-proxy k expose portu na každém nodu v clusteru. Pokud je tedy na našich K8s worker nodech nastavena veřejná adresa, tak přes ni přistoupíme společně s definicí portu na danou service, respektive až k aplikaci, která běží v cílových podech.

Ingress

Objekt, který řídí standardní HTTP/HTTPS (80/443) provoz zvenku na service. Ingress umožňuje load balancovat, řídit provoz dle názvů virtual hosta, terminovat SSL, upravovat hlavičky v provozu atd. Často se jako ingress používá Nginx, případně další jako je HAProxy nebo Traefik.

Externí Load Balancer (on premise)

Tento objekt jde s ohledem na podporu již mimo rozsah Kubernetes jako takového. Spíš se jedná o objekt, který řeší každý poskytovatel svým vlastním řešením.

Existuje service typu LoadBalancer, který u vybraných poskytovatelů umí automaticky vydeployovat LoadBalacer s externí IP adresou. Nevýhodou tohoto řešení jsou zvýšené náklady na vystavení vašich služeb do internetu na veřejné IP adrese. Při každé service typu LoadBalancer totiž zpravidla dochází k vytvoření vždy nového placeného loadbalanceru s veřejnou IP adresou.

Pokud řešíte výstavbu clusteru na míru ve vlastním prostředí, tak se nevyhnete otázce externího loadbalanceru, který za vás bude řešit otázku jednoduchého vystavení vašich service mimo IP rozsah Kubernetes clusteru, zajistí jednoduché směrování přes více IP adres až přímo do vašich aplikací. Tímto řešením zpravidla získáte další možnosti směrování a kontroly provozu a ušetříte nemalé náklady.