Written by 
- Kubernetes – orchestrátor kontejnerů (1) – schedulery vs. PaaS
- Kubernetes – orchestrátor kontejnerů (2) – instalace a první běžící kontejner
- Kubernetes – orchestrátor kontejnerů (3) – deployment aplikací, škálování a rollback
- Kubernetes – orchestrátor kontejnerů (4) – interní balancing a discovery služeb
- Kubernetes – orchestrátor kontejnerů (5) – přístup zvenku
Na stránkách cloudSvět jsme se už intenzivně věnovali Dockeru a kontejnerům obecně a také kompletní Platform-as-a-Service v podobě Cloud Foundry. Někde mezi tím jsou schedulery jako je Kubernetes (na ten se zaměříme detailně). Co je vlastně co a k čemu se dá použít?
Docker, Rocket, OCI – kontejnery
Úvod do toho, co kontejner je a jak ho použít najdete v starších článcích. V zásadě se jedná o způsob izolace na úrovni operačního systému (místo virtualizace hardwaru, kterou používá hypervisor) doplněný o některé příjemné vlastnosti jako je vrstvený souborový systém (jednoduchá a velmi efektivní distribuce obrazů) nebo networking. Kontejnery jsou v zásadě dost stará technologie (např. BSD Jail, OpenVZ, LXC), ale teprve v poslední době se způsob jejich ovládání a používání zlepšil natolik, že se staly jednou z nejdiskutovanějších IT technologií současnosti. V tomto procesu hrál klíčovou úlohu Docker (open source projekt i stejnojmenná firma), ale později se objevil soupeřící formát Rocket od CoreOS. Nejnovější iterace v této aréně je standardizace formátu runtime a obrazu kontejneru pod záštitou Open Container Initiative.
Kontejner je jen kontejner podobně jako je VM jen VM v obyčejném hypervisoru. Neřeší automatizovaný výběr hostitele, mutli-host networking, nehlídá si HA, nedokáže nativně držet víc kopií běžících kopií služby a balancovat na ni. Je to základní stavební blok, ale je to málo.
Mesos – univerzální scheduler
Problematika umísťování úloh do velkého clusteru zdrojů (tedy scheduling zdrojů) není nová a není úzce spojena jen s kontejnery. Některé firmy provozují velmi odlišné aplikace a často to řeší jejich infrastrukturním oddělením (běží na jiném železe). Například na sadě strojů je jejich analytický systém (např. Hadoop), jinde mají masivní databázi (třeba Cassandru), jidne zpracovávají události jako jsou IoT data (např. Kafka + Storm) a jinde běží samotné aplikace. Oddělenost infrastrukturní vede k neefektivitě a nemožnosti přelévat (třeba v noci dát méně aplikacím a více analytice, přes den naopak). Apache Mesos vznikl právě na řešení tohoto problému. Jde o Data Center Operating System – tedy Mesos dělá pro obrovský cluster počítačů to, co dělá operační systém pro jeden. Tedy má pod palcem zdroje, přiděluje je jednotlivým procesům a hlídá jejich stav.
Mesos (nebo jeho komerční distribuce DCOS od firmy Mesosphere, do které investovala řada velkých společností jako je HPE, Microsoft či Cisco), je tedy univerzální scheduler. Dokáže v něm běžet systém na rozjíždění Hadoop, Cassandry, Kafky a nebo třeba kontejnerů. Kromě nativního scheduleru kontejnerů ve formě Mesos Marathon nad Mesos můžete klidně spustit třeba Kubernetes.
Kubernetes, Swarm a Mesos Marathon – kontejnerové schedulery
Tyto schedulery jsou specifické pro svět kontejnerů. Pokud řešíte širší problém (například masivně využíváte Big Data a chcete to spojit dohromady), univerzálnější (a škálovatelnější) Mesos může být lepší volbou. Nicméně pokud jde o kontejnery samotné, mají Kubernetes a Swarm mnohé výhody. Swarm využívá stejných API jako Docker samotný (je vyvíjen přímo Dockerem) a přestože má méně funkcí, je ideální pro ty, kteří se už seznámili se základním Dockerem a nechtějí se učit nové ovládání (jinak řečeno tak jak ovládáte Docker na jednom notebooku, tak vám Swarm umožní ovládat celý cluster).
Kubernetes, který byl stvořen a stále je z velké části vyvíjen Googlem, jde dál a nabízí zajímavější vlastnosti (ostatně o těch bude v tomto seriálu ještě řeč). Například automatizuje desired state způsobem úkoly jako je držení určitého počtu replikovaných instancí a jejich automatický pozvolný upgrade z předchozí na novou verzi. Dokáže sdružovat kontejenry do služeb, zajišťovat jejich balancing i přístup zvenku. Scheduler můžete velmi významně ovlivňovat co do pravidel kam a jak chcete konkrétní workload umístit (má princip labelů a jejich filtrace).
Kontejnerové schedulery umožňují velmi efektivně provozovat kontejnery. Nicméně předpokládají, že aplikace v kontejnerech tak nějak už jsou a že tam s nimi jsou i všechny návaznosti (aplikační server, JVM, knihovny), které tam být mají. To Kubernetes a spol. neřeší. Máte velkou míru flexibility (kontejnery si poskládejte jak chcete), ale vývojáři stále musí řešit tvorbu kontejnerů a jejich dependencies. Tam přichází ke slovu PaaS.
Cloud Foundry, OpenShift – PaaS
Platform-as-a-Service nemá jako vstupní bod pouze kontejner, ale kód. Je zaměřena na blaho vývojářů. Do Cloud Foundry pošlete zdrojový kód aplikace a to následně zajistí kompilaci a kompletaci aplikace a podle vašeho předpisu připraví veškeré další návaznosti jako jsou aplikační server, web server, middleware či JVM. Současně aplikacím zprostředkuje přístup do externích služeb – zajistí napojení na databázi, cache, frontovací sběrnici nebo API dalších systémů. Z toho všeho vykouzlí kontejner a ten, jak jistě začínáte tušit, bude nějakým schedulerem provozovat. PaaS je tedy z hlediska abstrakcí výše, než schedulery, ale bude na nich stavět.
Cloud Foundry používá svůj vlastní scheduler, který je mu šitý na míru (v nejnovější generaci jde o Diego). Jde o to, že co má PaaS pod kontejnerovou kapotou už nehraje takovou roli (ovládáme to z pohledu aplikací, ne kontejnerů). OpenShift a někteří provozovatelé Cloud Foundry například dávají do motoru Kubernetes.
Výhodou PaaS je, že máte kompletní řešení pro vývoj a provoz cloud native aplikací. Nemusíte to zdlouhavě vymýšlet sami a je to nejrychlejší začátek. Nevýhodou je, že PaaS má jasně daná pravidla, která musíte dodržovat (ale jsou velmi dobrá a hodná dodržení). Není tedy tak flexibilní.
