Что нужно знать для продвинутой работы с Kubernetes

Привет, Хабр! Мы в Слёрме помогаем IT-специалистам повысить квалификацию и использовать IT-инструменты более эффективно.

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

Расскажем, что это за темы, почему они важны и какую пользу принесут системным инженерам, администраторам БД, инфраструктурным разработчикам и архитекторам IT-систем.

Создание отказоустойчивого кластера

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

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

Идентификация пользователя в кластере

Это тема будет интересна для сотрудников компаний, в которых есть централизованные системы аутентификации и нужно организовать доступ в кластер Kubernetes для нескольких десятков человек. Проще всего выдавать доступы в кластер Kubernetes по токену от сервис аккаунта или по сертификату, но после прослушивания лекции и выполнения практической части вы легко сможете настроить API-сервера своего кластера на валидацию пользователей в корпоративном LDAP, AD или через OIDC.

Network Policy

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

Сетевые политики — это кластерный firewall, который позволяет ограничивать трафик между сущностями kubernetes. Мы можем ограничивать трафик для определенных pod, а можем для всех, запущенных в конкретном namespace. Причем ограничить как входящий, так и исходящий трафик.

Безопасность и высокодоступные приложения в Kubernetes

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

• PodSecurityPolicy — позволяет не пропускать в кластер манифесты с опасными инструкциями. Например те, которые выдают контейнеру права менять настройки сетевого стека или монтировать внутрь контейнера произвольные каталоги узла.

• PodDisruptionBudget — инструмент, который позволяет обезопасить свое приложение от админов, защита от их некорректных действий в кластере. Например, может запретить убивать pod твоего приложения, если их количество меньше установленного в PDB значения.

• LimitRange, ResourceQuota — установка максимальных и минимальных значений для реквестов и лимитов памяти и процессора для пода. Настройка квоты на количество ресурсов памяти, процессора и на количество манифестов различных типов (service, persistancevolumeclame, secret и т.п.) которые можно использовать в определенном namespace.

Kubernetes под капотом

На продвинутом уровне неплохо будет уже на уровне исходного кода понимать, как реализованы системные компоненты Kubernetes, такие как API-сервер, controllermanager и scheduler, какие в них есть оптимизации и почему нельзя так просто взять и написать свой Kubernetes. Зато можно написать собственные операторы, чтобы расширить функционал Kubernetes конкретно под свои потребности.

Stateful приложения в кластере

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

Хранение секретов

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

HorizontalPodAutoscaler

Это технологи автоматического увеличения количества запущенных инстансов приложения в зависимости от нагрузки. Первый способ это сделать — опираться только на метрики нагрузки на CPU. Второй — управлять количеством pod в зависимости от разных метрик. Например, можно ориентироваться на количество запросов в минуту. Если по этим метрикам видно, что на наш сервис приходит тысяча запросов в минуту, мы можем сказать, что для их обслуживания надо запустить 10 pod. Если запросов начинает приходить 3000,  надо запустить 30 pod. Это все тоже можно настроить средствами Kubernetes.

Резервное копирование кластера

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

Ротация сертификатов в кластере

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

Deploy

По умолчанию в Kubernetes представлен один вариант деплоя — Rolling Update, с волнообразным обновлением приложения. Когда старая версия приложения плавно заменяется новой, по одному инстансу за раз.

Но с помощью простых техник можно организовать Blue-Green Deploy, когда мы поднимаем рядом полностью рабочую новую версию и потом просто переключаем запросы со старой версии до новой, или Canary Deploy, когда мы поднимаем новую версию и отправляем на нее небольшую часть входящего трафика, чтобы посмотреть, что все нормально работает. И постепенно переключаем на нее все больше людей.

Service mesh Istio

Service mesh  — это инструмент для организации интеллектуального взаимодействия между микросервисами вашего приложения. Обзорная лекция даст понимание, какие возможности добавляет servicemesh, сколько это будет стоить и насколько необходимо использовать эту технологию в ваших проектах. На практике поднимем Istio и посмотрим как можно реализовать управление трафиком между микросервисами.

Все эти темы мы разбираем в Слерме на курсе «Kubernetes Мега». Это курс для тех, кто уже работал с Kubernetes или проходил наш прошлый курс «Kubernetes База». Новый поток стартует осенью, но записаться можно уже сейчас. Внутри — все эти темы плюс много практических занятий, чтобы попробовать все сделать своими руками.