«Qual è la differenza tra Kubernetes e OpenShift?» – questa domanda sorge con una costanza invidiabile. Anche se, in realtà, è come chiedere in che modo un'auto si differenzi da un motore. Continuando l'analogia, un'auto è un prodotto finito, utilizzabile immediatamente, letteralmente: ti siedi e parti. D'altra parte, affinché un motore possa portarti da qualche parte, deve prima essere completato con una serie di altre cose, per ottenere alla fine la stessa auto.
Pertanto, Kubernetes è un motore attorno al quale è costruita l'auto (piattaforma) chiamata OpenShift, che ti porta verso il tuo obiettivo.
In questo articolo vogliamo ricordare e approfondire un po' i seguenti punti chiave:
- Kubernetes è il cuore della piattaforma OpenShift. Ed è un Kubernetes certificato al 100%, con codice completamente aperto e senza la minima proprietà. In breve:
- L'API per il cluster OpenShift è un Kubernetes al 100%.
- Se un container funziona in qualsiasi altro sistema Kubernetes, funzionerà senza alcuna modifica anche su OpenShift. Non è necessario apportare modifiche alle applicazioni.
- OpenShift non solo arricchisce Kubernetes con funzioni e capacità utili. Come un'auto, OpenShift è subito pronto all'uso, può essere immediatamente messo in produzione e, come mostreremo di seguito, semplifica notevolmente la vita agli sviluppatori. Ecco perché OpenShift è unico in due aspetti. È sia una piattaforma PaaS di successo e ampliamente conosciuta di classe enterprise, se vista dalla prospettiva dello sviluppatore. E contemporaneamente è una soluzione super affidabile di tipo Container-as-a-Service dal punto di vista dell'operatività industriale.
OpenShift è Kubernetes con certificazione al 100% dalla CNCF
Alla base di OpenShift c'è . Pertanto, dopo un'adeguata formazione, gli utenti si meravigliano della potenza di kubectl. E coloro che sono passati da Kubernetes Cluster a OpenShift spesso dicono quanto apprezzino 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 di kubectl e offre anche alcune utili funzionalità aggiuntive che saranno utili per eseguire una serie di compiti. Ma iniziamo con maggiori dettagli sulla 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 – ritorna i pod come ci si aspetterebbe.
• kubectl get namespaces – ritorna i namespace come ci si aspetterebbe.
Il comando kubectl create -f mydeployment.yaml crea risorse Kubernetes esattamente come su qualsiasi altra piattaforma Kubernetes, come mostrato nel video qui sotto:
In altre parole, tutte le API di Kubernetes sono completamente disponibili su OpenShift con una compatibilità del 100%. Ecco perché .
OpenShift arricchisce Kubernetes con funzionalità utili
Le API di Kubernetes sono disponibili al 100% su OpenShift, ma l'utilità di Kubernetes kubectl manca chiaramente di funzionalità e comodità. Per questo motivo, Red Hat ha arricchito Kubernetes con funzionalità utili e strumenti da riga di comando, come OC (acronimo di OpenShift client) e ODO (OpenShift DO, progettato per gli sviluppatori).
1. L'utilità OC è un'opzione più potente e conveniente rispetto a Kubectl
Ad esempio, a differenza di kubectl, consente di creare nuovi namespace e di passare facilmente da un contesto all'altro, oltre a offrire una serie di comandi utili per gli sviluppatori, come per la costruzione di immagini di contenitori e il deployment di applicazioni direttamente dal codice sorgente o dai file binari (Source-to-image, s2i).
Esaminiamo con degli esempi come gli helper integrati e la funzionalità avanzata dello strumento OC aiutano a semplificare il lavoro quotidiano.
Primo esempio – gestione dei namespace. In ogni cluster Kubernetes ci sono sempre diversi namespace. Di solito, vengono utilizzati per creare ambienti di sviluppo e produzione, ma possono essere impiegati anche per fornire a ciascun sviluppatore una "sandbox" personale. Nella pratica, ciò porta gli sviluppatori a dover passare frequentemente tra i namespace, poiché kubectl opera nel contesto del namespace attuale. Pertanto, nel caso di kubectl, ci si affida attivamente a script helper per questo scopo. Con OC, invece, basta dire “oc project nome_namespace” per passare al namespace desiderato.
Non ricordi come si chiama lo spazio dei nomi richiesto? Nessun problema, basta digitare “oc get projects” per visualizzare l'elenco completo. Sei scettico su come possa funzionare se hai accesso solo a un sottoinsieme limitato di spazi dei nomi nel cluster? Beh, perché kubectl lo fa correttamente solo se RBAC ti consente di vedere tutti gli spazi nel cluster, e in grandi cluster questi permessi non sono concessi a tutti. Quindi, rispondiamo: per OC non è affatto un problema e fornirà facilmente un elenco completo in questa situazione. È da queste piccole cose che si compone 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 ulteriore esempio dei miglioramenti di Red Hat OpenShift rispetto a Kubernetes è l'utilità della riga di comando ODO. È progettata per gli sviluppatori e consente di distribuire rapidamente il codice locale su un cluster OpenShift remoto. Inoltre, consente di ottimizzare i processi interni per sincronizzare istantaneamente tutte le modifiche al codice con i container del cluster OpenShift remoto senza dover ricompilare, caricare nel registro e ridistribuire le immagini.
Vediamo come OC e ODO semplificano il lavoro con i container e Kubernetes.
Confrontiamo un paio di flussi di lavoro, quando sono basati su kubectl e quando vengono utilizzati OC o ODO.
• Distribuzione del codice su OpenShift per chi non sa il linguaggio YAML:
Kubernetes / kubectl
$> git clone
1- Creiamo un Dockerfile che compila un'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- Compiliamo l'immagine
$> podman build …
3- Effettuiamo il login nel registro
podman login …
4- Carichiamo l'immagine nel registro
podman push
5- Creiamo i file yaml per la distribuzione dell'applicazione (deployment.yaml, service.yaml, ingress.yaml) – questo è il minimo indispensabile
6- Distribuiamo i file manifest:
Kubectl apply -f .
OpenShift / oc
$> oc new-app – nome_del_nostro_app
OpenShift / odo
$> git clone
$> odo create component nodejs myapp
$> odo push
• Cambio di contesto: modifica dello spazio dei nomi di lavoro o del 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à: «È emersa una funzione interessante qui, attualmente in versione alpha. Potremmo introdurla in produzione?»
Immaginate di essere messi in un'auto da corsa e vi dicono: «Abbiamo installato freni di nuova generazione e, a dire il vero, non sono proprio al massimo della loro affidabilità... Ma non preoccupatevi, li perfezioneremo durante il campionato». Che ne pensate? A noi di Red Hat non piace molto. 🙂
Pertanto, cerchiamo di evitarci le versioni alpha finché non sono sufficientemente mature e finché non abbiamo effettuato test approfonditi in condizioni operative e non ci sentiamo sicuri del loro utilizzo. Di solito, tutto passa prima attraverso la fase Dev Preview, poi e solo successivamente viene rilasciato come versione accessibile al pubblico (GA), che è già stabilizzato a tal punto da essere pronto per la produzione.
Perché è così? Perché, come per lo sviluppo di qualsiasi altro software, non tutte le idee iniziali in Kubernetes arrivano al rilascio finale. Oppure arrivano e mantengono la funzionalità prevista, ma la loro implementazione è radicalmente diversa da quella dell'alpha. Poiché migliaia di clienti Red Hat utilizzano OpenShift per supportare operazioni critiche, poniamo particolare attenzione alla stabilità della nostra piattaforma e al supporto a lungo termine.
Red Hat rilascia regolarmente aggiornamenti di OpenShift e aggiorna la versione di Kubernetes che ne fa parte. Ad esempio, nell'attuale rilascio GA di OpenShift 4.3, è integrato Kubernetes 1.16, che è solo di una versione indietro rispetto alla versione upstream di Kubernetes con numero 1.17. In questo modo, cerchiamo di fornire ai clienti Kubernetes di classe enterprise e garantire un controllo qualità aggiuntivo nel processo di rilascio di nuove versioni di OpenShift.
Correzioni software: «Nella versione di Kubernetes che abbiamo in produzione è stata trovata una vulnerabilità. E può essere risolta solo aggiornando a tre versioni superiori. Ci sono opzioni alternative?»
Nel contesto del progetto open source Kubernetes, le correzioni software vengono generalmente rilasciate con il rilascio successivo, a volte coprono una o due versioni intermedie precedenti, ciò porta a una copertura di sei mesi fa.
Red Hat è giustamente orgogliosa di rilasciare correzioni critiche prima di altri e di fornire supporto per un periodo di tempo molto più lungo. Prendiamo ad esempio la vulnerabilità di escalation dei privilegi in Kubernetes (): è stata scoperta in Kubernetes 1.11, e le correzioni per le versioni precedenti sono state rilasciate solo fino alla versione 1.10.11, lasciando questa falla in tutte le versioni precedenti di Kubernetes, da 1.x a 1.9.
Da parte sua, (che utilizza Kubernetes 1.2), coprendo nove versioni di OpenShift e dimostrando chiaramente attenzione per i clienti (scopri di più ).
Come OpenShift e Red Hat fanno avanzare Kubernetes
Red Hat è al secondo posto per il volume di contributi al progetto open source Kubernetes, superata solo da Google, e 3 dei 5 sviluppatori più prolifici sono dipendenti di Red Hat. Un altro fatto poco conosciuto: molte funzionalità critiche sono state introdotte in Kubernetes grazie all'iniziativa di Red Hat, in particolare funzionalità come:
- RBAC. In Kubernetes non erano presenti 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? Certo che no, perché Red Hat segue rigorosamente i principi del software open source, senza giocare ai giochi dell'Open Core. I miglioramenti e le innovazioni che vengono realizzati a livello di comunità di sviluppo, e non secondo un principio di proprietà, diventano più sostenibili e ottengono una diffusione più ampia, il che è perfettamente in linea con il nostro obiettivo principale: rendere il software open source più utile per i nostri clienti.
- 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). E come nel caso precedente, Red Hat ha deciso di introdurre questi sviluppi nel progetto open source Kubernetes, affinché tutti possano usufruirne.
Questa serie di esempi potrebbe continuare, ma volevamo solo mostrare che Red Hat si impegna realmente a sviluppare Kubernetes e a renderlo migliore per tutti.
Chiaro, OpenShift è Kubernetes. E quali sono le differenze? 🙂
Ci auguriamo che, arrivati a questo punto, abbiate compreso che Kubernetes è il componente principale di OpenShift. Principale, ma non certo unico. In altre parole, semplicemente installando Kubernetes, non otterrete una piattaforma enterprise. Dovrete aggiungere autenticazione, rete, sicurezza, monitoraggio, gestione dei log e molto altro. Inoltre, dovrete fare una scelta difficile tra un'ampia gamma di strumenti disponibili (per valutare la varietà dell'ecosistema, date un'occhiata ) e in qualche modo garantire coerenza e integrazione affinché funzionino come un tutto unico. Inoltre, dovrete effettuare regolarmente aggiornamenti e test di regressione ad ogni nuova versione di uno qualsiasi dei componenti utilizzati. Cioè, oltre a creare e mantenere la piattaforma stessa, dovrete occuparvi anche di tutto questo software. È improbabile che rimanga molto tempo per affrontare le sfide aziendali e conseguire un vantaggio competitivo.
Ma nel caso di OpenShift, Red Hat si occupa di tutte queste complessità e vi offre semplicemente una piattaforma funzionalmente completa, che non include solo Kubernetes, ma anche l'intero insieme di strumenti open source necessari per trasformare Kubernetes in una vera soluzione enterprise che può essere immediatamente e senza preoccupazioni avviata in produzione. E naturalmente, se avete già dei vostri stack tecnologici, potete integrare OpenShift nelle soluzioni esistenti.
Date un'occhiata all'illustrazione sopra: tutto ciò che si trova al di fuori del rettangolo Kubernetes è dove Red Hat aggiunge funzionalità che in Kubernetes non esistono, per così dire, by-design. Ora esamineremo le principali di queste aree.
1. Un sistema operativo affidabile come base: RHEL CoreOS o RHEL
Red Hat è da oltre 20 anni il principale fornitore di distribuzioni Linux per applicazioni aziendali critiche. L'esperienza maturata e costantemente aggiornata in questo settore ci consente di offrire una base veramente affidabile e fidata per l'operatività industriale dei container. RHEL CoreOS utilizza lo stesso kernel di RHEL, ma è ottimizzato principalmente per attività come l'esecuzione di container e il lavoro con cluster Kubernetes: la sua dimensione ridotta e l'immutabilità semplificano l'installazione di cluster, l'auto-scaling, il deployment di patch, ecc. Tutte queste funzionalità la rendono una base ideale per fornire la stessa esperienza utente lavorando con OpenShift in una vasta gamma di ambienti di calcolo, dall'hardware nudo al cloud privato e pubblico.
2. Automazione delle operazioni IT
L'automazione dei processi di installazione e delle operazioni del secondo giorno (cioè l'operatività quotidiana) è il punto di forza di OpenShift, che semplifica notevolmente l'amministrazione, l'aggiornamento e il mantenimento della piattaforma container al massimo livello. Questo viene raggiunto grazie al supporto dei Kubernetes operator a livello di kernel di OpenShift 4.
OpenShift 4 è anche un'intera ecosistema di soluzioni basate su Kubernetes operator, sviluppate sia da Red Hat che da partner esterni (vedi Red Hat, o il negozio degli operatori , creato da Red Hat per sviluppatori esterni).
L'integrato catalogo di OpenShift 4 comprende oltre 180 Kubernetes operator
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, così come servizi di integrazione e consegna continua CI/CD, database, ecc. OpenShift 4 offre , che include oltre 100 servizi basati su Kubernetes operator, sviluppati da Red Hat e dai nostri partner.
A differenza di Kubernetes, OpenShift 4 ha un'interfaccia grafica speciale (), che aiuta gli sviluppatori a distribuire le applicazioni da diverse fonti (git, registri esterni, Dockerfile, ecc.) nei propri spazi dei nomi senza sforzi eccessivi, visualizzando chiaramente le relazioni tra i componenti dell'applicazione.
Inoltre, OpenShift offre un insieme di strumenti di sviluppo Codeready, che include, in particolare, , un IDE completamente containerizzato con interfaccia web, che funziona direttamente su OpenShift e adotta l'approccio dell'«IDE come servizio». D'altro canto, per coloro che desiderano lavorare esclusivamente in modalità locale, ci sono i Codeready Containers: una versione completamente funzionale di OpenShift 4, che può essere distribuita su un laptop.
IDE integrato «come servizio» per lo sviluppo efficiente sulla piattaforma Kubernetes/OpenShift.
OpenShift offre, direttamente out of the box, un sistema CI/CD completo, basato su Jenkins containerizzato e un plugin per il funzionamento dei pipeline, oppure 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 attivare trigger dei pipeline, visualizzare distribuzioni, log, ecc.
4. Strumenti per applicazioni
OpenShift consente di distribuire sia applicazioni tradizionali stateful che soluzioni orientate al cloud basate su nuove architetture, come microservizi o serverless. La soluzione OpenShift Service Mesh offre out of the box strumenti chiave per la gestione dei microservizi, come Istio, Kiali e Jaeger. A sua volta, la soluzione OpenShift Serverless include non solo Knative, ma anche strumenti sviluppati nell'ambito di iniziative comuni 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 ridurre il divario tra applicazioni legacy e container, OpenShift ora consente di migrare macchine virtuali sulla piattaforma OpenShift utilizzando la Container Native Virtualization (attualmente in versione TechPreview), trasformando le applicazioni ibride in realtà e semplificando il loro spostamento tra vari cloud, sia privati che pubblici.
Macchina virtuale Windows 2019 Virtual, eseguita su OpenShift tramite Container Native Virtualization (attualmente in versione Tech preview).
5. Strumenti per cluster
Qualsiasi piattaforma di classe enterprise deve disporre di servizi di monitoraggio e gestione centralizzata dei log, meccanismi di sicurezza, autenticazione e autorizzazione, strumenti di gestione della rete. OpenShift fornisce tutto questo 'out of the box', e tutto con codice sorgente aperto al 100%, compresi soluzioni come ElasticSearch, Prometheus e Grafana. Tutte queste soluzioni vengono fornite con cruscotti, metriche e avvisi già configurati e impostati tenendo conto dell'ampia esperienza di Red Hat nel monitoraggio dei cluster, il che consente di controllare e monitorare efficacemente il lavoro del vostro ambiente di produzione fin dai primi minuti.
OpenShift include anche funzioni importanti per i clienti aziendali, come l'autenticazione con un provider oauth integrato, integrazione con provider di credenziali come LDAP, ActiveDirectory, OpenID Connect e molto altro.
Cruscotto Grafana preconfigurato per il monitoraggio del cluster OpenShift
Oltre 150 metriche e avvisi Prometheus preconfigurati per il monitoraggio del cluster OpenShift
Continua
La ricca funzionalità della soluzione e l'ampia esperienza di Red Hat nel Kubernetes sono proprio le ragioni per cui OpenShift ha occupato una posizione dominante nel mercato, come mostrato nell'immagine qui sotto (maggiori dettagli ).
«Attualmente Red Hat è leader di mercato con una quota del 44%.
L'azienda sta raccogliendo i frutti della sua strategia di vendita con un coinvolgimento attivo nei progetti dei clienti, in cui prima consulta e forma gli sviluppatori aziendali, per poi passare alla monetizzazione man mano che l'azienda inizia a implementare container in produzione».
(Fonte: )
Speriamo che ti sia piaciuto questo articolo. Nei prossimi post di questa serie approfondiremo i vantaggi di OpenShift rispetto a Kubernetes in ciascuna delle categorie discusse qui.
Fonte: habr.com
