Kontejnery pro mnoho lidí stále znamenají „Docker“. Docker popularizoval moderní využití kontejnerů při vývoji a nasazení softwaru. V dnešní době existují i jiné technologie. Zde je návod, jak spolu Containerd, Docker a Kubernetes souvisí.
Počátky
Při svém vydání v roce 2013 byl Docker samostatným projektem se vším, co jste potřebovali k sestavení a spuštění kontejnerů. Chyběl mu snadný způsob, jak zorganizovat nasazení kontejnerů v cloudu.
Koncem roku 2013 to už řešila skupina zaměstnanců společnosti Google s prototypem toho, co by se stalo Kubernetes. Kubernetes má zjednodušit provoz kontejnerových úloh napříč velkými flotilami strojů.
V těch raných dobách byl Kubernetes nerozlučně spojen s Dockerem. K interakci s kontejnery používal přímo Docker, i když potřeboval pouze podmnožinu funkcí – části zodpovědné za skutečný provoz kontejnerů.
Uživatelské rozhraní Docker zaměřené na vývojáře stálo v cestě Kubernetes. Musel obejít lidsky přívětivé aspekty projektu pomocí speciálního nástroje Dockershim. Problémy byly umocněny odlišnými směry, kterými se Docker a Kubernetes ubíraly. Docker spustil Swarm, vlastní alternativu Kubernetes, která nabízí orchestraci jako vestavěný „režim“ Dockeru.
The Rise of Containerd
Jak Kubernetes rostl a kolem Dockeru se objevilo více nástrojů třetích stran, byla jasná omezení jeho architektury. Ve stejné době začala iniciativa Open Container Initiative (OCI) standardizovat formáty kontejnerů a běhové prostředí. To vedlo ke specifikaci OCI definující kontejner, který by mohl být používán více běhovými moduly, jejichž příkladem je Docker.
Docker poté extrahoval svůj kontejner runtime do nového projektu, kontejneru. To zahrnuje funkce Dockeru pro spouštění kontejnerů, manipulaci s nízkoúrovňovým úložištěm a správu přenosů obrázků. Containerd byl darován nadaci Cloud Native Computing Foundation (CNCF), aby poskytl komunitě kontejnerů základ pro vytváření nových kontejnerových řešení.
Vznik kontejnerů usnadňuje projektům, jako je Kubernetes, přístup k nízkoúrovňovým prvkům „Docker“, které potřebují. Namísto skutečného používání Dockeru mají nyní přístupnější rozhraní pro běh kontejneru. Standardizace kontejnerových technologií OCI znamená, že lze použít i jiná běhová prostředí.
Pochopení role kontejneru
Abychom plně porozuměli kontejnerům, je nutné se podívat na povahu kontejnerů. Kontejnery jsou ve skutečnosti abstrakcí různých funkcí linuxového jádra. Abyste mohli spustit kontejner, musíte použít syscalls k nastavení kontejnerového prostředí. Kroky se liší podle platformy a distribuce.
Kontejner vstoupí, aby abstrahoval toto nízkoúrovňové vedení. Je to zamýšleno jako „klientská vrstva“, na kterou pak kontejnerový software staví. Může se jednat o software orientovaný na vývojáře, jako je Docker, nebo o cloudově orientované devops nástroje, jako je Kubernetes.
Dříve byly při vývoji Kubernetes ponechány dvě špatné možnosti:pokračovat v psaní shimů kolem mohutného rozhraní Dockeru nebo začít přímo interagovat s funkcemi jádra Linuxu. Odlomením kontejneru z Dockeru byla k dispozici třetí alternativa:použít kontejner jako systémovou abstrakční vrstvu bez zapojení Dockeru.
Zde je souhrn toho, jak se tyto tři technologie kombinují:
- Docker – Software orientovaný na vývojáře s rozhraním na vysoké úrovni, který vám umožní snadno vytvářet a spouštět kontejnery z vašeho terminálu. Jako běhový modul kontejneru nyní používá kontejner.
- Kontejner – Abstrakce funkcí jádra, která poskytuje rozhraní kontejneru na relativně vysoké úrovni. Jiné softwarové projekty to mohou používat ke spouštění kontejnerů a správě obrázků kontejnerů.
- Kubernetes – Kontejnerový orchestrátor, který pracuje s více kontejnerovými běhovými prostředími, včetně kontejnerů. Kubernetes se zaměřuje na nasazování kontejnerů v souhrnu přes jeden nebo více fyzických „uzlů“. Historicky byl Kubernetes svázán s Dockerem.
Containerd je pouze jeden backend kontejneru. Mezi další kontejnery implementující specifikaci Open Containers Runtime patří runC a CRI-O. Tyto běhové moduly lze také použít s Dockerem a Kubernetes; každý má své vlastní rozdíly.
OCI
OCI je orgán odpovědný za definování norem pro kontejnery. Jeho práce byla zásadní při usnadňování interoperability mezi různými technologiemi komponent.
Specifikace obrázku OCI definuje, jak by měl kontejner vypadat. Specifikace runtime stanoví rozhraní pro spouštění kontejnerů. Projekty jako kontejnerové pak implementují tyto specifikace.
Důležité je, že jednou z priorit OCI je podpora používání kontejnerů popularizovaných Dockerem. Jeho obrázky musí být spustitelné na cílové platformě bez jakýchkoli uživatelsky definovaných argumentů (např. docker run hello-world:latest ). Obrázky OCI proto musí obsahovat dostatečná metadata, aby umožnila tuto automatickou konfiguraci.
Můžete také vidět odkazy na rozhraní CRI (Container Runtime Interface). Toto je abstrakce specifická pro Kubernetes nad specifikací OCI. CRI staví na specifikacích OCI a umožňuje podporu pro výměnné běhové moduly kontejnerů v rámci Kubernetes.
A co My Docker Images?
Obrázky, které vytvoříte pomocí Dockeru, ve skutečnosti vůbec nejsou „obrázky Dockeru“. Protože Docker nyní používá kontejnerové běhové prostředí, vaše obrázky jsou vytvořeny ve standardizovaném formátu Open Container Initiative (OCI).
Nemusíte si dělat starosti s nekompatibilitou mezi obrazy Dockeru a prostředím, ve kterém se používají. Obrazy, které vytvoříte pomocí Dockeru, lze stále nasadit pomocí Kubernetes. Je to proto, že Kubernetes také podporuje obrazy OCI, a to prostřednictvím použití kontejnerů (a dalších běhových prostředí vyhovujících standardům). Záleží na běhu ke zpracování stahování a spouštění obrázků, nikoli rozhraní na vysoké úrovni, které poskytují nástroje jako Docker a Kubernetes.
Kubernetes a Docker
Kubernetes ukončila podporu běhového prostředí Docker na konci roku 2020. Bude odstraněno v budoucí verzi, která je aktuálně naplánována na konec roku 2021. Poté již Kubernetes nebude nabízet běhové prostředí Dockeru Podpěra, podpora. Místo toho bude nutné použít alternativní běhové prostředí kompatibilní se specifikacemi OCI, jako je kontejner.
Toto oznámení vyvolalo obavy z důsledků pro vývojáře. Změna by neměla mít vliv na většinu stávajících pracovních postupů. Jak jsme již viděli, Docker vytváří obrázky kompatibilní s OCI, které mohou spustit běhové moduly vyhovující OCI. Všechny obrázky, které vytvoříte pomocí docker build bude v Kubernetes stále fungovat, i když bude runtime Docker odebrán.
Zvažují se dvě různé technologie – rozhraní příkazového řádku Docker slouží k vytváření a spouštění kontejnerů a runtime Dockeru kolem kterého se obtéká rozhraní příkazového řádku.
Je to příliš matoucí!
Během několika málo let kontejnery proměnily, kolik vývojářů pracuje. Expanze v okolním ekosystému byla přirozeným vedlejším produktem tohoto posunu. Containers === Docker mentalita se ukázala být příliš dusivá, protože znemožňovala nástrojům jako Kubernetes ukázat svůj plný potenciál.
Posun směrem ke standardizaci vyústil v nepřeberné množství nových termínů, nástrojů a technologií. Nicméně pro vývojáře se ve skutečnosti nic nezměnilo, ať už komunikujete s Docker CLI na svém počítači nebo s clusterem Kubernetes v cloudu.
Každé uživatelské rozhraní na vysoké úrovni (jako je Docker a Kubernetes) nyní těží z výběru zaměnitelných nízkoúrovňových kontejnerových runtime (jako jsou kontejnery a runC). To umožňuje vyšší míru flexibility a umožňuje, aby se nové technologie založené na kontejnerech prosadily způsobem odpovídajícím standardům.