Skip to content

add ingress/gateway doc#407

Open
graydon wants to merge 1 commit into
stellar:mainfrom
graydon:gateway-and-ingress
Open

add ingress/gateway doc#407
graydon wants to merge 1 commit into
stellar:mainfrom
graydon:gateway-and-ingress

Conversation

@graydon

@graydon graydon commented Jul 11, 2026

Copy link
Copy Markdown
Contributor

This just adds a doc explaining a bit more about where we were coming from and where we're going to with the gateway API migration in #405. Comments welcome!

Copilot AI review requested due to automatic review settings July 11, 2026 01:18
@graydon graydon requested a review from Jonathan-Eid July 11, 2026 01:19

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Adds a new documentation note explaining Supercluster’s historical Ingress-based HTTP routing to stellar-core pods and the mid-2026 migration to Gateway API (HTTPRoute) with an intermediate nginx proxy hop, including rationale (notably avoiding ExternalName-driven DNS amplification).

Changes:

  • Add doc/gateway-and-ingress.md describing the old Ingress + ExternalName model and the new Gateway API + nginx-proxy model.
  • Document key constraints motivating the design (e.g., HTTPRoute rule limits) and the resulting request-flow diagrams.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment on lines +34 to +36
managing. But it also, annoyingly, also _limited_ the set of places
the HTTP-proxy-programs could send things to. Rather than common
things like "addresse" or "ports", it required us to configure and use
Comment on lines +101 to +102
One benefit of this is that we get to get rid of the `ExternalName`
objects. Which is good because they were evidently the source of much
Comment on lines +15 to +17
proxies) to be provided that k8s can operate on your behalf, via those
management APIs. So Supercluster asks k8s "hey can you open a port and
route incoming HTTP to a pod" and k8s turns around and launches a pod
would get routed to http://<peer-N>.cluster.internal.domain/foo by the
program. This was done by setting HTTP-proxy-program-specific
"annotations" on the ingress object, and this was fragile and often
broke: k8s gave us nearly no help configuring the proxies it was
So instead of using per-target-pod `HTTPRoute`s, we now forward
traffic from the gateway to a new, manually configured pod of some
number of nginx proxy containers which, as they are configured through
non-k8s-abstracted normal nginx config language, we can configure
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants