„Каква е разликата между Kubernetes и OpenShift?“ – този въпрос възниква със завидна последователност. Въпреки че в действителност това е като да питате как се различава колата от двигателя. Ако продължим аналогията, тогава колата е завършен продукт, можете да я използвате веднага, буквално: качете се и тръгвайте. От друга страна, за да те закара един двигател до някъде, първо трябва да се допълни с много други неща, за да се получи в крайна сметка същата кола.
Следователно Kubernetes е двигателят, около който се сглобява автомобилът (платформата) на марката OpenShift, който ви отвежда до вашата цел.
В тази статия искаме да ви напомним и разгледаме малко по-подробно следните ключови моменти:
- Kubernetes е сърцето на платформата OpenShift и е 100% сертифициран Kubernetes, напълно отворен код и без ни най-малка патентована природа. Накратко:
- OpenShift cluster API е XNUMX% 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 вземете шушулки
oc вземете подс
kubectl получава пространства от имена
oc получите пространства от имена
kubectl create -f deployment.yaml
oc create -f deployment.yaml
Ето как изглеждат резултатите от използването на kubectl в OpenShift API:
• kubectl get pods – връща pods според очакванията.
• kubectl get namespaces – връща пространства от имена според очакванията.
Командата kubectl create -f mydeployment.yaml създава ресурси на kubernetes точно както на всяка друга платформа на Kubernetes, както е показано във видеото по-долу:
С други думи, всички API на Kubernetes са напълно налични в OpenShift, като същевременно поддържат 100% съвместимост. Защото .
OpenShift добавя полезни функции към Kubernetes
API на Kubernetes са 100% налични в OpenShift, но на стандартната помощна програма на Kubernetes kubectl очевидно липсва функционалност и удобство. Ето защо Red Hat добави полезни функции и инструменти за команден ред към Kubernetes, като OC (съкращение от OpenShift client) и ODO (OpenShift DO, тази помощна програма е насочена към разработчици).
1. OC помощна програма - по-мощна и удобна версия на Kubectl
Например, за разлика от kubectl, той ви позволява да създавате нови пространства от имена и лесно да превключвате контексти, а също така предлага редица полезни команди за разработчиците, като изграждане на изображения на контейнери и внедряване на приложения директно от изходен код или двоични файлове (източник към изображение, s2i).
Нека да разгледаме примери за това как вградените помощници и разширената функционалност на помощната програма OC помагат за опростяване на ежедневната работа.
Първият пример е управлението на пространството от имена. Всеки клъстер на Kubernetes винаги има множество пространства от имена. Те обикновено се използват за създаване на среда за разработка и производство, но могат да се използват и за например предоставяне на всеки разработчик на лична пясъчна кутия. На практика това води до това, че програмистът трябва често да превключва между пространства от имена, тъй като kubectl работи в контекста на текущото пространство. Следователно, в случая с kubectl, хората активно използват помощни скриптове за това. Но когато използвате OC, за да превключите към желаното пространство, просто кажете „oc project namespace“.
Не помните как се нарича пространството от имена, от което се нуждаете? Няма проблем, просто напишете „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 клонинг
1- Създайте Dockerfile, който изгражда изображението от код
-----
ОТ възел
WORKDIR /usr/src/app
КОПИРАНЕ на пакет*.json ./
КОПИРАНЕ index.js ./
КОПИРАНЕ ./app ./app
ИЗПЪЛНЕТЕ npm install
EXPOSE 3000
CMD [ “npm”, “start” ] ————–
2- Ние изграждаме образа
$>podman build...
3- Влезте в регистъра
влизане в podman...
4- Поставете изображението в системния регистър
подман тласък
5- Създайте yaml файлове за внедряване на приложение (deployment.yaml, service.yaml, ingress.yaml) - това е абсолютният минимум
6- Разположете манифестни файлове:
Kubectl прилага -f.
OpenShift/oc
$> oc ново приложение – име на_нашето_приложение
OpenShift/odo
$>git клонинг
$> odo създайте компонент nodejs myapp
$>odo push
• Превключване на контекст: променете работното пространство на имената или работния клъстер.
Kubernetes/kubectl
1- Създайте контекст в kubeconfig за проекта „myproject“
2- kubectl set-context...
OpenShift/oc
oc проект "myproject"
Контрол на качеството: „Една интересна функция се появи тук, все още в алфа версия. Може би можем да го пуснем в производство?“
Представете си, че седите в състезателна кола и ви казват: „Инсталирахме нов тип спирачки и, честно казано, тяхната надеждност все още не е наред... Но не се притеснявайте, ние активно ще ги подобряваме по време на курса на първенството.” Как ви харесва тази перспектива? Ние в Red Hat някак не сме много доволни. 🙂
Затова се опитваме да задържим алфа версиите, докато станат достатъчно зрели и не направим задълбочено тестване в битка и смятаме, че са безопасни за използване. Обикновено всичко минава първо през етапа Dev Preview, след това през и едва тогава излиза като публично издание (GA), който вече е толкова стабилен, че е подходящ за производство.
Защо така? Тъй като, както при разработването на всеки друг софтуер, не всички първоначални идеи в Kubernetes достигат до финалната версия. Или го достигат и дори запазват предвидената функционалност, но реализацията им е коренно различна от тази в алфа версията. С хиляди и хиляди клиенти на Red Hat, използващи OpenShift за поддръжка на критични работни натоварвания, ние поставяме специален акцент върху стабилността на нашата платформа и дългосрочната поддръжка.
Red Hat се ангажира да пуска OpenShift често и да актуализира версията на Kubernetes, която идва с него. Например текущата версия на GA на OpenShift 4.3 към момента на писане включва Kubernetes 1.16, който е само с една единица зад версията на 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). Тази концепция за сигурно стартиране на приложения в подове първоначално беше внедрена в OpenShift под името SCC (Ограничения на контекста на сигурността). И както в предишния пример, 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 клъстери: неговият намален размер и неизменност улесняват настройването на клъстери, автоматично мащабиране, внедряване на пачове и т.н. Всички тези функции го правят идеална основа за предоставяне на едно и също потребителско изживяване с OpenShift в широк спектър от компютърни среди, от голо метално до частен и публичен облак.
2. Автоматизация на ИТ операциите
Автоматизирането на инсталационните процеси и операциите от ден 4 (т.е. ежедневните операции) е силната страна на OpenShift, което прави много по-лесно администрирането, актуализирането и поддържането на ефективността на контейнерната платформа на най-високо ниво. Това се постига чрез поддръжка на оператори на Kubernetes на ниво ядро на OpenShift XNUMX.
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 има специален GUI (), което помага на разработчиците без усилие да внедряват приложения от различни източници (git, външни регистри, Dockerfile и др.) в техните пространства от имена и ясно визуализира връзките между компонентите на приложението.
Освен това OpenShift предлага набор от инструменти за разработка Codeready, който по-специално включва , напълно контейнеризирана IDE с уеб интерфейс, който работи директно върху OpenShift и прилага подход IDE като услуга. От друга страна, за тези, които искат да работят стриктно в локален режим, има Codeready Containers, напълно функционална версия на OpenShift 4, която може да бъде внедрена на лаптоп.
Интегрирана IDE като услуга за ефективна разработка на платформата Kubernetes/OpenShift
OpenShift предлага пълна CI/CD система направо от кутията, базирана на контейнерен Jenkins и плъгин за работа с тръбопроводи или ориентирана към Kubernetes CI/CD система (в момента във версия за технически преглед). И двете решения се интегрират напълно с конзолата OpenShift, което ви позволява да стартирате тръбопроводни тригери, да преглеждате внедрявания, регистрационни файлове и др.
4. Инструменти за приложение
OpenShift ви позволява да внедрявате както традиционни приложения със състояние, така и базирани на облак решения, базирани на нови архитектури, като микроуслуги или без сървър. Решението OpenShift Service Mesh идва директно от кутията с ключови инструменти за поддържане на микроуслуги, като Istio, Kiali и Jaeger. От своя страна решението OpenShift Serverless включва не само Knative, но и инструменти като Keda, създадени като част от съвместна инициатива с Microsoft за предоставяне на Azure функции на платформата OpenShift.
Интегрираното решение OpenShift ServiceMesh (Istio, Kiali, Jaeger) ще бъде полезно при разработването на микроуслуги
За да се преодолее пропастта между наследени приложения и контейнери, OpenShift вече позволява миграция на виртуални машини към платформата OpenShift с помощта на Container Native Virtualization (в момента в TechPreview), превръщайки хибридните приложения в реалност и улеснявайки миграцията им между различни облаци, частни и публични.
Windows 2019 Виртуална виртуална машина, работеща на OpenShift чрез Container Native Virtualization (в момента във версия за технически преглед)
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 във всяка от категориите, обсъждани тук.
Източник: www.habr.com