Как я перестал гадать, какая пара нод сломалась после апдейта CNI, и написал для этого свой мониторинг

[Xelld]

Выглядит интересно, спасибо.

Собирал аналогичный инструмент, только не для kubernetes, а вообще для мониторинга intra/inter DC трафика.

Как идея вам - добавьте возможность подключать внешние агенты (без kubernetes).

И вопросы напрашиваются:

• Вы всегда полный mesh собираете, или все же как-то оптимизируете набор пиров для проверки?

• На каком количестве нод это сейчас работает?

• Как поведет себя на 100/1000/5000?

[esdmitrii]

Спасибо за комментарий. По пунктам.

Внешние агенты.
Тут приятная новость: в целом, архитектурно это ближе, чем кажется. Так как агент не ходит в API Kubernetes вообще, в коде нет ни одного импорта client-go и имя ноды он получает обычной переменной окружения через downward API, то есть для него это просто строка идентификатор, то зону можно задать явно в конфиге, и тогда контроллер не пытается резолвить её из объекта Node и регистрация проходит без всякой ноды. Фактически агент это самодостаточный бинарь, который знает адрес контроллера, своё имя и свою зону.
И исходя из этой мысли, то, чего не хватает по-настоящему двух вещей:
Первое: упаковка, сейчас единственный способ доставки это DaemonSet, нужен нормальный бинарь с systemd-юнитом.
Второе: gRPC между агентом и контроллером сейчас plaintext, потому что внутри кластера он закрыт NetworkPolicy и этого достаточно. Как только агент уезжает за пределы кластера, регистрация должна получить mTLS и авторизацию, иначе кто угодно, кто дотянулся до порта, объявляет себя нодой и попадает в меш.

Полный меш или нет.
Постоянные проверки между агентами - полный меш, N×(N−1) направленных пар, без сэмплинга. Это сознательно: смысл инструмента ровно в парной асимметрии, когда одна пара нод деградировала, а остальные в порядке, и любое прореживание графа теряет именно её. Проверять несколько случайных пиров это уже другой инструмент, он отвечает на вопрос «сеть жива?», а не «между какими двумя нодами сломалось».
Оптимизация выбора источников есть, но в другом месте, в разовых и запланированных проверках из консоли: sourceSelection: all | per-zone | one-per-zone. Там источники можно ограничить одним агентом на зону, и тогда объём растёт по числу зон, а не нод.

Про масштаб.
Реально гонял на кластерах до 50–100 нод, работает, ничего экзотического делать не пришлось. Дальше начинается место, где надо считать, и считать надо не зонды, а серии.
На направленную пару приходится около 70 активных временных рядов: четыре гистограммы (TCP connect, TCP total, UDP RTT, ICMP RTT) по 13 бакетов плюс +Inf, sum, count, три гейджа потерь и джиттера и три счётчика результатов.На сотне нод это 9 900 пар, то есть порядка 700 тысяч активных серий и около 6 тысяч зондов в секунду по кластеру, примерно 60 на агента.
Prometheus под это стоит посчитать заранее, а не ставить как «ну ещё один экспортер», но это обычная эксплуатация, а не героизм.
Тысяча и выше - честно: не тестировал и негде. Дальше только арифметика модели. Тысяча нод это уже 999 тысяч пар, порядка 70 миллионов серий и ~600 зондов в секунду с каждого агента; пять тысяч - 25 миллионов пар, тут обсуждать нечего.
Важно, что рост квадратичный и упирается всё в кардинальность TSDB, а не в CPU агентов или в сеть, они сдадутся заметно позже.

Что тут напрашивается, если однажды понадобится: развести две плоскости наблюдения. Постоянно и для всех - агрегат зона <--> зона, где кардинальность растёт по числу зон, то есть остаётся маленькой. Плюс разреженный граф между нодами: каждый агент проверяет не всех, а фиксированное число пиров, выбранных детерминированно так, чтобы граф оставался связным и покрывал все межзонные направления. А полный per-pair меш, не как фон, а как режим расследования: включается точечно, на конкретное подмножество нод, когда агрегат уже показал, что где-то плохо. Ровно тот путь, которым сейчас идут MTR и разовые проверки.