Кубернетес против CloudFoundry

Ответ 1

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

PaaS-как

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

Различие между ними состоит в том, что CF имеет промежуточный уровень, который принимает (12-факторное) пользовательское приложение (например, jar или gem) и buildpack стиля Heroku (например, Java + Tomcat или Ruby) и создает капельку ( аналогично изображению Докера). CF не предоставляет пользователю интерфейс контейнеризации, но Kubernetes делает.

Аудитория

Основная аудитория CloudFoundry - это разработчики корпоративных приложений, которые хотят развернуть 12-факторные приложения без состояния, используя сборные пакеты в стиле Героку.

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

Это различие может измениться в будущем:

• CloudFoundry может начать принимать изображения докеров (Решетка принимает изображения Docker).
• Кубернетес может добавить слой генерации изображения (OpenShift делает что-то вроде этого).

Сравнение функций

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

Оба CF и K8s имеют много похожих функций, таких как контейнеризация, пространство имен, аутентификация,

Конкурентные преимущества Кубернете:

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

Облачные конкурентные преимущества:

• Зрелая аутентификация, группировка пользователей и поддержка нескольких арендаторов [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) контейнерах. С момента своего создания он также был переупакован как Lattice, который является как-то вроде CloudFoundry-lite (хотя это имя было принято существующий проект). По этой причине, Lattice похожа на игрушку, поскольку она преднамеренно уменьшает аудиторию пользователей и область видимости, явно пропускает функции, которые сделают ее "готовой к работе". Функции, которые уже предоставляет CF. Частично это объясняется тем, что Lattice используется для тестирования основных компонентов без каких-либо накладных расходов от более сложного CF, но вы также можете использовать Lattice во внутренних средах с высоким уровнем доверия, где безопасность и многопользовательская аренда не так важны.

Также стоит упомянуть, что CloudFoundry и Warden (его контейнерный движок) предшествовали Докеру, а через пару лет.

Kubernetes, с другой стороны, является относительно новым проектом, который был разработан Google в течение многих лет использования контейнеров с BORG и Omega. Kubernetes можно было рассматривать как оркестровку 3-го поколения в Google, так же, как и Diego - 3-я поколение контейнерных оркестровок в Pivotal/VMware (v1 написан на VMware v2 в VMware с помощью Pivotal Labs, v3 в Pivotal после того, как он взял на себя проект).

Ответ 2

Cloud Foundry - отличный инструмент, предполагающий, что вы готовы всегда работать в рамках ограничений предложения, поскольку он очень упрям ​​/предписан. Веб-интерфейс удобен для просмотра в первый день, но редко используется после того, как вы начинаете работать с клиентом и настроили конвейер CI/CD. Я обнаружил, что Cloud Foundry отлично работает, пока не появятся всплывающие окна, которые не полностью поддерживаются в Cloud Foundry. Предоставление этих вариантов использования может задерживать проекты при попытке решить эти проблемы, в результате чего вы теряете видимость инфраструктуры и поддерживаете преимущества тех компонентов, которые в основном работают за пределами Cloud Foundry (думаю, что несколько баз данных, kafka, hadoop, cassandra, и т.д.). С течением времени я подозреваю, что момент, связанный с Docker, и негибкость Cloud Foundry приведут пользователей к Kubernetes, Mesos или Docker Swarm/Datacenter. Возможно, Cloud Foundry может догнать эти три, но это вряд ли будет связано с популярностью этих проектов с открытым исходным кодом.

Ответ 3

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

Конечно, я говорю это как разработчик Kubernetes - можно задавать те же вопросы Кубернеса против Мезоса, Amazon ECS против Kubernetes, или Docker Swarm vs Kubernetes.

Я надеюсь, что со временем все мы будем двигаться в одном направлении и можем больше сотрудничать и тратить меньше времени на новое творение.

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

Ответ 4

Существенным отличием, на мой взгляд, является подход, который они используют:

