«Каква е разликата между Kubernetes и OpenShift?» – този въпрос се задава с завидна постоянност. Всъщност, това е все едно да питаш каква е разликата между автомобил и двигател. Ако продължим аналогията, автомобилът е готов продукт, който може да се използва веднага, буквално: качваш се и тръгваш. От друга страна, за да може двигателят да те заведе на някъде, той първо трябва да бъде допълнен с множество други неща, за да получиш същия автомобил.
Затова Kubernetes е такъв двигател, около който е сглобен автомобил (платформа) с марка OpenShift, който те отвежда до целта.
В тази статия искаме да напомним и да разгледаме малко по-подробно следните ключови моменти:
- Kubernetes е сърцето на платформата OpenShift И това е 100% сертифициран Kubernetes, с напълно отворен код и без никаква собственост. Накратко:
- API за клъстера OpenShift е 100% 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, но на стандартната Kubernetes утилита kubectl явно й липсват функционалност и удобство. Затова Red Hat е добавил полезни функции и инструменти за команден ред, като 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, програмните корекции обикновено излизат в следващия релиз, понякога обхващат един или два предишни междинни релиза, което дава обхват на всичко преди 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 по замисъл. Сега ще разгледаме основните от тези области.
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 Service Mesh (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
