«Каква е разликата между Kubernetes и OpenShift?» – този въпрос възниква с завидна постоянство. Всъщност, това е все едно да питате каква е разликата между автомобил и двигател. Ако продължим аналогията, автомобилът е готов продукт, който можете да използвате веднага, буквално: седнете и тръгнете. От друга страна, за да може двигателят да ви отведе някъде, първо трябва да бъде допълнен с множество други неща, за да получите същия автомобил.
Затова Kubernetes е двигателят, около който е сглобен автомобилът (платформата) OpenShift, който и ви отведе до целта.
В тази статия искаме да припомним и малко по-подробно да разгледаме следните ключови моменти:
- Kubernetes е сърцето на платформата OpenShift И това е на 100% сертифициран Kubernetes, с напълно отворен код и без никаква проприетарност. Вкратце:
- API за клъстера OpenShift е стoпрoцентен 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, плюс предлага няколко полезни помощни средства, които ще бъдат от полза при изпълнението на редица задачи. Но първо, малко по-подробно за съвместимостта между OC и kubectl:
Команди на kubectl
Команди на OC
kubectl get pods
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, но стандартният инструмент kubectl очевидно ми липсва функционалност и удобство. Затова Red Hat добави полезни функции и инструменти за команден ред към Kubernetes, като OC (съкратено от OpenShift client) и ODO (OpenShift DO, този инструмент е предназначен за разработчици).
1. Инструментът OC – по-мощен и удобен вариант на Kubectl
Например, за разлика от kubectl, той позволява създаването на нови пространства от имена и лесно превключване на контекста, а също така предлага редица полезни команди за разработчиците, например за изграждане на контейнерни образи и разгръщане на приложения директно от изходния код или двоични файлове (Source-to-image, s2i).
Нека да разгледаме примери как вградените помощни функции и разширената функционалност на инструмента OC помагат за опростяване на ежедневната работа.
Пример първи – управление на пространства от имена. Във всеки Kubernetes клъстер винаги има няколко пространства от имена. Обикновено те се използват за създаване на девелоперски и продукционни среди, но могат да се използват и за даване на на всеки разработчик персонална "песъчница". На практика това води до необходимостта разработчика често да превключва между пространства от имена, тъй като kubectl работи в контекста на текущото пространство. Затова при работа с kubectl, хората активно използват помощни скриптове. При използването на 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 / odo
$> git clone
$> odo create component nodejs myapp
$> odo 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 програмните корекции обикновено излизат в следващия релиз, понякога обхващат един или два предходни междинни релиза, което дава обхват от шест месеца назад.
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, известна като по замисъл. Сега ще разгледаме основните от тези области.
1. Надеждена ОС като основа: RHEL CoreOS или RHEL
Red Hat е водещ доставчик на Linux дистрибуции за критични бизнес приложения вече повече от 20 години. Опитът, натрупан и постоянно обновяван в тази област, ни позволява да предложим наистина надеждна и доверена основа за промишлена експлоатация на контейнери. 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