CF автоматически создает среду выполнения из 3 компонентов: двоичный файл приложения, предоставленный пользователем, пакет сборки, содержащий промежуточное программное обеспечение, необходимое для запуска приложения, и образ ОС (stemcell). Пользователь CF (разработчик) должен предоставить только двоичный файл приложения (например, исполняемый файл JAR). CF заботится об остальном, то есть упаковке и запуске приложения.

Kubernetes ожидает от разработчика образов Docker, которые содержат промежуточное ПО и ОС, уже встроенные и готовые к запуску. Для этого в "манифесте развертывания" Kubernetes (например, диаграмма Хелма) описывается не только одно приложение или служба, но и все [микро] службы, которые составляют ваше решение во время выполнения. Вы отправляете одно декларативное описание своей среды выполнения, а Kubernetes заботится о том, чтобы фактическое состояние среды выполнения соответствовало предоставленному вами описанию.

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

Ответ 5

Cloud Foundry является облачной вычислительной системой с открытым исходным кодом. Cloud Foundry позволяет развертывать проекты в разных пространствах, а также привязывает любой облачный сервис к вашему приложению.

Kubernete больше похож на инструмент для украшения контейнеров (контейнеров), который автоматизирует развертывание, масштабирование и управление контейнеризованными приложениями. Он использует термин pods для определения контейнера или группы контейнеров.

Любое развертывание kubernetes требует как минимум двух ресурсов:

1) deploy.yaml: этот ресурс определяет, какую версию образа необходимо выбрать из реестра контейнера, наборов реплик (pod-реплик), стратегии развертывания, масштабирования, зондов и т.д.

2) service.yaml: это интерфейс между вашими внутренними модулями и внешним миром, весь внешний трафик будет прослушивать порт, определенный в этом ресурсе, откуда он распределяет нагрузку на внутренние модули.

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

Больше о kubernetes вы можете найти ниже: https://kubernetes.io/docs/

Ответ 6

[pcf vs kubernetes] [1] Разница между pcf и kubernetes

                                PCF

(абстракция платформы на уровне приложений) • Pivotal Cloud Foundry - это высокоуровневая абстракция разработки приложений на основе облака.

• У нас есть абстракция платформы на уровне приложения, создание и развертывание полностью настроенного приложения.

• PCF является одним из примеров PaaS "приложения" (также называемого средой исполнения приложения Cloud Foundry)

• Разработчик поддерживает приложение В будущем

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

                       Kubernetes 

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

• У нас есть абстракция платформы на уровне контейнеров, сборка и развертывание контейнеров как часть законченного приложения.

• Kubernetes - это "контейнерный" PaaS (иногда называемый CaaS).

• Используя инструменты управления контейнером, разработчик создает и затем поддерживает контейнер в будущем.

• Для нового приложения, больше работы для вашей команды инженеров и снижение производительности

Ответ 7

KUBERNETES ENGINE

Kubernetes Engine - это управляемая, готовая к работе среда для развертывания контейнерных приложений. Он привносит наши последние инновации в производительность труда разработчиков, эффективность использования ресурсов, автоматизацию операций и гибкость открытого исходного кода, чтобы ускорить ваше время выхода на рынок.

Запущенный в 2015 году Kubernetes Engine опирается на опыт работы Google с такими сервисами, как Gmail и YouTube, в контейнерах более 12 лет. Kubernetes Engine позволяет вам быстро приступить к работе с Kubernetes, полностью избавляя от необходимости устанавливать, управлять и эксплуатировать ваши собственные кластеры Kubernetes.

Kubernetes Engine обеспечивает быструю разработку и итерацию приложений, упрощая развертывание, обновление и управление вашими приложениями и сервисами. Kubernetes Engine не только для приложений без сохранения состояния; Вы можете подключить постоянное хранилище и даже запустить базу данных в своем кластере. Просто опишите вычислительные ресурсы, память и ресурсы хранения, необходимые для контейнеров приложений, и Kubernetes Engine обеспечит и автоматически управляет базовыми облачными ресурсами. Поддержка аппаратных ускорителей упрощает запуск машинного обучения, графических процессоров общего назначения, высокопроизводительных вычислений и других рабочих нагрузок, в которых используются специализированные аппаратные ускорители.

