Самостоятельная повторная подготовка кластера S3 без простоя

Моя цель

В настоящее время я экспериментирую с K8s дома в своей домашней лаборатории. Я работаю над созданием некоторого IaC с Terraform для предоставления кластера K8s APPS, состоящего из узлов Fedora CoreOS.

Я подумал, что хороший план для полной автоматизации инициализации узла K8S будет заключаться в следующем:

  1. Позвольте Terraform сгенерировать сценарий CoreOS Ignition для конфигурации предоставления ОС.
  2. Используйте Terraform, чтобы прикрепить мой файл Ignition к моей пользовательской сборке ISO Fedora CoreOS (созданной с использованием CoreOS Assembler).
  3. Загрузите ISO в локальное хранилище объектов, используя min.io (вероятно, используя Terraform).
  4. Подготовьте каждый узел с помощью Terraform, используя URL-адрес ISO.
  5. Пусть установка ОС произойдет с помощью Ignition.
  6. Дальнейшая настройка после подготовки выполняется с помощью Ansible.
  7. Подготовка кластера APPS завершена.

Кластер APPS будет использоваться для запуска всех моих контейнеров, таких как Jellyfin & co.

Как избежать создания избыточных кластеров s3?

Насколько я понимаю, для оптимального решения min.io (s3) должен быть не в кластере APPS, а в другом кластере K8s. Так что, если мне нужно снова подготовить кластер APPS, я могу без проблем уничтожить все узлы.

Если оба кластера являются основной ОС Fedora, как мне избежать создания второго кластера s3 только для хранения ISO, когда мне нужно повторно выделить мой первый кластер s3?

Дополнительные примечания

  • Пожалуйста, не стесняйтесь выделять все, что может показаться вам неправильным.
Развертывание модели машинного обучения с помощью Flask - Angular в Kubernetes
Развертывание модели машинного обучения с помощью Flask - Angular в Kubernetes
Kubernetes - это портативная, расширяемая платформа с открытым исходным кодом для управления контейнерными рабочими нагрузками и сервисами, которая...
1
0
55
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Ваша цель звучит хорошо. Немного похоже на загрузку OpenShift 4 в наши дни. Теперь, где запустить MinIO — хороший вопрос.

Не зная, как вы используете s3, помимо загрузки этих виртуальных машин, а также того, какой гипервизор/какие поставщики терраформ используются, я оставлю его общим:

1/ Первый вопрос: нужен ли вам MinIO?

Загружая свой кластер Kubernetes из MinIO, вы сталкиваетесь с проблемой курицы и яйца. Извлечение ваших исходных изображений и файлов зажигания, как минимум, будет какой-то HTTP-сервер.

1.1/ MinIO, используемый другими сервисами, не относящимися к Kubernetes

Предполагая, что MinIO каким-то образом требуется для других вещей, связанных с «голым металлом»: учитывая, что требуется начальная загрузка Kubernetes, я бы рассмотрел возможность размещения MinIO в качестве приложения «голого железа» (или с использованием старой доброй виртуализации) вне Kubernetes.

На пути к этому я мог бы даже рассмотреть вариант альтернатив MinIO, таких как Ceph: предложение как с объектным, так и с блочным хранилищем могло бы быть полезным при настройке PVC с динамическим выделением ресурсов. (предупреждение: минимальный кластер Ceph обычно больше, чем минимальная конфигурация MinIO, но если вы собираетесь отказаться от одного из ваших кластеров k8s, возможно, это имеет смысл, ...)

1.2/ Старайтесь не полагаться на MinIO для загрузки кластера

Если нет причин для участия MinIO в начальной загрузке виртуальных машин, я бы просто обслуживал свои файлы ISO и зажигания с помощью какого-нибудь nginx, lighttpd или apache.

Легче поддерживать, воссоздавать, ... И вы можете настроить этот http-сервер на любом хосте, который генерирует ваши собственные ISO.

1.3/ MinIO требуется приложениям, размещенным в Kubernetes

Предполагая, что вы в основном используете MinIO со своим приложением: держите его в Kuberenetes.

Вам даже не нужен выделенный кластер Kubernetes: вы можете использовать nodeSelectors, taints, допуски и т. д., например, ваши модули MinIO будут работать на несколько выделенных рабочих процессах Kubernetes, а ваши приложения будут работать на «обычных» узлах.

Вы можете использовать отдельные пространства имен, настроить RBAC кластера, возможно, даже NetworkPolicies (при условии, что ваша SDN поддерживает это) ... таким образом, чтобы изолировать ваше хранилище от ваших рабочих нагрузок.

2/ Следующий вопрос: ДОЛЖНЫ ли вы повторно создавать узлы (кластеры?), повторно развертывая свое приложение?

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

Развертывание и повторное развертывание рабочих нагрузок в Kubernetes «не должно» требовать уничтожения и повторного создания ни самого кластера k8s, ни любого из его узлов.

Тем не менее: вы не должны бояться пересоздавать узлы. Рабочие одноразовые, если вы хотите их уничтожить, создайте новых, воссоединившись с вашим кластером: это имеет смысл. Работая в облаке (aws/azure/openstack/gce/...), мы обычно настраиваем автомасштабирование: они будут уничтожать экземпляры и создавать новые в соответствии с общим использованием ресурсов кластера. Увеличение и уменьшение масштаба ваших кластеров совершенно нормально.

Спасибо, вы прекрасно ответили на главный вопрос min.io и дали мне действительно хорошие предложения по общему подходу, который я использую. Я, вероятно, не буду использовать min.io для такого случая, может быть, это слишком много. 💯

Jac 12.02.2023 11:20

Другие вопросы по теме