„Care este diferența dintre Kubernetes și OpenShift?” – această întrebare apare cu o consistență de invidiat. Deși, în realitate, este ca și cum ai întreba cum diferă o mașină de un motor. Dacă continuăm analogia, atunci o mașină este un produs finit, o puteți folosi imediat, la propriu: intrați și plecați. Pe de altă parte, pentru ca un motor să te ducă undeva, trebuie mai întâi completat cu o mulțime de alte lucruri pentru a obține în cele din urmă aceeași mașină.
Prin urmare, Kubernetes este motorul în jurul căruia este asamblată mașina (platforma) marca OpenShift, care te duce la obiectivul tău.
În acest articol dorim să vă reamintim și să examinăm următoarele puncte cheie mai detaliat:
- Kubernetes este inima platformei OpenShift și este 100% certificat Kubernetes, complet open source și fără nici cea mai mică natură proprietară. Scurt:
- API-ul pentru cluster OpenShift este 100% Kubernetes.
- Dacă containerul rulează pe orice alt sistem Kubernetes, atunci va rula pe OpenShift fără nicio modificare. Nu este nevoie să faceți modificări în aplicații.
- OpenShift nu numai că adaugă caracteristici și funcționalități utile la Kubernetes. Ca o mașină, OpenShift este scos din cutie, poate fi pus în producție imediat și, așa cum vom arăta mai jos, face viața unui dezvoltator mult mai ușoară. De aceea OpenShift este unit în două persoane. Este atât o platformă PaaS de clasă întreprindere de succes, cât și bine-cunoscută din perspectiva dezvoltatorului. Și, în același timp, este o soluție Container-as-a-Service super-fiabilă din punct de vedere al funcționării industriale.
OpenShift este Kubernetes cu certificare 100% CNCF
OpenShift se bazează pe . Prin urmare, după o pregătire adecvată, utilizatorii sunt uimiți de puterea kubectl. Iar cei care au trecut la OpenShift de la Kubernetes Cluster spun adesea cât de mult le place asta după redirecționarea kubeconfig către clusterul OpenShift, toate scripturile existente funcționează impecabil.
Probabil ați auzit despre utilitarul de linie de comandă al OpenShift numit OC. Este pe deplin compatibil cu kubectl cu comandă, plus că oferă mai multe ajutoare utili care vă vor fi la îndemână atunci când efectuați o serie de sarcini. Dar mai întâi, puțin mai multe despre compatibilitatea OC și kubectl:
comenzi kubectl
Echipele OC
kubectl obține păstăi
oc obține păstăi
kubectl obține spații de nume
oc obține spații de nume
kubectl create -f deployment.yaml
oc create -f deployment.yaml
Iată cum arată rezultatele utilizării kubectl pe API-ul OpenShift:
• kubectl get pods – returnează podurile așa cum era de așteptat.
• kubectl get namespaces – returnează namespaces așa cum era de așteptat.
Comanda kubectl create -f mydeployment.yaml creează resurse kubernetes la fel ca pe orice altă platformă Kubernetes, așa cum se arată în videoclipul de mai jos:
Cu alte cuvinte, toate API-urile Kubernetes sunt complet disponibile în OpenShift, păstrând în același timp compatibilitatea 100%. Acesta este motivul pentru care .
OpenShift adaugă caracteristici utile la Kubernetes
API-urile Kubernetes sunt 100% disponibile în OpenShift, dar utilitarul standard Kubernetes kubectl îi lipsește în mod clar funcționalitatea și comoditatea. De aceea, Red Hat a adăugat caracteristici utile și instrumente de linie de comandă la Kubernetes, cum ar fi OC (prescurtare pentru client OpenShift) și ODO (OpenShift DO, acest utilitar este destinat dezvoltatorilor).
1. Utilitar OC - o versiune mai puternică și mai convenabilă a Kubectl
De exemplu, spre deosebire de kubectl, vă permite să creați noi spații de nume și să comutați cu ușurință contextele și oferă, de asemenea, o serie de comenzi utile pentru dezvoltatori, cum ar fi construirea de imagini container și implementarea aplicațiilor direct din codul sursă sau binare (Sursă-la-imagine, s2i).
Să ne uităm la exemple despre cum ajutoarele încorporate și funcționalitățile avansate ale utilitarului OC ajută la simplificarea muncii de zi cu zi.
Primul exemplu este managementul spațiului de nume. Fiecare cluster Kubernetes are întotdeauna mai multe spații de nume. Ele sunt de obicei folosite pentru a crea medii de dezvoltare și producție, dar pot fi folosite și, de exemplu, pentru a oferi fiecărui dezvoltator un sandbox personal. În practică, acest lucru duce la nevoia dezvoltatorului de a comuta frecvent între spațiile de nume, deoarece kubectl rulează în contextul spațiului curent. Prin urmare, în cazul kubectl, oamenii folosesc în mod activ scripturi de ajutor pentru aceasta. Dar când utilizați OC, pentru a comuta la spațiul dorit, spuneți doar „oc project namespace”.
Nu vă amintiți cum se numește spațiul de nume de care aveți nevoie? Nicio problemă, trebuie doar să tastați „oc get projects” pentru a afișa lista completă. Vă întrebați sceptic cum va funcționa acest lucru dacă aveți acces doar la un subset limitat de spații de nume din cluster? Ei bine, pentru că kubectl face acest lucru corect numai dacă RBAC vă permite să vedeți toate spațiile din cluster, iar în clustere mari nu toată lumea are astfel de permisiuni. Așadar, răspundem: pentru OC aceasta nu este deloc o problemă și va produce cu ușurință o listă completă într-o astfel de situație. Aceste lucruri mici alcătuiesc orientarea corporativă a Openshift și scalabilitatea bună a acestei platforme în ceea ce privește utilizatorii și aplicațiile.
2. ODO - o versiune îmbunătățită a kubectl pentru dezvoltatori
Un alt exemplu de îmbunătățiri Red Hat OpenShift față de Kubernetes este utilitarul de linie de comandă ODO. Este conceput pentru dezvoltatori și vă permite să implementați rapid cod local într-un cluster OpenShift de la distanță. De asemenea, poate eficientiza procesele interne pentru a sincroniza instantaneu toate modificările de cod pe containerele dintr-un cluster OpenShift la distanță, fără a fi nevoie să reconstruiești, să înregistrezi și să redistribuie imaginile.
Să vedem cum OC și ODO facilitează lucrul cu containere și Kubernetes.
Comparați doar câteva fluxuri de lucru atunci când sunt construite pe baza kubectl și când sunt utilizate OC sau ODO.
• Implementarea codului pe OpenShift pentru cei care nu vorbesc YAML:
Kubernetes / kubectl
$>git clona
1- Creați un Dockerfile care construiește imaginea din cod
-----
DIN nod
WORKDIR /usr/src/app
COPIEAZĂ pachetul*.json ./
COPIEAZĂ index.js ./
COPY ./app ./app
RUN instalarea npm
EXPUNE 3000
CMD [ „npm”, „start” ]
-----
2- Construim imaginea
$>podman build...
3- Conectați-vă la registru
autentificare podman...
4- Plasați imaginea în registru
podman push
5- Creați fișiere yaml pentru implementarea aplicației (deployment.yaml, service.yaml, ingress.yaml) - acesta este minimul absolut
6- Implementați fișiere manifest:
Kubectl aplică -f .
OpenShift/oc
$> oc new-app – numele_aplicației_noastră
OpenShift/odo
$>git clona
$> odo create component nodejs myapp
$>odo push
• Comutare context: schimbați spațiul de nume de lucru sau clusterul de lucru.
Kubernetes / kubectl
1- Creați un context în kubeconfig pentru proiectul „myproject”
2- kubectl set-context...
OpenShift/oc
proiect oc „proiectul meu”
Controlul calității: „O caracteristică interesantă a apărut aici, încă în versiune alfa. Poate îl putem pune în producție?”
Imaginați-vă că sunteți așezat într-o mașină de curse și vi se spune: „Am instalat un nou tip de frâne și, sincer să fiu, fiabilitatea acestora nu este încă în regulă... Dar nu vă faceți griji, le vom îmbunătăți activ pe parcursul cursului. a campionatului.” Cum îți place această perspectivă? Noi, cei de la Red Hat, nu suntem cumva foarte fericiți. 🙂
Prin urmare, încercăm să reținem versiunile alfa până când sunt suficient de mature și am făcut teste de luptă amănunțite și simțim că sunt sigure de utilizat. De obicei, totul trece prin etapa de previzualizare a dezvoltatorului mai întâi, apoi prin etapa și abia apoi iese ca lansare publică (GA), care este deja atât de stabil încât este potrivit pentru producție.
De ce este asta? Pentru că, ca și în cazul dezvoltării oricărui alt software, nu toate ideile inițiale din Kubernetes ajung la versiunea finală. Sau ajung la el și chiar păstrează funcționalitatea dorită, dar implementarea lor este radical diferită de cea din versiunea alfa. Cu mii și mii de clienți Red Hat care folosesc OpenShift pentru a susține sarcini de lucru critice, punem un accent deosebit pe stabilitatea platformei noastre și pe suportul pe termen lung.
Red Hat se angajează să lanseze OpenShift în mod frecvent și să actualizeze versiunea Kubernetes care vine odată cu acesta. De exemplu, versiunea curentă GA a OpenShift 4.3 la momentul scrierii acestui articol include Kubernetes 1.16, care este doar o unitate în spatele versiunii din amonte a Kubernetes numerotată 1.17. Astfel, încercăm să oferim clientului Kubernetes de clasă enterprise și să oferim un control suplimentar al calității în timpul lansării noilor versiuni de OpenShift.
Remedieri software: „A existat o gaură în versiunea de Kubernetes pe care o avem în producție. Și îl puteți închide doar actualizând trei versiuni. Sau există variante?
În proiectul cu sursă deschisă Kubernetes, corecțiile software sunt de obicei lansate ca parte a următoarei ediții, uneori acoperind una sau două versiuni anterioare, oferind o acoperire înapoi în doar 6 luni.
Red Hat se mândrește cu lansarea de remedieri critice mai devreme decât altele și cu asistență pentru mult mai mult timp. Luați, de exemplu, vulnerabilitatea de escaladare a privilegiilor Kubernetes (): a fost descoperit în Kubernetes 1.11, iar corecțiile pentru versiunile anterioare au fost lansate doar până la versiunea 1.10.11, lăsând-o pe aceasta în gol în toate versiunile anterioare Kubernetes, de la 1.x la 1.9.
La rândul său, (Kubernetes 1.2 există), captând nouă versiuni OpenShift și demonstrând clar grija față de clienți (mai multe detalii ).
Cum OpenShift și Red Hat mută Kubernetes înainte
Red Hat este al doilea cel mai mare contributor de software la proiectul cu sursă deschisă Kubernetes, în urma doar Google, cu 3 dintre cei mai prolifici 5 dezvoltatori venind de la Red Hat. Un alt fapt puțin cunoscut: multe funcții critice au apărut în Kubernetes tocmai la inițiativa lui Red Hat, în special, cum ar fi:
- RBAC. Kubernetes nu a avut funcții RBAC (ClusterRole, ClusterRoleBinding) până când inginerii Red Hat au decis să le implementeze ca parte a platformei în sine, și nu ca funcționalitate suplimentară OpenShift. Îi este teamă lui Red Hat să îmbunătățească Kubernetes? Bineînțeles că nu, pentru că Red Hat urmează cu strictețe principiile open source și nu joacă jocuri Open Core. Îmbunătățirile și inovațiile care sunt conduse de comunitățile de dezvoltare, mai degrabă decât de cele proprietare, sunt mai viabile și mai larg adoptate, ceea ce se aliniază bine cu obiectivul nostru principal de a face software-ul open source mai util pentru clienții noștri.
- Politici de securitate pentru pods (Pod Security Policies). Acest concept de a rula aplicații în siguranță în interiorul podurilor a fost implementat inițial în OpenShift sub numele SCC (Security Context Constraints). Și ca și în exemplul anterior, Red Hat a decis să introducă aceste dezvoltări în proiectul deschis Kubernetes, astfel încât toată lumea să le poată folosi.
Această serie de exemple ar putea fi continuată, dar am vrut doar să arătăm că Red Hat este cu adevărat angajat să dezvolte Kubernetes și să-l îmbunătățească pentru toată lumea.
Este clar că OpenShift este Kubernetes. Care sunt diferențele? 🙂
Sperăm că citind până aici ați realizat că Kubernetes este componenta de bază a OpenShift. Principalul, dar departe de singurul. Cu alte cuvinte, simpla instalare a Kubernetes nu vă va oferi o platformă de clasă enterprise. Va trebui să adăugați autentificare, rețea, securitate, monitorizare, gestionare a jurnalelor și multe altele. În plus, va trebui să faceți niște alegeri dificile din numărul mare de instrumente disponibile (pentru a aprecia diversitatea ecosistemului, aruncați o privire ) și să asigure cumva consistență și coerență, astfel încât să funcționeze ca una. În plus, va trebui să efectuați în mod regulat actualizări și teste de regresie ori de câte ori este lansată o nouă versiune a oricăreia dintre componentele pe care le utilizați. Adică, pe lângă crearea și întreținerea platformei în sine, va trebui să vă ocupați și de tot acest software. Este puțin probabil să rămână mult timp pentru a rezolva problemele de afaceri și a obține avantaje competitive.
Dar, în cazul OpenShift, Red Hat preia toate aceste complexități și vă oferă pur și simplu o platformă completă funcțional, care include nu numai Kubernetes în sine, ci și întregul set de instrumente open source necesare care transformă Kubernetes într-o adevărată clasă enterprise. soluție pe care o puteți lansa imediat și complet calm în producție. Și, desigur, dacă aveți unele dintre propriile stive de tehnologie, atunci puteți integra OpenShift în soluțiile existente.
Aruncă o privire la imaginea de mai sus: tot ceea ce se află în afara dreptunghiului Kubernetes este locul în care Red Hat adaugă o funcționalitate pe care Kubernetes nu le are, după cum se spune, prin design. Și acum ne vom uita la principalele acestor domenii.
1. Sistem de operare robust ca bază: RHEL CoreOS sau RHEL
Red Hat este un furnizor de top de peste 20 de ani. Linux-distribuții pentru aplicații de business critice pentru misiune. Experiența noastră vastă și actualizată continuu în acest domeniu ne permite să oferim o bază cu adevărat fiabilă și de încredere pentru implementarea industrială a containerelor. RHEL CoreOS utilizează același kernel ca RHEL, dar este optimizat în principal pentru sarcini precum rularea containerelor și rularea în clustere Kubernetes: dimensiunea redusă și imutabilitatea simplifică configurarea clusterului, scalarea automată, implementarea patch-urilor și multe altele. Toate aceste caracteristici îl fac fundația ideală pentru a oferi o experiență consistentă pentru utilizatorii OpenShift într-o gamă largă de medii de calcul, de la bare metal la cloud-uri private și publice.
2. Automatizarea operațiunilor IT
Automatizarea proceselor de instalare și a operațiunilor din ziua 4 (adică operațiunile de zi cu zi) este punctul forte al OpenShift, ceea ce face mult mai ușor de administrat, actualizat și menținut performanța platformei container la cel mai înalt nivel. Acest lucru se realizează prin suport pentru operatorii Kubernetes la nivel de kernel OpenShift XNUMX.
OpenShift 4 este, de asemenea, un întreg ecosistem de soluții bazat pe operatori Kubernetes, dezvoltat atât de Red Hat în sine, cât și de parteneri terți (vezi. Red Hat, sau magazin de operator , creat de Red Hat pentru dezvoltatori terți).
Catalogul integrat OpenShift 4 include peste 180 de operatori Kubernetes
3. Instrumente pentru dezvoltatori
Din 2011, OpenShift este disponibil ca o platformă PaaS (Platform-as-a-Service) care face viața mult mai ușoară dezvoltatorilor, îi ajută să se concentreze pe codificare și oferă suport nativ pentru limbaje de programare precum Java, Node.js , PHP, Ruby, Python, Go, precum și servicii de integrare și livrare continuă CI/CD, baze de date etc. Oferă OpenShift 4 , care include peste 100 de servicii bazate pe operatorii Kubernetes dezvoltați de Red Hat și partenerii noștri.
Spre deosebire de Kubernetes, OpenShift 4 are o interfață grafică dedicată (), care îi ajută pe dezvoltatori să implementeze fără efort aplicații din diverse surse (git, registre externe, Dockerfile etc.) în spațiile lor de nume și vizualizează clar relațiile dintre componentele aplicației.
În plus, OpenShift oferă un set de instrumente de dezvoltare Codeready, care, în special, include , un IDE complet containerizat cu o interfață web care rulează direct pe OpenShift și implementează o abordare IDE-as-a-service. Pe de altă parte, pentru cei care doresc să lucreze strict în modul local, există Codeready Containers, o versiune complet funcțională a OpenShift 4 care poate fi implementată pe un laptop.
IDE integrat ca serviciu pentru dezvoltare eficientă pe platforma Kubernetes/OpenShift
OpenShift oferă un sistem complet CI/CD imediat din cutie, fie bazat pe Jenkins containerizat și un plugin pentru lucrul cu conducte sau cu un sistem CI/CD orientat spre Kubernetes (în prezent în versiunea de previzualizare Tech). Ambele soluții se integrează pe deplin cu consola OpenShift, permițându-vă să rulați declanșatoare de conducte, să vizualizați implementări, jurnalele și multe altele.
4. Instrumente de aplicare
OpenShift vă permite să implementați atât aplicații tradiționale cu stare, cât și soluții bazate pe cloud bazate pe noi arhitecturi, cum ar fi microservicii sau serverless. Soluția OpenShift Service Mesh vine imediat din cutie cu instrumente cheie pentru întreținerea microserviciilor, cum ar fi Istio, Kiali și Jaeger. La rândul său, soluția OpenShift Serverless include nu numai Knative, ci și instrumente precum Keda create ca parte a unei inițiative comune cu Microsoft pentru a oferi funcții Azure pe platforma OpenShift.
Soluția integrată OpenShift ServiceMesh (Istio, Kiali, Jaeger) va fi utilă la dezvoltarea microserviciilor
Pentru a reduce decalajul dintre aplicațiile vechi și containere, OpenShift permite acum migrarea mașinilor virtuale la platforma OpenShift folosind Container Native Virtualization (în prezent în TechPreview), făcând aplicații hibride o realitate și facilitând migrarea acestora între diferite cloud-uri, atât private, cât și publice.
Mașină virtuală Windows 2019 Virtual, rulând pe OpenShift prin Container Native Virtualization (în prezent în Tech Preview)
5. Instrumente pentru clustere
Orice platformă de clasă enterprise trebuie să aibă servicii de monitorizare și înregistrare centralizată, mecanisme de securitate, autentificare și autorizare și instrumente de gestionare a rețelei. Și OpenShift oferă toate acestea de la cutie și este totul 100% open source, inclusiv soluții precum ElasticSearch, Prometheus, Grafana. Toate aceste soluții vin cu tablouri de bord, metrici și alerte care sunt deja construite și configurate folosind experiența extinsă de monitorizare a clusterelor Red Hat, permițându-vă să controlați și să monitorizați eficient mediul de producție chiar de la început.
OpenShift vine, de asemenea, standard cu lucruri atât de importante pentru clienții corporativi, cum ar fi autentificarea cu un furnizor de oauth încorporat, integrarea cu furnizorii de acreditări, inclusiv LDAP, ActiveDirectory, OpenID Connect și multe altele.
Tabloul de bord Grafana preconfigurat pentru monitorizarea clusterului OpenShift
Peste 150 de valori și alerte Prometheus preconfigurate pentru monitorizarea clusterului OpenShift
Va urma
Funcționalitatea bogată a soluției și experiența vastă a Red Hat în domeniul Kubernetes sunt motivele pentru care OpenShift a obținut o poziție dominantă pe piață, așa cum se arată în figura de mai jos (citește mai mult ).
„Red Hat conduce în prezent piața cu o cotă de 44%.
Compania culege beneficiile strategiei sale de vânzări centrate pe client, în care mai întâi consultă și antrenează dezvoltatorii întreprinderii și apoi trece la monetizare pe măsură ce întreprinderea începe să implementeze containerele în producție.”
(O sursă: )
Sperăm că v-a plăcut acest articol. În postările viitoare din această serie, vom arunca o privire mai atentă asupra avantajelor OpenShift față de Kubernetes în fiecare dintre categoriile discutate aici.
Sursa: www.habr.com
