Обзор Kubernetes для программистов: как он устроен, как работает и как связан с облаками

Иван Игнатьев

---

Cloud Solution Architect. Живёт во Франции. Работает в Pluto Informatics. Сертифицированный системный администратор Linux Foundation (LFCS), сертифицированный эксперт по Microsoft Azure и администратор и специалист по безопасности Kubernetes.

---

Ссылки

Kubernetes — это оркестратор для контейнеров, написанный на языке Go в Google. Раньше уже существовали решения для создания и развёртывания виртуальных машин — такие как Microsoft Hyper-V или продукты от VMware.

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

Поэтому появился Kubernetes: он позволяет автоматизировать развёртывание целых кластеров с контейнерами, гибко задавать различные политики и настройки и пользоваться подходом Infrastructure as Code.

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

Содержание

Когда стоит использовать Kubernetes

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

А теперь представьте, что у нашего приложения довольно много пользователей и ему требуются серьёзные ресурсы. Понятно, что мы не будем собирать под него суперкомпьютер — современная IT-индустрия выбрала путь распределённых систем, когда какое-то количество относительно слабых серверов собираются в единую распределённую систему и дают необходимые мощность, быстродействие и ресурсы. Это удобно: их количество можно наращивать постепенно, масштабируя ресурсы под требования приложения, а отдельные серверы можно легко заменять, если они вдруг выйдут из строя.

Итак, у нас есть приложение, которое должно крутиться на распределённой системе из десятков или даже сотен серверов. Если мы возьмём Docker или любой другой инструмент для работы с контейнером внутри системы, то каждый сервер придётся настраивать и администрировать отдельно: мы не сможем применить единые конфигурации сразу для всей группы — это будет полуручной труд. И даже если мы напишем набор скриптов для автоматизации, они не станут универсальным решением — в любом другом кейсе придётся писать их снова.

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

Как появился Kubernetes

В книге Site Reliability Engineering описан внутренний проект Google — система управления кластерами Borg. В 2014 году Google опубликовал исходные коды этого проекта, а уже в 2015 году в партнёрстве с Linux Foundation организовал фонд Cloud Native Computing Foundation (CNCF), которому и передал сорцы Kubernetes в качестве своего технического вклада. Этот фонд развивает open-source-проекты по разработке утилит и библиотек, которые позволяют создавать приложения ориентированные на облачные модели архитектур.

Сейчас Kubernetes — alumni, или по-русски «выпускник», Cloud Native Computing Foundation. Его довели до стабильной версии, и он получил статус Graduated Project (завершённый проект) в терминологии CNCF.

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

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

Принцип работы Kubernetes

Kubernetes состоит из двух больших частей (см. изображение ниже):

• Control Plane — оркестратор, API и база конфигурации.
• Node Pools — серверы с доступными ресурсами.

За Control Plane отвечает сервер Kubernetes Master Node. Kubernetes Worker Nodes группируются в Node Pool (пул узлов, нод). Как правило, один Node Pool соответствует группе серверов с одинаковыми заданными характеристиками. Например, пул серверов на базе Windows, пул серверов с Linux и пул серверов с GPU.

На каждой ноде (или узле, отдельном физическом сервере или виртуальной машине) устанавливается агент kubelet — он помогает получать инструкции от сервера Master Node, а также различные компоненты, драйверы и расширения для мониторинга безопасности сети. Всё это складывается в платформу для развёртывания приложения.

Итого: само приложение описывается через deployment-ресурс, который содержит несколько pod (далее — поды), в каждом из которых находится от одного до нескольких контейнеров. Поды как раз и являются единицами масштабирования системы в Kubernetes — своеобразными молекулами, из которых состоит система. Например, когда выбирают, на какой ноде будет запущен тот или иной компонент приложения, минимальной областью ресурсов считается именно под, а не отдельный контейнер или физический сервер.

Принцип работы Kubernetes аналогичен классическим кластерам. Мозг системы — Kubernetes Master Node, который отвечает за Control Plane и содержит:

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

Напомню, что Kubernetes объединяет пулы из нод — то есть серверов, объединённых общими характеристиками. Например, пул из Windows-северов, пул из Linux-серверов, пул из серверов, на которых есть GPU. Ноды объединяются в пулы по определённым характеристикам. Потом администратор сообщает Kubernetes, что это за характеристики: вычислительная мощность, память, хранилище — а Kubernetes самостоятельно распределяет ресурсы, находит в кластере ноды, которые удовлетворяют этим характеристикам, и запускает поды приложения на них.

Можно установить минимальное и максимальное количество подов для приложения, и Kubernetes будет стараться поддерживать это их количество. А вот за поддержание и масштабирование количества нод (то есть отдельных физических серверов или виртуальных машин в составе поды) уже могут отвечать администратор, гипервизор или облачная платформа по типу Azure, GCP, AWS — но не сам Kubernetes.

