Будущее Kubernetes

Понимание того, что произойдет с технологией, когда вы изучите ее, будете жить ею и использовать ее ежедневно, часто возникает в голове человека. Постоянные вопросы «останется ли эта технология?» или «когда я должен начать изучать новую технологию?» приходят нам в голову и заставляют запутаться.

В случае с Kubernetes вопрос «останется ли эта технология» возникает не так часто, и не зря.

В этой статье вы узнаете о том, каким, по моему мнению, является будущее Kubernetes и что вам следует думать о ней в течение следующих нескольких лет.

Kubernetes станет неактуальным

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

Что касается начала Kubernetes, я бы сказал, что мы все еще находимся в нем. Организации все еще пытаются внедрить Kubernetes, а после внедрения инженеры все еще пытаются заставить его работать так, как они надеются, с точки зрения того, как им нужно выполнять рабочие нагрузки.

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

В конце концов, Kubernetes не станет концом оркестровки. Это будет просто еще одна платформа, на смену которой пришло что-то другое. Подумайте об этом так — управляемые службы Kubernetes, такие как Azure Kubernetes Service и AWS EKS, уже имеют инструменты для навешивания на Kubernetes любого ярлыка, который они захотят. С помощью Azure Container Apps и EKS Fargate они могут заменить «Kubernetes» и назвать его по-другому. Как? Потому что в конечном итоге платформа оркестровки — это платформа оркестровки. Неважно, какое у нее название. Начало конца уже существует. Все, что нужно, — это название платформы и масштабируемый подход.

Я действительно считаю, что «конец Kubernetes» займет немного больше времени, чем типичные технологии. Причина в том, что, несмотря на популярность Kubernetes, это не самая простая в управлении и развертывании платформа. В последний год или около того начали появляться продукты/платформы для упрощения работы с Kubernetes, а Kubernetes появился на полках магазинов в 2015 году, поэтому, как вы видите, здесь есть некоторый пробел. Кажется, что Kubernetes только что появился, но в то же время он уже давно существует.

Я решил написать этот раздел первым, потому что мыслить с точки зрения конца очень важно, чтобы понять, как будет развиваться будущее Kubernetes до конца. Также крайне важно понять, что вам понадобится перед концом Kubernetes.

Платформа может стать неактуальной, но двери, которые платформа открыла для нас, не станут таковыми. Ключевым выводом для Kubernetes в будущем будет то, что пользовательские определения ресурсов (CRD) и расширение API станут «будущим» платформ оркестровки.

Среда вместо платформы

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

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

Из-за этого негативного опыта Kubernetes будет восприниматься меньше как платформа и больше как центр обработки данных. О нем будут думать как о «центре обработки данных в облаке».

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

Что происходит под капотом

Когда речь заходит о Kubernetes, многое абстрагируется. Если вы подумаете об управляемых службах Kubernetes, таких как AKS и GKE, вам не нужно беспокоиться о плоскости управления. Это означает, что вам не нужно думать о:

  • масштабировании плоскости управления
  • Сервер API
  • Планировщик
  • Менеджер контроллеров
  • Etcd

Это, пожалуй, самые важные части Kubernetes.

При использовании Managed Kubernetes Services у вас даже нет возможности правильно понять, как работают все эти компоненты.

Вопрос, который я постоянно задаю себе: «Как кто-то может устранить неполадки, если что-то идет не так?». Например, допустим, у вас возникли проблемы с кластером Kubernetes, и в итоге выяснилось, что контейнерный сетевой интерфейс (CNI) имеет проблемы на плоскости управления, и поэтому рабочие узлы Kubernetes не могут подключиться.

Если вы не знаете, как работает CNI и что рабочие узлы и другие плоскости управления не подключаются к основной плоскости управления без работающей CNI, как вы можете устранить проблему? Как узнать, что именно вы сделали, а что — поставщик облачных услуг?

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

Гибридные решения

