Блог

У меня есть кластер kubernetes, созданный и развернутый с помощью приложения.

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

Если у меня есть два узла в кластере, а затем выполните другое развертывание с помощью secondapp.yaml.

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

Это то, что предоставляется kubernetes. Как ит-отдел будет управлять развертываниями, выполненными с использованием разных файлов? всегда ли они будут использоваться на отдельных узлах (если есть подготовленные узлы)?

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

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

Что касается вашего последнего вопроса — в нем нет никакого смысла. Вы можете использовать namespacesnetwork policies для разделения сред, вам все равно, на каких узлах находятся ваши модули. В этом весь смысл наличия кластера.

Вы можете использовать ограничения размещения для достижения того, что вы просите, но это не имеет никакого смысла.

https://kubernetes.io/docs/concepts/configuration/assign-pod-node/

Согласен с @4c74356b41. В качестве дополнения. Не имеет значения, где находятся ваши модули, у вас может быть несколько копий вашего приложения, разделенных, скажем, между 50 узлами, они все равно могут взаимодействовать друг с другом (службы, обнаружение служб, сетевой CNI) и совместно использовать ресурсы и т. Д.

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

Опять же, как упоминает @4c74356b41, если вы хотите разделить свой кластер на несколько сред, скажем, для разных команд или, как вы упомянули, для сред разработки и контроля качества, вы можете использовать для этого пространства имен. Они в основном создают меньшие кластеры в вашем кластере (обратите внимание, что это скорее логическое разделение, а не разделение с точки зрения безопасности, пока вы не добавите другие компоненты, например, роли) Вы можете просто добавить namespace поле в свой YAML развертывания, чтобы указать, в какое пространство имен вы хотите развернуть свои модули — по-прежнему не имеет значения, на каких узлах они находятся. В зависимости от вашего варианта использования.

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