„Jaký je rozdíl mezi Kubernetes a OpenShift?“ – tato otázka se objevuje s neobvyklou pravidelností. Ve skutečnosti je to jako ptát se, jaký je rozdíl mezi automobilem a motorem. Pokud to vezmeme v úvahu, auto je hotový produkt, který můžete okamžitě používat, jednoduše: nastupte a jeďte. Na druhé straně, abyste motor mohli někam vzít, musíte ho nejprve doplnit řadou dalších věcí, abyste nakonec dostali stejné auto.
Proto je Kubernetes motor, kolem kterého je postaveno auto (platforma) značky OpenShift, které vás řídí k cíli.
V tomto článku vám chceme připomenout a podrobněji prozkoumat následující klíčové body:
- Kubernetes je srdcem platformy OpenShift a je to 100% certifikovaný Kubernetes, s plně otevřeným kódem a bez jakékoli proprietární části. Stručně řečeno:
- API pro OpenShift klastry je stoprocentní Kubernetes.
- Pokud kontejner funguje v jakémkoli jiném systému Kubernetes, bude fungovat i na OpenShift bez jakýchkoli změn. Není potřeba provádět změny v aplikacích.
- OpenShift nejen doplňuje Kubernetes užitečnými funkcemi a možnostmi. Stejně jako auto je OpenShift okamžitě připraven k použití, lze ho okamžitě uvést do produkce a, jak ukážeme níže, velmi usnadňuje život vývojáři. Právě proto je OpenShift jedinečný ve dvou podobách. Je to jak úspěšná a široce známá PaaS platforma podnikové třídy z pohledu vývojáře, tak zároveň super spolehlivé řešení typu Container-as-a-Service z hlediska průmyslového nasazení.
OpenShift je Kubernetes se 100% certifikací od CNCF
OpenShift je založen na . Proto po odpovídajícím školení uživatelé obdivují sílu kubectl. A ti, kteří přešli na OpenShift z Kubernetes Cluster, často říkají, jak se jim velmi líbí, že po přesměrování kubeconfig na OpenShift cluster všechny existující skripty fungují bezchybně.
Určitě jste slyšeli o OpenShift příkazovém rozhraní známém jako OC. Je plně kompatibilní s příkazy kubectl a navíc nabízí několik užitečných pomocných funkcí, které se hodí při provádění celého řady úkolů. Ale ze začátku podrobněji o kompatibilitě OC a kubectl:
Příkazy kubectl
Příkazy OC
kubectl get pods
oc get pods
kubectl get namespaces
oc get namespaces
kubectl create -f deployment.yaml
oc create -f deployment.yaml
Takto vypadají výsledky použití kubectl na OpenShift API:
• kubectl get pods – jak se dalo očekávat, vrací pod.
• kubectl get namespaces – jak se dalo očekávat, vrací prostory jmen.
Příkaz kubectl create -f mydeployment.yaml vytváří kubernetesové zdroje stejně jako na jakékoli jiné platformě Kubernetes, jak je ukázáno ve videu níže:
Jinými slovy, všechny Kubernetes API jsou plně dostupné v OpenShift s 100% kompatibilitou. Proto .
OpenShift doplňuje Kubernetes užitečnými funkcemi
Kubernetes API jsou 100% dostupná v OpenShift, ale standardní utitlita Kubernetes, kubectl, postrádá funkčnost a pohodlí. Proto Red Hat doplnil Kubernetes užitečnými funkcemi a nástroji příkazového řádku, jako jsou OC (zkratka pro OpenShift client) a ODO (OpenShift DO, tento nástroj je určen pro vývojáře).
1. Nástroj OC – mocnější a uživatelsky přívětivější varianta Kubectl
Například na rozdíl od kubectl, umožňuje vytvářet nová jména prostorů a snadno přepínat kontext, a také nabízí řadu užitečných příkazů pro vývojáře, například pro sestavení kontejnerových obrazů a nasazení aplikací přímo ze zdrojového kódu nebo binárních souborů (Source-to-image, s2i).
Podívejme se na příklady, jak vestavěné helpery a rozšířená funkčnost nástroje OC usnadňují každodenní práci.
První příklad – správa jmen prostorů. V každém Kubernetes clusteru je vždy několik jmen prostorů. Obvykle se používají pro vytváření vývojových a produkčních prostředí, ale mohou být také použity například pro přidělení každému vývojáři osobní "píseček". V praxi to vede k tomu, že se vývojář často musí přepínat mezi jmény prostorů, protože kubectl pracuje v kontextu aktuálního prostoru. Proto se v případě kubectl aktivně používají helper skripty. Při použití OC je však pro přepnutí na požadovaný prostor dostatečné říci "oc project jméno_prostoru".
Nepamatujete si, jak se jmenuje požadovaný prostor jmen? Žádný problém, stačí zadat "oc get projects", abyste na obrazovku vypsali celý seznam. Skepticky se ptáte, jak to bude fungovat, pokud máte přístup pouze k omezenému podmnožství prostorů jmen na clusteru? Protože kubectl to dělá správně, pouze pokud vám RBAC umožňuje vidět všechny prostory na clusteru, a v těchto velkých clusterech takové oprávnění nedostává každý. Takže odpovídáme: pro OC to rozhodně není problém a snadno v této situaci poskytne celý seznam. Z takových drobností se skládá firemní orientace Openshift a dobrá škálovatelnost této platformy v oblasti uživatelů a aplikací.
2. ODO – vylepšená verze kubectl pro vývojáře
Dalším příkladem vylepšení Red Hat OpenShift oproti Kubernetes je příkazová řádka ODO. Je určena pro vývojáře a umožňuje rychle nasazovat lokální kód na vzdáleném clusteru OpenShift. Kromě toho lze s jejíž pomocí optimalizovat vnitřní procesy pro okamžitou synchronizaci všech změn kódu s kontejnery na vzdáleném clusteru OpenShift, aniž bychom museli opakovaně provádět sestavení, publikování v registru a opětovné nasazení obrazů.
Pojďme se podívat, jak OC a ODO usnadňují práci s kontejnery a Kubernetes.
Jednoduše porovnáme pár pracovních toků, když jsou postaveny na základě kubectl, a když se používají OC nebo ODO.
• Nasazení kódu na OpenShift pro ty, kteří neovládají jazyk YAML:
Kubernetes / kubectl
$> git clone
1- Vytvoříme Dockerfile, který provede sestavení obrazu z kódu
————–
FROM node
WORKDIR /usr/src/app
COPY package*.json ./
COPY index.js ./
COPY ./app ./app
RUN npm install
EXPOSE 3000
CMD [ "npm", "start" ]
————–
2- Provádíme sestavení obrazu
$> podman build …
3- Přihlašujeme se do registru
podman login …
4- Publikujeme obraz v registru
podman push
5- Vytváříme yaml soubory pro nasazení aplikace (deployment.yaml, service.yaml, ingress.yaml) – to je absolutní minimum
6- Nasazujeme manifest soubory:
Kubectl apply -f .
OpenShift / oc
$> oc new-app – jméno_naší_aplikace
OpenShift / odo
$> git clone
$> odo create component nodejs myapp
$> odo push
• Přepínání kontextu: změna pracovního prostoru jmen nebo pracovního clusteru.
Kubernetes / kubectl
1- Vytvoříme kontext v kubeconfig pro projekt "myproject"
2- kubectl set-context …
OpenShift / oc
oc project "myproject"
Kontrola kvality: „Objevila se zde jedna zajímavá funkce, zatím v alfa verzi. Možná ji uvedeme do produkce?“
Představte si, že vás posadí do závodního auta a řeknou: „Nainstalovali jsme tady nové brzdy a, upřímně řečeno, zatím nemají úplně nejlepší spolehlivost… Ale nebojte se, budeme je aktivně vyvíjet během závodního šampionátu.“ Jak se vám taková perspektiva líbí? Nám v Red Hat to moc nevoní. 🙂
Proto se snažíme vyhýbat alfa verzím, dokud nejsou dostatečně zralé, a neprovedeme důkladné testování a nebudeme mít pocit, že je možné je bezpečně používat. Obvykle prochází vším nejprve fází Dev Preview, pak a až poté vychází ve formě veřejného vydání (GA), které je už tak stabilní, že je vhodné pro produkci.
Proč tomu tak je? Protože, stejně jako při vývoji jakéhokoli jiného softwaru, rozhodně ne všechny původní návrhy v Kubernetes dosahují finálního vydání. Nebo dosahují, a dokonce si zachovávají zamýšlenou funkčnost, ale jejich realizace se radikálně liší od té, která byla v alfa verzi. Vzhledem k tomu, že tisíce klientů Red Hat používají OpenShift k podpoře kritických úloh, klademe zvláštní důraz na stabilitu naší platformy a dlouhodobou podporu.
Red Hat cíleně vydává časté verze OpenShift a aktualizuje verzi Kubernetes, která je jeho součástí. Například v aktuálním GA vydání OpenShift 4.3, platném v době psaní tohoto článku, je integrovaná Kubernetes 1.16, což je jen o jeden krok pozadu za upstream verzí Kubernetes s číslem 1.17. Usilujeme tak o to, abychom zákazníkům poskytli podnikové Kubernetes a zajistili dodatečnou kontrolu kvality během vydávání nových verzí OpenShift.
Opravy: „Ve verzi Kubernetes, kterou máme v produkci, byla zjištěna značka. A můžeme ji opravit jen aktualizací na tři verze výše. Nebo jsou i jiné možnosti?“
V rámci otevřeného projektu Kubernetes obvykle opravy vycházejí v rámci další verze, někdy pokrývají jednu nebo dvě předchozí mezivydání, což zajišťuje pokrytí až 6 měsíců zpětně.
Red Hat se právem pyšní tím, že vydává kritické opravy dříve než ostatní a poskytuje podporu po mnohem delší dobu. Vezměme si například zranitelnost s eskalací privilegií v Kubernetes (): ta byla odhalena v Kubernetes 1.11, a opravy pro předchozí verze byly uvolněny pouze do verze 1.10.11, což ponechalo tuto díru ve všech předchozích verzích Kubernetes, od 1.x po 1.9.
Na druhou stranu, (ta má Kubernetes 1.2), což pokrývá devět verzí OpenShift a jasně demonstruje péči o zákazníky (více ).
Jak OpenShift a Red Hat posouvají Kubernetes vpřed
Red Hat se umístil na druhém místě podle objemu příspěvků do otevřeného projektu Kubernetes, přičemž pouze Google je lepší, a 3 z 5 nejplodnějších vývojářů jsou zaměstnanci Red Hat. Další málo známý fakt: mnoho kritických funkcí se do Kubernetes dostalo díky iniciativě Red Hat, včetně funkcí, jako je:
- RBAC. V Kubernetes nebyly funkce RBAC (ClusterRole, ClusterRoleBinding) implementovány, dokud inženýři Red Hat nerozhodli je začlenit do samotné platformy, a ne jako dodatečnou funkcionalitu OpenShift. Nebojí se Red Hat vylepšovat Kubernetes? Určitě ne, protože Red Hat důsledně dodržuje principy otevřeného kódu a nehrát si na Open Core. Vylepšení a novinky, které jsou realizovány na úrovni vývojových komunit, a ne na základě vlastnických principů, se stávají životaschopnějšími a získávají širší přijetí, což skvěle souvisí s naším hlavním cílem – učinit software s otevřeným kódem užitečnějším pro naše zákazníky.
- Bezpečnostní politiky pro pod(y) (Pod Security Policies). Původně byla tato koncepce bezpečného provádění aplikací uvnitř podů implementována v OpenShift pod názvem SCC (Security Context Constraints). A stejně jako v předchozím příkladu se Red Hat rozhodl tyto práce začlenit do otevřeného projektu Kubernetes, aby jimi mohli využívat všichni zájemci.
Tento řetězec příkladů lze pokračovat, ale chtěli jsme jen ukázat, že Red Hat skutečně usiluje o rozvoj Kubernetes a jeho zlepšení pro všechny.
Je jasné, že OpenShift je Kubernetes. A jaké jsou vlastně rozdíly? 🙂
Doufáme, že po přečtení této části chápete, že Kubernetes je základní komponentou OpenShift. Základní, ale rozhodně ne jedinou. Jinými slovy, pouhou instalací Kubernetes nezískáte platformu podnikové třídy. Budete muset přidat autentizaci, síť, zabezpečení, monitoring, správu protokolů a mnohé další. Kromě toho budete čelit těžkému rozhodování mezi mnoha dostupnými nástroji (pro posouzení rozmanitosti ekosystému se jednoduše podívejte ) a nějak zajistit soudržnost a koordinaci, aby fungovaly jako jeden celek. Kromě toho budete pravidelně muset provádět aktualizace a regresní testování při vydání nové verze jakéhokoliv z používaných komponent. To znamená, že kromě vytváření a údržby samotné platformy se budete muset věnovat i celému tomuto softwaru. Očekávejte, že na řešení obchodních problémů a dosažení konkurenceschopnosti nezbude mnoho času.
Ale v případě OpenShift se Red Hat postará o všechny tyto složitosti a jednoduše vám poskytne funkčně ucelenou platformu, která zahrnuje nejen samotný Kubernetes, ale i kompletní sadu nezbytných nástrojů s otevřeným zdrojovým kódem, které přetvářejí Kubernetes na skutečné řešení podnikové třídy, které můžete ihned a zcela klidně nasadit do produkce. A samozřejmě, pokud máte nějaké vlastní technologické stacky, můžete integrovat OpenShift do již existujících řešení.
Podívejte se na obrázek výše: vše, co se nachází mimo obdélník Kubernetes, jsou oblasti, kde Red Hat přidává funkce, které v Kubernetes nejsou, jak se říká, by-design. A nyní se podíváme na některé z těchto hlavních oblastí.
1. Spolehlivý OS jako základ: RHEL CoreOS nebo RHEL
Red Hat je již více než 20 let vedoucím poskytovatelem Linuxových distribucí pro kritické obchodní aplikace. Zkušenosti, které jsme v této oblasti získali a neustále aktualizujeme, nám umožňují nabídnout skutečně spolehlivý a důvěryhodný základ pro průmyslový provoz kontejnerů. RHEL CoreOS používá jádro stejné jako RHEL, ale je optimalizováno zejména pro úlohy jako je provoz kontejnerů a práce ve Kubernetes clusterech: jeho zmenšená velikost a neměnnost (immutability) usnadňují instalaci clusterů, automatické škálování, nasazení oprav atd. Všechny tyto funkce z něj činí ideální základ pro zajištění stejného uživatelského zážitku při práci s OpenShift v různých výpočetních prostředích, od „holého železa“ po soukromé a veřejné cloudové služby.
2. Automatizace IT operací
Automatizace procesů nasazení a každodenního provozu (tedy každodenní správy) je silnou stránkou OpenShift, která výrazně usnadňuje administraci, aktualizaci a údržbu kontejnerové platformy na nejvyšší úrovni. Toho se dosahuje díky podpoře Kubernetes operátorů na úrovni jádra OpenShift 4.
OpenShift 4 je také celá ekosystém řešení založeného na Kubernetes operátorech, které vyvinula jak samotná Red Hat, tak i externí partneři (viz Red Hat, nebo obchod operátorů , který vytvořila Red Hat pro externí vývojáře).
Součástí integrovaného katalogu OpenShift 4 je více než 180 Kubernetes operátorů
3. Nástroje pro vývojáře
Od roku 2011 je OpenShift k dispozici jako platforma PaaS (Platform-as-a-Service), která výrazně usnadňuje život vývojářům, pomáhá jim soustředit se na psaní kódu a nabízí zabudovanou podporu pro programovací jazyky jako Java, Node.js, PHP, Ruby, Python, Go, jakož i služby kontinuální integrace a doručování CI/CD, databáze atd. OpenShift 4 nabízí , zahrnující více než 100 služeb založených na Kubernetes operátorech, které vyvinula Red Hat a naši partneři.
Na rozdíl od Kubernetes má OpenShift 4 speciální grafické rozhraní (), který umožňuje vývojářům bez námahy nasazovat aplikace ze různých zdrojů (git, externí registry, Dockerfile atd.) do jejich jmenných prostorů a vizuálně zobrazovat vazby mezi komponenty aplikace.
Kromě toho OpenShift nabízí soubor vývojových nástrojů Codeready, který zahrnuje mimo jiné: , plně kontejnerizované IDE s webovým rozhraním, která funguje přímo na OpenShift a realizuje přístup „IDE jako služba“. Na druhou stranu, pro ty, kteří chtějí pracovat přísně v lokálním režimu, jsou tu Codeready Containers – plnohodnotná verze OpenShift 4, kterou lze nasadit na notebooku.
Integrované „IDE jako služba“ pro efektivní vývoj na platformě Kubernetes/OpenShift.
OpenShift přímo z krabice nabízí plně funkční systém CI/CD, buď na základě kontejnerizovaného Jenkins a pluginu , který pracuje s potrubími, nebo CI/CD systémy orientovanými na Kubernetes. (zatím v Tech preview). Obě řešení se plně integrují s konzolí OpenShift, což umožňuje spouštět spouštěče potrubí, prohlížet nasazení, protokoly atd.
4. Nástroje pro aplikace
OpenShift umožňuje nasazovat jak tradiční stateful aplikace, tak cloudově orientovaná řešení na základě nových architektur, jako jsou mikroservisy nebo serverless. Řešení OpenShift Service Mesh z krabice obsahuje klíčové nástroje pro správu mikroservisů, jako jsou Istio, Kiali a Jaeger. Na druhou stranu, Řešení OpenShift Serverless zahrnuje nejen Knative, ale i nástroje vytvořené v rámci spolupráce s Microsoftem, jako je Keda pro poskytování funkcí Azure na platformě OpenShift.
Integrované řešení OpenShift ServiceMesh (Istio, Kiali, Jaeger) bude užitečné při vývoji mikroservisů.
Aby se zkrátil rozdíl mezi dědictvím aplikací a kontejnery, OpenShift nyní umožňuje provádět migraci virtuálních strojů na platformu OpenShift pomocí Container Native Virtualization (zatím v TechPreview), což přetváří hybridní aplikace na realitu a usnadňuje jejich přenos mezi různými cloudy, jak soukromými, tak veřejnými.
Virtuální stroj Windows 2019 Virtual, běžící na OpenShift přes Container Native Virtualization (zatím v Tech preview).
5. Nástroje pro clustery
Každá platforma podnikové třídy by měla mít monitorovací a centralizované logovací služby, bezpečnostní mechanismy, autentizaci a autorizaci, nástroje pro správu sítě. A OpenShift toto vše nabízí již v základním vybavení, a to vše na 100 % jako open-source kód, včetně řešení jako ElasticSearch, Prometheus, Grafana. Všechny tyto řešení přicházejí s informačními panely, metrikami a upozorněním, která jsou již sestavená a nastavena s ohledem na rozsáhlé zkušenosti společnosti Red Hat v oblasti monitorování clusterů, což umožňuje efektivně řídit a sledovat provoz vaší produkční prostředí již od prvních minut.
OpenShift také Standardně obsahuje důležité prvky pro podnikové zákazníky, jako je autentizace s integrovaným poskytovatelem oauth, integrace s poskytovateli identit, včetně LDAP, Active Directory, OpenID Connect a mnoha dalšími.
Přednastavený informační panel Grafana pro monitorování clusteru OpenShift
Více než 150 přednastavených metrik a upozornění Prometheus pro monitorování clusteru OpenShift
Pokračování příště
Bohatá funkčnost řešení a rozsáhlé zkušenosti společnosti Red Hat v oblasti Kubernetes – právě tyto důvody posunuly OpenShift na dominantní pozici na trhu, jak je ukázáno na obrázku níže (více podrobností ).
„V současné době je Red Hat lídrem na trhu s podílem 44 %.
Společnost sklízí plody své prodejní strategie se silnou účastí na klientech, v rámci které nejprve konzultuje a školí podnikové vývojáře, a poté přechází k monetizaci, jakmile podnik začne zavádět kontejnery do produkce.“
(Zdroj: )
Doufáme, že se vám tento článek líbil. V dalších příspěvcích z této série se podrobněji podíváme na výhody OpenShift v porovnání s Kubernetes v každé z kategorií, které jsme zde probrali.
Zdroj: habr.com
