Допустим, после отказа зоны под с постоянным томом не запускается в другой зоне. Как ограничение доступности тома влияет на решение оркестратора?
Оркестратор не размещает под в другой зоне, если постоянный том доступен только в исходной зоне. Планировщик учитывает топологические ограничения тома и отфильтровывает несовместимые узлы, поэтому под может остаться в состоянии Pending даже при наличии свободных CPU и памяти.
Перенос возможен только через хранилище, поддерживающее межзонный доступ или репликацию, либо через восстановление данных в новом томе другой зоны.
Облачные блочные хранилища часто создавались с привязкой к зоне доступности. Такая модель уменьшает сетевые задержки, упрощает реализацию хранилища и снижает стоимость межзонного трафика, но делает размещение вычислений зависимым от топологии диска.
Оркестраторам пришлось учитывать эту зависимость явно. Иначе планировщик мог бы разместить под на подходящем по ресурсам узле, после чего система не смогла бы подключить к нему том.
У пода есть требование подключить постоянный том, а сам том может быть смонтирован только на узлах определённой зоны. После отказа этой зоны узлы в других зонах остаются доступными, но подключение тома к ним невозможно.
Если игнорировать ограничение, под будет бесконечно перезапускаться или застрянет на этапе подключения тома. Если бездумно создать новый пустой том, приложение может запуститься, но потеряет данные или увидит неполное состояние.
При планировании Kubernetes учитываются сведения о топологии PersistentVolume, обычно выраженные через ограничения узлов, связанные с зоной или регионом. Планировщик оставляет только те узлы, на которых под одновременно может быть размещён и где его том потенциально может быть подключён.
Для заранее созданного зонального тома это означает фактическую привязку пода к совместимой зоне. Если подходящих узлов нет, под остаётся в состоянии Pending; наличие свободных ресурсов на несовместимых узлах ситуацию не меняет.
При динамическом создании тома важен режим ожидания до выбора потребителя, известный как WaitForFirstConsumer. Сначала учитываются требования пода и доступная топология, затем том создаётся в совместимой зоне. Это предотвращает создание диска в зоне, где под впоследствии не сможет работать.
После выбора узла отдельные компоненты CSI отвечают за подключение и монтирование тома. Успешное планирование не гарантирует успешного attach: могут возникнуть проблемы с квотами, лимитом подключений, состоянием узла или самим провайдером хранения.
Для отказоустойчивости применяют разные подходы. Реплицируемое межзонное хранилище уменьшает зависимость от одной зоны, но обычно имеет более высокую стоимость и может добавлять задержку. Восстановление тома из резервной копии или снимка в другой зоне дешевле, но создаёт простой и риск потери последних изменений. Репликация на уровне приложения даёт больший контроль, однако требует корректной реализации согласованности и процедуры переключения.
Распределение реплик по зонам само по себе не решает проблему: каждая реплика может всё равно зависеть от собственного зонального тома. Нужно проверить совместимость стратегии хранения, политики размещения и процедуры восстановления.
Stateful-сервис использовал по одному зональному тому на реплику. После недоступности зоны новые узлы в других зонах были здоровы, но поды оставались Pending из-за топологического ограничения томов.
Рассматривались три варианта. Ожидание восстановления зоны не требовало миграции данных, но сохраняло длительный простой. Восстановление из снимка в другой зоне ускоряло запуск, однако допускало потерю изменений после последней точки резервирования. Переход на межзонное реплицируемое хранилище уменьшал простой, но требовал дополнительных расходов и проверки производительности.
Выбрали репликацию данных между зонами на уровне самого сервиса, а резервные копии оставили как средство аварийного восстановления. При отказе зоны реплика переключалась на актуальный экземпляр в другой зоне, а зональные тома использовались только как локальное хранилище отдельных реплик. Это устранило зависимость доступности сервиса от одного тома, но потребовало тестировать переключение и восстановление после потери узла.
Дополнительный вопрос 1: Чем отличаются ограничения планировщика от ошибки подключения тома после размещения пода?
Ограничение планировщика предотвращает выбор несовместимого узла ещё до запуска пода. Ошибка подключения возникает позже, когда контроллеры пытаются выполнить attach и mount уже выбранного тома. Поэтому состояние Pending с сообщением о несовместимой топологии и ошибка монтирования имеют разные причины и требуют разной диагностики.
Дополнительный вопрос 2: Зачем нужен режим WaitForFirstConsumer при динамическом создании тома?
Без ожидания том может быть создан заранее в произвольной зоне, после чего требования пода окажутся с ним несовместимы. WaitForFirstConsumer откладывает создание до момента, когда планировщик сможет учесть зону, требования размещения и доступные узлы. Это не делает хранилище отказоустойчивым, а только предотвращает ошибочный первоначальный выбор топологии.
Дополнительный вопрос 3: Решит ли распределение реплик по зонам проблему отказа зонального тома?
Нет, если каждая реплика использует собственный том, доступный только в своей зоне, распределение помогает лишь при условии, что хотя бы одна реплика и её данные остаются доступными. Для автоматического восстановления в другой зоне нужны межзонная репликация, переносимые данные или заранее проверенная процедура восстановления. Правило размещения реплик не копирует содержимое томов и не меняет их топологические ограничения.