Не трогайте лучше fsync, идея плохая. Может возникнуть мысля мол “потеряю немного, как при откате к бэкапу”, но это вообще не так. Если щелкнет свет, а все три ноды словят рассинхрон одновременно придётся сносить кластер и поднимать заново. Это хуже чем бэкап. Я бы проверила точно ли дело в диске, может гадит какой-то из процессов (частый виновник в домашних кластерах эт какой нибудь Traefik/cert-manager со своим статус-чурном). Можно погонять fio с fdatasync на директорию etcd и посмотреть p99, он если укладывается в 10ms то тормозят не диск, а может логи от конкуренции с подами за очередь. Стоит еще глянуть есть ли у дисков PLP (nvme id-ctrl флаг VWC). Если нет то у диска нет полной гарантии durability, еще один повод не трогать fsync руками. Как вариант подкрутить heartbeat-interval и election-timeout, может уменьшить лишние перевыборы лидера из логов без всякого риска. Прежде чем тюнить дальше не лишним будет посмотреть кто вообще генерит основную запись, иногда там режется большая часть нагрузки одной правкой конфига.
А что произойдёт с RPC вызовом, если сервер упал или сеть отвалилась прямо во время выполнения запроса? Клиент поймёт, выполнен ли запрос, и может ли RPC автоматически ретраить его?
Манагед кубы снимают с тебя ответственность за диски, в этом их плюс. Если смотреть универсально - единственное что торчит наружу из control plane это сам apiserver, он же точка входа для kubectl. Придется навешивать Prometheus. Можно скрапить обычный /metrics apiserver и он сам скажет сколько времени у него ушло на каждый поход в etcd (etcd_request_duration_seconds). Если она растёт именно на записи, но на чтении всё ровно, можно сделать предположение что под etcd тупит именно диск. Может послужить косвенным сигналом о здоровье етсд. еще есть счётчик объектов по каждому ресурсу. Если он только растёт и не падает, значит где-то плодятся кривые объекты. etcd может упереться в квоту и присесть в read-only. Больше ничего облако не покажет, только эти два сигнала через apiserver могут послужить маячками. Даже если etcd там крякнет остается только идти с тикетом в поддержку облака
Информация
В рейтинге
365-я
Откуда
Тюмень, Тюменская обл. и Ханты-Мансийский АО, Россия
Не трогайте лучше fsync, идея плохая. Может возникнуть мысля мол “потеряю немного, как при откате к бэкапу”, но это вообще не так. Если щелкнет свет, а все три ноды словят рассинхрон одновременно придётся сносить кластер и поднимать заново. Это хуже чем бэкап. Я бы проверила точно ли дело в диске, может гадит какой-то из процессов (частый виновник в домашних кластерах эт какой нибудь Traefik/cert-manager со своим статус-чурном). Можно погонять fio с fdatasync на директорию etcd и посмотреть p99, он если укладывается в 10ms то тормозят не диск, а может логи от конкуренции с подами за очередь. Стоит еще глянуть есть ли у дисков PLP (nvme id-ctrl флаг VWC). Если нет то у диска нет полной гарантии durability, еще один повод не трогать fsync руками. Как вариант подкрутить heartbeat-interval и election-timeout, может уменьшить лишние перевыборы лидера из логов без всякого риска. Прежде чем тюнить дальше не лишним будет посмотреть кто вообще генерит основную запись, иногда там режется большая часть нагрузки одной правкой конфига.
спасибо! обязательно дополню статью!
А что произойдёт с RPC вызовом, если сервер упал или сеть отвалилась прямо во время выполнения запроса? Клиент поймёт, выполнен ли запрос, и может ли RPC автоматически ретраить его?
Манагед кубы снимают с тебя ответственность за диски, в этом их плюс. Если смотреть универсально - единственное что торчит наружу из control plane это сам apiserver, он же точка входа для kubectl. Придется навешивать Prometheus. Можно скрапить обычный /metrics apiserver и он сам скажет сколько времени у него ушло на каждый поход в etcd (etcd_request_duration_seconds). Если она растёт именно на записи, но на чтении всё ровно, можно сделать предположение что под etcd тупит именно диск. Может послужить косвенным сигналом о здоровье етсд. еще есть счётчик объектов по каждому ресурсу. Если он только растёт и не падает, значит где-то плодятся кривые объекты. etcd может упереться в квоту и присесть в read-only. Больше ничего облако не покажет, только эти два сигнала через apiserver могут послужить маячками. Даже если etcd там крякнет остается только идти с тикетом в поддержку облака