Gateway is Yolean's fifth generation gateway. It can:
- Use any Envoy config as template.
- Discover endpoints and scale workloads to/from zero.
- Authorize using ext_authz.
- Filter using ext_proc.
It's not dependent on a CRD or operator because at Yolean we run hundreds of gateways and we need to be able to manage major version changes with zero risk of disturbance to existing rollouts.
To see Gateway in action with a test setup, run:
kubectl -n g5y-example apply -k github.com/yolean/g5y/examples/noauth/?ref=mainWe run Gateway as a sidecar to every Envoy replica. That way we can allocate resources based on the traffic volumes each pod should handle, and scale horizontally with the gateway.
The sidecar container needs:
- An envoy config file template that's valid YAML if all template parameters are replaced with values.
- A secret populated with template parameters such as
SITEandREALM
Authorization is based on ext_authz.
The filter feature is based on ext_proc and is required for feedback during scale-from-zero. While it's there it can also be used for custom request and response transformations.
Gateway can watch endpoints for clusters that are configured for EDS. It can use each service's labels to scale the backing workload. Scaling is inspired by KEDA: it only does -to-one and -to-zero. A regular HorizontalPodAutoscaler can scale up from that.
Using a watcher Gateway will now instantly on a request to that cluster that it needs to be scaled up and the ext_proc filter can serve a loading page while waiting for availability.
Multiple replicas of Gateway can still be unaware of each other because they're very likely to take the same scaling decision (unlike scale above 1 that would depend on traffic volumes).
A configurable cooldown period triggers scale down. With very low traffic volumes the lack of coordination can be an issue here, so use long cooldown periods in such scenarios.
The implementation is less important than the test automation for this component. Tests are found in the scenarios folder. Each scenario consists of one config (k8s resources + template + secret) and a set of HTTP client and/or browser replay tests. The latter uses Puppeteer syntax.
Gateway has the following requirements:
- Kubernetes 1.31+
- Gateway API 1.3+
- Envoy 1.34+