Kubernetes vs. CloudFoundry [закрито]

Наступна версія CloudFoundry / Diego запропонує вбудовану підтримку контейнерів Docker, які будуть організовані через декілька хостів [ посилання ]. Це звучить дуже схоже на Kubernetes.

Звичайно, проблема, яку намагається вирішити Кубернетес, є більш загальною, де CloudFoundry більше зосереджена на розробці додатків. Однак для мене це здається, що обидва прямують у схожий напрямок, і CloudFoundry додає набагато більше функцій поверх простої оркестрації.

Тож мені цікаво випадків використання, коли Kubernetes додав би більше цінності, ніж CloudFoundry?

Як і CloudFoundry (минулий), і Kubernetes (теперішній) комітет, я, мабуть, однозначно кваліфікований, щоб відповісти на це.

PaaS-подібний

Мені подобається називати CloudFoundry "Application PaaS", а Kubernetes - "Container PaaS", але відмінність є досить тонким і текучим, враховуючи, що обидва проекти змінюються з часом, щоб конкурувати на одних і тих же ринках.

Відмінність між ними полягає в тому, що CF має інсценізаційний шар, який займає (12-факторний) користувальницький додаток (наприклад, jar або gem) та збірний пакет у стилі Heroku (наприклад, Java + Tomcat або Ruby) і видає крапельку (аналогічну до Зображення Докера). CF не піддає користувачу інтерфейс для контейнерізації, але Kubernetes це робить.

Аудиторія

Основна аудиторія CloudFoundry - це розробники корпоративних програм, які хочуть розгорнути 12-факторні програми без стану, використовуючи збірки в стилі Heroku.

Аудиторія Kubernetes трохи ширша, включаючи як програми без громадянства, так і державні розробники сервісів, які надають власні контейнери.

Ця різниця може змінитися в майбутньому:

• CloudFoundry може почати приймати зображення докера ( Решітка приймає зображення Docker ).
• Kubernetes може додати шар генерації зображень ( OpenShift робить щось подібне ).

Порівняння функцій

По мірі дозрівання та конкуренції обох проектів їх схожість та відмінності будуть змінюватися. Тому візьміть наступне порівняльне означення із зерном солі.

І CF, і K8 мають багато подібних функцій, таких як контейнери, простір імен, автентифікація,

Конкурентні переваги Kubernetes:

• Групуйте та масштабуйте стручки контейнерів, які мають спільний мережевий стек, а не просто масштабування незалежно
• Принесіть власний контейнер
• Державний шар стійкості
• Більша, більш активна спільнота OSS
• Більш розширювана архітектура із змінними компонентами та сторонніми плагінами
• Безкоштовний веб-інтерфейс

Конкурентні переваги CloudFoundry:

• Дозріла автентифікація, групування користувачів та підтримка багатьох орендарів [x]
• Візьміть власний додаток
• Включений балансир навантаження
• Розгорнутий, розширений і підтримуваний живим BOSH [x]
• Надійний журнал та агрегація показників [x]
• Інтерфейс інтерфейсу підприємства [x]

[x] Ці функції не входять до складу Дієго та не входять до решітки.

Розгортання

Однією з конкурентних переваг CloudFoundry є те, що він має зрілий двигун розгортання, BOSH, який забезпечує такі функції, як масштабування, відновлення та моніторинг основних компонентів CF. BOSH також підтримує багато шарів IaaS з абстрагуванням постачальника хмарних постачальників. На жаль, крива навчання та управління конфігурацією розгортання BOSH - кошмар. (Як підкоряючий BOSH, я думаю, що можу це сказати з точністю.)

Абстракція розгортання Kubernetes все ще знаходиться в зародковому стані. У основному репо доступні кілька цільових середовищ, але вони не всі працюють, добре перевірені або підтримуються первинними розробниками. Це здебільшого зріла річ. Можна очікувати, що з часом воно покращиться та зросте абстракція. Наприклад, Kubernetes в DCOS дозволяє розгортати Kubernetes в існуючий кластер DCOS за допомогою однієї команди.

Історичний контекст

Дієго - переписуючий агент із виконання крапель CF. Спочатку вона була розроблена ще до того, як було оголошено Kubernetes, і вона набула більшого масштабу, оскільки розвивався конкурентний ландшафт. Початкова його мета полягала у створенні крапель (користувацьке додаток + CF buildpack) та запусканні їх у Warden (перейменований Garden при переписуванні в Go) контейнери. З моменту свого створення він також був перекомплектований як Решітка , яка є дещо обласною програмою CloudFoundry (хоча таку назву взяв уже існуючий проект). З цієї причини решітка дещо схожа на іграшки, оскільки свідомо скорочує аудиторію та сферу використання, явно не вистачаючи функцій, які б зробили це "готовим до підприємств". Особливості, які CF вже надає. Почасти це тому, що решітка використовується для тестування основних компонентів, не маючи накладних витрат на складніші CF, але ви також можете використовувати решітки у внутрішніх середовищах з високим рівнем довіри, де безпека та багатожитловість не викликають особливих проблем. .

Варто також згадати, що CloudFoundry та Warden (його двигун з контейнерами) передували Докері також пару років.

Kubernetes, з іншого боку, є відносно новим проектом, розробленим Google на основі багаторічного використання контейнерів з BORG та Omega. Kubernetes можна розглядати як контейнерне оркестрування 3-го покоління в Google, так само, як Дієго - це контейнерне оркестрування 3-го покоління в Pivotal / VMware (v1 написано на VMware; v2 в VMware з Pivotal Labs help; v3 в Pivotal після того, як він взяв на себе проект) .

Cloud Foundry - це чудовий інструмент, припускаючи, що ви готові завжди працювати в рамках обмежень пропозиції, оскільки це дуже впевнено / прописано. Веб-інтерфейс є цікавим для першого дня, але він рідко використовується після того, як ви почнете працювати з клієнтом і налаштували ваш конвеєр CI / CD. Я виявив, що Cloud Foundry чудовий, доки не з’являться випадки використання, які легко не підтримуються повністю в Cloud Foundry. Надання цих випадків використання може затримати проекти, коли ви намагаєтеся вирішити ці проблеми, в результаті ви втрачаєте видимість інфраструктури та підтримуєте переваги тих компонентів, які потім в основному працюють за межами Cloud Foundry (подумайте про безліч баз даних, kafka, hadoop, cassandra і т.д.) Я підозрюю, що з часом імпульс навколо Докера та негнучкість Cloud Foundry призведе користувачів до Kubernetes, Mesos або Docker Swarm / Центр обробки даних. Цілком можливо, що Cloud Foundry може наздогнати цих трьох, але це може здатися малоймовірним через популярність цих проектів з відкритим кодом.

Важко відповісти, чому компанія створила б продукт, який істотно схожий на інший продукт. Причин дуже багато. Можливо, вони вже почали його використовувати і вкладають у це. Можливо, вони (CF) думають, що Kubernetes зроблено погано або неправильно переглядають API / модель / деталі. Можливо, вони думають, що вони можуть рухатись швидше, якщо контролювати весь продукт, а не робити внесок.

Зрозуміло, я кажу це як розробник Kubernetes - можна задати ті самі запитання Kubernetes vs Mesos, Amazon ECS проти Kubernetes або Docker Swarm проти Kubernetes.

Я сподіваюся, що з часом ми всі рухаємось в одному напрямку і можемо співпрацювати більше і витрачати менше часу на винахідлення роботи один одного.

Що стосується Kubernetes - в центрі уваги розробники додатків: прості та потужні примітиви, які дозволяють вам створювати та розгортати програми в масштабі дуже швидко. Ми спираємось на наш досвід (ну, Google) із подібними технологіями, щоб намітити наш курс. Інші люди матимуть різний досвід чи думку.

На мою думку, істотною відмінністю є підхід, який вони застосовують:

