Заранее спасибо всем, кто помогает.
Здравствуйте, у меня есть несколько уникальная проблема, ее довольно долго объяснять, но я думаю, что если она будет решена, мы сможем расширить варианты использования Kubernetes. Думаю, я знаю, как это решить, но не уверен, поддерживает ли Kubernetes Stateful Sets это решение. Позвольте мне подробнее рассказать о проблеме, самой проблеме, а затем о некоторых из моих примеров решений и, возможно, кто-то может помочь заполнить пробелы.
Доменное пространство:
- У меня есть набор учетных записей (внешних по отношению к kubernetes) {Account_A, Account_B, Account_C и т. Д.}
- Учетные записи могут быть активными или неактивными в любое время (Важно: НИ В КОНКРЕТНОМ ПОРЯДКЕ).
- Если эта функция активирована, развертывается модуль, который обслуживает эту учетную запись и хранит постоянный том со всеми этими учетными записями, рабочим пространством / данными. Эта учетная запись взаимодействует с ее уникальным идентификатором модуля и IP-адресом.
- Если этот параметр отключен, модуль удаляется, но данные сохраняются, так что в следующий раз, когда он будет активирован, он будет привязан к тому же требованию постоянного тома и, следовательно, получит доступ к своим предыдущим данным.
- При повторной активации модуль развертывается повторно, который использует предыдущее требование постоянного тома для возобновления работы с данными из предыдущих сеансов.
Очевидно, что, глядя на доступные инструменты / объекты Kubernetes, набор с отслеживанием состояния с headless-service - идеальный способ приблизиться к этому. Он поддерживает уникальные поды, которым назначаются уникальные IP-адреса, и поддерживает постоянные тома. Он также поддерживает динамическое предоставление постоянных томов через
Проблема:
Как упоминалось в домене, учетные записи могут быть активны в любом порядке, но модули с установленным состоянием являются порядковыми, то есть модуль pod_1 должен быть активен, чтобы модуль pod_2 был активен, чтобы модуль pod_3 был активен, и т. Д. Мы не можем иметь модули pod_1 active и pod_3. активен, пока pod_2 неактивен. Это означает, что если я включу Account_A, затем Account_C, будет создан модуль с именем pod_1, а затем будет создан модуль с именем pod_2.
Теперь вы можете сказать, что это не проблема. Мы просто храним карту, которая сопоставляет каждую учетную запись с относительным номером pod_number. Например, Account_A -> pod_1 и Account_C -> pod_2.
Почему это проблема? Поскольку при указании volumeClaimTemplate в наборе с отслеживанием состояния постоянные-тома-утверждения используют имя модуля в качестве идентификатора при создании. Это означает, что только модуль с таким же именем может получить доступ к одним и тем же данным. Данные (тома) привязываются на основе имени модуля, а не учетной записи. Это создает разрыв между учетными записями и их постоянными томами. Любой модуль с именем pod_2 всегда будет иметь те же данные, что и модуль pod_2, независимо от того, какая учетная запись была «сопоставлена» с модулем pod_2.
Позвольте мне проиллюстрировать это на примере:
1. Account_A=disabled, Account_B=disabled, Account_C=disabled (Start state, all accs disabled)
2. Account_A=enabled, Account_B=enabled, Account_C=enabled -> (All accounts are enabled)
pod_1 is created (with volume_1) and mapped to Account_A
pod_2 is created (with volume_2) and mapped to Account_B
pod_3 is created (with volume_3) and mapped to Account_C
3. Account_A=disabled, Account_B=disabled, Account_C=disabled (All Accounts are disabled)
pod_1 is deleted, volume_1 persists
pod_2 is deleted, volume_2 persists
pod_3 is deleted, volume_3 persists
4. Account_A=enabled, Account_B=disabled, Account_C=enabled (re-enable A and C but leave B disabled)
pod_1 is created (with volume_1) and mapped to Account_A (THIS IS FINE)
pod_2 is created (with **volume_2**) and mapped to Account_C (THIS IS **NOT** FINE)
Вы видите проблему? Account_C теперь использует хранилище данных, которое должно принадлежать Account_B (volume_2 был создан и использовался account_b, а не Account_C) из-за того, что тома / заявки сопоставляются по имени с именами модулей, а модули должны быть порядковыми, то есть pod_1 тогда pod_2.
Возможные решения
Уметь поддерживать настраиваемые не порядковые имена для модулей в наборе с отслеживанием состояния. (Самый простой и эффективный)
Это решает все и сохраняет преимущества и инструменты набора состояний. Я могу назвать свои модули так, как хочу, при запуске, так что, когда учетная запись включена, я просто запускаю модуль с этим именем учетной записи, а созданный том сопоставляется с любым модулем с тем же именем. Я искал и, кажется, не могу найти способ сделать это.
(p.s.) Я знаю, что наборы с отслеживанием состояния должны быть порядковыми для гарантии заказа, но вы можете отключить это с помощью "podManagementPolicy: Parallel"
Какой способ сделать это с помощью меток и селекторов?
Я новичок в Kubernetes и до сих пор не совсем понимаю все движущиеся части. Может быть, есть способ использовать метки в моем шаблоне volumeClaimtemplate, чтобы требования тома прикреплялись к томам с определенной меткой. то есть Account_C, сопоставленный с pod_2, может запрашивать volume_3, потому что volume_3 имеет метку с: account = Account_C. Я сейчас занимаюсь этим. Если это помогает, мои постоянные тома предоставляются динамически с помощью этого инструмента: https://github.com/kubernetes-incubator/external-storage/tree/master/nfs-client Может быть, я могу как-то изменить его, чтобы он добавлял определенные метки к создаваемым постоянным томам.
Откажитесь от наборов состояний и развертываний и просто добавьте модули вручную в кластер
Это не лучшее решение, поскольку, согласно документации, поды не должны существовать без набора состояний или развертывания в качестве родительского, а также удаляют все встроенные функции постоянных томов и динамического выделения томов и т. Д. Для меня dealbreaker не имеет volumeClaimTemplates, которые создают или привязываются к существующему volumeClaim при развертывании. Если бы я мог как-то воссоздать это, это решение сработало бы.
Создайте собственный объект Kubernetes, чтобы сделать это за меня
Это неидеально, поскольку потребовалось бы много работы, и я даже не знал бы, с чего начать. Я бы также воссоздал то же самое, что и набор с отслеживанием состояния, за исключением того, что без порядкового сопоставления. Мне нужно было бы выяснить, как записывать операторы, наборы реплик и т. Д. Похоже, что это излишество для довольно простой проблемы.
- Установите постоянное хранилище из контейнера пода. Это последнее средство, поскольку оно полностью устраняет необходимость в кубернетах. Это также означает, что я должен отправить информацию о подключении в контейнер внутри модуля и открыть там целую банку червей с безопасностью и аутентификацией.
Я буду обновлять все, что найду или придумаю. Спасибо всем, кто помогает.
