«Qual è la differenza tra Kubernetes e OpenShift?» – questa domanda sorge con una sorprendente regolarità. In realtà è come chiedere qual è la differenza tra un'auto e un motore. Se seguiamo l'analogia, l'auto è un prodotto finito, utilizzabile immediatamente: sali e parti. D'altra parte, affinché un motore ti porti da qualche parte, deve essere completato con una serie di altri elementi, per ottenere infine l'auto.
Quindi, Kubernetes è quel motore attorno al quale è costruita l'auto (piattaforma) OpenShift, che ti conduce verso la tua meta.
In questo articolo vogliamo ricordare e analizzare un po' più nel dettaglio i seguenti punti chiave:
- Kubernetes è il cuore della piattaforma OpenShift ed è un Kubernetes certificato al 100%, con codice completamente aperto e senza alcuna proprietà. In breve:
- L'API per il cluster OpenShift è un Kubernetes al 100%.
- Se un container funziona in un qualsiasi altro sistema Kubernetes, funzionerà senza modifiche anche su OpenShift. Non è necessario apportare modifiche alle applicazioni.
- OpenShift non solo integra funzionalità e opportunità utili in Kubernetes. Proprio come un'automobile, OpenShift è immediatamente pronto all'uso, può essere messo in produzione subito e, come dimostreremo in seguito, semplifica notevolmente la vita degli sviluppatori. Per questo motivo, OpenShift ha una doppia identità. È una piattaforma PaaS di livello enterprise di successo e ampiamente riconosciuta, se osservata dall'ottica dello sviluppatore. Contemporaneamente, è una soluzione estremamente affidabile di tipo Container-as-a-Service dal punto di vista dell'operatività industriale.
OpenShift è Kubernetes con certificazione al 100% da parte della CNCF
Alla base di OpenShift c'è . Pertanto, dopo la formazione adeguata, gli utenti sono entusiasti della potenza di kubectl. E coloro che sono passati a OpenShift da un cluster Kubernetes spesso affermano di apprezzare molto il fatto che, una volta reindirizzato kubeconfig al cluster OpenShift, tutti gli script esistenti funzionano perfettamente.
Hai sicuramente sentito parlare dell'utilità da riga di comando di OpenShift chiamata OC. È completamente compatibile con i comandi di kubectl e offre anche alcuni utili helper che saranno utili per eseguire una serie di attività. Ma prima, lasciami approfondire un po' la compatibilità tra OC e kubectl:
Comandi kubectl
Comandi OC
kubectl get pods
oc get pods
kubectl get namespaces
oc get namespaces
kubectl create -f deployment.yaml
oc create -f deployment.yaml
Ecco come appaiono i risultati dell'uso di kubectl sull'API di OpenShift:
• kubectl get pods – restituisce, come ci si aspettava, i pod.
• kubectl get namespaces – restituisce, come ci si aspettava, gli spazi dei nomi.
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 di Kubernetes sono completamente disponibili in OpenShift con il 100% di compatibilità. È proprio per questo che .
OpenShift arricchisce Kubernetes con funzionalità utili.
Le API di Kubernetes sono disponibili al 100% in OpenShift, ma l'utilità standard kubectl di Kubernetes manca chiaramente di funzionalità e comodità. Pertanto, Red Hat ha arricchito Kubernetes con funzioni utili e strumenti da riga di comando, come OC (abbreviazione di OpenShift client) e ODO (OpenShift DO, progettata per gli sviluppatori).
1. L'utilità OC è un'alternativa più potente e comoda a Kubectl.
Ad esempio, a differenza di kubectl, consente di creare nuovi spazi dei nomi e passare facilmente da un contesto all'altro, oltre a offrire una serie di comandi utili per gli sviluppatori, come la creazione di immagini di contenitori e il deploy delle applicazioni direttamente dal codice sorgente o dai file binari (Source-to-image, s2i).
Analizziamo, attraverso degli esempi, come gli helper incorporati e le funzionalità avanzate dell'utilità OC semplificano il lavoro quotidiano.
Esempio uno – gestione degli spazi dei nomi. In ogni cluster Kubernetes ci sono sempre diversi spazi dei nomi. Di solito, questi vengono utilizzati per creare ambienti di sviluppo e di produzione, ma possono anche essere utilizzati, ad esempio, per fornire a ciascun sviluppatore una "sandbox" personale. Nella pratica, ciò porta gli sviluppatori a dover spesso passare da uno spazio dei nomi all'altro, poiché kubectl opera nel contesto dello spazio attuale. Pertanto, con kubectl, le persone utilizzano attivamente script di supporto per questo scopo. D'altra parte, utilizzando OC, per passare allo spazio necessario basta digitare "oc project spazio_nome".
Non ricordi come si chiama lo spazio dei nomi necessario? Nessun problema, basta digitare “oc get projects” per visualizzare l'elenco completo. Ti chiedi scetticamente come funzioni se hai accesso solo a un sottoinsieme limitato di spazi dei nomi nel cluster? Ebbene, perché kubectl funziona correttamente solo se RBAC ti consente di vedere tutti gli spazi nel cluster, e in grandi cluster tali privilegi non sono concessi a tutti. Quindi, rispondiamo: per OC non è affatto un problema e fornirà facilmente un elenco completo in tale situazione. È da queste piccole cose che si compone l'orientamento aziendale di Openshift e la sua buona scalabilità in termini di utenti e applicazioni.
2. ODO – una versione migliorata di kubectl per sviluppatori
Un altro esempio dei miglioramenti di Red Hat OpenShift rispetto a Kubernetes è l'utilità della riga di comando ODO. Questa è progettata per gli sviluppatori e consente di distribuire rapidamente il codice locale su un cluster OpenShift remoto. Inoltre, permette di ottimizzare i processi interni per sincronizzare istantaneamente tutte le modifiche al codice con i contenitori sul cluster OpenShift remoto senza dover ricostruire, pubblicare nel registro e ridistribuire le immagini.
Esploriamo come OC e ODO semplificano il lavoro con i contenitori e Kubernetes.
Confrontiamo semplicemente un paio di flussi di lavoro, quando si basano su kubectl e quando vengono utilizzati OC o ODO.
• Distribuzione del codice su OpenShift per chi non conosce il linguaggio YAML:
Kubernetes / kubectl
$> git clone
1- Creiamo un Dockerfile che costruisce l'immagine dal codice
————–
FROM node
WORKDIR /usr/src/app
COPY package*.json ./
COPY index.js ./
COPY ./app ./app
RUN npm install
EXPOSE 3000
CMD [ "npm", "start" ]
————–
2- Eseguiamo la costruzione dell'immagine
$> podman build …
3- Accediamo al registro
podman login …
4- Pubblicare l'immagine nel registro
podman push
5- Creiamo i file yaml per il deployment dell'applicazione (deployment.yaml, service.yaml, ingress.yaml) – questo è il minimo indispensabile
6- Deployiamo i file manifest:
Kubectl apply -f .
OpenShift / oc
$> oc new-app – nome_della_nostra_applicazione
OpenShift / odo
$> git clone
$> odo create component nodejs myapp
$> odo push
• Cambiamento di contesto: cambio di namespace o cluster di lavoro.
Kubernetes / kubectl
1- Creiamo un contesto in kubeconfig per il progetto "myproject"
2- kubectl set-context …
OpenShift / oc
oc project "myproject"
Controllo qualità: "C'è una funzione interessante qui, attualmente in versione alpha. La introdurremo in produzione?"
Immaginate di essere seduti in una macchina da corsa e vi dicono: "Abbiamo installato freni di nuova generazione e, a dire il vero, non sono ancora del tutto affidabili... Ma non preoccupatevi, li miglioreremo attivamente durante il campionato." Come vi sembra questa prospettiva? A noi di Red Hat non ci piace molto. 🙂
Pertanto, tendiamo a evitare le versioni alpha finché non sono sufficientemente mature e non abbiamo effettuato test approfonditi sul campo e ci sentiamo sicuri di poterle utilizzare. Di solito tutto passa prima attraverso la fase Dev Preview, poi attraverso e solo dopo viene rilasciato come versione pubblica (GA), che è già così stabile da essere adatto per l'uso in produzione.
Perché? Perché, come nello sviluppo di qualsiasi altro software, non tutte le idee iniziali in Kubernetes riescono a raggiungere il rilascio finale. O magari ci riescono, mantenendo anche la funzionalità prevista, ma la loro realizzazione è radicalmente diversa da quella della versione alfa. Poiché migliaia di clienti di Red Hat utilizzano OpenShift per gestire attività critiche, ci concentriamo particolarmente sulla stabilità della nostra piattaforma e sul supporto a lungo termine.
Red Hat rilascia regolarmente nuove versioni di OpenShift e aggiorna la versione di Kubernetes in essa inclusa. Ad esempio, nell'attuale release GA di OpenShift 4.3, integrata con Kubernetes 1.16, che è solo leggermente indietro rispetto alla versione upstream di Kubernetes, che è 1.17. In questo modo, cerchiamo di fornire ai clienti un Kubernetes di classe enterprise e garantire un controllo qualità aggiuntivo nel processo di rilascio delle nuove versioni di OpenShift.
Patch software: "In the version of Kubernetes that we have in production, a vulnerability was found. And it can only be fixed by upgrading to three versions up. Or are there options?"
Within the open project Kubernetes, software fixes usually come out as part of the next release; sometimes they cover one or two previous intermediate releases, which provides coverage for up to six months back.
Red Hat rightly prides itself on releasing critical fixes earlier than others and providing support for a much longer period. For example, take the privilege escalation vulnerability in Kubernetes (): it was discovered in Kubernetes 1.11, but fixes for previous releases were only released up to version 1.10.11, leaving this gap in all previous Kubernetes releases, from 1.x to 1.9.
In turn, (which runs Kubernetes 1.2), covering nine OpenShift releases and clearly demonstrating concern for its customers (more details ).
How OpenShift and Red Hat advance Kubernetes
Red Hat si posiziona al secondo posto per il contributo di sviluppo al progetto open source Kubernetes, superato solo da Google. Inoltre, 3 dei 5 sviluppatori più prolifici sono dipendenti di Red Hat. Un altro fatto poco noto è che molte funzionalità critiche sono emerse in Kubernetes grazie all'iniziativa di Red Hat, in particolare:
- RBAC. In Kubernetes non c'erano funzionalità RBAC (ClusterRole, ClusterRoleBinding) fino a quando gli ingegneri di Red Hat non hanno deciso di implementarle nella piattaforma stessa e non come funzionalità aggiuntiva di OpenShift. Red Hat ha paura di migliorare Kubernetes? Assolutamente no, perché Red Hat segue rigorosamente i principi del codice aperto, senza giocare con giochi Open Core. I miglioramenti e le innovazioni realizzati a livello delle comunità di sviluppo, e non con un approccio proprietario, diventano più sostenibili e raggiungono una diffusione più ampia, allineandosi perfettamente al nostro obiettivo principale: rendere il software open source più utile per i nostri clienti.
- Le politiche di sicurezza per i pod (Pod Security Policies). Inizialmente, questo concetto di esecuzione sicura delle applicazioni all'interno dei pod è stato implementato in OpenShift con il nome di SCC (Security Context Constraints). Come nel caso precedente, Red Hat ha deciso di integrare queste funzionalità nel progetto Open Source Kubernetes, affinché possano essere utilizzate da chiunque ne abbia bisogno.
Questa serie di esempi potrebbe continuare, ma volevamo solo dimostrare che Red Hat è realmente impegnata nello sviluppo di Kubernetes e nel migliorarlo per tutti.
È chiaro, OpenShift è Kubernetes. Ma quali sono le differenze? 🙂
Speriamo che, arrivati a questo punto, abbiate compreso che Kubernetes è il componente principale di OpenShift. Principale, ma non l'unico. In altre parole, semplicemente installando Kubernetes, non otterrete una piattaforma di livello enterprise. Dovrete aggiungere autenticazione, rete, sicurezza, monitoraggio, gestione dei log e molto altro. Inoltre, dovrete prendere una decisione non facile tra i numerosi strumenti disponibili (per valutare la varietà dell'ecosistema, date un'occhiata alla ) e in qualche modo garantire coerenza e sinergia affinché funzionino come un'unica entità. Inoltre, sarà necessario eseguire regolarmente aggiornamenti e test di regressione con l'uscita di una nuova versione di qualsiasi componente utilizzato. Quindi, oltre a creare e mantenere la piattaforma stessa, dovrai anche occuparti di tutto il software. È improbabile che rimanga molto tempo per affrontare questioni imprenditoriali e raggiungere vantaggi competitivi.
Nel caso di OpenShift, Red Hat gestisce tutte queste complessità e ti offre semplicemente una piattaforma funzionalmente completa, che include non solo Kubernetes, ma anche un set completo di strumenti open source che trasformano Kubernetes in una vera soluzione di livello enterprise, pronta per essere lanciata in produzione senza problemi. E naturalmente, se hai già stack tecnologici specifici, puoi integrare OpenShift nelle soluzioni esistenti.
Guarda l'immagine sopra: tutto ciò che si trova al di fuori del rettangolo Kubernetes sono le aree in cui Red Hat aggiunge funzionalità che non sono presenti in Kubernetes, definite per design. Ora esamineremo le principali di queste aree.
1. Un sistema operativo affidabile come base: RHEL CoreOS o RHEL
Red Hat è un fornitore leader di distribuzioni Linux per applicazioni aziendali critiche da oltre 20 anni. L'esperienza accumulata e continuamente aggiornata in questo settore ci consente di offrire una base veramente affidabile e fidata per l'implementazione industriale dei contenitori. RHEL CoreOS utilizza lo stesso kernel di RHEL, ma è ottimizzato principalmente per compiti come l'esecuzione di contenitori e il funzionamento in cluster Kubernetes: la sua dimensione ridotta e la sua immutabilità semplificano l'installazione di cluster, il ridimensionamento automatico, il deployment delle patch, ecc. Tutte queste funzionalità la rendono una base ideale per garantire la stessa esperienza utente utilizzando OpenShift in diversi ambienti di calcolo, dall'hardware nudo a cloud privati e pubblici.
2. Automazione delle operazioni IT
L'automazione dei processi di installazione e delle operazioni del secondo giorno (cioè dell'operatività quotidiana) è il punto di forza di OpenShift, che facilita notevolmente l'amministrazione, l'aggiornamento e il mantenimento delle prestazioni della piattaforma container a livelli estremamente elevati. Questo è reso possibile grazie al supporto degli operatori Kubernetes a livello di base in OpenShift 4.
OpenShift 4 è anche un'intera ecosistema di soluzioni basate su operatori Kubernetes, sviluppate sia da Red Hat che da partner esterni (vedi Red Hat, o il negozio degli operatori , creato da Red Hat per gli sviluppatori esterni).
Il catalogo integrato di OpenShift 4 include oltre 180 operatori Kubernetes
3. Strumenti per gli sviluppatori
Dal 2011, OpenShift è disponibile come piattaforma PaaS (Platform-as-a-Service), che semplifica notevolmente la vita degli sviluppatori, aiutandoli a concentrarsi sulla scrittura del codice e offrendo supporto integrato per linguaggi di programmazione come Java, Node.js, PHP, Ruby, Python, Go, oltre a servizi di integrazione e distribuzione continua CI/CD, database, ecc. OpenShift 4 offre , che include oltre 100 servizi basati su operatori Kubernetes sviluppati da Red Hat e dai nostri partner.
A differenza di Kubernetes, OpenShift 4 offre un'interfaccia grafica specifica (), che aiuta gli sviluppatori a distribuire senza sforzi applicazioni dai vari fonti (git, registri esterni, Dockerfile, ecc.) nei loro spazi dei nomi e visualizza chiaramente le relazioni tra i componenti dell'applicazione.
Inoltre, OpenShift offre un set di strumenti di sviluppo Codeready, che include , un IDE completamente containerizzato con interfaccia web, che funziona direttamente sopra OpenShift e implementa l'approccio "IDE come servizio". D'altra parte, per chi desidera lavorare esclusivamente in modalità locale, ci sono i Codeready Containers: una versione completamente funzionale di OpenShift 4, che può essere distribuita su un laptop.
Un'"IDE come servizio" integrata per uno sviluppo efficace sulla piattaforma Kubernetes/OpenShift.
OpenShift offre una sistema CI/CD completo direttamente fuori dalla scatola, sia basato su Jenkins containerizzato e il plugin per lavorare con i pipeline o un sistema CI/CD orientato a Kubernetes (attualmente in versione Tech preview). Entrambe queste soluzioni si integrano completamente con la console di OpenShift, consentendo di avviare i trigger dei pipeline, visualizzare i deployment, i log, ecc.
4. Strumenti per le applicazioni
OpenShift consente di implementare sia applicazioni tradizionali stateful che soluzioni cloud-oriented basate su nuove architetture come microservizi o serverless. La soluzione OpenShift Service Mesh include nativamente strumenti chiave per la gestione dei microservizi, come Istio, Kiali e Jaeger. A sua volta, la soluzione OpenShift Serverless comprende non solo Knative, ma anche strumenti sviluppati nell'ambito di un'iniziativa congiunta con Microsoft, come Keda, 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 le applicazioni ereditate e i container, OpenShift consente ora la migrazione delle macchine virtuali sulla piattaforma OpenShift tramite Container Native Virtualization (attualmente in versione Tech Preview), trasformando le applicazioni ibride in realtà e facilitando il loro spostamento tra vari cloud, sia privati che pubblici.
Macchina virtuale Windows 2019 Virtual, in esecuzione su OpenShift tramite Container Native Virtualization (attualmente in versione Tech preview)
5. Strumenti per i cluster
Qualsiasi piattaforma enterprise deve disporre di servizi di monitoraggio e registrazione centralizzati, meccanismi di sicurezza, autentificazione e autorizzazione, strumenti di gestione della rete. OpenShift fornisce tutto ciò 'out of the box', e tutto il codice è completamente open source, inclusi soluzioni come ElasticSearch, Prometheus, Grafana. Tutte queste soluzioni vengono fornite con dashboard, metriche e avvisi già pronti e configurati, tenendo conto dell'ampia esperienza di Red Hat nel monitoraggio dei cluster, consentendo un controllo e un monitoraggio efficaci fin dai primi momenti della vostra ambiente di produzione.
In OpenShift, there are also essential features for enterprise clients, such as authentication with a built-in OAuth provider, integration with credential providers including LDAP, Active Directory, OpenID Connect, and much more.
Pre-configured Grafana dashboard for monitoring the OpenShift cluster
Over 150 pre-configured Prometheus metrics and alerts for monitoring the OpenShift cluster
To be continued
The rich functionality of the solution and Red Hat's extensive experience in Kubernetes are the reasons why OpenShift has taken a dominant position in the market, as shown in the figure below (read more ).
Currently, Red Hat leads the market with a share of 44%.
The company is reaping the benefits of its sales strategy, which actively involves engaging with clients, initially consulting and training corporate developers, and then monetizing as the enterprise begins to implement containers into production.
(Source: )
Ci auguriamo che ti sia piaciuto questo articolo. Nei prossimi post di questa serie esploreremo più in dettaglio i vantaggi di OpenShift rispetto a Kubernetes in ciascuna delle categorie qui esaminate.
Fonte: habr.com
