Kubernetes 1.17 GA: CSI стабилен - мигрируем in-tree volume plugins на CSI-драйверы

9 декабря вышел Kubernetes 1.17 GA. Мы ждали этого релиза с особым интересом - не из-за количества фич, а из-за одной конкретной: CSI (Container Storage Interface) переходит в статус stable. Не beta, не "production-ready with caveats" - полноценный stable. Для нас это прямое указание к действию: пора наконец разобраться с in-tree volume plugins и начать планомерный переезд.

Остановимся на том, что реально влияет на нашу managed-инфраструктуру.

Что такое in-tree plugins и почему это проблема

Kubernetes исторически включал код для работы с хранилищами прямо в основной репозиторий - рядом с кодом самого k8s. kubernetes.io/aws-ebs, kubernetes.io/gce-pd, kubernetes.io/cinder, kubernetes.io/vsphere-volume и ещё с десяток. Это значит, что баг в логике AWS EBS или добавление новой фичи для vSphere требует патча в core Kubernetes и ожидания следующего релиза.

С одной стороны, привычно и работает. С другой - это архитектурная проблема, которую сообщество Kubernetes решает уже несколько лет через миграцию на CSI. CSI - внешний интерфейс: storage-провайдер пишет свой CSI-драйвер, он живёт отдельно от k8s, обновляется независимо. Kubernetes только вызывает стандартные операции через gRPC.

Теперь CSI stable - и это меняет приоритеты.

Что нового в 1.17 по CSI

Конкретно в 1.17 CSI-фичи дошли до stable:

• CSI Migration framework - инфраструктура для прозрачной замены in-tree plugins на CSI-драйверы. При включении feature gate CSIMigration Kubernetes начинает прозрачно перенаправлять запросы к kubernetes.io/aws-ebs в CSI-драйвер ebs.csi.aws.com - без изменения существующих PV и манифестов. Флаги пока alpha для конкретных провайдеров, но сама инфраструктура stable.
• Volume Snapshot перешёл в beta - мы про это уже писали в ноябре, когда смотрели release notes до официального GA.
• Topology-aware volume scheduling - тоже stable.

Дополнительно: TLS bootstrapping для kubelet перешёл в GA. Это важно для автоматизации добавления нод - теперь механизм официально стабилен.

Наша ситуация с in-tree plugins

На кластерах, которые мы обслуживаем, живут PV разного возраста. Самые старые создавались два-три года назад, когда CSI ещё не было в принципе - только in-tree. За это время часть хранилищ переехала, часть нет, часть вообще сменила платформу.

Картина примерно такая:

• vSphere volumes - большой кусок on-premise инфраструктуры. In-tree plugin vsphere-volume жив и работает, но CSI-драйвер для vSphere уже есть (csi.vsphere.volume). Задача: понять, что сейчас на prod и когда реально мигрировать.
• Ceph RBD через in-tree - отдельная история. In-tree kubernetes.io/rbd работает через Ceph клиент, встроенный в kubeadm-образы. CSI-вариант через rbd.csi.ceph.com требует отдельного DaemonSet с ceph-csi. Зато потом обновление драйвера - независимо от версии k8s.
• Локальные тома - тут in-tree local тоже имеет CSI-эквивалент, но приоритет низкий.

Зачем мигрировать сейчас, а не потом

Есть прагматичный ответ: in-tree plugins в будущих версиях Kubernetes планируется удалить. Конкретных дат нет, но KEP (Kubernetes Enhancement Proposal) уже принят, code freeze для in-tree plugins уже де-факто работает - новые фичи идут только в CSI-драйверы. Чем дольше ждать, тем больше будет кластеров с in-tree PV, которые придётся мигрировать под давлением deadline.

Второй ответ: CSI-драйверы реально удобнее. Volume Snapshot, который мы тестировали в ноябре, работает только через CSI. Topology awareness - через CSI. Расширение тома без рестарта пода - через CSI. In-tree plugins эти фичи не поддерживают и не получат.

Как выглядит план миграции

Мы не переезжаем всё разом. Схема, которую мы закладываем:

Первый шаг - инвентаризация. Пройтись по всем кластерам, собрать список PV с in-tree provisioner. kubectl get pv -o json | jq '.items[].spec.storageClassName' в связке с анализом StorageClass - это быстро делается скриптом, но результат надо смотреть глазами, потому что часть StorageClass может называться одинаково на разных кластерах, а provisioner за ними разный.

Второй шаг - CSI-драйверы в dev. Поднять CSI-драйверы рядом с in-tree, создать новые StorageClass с CSI provisioner, протестировать create/mount/expand/snapshot на dev-нагрузках. Без удаления старого.

Третий шаг - новые PVC только через CSI. После прохождения dev - переключить StorageClass по умолчанию на CSI provisioner. Новые заявки идут через CSI, старые PV остаются на in-tree до плановой замены.

Четвёртый шаг - миграция существующих PV. Самый медленный. Для каждого PV нужно либо дождаться переезда нагрузки, либо делать live-migration через снимок + восстановление. Здесь Volume Snapshot beta в 1.17 пригодится напрямую.

Что мы уже сделали

Пока только первый шаг - инвентаризация на части кластеров. Результат ожидаемый: старых in-tree PV больше, чем хотелось бы. Новые кластеры, которые мы поднимали в этом году, уже частично на CSI - для Ceph RBD мы переходили на rbd.csi.ceph.com в августе после выхода Ceph Nautilus и нормального CSI-драйвера от Ceph. Там вопрос закрыт.

Проблема - legacy. Кластеры 2017-2018 года с vSphere-хранилищами и старыми PV - вот где работа. До конца декабря хотим закрыть хотя бы инвентаризацию по всем кластерам и поднять CSI-драйверы на dev. Дальше - по ситуации.

Пока наблюдение такое: stable CSI в 1.17 - не просто строчка в changelog, а точка, после которой откладывать эту работу становится сложнее обосновать.