Несколько окружений (постановка, QA, производство и т.д.) С Kubernetes

Ответ 1

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

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

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

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

Ответ 2

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

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

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

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

Ответ 3

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

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

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

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

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

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

Ответ 4

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

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

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

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

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

Ответ 5

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

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

Контроль доступа - у кого есть доступ к различным ресурсам среды с использованием ClusterRoles, Roles и т.д.

Ответ 6

Рассмотрение нескольких кластеров

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

Я хотел бы выделить некоторые плюсы и минусы:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я также рекомендую это прочитать: Освоение файла KUBECONFIG