Чому StatefulSets? Чи не може апарат без громадянства використовувати постійні томи?

Я намагаюся зрозуміти Stateful Sets . Чим їх використання відрізняється від використання стручків "без громадянства" з постійними обсягами? Тобто, якщо припустити, що "звичайний" Pod може претендувати на постійне сховище, що я очевидно втрачаю, що вимагає цієї нової конструкції (із впорядкованим запуском / зупинкою тощо)?

Так, звичайний стручок може використовувати постійний обсяг. Однак іноді у вас є кілька стручків, які логічно утворюють "групу". Прикладами цього можуть бути репліки баз даних, хости ZooKeeper, вузли Kafka тощо. У всіх цих випадках є купа серверів, які працюють разом і спілкуються між собою. Особливим у них є те, що кожна людина в групі має свою особистість. Наприклад, для кластера баз даних один є ведучим, а два - послідовниками, і кожен з послідовників спілкується з ведучим, повідомляючи йому, що він має, а не синхронізував. Отже, послідовники знають, що "db-x-0" є ведучим, і майстер знає, що "db-x-2" є послідовником і має всі дані до певної точки, але все ще потребує даних поза цим.

У таких ситуаціях вам потрібно кілька речей, які ви не можете легко отримати зі звичайного стручка:

1. Передбачувана назва: ви хочете, щоб ваші стручки казали їм, де знайти один одного, щоб вони могли сформувати групу, обрати лідера тощо, але для цього вам потрібно знати їх імена заздалегідь. Звичайні назви стручків випадкові, тому ви не можете їх знати заздалегідь.
2. Стабільна адреса / ім'я DNS: ви хочете, щоб будь-які імена, доступні на кроці (1), залишалися незмінними. Якщо звичайний pod перезапуститься (ви передислокуєте, хост, на якому він працював, вмирає тощо) на іншому хості, він отримає нове ім'я та нову IP-адресу.
3. Постійний зв’язок між особою в групі та її постійним томом: якщо хост, на якому працював один із майстрів бази даних, помре, він переміститься на новий хост, але повинен підключитися до того самого постійного тому, що є один і лише 1 том що містить правильні дані для цієї "особи". Так, наприклад, якщо ви передислокуєте свою групу з 3 хостів бази даних, ви хочете, щоб одна і та ж особа (за іменем DNS та IP-адресою) отримала однаковий постійний том, тому майстер все ще є ведучим і все ще має ті самі дані, replica1 отримує це дані тощо.

StatefulSets вирішують ці проблеми, оскільки вони забезпечують (цитування з https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/ ):

1. Стабільні, унікальні ідентифікатори мережі.
2. Стабільне, постійне зберігання.
3. Впорядковане, витончене розгортання та масштабування.
4. Замовлене, витончене видалення та припинення дії.

Я насправді не говорив про (3) та (4), але це також може допомогти кластерам, оскільки ви можете сказати першому, який розгортається, щоб стати майстром, а наступному знайти першого та розглядати його як майстра тощо.

Як деякі вже відзначали, ви можете дійсно можуть деяку з тих же переваг з використанням регулярних стручків і послуг, але його набагато більше роботи. Наприклад, якщо ви хочете 3 екземпляри бази даних, ви можете вручну створити 3 розгортання та 3 служби. Зверніть увагу, що ви повинні вручну створити 3 розгортання, оскільки ви не можете мати точку обслуговування до одного стручка в розгортанні. Потім, щоб збільшити масштаб, ви повинні вручну створити інше розгортання та іншу службу. Це працює і було дещо звичною практикою до появи програми PetSet / PersistentSet. Зверніть увагу, що в ньому відсутні деякі переваги, перераховані вище (наприклад, постійне відображення томів та фіксований порядок запуску).