На момент написания этой статьи существует четыре основных гибридных решения:

  • Azure Stack HCI
  • Google Anthos
  • AWS Outposts
  • EKS Anywhere

Все они делают примерно одно и то же на высоком уровне — предоставляют инженерам возможность запускать локальные рабочие нагрузки так, как будто они находятся в облаке.

Вы можете подумать: «Почему бы мне просто не запускать рабочие нагрузки в облаке?», и ответ на этот вопрос может быть один на миллион. Некоторые распространенные сценарии: у организаций есть устаревшие приложения, которые они еще не готовы перенести в облако, проблемы с задержками, проблемы с безопасностью, подъем и перемещение будут слишком большими для вознаграждения, или они просто хотят сочетать локальные и облачные решения (гибридная модель).

Следующий вопрос: «Зачем им тогда использовать эти сервисы?», и я считаю, что ответ на него такой же, как и на вопрос, почему люди хотят использовать OpenStack. Это как облако, только локальное.

Допустим, у вас уже есть контейнерные приложения, которые работают в облаке. Возможно, вы уже знакомы с EKS или AKS, и вы хотите контейнеризировать старые приложения и оркестровать их, но не хотите запускать их в облаке. Вы можете запускать их на месте, с помощью Kubernetes, точно так же, как вы запускаете контейнеризированные приложения в облаке. Они будут выглядеть и ощущаться одинаково. Единственное различие заключается в том, что они будут находиться на месте, а не в облаке. Инженерные команды будут взаимодействовать с приложениями и интерфейсом точно так же.

В организациях, по крайней мере в течение долгого времени, всегда будут существовать локальные рабочие нагрузки. Но то, что они локальные, не означает, что они не могут получить преимущества облачных решений.

Бессерверные Kubernetes

До появления управляемых служб Kubernetes, таких как AKS, EKS и GKE, инженерам приходилось создавать, управлять и обновлять плоскости управления и рабочие узлы. Благодаря AKS, EKS и GKE управление плоскостями управления теперь осуществляется с ежедневной точки зрения через облачного провайдера. При использовании этих служб инженеру все еще приходится заботиться о рабочих узлах.

Следующей итерацией этого будет то, что рабочие узлы также не будут управляться инженерами с повседневной точки зрения. Вот тут-то и вступает в игру бессерверная Kubernetes.

Существует несколько сервисов, которые делают именно это:

  • GKE AutoPilot
  • AWS Fargate
  • Azure Container Apps

«Бессерверный Kubernetes», то есть устранение необходимости выполнять повседневные операции для плоскостей управления и рабочих узлов, — это то, что нам уже почти не нужна платформа Kubernetes. На этом этапе инженерам приходится думать только о контроллерах, определениях ресурсов клиентов и самом API Kubernetes.

С бессерверной Kubernetes инженеры действительно беспокоятся только об управлении своей инфраструктурой с помощью API.

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

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

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

На данный момент я считаю, что бессерверная система Kubernetes еще слишком нова и не так часто используется в производстве, что делает прогноз ее использования в будущем. Я считаю, что основными проблемами для организаций будут масштаб и задержка. Если среда полностью выходит из-под вашего контроля, вы полагаетесь на базовую автоматизацию этих служб, которая будет масштабироваться за вас. Несколько человек из Microsoft, например, сказали, что Azure Container App сейчас отлично подходит для тестирования, но не для производства, поскольку таких вещей, как разделение пространства имен, не существует. Если подобные проблемы будут устранены, то бессерверная Kubernetes может стать серьезным соперником.

Создание ресурсов Kubernetes

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

Затем эта идея начала немного меняться. Появились такие инструменты, как Pulumi и AWS CDK, которые позволяют выполнять инфраструктуру как код, но с помощью языка программирования общего назначения, например Go или Python.

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

Я считаю, что то же самое произойдет и с созданием и управлением ресурсами Kubernetes.

На данный момент основным методом является YAML. Однако это далеко не единственный доступный вариант.