Управляйте своей средой с помощью встроенной панели управления Kubernetes Engine в консоли Google Cloud. Используйте регулярные проверки работоспособности для обнаружения и замены зависших или сбойных приложений внутри ваших развертываний. Стратегии репликации контейнера, мониторинг и автоматическое исправление помогают обеспечить высокую доступность ваших услуг и обеспечить бесперебойную работу ваших пользователей. Инженеры по надежности сайтов Google (SRE) постоянно отслеживают ваш кластер и его вычислительные ресурсы, сетевые ресурсы и ресурсы хранения, поэтому вам не нужно делать это, давая вам время сосредоточиться на своих приложениях.

Переходите от одной машины к тысячам: автоматическое масштабирование Kubernetes Engine позволяет вам справляться с повышенным спросом пользователей на ваши услуги, обеспечивая их доступность, когда это наиболее важно. Затем уменьшите масштаб в периоды бездействия, чтобы сэкономить деньги, или запланируйте пакетные задания с низким приоритетом, чтобы использовать свободные циклы. Kubernetes Engine поможет вам максимально эффективно использовать пул ресурсов.

Подключайтесь и изолируйте кластеры независимо от того, где вы находитесь, с помощью детальных сетевых политик, используя Global Virtual Private Cloud (VPC) в Google Cloud. Используйте общедоступные службы за одним глобальным произвольным IP-адресом для плавной балансировки нагрузки. Защита от DOS и других типов краевых атак на ваши контейнеры.

Kubernetes Engine использует сертифицированный Kubernetes, обеспечивающий переносимость через облака и локальные сети. Здесь нет привязки к поставщику: вы можете извлекать свои приложения из Kubernetes Engine и запускать их везде, где поддерживается Kubernetes, в том числе на ваших собственных локальных серверах. Вы можете адаптировать такие интеграции, как мониторинг, ведение журнала и CI/CD, используя Google Cloud Platform (GCP) и сторонние решения в экосистеме.

ОБЛАКА ФОНДРИ

Cloud Foundry имеет контейнерную архитектуру, которая запускает приложения на любом языке программирования. Развертывание приложений на CF с использованием существующих инструментов и без изменения кода. Создавать, развертывать и управлять кластерами Kubernetes высокой доступности с помощью CF BOSH в любом облаке.

Приложения, развернутые в Cloud Foundry, получают доступ к внешним ресурсам через API Open Service Broker. Смотрите доступные услуги и интеграции в The Foundry.

Cloud Foundry обладает высокой адаптивностью и сможет противостоять изменениям в технологиях, благодаря чему вы сможете внедрить новые инструменты, языки или платформы в будущем.

Отключая приложения от инфраструктуры, вы можете принимать индивидуальные решения о том, где разместить рабочие нагрузки - в помещении, в общедоступных облаках или в управляемых инфраструктурах - и перемещать эти рабочие нагрузки по мере необходимости в считанные минуты, без изменений в приложении.

Cloud Foundry не нарушит ваш текущий рабочий процесс. Он совместим с технологиями и инструментами, которые вы используете сегодня - будь то AWS, Docker, Kubernetes, Java или .NET, - и практически с любым в вашей текущей среде.

Cloud Foundry - это проект с открытым исходным кодом, модель открытого вклада и открытого управления, которая дает пользователям максимальную гибкость, позволяющую избежать блокировки поставщиков. Мы помогаем наблюдать за заслуживающим доверия сообществом разнообразных умов, которые собрались вместе, чтобы решать все виды задач. Больше перспектив и дивергентное мышление означают более сильный код.

Ответ 8

Через 4 года тренды выглядят так:

В наши дни кластеры Kubernetes становятся действительно дешевыми, а среда для kubernetes лучше.

Кроме того, большинство конкурентных возможностей, перечисленных другими авторами, в наши дни очень легко копировать внутри кубернетов.