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

121

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

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

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

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

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

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

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

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

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

Йоанис Гил
источник
2
Как вы в итоге это сделали? Пожалуйста, дайте нам знать ... Я тоже учусь и пытаюсь работать наилучшим образом. Похоже, что создание отдельных кластеров, вероятно, правильный путь ...
Петр Кула
3
В итоге у нас было два кластера: один для постановки, а другой для производства. С точки зрения инфраструктуры, требуется дополнительное управление, но в нашем случае уровень изоляции того стоил.
Yoanis Gil
1
@YoanisGil, здесь есть ответ, который можно отметить как принятый?
tdensmore
3
@tdensmore: большинство ответов по-своему хороши. Дело в том, что здесь просто нет одного ответа, и это зависит от рассматриваемого варианта использования. Я думаю, что K8s и его сообщество сильно повзрослели с тех пор, как я впервые задал этот вопрос (почти 3 года назад), и, похоже, есть по крайней мере некоторые минимальные передовые практики, которые можно было бы применить, независимо от того, сколько кластеров используется и для каких целей ( Я думаю о пространствах имен, сетевых политиках, селекторах узлов, seccomp и т. Д.).
Yoanis Gil

Ответы:

33

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

Взгляните на это сообщение в блоге Вадима Эйзенберга ( 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.

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

Эдуардо Байтелло
источник
26

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

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

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

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

Джеймс Страчан
источник
1
ссылка вроде не работает
Тибин
19

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

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

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

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

Освин Ноетцельманн
источник
3
Это все еще обсуждается, но я нашел это обсуждение полезным: groups.google.com/forum/#!topic/kubernetes-users/GPaGOGxCDD8
Индрадхануш Гупта,
1
Я поддержал упоминание двух типов промежуточных сред.
Джон Дэвид
8

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

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

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

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

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

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

Йоанис Гил
источник
6

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

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

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

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

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

Кочиз Рухулессин
источник
Как можно спланировать сбой обновления кластера?
Тибин
2

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

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

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

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

https://about.gitlab.com/images/13_2/MultipleProjectClusters.png

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

VonC
источник
1

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

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

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

Акаш Шарма
источник