CF автоматично створює час виконання з 3-х компонентів: користувач надав двійковий додаток, збірний пакет, що містить проміжне програмне забезпечення, необхідне для запуску програми та зображення ОС (стовпець). Користувач CF (розробник) повинен надавати лише бінарний додаток (наприклад, виконуваний файл jar). CF піклується про інше, тобто упаковку та запуск програми.

Kubernetes очікує від розробника Docker зображень, які містять проміжне програмне забезпечення та ОС, вже вбудовані та готові до запуску. Для цього Kubernetes "маніфест розгортання" (наприклад, діаграма Helm) описує не лише одне додаток чи послугу, а й усі [мікро] сервіси, які містять ваше рішення під час виконання. Ви подаєте єдиний декларативний опис вашого часу виконання, і Kubernetes піклується про те, щоб фактичний стан виконання відповідав наданому вами опису.

Таким чином, підхід CF дозволяє йому вирішувати такі випадки використання, як "заміна ОС на виправлений недолік безпеки у всій хмарі без простоїв для ваших послуг". Але він також зосереджений на сервісі на розгортання служби замість декларативного опису цільового "ідеального" режиму роботи вашої системи.

Cloud Foundry - це хмарні обчислювальні системи з відкритим кодом для платформи. Cloud Foundry дозволяє розгортати проекти в різних просторах, а також прив'язує будь-яку хмарну службу до вашої програми.

Kubernete більше схожий на орнаментальний інструмент для контейнерів (стручків), який робить автоматизацію розгортання, масштабування та управління контейнерними програмами. Він використовує термін стручки для визначення контейнера або групи контейнерів.

Будь-яке розвернення кубернетів потребує щонайменше двох ресурсів:

1) розміщення.yaml: Цей ресурс визначає, яку версію зображення потрібно забрати з реєстру контейнерів, реплікацій (реплік стручка), стратегії розгортання, масштабування та зондів тощо.

2) service.yaml: це інтерфейс між вашими внутрішніми стручками та зовнішнім світом, весь зовнішній трафік буде прослуховувати порт, визначений на цьому ресурсі, звідки він розподіляє навантаження на внутрішні стручки.

Більше ресурсів - це введення, яке надає кубернети, що управляє зовнішнім доступом до служб у кластері, як правило, http. Через Ingress ви можете забезпечити балансування завантаження, завершення SSL та віртуальний хостинг на основі імен.

Більше про kubernetes ви можете знайти нижче: https://kubernetes.io/docs/

[pcf vs kubernetes] [1] Різниця між pcf ​​та kubernetes

                                PCF

(абстракція платформи на рівні програми) • Pivotal Cloud Foundry - це абстракція високого рівня хмарних програм.

• У нас є абстракція платформи на рівні програми, побудова та розгортання повністю налаштованої програми

• PCF - один із прикладів програми "PaaS" (також званий програмою Cloud Foundry Application Runtime)

• Розробник підтримує додаток У майбутньому

• Ідеально підходить для нових програм, обласних додатків. Для команд, що працюють з короткими життєвими циклами та частими випусками, PCF пропонує чудовий продукт.

                       Kubernetes 

(абстракція платформи на рівні контейнерів) • Kubernetes - це планувальник контейнерів або оркестратор.

• У нас є абстракція платформи на рівні контейнерів, побудова та розгортання контейнерів як частина повноцінної програми.

• Kubernetes - це "контейнер" PaaS (іноді його називають CaaS).

• За допомогою інструментів для оркестрування контейнерів розробник створює та підтримує контейнер у майбутньому.

• Для нового застосування більше роботи для ваших інженерних команд та зниження продуктивності

Після 4 років тенденції виглядають приблизно так:

У наші дні кластери Kubernetes стають по-справжньому дешевими, а середовище інструментарію для кубернетів - краще.

Крім того, більшість конкурентних функцій, перелічених іншими плакатами, цілком легко копіювати всередині кубернетів.