А если какой-то из элементов инфраструктуры даёт сбой, Kubernetes автоматически пытается решить проблему: например, перезапустить одну поду или deployment, чтобы состояние системы в целом соответствовало конфигурациям, загруженным через API и сохранённым в Master Node. В результате приложение, компоненты которого поделены на поды и контейнеры, крутятся в пространстве ресурсов, объединённых в кластер Kubernetes — в своеобразное облако-контейнер.

Как стать специалистом по Kubernetes

Работать администратором Kubernetes достаточно сложно, потому что нужно хорошо ориентироваться в компонентах и всех аспектах ресурсов Kubernetes. Я представляю это для себя как облако в облаке. Возьмём в качестве примера облачные сервисы IaaS (Infrastructure as a Service) — в них всегда есть несколько слоёв: хранилище, сеть, вычислительные ресурсы и виртуализация. И нам нужно знать весь этот стек, чтобы дойти до возможности установки и настройки Kubernetes.

Но все те же слои будут отображаться ещё и внутри самого Kubernetes: там есть свои особенности организации виртуального хранилища, виртуальной сети и виртуальных вычислительных ресурсов. То есть у нас будет одновременно два стека: стек дата-центра или IaaS-облака + стек Kubernetes.

В результате всё, кроме «физической» сети и общих концепций, администратору придётся учить с нуля. Под общими концепциями я подразумеваю следующее:

• что такое сеть,
• как работать с распределёнными хранилищами,
• как работать с распределёнными вычислительными ресурсами.

Правда, с использованием этих концепций в реальной ежедневной работе с внутренними компонентами Kubernetes тоже придётся разбираться с нуля — что настраивать, чем пользоваться и так далее.

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

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

У меня уже есть сертификаты Certified Kubernetes Administrator (CKA) и Certified Kubernetes Security Specialist (CKS), кроме того, существует Certified Kubernetes Application Developer (CKAD). Это официальные программы от Linux Foundation. На то, чтобы получить сертификаты, мне понадобилось полгода — даже с учётом того, что я работаю с инфраструктурой уже более шести лет.

Для подготовки к CKS я проходил курс Killer Shell Support Team на Udemy. Также у меня есть подписка на Pluralsight, где тоже есть курсы, связанные с CKA, например Certified Kubernetes Administrator (CKA). Есть и подготовительные тренинги от самой Linux Foundation. Правда, они состоят из текста и схем, поэтому мне показались очень скучными, а вот их офлайн-тренинги — очень интересные и живые. На них инструктор показывает всё необходимое буквально за несколько дней и отвечает на вопросы слушателей. А чтобы лучше разобраться в безопасности Kubernetes, рекомендую посмотреть CIS Kubernetes Benchmarks.

Ещё у меня лежат две книги издательства O’Reilly:

• Site Reliability Engineering
• Cloud Native DevOps with Kubernetes

На YouTube тоже много полезного — особенно каналы амбассадоров Kubernetes (их полный список есть на сайте CNCF): они разбирают кейсы, показывают команды, предлагают делать домашние лаборатории — например, поднять микро-Kubernetes на Raspberry Pi. Я рекомендую посмотреть видео с YouTube-канала DevOps-консультанта Nana Janashia.

Какие вопросы задают на собеседовании

Если у вас уже есть сертификаты, то сложность на собеседовании может возникнуть разве что с System Design Interview: каким должно быть приложение, паттерны, Service Mesh, микросервисы (рекомендую отличную презентацию от Netflix). Но эти вопросы относятся уже к проектированию распределённых приложений, а не к самому Kubernetes.

Также компании могут задавать вопросы, связанные со спецификой конкретного провайдера, на котором будет крутиться Kubernetes. Например, в случае Azure, на котором я специализируюсь, помимо Kubernetes есть и своя экосистема — тот же Application Gateway от Microsoft (вот, например, описание кейса по работе с Azure Kubernetes Service).

То есть это специфичные вопросы о том, как Kubernetes будет существовать в конкретном контексте: каком-то дата-центре или облаке. И тут важно становится всё: драйверы, типы хранилищ, которые есть у облачных провайдеров, и как они интегрируются с Kubernetes. Конечно, таких вопросов в сертификации нет, да и нужны они далеко не всем. Рядовому DevOps-инженеру, который будет просто деплоить приложения, это ни к чему. Здорово, если администратор будет это знать, но даже если нет, в команде обычно есть специалист по конкретному облаку, который всегда поможет.

Риски использования Kubernetes и облачной инфраструктуры

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

Самый частый кейс использования Kubernetes во Франции — попытка вырваться из тисков привязки к конкретному вендору (vendor lock).

Достоинство любых облачных сервисов — Platform as a service, то есть приложение можно сразу же развернуть и заниматься более высоким уровнем абстракции, не думая о реализации уровня middleware, наподобие LAMP-stack (Linux/Apache/MySQL/PHP). Но если мы хотим, чтобы наше приложение могло одинаково работать на разных облачных платформах, решением может быть Kubernetes и запаковка приложения в контейнеры. Однако когда наше приложение привязывается к особенностям того или иного PaaS, переход от одного облачного провайдера к другому с технической точки зрения усложняется.

