Создание внутренней платформы Kubernetes

Технология управления контейнерами Kubernetes стала доминирующим решением для облачной инфраструктуры, поэтому она развивается невероятными темпами. Многие компании уже внедрили Kubernetes или находятся в процессе внедрения этого решения. Однако простого внедрения Kubernetes недостаточно, необходимо более широкое распространение этой технологии в вашей компании.
Эта статья – перевод разбора коллег из Loft Labs. Итак, что такое внутренняя платформа Kubernetes и как ее создать разбираемся в нашем материале.

Что такое внутренняя платформа Kubernetes?

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

Почему у вас должна быть внутренняя платформа Kubernetes?

С увеличением количества приложений, работающих на Kubernetes, также необходимо, чтобы внедрение Kubernetes распространилось внутри всей организации, чтобы разработчики могли напрямую взаимодействовать с технологией, лежащей в основе их приложений. Только при соблюдении этого требования можно реализовать такие преимущества Kubernetes как ускорение цикла разработки и повышение стабильности приложений.
Как видно из опроса разработчиков Stack Overflow Developer Survey 2020, разработчики готовы к следующему шагу, поскольку Kubernetes является очень "желанной" и "любимой" технологией, то есть они хотят работать с ней, а тем, кто уже работает с ней, она нравится.
Первый шаг, позволяющий инженерам работать с Kubernetes, - это предоставление им доступа к системе с помощью индивидуальных рабочих сред Kubernetes. Именно это и делает внутренняя платформа Kubernetes, поэтому она так важна для успешного дальнейшего внедрения.

Какие среды Kubernetes существуют для создания внутренней платформы?

В теории существует несколько вариантов предоставления инженерам прямого доступа к Kubernetes: локальные кластеры Kubernetes, индивидуальные кластеры или общие кластеры. Рассмотрим подробнее.
1. Локальные кластеры: Локальные кластеры - это специальные версии Kubernetes, созданные для запуска на компьютерах инженеров, такие как minikube или kind. Они обязательно ограничены локально доступными вычислительными ресурсами и не имеют всех возможностей Kubernetes, которые существуют в "настоящих" кластерах, работающих в облачных средах. Локальная среда также не позволяет оптимизировать процесс настройки, поэтому его должны выполнять сами инженеры, что требует определенного опыта работы с k8s.
Для этого хорошо подходят локальные кластеры Kubernetes, которые очень популярны на начальном этапе внедрения и тестирования, но они не являются подходящим решением для дальнейших этапов внедрения или создания внутренней платформы.

2. Индивидуальные кластеры: Индивидуальные кластеры - это кластеры, которые используются только одним инженером. Можно создать внутреннюю платформу, которая обеспечит ваших инженеров полноценными индивидуальными кластерами. В принципе, EKS, AKS и GKE уже являются "внешними" платформами Kubernetes, и, если вы предоставите каждому инженеру доступ к этим решениям общедоступных облачных провайдеров, у вас получится что-то вроде "внутренней" платформы Kubernetes. Однако такое решение будет очень дорогим, поскольку вычислительные ресурсы используются крайне неэффективно. Администраторам также гораздо сложнее контролировать систему с огромным количеством кластеров и выяснять, какие кластеры используются, а какие можно удалить. Наконец, большинство компаний не хотят предоставлять каждому инженеру прямой доступ к учетной записи облачного провайдера.
Таким образом, создание внутренней платформы Kubernetes с индивидуальными кластерами для инженеров теоретически возможно, но это будет очень дорого и неэффективно, поэтому вряд ли когда-либо будет сделано.

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

Пространства имен vs виртуальные кластеры

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

Ручное обслуживание vs самообслуживания

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

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

Как можно создать внутреннюю платформу Kubernetes?

1. Выберите платформу Kubernetes

Как было описано ранее, вы хотите построить внутреннюю платформу с общими кластерами. Тем не менее, вам необходимо решить, на какой платформе Kubernetes будет работать ваша внутренняя платформа.

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

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

2. Определите архитектуру платформы

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

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

Другой вопрос, на который вам необходимо ответить, - как пользователи внутренней платформы будут с ней взаимодействовать. Вы можете выбрать между графическим пользовательским интерфейсом, с которым, возможно, легче всего работать новичкам, но который также сложнее всего создавать, интерфейсом командной строки, который потенциально может быть хорошо интегрирован в рабочие процессы инженеров, или Kubernetes Custom Resource Definitions (CRDs, пользовательские определения ресурсов), которые будут реализованы ближе всего к фундаментальному Kubernetes. Конечно, можно также комбинировать различные варианты, например, предоставляя графический интерфейс, который создает CRD в фоновом режиме.

3. Настройте вашу платформу

Третьим шагом в создании платформы Kubernetes является настройка. Здесь вы столкнетесь с решением о производстве или закупке.

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

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

4. Привлечение инженеров и предоставление инструментария для разработчиков

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

Наличие правильного инструментария для разработчиков очень полезно на этом этапе, тем более что большинство таких инструментов могут быть предварительно настроены для типичных случаев использования. Примерами инструментов, специально созданных для разработчиков, являются DevSpace, который также имеет опциональную интеграцию с loft, если это выбранная вами платформа, Skaffold и Tilt.

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

5. Контроль затрат

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

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

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

Это также является требованием для внедрения "спящего режима", автоматической системы, которая отключает неиспользуемые пространства имен или виртуальные кластеры и таким образом предотвращает простаивание ресурсов. Экономия от такого спящего режима в сочетании с горизонтальным автомасштабированием может быть огромной (около 70%), если представить, что инженерам не нужны вычислительные ресурсы ночью, в выходные или во время совещаний, но вы все равно платите за них, если они продолжают работать.

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

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