"Ano ang pagkakaiba sa pagitan ng Kubernetes at OpenShift?" - ang tanong na ito ay lumitaw nang may nakakainggit na pagkakapare-pareho. Bagaman sa katotohanan ito ay tulad ng pagtatanong kung paano naiiba ang isang kotse sa isang makina. Kung ipagpapatuloy namin ang pagkakatulad, kung gayon ang isang kotse ay isang tapos na produkto, maaari mo itong gamitin kaagad, literal: pumasok at pumunta. Sa kabilang banda, para madala ka ng isang makina sa isang lugar, kailangan muna itong dagdagan ng maraming iba pang bagay upang sa huli ay makuha ang parehong sasakyan.
Samakatuwid, ang Kubernetes ay ang makina kung saan naka-assemble ang OpenShift brand car (platform), na magdadala sa iyo sa iyong layunin.
Sa artikulong ito, nais naming ipaalala sa iyo at suriin ang mga sumusunod na pangunahing punto nang mas detalyado:
- Ang Kubernetes ay ang puso ng OpenShift platform at ito ay 100% certified Kubernetes, ganap na open source at walang kaunting pagmamay-ari. Sa madaling sabi:
- Ang OpenShift cluster API ay 100% Kubernetes.
- Kung tumatakbo ang container sa anumang iba pang sistema ng Kubernetes, tatakbo ito sa OpenShift nang walang anumang pagbabago. Hindi na kailangang gumawa ng mga pagbabago sa mga application.
- Hindi lamang nagdaragdag ang OpenShift ng mga kapaki-pakinabang na feature at functionality sa Kubernetes. Tulad ng isang kotse, ang OpenShift ay wala sa kahon, maaaring ilagay sa produksyon kaagad, at, tulad ng ipapakita namin sa ibaba, ginagawang mas madali ang buhay ng isang developer. Iyon ang dahilan kung bakit ang OpenShift ay pinagsama sa dalawang tao. Ito ay parehong matagumpay at kilalang enterprise-class na platform ng PaaS mula sa pananaw ng isang developer. At sa parehong oras, ito ay isang napaka-maaasahang solusyon sa Container-as-a-Service mula sa punto ng view ng pang-industriyang operasyon.
Ang OpenShift ay Kubernetes na may 100% na sertipikasyon ng CNCF
Nakabatay ang OpenShift sa . Samakatuwid, pagkatapos ng wastong pagsasanay, ang mga gumagamit ay namangha sa kapangyarihan ng kubectl. At ang mga lumipat sa OpenShift mula sa Kubernetes Cluster ay madalas na nagsasabi kung gaano nila iyon kagusto pagkatapos i-redirect ang kubeconfig sa OpenShift cluster, lahat ng umiiral na mga script ay gumagana nang walang kamali-mali.
Marahil ay narinig mo na ang tungkol sa command line utility ng OpenShift na tinatawag na OC. Ito ay ganap na tugma sa command sa kubectl, at nag-aalok ito ng ilang mga kapaki-pakinabang na katulong na magiging kapaki-pakinabang kapag gumaganap ng ilang mga gawain. Ngunit una, kaunti pa tungkol sa pagiging tugma ng OC at kubectl:
mga utos ng kubectl
Mga OC Team
kumuha ng mga pod ang kubectl
oc kumuha ng pods
kubectl kumuha ng mga namespace
oc kumuha ng mga namespace
kubectl create -f deployment.yaml
oc lumikha -f deployment.yaml
Narito kung ano ang hitsura ng mga resulta ng paggamit ng kubectl sa OpenShift API:
• kubectl makakuha ng mga pod – nagbabalik ng mga pod gaya ng inaasahan.
• kubectl kumuha ng mga namespace – nagbabalik ng mga namespace gaya ng inaasahan.
Ang command na kubectl create -f mydeployment.yaml ay lumilikha ng mga mapagkukunan ng kubernetes tulad ng sa anumang iba pang platform ng Kubernetes, tulad ng ipinapakita sa video sa ibaba:
Sa madaling salita, ang lahat ng Kubernetes API ay ganap na magagamit sa OpenShift habang pinapanatili ang 100% compatibility. Kaya naman .
Nagdaragdag ang OpenShift ng mga kapaki-pakinabang na feature sa Kubernetes
Ang mga Kubernetes API ay 100% available sa OpenShift, ngunit ang karaniwang Kubernetes utility na kubectl ay malinaw na walang functionality at convenience. Iyon ang dahilan kung bakit nagdagdag ang Red Hat ng mga kapaki-pakinabang na feature at command line tool sa Kubernetes, gaya ng OC (maikli para sa OpenShift client) at ODO (OpenShift DO, ang utility na ito ay nakatuon sa mga developer).
1. OC utility - isang mas malakas at maginhawang bersyon ng Kubectl
Halimbawa, hindi tulad ng kubectl, binibigyang-daan ka nitong lumikha ng mga bagong namespace at madaling lumipat ng konteksto, at nag-aalok din ng ilang kapaki-pakinabang na command para sa mga developer, tulad ng pagbuo ng mga imahe ng container at pag-deploy ng mga application nang direkta mula sa source code o binary (Source-to-image, s2i).
Tingnan natin ang mga halimbawa kung paano nakakatulong ang mga built-in na katulong at advanced na functionality ng OC utility na gawing simple ang pang-araw-araw na gawain.
Ang unang halimbawa ay pamamahala ng namespace. Ang bawat cluster ng Kubernetes ay palaging may maraming namespace. Karaniwang ginagamit ang mga ito upang lumikha ng mga kapaligiran sa pag-unlad at produksyon, ngunit maaari ding gamitin upang, halimbawa, bigyan ang bawat developer ng personal na sandbox. Sa pagsasagawa, nagreresulta ito sa madalas na paglipat ng developer sa pagitan ng mga namespace, dahil tumatakbo ang kubectl sa konteksto ng kasalukuyang espasyo. Samakatuwid, sa kaso ng kubectl, aktibong gumagamit ng helper script ang mga tao para dito. Ngunit kapag gumagamit ng OC, upang lumipat sa nais na espasyo, sabihin lamang ang "oc project namespace".
Hindi mo naaalala kung ano ang tawag sa namespace na kailangan mo? Walang problema, i-type lang ang "oc get projects" para ipakita ang buong listahan. Nag-aalinlangan kung paano ito gagana kung mayroon ka lamang access sa isang limitadong subset ng mga namespace sa cluster? Well, dahil ginagawa lang ito ng kubectl nang tama kung pinapayagan ka ng RBAC na makita ang lahat ng mga puwang sa cluster, at sa malalaking cluster hindi lahat ay binibigyan ng ganoong mga pahintulot. Kaya, sagot namin: para sa OC ito ay hindi isang problema sa lahat at ito ay madaling makagawa ng isang kumpletong listahan sa ganoong sitwasyon. Ang maliliit na bagay na ito ang bumubuo sa corporate orientation ng Openshift at ang mahusay na scalability ng platform na ito sa mga tuntunin ng mga user at application.
2. ODO - isang pinahusay na bersyon ng kubectl para sa mga developer
Ang isa pang halimbawa ng mga pagpapahusay ng Red Hat OpenShift sa Kubernetes ay ang ODO command line utility. Idinisenyo ito para sa mga developer at nagbibigay-daan sa iyong mabilis na mag-deploy ng lokal na code sa isang remote na cluster ng OpenShift. Maaari din nitong i-streamline ang mga panloob na proseso upang agad na i-sync ang lahat ng mga pagbabago sa code sa mga container sa isang remote na cluster ng OpenShift nang hindi kinakailangang muling buuin, magrehistro, at mag-redeploy ng mga imahe.
Tingnan natin kung paano pinapadali ng OC at ODO ang pagtatrabaho sa mga container at Kubernetes.
Ihambing lamang ang ilang mga daloy ng trabaho kapag binuo ang mga ito batay sa kubectl, at kapag ginamit ang OC o ODO.
• Pag-deploy ng code sa OpenShift para sa mga hindi nagsasalita ng YAML:
Kubernetes/kubectl
$>git clone
1- Gumawa ng Dockerfile na bumubuo ng imahe mula sa code
-----
MULA sa node
WORKDIR /usr/src/app
COPY package*.json ./
COPY index.js ./
COPY ./app ./app
RUN npm install
EXPOSE 3000
CMD [ "npm", "simulan" ]
-----
2- Binubuo namin ang imahe
$>podman build...
3- Mag-login sa pagpapatala
podman login...
4- Ilagay ang imahe sa registry
podman push
5- Lumikha ng mga yaml file para sa pag-deploy ng application (deployment.yaml, service.yaml, ingress.yaml) - ito ang ganap na minimum
6- I-deploy ang mga manifest file:
Kubectl apply -f .
OpenShift/oc
$> oc bagong-app – aming_application_name
OpenShift/odo
$>git clone
$> odo gumawa ng component nodejs myapp
$>odo push
• Context switch: baguhin ang work namespace o work cluster.
Kubernetes/kubectl
1- Lumikha ng konteksto sa kubeconfig para sa proyektong "myproject"
2- kubectl set-context...
OpenShift/oc
oc project na "myproject"
Kontrol sa kalidad: "Isang kawili-wiling feature ang lumitaw dito, nasa alpha version pa rin. Baka pwede nating ilagay sa production?"
Isipin na nakaupo ka sa isang karerang kotse at sinabihan: "Nag-install kami ng isang bagong uri ng preno at, sa totoo lang, hindi pa maayos ang kanilang pagiging maaasahan... Ngunit huwag mag-alala, aktibong pagbubutihin namin ang mga ito sa panahon ng kurso. ng championship." Paano mo gusto ang prospect na ito? Kami sa Red Hat ay hindi gaanong masaya. 🙂
Samakatuwid, sinusubukan naming ihinto ang mga bersyon ng alpha hanggang sa maging sapat na ang mga ito at nakagawa kami ng masusing pagsubok sa labanan at sa tingin namin ay ligtas silang gamitin. Karaniwan, ang lahat ay dumadaan muna sa yugto ng Dev Preview, pagkatapos ay sa pamamagitan at pagkatapos lamang lumabas bilang isang pampublikong paglabas (GA), na napakatatag na na angkop para sa produksyon.
Bakit ganon? Dahil, tulad ng pagbuo ng anumang iba pang software, hindi lahat ng mga paunang ideya sa Kubernetes ay umabot sa huling paglabas. O naabot nila ito at pinapanatili pa ang nilalayon na pag-andar, ngunit ang kanilang pagpapatupad ay lubhang naiiba mula doon sa bersyon ng alpha. Sa libu-libong mga customer ng Red Hat na gumagamit ng OpenShift upang suportahan ang mga gawaing kritikal sa misyon, binibigyan namin ng espesyal na diin ang katatagan ng aming platform at pangmatagalang suporta.
Nakatuon ang Red Hat na i-release ang OpenShift nang madalas at i-update ang bersyon ng Kubernetes na kasama nito. Halimbawa, ang kasalukuyang release ng GA ng OpenShift 4.3 sa oras ng pagsulat na ito ay kinabibilangan ng Kubernetes 1.16, na isang unit lang sa likod ng upstream na bersyon ng Kubernetes na may numerong 1.17. Kaya, sinusubukan naming bigyan ang customer ng enterprise-class na Kubernetes at magbigay ng karagdagang kontrol sa kalidad habang naglalabas kami ng mga bagong bersyon ng OpenShift.
Mga pag-aayos ng software: “Nagkaroon ng butas sa bersyon ng Kubernetes na mayroon kami sa produksyon. At maaari mo lamang itong isara sa pamamagitan ng pag-update ng tatlong bersyon. O mayroon bang anumang mga pagpipilian?
Sa open source na proyekto ng Kubernetes, ang mga pag-aayos ng software ay karaniwang inilalabas bilang bahagi ng susunod na release, kung minsan ay sumasaklaw sa isa o dalawang nakaraang milestone na release, na nagbibigay ng coverage pabalik nang kasing 6 na buwan.
Ipinagmamalaki ng Red Hat ang sarili sa pagpapalabas ng mga kritikal na pag-aayos nang mas maaga kaysa sa iba at pagbibigay ng suporta nang mas matagal. Kunin halimbawa ang kahinaan sa pagtaas ng pribilehiyo ng Kubernetes (): natuklasan ito sa Kubernetes 1.11, at ang mga pag-aayos para sa mga nakaraang release ay inilabas lamang hanggang sa bersyon 1.10.11, na iniiwan ang isang ito sa butas sa lahat ng nakaraang paglabas ng Kubernetes, mula 1.x hanggang 1.9.
Kaugnay nito, (Nariyan ang Kubernetes 1.2), kumukuha ng siyam na release ng OpenShift at malinaw na nagpapakita ng pangangalaga para sa mga customer (higit pang mga detalye ).
Paano pinapasulong ng OpenShift at Red Hat ang mga Kubernetes
Ang Red Hat ay ang pangalawang pinakamalaking nag-aambag ng software sa open source na proyekto ng Kubernetes, sa likod lamang ng Google, na may 3 sa 5 pinaka-prolific na developer na nagmumula sa Red Hat. Isa pang hindi kilalang katotohanan: maraming kritikal na pag-andar ang lumitaw sa Kubernetes nang eksakto sa inisyatiba ng Red Hat, sa partikular, tulad ng:
- RBAC. Ang Kubernetes ay walang mga function ng RBAC (ClusterRole, ClusterRoleBinding) hanggang sa nagpasya ang mga inhinyero ng Red Hat na ipatupad ang mga ito bilang bahagi ng mismong platform, at hindi bilang karagdagang paggana ng OpenShift. Natatakot ba ang Red Hat na mapabuti ang Kubernetes? Siyempre hindi, dahil ang Red Hat ay mahigpit na sumusunod sa mga prinsipyo ng open source at hindi naglalaro ng Open Core na mga laro. Ang mga pagpapabuti at inobasyon na hinihimok ng mga komunidad ng pag-unlad, sa halip na mga pagmamay-ari, ay mas mabubuhay at mas malawak na pinagtibay, na naaayon nang maayos sa aming pangunahing layunin na gawing mas kapaki-pakinabang ang open source software sa aming mga customer.
- Mga Patakaran sa Seguridad para sa mga pod (Pod Security Policy). Ang konseptong ito ng pagpapatakbo ng mga application nang ligtas sa loob ng mga pod ay orihinal na ipinatupad sa OpenShift sa ilalim ng pangalang SCC (Security Context Constraints). At tulad ng sa nakaraang halimbawa, nagpasya ang Red Hat na ipakilala ang mga pag-unlad na ito sa bukas na proyekto ng Kubernetes upang magamit ng lahat ang mga ito.
Maaaring ipagpatuloy ang serye ng mga halimbawang ito, ngunit gusto lang naming ipakita na talagang nakatuon ang Red Hat sa pagbuo ng Kubernetes at pagandahin ito para sa lahat.
Malinaw na ang OpenShift ay Kubernetes. Ano ang mga pagkakaiba? 🙂
Umaasa kami na sa pamamagitan ng pagbabasa hanggang dito ay napagtanto mo na ang Kubernetes ay ang pangunahing bahagi ng OpenShift. Ang pangunahing isa, ngunit malayo sa isa lamang. Sa madaling salita, ang pag-install lang ng Kubernetes ay hindi magbibigay sa iyo ng enterprise-class na platform. Kakailanganin mong magdagdag ng pagpapatunay, networking, seguridad, pagsubaybay, pamamahala ng log, at higit pa. Dagdag pa, kakailanganin mong gumawa ng ilang mahihirap na pagpipilian mula sa malaking bilang ng mga tool na magagamit (upang pahalagahan ang pagkakaiba-iba ng ecosystem, tingnan lamang ) at kahit papaano ay tiyakin ang pagkakapare-pareho at pagkakaugnay-ugnay upang gumana sila bilang isa. Bilang karagdagan, regular mong kakailanganing magsagawa ng mga pag-update at pagsubok ng regression sa tuwing may ilalabas na bagong bersyon ng alinman sa mga bahaging ginagamit mo. Iyon ay, bilang karagdagan sa paglikha at pagpapanatili ng platform mismo, kakailanganin mo ring harapin ang lahat ng software na ito. Hindi malamang na maraming oras ang natitira upang malutas ang mga problema sa negosyo at makamit ang mga bentahe sa kompetisyon.
Ngunit sa kaso ng OpenShift, tinatanggap ng Red Hat ang lahat ng mga kumplikadong ito sa sarili nito at binibigyan ka lamang ng isang functional na kumpletong platform, na kinabibilangan hindi lamang ng mga Kubernetes mismo, kundi pati na rin ang buong hanay ng mga kinakailangang open source na tool na ginagawang isang tunay na enterprise-class ang Kubernetes. solusyon na maaari mong agad at ganap na mahinahon na ilunsad sa produksyon. At siyempre, kung mayroon kang ilan sa iyong sariling mga stack ng teknolohiya, maaari mong isama ang OpenShift sa mga umiiral nang solusyon.
Tingnan ang larawan sa itaas: lahat ng nasa labas ng Kubernetes rectangle ay kung saan nagdaragdag ang Red Hat ng functionality na wala sa Kubernetes, na tinatawag na by-design. At ngayon titingnan natin ang pangunahing ng mga lugar na ito.
1. Matatag na OS bilang base: RHEL CoreOS o RHEL
Ang Red Hat ay isang nangungunang tagapagbigay ng serbisyo sa loob ng mahigit 20 taon. Linux-mga distribusyon para sa mga kritikal na aplikasyon sa negosyo. Ang aming malawak at patuloy na ina-update na karanasan sa larangang ito ay nagbibigay-daan sa amin na mag-alok ng isang tunay na maaasahan at mapagkakatiwalaang pundasyon para sa pag-deploy ng industrial container. Ginagamit ng RHEL CoreOS ang parehong kernel gaya ng RHEL, ngunit pangunahing na-optimize para sa mga gawain tulad ng pagpapatakbo ng mga container at pagpapatakbo sa mga Kubernetes cluster: ang pinababang laki at immutability nito ay nagpapadali sa pag-setup ng cluster, autoscaling, patch deployment, at higit pa. Ang lahat ng mga tampok na ito ay ginagawa itong mainam na pundasyon para sa paghahatid ng isang pare-parehong karanasan ng gumagamit ng OpenShift sa malawak na hanay ng mga kapaligiran sa computing, mula sa bare metal hanggang sa pribado at pampublikong cloud.
2. Automation ng IT operations
Ang pag-automate ng mga proseso ng pag-install at pang-araw-araw na operasyon (iyon ay, pang-araw-araw na pagpapatakbo) ang pinakamatibay na punto ng OpenShift, na ginagawang mas madali ang pangangasiwa, pag-update, at pagpapanatili ng pagganap ng container platform sa pinakamataas na antas. Nakamit ito sa pamamagitan ng suporta para sa mga operator ng Kubernetes sa antas ng kernel ng OpenShift 4.
Ang OpenShift 4 ay isa ring buong ecosystem ng mga solusyon batay sa mga operator ng Kubernetes, na binuo ng Red Hat mismo at ng mga third-party na kasosyo (tingnan. Red Hat, o tindahan ng operator , na ginawa ng Red Hat para sa mga third-party na developer).
Kasama sa pinagsama-samang OpenShift 4 catalog ang higit sa 180 Kubernetes operator
3. Mga Tool ng Developer
Mula noong 2011, ang OpenShift ay magagamit bilang isang PaaS (Platform-as-a-Service) na platform na ginagawang mas madali ang buhay para sa mga developer, tinutulungan silang tumuon sa coding, at nag-aalok ng katutubong suporta para sa mga programming language gaya ng Java, Node.js , PHP, Ruby, Python, Go, pati na rin ang patuloy na pagsasama ng CI/CD at mga serbisyo sa paghahatid, mga database, atbp. Nag-aalok ang OpenShift 4 , na kinabibilangan ng higit sa 100 serbisyo batay sa mga operator ng Kubernetes na binuo ng Red Hat at ng aming mga kasosyo.
Hindi tulad ng Kubernetes, ang OpenShift 4 ay may nakalaang GUI (), na tumutulong sa mga developer na walang kahirap-hirap na mag-deploy ng mga application mula sa iba't ibang source (git, external registries, Dockerfile, atbp.) sa kanilang mga namespace at malinaw na nakikita ang mga ugnayan sa pagitan ng mga bahagi ng application.
Bilang karagdagan, nag-aalok ang OpenShift ng isang hanay ng mga tool sa pag-unlad ng Codeready, na, sa partikular, kasama , isang ganap na containerized na IDE na may web interface na direktang tumatakbo sa ibabaw ng OpenShift at nagpapatupad ng IDE-as-a-service approach. Sa kabilang banda, para sa mga gustong magtrabaho nang mahigpit sa lokal na mode, mayroong Codeready Containers, isang fully functional na bersyon ng OpenShift 4 na maaaring i-deploy sa isang laptop.
Pinagsamang IDE bilang isang serbisyo para sa mahusay na pag-unlad sa platform ng Kubernetes/OpenShift
Nag-aalok ang OpenShift ng buong CI/CD system mula mismo sa kahon, alinman batay sa containerized na Jenkins at isang plugin para sa pagtatrabaho sa mga pipeline, o isang Kubernetes-oriented na CI/CD system (kasalukuyang nasa bersyon ng preview ng Tech). Ang parehong mga solusyong ito ay ganap na pinagsama sa OpenShift console, na nagbibigay-daan sa iyong magpatakbo ng mga pipeline trigger, tingnan ang mga deployment, log, at higit pa.
4. Mga Tool sa Application
Binibigyang-daan ka ng OpenShift na mag-deploy ng parehong tradisyonal na stateful na mga application at cloud-based na solusyon batay sa mga bagong arkitektura, gaya ng mga microservice o serverless. Ang solusyon sa OpenShift Service Mesh ay lumabas mismo sa kahon na may mga pangunahing tool para sa pagpapanatili ng mga microservice, tulad ng Istio, Kiali at Jaeger. Kaugnay nito, kasama sa OpenShift Serverless solution hindi lamang ang Knative, kundi pati na rin ang mga tool tulad ng Keda na nilikha bilang bahagi ng pinagsamang inisyatiba sa Microsoft upang magbigay ng Azure function sa OpenShift platform.
Ang pinagsamang solusyon na OpenShift ServiceMesh (Istio, Kiali, Jaeger) ay magiging kapaki-pakinabang kapag bumubuo ng mga microservice
Upang i-bridge ang agwat sa pagitan ng mga legacy na application at container, pinapayagan na ngayon ng OpenShift ang paglipat ng virtual machine sa OpenShift platform gamit ang Container Native Virtualization (kasalukuyang nasa TechPreview), na ginagawang realidad ang mga hybrid na application at pinapadali ang kanilang paglipat sa pagitan ng iba't ibang cloud, pribado at pampubliko.
Virtual na makina Windows 2019 Virtual, tumatakbo sa OpenShift sa pamamagitan ng Container Native Virtualization (kasalukuyang nasa Tech Preview)
5. Mga tool para sa mga kumpol
Ang anumang platform ng enterprise-class ay dapat na mayroong monitoring at sentralisadong serbisyo sa pag-log, mekanismo ng seguridad, pagpapatunay at awtorisasyon, at mga tool sa pamamahala ng network. At ang OpenShift ay nagbibigay ng lahat ng ito sa labas ng kahon, at lahat ito ay 100% open source, kabilang ang mga solusyon tulad ng ElasticSearch, Prometheus, Grafana. Ang lahat ng solusyong ito ay may kasamang mga dashboard, sukatan, at alerto na binuo at na-configure na gamit ang malawak na cluster monitoring expertise ng Red Hat, na nagbibigay-daan sa iyong epektibong kontrolin at subaybayan ang iyong production environment sa simula pa lang.
Ang OpenShift ay mayroon ding pamantayan sa mga mahahalagang bagay para sa mga customer ng korporasyon tulad ng pagpapatotoo sa isang built-in na oauth provider, pagsasama sa mga tagapagbigay ng kredensyal, kabilang ang LDAP, ActiveDirectory, OpenID Connect, at marami pa.
Pre-configure na Grafana dashboard para sa OpenShift cluster monitoring
Higit sa 150 paunang na-configure na sukatan at alerto ng Prometheus para sa OpenShift cluster monitoring
Itutuloy
Ang mayamang functionality ng solusyon at ang malawak na karanasan ng Red Hat sa larangan ng Kubernetes ay ang mga dahilan kung bakit nakamit ng OpenShift ang isang nangingibabaw na posisyon sa merkado, tulad ng ipinapakita sa figure sa ibaba (magbasa nang higit pa ).
"Ang Red Hat ay kasalukuyang nangunguna sa merkado na may 44% na bahagi.
Ang kumpanya ay umaani ng mga benepisyo ng kanyang customer-centric na diskarte sa pagbebenta, kung saan ito unang kumunsulta at nagsasanay sa mga developer ng enterprise at pagkatapos ay lumipat sa monetization habang ang enterprise ay nagsisimulang mag-deploy ng mga container sa produksyon."
(Pinagmulan: )
Umaasa kami na nasiyahan ka sa artikulong ito. Sa mga susunod na post sa seryeng ito, titingnan natin ang mga bentahe ng OpenShift sa mga Kubernetes sa bawat kategoryang tinalakay dito.
Pinagmulan: www.habr.com
