Схема входящего траффика в кластер Kubernetes простая: web → Envoy Gateway → Ingress Nginx → backend. За Ingress Nginx, помимо обычного HTTP, живут долгоживущие WebSocket-соединения. Штатная нагрузка - около 100 RPS. Ничего экзотического.

В один прекрасный день всё в кластере легло. Клиенты получают 503/500. В логах Envoy - флаг UF и upstream_reset_before_response_started{connection_timeout}. То есть ingress-nginx просто перестал отвечать.

Дальше - два часа разбора и довольно красивая цепочка причин, которая началась с банального reload, а закончилась на том, как ядро считает лимит потоков при старте виртуалки.

В рамках этой статьи мы рассмотрим, как работает Garbage Collector в Kubernetes. Данная статья была написана, когда мне пришлось разбираться в производительности Garbage Collector, а чтобы понять как его можно ускорить, сначала надо понять, как он работает. Для точного понимания мы будем запускать Garbage Collector локально в дебаг режиме, чтобы максимально ясно видеть как он работает и что делает.

Недавно мной, совместно с коллегой, был реализован оператор для Kubernetes’a - Vector Operator. (Вот тут описано как мы пришли к решению, что там нужен свой оператор для Логирования в Kubernetes).

В рамках данной статьи я опишу разные интересные Задачи/Проблемы с которыми мы столкнулись в процессе разработки и как их решили.

В данной статье я расскажу про жизненный цикл одной важной задачи - “Настроить сбор/парсер логов в Kubernetes”. Или “Почему мы решили написать свой оператор для сбора логов в Kubernetes”.