„Mi a különbség a Kubernetes és az OpenShift között?” – ez a kérdés rendre felmerül. Bár valójában olyan, mintha azt kérdeznénk, miben különbözik az autó a motortól. Ha folytatjuk az analógiát, az autó egy kész termék, amit azonnal használhatunk, lényegében: beülünk és megyünk. Másrészről ahhoz, hogy a motor bárhová elvigyen minket, először számos más dologgal ki kell egészítenünk, hogy végül megkapjuk ugyanazt az autót.
Ezért a Kubernetes egy olyan motor, amely köré az OpenShift márkájú autó (platform) épült, ami elvisz minket a célhoz.
A cikkben szeretnénk emlékeztetni és egy kicsit részletesebben is megvizsgálni a következő kulcspontokat:
- A Kubernetes az OpenShift platform szíve. Ez egy 100%-ban tanúsított Kubernetes, teljesen nyílt forráskódú és semmilyen tulajdonjog nélküli. Röviden:
- Az OpenShift klaszter API-ja egy 100%-os Kubernetes.
- Ha egy konténer bármilyen más Kubernetes rendszerben működik, akkor módosítások nélkül fog működni az OpenShift-en is. Az alkalmazások megváltoztatására nincs szükség.
- Az OpenShift nemcsak a Kubernetes-t egészíti ki hasznos funkciókkal és lehetőségekkel. Mint egy autó, az OpenShift azonnal használatra kész, közvetlenül indítható a gyártásban, és ahogy alább bemutatjuk, jelentősen megkönnyíti a fejlesztők életét. Ezért az OpenShift egy kettős arculattal bír. Ez egyszerre egy sikeres, széles körben elismert vállalati PaaS platform a fejlesztők szemszögéből, és egy rendkívül megbízható Container-as-a-Service megoldás az ipari üzemeltetés szempontjából.
Az OpenShift a Kubernetes, 100%-os tanúsítással a CNCF alapítványtól.
Az OpenShift alapja a . Ezért a megfelelő képzés után a felhasználók csodálják meg a kubectl erejét. A Kubernetes klaszterről az OpenShift-re váltók gyakran említik, hogy mennyire tetszik nekik, hogy a kubeconfig átállítása után az OpenShift klaszterre minden meglévő szkript hibátlanul működik.
Bizonyára hallott már az OpenShift CLI eszközéről, az OC-ról. Ez teljes mértékben kompatibilis a kubectl parancsokkal, ráadásul néhány hasznos segédfunkcióval is rendelkezik, amelyek jól jöhetnek különböző feladatok elvégzésekor. De először nézzük meg részletesebben az OC és a kubectl kompatibilitását:
A kubectl parancsai
Az OC parancsai
kubectl get pods
oc get pods
kubectl get namespaces
oc get namespaces
kubectl create -f deployment.yaml
oc create -f deployment.yaml
Itt vannak a kubectl OpenShift API használatának eredményei:
• A kubectl get pods várható módon adja vissza a pod-okat.
• A kubectl get namespaces várható módon adja vissza a névtereket.
A kubectl create -f mydeployment.yaml parancs kubernetes-erőforrásokat hoz létre, akárcsak bármely más Kubernetes-platformon, ahogy az alábbi videóban látható:
Más szavakkal, az összes Kubernetes API teljes mértékben elérhető az OpenShift-en, 100% -os kompatibilitást megőrizve. Ezért .
Az OpenShift hasznos funkciókkal egészíti ki a Kubernetest.
A Kubernetes API 100% -ban elérhető az OpenShift-en, de a kormányzati Kubernetes eszköz, a kubectl nyilvánvalóan hiányzik az funkcionalitásból és a kényelméből. Ezért a Red Hat kiegészítette a Kubernetest hasznos funkciókkal és parancssori eszközökkel, mint például az OC (OpenShift kliens rövidítése) és az ODO (OpenShift DO, ez az eszköz a fejlesztők számára készült).
1. Az OC eszköz – a Kubectl erősebb és kényelmesebb változata.
Például, ellentétben a kubectl-lal, lehetővé teszi új névterek létrehozását és könnyű kontextusváltást, valamint számos hasznos parancsot kínál a fejlesztők számára, például konténerek képeinek építésére és alkalmazások telepítésére közvetlenül a forráskódból vagy bináris fájlokból (Source-to-image, s2i).
Nézzük meg példákon, hogyan segít a beépített segédprogramok és az OC eszköz kiterjesztett funkciója egyszerűsíteni a mindennapi munkát.
Első példa – névterek kezelése. Minden Kubernetes klaszterben mindig van több névtér. Ezeket általában fejlesztési és produkciós környezetek létrehozására használják, de például minden fejlesztő számára személyes „homokozó” kiadására is alkalmazhatók. A gyakorlatban ez azt jelenti, hogy a fejlesztőnek gyakran kell váltania a névterek között, mivel a kubectl a jelenlegi névtér kontextusában működik. Ezért a kubectl esetében az emberek aktívan használják a segédprogram-skripteket. Az OC használata során azonban elegendő a kívánt névterekre váltani az "oc project névtér" parancs beírásával.
Nem emlékszik, hogyan hívják a szükséges névteret? Nem probléma, egyszerűen írja be az "oc get projects" parancsot, hogy megjelenítse a teljes listát. Kétkedve érdeklődik, hogyan működik ez, ha csak a klaszter korlátozott névtér-állományához fér hozzá? Nos, az "kubectl" ezt csak akkor teszi helyesen, ha a RBAC megengedi, hogy lássa az összes névteret a klaszteren, és a nagy klaszterekben az ilyen jogosítványokat messze nem mindenki kapja meg. De válaszolunk: az OC számára ez nem probléma, és könnyen kiadja a teljes listát ilyen helyzetben. Az ilyen apróságok alkotják az Openshift vállalati orientáltságát és az alkalmazások és felhasználók szempontjából jó skálázhatóságát.
2. ODO – a kubectl továbbfejlesztett változata fejlesztőknek.
A Red Hat OpenShift Kuberneteshez képest nyújtott egy új példa a parancssori eszköz, az ODO. Ez a fejlesztők számára készült, és lehetővé teszi a helyi kód gyors telepítését egy távoli OpenShift klaszterre. Ezen kívül optimalizálhatja a belső folyamatokat, hogy azonnal szinkronizálja a kód minden módosítását a távoli OpenShift klaszter konténereivel anélkül, hogy újra kellene építenie, regisztrálnia és újra telepítenie a képeket.
Nézzük meg, hogyan könnyíti meg az OC és ODO a konténerek és a Kubernetes kezelését.
Egyszerűen hasonlítsuk össze egy pár munkafolyamatot, amikor azok kubectl alapúak, és amikor OC vagy ODO alkalmazásával épülnek.
• Kód telepítése az OpenShiftre, azok számára, akik nem ismerik a YAML nyelvet:
Kubernetes / kubectl
$> git clone
1- Hozzuk létre a Dockerfile-t, amely a kód alapján építi a képet.
————–
FROM node
WORKDIR /usr/src/app
COPY package*.json ./
COPY index.js ./
COPY ./app ./app
RUN npm install
EXPOSE 3000
CMD [ "npm", "start" ]
————–
2- Hozzuk létre a képet.
$> podman build …
3- Jelentkezzen be a registry-be.
podman login …
4- Feltölti a képet a registry-be.
podman push
5- Készítsünk yaml fájlokat az alkalmazás telepítéséhez (deployment.yaml, service.yaml, ingress.yaml) – ez az abszolút minimum.
6- Telepítjük a manifest fájlokat:
Kubectl apply -f .
OpenShift / oc
$> oc new-app – nevünk_alkalmazás
OpenShift / odo
$> git clone
$> odo create component nodejs myapp
$> odo push
• Kontextus váltás: a névtér vagy a klaszter munkaterületének váltása.
Kubernetes / kubectl
1- Hozzuk létre a kontextust a kubeconfigban a "myproject" projekthez.
2- kubectl set-context …
OpenShift / oc
oc project "myproject"
Minőségellenőrzés: „Itt egy érdekes funkció jelent meg, jelenleg alfa verzióban. Bevezetjük a termelésbe?”
Képzelje el, hogy egy versenyautóba ültetik, és azt mondják: „Új típusú fékeket szereltünk be, és, őszintén szólva, nem minden rendben van a megbízhatóságukkal... De ne aggódjon, aktívan fejleszteni fogjuk őket a bajnokság alatt.” Hogyan tetszik ez a perspektíva? Mi a Red Hat-nál nem vagyunk ezzel igazán elégedettek. 🙂
Ezért igyekszünk tartózkodni az alfa verzióktól, ameddig nem érnek el elegendő érettséget, és ameddig alapos harci tesztelést nem végeztünk, és ameddig nem érezzük, hogy biztonságosan használhatók. Általában először Dev Preview fázison mennek keresztül, majd és csak ezt követően jelennek meg nyilvános kiadás formájában (GA), amely már olyan stabil, hogy alkalmas a termelési használatra.
Miért ilyen? Mert, ahogy bármely más szoftver fejlesztésénél, nem minden kezdeti elképzelés valósul meg a Kubernetes végső kiadásában. Vagy megvalósulnak, és megőrzik a tervezett funkcionalitást, de a megvalósításuk radikálisan eltér az alfa verzióban látottaktól. Mivel a Red Hat ezer és ezer ügyfele az OpenShift-tet kulcsfontosságú feladatok támogatására használja, különös hangsúlyt fektetünk platformunk stabilitására és a hosszú távú támogatásra.
A Red Hat célzottan gyakori OpenShift kiadásokat ad ki és frissíti a benne található Kubernetes verziót. Például a cikk írásának időpontjában aktuális GA kiadású OpenShift 4.3 beépített Kubernetes 1.16-ot tartalmaz, amely mindössze egy egységgel marad el a Kubernetes upstream verziójától 1.17. Így próbáljuk a megrendelőnek vállalati szintű Kubernetes-t biztosítani, és további minőségellenőrzést nyújtunk az új OpenShift verziók kiadása során.
Szoftverjavítások: „Abban a Kubernetes verzióban, amely a termelésben van, találtunk egy lyukat. Ezt csak három verzióval magasabb frissítéssel tudjuk megjavítani. Vagy van más lehetőség?”
A nyílt Kubernetes projekt keretein belül a szoftverjavítások általában a következő kiadás keretén belül jelennek meg, néha egy-két korábbi közbenső kiadással is foglalkozva, ami hat hónapra visszamenőleg terjed.
A Red Hat méltán büszke arra, hogy másoknál korábban adja ki a kritikus javításokat, és sokkal hosszabb támogatási időt biztosít. Vegyük például a Kubernetes-ben felfedezett jogosultsági emelés sebezhetőségét (): ezt a Kubernetes 1.11-ben fedezték fel, a korábbi verziók javítását pedig csak az 1.10.11 verzióig végezték el, így ez a hiba megmaradt minden korábbi Kubernetes verzióban az 1.x-től 1.9-ig.
Viszont (itt a Kubernetes 1.2-es verziója fut), kilenc OpenShift verziót átölelve, és ezzel szemléltetve törődést az ügyfelekkel (további részletek itt ).
Hogyan segíti elő az OpenShift és a Red Hat a Kubernetes fejlesztését
A Red Hat a második helyet foglalja el a Kubernetes nyílt forráskodú projektbe történő hozzájárulás nagysága szerint, csak a Google áll az élen, és az öt legtermékenyebb fejlesztő közül három a Red Hat munkatársa. Egy másik kevéssé ismert tény: sok kritikus fontosságú funkció a Red Hat kezdeményezésére került be a Kubernetes-be, különösen olyanok, mint:
- RBAC. A Kubernetes-ben nem voltak RBAC funkciók (ClusterRole, ClusterRoleBinding), míg a Red Hat mérnökei el nem döntötték, hogy azokat pedig a platform részeként, és nem külön kiegészítő funkcióként valósítják meg az OpenShift-en. Nem fél a Red Hat a Kubernetes fejlesztésétől? Természetesen nem, hiszen a Red Hat szigorúan követi a nyílt forráskód elveit, és nem játszik az Open Core játékával. Azok a fejlesztések és újítések, amelyek a fejlesztői közösség szintjén valósulnak meg, nem a tulajdonos jogaira alapozva, fenntarthatóbbakká válnak, és szélesebb körben elérhetővé válnak, ami tökéletesen összhangban áll a fő célunkkal – az nyílt forráskódú szoftverek hasznossági szintjének növelése az ügyfeleink számára.
- A podok biztonsági irányelvei (Pod Security Policies). E biztonságos alkalmazáspontok megvalósítása eredetileg az OpenShift-en SCC (Security Context Constraints) néven valósult meg. És mint az előző példában, a Red Hat úgy döntött, hogy ezeket az új fejlesztéseket beépíti a nyílt forráskódú Kubernetes projektbe, hogy mindenki számára elérhetővé váljanak.
E sorozat példáit folytathatnánk, de csak azt szerettük volna megmutatni, hogy a Red Hat valóban elkötelezett a Kubernetes fejlesztése mellett, és egészen a javításon dolgozik mindenki számára.
Nyilvánvaló, hogy az OpenShift a Kubernetes. De hol vannak a különbségek? 🙂
Reméljük, hogy eddig a pontig eljutott, és megértette, hogy a Kubernetes az OpenShift alapvető összetevője. Alapvető, de korántsem egyedüli. Más szóval, csupán a Kubernetes telepítése nem fogja eredményezni a vállalati szintű platformot. Hozzá kell adnia az azonosítást, hálózatot, biztonságot, monitorozást, naplókezelést és még sok mást. Ezen kívül nehéz döntéseket kell hoznia a rendelkezésre álló eszközök széles választékából (hogy értékelni tudja az ökoszisztéma változatosságát, egyszerűen nézze meg ) és valahogyan biztosítania kell az összhangot, hogy együtt működjenek, mint egy egységes egész. Ezen kívül rendszeresen frissítenie és regressziós tesztelnie kell, amikor a használt összetevők bármelyikének új verziója megjelenik. Tehát a platform létrehozása és karbantartása mellett mindezzel a szoftverrel is foglalkoznia kell. Valószínűleg alig marad ideje az üzleti problémák megoldására és a versenyelőnyök elérésére.
Az OpenShift esetében a Red Hat azonban ezeket a bonyodalmakat a saját vállára veszi, és egyszerűen ad egy funkcionálisan teljes platformot, amely nemcsak magát a Kubernetest, hanem az összes szükséges nyílt forráskódú eszközt is tartalmazza, amelyek a Kubernetest valódi vállalati megoldássá alakítják, amelyet azonnal és teljes nyugalomban üzemeltethet. Természetesen, ha saját technológiai stack-ei vannak, az OpenShiftet integrálhatja a meglévő megoldásaiba.
Nézze meg a fenti ábrát: minden, ami a Kubernetes téglalapján kívül található, az azon területek, ahol a Red Hat olyan funkciót ad hozzá, amely a Kubernetesben nincs, úgynevezett by-design. Most megnézzük ezek közül néhányat.
1. Megbízható operációs rendszer alapként: RHEL CoreOS vagy RHEL
A Red Hat már több mint 20 éve a Linux-disztribúciók vezető szolgáltatója a kritikus üzleti alkalmazások számára. A területen felhalmozott és folyamatosan frissített tapasztalatunk lehetővé teszi számunkra, hogy valóban megbízható és hiteles alapot kínáljunk a konténeripari alkalmazásokhoz. A RHEL CoreOS ugyanazt a kernelt használja, mint a RHEL, de elsősorban olyan feladatokra van optimalizálva, mint a konténerek futtatása és a Kubernetes klaszterek működtetése: csökkentett mérete és változhatatlansága (immutability) egyszerűsíti a klaszterek telepítését, automatikus méretezését, hibajavítások telepítését stb. Mindezek a funkciók ideálissá teszik a nyújtott felhasználói élmény fenntartását az OpenShift folytatásához a legkülönfélébb számítási környezetekben, a „meztelen vasról” a magán- és nyilvános felhőig.
2. IT-műveletek automatizálása
A telepítési és második napi működési folyamatok automatizálása (azaz a napi üzemeltetés) az OpenShift szakterülete, amely jelentősen megkönnyíti a konténerplatform adminisztrációját, frissítését és karbantartását a legmagasabb szinten. Ezt a Kubernetes-operátorok kernel szintű támogatásával érik el az OpenShift 4-ben.
Az OpenShift 4 egy teljes Kubernetes-operátorok ökoszisztémája, amelyeket maga a Red Hat és külső partnerek fejlesztettek ki (lásd Red Hat, vagy az operátorok boltja , a Red Hat által létrehozott harmadik féltől származó fejlesztők számára).
Az OpenShift 4 integrált katalógusa több mint 180 Kubernetes-operátort tartalmaz
3. Fejlesztői eszközök
2011 óta az OpenShift elérhető PaaS (Platform-as-a-Service) formában, amely jelentősen megkönnyíti a fejlesztők életét, segíti őket a kód írására összpontosítani, és beépített támogatást nyújt olyan programozási nyelvekhez, mint Java, Node.js, PHP, Ruby, Python, Go, valamint CI/CD folyamatos integrációs és szállítási szolgáltatások, adatbázisok stb. Az OpenShift 4 kínál , beleértve több mint 100 Kubernetes-operátorokat, amelyeket a Red Hat és partnereink fejlesztettek ki.
Az OpenShift 4-ben, a Kubernetes-től eltérően, van egy speciális grafikus felhasználói felület (), amely segíti a fejlesztőket, hogy felesleges erőfeszítések nélkül telepítsenek alkalmazásokat különböző forrásokból (git, külső tárolók, Dockerfile stb.) a névtérben, és szemléletesen vizualizálja az alkalmazás komponensei közötti kapcsolatokat.
Ezen kívül az OpenShift egy Codeready fejlesztői eszközkészletet kínál, amely többek között tartalmazza , egy teljesen konténerizált IDE, amely webböngészőn keresztül működik közvetlenül az OpenShift tetején, és az 'IDE mint szolgáltatás' megközelítést valósítja meg. Másrészt, a helyi üzemmódban dolgozni kívánók számára rendelkezésre áll a Codeready Containers – egy teljes funkcionalitású OpenShift 4 verzió, amelyet a laptopra telepíthetünk.
Integrált 'IDE mint szolgáltatás' a Kubernetes/OpenShift platformon való hatékony fejlesztéshez.
Az OpenShift alapvetően teljes CI/CD rendszert kínál, akár konténerizált Jenkins és plugin, segítségével a pipeline-ok kezelésére, akár Kubernetes orientált CI/CD rendszerrel, (jelenleg Tech preview verzióban). Mindkét megoldás teljesen integrálódik az OpenShift konzollal, lehetővé téve a pipeline-k kiváltásának indítását, a telepítések, naplók és így tovább megtekintését.
4. Eszközök az alkalmazásokhoz
Az OpenShift lehetővé teszi hagyományos stateful alkalmazások, valamint új architektúrák, mint például a mikroszolgáltatások vagy serverless megoldások telepítését. Az OpenShift Service Mesh azonnal kulcsfontosságú eszközöket nyújt a mikroszolgáltatások kezeléséhez, mint például Istio, Kiali és Jaeger. Az OpenShift Serverless megoldása pedig nemcsak a Knative-t, hanem a Microsofttal közösen kidolgozott eszközöket is tartalmaz, mint például a Keda, amely Azure funkciókat biztosít az OpenShift platformján.
Az integrált OpenShift ServiceMesh (Istio, Kiali, Jaeger) hasznos lesz a mikroszolgáltatások fejlesztése során.
A hagyományos alkalmazások és konténerek közötti szakadék csökkentése érdekében az OpenShift most lehetővé teszi a virtuális gépek migrálását az OpenShift platformra Container Native Virtualization révén (jelenleg TechPreview verzióban), valóra váltva a hibrid alkalmazásokat, és megkönnyítve azok átvitelét a különböző felhők között, legyenek azok magán vagy nyilvános felhők.
Windows 2019 Virtual virtuális gép, amely az OpenShift-en fut a Container Native Virtualization (jelenleg Tech preview verzióban) révén.
5. Eszközök a klaszterekhez
Bármely vállalati szintű platformnak rendelkeznie kell monitoring és központosított naplózási szolgáltatásokkal, biztonsági mechanizmusokkal, autentikálással és engedélyezéssel, valamint hálózati kezelési eszközökkel. Az OpenShift mindezt kínálja dobozból, ráadásul mindez 100%-ban nyílt forráskódú, olyan megoldásokkal, mint az ElasticSearch, Prometheus, Grafana. Mindezek a megoldások olyan irányítópultokkal, metrikákkal és értesítésekkel érkeznek, amelyek már az Red Hat széleskörű tapasztalatai alapján lettek összeszerelve és konfigurálva a klaszterek monitorozásában, lehetővé téve, hogy az első pillanattól kezdve hatékonyan ellenőrizzék és nyomon követhessék a produkciós környezetük működését.
Az OpenShiftben ezen kívül olyan fontos funkciók is megtalálhatók a vállalati ügyfelek számára, mint a beépített oauth szolgáltatóval végzett autentikáció, integráció a hitelesítő szolgáltatókkal, beleértve az LDAP-ot, Active Directory-t, OpenID Connectet és még sok mást.
Előre beállított Grafana irányítópult az OpenShift klaszter monitorozásához
Több mint 150 előre beállított Prometheus metrika és értesítés az OpenShift klaszter monitorozásához
Folytatás következik
A megoldás gazdag funkcionalitása és az Red Hat kiterjedt tapasztalata a Kubernetes területén – ezek a tényezők miatt az OpenShift domináló pozíciót szerzett a piacon, ahogy az az alábbi ábrán látható (további részletek ).
„Jelenleg a Red Hat 44% piaci részesedéssel vezet.
A cég a vásárlói ügyeiben való aktív részvételének stratégiájának gyümölcsét aratja, amely keretén belül először konzultálja és oktatja a vállalati fejlesztőket, majd monetizál, ahogy a vállalat elkezdi bevezetni a konténereket a produkcióba.”
(Forrás: )
Reméljük, tetszett ez a cikk. A sorozat következő bejegyzéseiben részletesebben foglalkozunk az OpenShift előnyeivel a Kubernetes-szel szemben az itt tárgyalt kategóriák mindegyikében.
Forrás: habr.com
