Начало работы с Kubernetes в облаке

Kubernetes^® — система, которая требует определённой квалификации и опыта. Ведь после установки кластера необходимо настроить целый ряд параметров, среди которых права доступа, сетевые настройки, мониторинг, сбор логов, файловое хранилище. И только тогда систему можно будет считать стабильной и безопасной.

Для небольших проектов глубоко погружаться в тонкости Kubernetes^® необязательно. Например, с помощью Minikube, упрощённой реализации полноценного Kubernetes-кластера, можно развернуть кластер за 15 минут путём ввода нескольких консольных команд. У вас будет кластер с одним узлом, что достаточно для локальной разработки или начального изучения k8s. А что, если нужен более производительный вариант?

Тогда стоит выбрать решение Managed (управляемый) Kubernetes^®. Создание кластера в облаке — задача, с которой справится любой IT-специалист, хотя бы базово знакомый с технологией. Понимание основных концепций позволит правильно выбрать параметры сети, политик безопасности, количество подов на узле. И при этом не придётся погружаться в тонкости установки и настройки кластера.

В Yandex Cloud существует целая экосистема, связанная с контейнерами. Она состоит из трёх элементов:

1. Managed Service for Kubernetes^®. Оркестратор контейнеров, который поможет решить задачу любого размера и сложности.

2. Serverless Containers. Почти как облачные функции, только вместо функций — контейнеры. Этот сервис запускает контейнеризованные приложения без применения виртуальных машин, которыми нужно управлять.

3. Container Registry. Сервис для управления Docker-контейнерами и хранения образов в нашем облаке.

Что даёт Managed Service for Kubernetes^®Что даёт Managed Service for Kubernetes^®

Сервис Managed Service for Kubernetes^® предоставляет окружение для работы с контейнеризованными приложениями в инфраструктуре Yandex Cloud. Вы можете разворачивать, масштабировать и управлять приложениями в контейнерах с помощью Kubernetes^®.

Сервис позволяет предоставлять доступ к приложениям при помощи публичных и внутренних сервисов, а также решений, представленных в нашем маркетплейсе. Все данные безопасно хранятся и реплицируются в инфраструктуре Yandex Cloud. При необходимости можно организовать резервное копирование данных из Kubernetes^® и хранить их в Object Storage или другом хранилище.

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

У Kubernetes^® есть графический интерфейс управления, который решает свои задачи. Но мы разработали более удобный UI, доступный всем пользователям Managed Service for Kubernetes^®. Его преимущество в том, что он уже интегрирован с Yandex IAM, правами в облаке, мониторингом и другими сущностями Yandex Cloud. В нём можно просматривать все нужные параметры, не переключаясь на отдельные дашборды для Kubernetes^®, облачной инфраструктуры и т. д.

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

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

• Детализация потребления ресурсов. Вы можете контролировать потребление CPU, памяти и сетевых ресурсов по каждому узлу и поду.

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

• Гибкий фильтр событий. Вы можете фильтровать события в кластере по пространству имён, уровню или сущности.

Помимо UI-интерфейса, облачная платформа Yandex Cloud поддерживает возможность создания и управления кластером через API, CLI, SDK и Terraform.

Инфраструктура Managed Service for Kubernetes^®Инфраструктура Managed Service for Kubernetes^®

Managed Service for Kubernetes^® работает поверх других сервисов Yandex Cloud. Например, реализованы интеграции с балансировщиками, дисками, сервисами шифрования.

Обновление версий происходит автоматически. У Kubernetes^® есть три релизных канала для обновления:

• Rapid. Публикуются свежие версии Kubernetes^®. Здесь часто появляются небольшие обновления с новой функциональностью и улучшениями. Подходит для непродуктивных сред разработки и тестирования.

• Regular. Публикуются только протестированные версии. Подходит для большинства продуктовых сред.

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

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

Хранение данных в Managed Service for Kubernetes^®Хранение данных в Managed Service for Kubernetes^®

Kubernetes^® хорошо адаптирован для запуска приложений без хранения состояний (Stateless). Но иногда возникают задачи, которые требуют хранения каких-то данных (Stateful): запуск кэшей, баз данных или загружаемых пользователями данных. И требуется «оторвать» жизненный цикл контейнера от жизненного цикла данных.

