A konténerek továbbra is sok ember számára jelentik a „Dockert”. A Docker népszerűsítette a konténerek modern használatát a szoftverfejlesztésben és a telepítésben. Manapság más technológiák is a közelben vannak. Így viszonyul Containerd, Docker és Kubernetes egymáshoz.
A kezdetek
Annak megjelenés 2013-ban, A Docker önálló projekt volt, amely tartalmazott mindent a konténerek felépítéséhez és futtatásához. Hiányzott belőle a konténerek telepítésének egyszerű módja a felhőben.
2013 végén a Google munkatársai már voltak ezzel foglalkozva annak prototípusával, hogy mi lesz Kubernetes. A Kubernetes célja, hogy leegyszerűsítse a konténeres munkaterhelések működését a nagy gépparkokban.
Azokban a korai időkben Kubernetes elválaszthatatlanul összekapcsolódott Dockerrel. A Docker-t közvetlenül használta a tárolókkal való interakcióhoz, annak ellenére, hogy csak a funkcionalitás egy részére volt szüksége – a konténerek tényleges futtatásáért felelős részekre.
A Docker fejlesztőközpontú kezelőfelülete akadályozta Kubernetes-t. Egy dedikált eszköz segítségével meg kellett kerülnie a projekt emberbarát szempontjait, Dockershim. A kérdéseket kiegészítették a Docker és Kubernetes különböző irányai. A Docker elindította a Swarm-ot, a saját Kubernetes-alternatíváját, amely beépített hangszerelést kínál Docker „mód”.
A Containerd felemelkedése
Ahogy a Kubernetes nőtt, és újabb, harmadik féltől származó eszközök jelentek meg a Docker körül, egyértelművé vált architektúrájának korlátai. Ugyanakkor a Open Container Initiative (OCI) megkezdte a konténer formátumok és futásidők egységesítését. Ez egy OCI specifikációt eredményezett, amely meghatározta egy tárolót, amelyet több futási idő is használhat, amire a Docker is példa.
A Docker ezt követően egy új projektbe vonta ki a konténer futási idejét, containerd. Ez magában foglalja a Docker funkcionalitását a konténerek végrehajtására, az alacsony szintű tárolás kezelésére és a képátvitelek kezelésére. Containerd-t adományozták a Cloud Native Computing Foundation (CNCF) annak érdekében, hogy alapot biztosítson a konténer közösség számára új konténer megoldások létrehozásához.
A containerd megjelenése megkönnyíti az olyan projektek számára, mint a Kubernetes, a szükséges alacsony szintű „Docker” elemek elérését. Ahelyett, hogy ténylegesen a Dockert használnák, most már hozzáférhetőbb interfésszel rendelkeznek a konténer futásidejéhez. A konténertechnológiák OCI szabványosítása azt jelenti, hogy más futási idő is használható.
Containerd szerepének megértése
A containerd teljes megértéséhez meg kell vizsgálni a konténerek jellegét. A konténerek valóban absztrakció a különféle Linux kernelfunkciókhoz képest. Tároló futtatásához syscall-okat kell használnia a tárolt környezet beállításához. A lépések platformonként és disztribúciónként változnak.
A Containerd beilleszti ezt az alacsony szintű vezetéket. Célja mint „ügyfél réteg” hogy a konténerszoftver ekkor felépül. Ez lehet fejlesztő-orientált szoftver, például Docker, vagy felhő-orientált fejlesztői eszközök, például Kubernetes.
Korábban a Kubernetes fejlesztésnek két rossz lehetősége maradt: folytassa az írások írását a tetemes Docker felület körül, vagy kezdje el közvetlenül a Linux kernel szolgáltatásait. A containerd kibontásával a Dockerből egy harmadik alternatíva vált elérhetővé: a containerd használata rendszer-absztrakciós rétegként, Docker bevonása nélkül.
Íme egy összefoglaló a három technológia ötvözéséről:
- Dokkmunkás – Fejlesztő-orientált szoftver magas szintű interfésszel, amely lehetővé teszi a konténerek egyszerű felépítését és futtatását a terminálról. Most a containerd-t használja tároló futásidejeként.
- Containerd – A kernel tulajdonságainak absztrakciója, amely viszonylag magas szintű tároló felületet biztosít. Más szoftverprojektek felhasználhatják ezt tárolók futtatására és tároló képek kezelésére.
- Kubernetes – Egy konténeres hangszerelő, amely több konténer futási idővel működik, beleértve a containerd-t is. A Kubernetes arra összpontosít, hogy a konténereket összesítve helyezze el egy vagy több fizikai „csomóponton”. Történelmileg Kubernetes Dockerhez volt kötve.
A Containerd csak egy konténer háttérrendszer. A konténert megvalósító egyéb konténerek Nyissa meg a Containers Runtime specifikációt tartalmazza runC és CRI-O. Ezeket a futási idõket a Docker és a Kubernetes együttesen is használhatjuk; mindegyiknek megvan a maga megkülönböztetése.
Az OCI
Az OCI a meghatározásért felelős testület konténer szabványok. Munkája kulcsfontosságú volt a különböző alkatrész-technológiák közötti átjárhatóság megkönnyítésében.
Az OCI képspecifikációja meghatározza, hogy milyen legyen egy tároló. A futásidejű specifikáció interfészt határoz meg a tárolók futtatásához. Az olyan projektek, mint a containerd, végrehajtják ezeket a specifikációkat.
Fontos, hogy az OCI egyik prioritása a Docker által népszerűsített konténerhasználati élmény támogatása. Képeinek a felhasználó által definiált argumentumok (pl docker run hello-world:latest). Az OCI képeknek ezért elegendő metaadatot kell tartalmazniuk az automatikus konfigurálás engedélyezéséhez.
Láthat hivatkozásokat a Konténer futásidejű interfész (CRI). Ez egy Kubernetes-specifikus absztrakció az OCI specifikáció fölött. A CRI az OCI specifikációkra épít, hogy lehetővé tegye a cserélhető konténer futásideinek támogatását a Kubernetesen belül.
Mi a helyzet a Docker képeimmel?
A Dockerrel készített képek egyáltalán nem „Docker-képek”. Mivel a Docker most már a containerd futásidőt használja, a képek szabványosított Open Container Initiative (OCI) formátumban készülnek.
Nem kell aggódnia a Docker-képek és a használt környezet közötti összeférhetetlenség miatt. A Docker-rel készített képek továbbra is telepíthetők a Kubernetes használatával. A Kubernetes ugyanis támogatja az OCI képeket is a containerd (és más szabványoknak megfelelő futásidők) használatával. Ez a futási idő a képek lehúzásának és futtatásának kezelése, nem pedig a Dockerhez és a Kuberneteshez hasonló magas szintű interfész.
Kubernetes és Docker
Kubernetes 2020 végén megszüntette a Docker futási idejét eltávolításra kerül egy későbbi kiadásban, amelyet jelenleg 2021 végére terveznek. Ezt követően a Kubernetes már nem kínálja fel a Dockert futási idő támogatás. Helyette az OCI specifikációkkal kompatibilis alternatív futást kell használni, mint például a containerd.
Ez a bejelentés aggodalmat keltett a fejlesztőkre gyakorolt következményekkel kapcsolatban. A változás nem érinti a legtöbb meglévő munkafolyamatot. Amint már láthattuk, a Docker OCI-kompatibilis képeket készít, amelyeket az OCI-kompatibilis futási futtathat. Minden kép, amellyel épít docker build továbbra is működni fog a Kubernetesen belül, még a Docker futásidejének eltávolítása után is.
Két különböző technológiát fontolgatnak – a Docker-t parancssori felület tárolók és a Docker létrehozásához és futtatásához használt futási idő amelyet a parancssori felület körbefut.
Túl zavaró az egész!
Néhány év alatt a konténerek megváltoztatták a fejlesztők számát. A környező ökoszisztéma terjeszkedése ennek a változásnak természetes mellékterméke volt. A Containers === Docker a mentalitás túl fojtogatónak bizonyult, mivel megakadályozta, hogy a Kuberneteshez hasonló eszközök teljes képességeiket megmutassák.
A szabványosítás felé történő elmozdulás rengeteg új kifejezést, eszközt és technológiát eredményezett. Ennek ellenére semmi sem változott a fejlesztők számára, függetlenül attól, hogy a gépén Docker CLI-vel, vagy a felhőben lévő Kubernetes-fürtrel kommunikál-e.
Minden magas szintű felhasználói felület (például a Docker és a Kubernetes) most cserélhető alacsony szintű tároló futásidejű (például containerd és runC) előnyöket élvez. Ez nagyobb fokú rugalmasságot tesz lehetővé, és lehetővé teszi az új konténer alapú technológiák szabványokhoz igazodó megalapozását.