Хотя и при выборе Platform as a Service есть определённый риск стать Vendor locked — ведь существует не так много облачных решений. По сути, мы выбираем между Microsoft, Amazon, Alibaba или «Яндексом». А ведь делать темплейты приходится под конкретную конфигурацию конкретного облачного провайдера.

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

А в случае не с IT-бизнесом мы имеем ещё одну проблему: для таких компаний IT-инфраструктура не является основной, профильной деятельностью (то, что называется Core Business) — они рассматривают её лишь как внутренний сервис для удовлетворения потребностей бизнеса, а значит, команда IT-специалистов у них будет маленькой и поддерживать режим Multicloud будет практически нереально.

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

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

Отличия между решениями разных облачных провайдеров

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

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

Недостатки Kubernetes

Безопасность. В одной технологии много различных компонентов, за безопасностью которых приходится внимательно следить: как внешней, на уровне кластеров и нод, так и внутренней, на уровне конкретных образов. Уже появились специальные AntiMalware-решения под Kubernetes, которые сканируют всё, что происходит внутри контейнера.

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

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

Kubernetes — это всё-таки не PaaS, поэтому приходится запаковывать в контейнеры ещё и middleware, а также зависимости для приложения. Но и эта задача упрощается благодаря огромному количеству уже готовых и преднастроенных образов для контейнеров, которые выложены в публичные реестры.

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

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

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

Возможное решение — самостоятельно пройти сертификацию своего IT-решения. То есть заказать аудит систем, сконфигурировать, выровнять и поддерживать решение по какому-то принятому в индустрии стандарту, а потом, от версии к версии, продолжать регулярно делать аудиты. Но, скорее всего, в этом случае вложенные инвестиции не окупятся.

Лучше использовать решения, предоставляемые облачными провайдерами. Сегодня практически любой облачный провайдер подключает Kubernetes as a Service. Плюс существует понятие Certified Kubernetes — все облачные провайдеры сертифицируют своё Kubernetes-подключение в Cloud Native Computing Foundation, а фонд ведёт список сертифицированных провайдеров и постоянно обновляет его.

Если брать KaaS, то вы будете платить за выделенные вычислительные ресурсы и хранилища. Как правило, в стоимость также включена оплата за Master Node, который предоставляет API и распределяет ресурсы, а вот за Worker Nodes, на которых будут размещаться сами поды, надо будет платить отдельно.

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

Это развяжет руки провайдерам, но усложнит жизнь администраторам. Ведь, например, если я хочу поддерживать Kubernetes в Azure, мне нужно будет лучше понимать, что происходит внутри Azure и понадобится поддерживать знания по конкретному облаку.

Альтернативы Kubernetes

У Kubernetes были конкуренты среди оркестраторов контейнеров. Например, есть кластеры Apache Mesos, HashiCorp Consul, Windows Server, Docker Swarm — они помогают удобно работать с виртуальными машинами и контейнерами. На решениях от этих непрямых конкурентов тоже можно строить инфраструктуру. Однако Kubernetes выиграл войну и стал стандартом де-факто, потому что у него есть много удобных инструментов для управления ролями, доступами, политиками безопасности и идентификацией.

Ещё одна альтернатива Kubernetes — FaaS Serverless-технологии. При таком варианте код приложения будет запускаться в момент запроса, а так как приложение делится на самостоятельные запускаемые функции (созданные под каждый тип запроса), то такие системы становятся более портабельными и интегрируемыми, чем целое приложение, созданное под конкретный PaaS. Подобные решения есть у разных провайдеров, но они обладают кастомным API — например, как у Droplets от DigitalOcean.

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

Кстати, помимо классического Kubernetes, существует и Kubernetes от RedHat — Red Hat OpenShift.

Итоги

• Kubernetes стоит использовать, если в вашем проекте счёт контейнеров идёт на десятки или сотни.
• Kubernetes сам определяет, когда надо масштабировать ресурсы, когда подключить к проекту новые мощности и тому подобное — на основании конфигурации.
• Несмотря на то, что Kubernetes даёт определённую свободу за счёт высокого уровня абстракции, вы всё ещё можете столкнуться с проблемой Vendor Lock. Привязка к специфике крупнейших облачных провайдеров делает решения непереносимыми.
• Чтобы избежать рисков, связанных с блокировкой облачного провайдера, есть смысл разворачивать инфраструктуру на платформе двух провайдеров: один будет основным, а второй — резервным.
• Поддержание Kubernetes-инфраструктуры — дорогое удовольствие, на это нужна крепкая команда специалистов. На внутреннюю команду будет уходить много денег, а на аутстаффе велик риск выбрать неподходящего подрядчика.
• В Европе компании очень медленно переходят на Kubernetes и пока предпочитают более привычные и потому менее рисковые виртуальные машины.