"Hva er forskjellen mellom Kubernetes og OpenShift?" – Dette spørsmålet dukker opp med misunnelsesverdig konsistens. Selv om dette i virkeligheten er som å spørre hvordan en bil skiller seg fra en motor. Hvis vi fortsetter analogien, så er en bil et ferdig produkt, du kan bruke den med en gang, bokstavelig talt: gå inn og gå. På den annen side, for at en motor skal ta deg et sted, må den først suppleres med mye annet for til slutt å få samme bil.
Derfor er Kubernetes motoren som OpenShift-merkets bil (plattform) er satt sammen, som tar deg til målet ditt.
I denne artikkelen ønsker vi å minne deg på og undersøke følgende nøkkelpunkter litt mer detaljert:
- Kubernetes er hjertet av OpenShift-plattformen og den er 100 % sertifisert Kubernetes, helt åpen kildekode og uten den minste proprietære natur. Kort:
- OpenShift cluster API er XNUMX % Kubernetes.
- Hvis beholderen kjører på et annet Kubernetes-system, vil den kjøre på OpenShift uten endringer. Det er ikke nødvendig å gjøre endringer i applikasjonene.
- OpenShift legger ikke bare nyttige funksjoner og funksjonalitet til Kubernetes. Som en bil er OpenShift ute av esken, kan settes i produksjon umiddelbart, og som vi viser nedenfor, gjør livet til en utvikler mye enklere. Derfor er OpenShift forent i to personer. Det er både en vellykket og velkjent PaaS-plattform i bedriftsklassen fra et utviklerperspektiv. Og samtidig er det en superpålitelig Container-as-a-Service-løsning med tanke på industriell drift.
OpenShift er Kubernetes med 100 % CNCF-sertifisering
OpenShift er basert på . Derfor, etter riktig opplæring, blir brukerne overrasket over kraften til kubectl. Og de som byttet til OpenShift fra Kubernetes Cluster sier ofte hvor mye de virkelig liker det etter å ha omdirigert kubeconfig til OpenShift-klyngen, alle eksisterende skript fungerer feilfritt.
Du har sikkert hørt om OpenShifts kommandolinjeverktøy kalt OC. Den er fullstendig kommandokompatibel med kubectl, pluss at den tilbyr flere nyttige hjelpere som vil komme godt med når du utfører en rekke oppgaver. Men først, litt mer om kompatibiliteten til OC og kubectl:
kubectl kommandoer
OC-lag
kubectl få pods
oc få poder
kubectl får navneområder
oc få navneområder
kubectl opprette -f deployment.yaml
oc opprette -f deployment.yaml
Slik ser resultatene av bruk av kubectl på OpenShift API ut:
• kubectl get pods – returnerer pods som forventet.
• kubectl get navnerom – returnerer navnerom som forventet.
Kommandoen kubectl create -f mydeployment.yaml oppretter kubernetes-ressurser akkurat som på alle andre Kubernetes-plattformer, som vist i videoen nedenfor:
Med andre ord, alle Kubernetes APIer er fullt tilgjengelige i OpenShift samtidig som de opprettholder 100 % kompatibilitet. Det er hvorfor .
OpenShift legger til nyttige funksjoner til Kubernetes
Kubernetes API-er er 100 % tilgjengelige i OpenShift, men standard Kubernetes-verktøyet kubectl mangler tydeligvis funksjonalitet og bekvemmelighet. Det er derfor Red Hat har lagt til nyttige funksjoner og kommandolinjeverktøy til Kubernetes, slik som OC (forkortelse for OpenShift-klient) og ODO (OpenShift DO, dette verktøyet er rettet mot utviklere).
1. OC-verktøy - en kraftigere og mer praktisk versjon av Kubectl
For eksempel, i motsetning til kubectl, lar den deg lage nye navnerom og enkelt bytte kontekster, og tilbyr også en rekke nyttige kommandoer for utviklere, for eksempel å bygge containerbilder og distribuere applikasjoner direkte fra kildekode eller binærfiler (Kilde-til-bilde, s2i).
La oss se på eksempler på hvordan de innebygde hjelperne og den avanserte funksjonaliteten til OC-verktøyet bidrar til å forenkle arbeidshverdagen.
Det første eksemplet er navneområdeadministrasjon. Hver Kubernetes-klynge har alltid flere navneområder. De brukes vanligvis til å lage utviklings- og produksjonsmiljøer, men kan også brukes til for eksempel å gi hver utvikler en personlig sandkasse. I praksis resulterer dette i at utvikleren ofte må bytte mellom navneområder, siden kubectl kjører i konteksten til det aktuelle rommet. Derfor, når det gjelder kubectl, bruker folk aktivt hjelpeskript for dette. Men når du bruker OC, for å bytte til ønsket plass, si bare "oc project namespace".
Husker du ikke hva navneområdet du trenger heter? Ikke noe problem, bare skriv "oc get projects" for å vise hele listen. Lurer skeptisk på hvordan dette vil fungere hvis du bare har tilgang til et begrenset delsett av navnerom på klyngen? Vel, fordi kubectl bare gjør dette riktig hvis RBAC lar deg se alle plassene på klyngen, og i store klynger er ikke alle gitt slike tillatelser. Så vi svarer: for OC er ikke dette et problem i det hele tatt, og det vil lett produsere en komplett liste i en slik situasjon. Det er disse små tingene som utgjør bedriftsorienteringen til Openshift og den gode skalerbarheten til denne plattformen når det gjelder brukere og applikasjoner
2. ODO - en forbedret versjon av kubectl for utviklere
Et annet eksempel på Red Hat OpenShifts forbedringer i forhold til Kubernetes er kommandolinjeverktøyet ODO. Den er designet for utviklere og lar deg raskt distribuere lokal kode til en ekstern OpenShift-klynge. Det kan også strømlinjeforme interne prosesser for å umiddelbart synkronisere alle kodeendringer til containere på en ekstern OpenShift-klynge uten å måtte bygge om, registrere og omdistribuere bilder.
La oss se på hvordan OC og ODO gjør arbeidet med containere og Kubernetes enklere.
Bare sammenlign et par arbeidsflyter når de er bygget på grunnlag av kubectl, og når OC eller ODO brukes.
• Utplassering av kode på OpenShift for de som ikke snakker YAML:
Kubernetes/kubectl
$>git klone
1- Lag en Dockerfil som bygger bildet fra kode
-----
FRA node
WORKDIR /usr/src/app
COPY-pakke*.json ./
COPY index.js ./
KOPI ./app ./app
KJØR npm installasjon
UTSTILL 3000
CMD [ "npm", "start" ] ————–
2- Vi bygger bildet
$>podman build...
3- Logg på registeret
podman pålogging...
4- Plasser bildet i registeret
podman push
5- Lag yaml-filer for applikasjonsdistribusjon (deployment.yaml, service.yaml, ingress.yaml) - dette er det absolutte minimum
6- Distribuer manifestfiler:
Kubectl anvende -f .
OpenShift/oc
$> oc ny-app – vårt_applikasjonsnavn
OpenShift/odo
$>git klone
$> odo opprette komponent nodejs myapp
$>odo push
• Kontekstbryter: endre arbeidsnavneområde eller arbeidsklynge.
Kubernetes/kubectl
1- Lag en kontekst i kubeconfig for prosjektet "mittprosjekt"
2- kubectl sett-kontekst...
OpenShift/oc
oc-prosjektet "mittprosjekt"
Kvalitetskontroll: «En interessant funksjon har dukket opp her, fortsatt i alfaversjon. Kanskje vi kan sette den i produksjon?»
Tenk deg å sitte i en racerbil og bli fortalt: «Vi har installert en ny type bremser, og for å være ærlig er påliteligheten deres ikke i orden ennå... Men ikke bekymre deg, vi vil aktivt forbedre dem i løpet av kurset av mesterskapet." Hvordan liker du dette prospektet? Vi i Red Hat er liksom ikke særlig fornøyde. 🙂
Derfor prøver vi å holde ut alfaversjoner til de er tilstrekkelig modne og vi har gjort grundige kamptestinger og føler at de er trygge å bruke. Vanligvis går alt gjennom Dev Preview-stadiet først, deretter gjennom og først da kommer ut som en offentlig utgivelse (GA), som allerede er så stabil at den egner seg for produksjon.
Hvorfor det? For, som med utviklingen av all annen programvare, når ikke alle innledende ideer i Kubernetes den endelige utgivelsen. Eller de når det og beholder til og med den tiltenkte funksjonaliteten, men implementeringen deres er radikalt forskjellig fra den i alfaversjonen. Med tusener på tusener av Red Hat-kunder som bruker OpenShift for å støtte oppdragskritiske arbeidsbelastninger, legger vi spesiell vekt på stabiliteten til plattformen vår og langsiktig støtte.
Red Hat er forpliktet til å gi ut OpenShift ofte og oppdatere versjonen av Kubernetes som følger med. For eksempel inkluderer den nåværende GA-utgivelsen av OpenShift 4.3 i skrivende stund Kubernetes 1.16, som bare er én enhet bak oppstrømsversjonen av Kubernetes nummerert 1.17. Derfor prøver vi å gi kunden Kubernetes i bedriftsklassen og gi ytterligere kvalitetskontroll under utgivelsen av nye versjoner av OpenShift.
Programvarerettinger: «Det var et hull i versjonen av Kubernetes som vi har i produksjon. Og du kan bare lukke den ved å oppdatere tre versjoner. Eller er det noen alternativer?
I Kubernetes åpen kildekode-prosjekt utgis programvarefikser vanligvis som en del av neste utgivelse, noen ganger dekker en eller to tidligere milepælutgivelser, og gir dekning tilbake så lite som 6 måneder.
Red Hat er stolt av å gi ut kritiske rettelser tidligere enn andre og gi støtte mye lenger. Ta for eksempel Kubernetes privilegieeskaleringssårbarhet (): den ble oppdaget i Kubernetes 1.11, og rettelser for tidligere utgivelser ble kun utgitt opp til versjon 1.10.11, og la denne i hullet i alle tidligere Kubernetes-utgivelser, fra 1.x til 1.9.
I sin tur, (Kubernetes 1.2 er der), fanger ni OpenShift-utgivelser og viser tydelig omsorg for kundene (mer detaljer ).
Hvordan OpenShift og Red Hat beveger Kubernetes fremover
Red Hat er den nest største programvarebidragsyteren til Kubernetes-prosjektet med åpen kildekode, kun bak Google, med 3 av de 5 mest produktive utviklerne fra Red Hat. Et annet lite kjent faktum: mange kritiske funksjoner dukket opp i Kubernetes nettopp på initiativ fra Red Hat, spesielt, for eksempel:
- RBAC. Kubernetes hadde ikke RBAC-funksjoner (ClusterRole, ClusterRoleBinding) før Red Hat-ingeniører bestemte seg for å implementere dem som en del av selve plattformen, og ikke som ekstra OpenShift-funksjonalitet. Er Red Hat redd for å forbedre Kubernetes? Selvfølgelig ikke, fordi Red Hat følger strengt åpen kildekode-prinsipper og spiller ikke Open Core-spill. Forbedringer og innovasjoner som er drevet av utviklingssamfunn, snarere enn proprietære, er mer levedyktige og mer utbredt, noe som stemmer godt overens med vårt kjernemål om å gjøre åpen kildekode-programvare mer nyttig for kundene våre.
- Sikkerhetspolicyer for pods (Pod Security Policies). Dette konseptet med å kjøre applikasjoner sikkert inne i pods ble opprinnelig implementert i OpenShift under navnet SCC (Security Context Constraints). Og som i forrige eksempel, bestemte Red Hat seg for å introdusere disse utviklingene i det åpne Kubernetes-prosjektet slik at alle kunne bruke dem.
Denne serien med eksempler kan fortsette, men vi ville bare vise at Red Hat virkelig er forpliktet til å utvikle Kubernetes og gjøre det bedre for alle.
Det er tydelig at OpenShift er Kubernetes. Hva er forskjellene? 🙂
Vi håper at du ved å lese så langt har innsett at Kubernetes er kjernekomponenten i OpenShift. Den viktigste, men langt fra den eneste. Med andre ord, bare å installere Kubernetes vil ikke gi deg en plattform i bedriftsklassen. Du må legge til autentisering, nettverk, sikkerhet, overvåking, loggadministrasjon og mer. I tillegg må du ta noen tøffe valg fra det store antallet verktøy som er tilgjengelig (for å sette pris på mangfoldet i økosystemet, bare ta en titt ) og på en eller annen måte sikre konsistens og sammenheng slik at de fungerer som ett. I tillegg må du regelmessig utføre oppdateringer og regresjonstesting hver gang en ny versjon av noen av komponentene du bruker utgis. Det vil si at i tillegg til å lage og vedlikeholde selve plattformen, må du også forholde deg til all denne programvaren. Det er usannsynlig at det vil være mye tid igjen til å løse forretningsproblemer og oppnå konkurransefortrinn.
Men når det gjelder OpenShift, tar Red Hat alle disse kompleksitetene på seg og gir deg ganske enkelt en funksjonelt komplett plattform, som ikke bare inkluderer Kubernetes selv, men også hele settet med nødvendige åpen kildekodeverktøy som gjør Kubernetes til en ekte bedriftsklasse løsning som du umiddelbart og helt rolig kan sette i produksjon. Og selvfølgelig, hvis du har noen av dine egne teknologistabler, kan du integrere OpenShift i eksisterende løsninger.
Ta en titt på bildet over: alt som er utenfor Kubernetes-rektangelet er der Red Hat legger til funksjonalitet som Kubernetes ikke har, som de sier, by-design. Og nå skal vi se på hoveddelen av disse områdene.
1. Robust OS som base: RHEL CoreOS eller RHEL
Red Hat har vært en ledende leverandør av Linux-distribusjoner for forretningskritiske applikasjoner i mer enn 20 år. Vår akkumulerte og stadig oppdaterte erfaring på dette området gjør at vi kan tilby et virkelig pålitelig og pålitelig grunnlag for industriell drift av containere. RHEL CoreOS bruker samme kjerne som RHEL, men er optimalisert primært for oppgaver som å kjøre containere og kjøre Kubernetes-klynger: dens reduserte størrelse og uforanderlighet gjør det enklere å sette opp klynger, autoskalering, distribuere patcher osv. Alle disse funksjonene gjør det enklere å sette opp klynger. et ideelt grunnlag for å levere den samme brukeropplevelsen med OpenShift på tvers av et bredt spekter av datamiljøer, fra bare metall til privat og offentlig sky.
2. Automatisering av IT-drift
Automatisering av installasjonsprosesser og dag-4 operasjoner (det vil si daglig drift) er OpenShifts sterke side, noe som gjør det mye enklere å administrere, oppdatere og vedlikeholde ytelsen til containerplattformen på høyeste nivå. Dette oppnås gjennom støtte for Kubernetes-operatører på OpenShift XNUMX-kjernenivå.
OpenShift 4 er også et helt økosystem av løsninger basert på Kubernetes-operatører, utviklet både av Red Hat selv og av tredjepartspartnere (se. Red Hat, eller operatørbutikk , laget av Red Hat for tredjepartsutviklere).
Den integrerte OpenShift 4-katalogen inkluderer mer enn 180 Kubernetes-operatører
3. Utviklerverktøy
Siden 2011 har OpenShift vært tilgjengelig som en PaaS (Platform-as-a-Service)-plattform som gjør livet mye enklere for utviklere, hjelper dem med å fokusere på koding og tilbyr innebygd støtte for programmeringsspråk som Java, Node.js , PHP, Ruby, Python, Go, samt CI/CD kontinuerlig integrasjon og leveringstjenester, databaser osv. OpenShift 4 tilbyr , som inkluderer mer enn 100 tjenester basert på Kubernetes-operatører utviklet av Red Hat og våre partnere.
I motsetning til Kubernetes, har OpenShift 4 en dedikert GUI (), som hjelper utviklere uten problemer med å distribuere applikasjoner fra ulike kilder (git, eksterne registre, Dockerfile, etc.) i navneområdene og tydelig visualiserer relasjonene mellom applikasjonskomponenter.
I tillegg tilbyr OpenShift et sett med Codeready-utviklingsverktøy, som spesielt inkluderer , en fullstendig containerisert IDE med et nettgrensesnitt som kjører direkte på toppen av OpenShift og implementerer en IDE-som-en-tjeneste-tilnærming. På den annen side, for de som ønsker å jobbe strengt i lokal modus, er det Codeready Containers, en fullt funksjonell versjon av OpenShift 4 som kan distribueres på en bærbar datamaskin.
Integrert IDE som en tjeneste for effektiv utvikling på Kubernetes/OpenShift-plattformen
OpenShift tilbyr et komplett CI/CD-system rett ut av esken, enten basert på containeriserte Jenkins og en plugin for arbeid med rørledninger, eller et Kubernetes-orientert CI/CD-system (for øyeblikket i Tech forhåndsversjon). Begge disse løsningene integreres fullt ut med OpenShift-konsollen, slik at du kan kjøre pipeline-utløsere, se distribusjoner, logger og mer.
4. Applikasjonsverktøy
OpenShift lar deg distribuere både tradisjonelle stateful-applikasjoner og skybaserte løsninger basert på nye arkitekturer, for eksempel mikrotjenester eller serverløse. OpenShift Service Mesh-løsningen kommer rett ut av esken med nøkkelverktøy for vedlikehold av mikrotjenester, som Istio, Kiali og Jaeger. I sin tur inkluderer OpenShift Serverless-løsningen ikke bare Knative, men også verktøy som Keda laget som en del av et felles initiativ med Microsoft for å tilby Azure-funksjoner på OpenShift-plattformen.
Den integrerte løsningen OpenShift ServiceMesh (Istio, Kiali, Jaeger) vil være nyttig ved utvikling av mikrotjenester
For å bygge bro mellom eldre applikasjoner og beholdere, tillater OpenShift nå virtuell maskinmigrering til OpenShift-plattformen ved å bruke Container Native Virtualization (for øyeblikket i TechPreview), noe som gjør hybridapplikasjoner til en realitet og letter deres migrering mellom forskjellige skyer, både private og offentlige.
Virtuell virtuell maskin for Windows 2019 som kjører på OpenShift via Container Native Virtualization (for øyeblikket i Tech forhåndsversjon)
5. Verktøy for klynger
Enhver plattform i bedriftsklassen må ha overvåking og sentraliserte loggingstjenester, sikkerhetsmekanismer, autentisering og autorisasjon og nettverksadministrasjonsverktøy. Og OpenShift gir alt dette rett ut av boksen, og det hele er 100 % åpen kildekode, inkludert løsninger som ElasticSearch, Prometheus, Grafana. Alle disse løsningene kommer med dashbord, beregninger og varsler som allerede er bygget og konfigurert ved hjelp av Red Hats omfattende klyngeovervåkingsekspertise, slik at du effektivt kan kontrollere og overvåke produksjonsmiljøet ditt helt fra starten.
OpenShift kommer også som standard med så viktige ting for bedriftskunder som autentisering med en innebygd oauth-leverandør, integrasjon med legitimasjonsleverandører, inkludert LDAP, ActiveDirectory, OpenID Connect og mye mer.
Forhåndskonfigurert Grafana-dashbord for OpenShift-klyngeovervåking
Over 150 forhåndskonfigurerte Prometheus-beregninger og varsler for OpenShift-klyngeovervåking
Skal videreføres
Løsningens rike funksjonalitet og Red Hats omfattende erfaring innen Kubernetes er årsakene til at OpenShift har oppnådd en dominerende posisjon i markedet, som vist i figuren under (les mer ).
"Red Hat leder for tiden markedet med en andel på 44 %.
Selskapet høster fordelene av sin kundesentrerte salgsstrategi, der det først konsulterer og trener bedriftsutviklere og deretter går over til inntektsgenerering etter hvert som bedriften begynner å distribuere containere i produksjon.»
(Kilde: )
Vi håper du likte denne artikkelen. I fremtidige innlegg i denne serien skal vi se nærmere på fordelene med OpenShift fremfor Kubernetes i hver av kategoriene som diskuteres her.
Kilde: www.habr.com