Подробный обзор запуска Kubernetes, который поможет вам сделать все правильно с первого раза.

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

Одной из шести категорий является инфраструктура. Когда вы настроите кластер Kubernetes, вы начнете именно с него. В этой статье основное внимание будет уделено облачной инфраструктуре, необходимой для готового к работе стека Kubernetes, так что вы (надеюсь) все сделаете правильно с первого раза.

Настроить Kubernetes в облаке можно всего за несколько кликов на выбранном вами облачном портале. Azure делает это еще проще, чем AWS. Однако, если вам нужен зрелый, готовый к работе стек, ручные действия на портале, в консоли или в любом другом пользовательском интерфейсе — не лучший вариант. Кроме того, настройка Kubernetes по умолчанию, например, с точки зрения сети, к сожалению, не самый безопасный способ. Вам необходимо спроектировать настройку IaC, сетевую стратегию, пулы узлов и окружающую инфраструктуру при создании кластера Kubernetes.

1. Используйте инфраструктуру как код

Прежде всего, Infrastructure as Code должна быть вашей единственной стратегией развертывания, если вы работаете с облачной инфраструктурой. Не используйте пользовательский интерфейс для создания производственной инфраструктуры. Кроме того, старайтесь избегать написания сценариев для своей инфраструктуры с использованием облачных API напрямую или с использованием облачных интерфейсов командной строки, поскольку вам потребуется написать логику кода для всей CRUD вашей инфраструктуры (создание, чтение, обновление, удаление). Лучший способ — настроить инфраструктуру декларативно и указать только желаемое конечное состояние.

Выбор инструмента

Многие инструменты делают инфраструктуру как код. Terraform является наиболее часто используемым инструментом IaC с открытым исходным кодом и имеет наилучшую документацию для быстрого начала работы. Pulumi может быть хорошей альтернативой, если вам нужен инструмент IaC, ориентированный на разработчиков. Более свежим и многообещающим решением IaC является Cross Plane, которое полностью основано на Kubernetes и имеет большой потенциал в качестве решения IaC в стиле GitOps. Он даже запускает Terraform. Но прежде чем идти по этому пути, убедитесь, что вы провели всестороннее тестирование. На данный момент Terraform является наиболее зрелым и широко используемым решением.

Создание конвейеров развертывания инфраструктуры

Наличие IaC уже является большим преимуществом, но чтобы полностью управлять кодом, убедитесь, что вы максимально автоматизируете развертывание. Используйте полуавтоматические конвейеры для развертывания инфраструктуры и не забывайте обращаться с вашей инфраструктурой «как с кодом», что означает, что вы должны автоматически тестировать свою инфраструктуру в конвейере развертывания (например, с помощью Terratest).

Используйте сине-зеленые развертывания

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

2. Имейте сетевую стратегию

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

Планирование IP-адресов

Большинство управляемых облачных служб (таких как AKS или EKS) поставляются с сетью по умолчанию с диапазоном IP-адресов по умолчанию (часто 10.0.0.0/16). Если вы придерживаетесь облачных настроек по умолчанию, у вас возникнут трудности с пиринговыми сетями. Это часто приводит к сложным и запутанным правилам NAT для маршрутизации трафика в перекрывающиеся сети. Лучше сделать все правильно с первого раза, настроив хорошую сетевую архитектуру с предопределенными блоками CIDR. Убедитесь, что ваши частные IP-адреса не перекрываются, в том числе, когда сети еще не подключены друг к другу.

Частные кластеры

Вы, наверное, знаете, что Kubernetes состоит из плоскости управления (также называемой главными узлами) и узлов, на которых вы запускаете свои приложения (рабочие узлы). По умолчанию в Azure (AKS) и AWS (EKS) ваш API плоскости управления будет публично доступен в Интернете, что представляет собой ненужную угрозу безопасности. В недавнем сканировании 380 000 из 450 000 проанализированных кластеров были публично доступны в Интернете. Это увеличивает поверхность атаки, и этого следует избегать. Подробнее о том, как это исправить на АКС или ЭКС, читайте . Белый список VPN или IP-адресов может предоставить инженерам доступ к API Kubernetes, блокируя при этом весь остальной внешний трафик.

Еще одна часть, которую легко пропустить, — это приложения для управления, предоставляющие API и пользовательские интерфейсы (ArgoCD, Prometheus, Grafana, Kubernetes Dashboard и т. д.). Убедитесь, что эти приложения доступны только в частном порядке с использованием белого списка IP-адресов или VPN. Излишне говорить, что вы также должны защищать их с помощью механизмов аутентификации и авторизации.

Входящий и исходящий трафик

Лучшей практикой для общедоступных API и пользовательских интерфейсов в кластере Kubernetes является использование Ingress Controller, связанного с Cloud LoadBalancer, IP и DNS. Таким образом, вы можете централизованно управлять всем входящим трафиком с помощью соответствующих сетевых политик и правил входа. Убедитесь, что эти компоненты надежно настроены, а ваш Ingress Controller регулярно обновляется.

По умолчанию контейнеры Kubernetes в облаке могут обмениваться данными с Интернетом. Однако некоторые компании (например, корпоративные) имеют более строгие стандарты безопасности. Ограничение интернет-трафика из ваших приложений является очень распространенным требованием. Если это так, разработайте правила брандмауэра соответствующим образом. Это также можно организовать внутри Kubernetes с помощью Сетевых политик.

3. Создайте свои группы узлов / пулы

Кластеры Kubernetes можно сравнить с живыми организмами. Как и ячейки, приложения постоянно перемещаются по вашим узлам (ВМ). Их можно убить или масштабировать вверх и вниз. Вам необходимо спроектировать свои приложения и кластеры для этого непрерывного движения. Подумайте о своих приложениях и их требованиях, таких как ЦП, память, хранилище, автоматическое масштабирование и высокая доступность.

Автомасштабирование

Автомасштабирование может быть реализовано на нескольких уровнях — на уровне приложения и узла. Он имеет множество преимуществ. Во-первых, это сократит затраты, поскольку вы платите только за те ресурсы, которые используете. Во-вторых, ваши приложения станут более зрелыми. Приложениям приходится иметь дело с уничтожением, что автоматически дает вам более надежную архитектуру.

Высокая доступность

Kubernetes предназначен для того, чтобы быть «в рабочем состоянии» все время. Если вы хотите предотвратить простои в случае сбоя, убедитесь, что ваш стек настроен на высокую доступность при нескольких уровнях сбоя. Вот как это сделать:

  1. Запустите несколько реплик вашего приложения — несколько модулей (на уровне модуля).
  2. Разверните несколько узлов в кластере (на уровне узла)
  3. Разверните свои узлы в нескольких зонах доступности (уровень AZ)

4. Подключите внешние облачные сервисы

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

  • Реестр контейнеров
  • Управление идентификацией и доступом (IAM)
  • Секретные хранилища
  • Платформы уведомлений, такие как Slack, PagerDuty и т. д.
  • Внешние базы данных
  • Репозитории Git для развертываний GitOps
  • Эмитенты SSL-сертификатов (например, LetsEncrypt)

Для интеграции с этими внешними (облачными) сервисами вам необходимо настроить учетные записи службы Kubernetes с надлежащим доступом и установить операторов Kubernetes, таких как ArgoCD или ExternalSecrets. Со всеми этими внешними инструментами убедитесь, что вы следуете принципу наименьших привилегий из соображений безопасности.

Заключение

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

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

Спасибо за прочтение. Оставайтесь с нами, чтобы узнать больше.