Автор 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