Вот здесь и приходят на помощь тома Kubernetes^®. Работа с постоянными томами Kubernetes^® осуществляется с помощью объектов API PersistentVolume (PV) и PersistentVolumeClaim (PVC).

• PV — это ресурсы кластера Kubernetes^®, которые существуют независимо от подов. Поэтому предоставленные PV диск и данные продолжают существовать при изменении кластера, удалении и повторном создании подов. Можно сказать, что PV — это эквивалент диска.

• PVC — это запрос от пользователя к Persistent Volumes на хранение, то есть фактически запрос на диск. Объекты PersistentVolumeClaim запрашивают определённый размер, режим доступа и класс хранилищ для объекта PersistentVolume.

Обратите внимание на возможность интеграции решения с дисками. Диск — это виртуальный аналог физических накопителей (SSD, HDD). Он тоже предназначен для хранения данных и подключается к виртуальным машинам. Диск можно отключить, данные на нём сохраняются.

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

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

Масштабирование и отказоустойчивость Managed Service for Kubernetes^®Масштабирование и отказоустойчивость Managed Service for Kubernetes^®

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

В любой установке Kubernetes^®, даже on-premise, есть инструмент Horizontal Pod Autoscaler. Он позволяет динамически изменять количество подов согласно нагрузке. Но здесь есть важная особенность: если кончатся узлы для размещения подов, их нужно будет добавлять вручную. Или предусмотреть наличие постоянно запущенных резервных узлов, но тогда никакой экономии от автомасштабирования не получается. И не исключено, что в момент непредвиденной пиковой нагрузки может не хватить даже этих резервов.

В Yandex Cloud есть Cluster Autoscaler, который отслеживает нагрузку на узлы и при необходимости изменяет их количество в указанных пределах. Благодаря автомасштабированию вопрос простоя оборудования решается парой кликов. Задайте нижнюю и верхнюю границы количества узлов при создании кластера, а система сама будет следить за этим параметром. Инструменты Managed Service for Kubernetes^® масштабируют ваш кластер до любого числа узлов, требуемых в данный момент. Более подробно про автоматическое масштабирование в кластере Kubernetes^® мы рассказали в нашем вебинаре.

Ещё один важный аспект работы с облачными решениями Yandex Cloud — высокая отказоустойчивость инфраструктуры. Чтобы ваша система стабильно работала даже в условиях пиковых нагрузок, можно создать региональный отказоустойчивый кластер.

Возможно, вы уже знаете, что кластеры могут быть зональными и региональными.

• Зональный разворачивается в одной зоне доступности. Все узлы расположены в одном дата-центре или географической зоне (городе или районе). Пользователь получает один мастер-узел, и отказоустойчивость тут весьма условная. Стабильность работы инфраструктуры в дата-центрах обеспечивается путём резервирования и дублирования критических узлов. Но ЧП природного или техногенного характера, а также аварии, причиной которых стал человеческий фактор, могут привести к тому, что центр обработки данных перестанет функционировать, а доступ к кластеру будет утерян. Такой вариант подойдёт для dev-сценариев. Для тестовых сред можно создать зональный кластер с одним мастер-узлом. Это получится значительно дешевле, чем региональный отказоустойчивый кластер.

• Managed-решение позволяет создать региональный отказоустойчивый кластер. Он разворачивается в трёх мастер-узлах (ЦОД во Владимирской, Рязанской и Московской областях) за внутренним балансировщиком. Это даёт отказоустойчивость, которую гарантирует SLA Yandex Cloud. Авария в любом из дата-центров никак не скажется на ваших приложениях: мастер-узлы в остальных дата-центрах продолжат работать, и все сервисы будут доступны.

В кластер можно добавлять ноды с GPU, что позволяет реализовывать ML-сценарии. Yandex Cloud предлагает карты NVIDIA^® Tesla^® A100 и NVIDIA^® T4.

Обновление кластеров в Managed Service for Kubernetes^®Обновление кластеров в Managed Service for Kubernetes^®

Кластер, как и любая другая система, нуждается в периодическом обновлении. On-premise решение предполагает, что вам придётся самостоятельно обновлять и тестировать кластер. Если учесть некоторую сложность освоения Kubernetes^®, велик риск допустить ошибки, исправлять которые придётся самостоятельно, тратя на это силы и время. Обновление кластера без простоя — ещё более сложная задача.

