Множественные среды (Staging, QA, production и т. Д.) С Kubernetes

Что считается хорошей практикой с K8S для управления несколькими средами (QA, Staging, Production, Dev и т. Д.)?

В качестве примера предположим, что команда работает над продуктом, который требует развертывания нескольких API вместе с интерфейсным приложением. Обычно для этого требуется как минимум 2 среды:

• Стадия: для итераций / тестирования и проверки перед выпуском для клиента
• Производство: это среда, к которой имеет доступ клиент. Должен содержать стабильные и проверенные функции.

Итак, если команда использует Kubernetes, что было бы хорошей практикой для размещения этих сред? До сих пор мы рассматривали два варианта:

1. Используйте кластер K8s для каждой среды
2. Используйте только один кластер K8s и храните их в разных пространствах имен.

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

(2) Похоже, что это упрощает управление инфраструктурой и развертыванием, потому что существует один единственный кластер, но это вызывает несколько вопросов, например:

• Как убедиться, что человеческая ошибка может повлиять на производственную среду?
• Как убедиться, что высокая нагрузка в промежуточной среде не вызовет потери производительности в производственной среде?

Могут быть некоторые другие проблемы, поэтому я обращаюсь к сообществу K8s на StackOverflow, чтобы лучше понять, как люди справляются с подобными проблемами.

Рекомендации по использованию нескольких кластеров

Взгляните на это сообщение в блоге Вадима Эйзенберга ( IBM / Istio ): Контрольный список: плюсы и минусы использования нескольких кластеров Kubernetes и способы распределения рабочих нагрузок между ними .

Хочу выделить некоторые из плюсов и минусов:

Причины иметь несколько кластеров

• Разделение производства / разработки / тестирования: специально для тестирования новой версии Kubernetes, сервисной сети или другого программного обеспечения кластера.
• Соответствие: согласно некоторым правилам некоторые приложения должны работать в отдельных кластерах / отдельных VPN.
• Лучшая изоляция для безопасности
• Облако / локально: для разделения нагрузки между локальными сервисами

Причины иметь единый кластер

• Сократите накладные расходы на настройку, обслуживание и администрирование
• Улучшение использования
• Снижение цены

Учитывая не слишком дорогую среду со средним уровнем обслуживания, но при этом обеспечивающую изоляцию безопасности для производственных приложений, я бы порекомендовал:

• 1 кластер для DEV и STAGING (разделены пространствами имен, возможно, даже изолированы, с использованием сетевых политик, как в Calico )
• 1 кластер для PROD

Паритет окружающей среды

Хорошая практика - поддерживать как можно более похожую разработку, постановку и производство:

Различия между службами поддержки означают, что возникают крошечные несовместимости, из-за которых код, который работал и прошел тесты при разработке или промежуточном этапе, не работал в производственной среде. Ошибки такого типа создают трение, которое препятствует непрерывному развертыванию.

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

GitLab CI / CD с AutoDevops имеет мощную интеграцию с Kubernetes, что позволяет вам управлять несколькими кластерами Kubernetes уже с поддержкой Helm.

Управление несколькими кластерами ( kubectlвзаимодействиями)

Когда вы работаете с несколькими кластерами Kubernetes, легко запутаться с контекстами и работать kubectlв неправильном кластере. Помимо этого, Kubernetes имеет ограничения на несоответствие версий между клиентом ( kubectl) и сервером (мастер кубернетов), поэтому выполнение команд в правильном контексте не означает запуск правильной версии клиента.

Чтобы преодолеть это:

• Используйте asdfдля управления несколькими kubectlверсиями
• УстановитеKUBECONFIG переменную env для переключения между несколькими kubeconfigфайлами
• Используйте kube-ps1для отслеживания текущего контекста / пространства имен
• Используйте kubectxиkubens для быстрого переключения между кластерами / пространствами имен
• Используйте псевдонимы, чтобы объединить их все вместе

У меня есть статья, в которой демонстрируется, как это сделать: Использование разных версий kubectl с несколькими кластерами Kubernetes.

Я также рекомендую следующие книги:

