Kubernetes для разработчиков: какие знания нужны?
Раньше мы уже писали про зоны ответственности разработчиков и DevOps-инженеров при работе с Kubernetes. В преддверии возвращения Вечерней школы по Kubernetes, в этот раз для разработчиков, подготовили интервью с Павлом Селивановым архитектором в Mail.ru Cloud Solutions и Марселем Ибраевым CTO Слёрма. Речь пойдет о том, какие конкретно знания нужны разработчику в компаниях с Kubernetes, Павел и Марсель поделятся кейсами из своей практики.
Что должен знать разработчик о Kubernetes, а какие знания окажутся лишними?
Павел Селиванов: Расскажу сначала, чего разработчикам не нужно знать о кластере.
Разработчикам не нужно знать, как установить кластер. Не нужно знать, как настроить компоненты кластера, какие там есть параметры. С какими параметрами и при каких условиях лучше работают kubelet, API-сервер, controller-manager.
Разработчику не нужно знать, как конфигурируются какие-то внутренние компоненты, которые находятся в самом кластере. Ингресс-контроллеры, DNS и прочее.
Разработчику точно не нужно знать ничего о сертификатах кластера и сроках их действия.
Теперь обозначу, что полезно знать разработчикам, но не обязательно.
Во-первых, как работает Kubernetes для того, чтобы запустить в нём приложение. То есть, что происходит в кластере, когда разработчик делает kubectl apply -f deploy.yaml.
Подключаются определенные компоненты в определенной последовательности. Без этого разработчику жить точно можно, но такое знание позволяет в некоторых случаях без помощи инфраструктурной команды понять, что происходит с твоим приложением.
Например, почему деплой прошел, а Pod`ы находятся в статусе pending? В таком случае нет смысла смотреть controller-manager. Можно посмотреть в describe Deployment`а и увидеть, что там создался ReplicaSet.
Значит controller-manager отработал нормально, ReplicaSet создался. Смотрим в describe ReplicaSet`а, видим, что там у нас Pod`ы тоже создались. То есть с controller-manager точно проблем нет. Смотрим, а Pod`ы висят в pending, и ничего не сообщается, почему они в этом статусе. Тут мы понимаем, что в кластере сломался компонент, который называется scheduler.
Вот знать не необходимо, но это очень хорошо позволяет понимать, что происходит с кластером Kubernetes и почему твои приложения запускаются или не запускаются или запускаются долго и так далее.
Во-вторых, хорошо бы, но не обязательно знать об инфраструктурных ограничениях, которые есть в кластере. О том, что там есть ресурсы, CPU, память, что эти ресурсы могут ограничивать админы.
Что есть такие объекты как Limit Range и Resource Quota, их админы применяют, чтобы ограничивать ресурсы и разделять разделять ресурсы по пространствам имен (namespace).
Дальше: разработчику тоже хорошо бы знать, что есть в кластере процессы аутентификации и авторизации, что есть такая штука как RBAC (Role-Based Access Control). Все это используется админами, чтобы разделять права в кластере.Что вообще в кластере есть какие-то права.
Опять же, без этого знания, наверное, жить можно, но это очень сильно помогает налаживать контакт между командами эксплуатации и разработки. Разработчики понимают, что в кластере есть некие ограничения, которые на них применяют, что в кластер иногда может что-то не влезать, и это нормально. Можно посмотреть, например, в describe Pod`а и увидеть, что не влезло, и Pod не запускается потому, что нарушаются некие политики Resource Quotas.
И хорошо бы понимать, что за Resource Quota такая и вообще к кому с этим бежать. Что это нормально: администраторами на кластер установлены лимиты на namespace`ы, и нужно к ним обратиться и сказать: ребята, мы тут в лимит уперлись. Конечно, в идеале у админов должен бы быть на это алерт, и они должны сами на это отреагировать.
Полезно понимать, что, например, у вас могут быть какие-нибудь права на ваш namespace, но отсутствовать права на namespaces других команд. У вас могут быть права на стейдже на создание секретов, а в продакшене их может не быть.
Ну и опять же для того, чтобы просто не бегать со странными вопросами типа «А почему тут я могу сделать, а тут я не могу сделать? А почему так не работает?».
RBAC Kubernetes также может быть полезен для разработчиков, потому что он дает возможность делать собственные авторизационные инструменты для приложений. Так что знания этого механизма, скорее всего, пригодятся. Хорошо, если вы будете использовать его в рамках своего приложения. Можно построить авторизацию в своем приложении или общение между приложениями с помощью RBAC.
Дальше расскажу о самом важном: что разработчику критически нужно знать, если он работает в компании с Kubernetes.
Основные абстракции которые есть в Kubernetes: Pod, Deployment, ReplicaSet, StatefulSet, Job, CronJob. Это всё нужно просто потому, что это то, что описывает твое приложение в рамках кластера Kubernetes.
И если твоя логика работы с кластером заключается в том, что ты отдаешь свой Docker-образ и ждешь, когда из него админы что-то запустят, ты просто теряешь инструмент управления своим приложением в виде возможности настройки Health Check`ов, настройки поведения приложения.
Deployment — это не просто yaml, в котором прописано количество реплик и образ, из которого нужно запуститься. Это настройки безопасности, настройки Health Check`ов, портов, ресурсов, которые хорошо бы понимать.
Вот здесь могу привести пример, я его обычно на конференциях привожу.
Мне один разработчик однажды сказал, что приложение не запускается в кластере. Я посмотрел быстренько в describe Pod`а (опять же разработчику хорошо бы знать, где искать первопричину проблем). А там было написано, что ресурсы на вашем Pod`е очень маленькие, и по логам видно, что приложение просто не запускаются из-за этого. Я ему сказал: подними ресурсы по CPU. Он ответил, что не знает ни про какие ресурсы, он пишет код, а ресурсы — дело админов. Чтобы избегать таких нелепых ситуаций, представления обо всем этом нужно иметь.
Понимать все или хотя бы большинство возможностей, которые нам предоставляет Kubernetes в рамках своих основных манифестов очень ценно, потому что там есть действительно полезные вещи, которые можно использовать для своих приложений.
Я сейчас описал всё на базе Deployment`а. То же самое касается выполнения других задач. У нас, оказывается, в кластере есть Job`ы, и на их базе можно сделать очень много всего. Например, smoke-тесты после релизов, выполнение миграции. А еще есть CronJob`ы, с помощью которых можно на базе кластера реализовывать выполнение каких-то задач по расписанию.
Также важно понимать, для чего нужны StatefulSet`ы и когда они могут пригодиться. По секрету скажу: они нужны не только для баз данных. Как еще их применяют, будем рассказывать на открытой «Вечерней школе Kubernetes для разработчиков».
Как я уже говорил, это возможности, которые самKubernetes дает, и которые можно использовать в рамках своих приложений. Например, важно знать, что есть объект ConfigMap или Secret. Если вам нужно хранить какую-то секретную информацию, вы используете Secret, а в ConfigMap можете сложить свои конфиги, и можете их обновлять независимо от приложения, и они будут доезжать к вашему приложению при обновлении ConfigMap. А если ваше приложение научится замечать изменения своих конфигов на диске, то оно может даже бесшовно релоадиться при изменении всего лишь одного ConfigMap.
Здорово знать, что есть еще более хитрые штуки, например, Pod Disruption Budget.
Такие вещи нам позволяют управлять поведением кластера по отношению к вашему приложению в тот момент, когда ноды кластера выводятся системными администраторами на обслуживание. Это такой контракт в yaml-формате между разработчиком и системным администратором, который может создать разработчик.
Еще не могу не упомянуть про такие штуки как Ingress, Service. Хорошо понимать, что они позволяют вам сделать, как можно построить на сетевом уровне общение между своими компонентами в рамках Kubernetes. Как с помощью того же Ingress можно настроить своё приложение, его проксирование.
Хорошо бы, наверное, понимать, что такое Network Policies. Здесь тема находится на стыке того, что может делать разработчик, специалист по безопасности и системный администратор. Но все же разработчикам не повредит это знание и понимание того, что можно с помощью опять же встроенных средств Kubernetes ограничивать доступ к своим приложениям, разграничивать, кто может в него попасть, кто не может. Из каких namespace`ов, из каких Pod`ов, Service`ов и так далее.
И наконец, умение работать с какими-то шаблонизаторами типа Helm. Тут, думаю, читатели смогут сказать: «да это точно уже задача DevOps`ов, вы что-то от разработчиков хотите слишком много!» Но все же. Понимание, как вообще деплоить в Kubernetes с помощью Helm или с помощью kubectl, думаю тоже не будет лишним для разработчиков.
Потому что, во-первых, специально выделенные инженеры, которые могут за вас все это написать, есть далеко не у всех. Во-вторых, DevOps-инженеров обычно всё-таки меньше, чем разработчиков. Ну и умение в случае чего написать Helm chart для своего приложения или настроить CI/CD, не дожидаясь инженеров эксплуатации, написать себе туда kubectl apply или helm upgrade, я думаю, тоже никому не повредит.
А какие могут возникнуть дополнительные проблемы, если разработчик не понимает, как работает Kubernetes, а продакшен лежит?
Павел Селиванов: Приведу реальные кейсы, которые встречал. Например, разработчики что-то деплоят. И они знают нечто про аннотации в Ingress, которые конфигурируют какие-то параметры. Деплоят их в продакшн, потом оказывается, что они задеплоены с ошибками. И в итоге все ложится.
Никто лучше разработчика, который это выкатывал, не представляет, что он там именно выкатил. Понятно, что если ты вообще не представляешь, что там за аннотации, чего они конфигурируют, что ты вообще пытался сделать и что могло сломаться, ты бежишь к админам, они начинают копаться, кто и что делал. Элементарно поиск проблемы становится командной задачей на много минут или даже на много часов.Если бы разработчик действительно понимал, что он делает, он мог бы легко и просто эту проблему в случае чего устранить откатом и пониманием того, что пошло не так.
Опять же тот пример, который я приводил с ресурсами. Например, когда разработчики, не понимая, что вообще за ресурсы в кластере, для чего они нужны, что они делают, выкатывают свои сервисы на бой, при этом их обычно мигрируют еще с каких-нибудь виртуалок. И у нас получается ситуация, когда какие-нибудь интерпретируемые языки программирования выкатываются с конфигурациями типа «автоматическое количество воркеров». Лимиты при этом разработчик выставляет у себя на подах 100 милли-CPU, приходит нагрузка, автоматика решает, что раз нагрузка пришла, нужно количество воркеров поднять, ну и, соответственно, сотни воркеров начинают работать на одной десятой части одного процессорного ядра. И все ложится.
Этой проблемы можно было бы легко избежать, если бы разработчик заранее знал, что такое лимиты в Deployments приложения в Kubernetes. Знал бы, что их хорошо подбирать, исходя из реальной ситуации. Ну и в принципе какие-то best practices по поводу запуска своих приложений в контейнерной и в кубернетесовой среде, по поводу количества воркеров, которое нужно запустить, по поводу каких-нибудь особенностей настройки java-машины ну и так далее.
Марсель Ибраев: Если про историю из жизни, то на одном из проектов у нас был случай, правда со старой версией приложения Cert-manager, которое выпускает сертификаты. Разработчики наплодили много Ingress`ов. На каждый url они делали отдельный манифест Ingress и все это, естественно, с tls. Как следствие, Cert-manager на каждый URL выпускал каждый раз сертификат. А потом LetsEncrypt благополучно нас забанил. Благо дело это был stage-кластер и получилось просто сменить домен. Если бы это случилось на продакшене, было бы достаточно больно.
Подобные моменты DevOps-инженеры пытаются прикрыть за счет того, что вводят всякие тестирования и еще дополнительные абстракции в кластер, которые валидируют эти объекты. Чтобы вместо 100m CPU не поставили 100 CPU, например. Но факт, что лучше это тоже знать.
Павел Селиванов: Конечно, в идеальном мире это задача DevOps-инженера. И если они есть в компании, естественно, стараются такие вещи закрывать. Но понятно, что не всё и сразу можно закрыть. Поэтому элементарные знания о гигиене в кластере для разработчика могут очень сильно и очень много раз спасти продакшен.
Какие выгоды есть для команды и бизнеса в целом от того, что разработчик знает Kubernetes?
Павел Селиванов: Самое главное — это просто уменьшение time-to-market. Потому что у нас убирается бутылочное горлышко в виде системного администратора, который сидит и вручную по ночам выкладывает каждый сервис, поднимает для него виртуальные машины, пишет конфигурации и так далее.
Особенно это важно в мире микросервисов, в мире Agile-подхода к разработке, когда у нас происходит непрерывное совершенствование продукта, когда разработчики могут каждый день писать новые микросервисы. Понятно, что ожидание команды эксплуатации, которая развернет под это инфраструктуру, становится очень критичным.
То есть вся суть микросервиса вот в чем: разработчик решил, что новый функционал можно реализовать с помощью отдельного приложения, написал его буквально в течение двух дней, запаковал в Docker, нажал одну кнопку, и оно выкатилось. Возможно, даже выкатилось в продакшен.
Элементарное уменьшение time-to-market. Как следствия — преимущество над конкурентами в плане скорости выпуска релизов и уменьшение издержек на содержание огромной команды сопровождения, которая в противном случае это все делала бы руками, создавала эту инфраструктуру и выкатывала. Я думаю, это главное преимущество.
Марсель Ибраев: DevOps`ы и инженеры инфраструктурной команды в принципе ребята достаточно нагруженные. Как правило, их меньше, чем разработчиков, а задачи постоянно есть, они постоянно горячие. И если DevOps-команда будет тратить время на то, чтобы еще строить костыли для разработчиков, потому что они не хотят разбираться в каких-то деталях той инфраструктуры, куда деплоят, то действительно время будет очень сильно растягиваться. Фичи не будут выпускаться так скоро, как хотелось бы.
Павел Селиванов: Что касается преимуществ для команд: для разработки, DevOps, сопровождения. Для разработки понятно — это убирает необходимость ожидания соседней команды, когда тебе развернут инфраструктуру, то есть это позволяет быстро на ходу экспериментировать, поднимать что-то в stage-кластере. Мы тут не говорим о продакшен, конечно. Быстро поднять себе в stage-кластере какую-то инфраструктуру, протестироваться на ней, что-то выкатить.
С точки зрения команд сопровождения, SRE — это дает, естественно, возможность сконцентрироваться на глобальных задачах. Улучшение платформы, автоматизация своих рутинных задач вместо того, чтобы ходить и руками саппортить разработчиков, писать за них манифесты или поднимать за них виртуалки. То есть знание разработчиками Kubernetes позволяет команде сопровождения или эксплуатации стать непосредственным участником разработки. Только не бизнес-логики приложений, а инфраструктурной части всего приложения.
Марсель Ибраев: Я только немного все подытожу. Что, по нашему мнению, требуется знать разработчику? Во-первых, на самом базовом уровне — это умение и понимание, как разрабатывать свое приложение в рамках микросервисной архитектуры. И без этого, наверное, странно подходить к Kubernetes. Далее, конечно, — знание базовых абстракций, с которыми разработчику непосредственно придется работать. Это верхнеуровневое понимание, как работает сам Kubernetes. Это понимание, как деплоить свои приложения (знание инструментария) и, как сказал Павел, в идеале еще понимание, как шаблонизировать свое приложение.
Спасибо за прочтение статьи, это не всё, что мы хотели рассказать.
1 октября каждый сможет развить свои навыки с «Вечерней школой по Kubernetes для разработчиков». Это будет бесплатный курс с практикой, 2 раза в неделю, по вечерам. Смотреть можно будет и в записи.
Изучить программу по дням и зарегистрироваться: https://slurm.club/3DZs9iP.
