Пост 🦀 1,8 млн ошибок из-за одного пробела: как разработчик собирал Kubernetes Ingress на Rust и Go

🦀 1,8 млн ошибок из-за одного пробела: как разработчик собирал Kubernetes Ingress на Rust и Go Автор Silex разделил систему на две части: • Go-контроллер наблюдает за Ingress и EndpointSlice, отслеживая маршруты и адреса бэкендов. • Rust-движок на Tokio принимает трафик и ищет маршруты в конкурентной таблице DashMap. Обработка запросов отделена от взаимодействия с Kubernetes API. Первый нагрузочный тест выглядел обнадёживающе только по счётчику соединений: движок принимал около 55 тысяч в секунду, но не отдавал успешных ответов. Причина оказалась в разборе конфигурации. Вместо JSON-парсера код искал точную подстроку: Ожидал: "host":"silex.local" Получил: "host": "silex.local" Допустимый в JSON пробел ломал поиск. Обработчик молча завершался и закрывал TCP-соединение. Итог: 1,8 млн ошибок чтения. После исправления автор сравнил Silex с NGINX Ingress: K3s, HTTP echo-бэкенд, wrk, 400 соединений, 4 потока, 30 секунд. Silex: 2536 запросов/с. NGINX: 2274. Разница: +11,5%. Но максимальная задержка у обоих была около двух секунд, таймауты тоже остались. У Silex их даже больше: 302 против 286. По объяснению автора, нагрузка упёрлась в Node.js-бэкенд. На момент статьи TLS-терминация, активные проверки бэкендов и Prometheus-метрики ещё были в планах. Самое ценное здесь: увидеть, как устроен небольшой ingress, где ломается взаимодействие компонентов и почему throughput нужно читать вместе с ошибками и задержками. https://dev.to/sysalchemist/how-i-built-a-custom-kubernetes-ingress-in-rustgo-that-outperforms-nginx-by-11-4iag @Golang_google