Когда вы взаимодействуете с Kubernetes, все, что вы делаете, это «разговариваете» с API. Поэтому любой язык, который может «разговаривать» с любым API, может создавать ресурсы в Kubernetes.

Например, вот ссылка на код на Go, который я написал для создания развертывания и службы Kubernetes для приложения Nginx.

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

Погружение глубже

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

В современном мире слишком много абстракций, а ведь изначально абстракции предназначались для технологий.

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

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

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

Я снова и снова слышу: «Зачем мне это знать, если это абстрагировано» или «Зачем мне знать базовые компоненты Kubernetes, если я с ними не работаю».

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

В современном инженерном мире постоянно ходит шутка, что если люди не могут найти ответ на StackOverflow за 10 минут, они говорят, что это невозможно сделать.

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

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

Не углубившись в тему, вы никогда не сможете по-настоящему ее познать.

Если вам интересно узнать о предпосылках Kubernetes и о том, как глубоко в них погрузиться, ознакомьтесь с этой статьей в блоге.

Принятие Kubernetes и инкубаторы

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

Некоторые из них сосредоточены на RBAC, другие — на логировании, третьи — на упрощении работы с Kubernetes, а четвертые — на всем остальном.

CNCF работает со многими из этих стартапов, и очевидно, что CNCF уделяет много времени Kubernetes в целом, а также тому направлению, в котором Kubernetes развивается благодаря этим продуктам.

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

Виртуальные машины

Это предсказание, вероятно, самое «хм, я не уверен в этом». Однако я считаю, что это имеет смысл из-за устаревших приложений.

Подумайте о HashiCorp Nomad — это оркестратор, который делает то же самое, что и Kubernetes, только Kubernetes поддерживает только контейнерные приложения. Nomad поддерживает любой тип приложений.

Чтобы Kubernetes оставался конкурентоспособным, об этом придется подумать и в конечном итоге решить.

Хорошей новостью является то, что есть решения, которые помогают в этом.

Kube-virt предоставляет платформу, с помощью которой инженеры могут создавать приложения как для контейнеров, так и для виртуальных машин в одной среде. По сути, она позволяет запускать виртуальные машины на Kubernetes.

Это возвращает нас к гибридному подходу из предыдущего раздела. Некоторые организации не захотят переносить все в облако, и, если сделать еще один шаг вперед, некоторые организации не захотят контейнеризировать некоторые устаревшие приложения. Однако им нужна «мощь» Kubernetes для управления устаревшими приложениями.

Именно здесь в игру вступают такие инструменты, как Kube-virt, и я уверен, что другие инструменты также выйдут на рынок, как только Kubernetes начнет использоваться в производстве. Если Kubernetes действительно является способом управления инфраструктурой с помощью API, это означает, что мы должны иметь возможность управлять всей инфраструктурой.

Управление кластерами

И последнее, но, конечно, не менее важное, — управление кластерами. Здесь есть все, начиная от:

  • Гибридное облако
  • Мульти-облако
  • Кластеры на месте
  • Кластеры в OpenStack
  • Все различные продукты и решения

много инфраструктуры, летающей повсюду.

Инструменты управления кластерами, такие как Rancher и Azure Arc, уже существуют, но они станут более актуальными, когда организации начнут включать в себя несколько кластеров Kubernetes. На данный момент менее 10% организаций используют более 50 кластеров Kubernetes. Поскольку это число так мало, вы должны представить, что многие организации используют максимум несколько кластеров Kubernetes, и это не означает, что все они находятся в производстве.

Когда Kubernetes станет «средой», а не «платформой», будет развертываться все больше и больше кластеров, и инструменты управления кластерами станут не опцией, а необходимостью. Кроме того, эти инструменты управления кластерами дадут вам возможность легко управлять внутренними компонентами ваших кластеров. Например, общее управление RBAC на всех ваших кластерах вместо управления RBAC на каждом кластере.

Оцените статью
devanswers.ru
Добавить комментарий