Ano ang bago sa Red Hat OpenShift 4.2 at 4.3?

Ano ang bago sa Red Hat OpenShift 4.2 at 4.3?
Ang ika-apat na bersyon ng OpenShift ay pinakawalan kamakailan. Ang kasalukuyang bersyon 4.3 ay magagamit mula noong katapusan ng Enero at lahat ng mga pagbabago dito ay alinman sa isang ganap na bago na wala sa ikatlong bersyon, o isang pangunahing pag-update ng kung ano ang lumabas sa bersyon 4.1. Lahat ng sasabihin namin sa iyo ngayon ay kailangang malaman, maunawaan at isaalang-alang ng mga nagtatrabaho sa OpenShift at nagpaplanong lumipat sa isang bagong bersyon.

Sa paglabas ng OpenShift 4.2, pinadali ng Red Hat ang pakikipagtulungan sa Kubernetes. Ang mga bagong tool at plugin ay lumitaw para sa paggawa ng mga container, CI/CD pipelines at serverless deployment. Ang mga inobasyon ay nagbibigay ng pagkakataon sa mga developer na tumuon sa pagsulat ng code, at hindi sa pakikitungo sa Kubernetes.

Sa totoo lang, ano ang bago sa mga bersyon ng OpenShift 4.2 at 4.3?

Paglipat patungo sa hybrid na ulap

Kapag nagpaplano ng bagong imprastraktura ng IT o kapag bumubuo ng isang umiiral na IT landscape, ang mga kumpanya ay lalong isinasaalang-alang ang isang cloud approach sa pagbibigay ng mga IT resources, kung saan sila ay nagpapatupad ng mga pribadong cloud solution o ginagamit ang kapangyarihan ng mga pampublikong cloud provider. Kaya, ang mga modernong imprastraktura ng IT ay unti-unting ginagawa ayon sa isang "hybrid" na modelo ng ulap, kapag ang parehong mga mapagkukunan sa nasasakupan at pampublikong mapagkukunan ng ulap na may isang karaniwang sistema ng pamamahala ay ginagamit. Ang Red Hat OpenShift 4.2 ay espesyal na idinisenyo upang pasimplehin ang paglipat sa isang hybrid na modelo ng ulap at ginagawang madali ang pagkonekta ng mga mapagkukunan mula sa mga provider tulad ng AWS, Azure at Google Cloud Platform sa cluster, kasama ang paggamit ng mga pribadong ulap sa VMware at OpenStack.

Bagong diskarte sa pag-install

Sa bersyon 4, ang diskarte sa pag-install ng OpenShift ay nagbago. Nagbibigay ang Red Hat ng isang espesyal na utility para sa pag-deploy ng OpenShift cluster - openshift-install. Ang utility ay isang binary file na nakasulat sa Go. Ang Openshit-installer ay naghahanda ng yaml file na may kinakailangang configuration para sa pag-deploy.

Sa kaso ng pag-install gamit ang cloud resources, kakailanganin mong tukuyin ang kaunting impormasyon tungkol sa hinaharap na cluster: DNS zone, bilang ng mga worker node, mga partikular na setting para sa cloud provider, impormasyon ng account para sa pag-access sa cloud provider. Pagkatapos ihanda ang configuration file, maaaring i-deploy ang cluster gamit ang isang command.

Sa kaso ng pag-install sa iyong sariling mga mapagkukunan sa pag-compute, halimbawa, kapag gumagamit ng isang pribadong cloud (vSphere at OpenStack ay suportado) o kapag nag-i-install sa mga bare metal server, kakailanganin mong manu-manong i-configure ang imprastraktura - ihanda ang minimum na bilang ng mga virtual machine o mga pisikal na server na kinakailangan upang lumikha ng isang Control Plane cluster, i-configure ang mga serbisyo sa network. Pagkatapos ng pagsasaayos na ito, ang isang OpenShift cluster ay maaaring gawin nang katulad gamit ang isang command ng openshift-installer utility.

Mga update sa imprastraktura

Pagsasama ng CoreOS

