«Hvad er forskellen mellem Kubernetes og OpenShift?» – dette spørgsmål dukker op med beundringsværdig regelmæssighed. I virkeligheden er det dog lige så meningsløst som at spørge, hvordan en bil adskiller sig fra en motor. For at fortsætte analogien: en bil er et færdigt produkt, som man kan bruge straks – simpelthen: sæt dig ind og kør. På den anden side, for at en motor kan transportere dig, skal den suppleres med en masse andre komponenter for til sidst at få den samme bil.
Derfor er Kubernetes som en motor, omkring hvilken bilen (platformen) mærket OpenShift er bygget, der transporterer dig mod målet.
I denne artikel vil vi gerne minde dig om samt uddybe følgende centrale punkter:
- Kubernetes er hjertet i OpenShift-platformen, og det er 100% certifieret Kubernetes, med fuld kildekode og uden spor af proprietaritet. Kort sagt:
- API'et for OpenShift-klyngen er 100% Kubernetes.
- Hvis en container fungerer i et andet Kubernetes-system, vil den fungere uden ændringer i OpenShift. Det er ikke nødvendigt at ændre applikationerne.
- OpenShift suppleres ikke kun med nyttige funktioner og muligheder til Kubernetes. Ligesom bilen er OpenShift straks klar til brug, det kan straks sættes i produktion, og som vi vil vise nedenfor, gør det livet betydeligt lettere for udvikleren. Derfor er OpenShift ét i to ansigtter. Det er både en succesfuld og velkendt PaaS-platform i virksomhedsklasse, når man ser det fra udviklerens perspektiv. Samtidig er det en super-pålidelig løsning i klassen Container-as-a-Service set fra et industrielt driftsperspektiv.
OpenShift er Kubernetes med 100% certificering fra CNCF-fonden.
Kernen i OpenShift er . Derfor er brugere efter passende træning imponerede over kraften i kubectl. Og dem, der er gået fra Kubernetes-klynge til OpenShift, siger ofte, at de virkelig kan lide, at efter at have omdirigeret kubeconfig til OpenShift-klyngen fungerer alle eksisterende scripts fejlfrit.
Du har sikkert hørt om OpenShift's kommandolinjeværktøj kaldet OC. Det er fuldt kompatibelt med kubectl, plus det tilbyder flere nyttige hjælpemidler, der kan bruges til en række opgaver. Men først lidt mere om kompatibiliteten mellem OC og kubectl:
kubectl-kommandoer
OC-kommandoer
kubectl get pods
oc get pods
kubectl get namespaces
oc get namespaces
kubectl create -f deployment.yaml
oc create -f deployment.yaml
Sådan ser resultaterne af at bruge kubectl med OpenShift API ud:
• kubectl get pods – forventeligt returnerer pod'ene.
• kubectl get namespaces – forventeligt returnerer navnerummene.
Kommandoen kubectl create -f mydeployment.yaml opretter Kubernetes-ressourcer nøjagtigt som på enhver anden Kubernetes-platform, som vist i videoen nedenfor:
Med andre ord er alle Kubernetes-API'er helt tilgængelige i OpenShift med 100% kompatibilitet. Det er derfor, .
OpenShift supplerer Kubernetes med nyttige funktioner
Kubernetes-API'erne er 100% tilgængelige i OpenShift, men den standard Kubernetes-utility, kubectl, mangler klart funktionalitet og brugervenlighed. Derfor har Red Hat suppleret Kubernetes med nyttige funktioner og kommandolinjeværktøjer som OC (forkortelse for OpenShift client) og ODO (OpenShift DO, dette værktøj er beregnet til udviklere).
1. OC-værktøjet – en mere kraftfuld og brugervenlig variant af Kubectl
For eksempel, i modsætning til kubectl, gør det muligt at oprette nye navnerum og nemt skifte kontekst samt tilbyder en række nyttige kommandoer for udviklere, for eksempel til at bygge containerbilleder og implementere applikationer direkte fra kildekode eller binære filer (Source-to-image, s2i).
Lad os se på eksempler på, hvordan de indbyggede hjælpemidler og den udvidede funktionalitet i OC-værktøjet hjælper med at forenkle den daglige arbejdsgang.
Eksempel et – administration af navnerum. Der er altid flere navnerum i hver Kubernetes-klynge. De bruges normalt til at oprette udviklings- og produktionsmiljøer, men kan også anvendes til at give hver udvikler en personlig 'sandkasse'. I praksis fører dette til, at udvikleren ofte skal skifte mellem navnerum, da kubectl fungerer i konteksten af det aktuelle navnerum. Derfor bruger folk aktivt hjælpeskriipter til dette formål med kubectl. Men når man bruger OC, er det tilstrækkeligt at sige “oc project navnerum” for at skifte til det ønskede navnerum.
Kan du ikke huske, hvad det rigtige navn på det nødvendige navnerum er? Ikke et problem, skriv bare "oc get projects" for at få vist en fuld liste. Er du skeptisk og nysgerrig på, hvordan det fungerer, hvis du kun har adgang til et begrænset udvalg af navnerum i klyngen? Det er fordi, kubectl kun gør det korrekt, hvis RBAC tillader dig at se alle navnerum i klyngen, og i store klynger får ikke alle sådanne rettigheder. Så her er svaret: For OC er det slet ikke et problem, og det vil nemt vise en fuld liste i en sådan situation. Det er disse små detaljer, der bidrager til Openshifts virksomhedsfokus og platformens fremragende skalerbarhed med hensyn til brugere og applikationer.
2. ODO – en forbedret version af kubectl for udviklere
Som et andet eksempel på forbedringerne i Red Hat OpenShift sammenlignet med Kubernetes kan nævnes kommandolinjeværktøjet ODO. Det er designet til udviklere og gør det muligt hurtigt at implementere lokal kode på en fjern OpenShift-klynge. Desuden kan det optimere interne processer for hurtigt at synkronisere alle kodeændringer med containere i den fjernbetjente OpenShift-klynge uden at skulle genopbygge, uploade til registreret og redeployere billeder.
Lad os se på, hvordan OC og ODO letter arbejdet med containere og Kubernetes.
Lad os simpelthen sammenligne et par arbejdsgange, når de bygges på basis af kubectl, og når OC eller ODO anvendes.
• Implementering af kode på OpenShift for dem, der ikke mestrer YAML:
Kubernetes / kubectl
$> git clone
1- Opretter en Dockerfile, der bygger et billede fra koden
————–
FROM node
WORKDIR /usr/src/app
COPY package*.json ./
COPY index.js ./
COPY ./app ./app
RUN npm install
EXPOSE 3000
CMD [ "npm", "start" ]
————–
2- Byg billedet
$> podman build …
3- Logger ind på registreret
podman login …
4- Lægger billedet i registreret
podman push
5- Opretter yaml-filer til implementering af applikationen (deployment.yaml, service.yaml, ingress.yaml) – dette er det absolutte minimum
6- Implementerer manifest-filerne:
kubectl apply -f .
OpenShift / oc
$> oc new-app – navn_på_vores_applikation
OpenShift / odo
$> git clone
$> odo create component nodejs myapp
$> odo push
• Skifte kontekst: ændre navnerum eller arbejdsgruppe.
Kubernetes / kubectl
1- Opretter en kontekst i kubeconfig for projektet "myproject"
2- kubectl set-context …
OpenShift / oc
oc project "myproject"
Kvalitetskontrol: "Her er en interessant funktion, som lige nu er i alpha-version. Skal vi måske implementere den i produktion?"
Forestil dig, at du bliver placeret i en racerbilsæde og får at vide: "Vi har installeret bremsesystemer af en ny type, og ærligt talt, så er de ikke helt pålidelige endnu… Men bare rolig, vi vil arbejde aktivt med dem under hele mesterskabet." Hvordan ser det ud for dig? Hos Red Hat er vi ikke så trygge ved det. 🙂
Derfor forsøger vi at undgå alpha-versioner, indtil de er tilstrækkeligt modne, og vi har udført en grundig feltprøvning og føler os sikre på, at de kan anvendes sikkert. Normalt går alt først gennem en Dev Preview-fase, derefter gennem og først derefter frigives som en offentlig version (GA), som er stabil nok til at kunne anvendes i produktion.
Hvorfor det? Fordi, ligesom ved udviklingen af al anden software, når ikke alle de første idéer i Kubernetes frem til den endelige frigivelse. Eller de gør, og bevarer endda den planlagte funktionalitet, men deres implementering adskiller sig markant fra den, der var i alpha-versionen. Da tusindvis af Red Hat-kunder bruger OpenShift til at understøtte kritiske opgaver, lægger vi særlig vægt på stabiliteten af vores platform og langsigtet support.
Red Hat frigiver målrettet hyppige opdateringer af OpenShift og opdaterer den version af Kubernetes, der er en del af den. For eksempel er den nuværende GA-version af OpenShift 4.3, som jeg skriver denne artikel om, bygget på Kubernetes 1.16, som kun er ét nummer bag upstream-versionen af Kubernetes 1.17. På den måde forsøger vi at levere en enterprise-klasse Kubernetes til vores kunder og sikre en ekstra kvalitetskontrol i løbet af udgivelsen af nye versioner af OpenShift.
Programrettelser: "I den version af Kubernetes, vi har i produktion, er der blevet fundet en sårbarhed. Og den kan kun lukkes med en opdatering til tre versioner opad. Eller er der alternativer?"
I forbindelse med det åbne projekt Kubernetes frigives programrettelser normalt i den næste version, nogle gange dækker de en eller to tidligere mellemversioner, hvilket giver dækning for op til 6 måneder tilbage.
Red Hat er med rette stolt af at udsende kritiske rettelser før andre og tilbyder support i betydeligt længere tid. Tag for eksempel en sårbarhed med privilegietillæggelse i Kubernetes (): den blev opdaget i Kubernetes 1.11, og rettelser til tidligere versioner blev kun udgivet op til version 1.10.11, hvilket efterlod et hul i alle tidligere versioner af Kubernetes fra 1.x til 1.9.
På sin side (hvor Kubernetes 1.2 er installeret), og dækker ni versioner af OpenShift, hvilket tydeligt demonstrerer omsorg for kunderne (læs mere om ).
Hvordan OpenShift og Red Hat fremmer Kubernetes
Red Hat indtager den næststørste plads i forhold til softwarebidrag til det åbne Kubernetes-projekt, kun overgået af Google, og 3 ud af de 5 mest produktive udviklere er ansatte hos Red Hat. En anden lidt kendt kendsgerning: mange kritiske funktioner i Kubernetes blev faktisk introduceret af Red Hat, især som:
- RBAC. I Kubernetes blev der ikke introduceret RBAC-funktioner (ClusterRole, ClusterRoleBinding) før Red Hats ingeniører besluttede at implementere dem i selve platformen, og ikke som en ekstra funktionalitet i OpenShift. Frygter Red Hat at forbedre Kubernetes? Selvfølgelig ikke, for Red Hat følger strengt principperne for åbent kode og spiller ikke spil med Open Core. Forbedringer og innovationer, der implementeres i udviklingssamfundet snarere end på proprietær basis, bliver mere levedygtige og får bredere udbredelse, hvilket helt er i overensstemmelse med vores hovedmål – at gøre open source-software mere nyttig for vores kunder.
- Sikkerhedspolitikker for pods (Pod Security Policies). Oprindeligt blev denne koncept for sikker kørsel af applikationer inden for pods implementeret i OpenShift under navnet SCC (Security Context Constraints). Og ligesom i det forrige eksempel, besluttede Red Hat at introducere disse tiltag i det åbne Kubernetes-projekt, så alle interesserede kan dra nytte af dem.
Denne række eksempler kan fortsættes, men vi ville blot vise, at Red Hat faktisk stræber efter at udvikle Kubernetes og gøre det bedre for alle.
Det er klart, OpenShift er Kubernetes. Men hvad er forskellene? 🙂
Vi håber, at du nu har forstået, at Kubernetes er den primære komponent i OpenShift. Den er grundlæggende, men langt fra den eneste. Med andre ord, blot ved at installere Kubernetes får du ikke en virksomhedsklasseplatform. Du skal tilføje autentificering, netværk, sikkerhed, overvågning, logstyring og meget mere. Derudover skal du træffe et vanskeligt valg blandt de mange tilgængelige værktøjer (for at få et indtryk af mangfoldigheden i økosystemet, se blot ), og finde en måde at sikre konsistens og koordination, så de fungerer som en enhed. Derudover skal du regelmæssigt udføre opdateringer og regressionstest, når nye versioner af nogle af de anvendte komponenter frigives. Det vil sige, at du udover at oprette og vedligeholde selve platformen også skal håndtere al denne software. Der vil næppe være meget tid til at løse forretningsproblemer og opnå konkurrencefordele.
Men i tilfældet med OpenShift tager Red Hat sig af alle disse kompleksiteter og giver dig blot en funktionsdygtig og afsluttet platform, der ikke kun indeholder Kubernetes, men også et komplet sæt nødvendige open source-værktøjer, som omdanner Kubernetes til en reel virksomhedsløsning, som du straks og uden problemer kan sætte i produktion. Og selvfølgelig, hvis du har egne teknologiske stakke, kan du integrere OpenShift i de eksisterende løsninger.
Se på billedet ovenfor: Alt, hvad der ligger uden for Kubernetes-rektanglet, er de områder, hvor Red Hat tilføjer funktionalitet, som ikke findes i Kubernetes, såkaldt by-design. Og nu vil vi kigge nærmere på de vigtigste af disse områder.
1. Et pålideligt operativsystem som basis: RHEL CoreOS eller RHEL
Red Hat har i over 20 år været en førende leverandør af Linux-distributioner til kritiske forretningsapplikationer. Den opbygget og konstant opdaterede erfaring på dette område gør det muligt for os at tilbyde en virkelig pålidelig og betroet basis for industriel drift af containere. RHEL CoreOS bruger den samme kerne som RHEL, men er primært optimeret til opgaver som kørsel af containere og drift i Kubernetes-klynger: dens reducerede størrelse og immutabilitet forenkler oprettelsen af klynger, automatisk skalering, udrulning af opdateringer osv. Alle disse funktioner gør den til et ideelt fundament for at opnå den samme brugeroplevelse ved brug af OpenShift i forskellige beregningsmiljøer, fra 'bare metal' til private og offentlige cloud-løsninger.
2. Automatisering af IKT-operationer
Automatisering af installationsprocesser og operationer på den anden dag (dvs. den daglige drift) er et speciale for OpenShift, som væsentligt letter administrationen, opdateringen og vedligeholdelsen af containersystemet på det højeste niveau. Dette opnås gennem understøttelse af Kubernetes-operatorer på kernniveau i OpenShift 4.
OpenShift 4 er også et helt økosystem af løsninger baseret på Kubernetes-operatorer, der er udviklet af både Red Hat og tredjeparts partnere (se Red Hat, eller operatorbutikken , oprettet af Red Hat for tredjeparts udviklere).
Den integrerede katalog i OpenShift 4 indeholder over 180 Kubernetes-operatorer
3. Værktøjer til udviklere
Siden 2011 har OpenShift været tilgængelig som en PaaS (Platform-as-a-Service), der væsentligt forenkler livet for udviklere, hjælper dem med at fokusere på at skrive kode og tilbyder indbygget støtte til programmeringssprog som Java, Node.js, PHP, Ruby, Python, Go samt tjenester til kontinuerlig integration og levering CI/CD, databaser osv. OpenShift 4 tilbyder , der inkluderer over 100 tjenester baseret på Kubernetes-operatorer udviklet af Red Hat og vores partnere.
I modsætning til Kubernetes har OpenShift 4 en speciel grafisk brugerflade (), der hjælper udviklere med nemt at implementere applikationer fra forskellige kilder (git, eksterne registre, Dockerfile osv.) i deres navnerum og visuelt visualisere forbindelserne mellem applikationskomponenter.
Derudover tilbyder OpenShift et sæt udviklingsværktøjer kaldet Codeready, som blandt andet inkluderer , en fuldt containeriseret IDE med webgrænseflade, der arbejder direkte ovenpå OpenShift og implementerer tilgangen ‘IDE som en service’. På den anden side, for dem der ønsker at arbejde strengt i lokal tilstand, er der Codeready Containers – en fuldt funktionel version af OpenShift 4, som kan implementeres på en bærbar computer.
Integreret ‘IDE som en service’ til effektiv udvikling på Kubernetes/OpenShift-platformen.
Direkte fra kassen tilbyder OpenShift et komplet CI/CD-system, enten baseret på en containeriseret Jenkins og plugin til arbejde med pipelines, eller et Kubernetes-orienteret CI/CD-system (stadig i Tech preview-versionen). Begge løsninger er fuldt integreret med OpenShift-konsollen, hvilket muliggør at udløse pipeline, se deployment, logfiler osv.
4. Værktøjer til applikationer
OpenShift muliggør implementering af både traditionelle stateful-applikationer og skyorienterede løsninger baseret på nye arkitekturer, såsom mikroservices eller serverless. OpenShift Service Mesh-løsningen leveres direkte fra kassen med nøgleværktøjer til støtte for mikroservices som Istio, Kiali og Jaeger. I sin tur inkluderer OpenShift Serverless-løsningen ikke kun Knative, men også værktøjer udviklet i samarbejde med Microsoft, som Keda til at give Azure-funktioner på OpenShift-platformen.
Den integrerede OpenShift ServiceMesh-løsning (Istio, Kiali, Jaeger) vil være nyttig ved udvikling af mikroservices.
For at mindske kløften mellem arvet applikationer og containere tillader OpenShift nu migration af virtuelle maskiner til OpenShift-platformen ved hjælp af Container Native Virtualization (stadig i Tech Preview-version), hvilket gør hybride applikationer til en realitet og letter deres overførsel mellem forskellige skyer, både private og offentlige.
Windows 2019 Virtual, der kører på OpenShift via Container Native Virtualization (stadig i Tech Preview-version).
5. Værktøjer til klynger
Enhver virksomhedsklasseplatform skal have overvågnings- og centraliserede logningstjenester, sikkerhedsmekanismer, autentificering og autorisation samt netværksadministrationsværktøjer. Og OpenShift leverer alt dette lige ud af boksen, alt sammen med 100% åben kildekode, inklusive løsninger som ElasticSearch, Prometheus, Grafana. Alle disse løsninger leveres med dashboards, metrikker og alarmer, der allerede er konfigureret og tilpasset med Red Hats omfattende erfaring inden for clusterovervågning, hvilket gør det muligt at effektivt overvåge og spore din produktionsmiljø fra første minut.
OpenShift har også som standard vigtige funktioner for erhvervslivet, såsom autentificering med en indbygget OAuth-udbyder, integration med legitimationsudbydere, herunder LDAP, ActiveDirectory, OpenID Connect og meget mere.
Forudkonfigureret Grafana-dashboard til overvågning af OpenShift-clusteret
Over 150 forudkonfigurerede Prometheus-metrikker og alarmer til overvågning af OpenShift-clusteret
Fortsættes
Den rige funktionalitet af løsningen og Red Hats omfattende erfaring inden for Kubernetes er netop grundene til, at OpenShift har taget en dominerende position på markedet, som vist nedenfor (læs mere ).
„Red Hat fører i øjeblikket markedet med en andel på 44%.
Virksomheden høster frugterne af sin salgsstrategi med aktiv deltagelse i kundernes anliggender, hvor den først rådgiver og træner virksomhedens udviklere, og derefter går over til monetisering, efterhånden som virksomheden begynder at implementere containere i produktion."
(Kilde: )
Vi håber, at du kunne lide denne artikel. I de kommende indlæg i denne serie vil vi nærmere se på fordelene ved OpenShift sammenlignet med Kubernetes i hver af de kategorier, der er dækket her.
Kilde: habr.com