В Managed Service for Kubernetes^® кластеры обновляются автоматически. Все новые версии Kubernetes^® сначала тестируются и только потом устанавливаются на кластеры клиентов. Вам остаётся лишь проверить корректность работы сервисов и приложений в новой версии Kubernetes^®.

Как контролировать процесс обновления:

• Задать расписание. Укажите конкретные дни и время установки обновления. Популярный вариант — ночь с пятницы на субботу. При такой настройке в случае непредвиденных ситуаций остаётся время на исправление. Перед установкой обновления администратору приходит уведомление.

• Установить ручное обновление. Выберите эту опцию, чтобы ставить каждое обновление по мере необходимости.

Безопасность Managed Service for Kubernetes^®Безопасность Managed Service for Kubernetes^®

Сетевые политики Kubernetes^® позволяют настроить сетевое взаимодействие между группами подов и узлами сети. Вы можете создать сетевые политики с помощью Kubernetes Network Policy API, который задаёт правила фильтрации трафика на уровне подов. Правила определяют, какие поды и сервисы в кластере Kubernetes^® могут получить доступ друг к другу.

Для управления сетевыми политиками в Managed Service for Kubernetes^® используются контроллеры Calico и Cilium. Сетевой контроллер Calico использует правила iptables, а Cilium — технологию eBPF.

Помимо разграничения сетевого доступа, важно уделить внимание контролю конфигурации объектов кластера. За этот аспект безопасности отвечает Kyverno-policies, расширение для Kyverno. Политики безопасности представлены в Kyverno как ресурсы Kubernetes^®. Kyverno поддерживает kubectl, git и kustomize. Интерфейс командной строки Kyverno можно использовать для тестирования политик и проверки ресурсов как часть конвейера CI/CD.

Kyverno-policies содержит реализацию Kubernetes Pod Security Standards (PSS). При установке расширения можно выбрать режим работы политик: audit (только оповещение) или enforce (блокировка). Отправлять оповещения из Kyverno в другие системы можно с помощью расширения kyverno-policy-reporter, оно поддерживает выгрузку в Object Storage.

Если говорить о безопасности, то нужно вспомнить и такое понятие, как секреты. В Kubernetes^® секреты (secrets) — это внутренние объекты, которые хранят в себе конфиденциальную информацию: ключи, пароли, API-токены. Доступ к этим данным должен быть ограничен. Но при развёртывании приложения в Kubernetes^® мы сталкиваемся с проблемой: по умолчанию секреты хранятся в формате Base64, что не позволяет организовать безопасную передачу этих данных внутрь Kubernetes^®, например в YAML-манифесте.

Поэтому для хранения секретов и их безопасной передачи внутрь Kubernetes^® чаще всего используют внешние Secret Managers, которые агрегируют все секреты в едином хранилище и поддерживают версионирование и аудит событий. Использование Secret Manager позволяет снизить риск утечки секретов в незашифрованном виде.

В Yandex Cloud разработали собственный Secret Manager — Lockbox. Этот сервис для создания и хранения секретов в консоли управления или через API поддерживает шифрование секретов с помощью ключей Key Management Service, разграничение доступа и централизованное хранение. Для интеграции Lockbox и Kubernetes^® использован open source продукт External Secrets. Секреты, хранящиеся в Lockbox, передаются в нужные пространства имён с помощью External Secrets Operator, при этом аудит событий выгружается в сервис Audit Trails.

Начало работы с Kubernetes^®. Запуск кластераНачало работы с Kubernetes^®. Запуск кластера

Коротко подытожим сказанное:

1. Чтобы упростить администрирование и интеграцию, Yandex предлагает собственный сервис Managed Service for Kubernetes^® для работы в Yandex Cloud.

2. При использовании Managed Service for Kubernetes^® вы создаёте кластер и группы узлов. При этом мастер-ноды, пространство имён, сервис DNS и прочие необходимые элементы развёртываются автоматически. А за обслуживание и обновление всей инфраструктуры кластера отвечает облачный провайдер.

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

4. У Managed Service for Kubernetes^® есть свой графический интерфейс. Дополнительные расширения не требуются.