Ang pangunahing update ay ang pagsasama sa Red Hat CoreOS. Ang mga master node ng Red Hat OpenShift ay maaari na ngayong gumana lamang sa bagong OS. Ito ay isang libreng operating system mula sa Red Hat na partikular na idinisenyo para sa mga solusyon sa lalagyan. Ang Red Hat CoreOS ay isang magaan na Linux na na-optimize para sa pagpapatakbo ng mga container.

Kung sa 3.11 ang operating system at OpenShift ay umiral nang hiwalay, pagkatapos ay sa 4.2 ito ay inextricably naka-link sa OpenShift. Ngayon ito ay isang solong appliance - hindi nababagong imprastraktura.

Ano ang bago sa Red Hat OpenShift 4.2 at 4.3?
Para sa mga cluster na gumagamit ng RHCOS para sa lahat ng node, ang pag-upgrade ng OpenShift Container Platform ay isang simple at lubos na automated na proseso.

Dati, upang i-update ang OpenShift, kailangan mo munang i-update ang pinagbabatayan na operating system kung saan tumatakbo ang produkto (sa panahong iyon, Red Hat Enterprise Linux). Pagkatapos lamang ay maaaring ma-update ang OpenShift nang unti-unti, bawat node. Walang pag-uusap tungkol sa anumang automation ng proseso.

Ngayon, dahil ganap na kinokontrol ng OpenShift Container Platform ang mga system at serbisyo sa bawat node, kasama ang OS, ang gawaing ito ay malulutas sa pamamagitan ng pagpindot sa isang button mula sa web interface. Pagkatapos nito, isang espesyal na operator ang inilunsad sa loob ng OpenShift cluster, na kumokontrol sa buong proseso ng pag-update.

Bagong CSI

Pangalawa, ang bagong CSI ay isang storage interface controller na nagbibigay-daan sa iyong ikonekta ang iba't ibang external storage system sa OpenShift cluster. Ang malaking bilang ng mga provider ng driver ng storage para sa OpenShift ay sinusuportahan batay sa mga driver ng storage na isinulat mismo ng mga manufacturer ng storage system. Ang kumpletong listahan ng mga sinusuportahang driver ng CSI ay makikita sa dokumentong ito: https://kubernetes-csi.github.io/docs/drivers.html. Sa listahang ito mahahanap mo ang lahat ng pangunahing modelo ng mga disk array mula sa mga nangungunang tagagawa (Dell/EMC, IBM, NetApp, Hitachi, HPE, PureStorage), mga solusyon sa SDS (Ceph) at cloud storage (AWS, Azure, Google). Sinusuportahan ng OpenShift 4.2 ang mga driver ng CSI ng bersyon 1.1 ng detalye ng CSI.

RedHat OpenShift Service Mesh

Batay sa mga proyekto ng Istio, Kiali at Jaeger, ang Red Hat OpenShift Service Mesh, bilang karagdagan sa mga karaniwang gawain ng mga kahilingan sa pagruruta sa pagitan ng mga serbisyo, ay nagbibigay-daan para sa kanilang pagsubaybay at visualization. Nakakatulong ito sa mga developer na madaling makipag-usap, subaybayan, at pamahalaan ang isang application na naka-deploy sa loob ng Red Hat OpenShift.

Ano ang bago sa Red Hat OpenShift 4.2 at 4.3?
Visualization ng isang application na mayroong microservice architecture gamit ang Kiali

Upang gawing simple ang pag-install, pagpapanatili, at pamamahala ng lifecycle ng Service Mesh hangga't maaari, ang Red Hat OpenShift ay nagbibigay sa mga administrator ng isang espesyal na operator, ang Service Mesh Operator. Ito ay isang operator ng Kubernetes na nagbibigay-daan sa iyong i-deploy ang na-reconfigure na Istio, Kiali at Jaeger na mga pakete sa isang cluster, na nagpapalaki sa administratibong pasanin ng pamamahala ng mga application.

CRI-O sa halip na Docker

Ang default na container runtime Docker ay pinalitan ng CRI-O. Posibleng gamitin ang CRI-O na nasa bersyon 3.11, ngunit sa 4.2 ito ang naging pangunahing. Hindi mabuti o masama, ngunit isang bagay na dapat tandaan kapag ginagamit ang produkto.

