«У чому різниця між 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
ВИКЛИТИ 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 немає, що називається, 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