You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Explains one-Gateway-per-namespace pattern: single Envoy Gateway
controller + single operator, one Gateway per namespace each with
its own ALB. Includes install commands for both operator and
per-namespace Gateway.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Copy file name to clipboardExpand all lines: README.md
+34Lines changed: 34 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -62,6 +62,40 @@ Key Helm values:
62
62
| `gateway.allowedRouteNamespaces` | `All` | Namespaces that can attach HTTPRoutes |
63
63
| `gateway.create` | `true` | Set `false` to bring your own Gateway |
64
64
65
+
## Multi-namespace setup
66
+
67
+
If you have multiple namespaces each with their own ALB, deploy one `Gateway` per namespace. A single Envoy Gateway controller and a single operator instance serve the whole cluster.
68
+
69
+
```
70
+
ns-1: ALB-1 → Gateway (ns-1) → HTTPRoutes for pp-* in ns-1
71
+
ns-2: ALB-2 → Gateway (ns-2) → HTTPRoutes for pp-* in ns-2
72
+
```
73
+
74
+
**ALB configuration:** each ALB needs only one rule — forward `/*` to the Envoy Gateway service in that namespace. No per-pod rules.
75
+
76
+
**Install the operator once** (cluster-wide, no Gateway):
--set operator.watchNamespace=ns-1 # disable second operator — only one needed
95
+
```
96
+
97
+
> The operator uses the pod's namespace to find the local Gateway when `--gateway-namespace` is empty, so HTTPRoutes in `ns-1` attach to the Gateway in `ns-1` automatically.
0 commit comments