"Hvad er forskellen mellem Kubernetes og OpenShift?" – dette spørgsmål opstår med misundelsesværdig konsekvens. Selvom det i virkeligheden er som at spørge, hvordan en bil adskiller sig fra en motor. Hvis vi fortsætter analogien, så er en bil et færdigt produkt, du kan bruge det med det samme, bogstaveligt talt: Kom ind og gå. For at en motor skal bringe dig et sted hen, skal den derimod først suppleres med en masse andre ting for i sidste ende at få den samme bil.
Derfor er Kubernetes motoren, som OpenShift-mærkebilen (platformen) er samlet omkring, som fører dig til dit mål.
I denne artikel vil vi minde dig om og undersøge følgende nøglepunkter lidt mere detaljeret:
- Kubernetes er hjertet i OpenShift-platformen, og det er 100% certificeret Kubernetes, fuldstændig open source og uden den mindste proprietære karakter. Kort:
- OpenShift cluster API er XNUMX % Kubernetes.
- Hvis containeren kører på et hvilket som helst andet Kubernetes-system, vil den køre på OpenShift uden ændringer. Det er ikke nødvendigt at foretage ændringer i applikationerne.
- OpenShift tilføjer ikke kun nyttige funktioner og funktionalitet til Kubernetes. Ligesom en bil er OpenShift ude af æsken, kan sættes i produktion med det samme, og som vi vil vise nedenfor, gør det en udviklers liv meget lettere. Derfor er OpenShift forenet i to personer. Det er både en succesfuld og velkendt PaaS-platform i virksomhedsklassen set fra et udviklerperspektiv. Og samtidig er det en super-pålidelig Container-as-a-Service-løsning set ud fra industriel drift.
OpenShift er Kubernetes med 100 % CNCF-certificering
OpenShift er baseret på . Derfor, efter ordentlig træning, bliver brugerne overrasket over kraften i kubectl. Og dem, der skiftede til OpenShift fra Kubernetes Cluster, siger ofte, hvor meget de virkelig kan lide, at efter at have omdirigeret kubeconfig til OpenShift-klyngen, fungerer alle eksisterende scripts fejlfrit.
Du har sikkert hørt om OpenShifts kommandolinjeværktøj kaldet OC. Det er fuldt kommandokompatibelt med kubectl, plus det tilbyder flere nyttige hjælpere, der vil være nyttige, når du udfører en række opgaver. Men først lidt mere om kompatibiliteten af OC og kubectl:
kubectl kommandoer
OC hold
kubectl få bælg
oc få bælg
kubectl få navnerum
oc få navnerum
kubectl oprette -f deployment.yaml
oc oprette -f deployment.yaml
Sådan ser resultaterne af brugen af kubectl på OpenShift API'et ud:
• kubectl get pods – returnerer pods som forventet.
• kubectl get navnerum – returnerer navnerum som forventet.
Kommandoen kubectl create -f mydeployment.yaml opretter kubernetes-ressourcer ligesom på enhver anden Kubernetes-platform, som vist i videoen nedenfor:
Med andre ord er alle Kubernetes API'er fuldt tilgængelige i OpenShift, mens de bevarer 100 % kompatibilitet. Det er derfor .
OpenShift tilføjer nyttige funktioner til Kubernetes
Kubernetes API'er er 100 % tilgængelige i OpenShift, men standard Kubernetes-værktøjet kubectl mangler tydeligvis funktionalitet og bekvemmelighed. Det er derfor, Red Hat har tilføjet nyttige funktioner og kommandolinjeværktøjer til Kubernetes, såsom OC (forkortelse for OpenShift-klient) og ODO (OpenShift DO, dette værktøj er rettet mod udviklere).
1. OC-værktøj - en mere kraftfuld og bekvem version af Kubectl
For eksempel, i modsætning til kubectl giver det dig mulighed for at oprette nye navnerum og nemt skifte kontekster, og det tilbyder også en række nyttige kommandoer til udviklere, såsom at bygge containerbilleder og implementere applikationer direkte fra kildekode eller binære filer (Kilde-til-billede, s2i).
Lad os se på eksempler på, hvordan OC-værktøjets indbyggede hjælpere og avancerede funktionalitet hjælper med at forenkle det daglige arbejde.
Det første eksempel er navneområdestyring. Hver Kubernetes-klynge har altid flere navnerum. De bruges normalt til at skabe udviklings- og produktionsmiljøer, men kan også bruges til fx at give hver udvikler en personlig sandkasse. I praksis resulterer dette i, at udvikleren ofte skal skifte mellem navneområder, da kubectl kører i sammenhæng med det aktuelle rum. Derfor, i tilfælde af kubectl, bruger folk aktivt hjælpescripts til dette. Men når du bruger OC, for at skifte til det ønskede rum, skal du bare sige "oc project namespace".
Kan du ikke huske, hvad det navneområde, du skal bruge, hedder? Intet problem, bare skriv "oc get projects" for at få vist hele listen. Skeptisk spekulerer på, hvordan dette vil fungere, hvis du kun har adgang til et begrænset undersæt af navnerum på klyngen? Nå, fordi kubectl kun gør dette korrekt, hvis RBAC tillader dig at se alle mellemrum på klyngen, og i store klynger er det ikke alle, der får sådanne tilladelser. Så vi svarer: for OC er dette overhovedet ikke et problem, og det vil nemt producere en komplet liste i en sådan situation. Det er disse små ting, der udgør Openshifts virksomhedsorientering og den gode skalerbarhed af denne platform med hensyn til brugere og applikationer
2. ODO - en forbedret version af kubectl til udviklere
Et andet eksempel på Red Hat OpenShifts forbedringer i forhold til Kubernetes er kommandolinjeværktøjet ODO. Det er designet til udviklere og giver dig mulighed for hurtigt at implementere lokal kode til en ekstern OpenShift-klynge. Det kan også strømline interne processer for øjeblikkeligt at synkronisere alle kodeændringer til containere på en ekstern OpenShift-klynge uden at skulle genopbygge, registrere og geninstallere billeder.
Lad os se på, hvordan OC og ODO gør arbejdet med containere og Kubernetes lettere.
Sammenlign blot et par arbejdsgange, når de er bygget på basis af kubectl, og når OC eller ODO bruges.
• Implementering af kode på OpenShift for dem, der ikke taler YAML:
Kubernetes/kubectl
$>git klon
1- Opret en Dockerfil, der bygger billedet ud fra kode
-----
FRA node
WORKDIR /usr/src/app
COPY-pakke*.json ./
COPY index.js ./
KOPI ./app ./app
KØR npm installation
UDSÆT 3000
CMD [ "npm", "start" ] ————–
2- Vi bygger billedet
$>podman build...
3- Log ind på registreringsdatabasen
podman login...
4- Placer billedet i registreringsdatabasen
podman skub
5- Opret yaml-filer til applikationsimplementering (deployment.yaml, service.yaml, ingress.yaml) - dette er det absolutte minimum
6- Implementer manifestfiler:
Kubectl anvende -f .
OpenShift/oc
$> oc ny-app – vores_applikationsnavn
OpenShift/odo
$>git klon
$> odo oprette komponent nodejs minapp
$>odo skub
• Kontekstskift: skift arbejdsnavneområde eller arbejdsklynge.
Kubernetes/kubectl
1- Opret en kontekst i kubeconfig for projektet "mitprojekt"
2- kubectl sæt-kontekst...
OpenShift/oc
oc projekt "mitprojekt"
Kvalitetskontrol: "En interessant funktion er dukket op her, stadig i alfaversion. Måske vi kan sætte den i produktion?”
Forestil dig at sidde i en racerbil og få at vide: "Vi har installeret en ny type bremser, og for at være ærlig er deres pålidelighed ikke i orden endnu... Men bare rolig, vi vil aktivt forbedre dem i løbet af kurset af mesterskabet." Hvordan kan du lide denne udsigt? Vi hos Red Hat er på en eller anden måde ikke særlig glade. 🙂
Derfor forsøger vi at holde ud med alfa-versioner, indtil de er tilstrækkeligt modne, og vi har lavet en grundig kamptest og føler, at de er sikre at bruge. Normalt går alt først gennem Dev Preview-stadiet og derefter igennem og først derefter udkommer som en offentlig udgivelse (GA), som allerede er så stabil, at den er velegnet til produktion.
Hvorfor det? For, som med udviklingen af enhver anden software, er det ikke alle indledende ideer i Kubernetes, der når den endelige udgivelse. Eller de når det og beholder endda den tilsigtede funktionalitet, men deres implementering er radikalt anderledes end i alfaversionen. Med tusinder og atter tusinder af Red Hat-kunder, der bruger OpenShift til at understøtte missionskritiske arbejdsbelastninger, lægger vi særlig vægt på stabiliteten af vores platform og langsigtet support.
Red Hat er forpligtet til at frigive OpenShift ofte og opdatere den version af Kubernetes, der følger med. For eksempel inkluderer den nuværende GA-udgivelse af OpenShift 4.3 på tidspunktet for dette skrivende Kubernetes 1.16, som kun er én enhed efter opstrømsversionen af Kubernetes nummereret 1.17. Derfor forsøger vi at give kunden Kubernetes i virksomhedsklasse og give yderligere kvalitetskontrol, efterhånden som vi udgiver nye versioner af OpenShift.
Softwarerettelser: "Der var et hul i den version af Kubernetes, som vi har i produktion. Og du kan kun lukke den ved at opdatere tre versioner. Eller er der nogle muligheder?
I Kubernetes open source-projektet frigives softwarerettelser normalt som en del af den næste udgivelse, nogle gange dækkende en eller to tidligere milepælsudgivelser, hvilket giver dækning så lidt som 6 måneder tilbage.
Red Hat er stolt af at frigive kritiske rettelser tidligere end andre og yde support i meget længere tid. Tag for eksempel Kubernetes-privilegieeskaleringssårbarheden (): det blev opdaget i Kubernetes 1.11, og rettelser til tidligere udgivelser blev kun udgivet op til version 1.10.11, hvilket efterlod denne i hullet i alle tidligere Kubernetes-udgivelser, fra 1.x til 1.9.
Til gengæld (Kubernetes 1.2 er der), fanger ni OpenShift-udgivelser og viser tydeligt omsorg for kunderne (flere detaljer ).
Hvordan OpenShift og Red Hat flytter Kubernetes fremad
Red Hat er den næststørste softwarebidragyder til open source Kubernetes-projektet, kun efter Google, hvor 3 af de 5 mest produktive udviklere kommer fra Red Hat. En anden lidet kendt kendsgerning: mange kritiske funktioner dukkede op i Kubernetes netop på initiativ af Red Hat, især, såsom:
- RBAC. Kubernetes havde ikke RBAC-funktioner (ClusterRole, ClusterRoleBinding), indtil Red Hat-ingeniører besluttede at implementere dem som en del af selve platformen og ikke som yderligere OpenShift-funktionalitet. Er Red Hat bange for at forbedre Kubernetes? Selvfølgelig ikke, for Red Hat følger strengt open source-principper og spiller ikke Open Core-spil. Forbedringer og innovationer, der er drevet af udviklingsfællesskaber, snarere end proprietære, er mere levedygtige og mere udbredte, hvilket stemmer godt overens med vores kernemål om at gøre open source-software mere nyttig for vores kunder.
- Sikkerhedspolitikker for pods (Pod Security Policies). Dette koncept med at køre applikationer sikkert inde i pods blev oprindeligt implementeret i OpenShift under navnet SCC (Security Context Constraints). Og som i det foregående eksempel besluttede Red Hat at introducere disse udviklinger i det åbne Kubernetes-projekt, så alle kunne bruge dem.
Denne serie af eksempler kunne fortsættes, men vi ville bare vise, at Red Hat virkelig er engageret i at udvikle Kubernetes og gøre det bedre for alle.
Det er klart, at OpenShift er Kubernetes. Hvad er forskellene? 🙂
Vi håber, at du ved at læse så langt har indset, at Kubernetes er kernekomponenten i OpenShift. Den vigtigste, men langt fra den eneste. Med andre ord, blot at installere Kubernetes vil ikke give dig en platform i virksomhedsklassen. Du skal tilføje godkendelse, netværk, sikkerhed, overvågning, logstyring og mere. Plus, du bliver nødt til at træffe nogle svære valg fra det store antal tilgængelige værktøjer (for at værdsætte mangfoldigheden af økosystemet, bare tag et kig ) og på en eller anden måde sikre sammenhæng og sammenhæng, så de fungerer som ét. Derudover skal du regelmæssigt udføre opdateringer og regressionstest, hver gang en ny version af nogen af de komponenter, du bruger, frigives. Det vil sige, at du udover at oprette og vedligeholde selve platformen også skal håndtere al denne software. Det er usandsynligt, at der vil være meget tid tilbage til at løse forretningsproblemer og opnå konkurrencefordele.
Men i tilfældet med OpenShift, tager Red Hat alle disse kompleksiteter på sig og giver dig simpelthen en funktionelt komplet platform, som ikke kun inkluderer Kubernetes selv, men også hele sæt nødvendige open source-værktøjer, der gør Kubernetes til en rigtig virksomhedsklasse løsning, som du straks og helt roligt kan sætte i produktion. Og selvfølgelig, hvis du har nogle af dine egne teknologistakke, så kan du integrere OpenShift i eksisterende løsninger.
Tag et kig på billedet ovenfor: alt, hvad der er uden for Kubernetes-rektanglet, er der, hvor Red Hat tilføjer funktionalitet, som Kubernetes ikke har, som de siger, by-design. Og nu vil vi se på de vigtigste af disse områder.
1. Robust OS som base: RHEL CoreOS eller RHEL
Red Hat har været en førende leverandør af Linux-distributioner til forretningskritiske applikationer i mere end 20 år. Vores akkumulerede og konstant opdaterede erfaring på dette område giver os mulighed for at tilbyde et virkelig pålideligt og pålideligt grundlag for industriel drift af containere. RHEL CoreOS bruger den samme kerne som RHEL, men er primært optimeret til opgaver som at køre containere og køre Kubernetes-klynger: dens reducerede størrelse og uforanderlighed gør det nemmere at opsætte klynger, autoskalering, implementering af patches osv. Alle disse funktioner gør det et ideelt grundlag for at levere den samme brugeroplevelse med OpenShift på tværs af en bred vifte af computermiljøer, fra bare metal til privat og offentlig cloud.
2. Automatisering af IT-drift
Automatisering af installationsprocesser og dag-4 operationer (det vil sige den daglige drift) er OpenShifts stærke side, hvilket gør det meget nemmere at administrere, opdatere og vedligeholde containerplatformens ydeevne på højeste niveau. Dette opnås gennem understøttelse af Kubernetes-operatører på OpenShift XNUMX-kerneniveau.
OpenShift 4 er også et helt økosystem af løsninger baseret på Kubernetes-operatører, udviklet både af Red Hat selv og af tredjepartspartnere (se. Red Hat, eller operatørbutik , skabt af Red Hat til tredjepartsudviklere).
Det integrerede OpenShift 4-katalog omfatter mere end 180 Kubernetes-operatører
3. Udviklerværktøjer
Siden 2011 har OpenShift været tilgængelig som en PaaS (Platform-as-a-Service) platform, der gør livet meget nemmere for udviklere, hjælper dem med at fokusere på kodning og tilbyder native support til programmeringssprog som Java, Node.js , PHP, Ruby, Python, Go, samt CI/CD kontinuerlig integration og leveringstjenester, databaser osv. OpenShift 4 tilbyder , som omfatter mere end 100 tjenester baseret på Kubernetes-operatører udviklet af Red Hat og vores partnere.
I modsætning til Kubernetes har OpenShift 4 en dedikeret GUI (), som hjælper udviklere med ubesværet at implementere applikationer fra forskellige kilder (git, eksterne registre, Dockerfile osv.) i deres navnerum og tydeligt visualiserer relationerne mellem applikationskomponenter.
Derudover tilbyder OpenShift et sæt Codeready-udviklingsværktøjer, som især omfatter , en fuldt containeriseret IDE med en webgrænseflade, der kører direkte oven på OpenShift og implementerer en IDE-as-a-service tilgang. 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, der kan implementeres på en bærbar computer.
Integreret IDE som en service til effektiv udvikling på Kubernetes/OpenShift platformen
OpenShift tilbyder et komplet CI/CD-system lige ud af æsken, enten baseret på containeriserede Jenkins og et plugin til arbejde med pipelines eller et Kubernetes-orienteret CI/CD-system (i øjeblikket i Tech preview-version). Begge disse løsninger integreres fuldt ud med OpenShift-konsollen, så du kan køre pipeline-triggere, se implementeringer, logfiler og mere.
4. Applikationsværktøjer
OpenShift giver dig mulighed for at implementere både traditionelle stateful-applikationer og cloud-baserede løsninger baseret på nye arkitekturer, såsom mikrotjenester eller serverløse. OpenShift Service Mesh-løsningen kommer lige ud af kassen med nøgleværktøjer til vedligeholdelse af mikrotjenester, såsom Istio, Kiali og Jaeger. Til gengæld inkluderer OpenShift Serverless-løsningen ikke kun Knative, men også værktøjer som Keda skabt som en del af et fælles initiativ med Microsoft for at levere Azure-funktioner på OpenShift-platformen.
Den integrerede løsning OpenShift ServiceMesh (Istio, Kiali, Jaeger) vil være nyttig ved udvikling af mikrotjenester
For at bygge bro mellem ældre applikationer og containere tillader OpenShift nu virtuel maskinmigrering til OpenShift-platformen ved hjælp af Container Native Virtualization (i øjeblikket i TechPreview), hvilket gør hybridapplikationer til en realitet og letter deres migrering mellem forskellige skyer, både private og offentlige.
Windows 2019 Virtuel virtuel maskine, der kører på OpenShift via Container Native Virtualization (aktuelt i Tech preview-version)
5. Værktøjer til klynger
Enhver platform i virksomhedsklassen skal have overvågnings- og centraliserede logningstjenester, sikkerhedsmekanismer, autentificering og autorisation samt netværksadministrationsværktøjer. Og OpenShift leverer alt dette ud af boksen, og det hele er 100 % open source, inklusive løsninger som ElasticSearch, Prometheus, Grafana. Alle disse løsninger kommer med dashboards, målinger og advarsler, der allerede er bygget og konfigureret ved hjælp af Red Hats omfattende klyngeovervågningsekspertise, hvilket giver dig mulighed for effektivt at kontrollere og overvåge dit produktionsmiljø lige fra starten.
OpenShift kommer også som standard med så vigtige ting for virksomhedskunder som autentificering med en indbygget oauth-udbyder, integration med legitimationsudbydere, herunder LDAP, ActiveDirectory, OpenID Connect og meget mere.
Forudkonfigureret Grafana-dashboard til OpenShift-klyngeovervågning
Over 150 forudkonfigurerede Prometheus-målinger og alarmer til OpenShift-klyngeovervågning
Fortsættes
Løsningens rige funktionalitet og Red Hats store erfaring inden for Kubernetes er årsagerne til, at OpenShift har opnået en dominerende position på markedet, som vist i nedenstående figur (læs mere ).
"Red Hat er i øjeblikket førende på markedet med en andel på 44%.
Virksomheden høster fordelene af sin kundecentrerede salgsstrategi, hvor den først konsulterer og træner virksomhedsudviklere og derefter går over til indtægtsgenerering, efterhånden som virksomheden begynder at implementere containere i produktion.”
(Kilde: )
Vi håber, du nød denne artikel. I fremtidige indlæg i denne serie vil vi se nærmere på fordelene ved OpenShift frem for Kubernetes i hver af de kategorier, der diskuteres her.
Kilde: www.habr.com