12 друзей инженера, работающего с Kubernetes
12 друзей инженера, работающего с Kubernetes
Привет, Хабр! Курсы по Kubernetes мы в Слёрме делаем с 2018 года, при этом постоянно дополняем, обновляем и улучшаем программы и материалы. Недавно наши эксперты дорабатывали программу для продвинутого курса по Kubernetes и составили список тем, которые, по их мнению, должен знать специалист, чтобы перейти с базового уровня владения k8s на продвинутый.
Тем получилось 12. В статье перечисляем эти темы с небольшими пояснениями о том, какую пользу принесут такие знания системным инженерам, администраторам БД, инфраструктурным разработчикам и архитекторам ИТ-систем. Поехали!
1. Создание отказоустойчивого кластера
Это основной момент, важный для любого инженера, работающего с Kubernetes. Ещё на базовом уровне нужно знать, из каких компонентов вообще состоит k8s, как они между собой взаимодействуют и как эти компоненты можно собирать вместе.
На продвинутом уровне их уже нужно не просто собирать, а создавать высокодоступную и отказоустойчивую конфигурацию. Чтобы это делать, важно глубоко понимать, как Kubernetes работает изнутри. А ещё уметь размещать компоненты на железных серверах с нужными настройками и в нужном количестве.
2. Идентификация пользователя в кластере
Это тема для компаний, в которых есть централизованные системы аутентификации и нужно организовать доступ в кластер Kubernetes для десятков сотрудников. Кластер Kubernetes можно научить работать не по токену сервис аккаунта или сертификату, а по внешним централизованным системам аутентификации, которые уже настроены в компании.
Это может быть сделано через Nginx, Gangway или другие инструменты.
3. Network Police
Сетевые политики — шаг в сторону безопасности и изоляции неймспейсов. По умолчанию неймспейс— это чисто логическое разделение, никаких физических ограничений между ними нет. Под, запущенный в одном неймспейсе, может послать запросы в под в другом неймспейсе. Для этого поду нужно знать IP-адреса других подов, как-то их подобрать либо знать названия сервисов в другом неймспейсе.
Сетевые политики — это кластерный firewall, который позволяет ограничивать трафик между сущностями Kubernetes. Мы можем ограничивать трафик для определённых подов, а можем для всех, запущенных в конкретном неймспейсе. Причём ограничить можно как входящий, так и исходящий трафик.
Есть сетевые политики, которые настраиваются манифестами Kubernetes, а есть те, которые настраиваются манифестами конкретного CNI. То есть, соответственно, у Calico или Cilium есть свой набор манифестов для настройки сетевых политик. И политики, которые реализуются конкретным CNI, позволяют делать более хитрые вещи.
Например, сетевые политики Kubernetes позволяют описать ограничения по IP-адресам, по меткам пода, по меткам неймспейса и по портам, по протоколам. А в том же Cilium можно описать ограничения по содержимому HTTP-пакетов. То есть эксплуатировать определённые хосты и пути, которые прописаны в HTTP-пакетах.
4. Безопасность и высокодоступные приложения в Kubernetes
Здесь речь не про информационную безопасность, а скорее про безопасность с точки зрения комфортной работы со множеством приложений на общем сервере. Здесь можно затронуть сразу несколько тем:
Pod Security Police — позволяет не пропускать в кластер манифесты с опасными инструкциями. Например те, которые выдают контейнеру права менять настройки сетевого стека.
Pod Description Budget — инструмент, который позволяет обезопасить свое приложение от админов, защита от их некорректных действий в кластере. Например, может запретить убивать под твоего приложения, пока не будет запущено определенное количество подов.
Limit Rangers, Resource Quotas — защита от переполнения, описание квоты ресурсов на определённом неймспейсе.
5. Kubernetes под капотом
Для продвинутых пользователей важно уже на уровне кода понимать, как реализован Kubernetes, какие в нем есть оптимизации и почему нельзя так просто взять и написать свой Kubernetes. Зато можно писать собственные операторы, чтобы расширить функционал Kubernetes конкретно под свои потребности.
6. Stateful-приложения в кластере
Понимание того, как в Kubernetes запускать базу данных. Что это теоретически возможно, но легко может принести гораздо больше проблем, чем пользы.
7. Хранение секретов
Вообще хранить secrets внутри Kubernetes не стоит. Поэтому ИТ-специалисту важно понимать, какие есть внешние системы для их хранения, как прозрачно передавать секреты, как сделать всё безопасно и правильно.
8. HorizontalPodAutoscaler
Это увеличение количества подов в зависимости от нагрузки. Первый способ это сделать — опираться только на метрики нагрузки на CPU. Второй — управлять количеством подов в зависимости от разных метрик. Например, можно ориентироваться на количество запросов в минуту. Если по этим метрикам видно, что на наш сервис приходит тысяча запросов в минуту, мы можем сказать, что для их обслуживания надо запустить 10 подов. Если запросов начинает приходить 3000, надо запустить 30 подов. Это всё тоже можно настроить средствами Kubernetes.
9. Резервное копирование кластера
Прежде всего здесь важно понимать, когда состояние кластера Kubernetes копировать нужно, а когда не нужно. Ну и, конечно, знать, как это сделать — какие есть варианты, в каких конкретных ситуациях их применять. Стандарт — это работа с утилитой Velero, которая позволяет снять копию, получить все манифесты, которые есть в кластере и все java-файлы, которые хранятся в базе.
10. Ротация сертификатов в кластере
Часть компонентов кластера идентифицируются между собой по сертификатам TLS. И у этих сертификатов есть срок действия, по умолчанию — год. В итоге через год сертификаты истекают, компоненты не могут общаться друг с другом и кластер превращается в тыкву. Поэтому важно знать, как продлевать сертификаты и определять, какие вообще нуждаются в продлении.
11. Deploy
По умолчанию в Kubernetes представлен один вариант деплоя — Rolling Update, с волнообразным обновлением системы. 10 инстансов запущено, один удаляется, новый поднимается, всё продолжается дальше.
Но есть вариант с Blue-Green Deploy, когда мы поднимаем рядом полностью рабочую новую версию и потом просто переключаем запросы со старой версии до новой. И Canary deploy, когда мы поднимаем новую версию и отправляем на нее небольшую часть входящего трафика, чтобы посмотреть, что всё нормально работает, а затем постепенно переключаем на неё остальной трафик.
12. Service mesh
Service mesh — это инструмент для организации интеллектуального взаимодействия между микросервисами вашего приложения. Она позволяет, например:
Добавить аутентификацию, чтобы запросы к микросервисам мог посылать только тот, кому это разрешено.
Добавить ретраи, чтобы, если микросервис сломался, можно было не трогать detra-service источника, а направить запрос на интсанс, который повторит его автоматически.
Сделать так, чтобы service mesh сама генерировала информацию о том, что через определённое время не получен нужный ответ, и возвращало ошибку.
Все эти темы мы разбираем в Слёрме на курсе «Kubernetes Мега». Это курс для тех, кто уже работал с Kubernetes или проходил курс «Kubernetes База: стартовый курс для администраторов». Новый поток стартует осенью, но записаться можно уже сейчас. Внутри — все эти темы плюс много практических занятий и AMA-сессии со спикерами.
