etcd для самых маленьких: гайд по хранилищу kubernetes

[ArtemDudich]

Отличный разбор, особенно про разнесение WAL и bbolt по разным дискам — это редко где так внятно объясняют. Вопрос: в managed-кубах (EKS/GKE/AKS) мы обычно не видим ни --wal-dir, ни метрик etcd напрямую. Есть ли у вас практики, как в таких условиях хотя бы косвенно ловить «диск не тянет fsync» — по apiserver-метрикам, request latency, чему-то ещё?

[metalw4rrior]

Манагед кубы снимают с тебя ответственность за диски, в этом их плюс. Если смотреть универсально - единственное что торчит наружу из control plane это сам apiserver, он же точка входа для kubectl. Придется навешивать Prometheus. Можно скрапить обычный /metrics apiserver и он сам скажет сколько времени у него ушло на каждый поход в etcd (etcd_request_duration_seconds). Если она растёт именно на записи, но на чтении всё ровно, можно сделать предположение что под etcd тупит именно диск. Может послужить косвенным сигналом о здоровье етсд. еще есть счётчик объектов по каждому ресурсу. Если он только растёт и не падает, значит где-то плодятся кривые объекты. etcd может упереться в квоту и присесть в read-only. Больше ничего облако не покажет, только эти два сигнала через apiserver могут послужить маячками. Даже если etcd там крякнет остается только идти с тикетом в поддержку облака

[makurus]

Какие еще best practice по etcd можно добавить:

• НИКОГДА не выполнять команду defrag одновременно на всех нодах etcd кластера. Это, гарантировано, на нагруженном кластере, приведет к отказу в обслуживании; да, скорее всего временно, но тем не менее, может стать триггером к более серьезным проблемам. Почему такое может случиться? Каждый раз перечислять все узлы кластера в аргументе --endpoints= для etcdctl контрпродуктивно, поэтому, как правило, используется env переменная ETCD_ENDPOINTS, где прописаны все участники кластера

• Если у вас etcd до версии v3.6.x может быть неожиданностью, что auto compaction mode работает не так как ожидается. В предыдущих версиях много неразберихи: в v3.2.x, например, параметр --auto-compaction-mode отсутствует, в v3.3/4/5.x разные дефолты для cli-флага --auto-compaction-mode и в функции NewConfig() при запуске через --config-file. С версии v3.6.x это все устранили

Можно еще для синтетики прогнать fio:

[global]
time_based=1
group_reporting=1
directory=/mnt/wal
loops=1
ramp_time=5s

[etcd]
ioengine=sync
fdatasync=1
direct=0
bs=2300
iodepth=1
rw=write
nrfiles=1000
filesize=64MiB
fallocate=truncate

Это близкое к тому как пишется WAL: etcd преаллоцирует 64MiB файл, последовательно в него пишет, после заполнения текущего открывает новый файл и так далее.

Тут есть нюанс: fio не умеет преаллоцировать файлы во время работы и после заполнения удалять их, поэтому все файлы нужно создать заранее.

Задавайте число файлов (nrfiles) достаточно большим, чтобы тест не завершился за считанные секунды на SSD/NVMe.

Длительность теста по времени (runtime=) нет смысла проводить, потому как после заполнения всех преаллоцированных файлов fio начнет писать в уже заполненные файлы, что провоцирует паттерн readModifyWrite и iops падают на порядок. У меня было так 250k -> 20k.

Block size (bs) не кратен 4k, чтобы было честно, так как etcd при записи в wal никакие границы блока не выравнивает и запись может быть любого размера (разве что ограничена --max-request-bytes).

Можно добавить fio сценарий для bbolt (он, кстати, совершенно другой), но основной паттерн для etcd, все таки WAL

[metalw4rrior]

спасибо! обязательно дополню статью!