Rejecting Invalid Ingress Routes at Apply Time
How Zalando used Skipper as a validating admission webhook to reject invalid filters and predicates at apply time, and what it took to make that safe on the Kubernetes control plane path.

Skipper is an open-source HTTP router and reverse proxy that can also run as a
Kubernetes ingress controller. At Zalando, it is the component that turns Ingress and RouteGroup configuration into
live routing behavior. Its routing model is powerful because requests can be matched by predicates, transformed by
filters, and then forwarded to backends.
The downside is that Kubernetes has no understanding of Skipper-specific filters and predicates, and therefore cannot validate them through standard Admission Control. For example, a route might reference a non-existing predicate, use a filter with invalid parameters, or define a backend that cannot be parsed. Kubernetes accepts this configuration because it is syntactically valid, but from Skipper’s perspective, the route is broken.
At Zalando scale, these invalid routes are critical. We run Skipper across 250+ Kubernetes clusters, with 15k+ ingresses, ~200k routes, and 500k-2M RPS. At that size, even 1% invalid routes is not background noise. It is real production risk.
The goal was simple: reject invalid Skipper routing configuration during kubectl apply.
خواندن Zalando Engineering با پرو
این منبع جزو کتابخانه پرو است. همه منابع ویژه، ترجمه هوشمند و فیدهای شخصی را باز کنید.
منتشرشده در
Zalando Engineering
ادامه مطالعه





