🦀 1,8 млн ошибок из-за одного пробела: как разработчик собирал…
🦀 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
Автор 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