„Care este diferența dintre Kubernetes și OpenShift?” – această întrebare apare cu o frecvență remarcabilă. De fapt, este ca și cum ai întreba ce diferențiază o mașină de motor. Dacă continuăm analogia, mașina este un produs finit, ce poate fi utilizat imediat, pur și simplu: urci și pleci. Pe de altă parte, pentru ca motorul să te ducă undeva, trebuie să fie completat cu o mulțime de alte lucruri pentru a obține aceeași mașină.
De aceea, Kubernetes este motorul din jurul căruia este construită mașina (platforma) OpenShift, care te duce către scopul tău.
În acest articol, dorim să reamintim și să discutăm în detaliu următoarele puncte cheie:
- Kubernetes este inima platformei OpenShift. Și este un Kubernetes 100% certificat, cu cod complet deschis și fără nicio proprietate. Pe scurt:
- API-ul pentru clusterele OpenShift este un Kubernetes 100%.
- Dacă un container funcționează în orice alt sistem Kubernetes, acesta va funcționa fără nicio modificare și pe OpenShift. Nu este nevoie să faci modificări în aplicații.
- OpenShift nu doar completează Kubernetes cu funcționalități și capabilități utile. La fel ca o mașină, OpenShift este pregătit pentru utilizare imediată, poate fi dus imediat în producție și, așa cum vom arăta mai jos, facilitează considerabil viața dezvoltatorului. De aceea, OpenShift este unic în cele două fețe. Este atât o platformă PaaS de succes și bine cunoscută la nivel de întreprindere, din perspectiva dezvoltatorului, cât și o soluție ultra-fiabilă de tip Container-as-a-Service din perspectiva exploatării industriale.
OpenShift este Kubernetes cu certificare 100% de la fundația CNCF.
La baza OpenShift stă . Așadar, după o instruire adecvată, utilizatorii sunt impresionati de puterea kubectl. Iar cei care au migrat pe OpenShift de la Kubernetes Cluster adesea menționează cât de mult le place că, după redirecționarea kubeconfig către clusterul OpenShift, toate scripturile existente funcționează impecabil.
Cu siguranță ați auzit despre utilitarul din linia de comandă OpenShift numit OC. Este complet compatibil cu comenzile kubectl și oferă, în plus, câțiva helperi utili care vor fi necesari pentru o serie întreagă de sarcini. Dar mai întâi, un pic mai în detaliu despre compatibilitatea OC și kubectl:
Comenzile kubectl
Comenzile OC
kubectl get pods
oc get pods
kubectl get namespaces
oc get namespaces
kubectl create -f deployment.yaml
oc create -f deployment.yaml
Iată cum arată rezultatele folosirii kubectl pe API-ul OpenShift:
• kubectl get pods – returnează, așa cum era de așteptat, pod-urile.
• kubectl get namespaces – returnează, așa cum era de așteptat, spațiile de nume.
Comanda kubectl create -f mydeployment.yaml creează resurse Kubernetes exact ca pe orice altă platformă Kubernetes, așa cum este prezentat în videoclipul de mai jos:
Cu alte cuvinte, toate API-urile Kubernetes sunt complet accesibile în OpenShift, menținând 100% compatibilitate. De aceea, .
OpenShift completează Kubernetes cu funcționalități utile
API-urile Kubernetes sunt 100% disponibile în OpenShift, dar utilitarul standard Kubernetes, kubectl, nu oferă suficientă funcționalitate și comoditate. De aceea, Red Hat a adăugat funcționalități și instrumente de linie de comandă utile, cum ar fi OC (prescurtare de la OpenShift client) și ODO (OpenShift DO, acest utilitar este destinat dezvoltatorilor).
1. Utilitarul OC – o versiune mai puternică și mai convenabilă decât Kubectl
De exemplu, spre deosebire de kubectl, permite crearea de noi spații de nume și schimbarea contextului cu ușurință, oferind, de asemenea, o serie de comenzi utile pentru dezvoltatori, cum ar fi pentru construirea imaginilor de containere și desfășurarea aplicațiilor direct din codul sursă sau din fișiere binare (Source-to-image, s2i).
Să analizăm prin exemple cum ajutoarele încorporate și funcționalitatea extinsă a utilitarului OC ajută la simplificarea muncii de zi cu zi.
Primul exemplu – gestionarea spațiilor de nume. În fiecare cluster Kubernetes există întotdeauna mai multe spații de nume. Acestea sunt folosite de obicei pentru a crea medii de dezvoltare și producție, dar pot fi utilizate și pentru a oferi fiecărui dezvoltator un „sandbox” personal. În practică, aceasta înseamnă că dezvoltatorul trebuie să comute frecvent între spațiile de nume, deoarece kubectl funcționează în contextul spațiului curent. Așadar, în cazul kubectl, oamenii folosesc activ scripturi de ajutor pentru a face acest lucru. Însă, atunci când folosești OC, pentru a comuta pe spațiul dorit, este suficient să spui “oc project spațiu_nume”.
Nu îți amintești cum se numește spațiul de nume dorit? Nicio problemă, pur și simplu introdu „oc get projects” pentru a afișa o listă completă. Ești sceptic în privința modului în care va funcționa asta dacă ai acces doar la un subset restrâns de spații de nume în cluster? Ei bine, deoarece kubectl face asta corect doar dacă RBAC îți permite să vezi toate spațiile din cluster, iar în clusterele mari aceste permisiuni nu sunt acordate tuturor. Așadar, răspunsul este: pentru OC, aceasta nu este o problemă și va oferi cu ușurință o listă completă în această situație. Aceste mici detalii contribuie la orientarea corporate Openshift și la buna scalabilitate 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 aduse de Red Hat OpenShift în comparație cu Kubernetes este utilitarul de linie de comandă ODO. Acesta este destinat dezvoltatorilor și permite desfășurarea rapidă a codului local pe un cluster OpenShift la distanță. În plus, cu ajutorul său, poți optimiza procesele interne pentru a sincroniza instantaneu toate modificările de cod cu containerele de pe clusterul OpenShift la distanță, fără a fi nevoie să reconstruiești, să publici în registru și să desfășori din nou imaginile.
Să vedem cum OC și ODO fac mai ușoară lucrul cu containerele și Kubernetes.
Să comparăm câteva procese de lucru, când sunt construite pe baza kubectl, și când se aplică OC sau ODO.
• Desfășurarea codului pe OpenShift pentru cei care nu stăpânesc limbajul YAML:
Kubernetes / kubectl
$> git clone
1- Creăm un Dockerfile care construiește imaginea din cod
————–
FROM node
WORKDIR /usr/src/app
COPY package*.json ./
COPY index.js ./
COPY ./app ./app
RUN npm install
EXPOSE 3000
CMD [ "npm", "start" ]
————–
2- Executăm construirea imaginii
$> podman build …
3- Ne conectăm la registru
podman login …
4- Publicăm imaginea în registru
podman push
5- Creăm fișiere YAML pentru desfășurarea aplicației (deployment.yaml, service.yaml, ingress.yaml) – acesta este minimul absolut
6- Desfășurăm fișierele manifest:
Kubectl apply -f .
OpenShift / oc
$> oc new-app – numele_aplicației_noastre
OpenShift / odo
$> git clone
$> odo create component nodejs myapp
$> odo push
• Schimbarea contextului: schimbarea spațiului de nume de lucru sau a clusterului de lucru.
Kubernetes / kubectl
1- Creăm un context în kubeconfig pentru proiectul „myproject”
2- kubectl set-context …
OpenShift / oc
oc project „myproject”
Controlul calității: „A apărut o funcție interesantă aici, în prezent în versiune alpha. O vom implementa în producție?”
Imaginați-vă că sunteți așezat într-o mașină de curse și vi se spune: „Am instalat frâne de nou tip și, sincer, nu sunt foarte fiabile în acest moment... Dar nu vă faceți griji, le vom perfecționa pe parcursul campionatului.” Cum vi se pare această perspectivă? Nouă, la Red Hat, nu prea ne convine. 🙂
De aceea, ne străduim să ne abținem de la versiunile alpha până când acestea nu sunt suficient mature și până când nu efectuăm testări riguroase în condiții reale și nu simțim că pot fi utilizate în siguranță. De obicei, totul trece mai întâi printr-o etapă Dev Preview, apoi prin și abia apoi este lansat ca o versiune publică (GA), care este deja stabilă suficient pentru a fi utilizată în producție.
De ce este așa? Pentru că, la fel ca în dezvoltarea orice alt software, nu toate ideile inițiale în Kubernetes ajung la versiunea finală. Sau ajung, și chiar își păstrează funcționalitatea dorită, dar implementarea este radical diferită de cea din versiunea alpha. Având în vedere că mii și mii de clienți Red Hat utilizează OpenShift pentru a suporta sarcini critice, punem un accent deosebit pe stabilitatea platformei noastre și pe suportul pe termen lung.
Red Hat lansează în mod intenționat actualizări frecvente pentru OpenShift și actualizează versiunea Kubernetes inclusă în acesta. De exemplu, în versiunea GA OpenShift 4.3 disponibilă la data scrierii acestui articol, este integrată Kubernetes 1.16, care este cu o versiune în urmă față de versiunea upstream Kubernetes 1.17. Astfel, ne străduim să oferim clienților Kubernetes de clasă enterprise și să asigurăm un control suplimentar al calității în procesul de lansare a noilor versiuni OpenShift.
Corecții software: „În versiunea Kubernetes pe care o avem în producție, a fost descoperită o vulnerabilitate. Și pentru a o remedia, este necesară o actualizare de trei versiuni. Sau există alte opțiuni?”
În cadrul proiectului open source Kubernetes, corecțiile software sunt de obicei incluse în următoarea lansare, uneori acoperind una sau două lansări intermediare anterioare, ceea ce oferă o acoperire de până la 6 luni în urmă.
Red Hat se mândrește pe bună dreptate că lansează corecții critice mai devreme decât alții și oferă suport pe o durată mult mai lungă. Să luăm, de exemplu, vulnerabilitatea de escaladare a privilegiilor în Kubernetes (): aceasta 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 această vulnerabilitate în toate versiunile anterioare ale Kubernetes, de la 1.x la 1.9.
În schimb, (care folosește Kubernetes 1.2), acoperind nouă versiuni OpenShift și demonstrând clar grija față de clienți (mai multe detalii ).
Cum OpenShift și Red Hat promovează Kubernetes
Red Hat ocupă locul doi în ceea ce privește contribuțiile programatice către proiectul deschis Kubernetes, fiind depășită doar de Google, iar 3 din 5 cei mai prolifici dezvoltatori sunt angajați ai Red Hat. Un alt fapt puțin cunoscut: multe funcții esențiale au fost adăugate în Kubernetes la inițiativa Red Hat, în special, cum ar fi:
- RBAC. În Kubernetes nu existau funcții RBAC (ClusterRole, ClusterRoleBinding) până când inginerii Red Hat nu au decis să le implementeze în cadrul platformei însăși, și nu ca o funcționalitate suplimentară OpenShift. Îi este frică lui Red Hat să îmbunătățească Kubernetes? Sigur că nu, deoarece Red Hat respectă strict principiile codului deschis și nu joacă jocuri Open Core. Îmbunătățirile și inovațiile realizate la nivelul comunităților de dezvoltare devin mai viabile și au o distribuție mai largă, ceea ce se aliniază perfect cu scopul nostru principal - de a face software-ul cu cod deschis mai util pentru clienții noștri.
- Politicile de securitate pentru poduri (Pod Security Policies). Inițial, această conceptie de execuție sigură a aplicațiilor în interiorul podurilor a fost implementată în OpenShift sub numele de SCC (Security Context Constraints). Și, ca în exemplul anterior, Red Hat a decis să integreze aceste contribuții în cadrul proiectului deschis Kubernetes, pentru ca toți doritorii să le poată folosi.
Această serie de exemple poate continua, dar am dorit doar să arătăm că Red Hat se străduiește cu adevărat să dezvolte Kubernetes și să-l facă mai bun pentru toți.
Desigur, OpenShift este Kubernetes. Dar care sunt diferențele? 🙂
Sperăm că, citind până aici, ați înțeles că Kubernetes este componenta principală a OpenShift. Principală, dar departe de a fi singura. Cu alte cuvinte, instalând doar Kubernetes, nu veți obține o platformă de clasă enterprise. Va trebui să adăugați autentificare, rețea, securitate, monitorizare, gestionarea jurnalelor și multe altele. De asemenea, va trebui să faceți o alegere dificilă dintr-o gamă largă de instrumente disponibile (pentru a evalua diversitatea ecosistemului, aruncați o privire pe ) și într-un fel să asigurați coerența și armonia, astfel încât să funcționeze ca un întreg. În plus, va trebui să efectuați actualizări regulate și teste de regresie la fiecare nouă versiune a oricărui component utilizat. Asta înseamnă că, 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.
În cazul OpenShift, compania Red Hat își asumă toate aceste complexități și vă oferă pur și simplu o platformă funcțional completă, care include nu doar Kubernetes, ci și întreaga suită de instrumente open-source necesare, care transformă Kubernetes într-o soluție reală de clasă enterprise, pe care o puteți lansa imediat și fără emoții în producție. Și, desigur, dacă aveți propriile stive tehnologice, puteți integra OpenShift în soluțiile existente.
Uitați-vă la imaginea de mai sus: tot ceea ce se află în afara dreptunghiului Kubernetes reprezintă acele domenii în care Red Hat adaugă funcționalități care nu sunt disponibile în Kubernetes, așa cum se spune, by-design. Acum vom examina principalele dintre aceste domenii.
1. Un sistem de operare de încredere ca bază: RHEL CoreOS sau RHEL
Red Hat este deja de peste 20 de ani un lider în furnizarea de distribuții Linux pentru aplicații critice de afaceri. Experiența acumulată și actualizată constant în acest domeniu ne permite să oferim o bază cu adevărat fiabilă și de încredere pentru utilizarea industrială a containerelor. RHEL CoreOS folosește același nucleu ca RHEL, dar este optimizat în primul rând pentru sarcini precum rularea containerelor și funcționarea în clustere Kubernetes: dimensiunea sa redusă și imutabilitatea simplifică instalarea clusterelor, scalarea automată, implementarea de patch-uri etc. Toate aceste caracteristici o fac o bază ideală pentru a oferi aceeași experiență utilizatorului când se lucrează cu OpenShift în cele mai variate medii de calcul, de la „hard disk gol” la cloud privat și public.
2. Automatizarea operațiunilor IT
Automatizarea proceselor de instalare și a operațiunilor de zi cu zi (adică operarea cotidiană) este specialitatea OpenShift, facilitând semnificativ administrarea, actualizarea și menținerea platformei de containere la cele mai înalte standarde. Acest lucru se realizează prin suportul operatorilor Kubernetes la nivelul kernel-ului OpenShift 4.
OpenShift 4 este de asemenea o întreagă ecosistem de soluții bazate pe operatori Kubernetes, dezvoltate atât de Red Hat, cât și de parteneri terți (vezi Red Hat, sau magazinul operatorilor , creat de Red Hat pentru dezvoltatorii terți).
Catalogul integrat OpenShift 4 cuprinde peste 180 de operatori Kubernetes
3. Instrumente pentru dezvoltatori
Începând din 2011, OpenShift este disponibilă ca platformă PaaS (Platform-as-a-Service), care simplifică considerabil viața dezvoltatorilor, ajutându-i să se concentreze pe scrierea codului și oferind suport încorporat 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. OpenShift 4 oferă , 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 dispune de o interfață grafică specială (), ajutând dezvoltatorii să desfășoare fără efort aplicații din diverse surse (git, registre externe, Dockerfile etc.) în spațiile lor de nume și să vizualizeze clar relațiile dintre componentele aplicației.
În plus, OpenShift oferă un set de unelte de dezvoltare Codeready, care include, printre altele, , o IDE complet containerizată cu interfață web, care funcționează direct pe OpenShift și realizează abordarea „IDE ca serviciu”. Pe de altă parte, pentru cei care doresc să lucreze strict în mod local, există Codeready Containers – o versiune complet funcțională a OpenShift 4, care poate fi desfășurată pe laptop.
„IDE ca serviciu” integrată pentru dezvoltare eficientă pe platforma Kubernetes/OpenShift.
Direct din cutie, OpenShift oferă un sistem CI/CD complet, fie pe baza unui Jenkins containerizat și a pluginului pentru lucrul cu pipeline-uri, fie o soluție CI/CD orientată pe Kubernetes. (în prezent în versiune Tech preview). Ambele soluții sunt complet integrate cu consola OpenShift, permițând lansarea declanșatoarelor de pipeline-uri, vizionarea desfășurărilor, jurnalelor etc.
4. Unelte pentru aplicații
OpenShift permite desfășurarea atât a aplicațiilor tradiționale stateful, cât și a soluțiilor cloud-oriented pe baza unor arhitecturi noi, cum ar fi microserviciile sau serverless. Soluția OpenShift Service Mesh include direct din cutie instrumentele esențiale pentru gestionarea microserviciilor, cum ar fi Istio, Kiali și Jaeger. În schimb, soluția OpenShift Serverless include nu doar Knative, ci și instrumentele create în cadrul inițiativei comune cu Microsoft, cum ar fi Keda, pentru a oferi funcții Azure pe platforma OpenShift.
Soluția integrată OpenShift ServiceMesh (Istio, Kiali, Jaeger) va fi utilă în dezvoltarea microserviciilor.
Pentru a reduce decalajul dintre aplicațiile moștenite și containere, OpenShift permite acum migrarea mașinilor virtuale pe platforma OpenShift folosind Container Native Virtualization (în prezent în versiune Tech Preview), transformând aplicațiile hibride în realitate și facilitând transportul lor între diferite cloud-uri, atât private, cât și publice.
Mașina virtuală Windows 2019 Virtual, rulată pe OpenShift prin Container Native Virtualization (în prezent în versiune Tech preview).
5. Unelte pentru clustere
Orice platformă de clasă enterprise ar trebui să aibă servicii de monitorizare și înregistrare centralizată, mecanisme de securitate, autentificare și autorizare, precum și instrumente de gestionare a rețelelor. OpenShift oferă toate acestea „din cutie”, și toate acestea sunt 100% cod sursă deschis, incluzând soluții precum ElasticSearch, Prometheus, Grafana. Toate aceste soluții vin la pachet cu panouri informative, metrici și notificări, deja compilate și configurate ținând cont de vasta experiență a Red Hat în monitorizarea clusterelor, ceea ce permite controlul și urmărirea eficientă a funcționării mediului de producție încă din primele minute.
OpenShift include de asemenea lucruri esențiale pentru clienții corporate, cum ar fi autentificarea cu un furnizor oauth integrat, integrarea cu furnizorii de acreditive, inclusiv LDAP, ActiveDirectory, OpenID Connect și multe altele.
Panou informativ Grafana preconfigurat pentru monitorizarea clusterului OpenShift
Peste 150 de metrici și notificări preconfigurate Prometheus pentru monitorizarea clusterului OpenShift
Continuarea urmează
Funcționalitatea bogată a soluției și vasta experiență a Red Hat în Kubernetes – aceste motive au făcut ca OpenShift să ocupe o poziție dominantă pe piață, așa cum este ilustrat în figura de mai jos (mai multe detalii ).
„În prezent, Red Hat are o cotă de 44% pe piață.
Compania culege roadele strategiei sale de vânzări, cu un angajament activ în afacerile clientului, prin intermediul căreia se consultă și instruiesc dezvoltatorii corporate, pentru a trece apoi la monetizare pe măsură ce întreprinderea începe să implementeze containere în producție”.
(Sursă: )
Sperăm că v-a plăcut acest articol. În postările următoare din această serie, vom explora mai în detaliu avantajele OpenShift în comparație cu Kubernetes în fiecare dintre categoriile discutate aici.
Sursa: habr.com
