Kubernetes 2020: что нас ждет в следующем году и далее?
Кажется почти бесполезным пытаться предсказать будущее самого быстрорастущего проекта с открытым исходным кодом в истории, тем более что абсолютно никто не мог представить себе путь до сих пор. То, что в значительной степени начиналось как «подручное» от Google остальному сообществу, превратилось в стандарт де-факто для оркестровки и, как некоторые называют это, в правителя мира. Никогда еще не было ни одного проекта, который получил бы такую коллективную поддержку всего корпоративного сообщества. Один взгляд на длинный список членов CNCF покажет вам, что и друзья, и враги отложили в сторону не только свои разногласия, но и свои собственные конкурирующие продукты в пользу поддержки Kubernetes. Благодаря беспрецедентной поддержке, технологической поддержке и тому, кто есть кто на предприятии, можно с уверенностью сказать, что у всех есть свои яйца в одной большой корзине Kubernetes. И, опираясь на успех 2019 года, в Kubernetes 2020 будет больше яиц и большая корзина.
Бессерверная оркестровка
Однако в текущей ситуации совершенно очевидно, что Kubernetes и бессерверная архитектура находятся на пути к столкновению. С одной стороны, у нас есть Kubernetes, который официально вышел из стадии экспериментов и находится в производстве, а с другой стороны, эта идея, называемая бессерверной, к которой люди стремились с тех пор, как была выпущена первая PaaS. Причина, по которой мы называем бессерверную идею здесь, не в том, что ее не существует, а в том, что она относится к вечному Святому Граалю целей разработчиков платформ, абстракции всей инфраструктуры. Обеспечение того, чтобы разработчики могли свободно работать над своими приложениями, — это не та задача, от которой предприятие когда-либо откажется, особенно в пользу Kubernetes или любого другого программного обеспечения для оркестровки, независимо от того, насколько оно мощное или универсальное. Что приводит нас к одному выводу: в будущем определенно будут представлены контейнеры, бессерверная архитектура и Kubernetes.
Это, в свою очередь, заставляет нас задаться очевидным вопросом: «Какую роль будет играть Kubernetes в будущем бессерверных контейнеров?» Хотя будущее всегда оставляет за собой право поставить нас в тупик, оркестровка — довольно безопасная ставка. Это связано с тем, что бессерверной контейнерной инфраструктуре придется пройти несколько световых лет, чтобы догнать Kubernetes, а для создания более сложных систем всегда потребуется высокоуровневый оркестратор. Таким образом, вместо того, чтобы начинать с нуля и конкурировать с самым быстрорастущим проектом с открытым исходным кодом на планете, имеет смысл просто присоединиться к побеждающей стороне на выборах Kubernetes и консолидироваться вокруг API оркестрации. Кроме того, для конфиденциальных данных и высокоприоритетных рабочих нагрузок всегда будут требоваться выделенные машины и специальное оборудование, по крайней мере, в обозримом будущем. Так что, хотя будущее действительно будет безсерверным, оно также будет гибридной комбинацией множества других вещей (работающих на Kubernetes).
Гибридная оркестровка
Идеальной ситуацией, очевидно, были бы бессерверные контейнеры, делающие «взрывные» вещи, в то время как какое-то серьезное оборудование удерживает форт (службы в стабильном состоянии). Это подразумевает другой уровень гибридного облака, который учитывает не только локальную инфраструктуру и пару общедоступных облаков, но и бессерверную архитектуру. На данный момент виртуальный kubelet — это единственный способ, с помощью которого Kubernetes может экспериментировать с бессерверной архитектурой. Virtual kubelet — это проект с открытым исходным кодом, который позволяет Kubernetes подключаться к другим API-интерфейсам и в настоящее время используется для интеграции Kubernetes и бессерверных технологий путем создания виртуального узла, представляющего бессерверную инфраструктуру. Виртуальный кублет сохраняет всю мощь и функциональность Kubernetes и может обрабатывать концепции более высокого уровня, такие как сервисы, развертывания, секреты и тому подобное. Еще одним совместным предприятием между Kubernetes и бессерверной архитектурой является Knative, платформа на основе Kubernetes, разработанная для предоставления нативного API Kubernetes для реализации функций бессерверного типа.
Предприятие хочет гибридное облако, а Kubernetes лежит в основе гибридного облака, поэтому ожидать, что Google будет стоять в стороне и смотреть, как его детище захватывает мир, по меньшей мере глупо. Недавно Google анонсировала Anthos, свою гибридную мультиоблачную платформу, в основе которой лежит GKE, а также GKE on-prem, Istio, Velostrata и другие. Что здесь отличается от других гибридных облачных предложений, так это то, что Anthos обладает глубоким пониманием Google Kubernetes и еще более глубоко укоренившимися основами контейнеров. В то время как Velostrata является первым в отрасли инструментом миграции с физического на Kubernetes, созданным Google, Anthos также включает в себя Config Management, Stackdriver, GCP Cloud Interconnect и GCP Marketplace. Хотя почти заманчиво думать, что это был план Google с самого первого дня, доказательство всегда находится в пудинге, и нам нужно будет увидеть, насколько простым и удобным для пользователя Anthos удается управлять гибридным/мультиоблачным управлением.
Сквозная CI/CD
Еще одно явление, которое мы, вероятно, будем наблюдать гораздо чаще, — это то, что поставщики облачных услуг обращают внимание на потребности разработчиков, такие как сквозные решения, которые помогают управлять всем SDLC. В настоящее время в этом секторе доминируют CloudBees, архитекторы Jenkins и Jenkins X. Ранее в этом году, вместе с сообществом Jenkins и Google, CloudBees даже запустили Continuous Delivery Foundation (CDF), новое ответвление Linux Foundation, направленное на разработку и продвижение проектов с открытым исходным кодом и лучших практик непрерывной доставки. Кроме того, CloudBees также объявила о приобретении Electric Cloud с намерением стать первым поставщиком CI/CD и ARA) для автоматизации выпуска приложений. BitBucket Pipelines, которая является частью BitBucket Cloud от Atlassian, является еще одним крупным игроком на этом рынке, одним из крупнейших конкурентов которого является GitLab. GitLab также является довольно популярным выбором для CI/CD и имеет свои механизмы тестирования сборки и развертывания, связанные с его репозиториями.
Однако мы пытались подчеркнуть, что в ближайшем будущем мы увидим гораздо больше крупных облачных игроков на этом не очень «нишевом» рынке. Крупные игроки уже запустили этот процесс, например AWS CodePipeline от Amazon, который отлично справляется с доставкой кода на сервер AWS, хотя по-прежнему существует большое количество уровней для навигации, таких как CodeCommit, CodeDeploy и CodeStar. Точно так же в конце прошлого года Azure изменила Visual Studio Team Services на Azure DevOps, набор услуг, призванных помочь пользователям создавать сквозные автоматизированные конвейеры. Сюда входят пять различных инструментов с именами Azure Pipelines, Boards, Artifacts, Repos и Test Plans, а также литература, в которой говорится «любой язык, любая платформа». Кроме того, в прошлом году Microsoft приобрела GitHub, что означает, что они очень заинтересованы в этом секторе.
Futurenetes
Таким образом, хотя много говорят о том, что футуристические легковесные виртуальные машины заменят контейнеры, а бессерверные контейнеры заменят Kubernetes, приложения для разных предприятий настолько разнообразны, что редко можно встретить универсальный вариант. Хотя бессерверная инфраструктура, такая как Azure Container Instances, — отличный способ запустить несколько контейнеров в облаке, по мере масштабирования вам не избежать оркестрации, и чтобы сделать это правильно, вам понадобятся возможности Kubernetes. Это означает, что в будущем речь пойдет не о виртуальных машинах, контейнерах или бессерверных технологиях, а о том, как Kubernetes будет использоваться для коллективной организации различных рабочих нагрузок в облаке. Эти рабочие нагрузки будут включать традиционные виртуальные машины, микро-виртуальные машины, «будущие» виртуальные машины, бессерверные контейнеры и виртуальные машины или даже пустую инфраструктуру.