"Qual è la differenza tra Kubernetes e OpenShift?" – questa domanda si pone con invidiabile coerenza. Anche se in realtà è come chiedersi in cosa differisce un'auto da un motore. Se continuiamo l'analogia, allora un'auto è un prodotto finito, puoi usarla subito, letteralmente: sali e vai. D'altra parte, affinché un motore possa portarti da qualche parte, deve prima essere integrato con molte altre cose per ottenere alla fine la stessa macchina.
Pertanto, Kubernetes è il motore attorno al quale è assemblata l'auto (piattaforma) del marchio OpenShift, che ti porta al tuo obiettivo.
In questo articolo vogliamo ricordarvi ed esaminare un po’ più nel dettaglio i seguenti punti chiave:
- Kubernetes è il cuore della piattaforma OpenShift ed è certificato Kubernetes al 100%, completamente open source e senza la minima natura proprietaria. Brevemente:
- L'API del cluster OpenShift è al XNUMX% Kubernetes.
- Se il contenitore viene eseguito su qualsiasi altro sistema Kubernetes, verrà eseguito su OpenShift senza alcuna modifica. Non è necessario apportare modifiche alle applicazioni.
- OpenShift non solo aggiunge caratteristiche e funzionalità utili a Kubernetes. Come un'auto, OpenShift è pronto all'uso, può essere messo immediatamente in produzione e, come mostreremo di seguito, rende la vita di uno sviluppatore molto più semplice. Ecco perché OpenShift è unito in due persone. È una piattaforma PaaS di classe enterprise di successo e ben nota dal punto di vista dello sviluppatore. E allo stesso tempo è una soluzione Container-as-a-Service estremamente affidabile dal punto di vista del funzionamento industriale.
OpenShift è Kubernetes con certificazione CNCF al 100%.
OpenShift è basato su . Pertanto, dopo un'adeguata formazione, gli utenti rimangono stupiti dalla potenza di kubectl. E coloro che sono passati a OpenShift da Kubernetes Cluster spesso dicono di apprezzare davvero il fatto che, dopo aver reindirizzato kubeconfig al cluster OpenShift, tutti gli script esistenti funzionino perfettamente.
Probabilmente hai sentito parlare dell'utilità della riga di comando di OpenShift chiamata OC. È completamente compatibile con i comandi con kubectl e offre inoltre diversi utili aiutanti che torneranno utili durante l'esecuzione di una serie di attività. Ma prima, qualcosa in più sulla compatibilità di OC e kubectl:
comandi kubectl
Squadre OC
kubectl ottieni pod
oc prendi i pod
kubectl ottiene gli spazi dei nomi
oc ottieni gli spazi dei nomi
kubectl create -f deploy.yaml
oc create -f deploy.yaml
Ecco come appaiono i risultati dell'utilizzo di kubectl sull'API OpenShift:
• kubectl get pod – restituisce i pod come previsto.
• kubectl get namespaces – restituisce gli spazi dei nomi come previsto.
Il comando kubectl create -f mydeployment.yaml crea risorse Kubernetes proprio come su qualsiasi altra piattaforma Kubernetes, come mostrato nel video qui sotto:
In altre parole, tutte le API Kubernetes sono completamente disponibili in OpenShift pur mantenendo la compatibilità al 100%. È per questo .
OpenShift aggiunge funzionalità utili a Kubernetes
Le API Kubernetes sono disponibili al 100% in OpenShift, ma l'utilità Kubernetes standard kubectl manca chiaramente di funzionalità e praticità. Ecco perché Red Hat ha aggiunto a Kubernetes funzionalità utili e strumenti da riga di comando, come OC (abbreviazione di OpenShift client) e ODO (OpenShift DO, questa utility è rivolta agli sviluppatori).
1. Utilità OC: una versione più potente e conveniente di Kubectl
Ad esempio, a differenza di kubectl, consente di creare nuovi spazi dei nomi e cambiare facilmente contesto e offre anche una serie di comandi utili per gli sviluppatori, come la creazione di immagini di contenitori e la distribuzione di applicazioni direttamente dal codice sorgente o dai binari (Source-to-image, s2i).
Diamo un'occhiata ad esempi di come gli aiutanti integrati e le funzionalità avanzate dell'utilità OC aiutano a semplificare il lavoro quotidiano.
Il primo esempio è la gestione dello spazio dei nomi. Ogni cluster Kubernetes ha sempre più spazi dei nomi. Solitamente vengono utilizzati per creare ambienti di sviluppo e produzione, ma possono anche essere utilizzati, ad esempio, per fornire a ogni sviluppatore un sandbox personale. In pratica, ciò fa sì che lo sviluppatore debba passare spesso da uno spazio dei nomi all'altro, poiché kubectl viene eseguito nel contesto dello spazio corrente. Pertanto nel caso di kubectl le persone utilizzano attivamente gli script di supporto. Ma quando usi OC, per passare allo spazio desiderato, basta dire "oc project namespace".
Non ricordi come si chiama lo spazio dei nomi che ti serve? Nessun problema, basta digitare "oc get project" per visualizzare l'elenco completo. Scettico ti chiedi come funzionerà se hai accesso solo a un sottoinsieme limitato di spazi dei nomi sul cluster? Bene, perché kubectl lo fa correttamente solo se RBAC ti consente di vedere tutti gli spazi sul cluster e nei cluster di grandi dimensioni non a tutti vengono concesse tali autorizzazioni. Quindi rispondiamo: per l'OC questo non è affatto un problema e in una situazione del genere produrrà facilmente un elenco completo. Sono queste piccole cose che costituiscono l’orientamento aziendale di Openshift e la buona scalabilità di questa piattaforma in termini di utenti e applicazioni
2. ODO: una versione migliorata di kubectl per gli sviluppatori
Un altro esempio dei miglioramenti apportati da Red Hat OpenShift rispetto a Kubernetes è l'utilità della riga di comando ODO. È progettato per gli sviluppatori e consente di distribuire rapidamente il codice locale su un cluster OpenShift remoto. Può anche semplificare i processi interni per sincronizzare istantaneamente tutte le modifiche al codice nei contenitori su un cluster OpenShift remoto senza dover ricostruire, registrare e ridistribuire le immagini.
Diamo un'occhiata a come OC e ODO semplificano il lavoro con container e Kubernetes.
Basta confrontare un paio di flussi di lavoro quando sono costruiti sulla base di kubectl e quando vengono utilizzati OC o ODO.
• Distribuzione del codice su OpenShift per coloro che non parlano YAML:
Kubernetes/kubectl
$>git clone
1- Crea un Dockerfile che costruisce l'immagine dal codice
-----
DA nodo
WORKDIR /usr/src/app
COPIA pacchetto*.json ./
COPIA indice.js ./
COPIA ./app ./app
ESEGUIRE l'installazione di npm
ESPOSI 3000
CMD [“npm”, “inizio”] ————–
2- Costruiamo l'immagine
$>produzione Podman...
3- Accedi al registro
accesso podman...
4- Posiziona l'immagine nel registro
spinta del podman
5- Crea file yaml per la distribuzione dell'applicazione (deployment.yaml, service.yaml, ingress.yaml): questo è il minimo assoluto
6- Distribuisci i file manifest:
Kubectl applica -f .
OpenShift/oc
$> oc nuova-app – nome_nostra_applicazione
OpenShift/odo
$>git clone
$> odo crea il componente nodejs myapp
$>odo spingere
• Cambio di contesto: modifica lo spazio dei nomi del lavoro o il cluster di lavoro.
Kubernetes/kubectl
1- Crea un contesto in kubeconfig per il progetto “myproject”
2- contesto impostato kubectl…
OpenShift/oc
progetto oc “mioprogetto”
Controllo qualità: “Qui è apparsa una funzionalità interessante, ancora in versione alpha. Forse possiamo metterlo in produzione?"
Immaginate di essere seduti su un'auto da corsa e di sentirvi dire: “Abbiamo installato un nuovo tipo di freni e, a dire il vero, la loro affidabilità non è ancora a posto... Ma non preoccupatevi, li miglioreremo attivamente durante il corso del campionato”. Ti piace questa prospettiva? Noi di Red Hat per qualche motivo non siamo molto contenti. 🙂
Pertanto, cerchiamo di tenere a bada le versioni alfa finché non saranno sufficientemente mature e non avremo effettuato test di battaglia approfonditi e riteniamo che siano sicure da usare. Di solito, tutto passa prima attraverso la fase di anteprima dello sviluppatore, quindi e solo allora esce come versione pubblica (GA), che è già così stabile da essere adatto alla produzione.
Perché? Perché, come per lo sviluppo di qualsiasi altro software, non tutte le idee iniziali in Kubernetes raggiungono la versione finale. Oppure lo raggiungono e mantengono anche la funzionalità prevista, ma la loro implementazione è radicalmente diversa da quella della versione alpha. Con migliaia e migliaia di clienti Red Hat che utilizzano OpenShift per supportare carichi di lavoro mission-critical, poniamo particolare enfasi sulla stabilità della nostra piattaforma e sul supporto a lungo termine.
Red Hat si impegna a rilasciare frequentemente OpenShift e ad aggiornare la versione inclusa di Kubernetes. Ad esempio, l'attuale versione GA di OpenShift 4.3 al momento in cui scriviamo include Kubernetes 1.16, che è solo uno dietro la versione upstream di Kubernetes numerata 1.17. Pertanto, stiamo cercando di fornire al cliente Kubernetes di livello aziendale e di fornire un ulteriore controllo di qualità man mano che rilasciamo nuove versioni di OpenShift.
Correzioni software: “C'era un buco nella versione di Kubernetes che abbiamo in produzione. E puoi chiuderlo solo aggiornando tre versioni in su. Oppure ci sono delle opzioni?
Nel progetto open source Kubernetes, le correzioni software vengono solitamente rilasciate come parte del rilascio successivo, a volte coprendo uno o due rilasci fondamentali precedenti, fornendo copertura fino a 6 mesi.
Red Hat è orgogliosa di rilasciare soluzioni critiche prima degli altri e di fornire supporto per molto più tempo. Prendiamo ad esempio la vulnerabilità relativa all'escalation dei privilegi di Kubernetes (): è stato scoperto in Kubernetes 1.11 e le correzioni per le versioni precedenti sono state rilasciate solo fino alla versione 1.10.11, lasciando questa nel buco in tutte le versioni precedenti di Kubernetes, da 1.x a 1.9.
A sua volta, (Kubernetes 1.2 è presente), catturando nove versioni di OpenShift e dimostrando chiaramente l'attenzione per i clienti (maggiori dettagli ).
Come OpenShift e Red Hat stanno facendo avanzare Kubernetes
Red Hat è il secondo maggior contributore di software al progetto open source Kubernetes, dietro solo a Google, con 3 dei 5 sviluppatori più prolifici provenienti da Red Hat. Altro fatto poco noto: molte funzioni critiche sono apparse in Kubernetes proprio su iniziativa di Red Hat, in particolare, come:
- RBAC. Kubernetes non disponeva di funzioni RBAC (ClusterRole, ClusterRoleBinding) finché gli ingegneri di Red Hat non decisero di implementarle come parte della piattaforma stessa e non come funzionalità OpenShift aggiuntiva. Red Hat ha paura di migliorare Kubernetes? Ovviamente no, perché Red Hat segue rigorosamente i principi open source e non utilizza giochi Open Core. I miglioramenti e le innovazioni guidati dalle comunità di sviluppo, piuttosto che da quelle proprietarie, sono più fattibili e più ampiamente adottati, il che si allinea bene con il nostro obiettivo principale di rendere il software open source più utile per i nostri clienti.
- Politiche di sicurezza per i pod (Politiche di sicurezza dei pod). Questo concetto di esecuzione sicura delle applicazioni all'interno dei pod è stato originariamente implementato in OpenShift con il nome SCC (Security Context Constraints). E come nell’esempio precedente, Red Hat ha deciso di introdurre questi sviluppi nel progetto aperto Kubernetes in modo che tutti potessero utilizzarli.
Questa serie di esempi potrebbe continuare, ma volevamo solo dimostrare che Red Hat è davvero impegnata nello sviluppo di Kubernetes e nel renderlo migliore per tutti.
È chiaro che OpenShift è Kubernetes. Quali sono le differenze? 🙂
Ci auguriamo che leggendo fin qui tu abbia capito che Kubernetes è il componente principale di OpenShift. Il principale, ma non l’unico. In altre parole, la semplice installazione di Kubernetes non ti darà una piattaforma di classe enterprise. Dovrai aggiungere autenticazione, rete, sicurezza, monitoraggio, gestione dei registri e altro ancora. Inoltre, dovrai fare alcune scelte difficili tra il gran numero di strumenti disponibili (per apprezzare la diversità dell'ecosistema, basta dare un'occhiata ) e garantire in qualche modo consistenza e coerenza in modo che funzionino come un tutt'uno. Inoltre, dovrai eseguire regolarmente aggiornamenti e test di regressione ogni volta che viene rilasciata una nuova versione di uno qualsiasi dei componenti che utilizzi. Cioè, oltre a creare e mantenere la piattaforma stessa, dovrai occuparti anche di tutto questo software. È improbabile che rimanga molto tempo per risolvere i problemi aziendali e ottenere vantaggi competitivi.
Ma nel caso di OpenShift, Red Hat si fa carico di tutte queste complessità e offre semplicemente una piattaforma funzionalmente completa, che include non solo Kubernetes stesso, ma anche l'intero set di strumenti open source necessari che trasformano Kubernetes in un vero e proprio servizio di classe enterprise. soluzione che puoi lanciare immediatamente e con tutta calma in produzione. E, naturalmente, se disponi di alcuni dei tuoi stack tecnologici, puoi integrare OpenShift nelle soluzioni esistenti.
Dai un'occhiata all'immagine sopra: tutto ciò che è al di fuori del rettangolo di Kubernetes è il luogo in cui Red Hat aggiunge funzionalità che Kubernetes non ha, come si suol dire, by-design. E ora esamineremo le principali di queste aree.
1. Sistema operativo robusto come base: RHEL CoreOS o RHEL
Red Hat è da oltre 20 anni un fornitore leader di distribuzioni Linux per applicazioni business-critical. La nostra esperienza accumulata e costantemente aggiornata in questo settore ci consente di offrire una base veramente affidabile e affidabile per il funzionamento industriale dei contenitori. RHEL CoreOS utilizza lo stesso kernel di RHEL, ma è ottimizzato principalmente per attività come l'esecuzione di contenitori e l'esecuzione di cluster Kubernetes: le sue dimensioni ridotte e l'immutabilità semplificano la configurazione di cluster, la scalabilità automatica, la distribuzione di patch, ecc. Tutte queste funzionalità lo rendono una base ideale per offrire la stessa esperienza utente con OpenShift in un'ampia gamma di ambienti informatici, dal bare metal al cloud privato e pubblico.
2. Automazione delle operazioni IT
L'automazione dei processi di installazione e delle operazioni day-4 (ovvero, le operazioni quotidiane) è il punto di forza di OpenShift, rendendo molto più semplice amministrare, aggiornare e mantenere le prestazioni della piattaforma container al massimo livello. Ciò si ottiene attraverso il supporto per gli operatori Kubernetes a livello del kernel OpenShift XNUMX.
OpenShift 4 è anche un intero ecosistema di soluzioni basate su operatori Kubernetes, sviluppate sia dalla stessa Red Hat che da partner terzi (vedi. Red Hat, o negozio dell'operatore , creato da Red Hat per sviluppatori di terze parti).
Il catalogo integrato OpenShift 4 comprende più di 180 operatori Kubernetes
3. Strumenti per sviluppatori
Dal 2011, OpenShift è disponibile come piattaforma PaaS (Platform-as-a-Service) che semplifica la vita agli sviluppatori, li aiuta a concentrarsi sulla codifica e offre supporto nativo per linguaggi di programmazione come Java, Node.js , PHP, Ruby, Python, Go, nonché servizi di integrazione e distribuzione continua CI/CD, database, ecc. OpenShift 4 offre , che include più di 100 servizi basati sugli operatori Kubernetes sviluppati da Red Hat e dai nostri partner.
A differenza di Kubernetes, OpenShift 4 ha una GUI dedicata (), che aiuta gli sviluppatori a distribuire facilmente applicazioni da varie fonti (git, registri esterni, Dockerfile, ecc.) nei loro spazi dei nomi e visualizza chiaramente le relazioni tra i componenti dell'applicazione.
Inoltre, OpenShift offre una serie di strumenti di sviluppo Codeready, che, in particolare, include , un IDE completamente containerizzato con un'interfaccia web che viene eseguito direttamente su OpenShift e implementa un approccio IDE-as-a-service. Per chi, invece, vuole lavorare rigorosamente in modalità locale, c'è Codeready Containers, una versione completamente funzionante di OpenShift 4 che può essere implementata su un laptop.
IDE integrato come servizio per uno sviluppo efficiente sulla piattaforma Kubernetes/OpenShift
OpenShift offre un sistema CI/CD completo pronto all'uso, basato su Jenkins containerizzato e su un plug-in per lavorare con pipeline o un sistema CI/CD orientato a Kubernetes (attualmente nella versione Tech Preview). Entrambe queste soluzioni si integrano completamente con la console OpenShift, consentendoti di eseguire trigger di pipeline, visualizzare distribuzioni, registri e altro ancora.
4. Strumenti applicativi
OpenShift consente di implementare sia applicazioni stateful tradizionali che soluzioni basate su cloud basate su nuove architetture, come microservizi o serverless. La soluzione OpenShift Service Mesh è pronta all'uso con strumenti chiave per la manutenzione dei microservizi, come Istio, Kiali e Jaeger. A sua volta, la soluzione OpenShift Serverless include non solo Knative, ma anche strumenti come Keda creati nell'ambito di un'iniziativa congiunta con Microsoft per fornire funzionalità Azure sulla piattaforma OpenShift.
La soluzione integrata OpenShift ServiceMesh (Istio, Kiali, Jaeger) sarà utile nello sviluppo di microservizi
Per colmare il divario tra applicazioni legacy e contenitori, OpenShift ora consente la migrazione delle macchine virtuali sulla piattaforma OpenShift utilizzando Container Native Virtualization (attualmente in TechPreview), rendendo le applicazioni ibride una realtà e facilitando la loro migrazione tra diversi cloud, sia privati che pubblici.
Macchina virtuale virtuale Windows 2019 in esecuzione su OpenShift tramite virtualizzazione nativa del contenitore (attualmente nella versione di anteprima tecnica)
5. Strumenti per i cluster
Qualsiasi piattaforma di livello aziendale deve disporre di servizi di monitoraggio e registrazione centralizzati, meccanismi di sicurezza, autenticazione e autorizzazione e strumenti di gestione della rete. E OpenShift fornisce tutto questo fuori dagli schemi, ed è tutto open source al 100%, comprese soluzioni come ElasticSearch, Prometheus, Grafana. Tutte queste soluzioni sono dotate di dashboard, parametri e avvisi già creati e configurati utilizzando l'ampia esperienza di Red Hat nel monitoraggio dei cluster, consentendoti di controllare e monitorare in modo efficace il tuo ambiente di produzione fin dall'inizio.
OpenShift viene inoltre fornito di serie con aspetti importanti per i clienti aziendali come l'autenticazione con un provider OAuth integrato, l'integrazione con provider di credenziali, tra cui LDAP, ActiveDirectory, OpenID Connect e molto altro.
Dashboard Grafana preconfigurata per il monitoraggio del cluster OpenShift
Oltre 150 metriche e avvisi Prometheus preconfigurati per il monitoraggio dei cluster OpenShift
essere continuato
La ricca funzionalità della soluzione e la vasta esperienza di Red Hat nel campo di Kubernetes sono le ragioni per cui OpenShift ha raggiunto una posizione dominante nel mercato, come mostrato nella figura seguente (leggi di più ).
“Red Hat attualmente guida il mercato con una quota del 44%.
L’azienda sta raccogliendo i frutti della sua strategia di vendita incentrata sul cliente, in cui prima consulta e forma gli sviluppatori aziendali e poi passa alla monetizzazione non appena l’azienda inizia a distribuire i contenitori in produzione”.
(Fonte: )
Ci auguriamo che questo articolo ti sia piaciuto. Nei post futuri di questa serie, daremo uno sguardo più da vicino ai vantaggi di OpenShift rispetto a Kubernetes in ciascuna delle categorie discusse qui.
Fonte: habr.com