5. Для хранения Docker-образов используйте Yandex Container Registry.

6. Мастер-узел можно настроить так, что он будет автоматически реплицироваться во всех зонах доступности Yandex Cloud.

7. Благодаря интеграции с Yandex Identity and Access Management можно добавлять пользователей в кластеры Kubernetes^® по учётным записям вашей организации или почте на @yandex.ru.

А теперь для примера создадим кластер Kubernetes^® и группу узлов в нём.

Шаг 1. Выбор каталога для проектаШаг 1. Выбор каталога для проекта

В консоли управления облаком выберите каталог для кластера.

Шаг 2. Создание кластераШаг 2. Создание кластера

Выберите сервис Managed Service for Kubernetes^®. Нажмите кнопку Создать кластер. Заполните настройки кластера, указав его имя, описание и другие параметры.

Обратите внимание, для Kubernetes^® необходим сервисный аккаунт для ресурсов и узлов. Он требуется уже созданным узлам самого кластера Kubernetes^® для доступа к другим ресурсам. Например, чтобы получить Docker-образы из Container Registry. Создайте такой аккаунт, задав ему нужные права.

Ключ шифрования Key Management Service позволяет защитить конфиденциальную информацию (пароли, OAuth-токены и SSH-ключи) и повысить безопасность. Это необязательно: кластер запустится и без ключа. Не создавайте его.

О каналах Rapid, Regular, Stable мы уже говорили ранее. Внимательно выбирайте релизный канал, потому что изменить его после создания кластера Kubernetes^® нельзя. Для примера выберем Stable.

Шаг 2.1. Конфигурация мастераШаг 2.1. Конфигурация мастера

Следующий этап — это конфигурация мастера, главной ноды группы узлов кластера, которая следит за состоянием Kubernetes^® и запускает управляющие процессы.

Выберите версию Kubernetes^® (доступность версий зависит от релизного канала) и задайте автоматическое присвоение кластеру публичного IP-адреса. Благодаря этой опции IP будет назначаться из пула свободных адресов. Без автоматического назначения IP-адресов вы не сможете подключиться к кластеру: он будет виден только внутри вашего облака.

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

Шаг 2.2. Настройка обновленийШаг 2.2. Настройка обновлений

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

Шаг 2.3. Сетевые настройки кластераШаг 2.3. Сетевые настройки кластера

Теперь займёмся сетевыми настройками кластера. Сетевые политики для кластера Kubernetes^® необязательны, поэтому не выбирайте эту опцию.

Во время работы кластера Kubernetes^® внутренние IP-адреса будут автоматически присваиваться подам с контейнерами и сервисам самого кластера. Чтобы IP-адреса подов и сервисов Kubernetes^® не пересеклись с другими адресами в вашем облаке, задайте CIDR, но оставьте адреса пустыми. Тогда они будут назначены автоматически.

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

Настройка завершена, теперь можно нажимать кнопку Создать. Подождите минут десять, пока статус кластера не станет RUNNING, а состояние — HEALTHY. После этого можно заниматься созданием групп узлов.

Шаг 3. Управление узламиШаг 3. Управление узлами

Зайдите в созданный кластер, откройте раздел Управление узлами и нажмите Создать группу узлов. Каждый узел — это одна виртуальная машина.

Задайте имя и описание группы, выберите версию Kubernetes^®. Чтобы система была стабильнее, выберите автоматический тип масштабирования. Укажите количество узлов, в нашем случае их может быть от 1 до 5.

Шаг 3.1. Сетевые настройки узлаШаг 3.1. Сетевые настройки узла

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

Остальные настройки оставьте по умолчанию. Нажмите Создать группу узлов и дождитесь, пока операция выполнится. Теперь у вас есть рабочий кластер Kubernetes^® с группой узлов.

В заключенииВ заключении

Мы описали далеко не всё, что может предложить Yandex Cloud для решения задач Kubernetes^®. С помощью платформы удобно выполнять и другие задачи. Например, находить уязвимости в образах контейнеров, шифровать секреты в etcd‑хранилище или интегрироваться с инструментами CI/CD. Более подробно об этих и других возможностях вы можете узнать из нашего вебинара Kubernetes^®. Managed на все 100%.