Как стать автором
Обновить

Комментарии 10

Судя по описанию проблему, вы спокойно можете воспроизвести ее:


  • Запустить в кластере под с dnsperf: https://github.com/guessi/docker-dnsperf (или любым другим подобным ПО)
  • Скейлить coredns/kube-dns в кластере вверх и вниз
  • Смотреть логи kube-proxy
  • Смотреть состояние conntrack: conntrack -L на машинах фильтруя по адресам подов dns и dnsperf

Данный способ будет корректным, так как в conntrack будет минимальное количество записей связанных с данным подов dnsperf'а, так как src и sport будет один и тот же, при этом в качестве dst будут поды dns.


Ну и на тестовом сетапе вы сможете разобраться более глубоко в проблеме и решить первопричину.


Тут в диагностике не сильно поможет какой-нибудь while true; do host test.com <DNS_POD_IP>, так как в этом случае с большой вероятностью наплодится большое количество записей в conntrack и отдебажить будет куда сложнее.

Интересует, что дальше было сделано с этим протоколом пост-мортема
Все посмтортемы у нас хранятся в Confluence, ну и как написано в статье, обсуждаются на еженедельных митингах.
Ну т.е. пользы почти никакой нет. Выглядит, что где-то увидели, что надо писать протоколы, и написали.
Конкретно для нас польза такая.
1. Инцидент зафиксирован и донесен до всех членов команды, в будущем такого повториться не должно
2. Если даже вдруг он в будущем повторится, у нас зафиксированно все в документации
3. Плюс это расширение экспертизы (опыт) для других членов команды, которые работают со смежной технологией например
НЛО прилетело и опубликовало эту надпись здесь
А какую версию ядра используете?
$ uname -v
#1 SMP Debian 4.9.189-3+deb9u2 (2019-11-11)
$ conntrack --version
conntrack v1.4.4 (conntrack-tools)
1.13, не IPVS
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории