"У чым розніца паміж Kubernetes і OpenShift?" – гэтае пытанне ўзнікае з зайздроснай сталасцю. Хоць насамрэч гэта ўсё роўна што пытацца, чым аўтамабіль адрозніваецца ад рухавіка. Калі працягнуць аналогію, то аўтамабіль - гэта гатовы прадукт, ім можна карыстацца адразу ж, літаральна: сеў і паехаў. З іншага боку, каб рухавік вас кудысьці павёз, яго спачатку трэба дапоўніць масай іншых рэчаў, каб у выніку атрымаць усё той жа аўтамабіль.
Таму Kubernetes гэта такі рухавік, вакол якога сабраны аўтамабіль (платформа) маркі OpenShift, які і вязе вас да мэты.
У гэтым артыкуле мы хочам нагадаць і крыху падрабязней разабраць наступныя ключавыя моманты:
- Kubernetes - гэта сэрца платформы OpenShift І гэта на 100% сертыфікаваны Kubernetes, з цалкам адкрытым кодам і без найменшай прапрыетарнасці. Сцісла:
- API для кластара OpenShift - гэта стоадсоткавы Kubernetes.
- Калі кантэйнер працуе ў любой іншай сістэме Kubernetes, то ён без якія-небудзь змен будзе працаваць і на OpenShift. Уносіць змены ў дадатку не трэба.
- OpenShift не толькі дапаўняе Kubernetes карыснымі функцыямі і магчымасцямі. Як і аўтамабіль, OpenShift адразу ж готаў да выкарыстання, яго можна неадкладна пускаць у прадакшн і, як мы пакажам ніжэй, ён значна спрашчае жыццё распрацоўніку. Менавіта таму OpenShift адзіны ў дзвюх асобах. Гэта і паспяховая, і шырока вядомая PaaS-платформа карпаратыўнага класа, калі глядзець з пазіцый распрацоўніка. І адначасова гэтае супернадзейнае рашэнне класа Container-as-a-Service з пункта гледжання прамысловай эксплуатацыі.
OpenShift - гэта Kubernetes са 100% сертыфікацыяй ад фонду CNCF
У аснове OpenShift ляжыць . Таму пасля адпаведнага навучання карыстачы захапляюцца моцай kubectl. А тыя, хто перайшоў на OpenShift з Kubernetes Cluster, часта кажуць, як ім вельмі падабаецца, што пасля перанакіравання kubeconfig на кластар OpenShift усе скрыпты працуюць бездакорна.
Вы напэўна чулі пра OpenShift'аўскую ўтыліту каманднага радка пад назовам OC. Яна цалкам сумяшчальная па камандах з kubectl, плюс, прапануе некалькі карысных helper'ов, якія спатрэбяцца пры выкананні цэлага шэрагу задач. Але спачатку крыху падрабязней аб сумяшчальнасці OC і kubectl:
Каманды kubectl
Каманды OC
kubectl атрымаць струкі
oc get pods
kubectl get namespaces
oc get namespaces
kubectl create -f deployment.yaml
oc create -f deployment.yaml
Вось як выглядаюць вынікі выкарыстання kubectl на OpenShift API:
• kubectl get pods - цалкам чакана вяртае pod'ы.
• kubectl get namespaces - цалкам чакана вяртае прасторы імёнаў.
Каманда kubectl create -f mydeployment.yaml стварае kubernetes-рэсурсы сапраўды гэтак жа, як на і на любой іншай Kubernetes-платформе, як паказана ў відэа ніжэй:
Інакш кажучы, усе Kubernetes'аўскія API цалкам даступныя ў OpenShift з захаваннем 100% сумяшчальнасці. Менавіта таму .
OpenShift дапаўняе Kubernetes карыснымі функцыямі
Kubernetes'аўскія API на 100% даступныя ў OpenShift, але вось штатнай Kubernetes'аўскай утыліце kubectl відавочна не хапае функцыянальнасці і выгоды. Таму Red Hat дапоўніў Kubernetes карыснымі функцыямі і прыладамі каманднага радка, такімі як OC (скарачэнне ад OpenShift client) і ODO (OpenShift DO, гэтая ўтыліта прызначаная для распрацоўнікаў).
1. Утыліта OC - больш магутны і зручны варыянт Kubectl
Напрыклад, у адрозненне ад kubectl, яна дазваляе ствараць новыя прасторы імёнаў і лёгка перамыкаць кантэкст, а таксама прапануе шэраг карысных каманд для распрацоўнікаў, напрыклад, для зборкі кантэйнерных выяў і разгортванні прыкладанняў непасрэдна з зыходнага кода ці двайковых файлаў (Source-to-image, s2i).
Давайце на прыкладах разгледзім, як убудаваныя helper'ы і пашыраная функцыянальнасць утыліты OC дапамагаюць спрасціць паўсядзённае працу.
Прыклад першы - кіраванне прасторамі імёнаў. У кожным кластары Kubernetes заўсёды ёсць некалькі прастор імёнаў. Звычайна яны выкарыстоўваюцца для стварэння дэвелаперскіх і прадакшн-акружэнняў, але могуць прымяняцца і для таго, каб, напрыклад, выдаваць кожнаму распрацоўшчыку персанальную "пясочніцу". На практыцы гэта прыводзіць да таго, што распрацоўніку даводзіцца часта перамыкацца паміж прасторамі імёнаў, паколькі kubectl працуе ў кантэксце бягучай прасторы. Таму ў выпадку з kubectl народ актыўна прымяняе для гэтага helper-скрыпты. А вось пры выкарыстанні OC для пераключэння на патрэбную прастору дастаткова сказаць "oc project прастора_імёнаў".
Не памятаеце, як завецца патрэбная прастора імёнаў? Ці не праблема, проста ўвядзіце “oc get projects”, каб вывесці на экран поўны спіс. Скептычна цікавіцеся, як гэта спрацуе, калі ў вас ёсць доступ толькі да абмежаванага падмноства прастор імёнаў на кластары? Ну, таму што kubectl робіць гэта карэктна, толькі калі RBAC дазваляе вам бачыць усю прастору на кластары, а ў вялікіх кластарах такія паўнамоцтвы выдаюць далёка не ўсім. Дык вось, адказваем: для OC гэта ўвогуле не праблема і яна лёгка выдасць у такой сітуацыі поўны спіс. Вось з такіх дробязяў і складаецца карпаратыўная арыентаванасць Openshift і добрая маштабаванасць гэтай платформы ў плане карыстальнікаў і дадаткаў.
2. ODO - палепшаная версія kubectl для распрацоўнікаў
У якасці яшчэ аднаго прыкладу паляпшэнняў Red Hat OpenShift у параўнанні з Kubernetes можна прывесці ўтыліту каманднага радка ODO. Яна прызначана для распрацоўшчыкаў і дазваляе хутка разгортваць лакальны код на выдаленым кластары OpenShift. Акрамя таго, з яе дапамогай можна аптымізаваць унутраныя працэсы, каб імгненна сінхранізаваць усе змены кода з кантэйнерамі на выдаленым кластары OpenShift без таго, каб зноўку выконваць зборку, размяшчэнне ў рэестры і паўторнае разгортванне выяў.
Давайце паглядзім, як OC і ODO палягчае працу з кантэйнерамі і Kubernetes.
Проста параўнаем парачку працоўных працэсаў, калі яны будуюцца на аснове kubectl, і калі ўжываюцца OC ці ODO.
• Разгортванне кода на OpenShift для тых, хто не валодае мовай YAML:
Kubernetes / kubectl
$> git clone
1- Ствараем Dockerfile, які выконвае зборку выявы з кода
-----
FROM node
WORKDIR /usr/src/app
COPY package*.json ./
COPY index.js ./
COPY ./app ./app
RUN npm install
EXPOSE 3000
CMD [ "npm", "start" ] ————–
2- Выконваем зборку выявы
$> podman build …
3- Лагін у рэестр
podman login …
4- Размяшчаем вобраз у рэестры
podman push
5- Ствараем yaml-файлы для разгортвання прыкладання (deployment.yaml, service.yaml, ingress.yaml) - гэта абсалютны мінімум
6- Разгортваем manifest-файлы:
Kubectl apply -f.
OpenShift/oc
$> oc new-app – імя_нашага_прыкладання
OpenShift / ode
$> git clone
$> ode create component nodejs myapp
$> ode push
• Пераключэнне кантэксту: змена працоўнай прасторы імёнаў ці працоўнага кластара.
Kubernetes / kubectl
1- Ствараем кантэкст у kubeconfig для праекта “myproject”
2- kubectl set-context …
OpenShift/oc
oc project “myproject”
Кантроль якасці: «Тут з'явілася адна цікавая функцыя, пакуль у альфа-версіі. Можа ўвядзем яе ў прадакшн?»
Уявіце, што вас садзяць у гоначны балід і кажуць: «Мы тут паставілі тормазы новага тыпу і, шчыра кажучы, у іх пакуль не ўсё ў парадку з надзейнасцю… Але ты не хвалюйся, будзем іх актыўна дапрацоўваць прама па ходзе чэмпіянату». Як вам такі далягляд? Нам у Red Hat неяк не вельмі. 🙂
Таму мы імкнемся ўстрымлівацца ад альфа-версій датуль, пакуль яны ў дастатковай меры не саспеюць, і мы не правядзём дбайнае баявое тэставанне і не адчуем, што іх можна бяспечна выкарыстаць. Звычайна ў нас усё праходзіць спачатку праз стадыю Dev Preview, потым праз і толькі потым выходзіць у выглядзе агульнадаступнага рэлізу (GA), які стабільны ўжо настолькі, што падыходзіць у прадакшн.
Чаму так? Таму што, як і пры распрацоўцы любога іншага софту, далёка не ўсе першапачатковыя задумкі ў Kubernetes даходзяць да фінальнага рэлізу. Ці даходзяць, і нават захоўваюць задуманую функцыянальнасць, але іх рэалізацыя кардынальна адрозніваецца ад той, што была ў альфа-версіі. Паколькі тысячы і тысячы кліентаў Red Hat ужываюць OpenShift для падтрымкі крытычна важных задач, мы робім адмысловы ўпор на стабільнасці нашай платформы і на доўгачасовай падтрымцы.
Red Hat мэтанакіравана выпускае частыя рэлізы OpenShift і абнаўляе версію Kubernetes, якая ўваходзіць у яе склад. Напрыклад, у бягучы на момант напісання гэтага артыкула GA-рэліз OpenShift 4.3 убудаваны Kubernetes 1.16, які ўсяго на адзінку адстае ад upstream-версіі Kubernetes з нумарам 1.17. Такім чынам мы імкнемся даць замоўцу Kubernetes карпаратыўнага класа і забяспечыць дадатковы кантроль якасці падчас выпуску новых версій OpenShift.
Праграмныя выпраўленні: «У той версіі Kubernetes, якая ў нас у прадакшн, знайшлася дзірка. І закрыць яе можна толькі абнаўленнем на тры версіі ўверх. Ці ёсць варыянты?
У рамках адчыненага праекту Kubernetes праграмныя выпраўленні звычайна выходзяць у складзе наступнага рэлізу, часам яны ахапляюць адзін ці два папярэдніх прамежкавых рэлізу, што дае ахоп усяго на 6 месяцаў назад.
Red Hat па праве ганарыцца тым, што выпускае крытычныя выпраўленні раней за іншых і забяспечвае падтрымку на значна большы тэрмін. Возьмем, напрыклад, уразлівасць з эскалацыяй прывілеяў у Kubernetes (): яна выявілася ў Kubernetes 1.11, а выпраўленні для папярэдніх рэлізаў выпусцілі толькі да версіі 1.10.11, пакінуўшы гэтую ў дзірку ва ўсе папярэднія рэлізах Kubernetes, з 1.x па 1.9.
У сваю чаргу, (там варта Kubernetes 1.2), захапіўшы дзевяць рэлізаў OpenShift і наглядна прадэманстраваўшы клопат аб кліентах (падрабязней ).
Як OpenShift і Red Hat рухаюць наперад Kubernetes
Red Hat займае другое месца па памеры праграмнага ўкладу ў адкрыты праект Kubernetes, саступаючы тут толькі Google, прычым 3 з 5 самых пладавітых распрацоўшчыкаў з'яўляюцца супрацоўнікамі Red Hat. Яшчэ адзін малавядомы факт: шматлікія крытычна важныя функцыі з'явіліся ў Kubernetes менавіта па ініцыятыве Red Hat, у прыватнасці, такія як:
- RBAC. У Kubernetes не было функцый RBAC (ClusterRole, ClusterRoleBinding) датуль, пакуль інжынеры Red Hat не вырашылі рэалізаваць іх у складзе самай платформы, а не як дадатковы функцыянал OpenShift. Ці не баіцца Red Hat паляпшаць Kubernetes? Вядома няма, бо Red Hat строга прытрымліваецца прынцыпаў адкрытага кода, а не гуляе ў гульні Open Core. Паляпшэнні і навіны, якія рэалізуюцца на ўзроўні супольнасцяў распрацоўкі, а не па прынцыпе прапрыетарнасці, становяцца больш жыццяздольнымі і атрымліваюць шырэйшае распаўсюджванне, што выдатна ўзгадняецца з нашай галоўнай мэтай - зрабіць софт з адчыненым кодам больш карысным для нашых кліентаў.
- Палітыкі бяспекі для pod'ов (Pod Security Policies). Першапачаткова гэтая канцэпцыя бяспечнага выканання прыкладанняў усярэдзіне pod'ов была рэалізаваная ў OpenShift пад імем SCC (Security Context Constraints). І як і ў папярэднім прыкладзе, Red Hat вырашыла ўвесці гэтыя напрацоўкі ў склад адчыненага праекту Kubernetes, каб імі маглі карыстацца ўсё жадаючыя.
Гэты шэраг прыкладаў можна працягнуць, але мы толькі хацелі паказаць, што Red Hat рэальна імкнецца разьвіваць Kubernetes і рабіць яго лепш для ўсіх.
Зразумела, OpenShift гэта Kubernetes. А адрозненні ў чым? 🙂
Спадзяемся, што, дачытаўшы да гэтага месца, вы ўразумелі, што Kubernetes гэта асноўны кампанент OpenShift. Асноўны, але далёка не адзіны. Інакш кажучы, проста ўсталяваўшы Kubernetes, вы не атрымаеце платформу карпаратыўнага класа. Вам трэба будзе дадаць аўтэнтыфікацыю, сетку, бяспеку, маніторынг, кіраванне часопісамі і шматлікае іншае. Акрамя таго, давядзецца зрабіць нялёгкі выбар з вялікай колькасці даступных інструментаў (каб ацаніць разнастайнасць экасістэмы, проста зірніце ) і неяк забяспечыць узгодненасць і зладжанасць, каб яны працавалі як адно цэлае. Акрамя таго, вам рэгулярна давядзецца выконваць абнаўленне і рэгрэсійнае тэсціраванне пры выхадзе новай версіі любога з выкарыстоўваных кампанентаў. Гэта значыць, апроч стварэння і суправаджэння самой платформы, вам трэба будзе займацца яшчэ і ўсім гэтым софтам. Ці наўрад тут застанецца шмат часу на рашэнне бізнэс-задач і дасягненне канкурэнтных пераваг.
А вось у выпадку з OpenShift кампанія Red Hat бярэ ўсе гэтыя складанасці на сябе і проста дае вам функцыянальна скончаную платформу, куды ўваходзіць не толькі сам Kubernetes, але і ўвесь камплект неабходных прылад з адчыненым кодам, якія ператвараюць Kubernetes у сапраўднае рашэнне карпаратыўнага класа, якое можна адразу ж і зусім спакойна запускаць у прадакшн. І вядома ж, калі ў вас ёсць нейкія свае тэхналагічныя стэкі, тыя вы можаце ўбудаваць OpenShift ва ўжо наяўныя рашэнні.
Зірніце на малюнак вышэй: усё, што знаходзіцца па-за прастакутнікам Kubernetes, - гэта тыя вобласці, дзе Red Hat дадае функцыянал, якога ў Kubernetes няма, што завецца, by-design. І зараз мы разгледзім асноўныя з гэтых абласцей.
1. Надзейная АС у якасці асновы: RHEL CoreOS ці RHEL
Red Hat ужо больш за 20 гадоў з'яўляецца вядучым пастаўшчыком Linux-дыстрыбутываў для крытычна важных бізнес-прыкладанняў. Напрацаваны і ўвесь час які абнаўляецца ў гэтай вобласці досвед дазваляе нам прапанаваць па-сучаснасці надзейную і давераную аснову для прамысловай эксплуатацыі кантэйнераў. RHEL CoreOS выкарыстоўвае тое ж ядро, што і RHEL, але аптымізавана перш за ўсё для такіх задач, як выкананне кантэйнераў і праца ў кластарах Kubernetes: яе паменшаны памер і неподверженность зменам (immutability) спрашчае ўстаноўку кластараў, аўтамаштабаванне, разгортванне выпраўленняў і т. д. Усе гэтыя функцыі робяць яе ідэальнай асновай для атрымання аднаго і таго ж карыстацкага досвед пры працы з OpenShift у самых розных вылічальных асяроддзях, ад «голага жалеза» да прыватнага і публічнага аблокі.
2. Аўтаматызацыя ІТ-аперацый
Аўтаматызацыя працэсаў усталёўкі і аперацый другога дня (гэта значыць паўсядзённай эксплуатацыі) - гэта канёк OpenShift, якія значна палягчае адміністраванне, абнаўленне і падтрыманне працы кантэйнернай платформы на найвысокім узроўні. Гэта дасягаецца за рахунак падтрымкі Kubernetes-аператараў на ўзроўні ядра OpenShift 4.
OpenShift 4 - гэта таксама і цэлая экасістэма рашэнняў на аснове Kubernetes-аператараў, распрацаваных як самой Red Hat, так і іншымі партнёрамі (гл. Red Hat, ці крама аператараў , створаны Red Hat для іншых распрацоўшчыкаў).
У склад інтэграванага каталога OpenShift 4 уваходзіць больш за 180 Kubernetes-аператараў
3. Інструменты для распрацоўшчыкаў
Пачынальна з 2011 гады, OpenShift даступная ў выглядзе платформы PaaS (Platform-as-a-Service), якая значна спрашчае жыццё распрацоўнікам, дапамагае ім засяродзіцца на стварэнні кода і прапануе ўбудаваную падтрымкі такіх моў праграмавання, як Java, Node.js, PHP, Ruby, Python, Go, а таксама сэрвісы бесперапыннай інтэграцыі і дастаўкі CI/CD, базы дадзеных і т. п. OpenShift 4 прапануе , Які ўключае больш за 100 сэрвісаў на аснове Kubernetes-аператараў, распрацаваных Red Hat і нашымі партнёрамі.
У адрозненне ад Kubernetes, у OpenShift 4 ёсць спецыяльны графічны інтэрфейс (), які дапамагае распрацоўнікам без лішніх намаганняў разгортваць у сваіх прасторах імёнаў прыкладання з розных крыніц (git, знешнія рэестры, Dockerfile і г. д) і наглядна візуалізуюць сувязі паміж кампанентамі прыкладання.
Акрамя таго, OpenShift прапануе набор прылад распрацоўкі Codeready, куды, у прыватнасці, уваходзіць , цалкам кантэйнерызаваная IDE з вэб-інтэрфейсам, якая працуе непасрэдна па-над OpenShift і рэалізуе падыход «IDE-як сэрвіс». З іншага боку, для тых, хто жадае працаваць строга ў лакальным рэжыме, ёсць Codeready Containers - поўнафункцыянальная версія OpenShift 4, якую можна разгарнуць на наўтбуку.
Інтэграваная "IDE як сэрвіс" для эфектыўнай распрацоўкі на платформе Kubernetes/OpenShift
Прама са скрынкі OpenShift прапануе паўнавартасную сістэму CI/CD, альбо на аснове кантэйнерызаванага Jenkins і плагіна для працы з канвеерамі, альбо арыентаваную на Kubernetes CI/CD-сістэму (пакуль у версіі Tech preview). Абодва гэтых рашэнні цалкам інтэгруюцца з кансоллю OpenShift, дазваляючы запускаць трыгеры канвеераў, праглядаць разгортванні, часопісы і т. д.
4. Інструменты для прыкладанняў
OpenShift дазваляе разгортваць як традыцыйныя stateful-прыкладанні, так і воблачна-арыентаваныя рашэнні на базе новых архітэктур, накшталт мікрасэрвісаў ці serverless. Рашэнне OpenShift Service Mesh прама са скрынкі ключавыя для суправаджэння мікрасэрвісаў інструменты, як Istio, Kiali і Jaeger. У сваю чаргу, рашэнне OpenShift Serverless уключае ў сябе не толькі Knative, але і створаныя ў рамках сумеснай з Microsoft ініцыятывы прылады накшталт Keda для падавання функцый Azure на платформе OpenShift.
Інтэграванае рашэнне OpenShift ServiceMesh (Istio, Kiali, Jaeger) спатрэбіцца пры распрацоўцы мікрасэрвісаў
Каб скараціць разрыў паміж атрыманымі ў спадчыну прыкладаннямі і кантэйнерамі, OpenShift зараз дазваляе правесці міграцыю віртуальных машын на платформу OpenShift з дапамогай Container Native Virtualization (пакуль у версіі ў TechPreview), ператвараючы гібрыдныя прыкладанні ў рэальнасць і палягчаючы іх перанос паміж рознымі аблокі, як прыватнымі, публічнымі.
Віртуальная машына Windows 2019 Virtual, запушчаная на OpenShift праз Container Native Virtualization (пакуль у версіі Tech preview)
5. Інструменты для кластараў
У любой платформы карпаратыўнага класа павінны быць сэрвісы маніторынгу і цэнтралізаванага вядзення логаў, механізмы бяспекі, аўтэнтыфікацыі і аўтарызацыя, сродкі сеткавага кіравання. І OpenShift падае ўсё гэта са скрынкі, прычым усё гэта на 100% адчынены код, уключаючы такія рашэнні як ElasticSearch, Prometheus, Grafana. Усе гэтыя рашэнні ідуць у камплекце з інфармацыйнымі панэлямі, метрыкамі і абвесткамі, якія ўжо скампанаваны і настроены з улікам шырокага вопыту Red Hat у галіне маніторынгу кластараў, што дазваляе з першых жа хвілін эфектыўна кантраляваць і адсочваць працу вашай прадакшн-асяроддзя.
У OpenShift таксама штатна мае такія важныя для карпаратыўнага заказчыка рэчы, як аўтэнтыфікацыя з убудаваным правайдэрам oauth, інтэграцыя з правайдэрамі уліковых дадзеных, уключаючы LDAP, ActiveDirectory, OpenID Connect, і шматлікае іншае.
Папярэдне настроеная інфармацыйная панэль Grafana для маніторынгу кластара OpenShift
Больш за 150 папярэдне настроеных метрык і абвестак Prometheus для маніторынгу кластара OpenShift
Працяг варта
Багаты функцыянал рашэння і шырокі досвед Red Hat у вобласці Kubernetes – менавіта па гэтых чынніках OpenShift заняў дамінантнае становішча на рынку, як паказана на малюнку ніжэй (падрабязней ).
«На бягучы момант Red Hat лідзіруе на рынку з доляй у 44%.
Кампанія пажынае плён сваёй стратэгіі продажаў з актыўным удзелам у справах кліента, у рамках якой яна спачатку кансультуе і навучае карпаратыўных распрацоўшчыкаў, а затым пераходзіць да манетызацыі па меры таго, як прадпрыемства пачынае ўкараняць кантэйнеры ў прадакшн ».
(Крыніца: )
Спадзяемся, вам спадабаўся гэты артыкул. У наступных пастах з гэтай серыі мы падрабязней спынімся на перавагі OpenShift у параўнанні Kubernetes у кожнай з разгледжаных тут катэгорый.
Крыніца: habr.com