Mga operator at pag-deploy ng application

Ang mga operator ay isang bagong entity para sa RedHat OpenShift, na lumabas sa ikaapat na bersyon. Ito ay isang paraan ng packaging, pag-deploy, at pamamahala ng isang Kubernetes application. Maaari itong isipin bilang isang plugin para sa mga application na naka-deploy sa mga container, na hinimok ng Kubernetes API at mga tool ng kubectl.

Tumutulong ang mga operator ng Kubernetes na i-automate ang anumang mga gawaing nauugnay sa pangangasiwa at pamamahala ng lifecycle ng application na idini-deploy mo sa iyong cluster. Halimbawa, maaaring i-automate ng operator ang mga update, backup at scaling ng application, baguhin ang configuration, atbp. Ang kumpletong listahan ng mga operator ay matatagpuan sa https://operatorhub.io/.

Direktang maa-access ang OperatorHub mula sa web interface ng management console. Ito ay isang direktoryo ng aplikasyon para sa OpenShift na pinananatili ng Red Hat. Yung. lahat ng inaprubahang operator ng Red Hat ay sasakupin ng suporta ng vendor.

Ano ang bago sa Red Hat OpenShift 4.2 at 4.3?
OperatorHub portal sa OpenShift management console

Pangkalahatang batayang imahe

Ito ay isang standardized na hanay ng mga imahe ng RHEL OS na maaaring magamit upang bumuo ng iyong mga containerized na application. Mayroong minimal, karaniwan at buong hanay. Gumagamit sila ng napakaliit na espasyo at sinusuportahan ang lahat ng kinakailangang naka-install na package at programming language.

Mga Tool ng CI/CD

Sa RedHat OpenShif 4.2, naging posible na pumili sa pagitan ng Jenkins at OpenShift Pipelines batay sa Tekton Pipelines.

Ang OpenShift Pipelines ay batay sa Tekton, na mas mahusay na sinusuportahan ng Pipeline habang lumalapit ang Code at GitOps. Sa mga pipeline ng OpenShift, tumatakbo ang bawat hakbang sa sarili nitong lalagyan, kaya ginagamit lang ang mga mapagkukunan habang isinasagawa ang hakbang. Nagbibigay ito sa mga developer ng kumpletong kontrol sa mga pipeline ng paghahatid ng module, plugin, at kontrol sa pag-access nang walang sentral na CI/CD server na mamamahala.

Ang OpenShift Pipelines ay kasalukuyang nasa Developer Preview at available bilang isang operator sa isang OpenShift 4 cluster. Siyempre, magagamit pa rin ng mga user ng OpenShift ang Jenkins sa RedHat OpenShift 4.

Mga Update sa Pamamahala ng Developer

Sa 4.2 OpenShift, ang web interface ay ganap na na-update para sa parehong mga developer at administrator.

Sa mga nakaraang bersyon ng OpenShift, lahat ay nagtrabaho sa tatlong console: service directory, administrator console at work console. Ngayon ang cluster ay nahahati sa dalawang bahagi lamang - administrator console at developer console.

Nakatanggap ang Developer console ng makabuluhang pagpapahusay ng user interface. Ngayon ay mas maginhawang ipinapakita ang mga topologies ng mga application at kanilang mga assemblies. Ginagawa nitong mas madali para sa mga developer na gumawa, mag-deploy, at mag-visualize ng mga containerized na application at clustered resources. Nagbibigay-daan sa kanila na tumuon sa kung ano ang mahalaga sa kanila.

Ano ang bago sa Red Hat OpenShift 4.2 at 4.3?
Portal ng developer sa OpenShift management console

Odo

Ang Odo ay isang developer-oriented na command line utility na pinapasimple ang pagbuo ng application sa OpenShift. Gamit ang git push style na komunikasyon, tinutulungan ng CLI na ito ang mga developer na bago sa Kubernetes na bumuo ng mga application sa OpenShift.

Pagsasama sa mga kapaligiran sa pag-unlad

