"Vad är skillnaden mellan Kubernetes och OpenShift?" – Den här frågan uppstår med avundsvärd konsekvens. Även om det i verkligheten är som att fråga hur en bil skiljer sig från en motor. Om vi fortsätter analogin, då är en bil en färdig produkt, du kan använda den direkt, bokstavligen: gå in och gå. Å andra sidan, för att en motor ska ta dig någonstans måste den först kompletteras med en massa annat för att i slutändan få samma bil.
Därför är Kubernetes motorn runt vilken OpenShift-bilen (plattformen) är monterad, som tar dig till ditt mål.
I den här artikeln vill vi påminna dig och undersöka följande nyckelpunkter lite mer detaljerat:
- Kubernetes är hjärtat i OpenShift-plattformen och det är 100 % certifierade Kubernetes, helt öppen källkod och utan den minsta proprietära karaktär. I korthet:
- OpenShift kluster API är XNUMX % Kubernetes.
- Om behållaren körs på något annat Kubernetes-system kommer den att köras på OpenShift utan några ändringar. Det finns ingen anledning att göra ändringar i applikationerna.
- OpenShift lägger inte bara till användbara funktioner och funktionalitet till Kubernetes. Precis som en bil är OpenShift ur lådan, kan sättas i produktion omedelbart och, som vi ska visa nedan, gör det en utvecklares liv mycket enklare. Det är därför OpenShift är förenat i två personer. Det är en både framgångsrik och välkänd PaaS-plattform i företagsklass ur ett utvecklarperspektiv. Och samtidigt är det en superpålitlig Container-as-a-Service-lösning ur industriell driftsynpunkt.
OpenShift är Kubernetes med 100 % CNCF-certifiering
OpenShift är baserad på . Därför, efter korrekt utbildning, blir användare förvånade över kraften i kubectl. Och de som bytte till OpenShift från Kubernetes Cluster säger ofta hur mycket de verkligen gillar att efter att ha omdirigerat kubeconfig till OpenShift-klustret, fungerar alla befintliga skript felfritt.
Du har säkert hört talas om OpenShifts kommandoradsverktyg som heter OC. Den är helt kommandokompatibel med kubectl, plus att den erbjuder flera användbara hjälpare som kommer att vara användbara när du utför ett antal uppgifter. Men först, lite mer om kompatibiliteten för OC och kubectl:
kubectl-kommandon
OC-lag
kubectl få skidor
oc få poddar
kubectl hämta namnutrymmen
oc få namnutrymmen
kubectl skapa -f deployment.yaml
oc skapa -f deployment.yaml
Så här ser resultaten ut av att använda kubectl på OpenShift API:
• kubectl get pods – returnerar pods som förväntat.
• kubectl get namespaces – returnerar namnrymder som förväntat.
Kommandot kubectl create -f mydeployment.yaml skapar kubernetes-resurser precis som på alla andra Kubernetes-plattformar, som visas i videon nedan:
Med andra ord är alla Kubernetes API:er fullt tillgängliga i OpenShift samtidigt som de bibehåller 100 % kompatibilitet. Det är därför .
OpenShift lägger till användbara funktioner till Kubernetes
Kubernetes API:er är 100 % tillgängliga i OpenShift, men standardverktyget Kubernetes kubectl saknar helt klart funktionalitet och bekvämlighet. Det är därför Red Hat har lagt till användbara funktioner och kommandoradsverktyg till Kubernetes, som OC (förkortning för OpenShift-klient) och ODO (OpenShift DO, det här verktyget riktar sig till utvecklare).
1. OC-verktyg - en mer kraftfull och bekväm version av Kubectl
Till exempel, till skillnad från kubectl, låter den dig skapa nya namnutrymmen och enkelt byta sammanhang, och erbjuder även ett antal användbara kommandon för utvecklare, som att bygga behållarbilder och distribuera applikationer direkt från källkod eller binärer (Källa-till-bild, s2i).
Låt oss titta på exempel på hur de inbyggda hjälparna och avancerade funktionerna i OC-verktyget hjälper till att förenkla det dagliga arbetet.
Det första exemplet är namnutrymmeshantering. Varje Kubernetes-kluster har alltid flera namnområden. De används vanligtvis för att skapa utvecklings- och produktionsmiljöer, men kan också användas för att till exempel förse varje utvecklare med en personlig sandlåda. I praktiken resulterar detta i att utvecklaren ofta måste byta mellan namnutrymmen, eftersom kubectl körs i sammanhanget med det aktuella utrymmet. Därför, när det gäller kubectl, använder människor aktivt hjälpskript för detta. Men när du använder OC, för att byta till önskat utrymme, säg bara "oc project namespace".
Kommer du inte ihåg vad namnutrymmet du behöver heter? Inga problem, skriv bara "oc get projects" för att visa hela listan. Undrar skeptisk hur detta kommer att fungera om du bara har tillgång till en begränsad delmängd av namnutrymmen i klustret? Jo, eftersom kubectl bara gör detta korrekt om RBAC tillåter dig att se alla utrymmen i klustret, och i stora kluster ges inte alla sådana behörigheter. Så vi svarar: för OC är detta inte ett problem alls och det kommer lätt att producera en komplett lista i en sådan situation. Det är dessa små saker som utgör företagsinriktningen hos Openshift och den här plattformens goda skalbarhet när det gäller användare och applikationer
2. ODO - en förbättrad version av kubectl för utvecklare
Ett annat exempel på Red Hat OpenShifts förbättringar jämfört med Kubernetes är kommandoradsverktyget ODO. Den är designad för utvecklare och låter dig snabbt distribuera lokal kod till ett fjärranslutet OpenShift-kluster. Det kan också effektivisera interna processer för att omedelbart synkronisera alla kodändringar till behållare på ett fjärranslutet OpenShift-kluster utan att behöva bygga om, registrera och omdistribuera bilder.
Låt oss titta på hur OC och ODO gör det enklare att arbeta med containrar och Kubernetes.
Jämför bara ett par arbetsflöden när de är byggda på basis av kubectl, och när OC eller ODO används.
• Implementering av kod på OpenShift för de som inte talar YAML:
Kubernetes/kubectl
$>git klon
1- Skapa en Dockerfil som bygger bilden från kod
-----
FRÅN nod
WORKDIR /usr/src/app
COPY package*.json ./
COPY index.js ./
KOPIERA ./app ./app
KÖR npm installation
EXPONERA 3000
CMD [ "npm", "start" ] ————–
2- Vi bygger bilden
$>podman build...
3- Logga in i registret
podman login...
4- Placera bilden i registret
podman push
5- Skapa yaml-filer för applikationsdistribution (deployment.yaml, service.yaml, ingress.yaml) - detta är det absoluta minimumet
6- Distribuera manifestfiler:
Kubectl tillämpa -f .
OpenShift/oc
$> oc ny-app – vårt_applikationsnamn
OpenShift/odo
$>git klon
$> odo skapa komponent nodejs minapp
$>odo tryck
• Kontextväxling: ändra arbetsnamnutrymmet eller arbetskluster.
Kubernetes/kubectl
1- Skapa ett sammanhang i kubeconfig för projektet "myproject"
2- kubectl set-kontext...
OpenShift/oc
oc projekt "mitt projekt"
Kvalitetskontroll: "En intressant funktion har dykt upp här, fortfarande i alfaversion. Kanske kan vi sätta den i produktion?”
Föreställ dig att du sitter i en racerbil och får höra: "Vi har installerat en ny typ av bromsar och ärligt talat är deras tillförlitlighet inte okej ännu... Men oroa dig inte, vi kommer aktivt att förbättra dem direkt under mästerskap." Hur gillar du den här utsikten? Vi på Red Hat är på något sätt inte särskilt nöjda. 🙂
Därför försöker vi vänta med alfaversioner tills de är tillräckligt mogna och vi har gjort grundliga stridstester och känner att de är säkra att använda. Vanligtvis går allt först igenom Dev Preview-stadiet och sedan igenom och först därefter kommer ut som en offentlig release (GA), som redan är så stabil att den lämpar sig för produktion.
Varför är det så? Eftersom, som med utvecklingen av all annan programvara, når inte alla initiala idéer i Kubernetes den slutliga versionen. Eller de når det och behåller till och med den avsedda funktionaliteten, men deras implementering skiljer sig radikalt från den i alfaversionen. Med tusentals och åter tusentals Red Hat-kunder som använder OpenShift för att stödja verksamhetskritiska arbetsbelastningar, lägger vi särskild tonvikt på stabiliteten hos vår plattform och långsiktigt stöd.
Red Hat har förbundit sig att släppa OpenShift ofta och uppdatera den version av Kubernetes som följer med. Till exempel inkluderar den nuvarande GA-versionen av OpenShift 4.3 när detta skrivs Kubernetes 1.16, som bara är en enhet bakom uppströmsversionen av Kubernetes med nummer 1.17. Därför försöker vi förse kunden med Kubernetes i företagsklass och tillhandahålla ytterligare kvalitetskontroll under lanseringen av nya versioner av OpenShift.
Programvarukorrigeringar: "Det fanns ett hål i versionen av Kubernetes som vi har i produktion. Och du kan bara stänga den genom att uppdatera tre versioner. Eller finns det några alternativ?
I Kubernetes open source-projekt släpps programfixar vanligtvis som en del av nästa utgåva, ibland täcker en eller två tidigare milstolpsutgåvor, vilket ger täckning tillbaka så lite som 6 månader.
Red Hat är stolt över att släppa kritiska korrigeringar tidigare än andra och ge support mycket längre. Ta till exempel Kubernetes privilegieeskaleringssårbarhet (): den upptäcktes i Kubernetes 1.11, och korrigeringar för tidigare utgåvor släpptes endast upp till version 1.10.11, vilket lämnade denna i hålet i alla tidigare Kubernetes-utgåvor, från 1.x till 1.9.
I sin tur, (Kubernetes 1.2 finns där), fångar nio OpenShift-versioner och visar tydligt omsorg för kunderna (mer information ).
Hur OpenShift och Red Hat för Kubernetes framåt
Red Hat är den näst största mjukvarubidragsgivaren till Kubernetes-projektet med öppen källkod, efter endast Google, med 3 av de 5 mest produktiva utvecklarna som kommer från Red Hat. Ett annat föga känt faktum: många kritiska funktioner dök upp i Kubernetes just på initiativ av Red Hat, i synnerhet, som:
- RBAC. Kubernetes hade inte RBAC-funktioner (ClusterRole, ClusterRoleBinding) förrän Red Hat-ingenjörer bestämde sig för att implementera dem som en del av själva plattformen och inte som ytterligare OpenShift-funktionalitet. Är Red Hat rädd för att förbättra Kubernetes? Naturligtvis inte, eftersom Red Hat strikt följer principerna för öppen källkod och inte spelar Open Core-spel. Förbättringar och innovationer som drivs av utvecklingsgemenskaper, snarare än proprietära sådana, är mer genomförbara och mer allmänt antagna, vilket stämmer väl överens med vårt kärnmål att göra programvara med öppen källkod mer användbar för våra kunder.
- Säkerhetspolicyer för pods (Pod Security Policies). Detta koncept med att köra applikationer säkert inuti pods implementerades ursprungligen i OpenShift under namnet SCC (Security Context Constraints). Och som i föregående exempel bestämde sig Red Hat för att introducera dessa utvecklingar i det öppna Kubernetes-projektet så att alla kunde använda dem.
Den här serien av exempel skulle kunna fortsätta, men vi ville bara visa att Red Hat verkligen är engagerad i att utveckla Kubernetes och göra det bättre för alla.
Det är tydligt att OpenShift är Kubernetes. Vilka är skillnaderna? 🙂
Vi hoppas att du genom att läsa så här långt har insett att Kubernetes är kärnkomponenten i OpenShift. Den främsta, men långt ifrån den enda. Med andra ord, att bara installera Kubernetes kommer inte att ge dig en plattform i företagsklass. Du måste lägga till autentisering, nätverk, säkerhet, övervakning, logghantering och mer. Dessutom måste du göra några svåra val bland det stora antalet tillgängliga verktyg (för att uppskatta mångfalden i ekosystemet, ta bara en titt ) och på något sätt säkerställa konsekvens och sammanhållning så att de fungerar som ett. Dessutom kommer du regelbundet behöva utföra uppdateringar och regressionstestning när en ny version av någon av komponenterna du använder släpps. Det vill säga, förutom att skapa och underhålla själva plattformen kommer du också att behöva ta itu med all denna mjukvara. Det är osannolikt att det kommer att finnas mycket tid kvar för att lösa affärsproblem och uppnå konkurrensfördelar.
Men i fallet med OpenShift tar Red Hat alla dessa komplexiteter på sig och ger dig helt enkelt en funktionellt komplett plattform, som inte bara inkluderar Kubernetes själv, utan också hela uppsättningen nödvändiga verktyg med öppen källkod som gör Kubernetes till en riktig företagsklass lösning som du omedelbart och helt lugnt kan sätta i produktion. Och naturligtvis, om du har några av dina egna teknikstackar, kan du integrera OpenShift i befintliga lösningar.
Ta en titt på bilden ovan: allt som finns utanför Kubernetes rektangel är där Red Hat lägger till funktionalitet som Kubernetes inte har, som de säger, by-design. Och nu ska vi titta på huvuddelen av dessa områden.
1. Robust OS som bas: RHEL CoreOS eller RHEL
Red Hat har varit en ledande leverantör av Linux-distributioner för affärskritiska applikationer i mer än 20 år. Vår samlade och ständigt uppdaterade erfarenhet inom detta område gör att vi kan erbjuda en verkligt pålitlig och pålitlig grund för industriell drift av containrar. RHEL CoreOS använder samma kärna som RHEL, men är optimerad främst för uppgifter som att köra behållare och köra Kubernetes-kluster: dess minskade storlek och oföränderlighet gör det lättare att konfigurera kluster, autoskalning, distribuera patchar etc. Alla dessa funktioner gör det en idealisk grund för att leverera samma användarupplevelse med OpenShift i ett brett utbud av datormiljöer, från ren metall till privata och offentliga moln.
2. Automatisering av IT-drift
Automatisering av installationsprocesser och dag-4-operationer (det vill säga den dagliga driften) är OpenShifts starka sida, vilket gör det mycket lättare att administrera, uppdatera och underhålla containerplattformens prestanda på högsta nivå. Detta uppnås genom stöd för Kubernetes-operatörer på OpenShift XNUMX-kärnnivå.
OpenShift 4 är också ett helt ekosystem av lösningar baserade på Kubernetes-operatörer, utvecklade både av Red Hat själv och av tredjepartspartners (se. Red Hat, eller operatörsbutik , skapad av Red Hat för tredjepartsutvecklare).
Den integrerade OpenShift 4-katalogen innehåller mer än 180 Kubernetes-operatörer
3. Utvecklarverktyg
Sedan 2011 har OpenShift varit tillgänglig som en PaaS-plattform (Platform-as-a-Service) som gör livet mycket lättare för utvecklare, hjälper dem att fokusera på kodning och erbjuder inbyggt stöd för programmeringsspråk som Java, Node.js , PHP, Ruby, Python, Go, samt CI/CD kontinuerlig integration och leveranstjänster, databaser, etc. OpenShift 4 erbjuder , som inkluderar mer än 100 tjänster baserade på Kubernetes-operatörer utvecklade av Red Hat och våra partners.
Till skillnad från Kubernetes har OpenShift 4 ett dedikerat GUI (), som hjälper utvecklare att enkelt distribuera applikationer från olika källor (git, externa register, Dockerfile, etc.) i sina namnområden och tydligt visualiserar relationerna mellan applikationskomponenter.
Dessutom erbjuder OpenShift en uppsättning Codeready-utvecklingsverktyg, som i synnerhet inkluderar , en helt containeriserad IDE med ett webbgränssnitt som körs direkt ovanpå OpenShift och implementerar en IDE-som-en-tjänst-metod. Å andra sidan, för de som vill arbeta strikt i lokalt läge, finns Codeready Containers, en fullt fungerande version av OpenShift 4 som kan distribueras på en bärbar dator.
Integrerad IDE som en tjänst för effektiv utveckling på Kubernetes/OpenShift-plattformen
OpenShift erbjuder ett komplett CI/CD-system direkt ur lådan, antingen baserat på containeriserade Jenkins och en plugin för arbete med pipelines, eller ett Kubernetes-orienterat CI/CD-system (för närvarande i teknisk förhandsversion). Båda dessa lösningar är helt integrerade med OpenShift-konsolen, så att du kan köra pipelineutlösare, visa distributioner, loggar och mer.
4. Applikationsverktyg
OpenShift låter dig distribuera både traditionella stateful applikationer och molnbaserade lösningar baserade på nya arkitekturer, såsom mikrotjänster eller serverlösa. OpenShift Service Mesh-lösningen kommer direkt ur lådan med viktiga verktyg för att underhålla mikrotjänster, som Istio, Kiali och Jaeger. I sin tur inkluderar OpenShift Serverless-lösningen inte bara Knative, utan också verktyg som Keda skapade som en del av ett gemensamt initiativ med Microsoft för att tillhandahålla Azure-funktioner på OpenShift-plattformen.
Den integrerade lösningen OpenShift ServiceMesh (Istio, Kiali, Jaeger) kommer att vara användbar vid utveckling av mikrotjänster
För att överbrygga klyftan mellan äldre applikationer och behållare tillåter OpenShift nu virtuell maskinmigrering till OpenShift-plattformen med hjälp av Container Native Virtualization (för närvarande i TechPreview), vilket gör hybridapplikationer till verklighet och underlättar deras migrering mellan olika moln, både privata och offentliga.
Windows 2019 virtuell virtuell maskin som körs på OpenShift via Container Native Virtualization (för närvarande i teknisk förhandsversion)
5. Verktyg för kluster
Varje plattform i företagsklass måste ha övervaknings- och centraliserade loggningstjänster, säkerhetsmekanismer, autentisering och auktorisering och nätverkshanteringsverktyg. Och OpenShift tillhandahåller allt detta direkt, och allt är 100 % öppen källkod, inklusive lösningar som ElasticSearch, Prometheus, Grafana. Alla dessa lösningar kommer med instrumentpaneler, mätvärden och varningar som redan är byggda och konfigurerade med hjälp av Red Hats omfattande expertis inom klusterövervakning, vilket gör att du effektivt kan kontrollera och övervaka din produktionsmiljö redan från början.
OpenShift kommer också som standard med så viktiga saker för företagskunder som autentisering med en inbyggd OAuth-leverantör, integration med legitimationsleverantörer, inklusive LDAP, ActiveDirectory, OpenID Connect och mycket mer.
Förkonfigurerad Grafana-instrumentpanel för OpenShift-klusterövervakning
Över 150 förkonfigurerade Prometheus-mått och varningar för OpenShift-klusterövervakning
Fortsättning
Lösningens rika funktionalitet och Red Hats långa erfarenhet inom Kubernetes-området är anledningarna till att OpenShift har uppnått en dominerande ställning på marknaden, som visas i figuren nedan (läs mer ).
"Red Hat leder för närvarande marknaden med en andel på 44%.
Företaget skördar frukterna av sin kundcentrerade försäljningsstrategi, där det först konsulterar och utbildar företagsutvecklare och sedan går över till intäktsgenerering när företaget börjar distribuera containrar i produktion."
(Källa: )
Vi hoppas att du gillade den här artikeln. I framtida inlägg i den här serien kommer vi att titta närmare på fördelarna med OpenShift framför Kubernetes i var och en av kategorierna som diskuteras här.
Källa: will.com