Привет, комьюнити! Прошу помощи у коллективного разума, сам что-то уже в

тупике, быть может чего-то не вижу в упор.

Дано.
Относительно большой кластер, 20к подов порождённых 20к стетфулсетов, 150 воркеров, 5 мастеров. На каждом из мастеров haproxy, бэкендами у которого выступают все http-эндпоинты kube-apiserver. Между мастерами плавающий айпишник, настроенный в keepalived.
Версия 1.17
Каждый под имеет pvc и соответствующий pv. PVC принадлежат двум разным storageclass'ам. Оба storageclass'а - rbd под ceph, но с разыми проижионерами, ceph.com/rbd и rbd.csi.ceph.com.

Проблема.
Вне зависимости от storageclass'а и провижионера, при создании нового стейтфулсета, соответствующий под зависает на монтировании тома. Логи пода и kube-controller-manager:
https://pastebin.com/gQURvatj

Т.е. как будто где-то внутри кластера для serviceaccount'а ноды не подтягиваются права на чтение тома (??).
Под может сам собой запуститься через некоторое время, провисев в ContainerCreating от 10 минут до часа.
Что интересно, ситуативно помогает рестарт kubelet на воркере, но не везде и не всегда. Больше похоже на какое-то шаманство с рандомом и переподключениями.

Что пробовал крутить:

haproxy:
Глупо, но:
Увеличивал лимит коннектов (но и так не упиралось).
Увеличивал таймауты.

kube-apiserver:
Увеличивал таймаут для кублета:
--kubelet-timeout=30s (вместо 5с)
Увеличивал лимит выполняемых запросов:
--max-mutating-requests-inflight=1500
--max-requests-inflight=2000

kube-controller-manager:
Количество одновременных синхронизаций serviceaccount'ов (самое потенциально близкое по смыслу, как мне кажется):
--concurrent-serviceaccount-token-syncs=25
Ну и лимиты запросов к api:
--kube-api-qps=200
--kube-api-burst=300

Короче говоря, странная какая-то проблема. Есть ощущение, что что-то упирается в какой-то лимит или таймаут, но я никак не пойму что и где.

Кипэлайв говно

Перемещает айпишник мастера и ладно :) Вообще, сейчас вроде бы как принято делать конфигурацию с прокси на каждом воркере, у которых бэкенд смотрит на мастеров, а кублет самой ноды смотрит на этот прокси. Но я не пробовал.

Это ты описал кубеспрей путь, в принципе, валидно, если нет балансировщика

Попробуй пересетапить, можешь даже, господи прости, спрей взять - проблема наверняка уйдёт

Да что-то стрёмно под продом пересетапливать это всё добро, тем более на спрей, тем более не разобравшись в проблеме. Может быть если мысли, хотя бы в какую сторону копать?

а логи csi агента на нодах смотрел? и kubelet?

попробуй, годная тема

csi агента для первого провижионера вообще нет, так что тут дело явно не в csi. В то же время в kubelet интересная штука: Apr 28 19:07:25 kworker-51 kubelet[13015]: E0428 19:07:25.459463 13015 reflector.go:156] object-"clients"/"xyz": Failed to list *v1.ConfigMap: configmaps "xyz" is forbidden: User "system:node:kworker-51" cannot list resource "configmaps" in API group "" in the namespace "clients": no relationship found between node "kworker-51" and this object Apr 28 19:07:25 kworker-51 kubelet[13015]: E0428 19:07:25.481334 13015 desired_state_of_world_populator.go:320] Error processing volume "rms-data" for pod "xyz-0_clients(eb32dff5-3fd9-4e50-90ea-899aaa3e8974)": error processing PVC clients/xyz-0: failed to fetch PVC from API server: persistentvolumeclaims "xyz-0" is forbidden: User "system:node:kworker-51" cannot get resource "persistentvolumeclaims" in API group "" in the namespace "clients": no relationship found between node "kworker-51" and this object

Спасибо. В принципе, да, неплохо было бы все вызовы апи не через одну дырку пихать, а через пять

Ого, интересно

Т.е. он явно не успевает как-то синхронизировать права на вольюмы - будь то configmap или pv, без разницы

Я если честно вообще не знал, что у kubelet есть права читать PVC. Думал этим всем CSI занимается, в том числе монтирует том на ноду

Здесь он не может даже configmap прочитать... Наткнулся на интересную статью, https://engineering.dollarshaveclub.com/kubernetes-fixing-delayed-service-endpoint-updates-fd4d0a31852c У автора долго синхронизировались эндпоинты. Кажется, что-то похожее, учитывая, что это в принципе всё сущности апи

Я бы начал с изучения кода, как том монтируется на ноду. В какой момент кубелету даются права на это. Ваще интересная тема