Ang mga developer ay maaari na ngayong bumuo, mag-debug at mag-deploy ng kanilang mga application sa OpenShift nang hindi umaalis sa kanilang paboritong code development environment, tulad ng Microsoft Visual Studio, JetBrains (kabilang ang IntelliJ), Eclipse Desktop, atbp.

Red Hat OpenShift Deployment extension para sa Microsoft Azure DevOps

Ang extension ng Red Hat OpenShift Deployment para sa Microsoft Azure DevOps ay inilabas. Maaari na ngayong i-deploy ng mga user ng toolset na ito ng DevOps ang kanilang mga application sa Azure Red Hat OpenShift o anumang iba pang cluster ng OpenShift nang direkta mula sa Microsoft Azure DevOps.

Transition mula sa ikatlong bersyon hanggang sa ikaapat

Dahil isang bagong release ang pinag-uusapan, at hindi isang update, hindi mo lang mailalagay ang pang-apat na bersyon sa ibabaw ng pangatlo. Ang pag-update mula sa bersyon XNUMX hanggang sa bersyon XNUMX ay hindi susuportahan..

Ngunit may magandang balita: Nagbibigay ang Red Hat ng mga tool para sa paglilipat ng mga proyekto mula 3.7 hanggang 4.2. Maaari kang mag-migrate ng mga workload ng application gamit ang tool na Cluster Application Migration (CAM). Binibigyang-daan ka ng CAM na kontrolin ang paglipat at bawasan ang downtime ng application.

OpenShift 4.3

Ang mga pangunahing inobasyon na inilarawan sa artikulong ito ay lumabas sa bersyon 4.2. Ang kamakailang inilabas na 4.3 na mga pagbabago ay hindi kasing laki, ngunit mayroon pa ring ilang mga bagong bagay. Ang listahan ng mga pagbabago ay medyo malawak, narito ang pinakamahalaga sa aming opinyon:

I-update ang bersyon ng Kubernetes sa 1.16.

Ang bersyon ay na-upgrade ng dalawang hakbang nang sabay-sabay; sa OpenShift 4.2 ito ay 1.14.

Pag-encrypt ng data sa etcd

Simula sa bersyon 4.3, naging posible na i-encrypt ang data sa etcd database. Kapag na-enable na ang pag-encrypt, posibleng i-encrypt ang sumusunod na OpenShift API at mga mapagkukunan ng Kubernetes API: Mga Lihim, ConfigMaps, Mga Ruta, mga token sa pag-access, at awtorisasyon ng OAuth.

timon

Nagdagdag ng suporta para sa bersyon 3 ng Helm, isang sikat na manager ng package para sa Kubernetes. Sa ngayon, may status na TECHNOLOGY PREVIEW ang suporta. Ang suporta sa helm ay palalawakin sa ganap na suporta sa mga hinaharap na bersyon ng OpenShift. Ang helm cli utility ay kasama ng OpenShift at maaaring i-download mula sa cluster management web console.

Pag-update ng Dashboard ng Proyekto

Sa bagong bersyon, ang Project Dashboard ay nagbibigay ng karagdagang impormasyon sa pahina ng proyekto: katayuan ng proyekto, paggamit ng mapagkukunan, at mga quota ng proyekto.

Pagpapakita ng mga kahinaan para sa quay sa Web console

Ang isang tampok ay idinagdag sa console ng pamamahala upang ipakita ang mga kilalang kahinaan para sa mga larawan sa mga imbakan ng Quay. Ang pagpapakita ng mga kahinaan para sa mga lokal at panlabas na repositoryo ay sinusuportahan.

Pinasimpleng paggawa ng offline operatorhub

Para sa kaso ng pag-deploy ng OpenShift cluster sa isang nakahiwalay na network, kung saan ang access sa Internet ay limitado o wala, ang paggawa ng "mirror" para sa OperatorHub registry ay pinasimple. Ngayon ito ay maaaring gawin sa tatlong koponan lamang.

Mga May-akda:
Victor Puchkov, Yuri Semenyukov

Pinagmulan: www.habr.com

Magdagdag ng komento