Пространство имен на развертывание в kubernetes

Question

Мне нужен совет по управлению развертыванием в K8S. Мне нужно иметь сине-зеленое развертывание, используя gitops, и это оставляет мне два основных варианта:

1. Использовать одно пространство имен.

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

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

Минусы: управляется штурвалом, может что-то испортить, особенно в нескольких неудачных развертываниях ; может создать пространство имен снежинки, если кто-то быстро исправит / добавит какой-либо ресурс и не будет делать репо;

2. Использование одного пространства имен на развертывание

Просто разверните каждую ревизию в своем пространстве имен, например web-front-2142 , отметьте, перейдите к входу, затем удалите все остальные web-front - [\ d] Я все еще могу использовать двигатель шаблона руля, но без румпеля. Нет необходимости полагаться на ресурсы управления румпелем - пространство имен будет удалено после повышения производительности пространства имен.

Мне нужно создать отдельное пространство имен для входа, потому что это единичный ресурс, но это будет действительно простое пространство имен, что-то вроде web-front-ingress .

Плюсы: без снежинок, каждое развертывание было полностью создано из репо; если это работает - это работает; Никакой зависимости от предыдущих развертываний, если предыдущее развертывание было полностью скрыто, это не имеет значения.

Минусы: отдельное пространство имен для отдельных ресурсов, таких как вход; кажется, не так, как K8S был разработан и может привести к непредвиденным последствиям; все инструменты развертывания, включая spinnaker, вращаются вокруг одного пространства имен.

---

Нужен совет и лучшие практики! :)

Answer 1

Итак, в основном я с тех пор остановился на ответе - единичные пространства имен - это путь. Главным образом из-за особых ресурсов, таких как PVC, которые не могут быть разделены между пространствами имен.

Но главное прозрение заключается в том, что вам не нужно использовать румпель! Вы все еще можете использовать шаблоны руля, и все, что вам нужно, - это ярлыки K8S! Например, я использую Дженкинс как строитель и версионер Он устанавливает метки, такие как managed_by: jenkins и version: <build_number>, поэтому все, что мне нужно сделать при развертывании, - это найти все ресурсы с такой же name и версией ниже текущей и исправить их, а затем добавить новые ресурсы и удалить все ресурсы managed_by: jenkins, которых больше нет (по их name). Я построил простой случай этого, и он, кажется, работает просто отлично.

Answer 2

Официальная документация упоминает следующее:

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

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

* * * * * * Пространства имен Kubernetes: примеры использования и понимание " В статье рассказывается о лучших подходах с использованием пространств имен. Не рекомендуется использовать разные пространства имен для версий программного обеспечения:

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

Другие ресурсы (например, GCPB ) описывают использование пространств имен в основном для разделения объектов Kubernetes для различных этапов, команд, проектов, клиентов.
Таким образом, вы можете предположить, что использование отдельных пространств имен для сине-зеленых развертываний или развертывания канареек не очень распространенный подход.