Продолжаем рассказывать на примере известных компаний о том, что Kubernetes в production — это не только мечты и надежды. Эта статья — снова про технарей с мировым именем: SAP и её конвергентное облако на базе OpenStack и Kubernetes. Однако начнём с менее известной Concur и вот почему…
Concur
Concur Technologies — американская компания, существующая с 1993 года и насчитывающая сегодня 6800 сотрудников. Её бизнес — это SaaS для услуг в области путешествий и управления затратами для предприятий. В 2010 году ей удалось попасть в сотню лучших маленьких компаний по версии журнала Forbes, а по актуальным сведениям (2017 г.) около 70 % представителей списков Forbes 100 и Forbes 500 пользуются её услугами. В сентябре 2014 года стало известно, что SAP покупает Concur Technologies за 8,3 млрд USD, и поглощение было завершено в декабре того же года.
Статью же про SAP я решил начать с Concur, потому что эта компания, уже будучи подразделением SAP, стала прекрасным примером одних из ранних серьёзных пользователей Kubernetes в production. Первые сведения об этом появились в мае 2016 года. На проходившем тогда в Бостоне мероприятии ContainerDays 2016 ведущий инженер компании Dale Ragan дал интервью, в котором рассказал об опыте Concur.
Использовать Kubernetes в компании начали с одного фрагмента инфраструктуры — для сервиса по управлению чеками. На тот момент в Concur уже работали с Amazon Web Services и хотели запускать своё приложение как локально (on-premises), так и в облаке. Применять EC2 Container Service, который находился тогда в бета-тестировании, в Concur не захотели из-за появляющейся зависимости от одного поставщика (Amazon).
Одним из заметных препятствий при эксплуатации Kubernetes стало отсутствие поддержки AWS Availability Zones для NoSQL-хранилища etcd — проблему решили усилиями инженеров компании и обещали передать Open Source-сообществу. Результатом внедрения Kubernetes, по словам инженера Concur, стала «неизменная» инфраструктура (immutable infrastructure) — такая, что при внесении в неё изменений вместо модификации существующего кластера создаётся новый (и туда производится миграция). Это позволило им «чувствовать себя уверенными при миграциях, когда для всей инфраструктуры делается версионирование подобно тому, как деплоятся новые версии приложения». Для мониторинга производительности в компании внедрили Prometheus и Grafana, а главной проблемой проекта Kubernetes по итогам своего внедрения в Concur назвали недостаточно хорошую/подробную документацию.
Рассказывая об этом событии в своём блоге, Dale Ragan представил общую схему полученной инфраструктуры компании в AWS на базе Kubernetes:
… и пообещал рассказать подробнее об этом проекте, однако по каким-то причинам этого не произошло :-)
Несмотря на это, применение Kubernetes в Concur получило активное продолжение и развитие. Осенью того же года старший архитектор компании Dan Wilson выступил на KubeCon 2016 с докладом о масштабировании микросервисов с помощью Kubernetes, а ещё через год — на CoreOS Fest 2017 с докладом (презентация в PowerPoint) про использование Federated Cluster Selector из Kubernetes 1.7.
В последнем докладе архитектор Concur объяснил выбор Kubernetes следующими причинами:
Отдельного замечания стоит тот факт, что к 2017 году в Concur полюбили продукты CoreOS (хотя начинали с использования только «родных» компонентов Kubernetes), в том числе объясняя это «лучшей документацией для Kubernetes». Архитектура кластеров в компании получила такой вид:
В этом же докладе Dan Wilson представил и один из Open Source-проектов Concur для Kubernetes — kubegowatcher. Это шаблон плагина, который создан для запуска в контейнере внутри Kubernetes и отслеживания изменений в сервисах, подах и узлах (с возможностью добавлять свою бизнес-логику на события добавления/изменения/удаления объектов). Дополнительно отмечу, что архитектор Concur вносит свои правки и в upstream самого Kubernetes.
SAP: DevOps, микросервисы, Kubernetes (2016)
Официальных подтверждений тому, что солидный опыт с Kubernetes у Concur повлиял на инженеров SAP, нет. Однако общие идеи как минимум «витали в воздухе» — ведь ещё при покупке Concur глава SAP выражал восторг по поводу «расширения облачного портфолио SAP ведущими решениями для путешествий и управления расходами».
Так или иначе первое публичное упоминание применения Kubernetes для нужд SAP встречается летом 2016 года, когда архитектор облачной инфраструктуры компании Darren Hague выступал на DevOps Enterprise Summit 2016 (DOES16) в Лондоне с докладом «SAP’s DevOps Journey: From Building an App to Building a Cloud». К DevOps в компании пришли ещё в 2010—2013 годах (см. выступление того же автора на FlowCon San Francisco 2013), и Kubernetes стал следующим логичным шагом в её эволюции.
Представляя Kubernetes, Darren провёл заимствованную у сотрудника ЦЕРНа аналогию с домашними животными и скотом: если первые «имеют свои имена, уникальны, получают заботу с любовью и восстановление здоровья в случае проблем», то вторые — «получают номера вместо имён, практически идентичны друг другу и легко заменяются в случае болезней» (лично от себя добавлю, что совершенно не разделяю подобное отношение к животным, но это выходит далеко за рамки статьи). Так вот Kubernetes, по мнению архитектора SAP, — это возможность «обращаться с контейнерами, как со скотом, а не домашними питомцами».
Одной из особенностей применения системы Kubernetes в инфраструктуре SAP стало её использование как фундамента, поверх которого (т.е. в Docker-контейнерах которого) запускалась облачная платформа OpenStack. Уже в середине 2016 года озвучивалась задача компании по реализации такой новой платформы в 13 регионах и 18 дата-центрах с тем, чтобы её использовали одновременно «для облачных услуг SAP и для внутренних инноваций». Общение видение платформы представлялось следующим образом:
Отдельного упоминания заслуживает предпоследний пункт: инженеры компании создавали своего «агента автоматизации» под названием Arc, упоминаний в интернете о котором, к сожалению, осталось не так много. Существующий проект на Launchpad характеризует разработку как «безопасный фрейморк удалённого исполнения команд в OpenStack для настройки и запуска задач на гостевых системах в Linux и Windows», ссылаясь на ныне отсутствующий репозиторий в GitHub.
Интересной оказалась статистика по R&D создаваемой платформы: менее 10 % работы над проектом отнесены к категории «новые разработки», а более 90 % — улучшение имеющегося Open Source-кода. В частности, специалисты SAP внесли правки в upstream таких проектов, как OpenStack, Kubernetes, Docker и Grafana. (Впрочем, по данным Stackalytics, SAP не входит в сколь-нибудь значимый топ самых активных контрибьюторов ни для OpenStack в целом, ни для компонента Kubernetes в частности — проверка осуществлена для релизов OpenStack 2016—2017 годов.)
К подробностям об этой платформе мы ещё вернёмся, а пока будем следовать хронологии. В ноябре того же года на KubeCon 2016 прозвучал доклад (PDF) двух сотрудников SAP Labs о пилотном проекте по запуску в Kubernetes контейнеров с enterprise-сервисами компании. Из него можно было узнать о продолжающемся интересе инженеров SAP к переводу монолитных приложений к микросервисной архитектуре и имеющимся способам его реализации. Общую архитектуру в SAP видят так:
В примечании к этому слайду утверждается, что SAP работает и с HashiCorp, и с Mesosphere, однако выбранной реализацией контейнеров по умолчанию является Docker, а конкретный доклад посвящён их применению с Kubernetes и CoreOS. Итог же исследовательского проекта SAP Labs таков, что он на тот момент не закончен: остаётся ряд сложностей (в основном это вопросы стандартизации и интеграции различных компонентов и процессов компании), которые инженеры намерены преодолеть до того, как практики станут повсеместно адаптироваться. Отдельного упоминания в этом проекте стоит намерение SAP Labs «выпустить в ближайшем будущем Open Source-инструмент для управления Kubernetes — инструмента, который будет полезен и для разработчиков, и для команд эксплуатации».
SAP: конвергентное облако (2017)
В марте 2017 года история облачной платформы SAP на базе Kubernetes и OpenStack получила публичное продолжение: в корпоративном блоге анонсируется production-статус конвергентного облака SAP (SAP Converged Cloud, SAPCC). Заявляется, что оно предназначено только для внутреннего применения в компании, однако его масштабы всё равно впечатляют: проект объединил 23 других облачных решения, применявшихся ранее. Так много их было по разным причинам: «от быстрой инновации в разных областях бизнеса до множества приобретений, сделанных SAP за последние годы» (у таких компаний, как SuccessFactors, Ariba и, конечно, уже упомянутой Concur, были свои облака в момент их присоединения к SAP).
Как сообщается в анонсе, «OpenStack разворачивается на 100% контейнеризированным с помощью автоматизированной системы на базе Kubernetes». Некоторые подробности о технических особенностях и трудностях применения Kubernetes можно почерпнуть из доклада (кстати, это видео содержит 4-минутную демонстрацию того, как новый дата-центр может быть развёрнут в SAP Converged Cloud) архитектора компании Michael Schmidt на OpenStack Summit 2016:
Весь CI/CD pipeline в SAP (применяется Concourse) интегрирован с контейнерами из облака (применяется OpenStack Kolla), а для удобного управления инфраструктурой, разворачиваемой Kubernetes, используется пакетный менеджер Helm. В GitHub опубликованы различные Helm Charts: для разворачивания базовой IaaS на основе OpenStack, а также дополнительные, что требуются для SAP Converged Cloud.
Для работы с SAPCC создан веб-интерфейс, позволяющий управлять облачными ресурсами. Докладчик особо отмечает, что в интерфейсе управления серверами дополнительно предлагается и терминал для выполнения в нём привычных консольных команд OpenStack:
На момент анонса SAP Converged Cloud в нём была доступна лишь одна availability zone в Австралии с планами добавить ещё две европейские в течение 2 последующих недель и добиться распространения облака на 19 дата-центров в 13 регионах к концу 2018 года. В GitHub проекта SAPCC можно найти и другие интересные репозитории используемых в инфраструктуре компонентов — например, операторы для управления OpenStack на Kubernetes (подробнее об операторах для Kubernetes мы писали в этой статье) или утилиту для проверки сетевых настроек кластера Kubernetes.
Напоследок отмечу, что в этом же году СУБД SAP HANA была сертифицирована для запуска на Google Cloud Platform (GCP).
Другие статьи из цикла
Автор: shurup