• Освоение файла KUBECONFIG Ахметом Альпом Балканом ( инженер Google )
• Как Zalando управляет 140+ кластерами Kubernetes , Хеннинг Джейкобс ( Zalando Tech )

Определенно используйте отдельный кластер для разработки и создания образов докеров, чтобы ваши промежуточные / производственные кластеры можно было заблокировать с точки зрения безопасности. Независимо от того, используете ли вы отдельные кластеры, staging + productionрешать вам, исходя из соотношения рисков и затрат - разумеется, их разделение поможет избежать stagingвлияния production.

Я также настоятельно рекомендую использовать GitOps для продвижения версий ваших приложений между вашими средами.

Чтобы свести к минимуму человеческую ошибку, я также рекомендую вам как можно больше обратить внимание на автоматизацию CI / CD и продвижения по службе.

Вот демонстрация того, как автоматизировать CI / CD с несколькими средами в Kubernetes с использованием GitOps для продвижения между средами и средами предварительного просмотра по запросам на извлечение, что было сделано в реальном времени на GKE, хотя Jenkins X поддерживает большинство кластеров Kubernetes.

Это зависит от того, что вы хотите протестировать в каждом из сценариев. В общем, я бы старался избегать запуска тестовых сценариев в производственном кластере, чтобы избежать ненужных побочных эффектов (влияние на производительность и т. Д.).

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

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

Для управления различными кластерами я предпочитаю иметь отдельную машину ci / cd, которая не является частью кластера, но используется для запуска и выключения кластеров, а также для выполнения работ по развертыванию, запуска тестов и т. Д. Это позволяет настраивать и завершать работу. кластеры как часть сценариев автоматического тестирования.

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

• минимум 3 мастера для производственного кластера и минимум один мастер для промежуточного
• 2 файла конфигурации Kubectl для добавления в систему CI / CD

Также не будем забывать, что может быть более одной среды. Например, я работал в компаниях, где есть как минимум 3 среды:

• QA: здесь мы выполняли ежедневные развертывания и где мы проводили внутреннее тестирование перед выпуском для клиента)
• Контроль качества клиента: здесь мы развернули его перед развертыванием в производственной среде, чтобы клиент мог проверить среду перед выпуском в производственную среду)
• Производство: здесь развертываются производственные службы.

Я думаю, что эфемерные кластеры / кластеры по запросу имеют смысл, но только для определенных случаев использования (тестирование нагрузки / производительности или очень «большая» интеграция / сквозное тестирование), но для более устойчивых / липких сред я вижу накладные расходы, которые можно уменьшить запустив их в одном кластере.

Думаю, я хотел обратиться к сообществу k8s, чтобы узнать, какие шаблоны используются для таких сценариев, как те, которые я описал.

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

• Убедитесь, что вы также группируете узлы для каждой среды с помощью меток. Затем вы можете использовать nodeSelectorресурсы on, чтобы убедиться, что они работают на определенных узлах. Это снизит вероятность перераспределения (избыточного) потребления ресурсов между средами.

• Рассматривайте свои пространства имен как подсети и по умолчанию запрещайте весь исходящий / входящий трафик. См. Https://kubernetes.io/docs/concepts/services-networking/network-policies/ .

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

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

Использование нескольких кластеров является нормой, в самом списке, чтобы обеспечить четкое разделение между производственной и «непроизводственной».

В этом духе обратите внимание, что GitLab 13.2 (июль 2020 г.) теперь включает:

Развертывание нескольких кластеров Kubernetes в Core

Использование GitLab для развертывания нескольких кластеров Kubernetes с GitLab ранее требовало лицензии Premium.
Наше сообщество говорило, и мы слушали: развертывание в нескольких кластерах полезно даже для отдельных участников.
Основываясь на ваших отзывах, начиная с GitLab 13.2, вы можете развертывать в нескольких кластерах групп и проектов в Core.

Смотрите документацию и выпуск /

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

Сетевая политика - запретить рабочей нагрузке среды dev / qa взаимодействовать с производственными / промежуточными хранилищами.

Контроль доступа - кто имеет доступ к разным ресурсам среды с помощью ClusterRoles, Roles и т. Д.