Как коммитер CloudFoundry (в прошлом) и Kubernetes (в настоящее время), я, вероятно, обладаю уникальной квалификацией, чтобы ответить на этот вопрос.
PaaS-подобный
Мне нравится называть CloudFoundry «Application PaaS», а Kubernetes - «Container PaaS», но различие довольно тонкое и плавное, учитывая, что оба проекта со временем меняются, чтобы конкурировать на одних и тех же рынках.
Различие между ними в том, что CF имеет промежуточный уровень, который принимает (12-факторное) пользовательское приложение (например, jar или gem) и пакет сборки в стиле Heroku (например, Java + Tomcat или Ruby) и создает каплю (аналогично Образ Docker). CF не предоставляет пользователю интерфейс контейнеризации, в отличие от Kubernetes.
Зрительская аудитория
Основная аудитория CloudFoundry - это разработчики корпоративных приложений, которые хотят развертывать 12-факторные приложения без сохранения состояния с использованием пакетов сборки в стиле Heroku.
Аудитория Kubernetes немного шире, включая разработчиков приложений без сохранения состояния и разработчиков служб с отслеживанием состояния, которые предоставляют свои собственные контейнеры.
Это различие может измениться в будущем:
Сравнение характеристик
По мере развития и конкуренции обоих проектов их сходства и различия будут меняться. Так что возьмите следующее сравнение характеристик с недоверием.
И CF, и K8 имеют много схожих функций, таких как контейнеризация, пространство имен, аутентификация,
Конкурентные преимущества Kubernetes:
- Группируйте и масштабируйте поды контейнеров, которые используют общий сетевой стек, а не просто масштабируются независимо
- Принеси свой контейнер
- Слой сохраняемости с сохранением состояния
- Более широкое и активное сообщество OSS
- Более расширяемая архитектура с заменяемыми компонентами и сторонними плагинами
- Бесплатный веб-интерфейс
Конкурентные преимущества CloudFoundry:
- Зрелая аутентификация, группировка пользователей и поддержка мультитенантности [x]
- Принесите собственное приложение
- Включенный балансировщик нагрузки
- Развертывается, масштабируется и поддерживается BOSH [x]
- Надежное ведение журнала и агрегирование показателей [x]
- Корпоративный веб-интерфейс [x]
[x] Эти функции не являются частью Diego и не включены в Lattice.
Развертывание
Одним из конкурентных преимуществ CloudFoundry является наличие развитого механизма развертывания BOSH, который обеспечивает такие функции, как масштабирование, восстановление и мониторинг основных компонентов CF. BOSH также поддерживает множество уровней IaaS с подключаемой абстракцией облачного провайдера. К сожалению, обучение и управление конфигурацией развертывания BOSH просто кошмарны. (Как коммиттер BOSH, думаю, я могу сказать это с точностью.)
Абстракция развертывания Kubernetes все еще находится в зачаточном состоянии. В основном репозитории доступно несколько целевых сред, но не все они работают, хорошо протестированы или поддерживаются основными разработчиками. В основном это вопрос зрелости. Можно было ожидать, что со временем это улучшится и увеличится абстракция. Например, Kubernetes в DCOS позволяет развернуть Kubernetes в существующем кластере DCOS с помощью одной команды.
Исторический контекст
Диего - это переработанная версия программы CF's Droplet Execution Agent. Первоначально он был разработан до того, как был анонсирован Kubernetes, и по мере развития конкурентной среды приобрел больше возможностей. Первоначальной целью было создание дроплетов (пользовательское приложение + пакет сборки CF) и запуск их в контейнерах Warden (переименованных в Garden при переписывании в Go). С момента своего создания он также был переупакован как Lattice , который является чем-то вроде CloudFoundry-lite (хотя это имя было взято в существующем проекте.). По этой причине Lattice в некоторой степени похож на игрушку, поскольку он намеренно сократил пользовательскую аудиторию и объем, явно упустив функции, которые сделали бы ее «готовой для предприятий». Функции, которые уже предоставляет CF. Отчасти это связано с тем, что Lattice используется для тестирования основных компонентов без некоторых накладных расходов из-за более сложного CF, но вы также можете использовать Lattice во внутренних средах с высоким уровнем доверия, где безопасность и многопользовательская среда не так важны. .
Также стоит упомянуть, что CloudFoundry и Warden (его контейнерный движок) на пару лет предшествовали Docker.
С другой стороны, Kubernetes - это относительно новый проект, разработанный Google на основе многолетнего использования контейнеров с BORG и Omega. Kubernetes можно рассматривать как оркестровку контейнеров 3-го поколения в Google, точно так же, как Диего представляет собой оркестровку контейнеров 3-го поколения в Pivotal / VMware (v1 написано в VMware; v2 в VMware с помощью Pivotal Labs; v3 в Pivotal после того, как он возглавил проект) .
Cloud Foundry - отличный инструмент, предполагающий, что вы всегда готовы работать в рамках ограничений предложения, поскольку оно очень самоуверенно / предписано. На веб-интерфейс приятно смотреть в первый день, но он редко используется после того, как вы начнете работать с клиентом и настроили конвейер CI / CD. Я обнаружил, что Cloud Foundry хороша до тех пор, пока не появятся варианты использования, которые нелегко полностью поддержать в Cloud Foundry. Выполнение этих сценариев использования может задержать проекты по мере того, как вы пытаетесь решить эти проблемы, в результате вы теряете видимость инфраструктуры и преимуществ поддержки тех компонентов, которые затем в основном работают за пределами Cloud Foundry (подумайте о нескольких базах данных, kafka, hadoop, cassandra и т. д.) Я подозреваю, что со временем импульс, окружающий Docker, и негибкость Cloud Foundry приведут пользователей к Kubernetes, Mesos или Docker Swarm / Datacenter. Возможно, Cloud Foundry сможет догнать этих трех, но это кажется маловероятным из-за популярности этих проектов с открытым исходным кодом.
источник
Трудно ответить, почему компания создала продукт, который существенно похож на другой продукт. Причин много. Может, они уже начали им пользоваться и вкладываются в это. Может быть, они (CF) думают, что Kubernetes работает плохо или неправильно понимает API / модель / детали. Возможно, они думают, что смогут действовать быстрее, если будут контролировать весь продукт, а не вносить свой вклад.
Конечно, я говорю это как разработчик Kubernetes - можно задать одни и те же вопросы: Kubernetes vs Mesos, Amazon ECS vs Kubernetes или Docker Swarm vs Kubernetes.
Я надеюсь, что со временем мы все будем двигаться в одном направлении и сможем больше сотрудничать и тратить меньше времени на переосмысление работы друг друга.
Что касается Kubernetes, основное внимание уделяется разработчикам приложений: простым и мощным примитивам, которые позволяют очень быстро создавать и развертывать приложения в масштабах. Мы опираемся на наш опыт (ну, Google) с аналогичными технологиями, чтобы наметить наш курс. У других людей будет другой опыт или мнение.
источник
Существенная разница, на мой взгляд, заключается в используемом ими подходе:
CF автоматически строит среду выполнения из трех компонентов: двоичный файл приложения, предоставленный пользователем, пакет сборки, содержащий промежуточное ПО, необходимое для запуска приложения, и образ ОС (элементарный элемент). Пользователь CF (разработчик) должен предоставить только двоичный файл приложения (например, исполняемый файл jar). CF позаботится обо всем остальном, а именно об упаковке и запуске приложения.
Kubernetes ожидает от разработчика образов Docker, которые содержат уже встроенное ПО промежуточного слоя и ОС, готовые к запуску. Для этого «манифест развертывания» Kubernetes (например, диаграмма Helm) описывает не только отдельное приложение или сервис, но и все [микро] сервисы, составляющие ваше решение во время выполнения. Вы отправляете единое декларативное описание своей среды выполнения, и Kubernetes заботится о том, чтобы фактическое состояние среды выполнения соответствовало предоставленному вами описанию.
Таким образом, подход CF позволяет решать такие случаи использования, как «замена ОС с исправленным недостатком безопасности во всем облаке без простоя для ваших сервисов». Но он также фокусируется на развертывании службы для каждой службы, а не на декларативном описании целевой «идеальной» среды выполнения вашей системы.
источник
Cloud Foundry - это система облачных вычислений типа «платформа как услуга» с открытым исходным кодом. Cloud Foundry позволяет развертывать проекты в разных пространствах, а также связывает любую облачную службу с вашим приложением.
Kubernete больше похож на инструмент для украшения контейнеров (подов), который автоматизирует развертывание, масштабирование и управление контейнерными приложениями. Он использует термин pods для определения контейнера или группы контейнеров.
Для любого развертывания кубернетов требуется как минимум два ресурса:
1) deployment.yaml: этот ресурс определяет, какая версия образа должна быть получена из реестра вашего контейнера, наборов реплик (реплик подов), стратегии развертывания, масштабирования, зондов и т. Д.
2) service.yaml: это интерфейс между вашими внутренними модулями и внешним миром, весь внешний трафик будет прослушивать порт, определенный в этом ресурсе, откуда он распределяет нагрузку на внутренние модули.
Еще один ресурс - это вход, который предоставляют кубернеты, управляющие внешним доступом к службам в кластере, обычно http. С помощью Ingress вы можете обеспечить балансировку нагрузки, завершение SSL и виртуальный хостинг на основе имен.
Подробнее о кубернетах вы можете найти ниже: https://kubernetes.io/docs/
источник
[pcf vs kubernetes] [1] Разница между pcf и kubernetes
(абстракция платформы на уровне приложения) • Pivotal Cloud Foundry - это абстракция высокого уровня для разработки облачных приложений.
• У нас есть абстракция платформы на уровне приложения, создание и развертывание полностью настроенного приложения.
• PCF является одним из примеров «приложения» PaaS (также называемого средой выполнения приложения Cloud Foundry).
• Разработчик поддерживает приложение в будущем
• Идеально подходит для новых приложений, облачных приложений. Для команд, работающих с короткими жизненными циклами и частыми выпусками, PCF предлагает отличный продукт.
(абстракция платформы на уровне контейнера) • Kubernetes - это планировщик или оркестратор контейнеров.
• У нас есть абстракция платформы на уровне контейнера, позволяющая создавать и развертывать контейнеры как часть полного приложения.
• Kubernetes - это «контейнер» PaaS (иногда называемый CaaS).
• С помощью инструментов оркестровки контейнеров Разработчик создает, а затем поддерживает контейнер в будущем.
• Для нового приложения больше работы для ваших инженерных команд и снижение производительности
источник
Спустя 4 года тенденции выглядят так:
Кластеры Kubernetes в наши дни становятся действительно дешевыми, а инструментальная среда для кубернетов лучше.
Кроме того, большинство конкурентных функций, перечисленных на других плакатах, в наши дни легко воспроизвести внутри кубернетов.
источник