Repository navigation
gateway: check this controller's route-status writer against a live Cilium #4199
Description
Split out of the review of #3342. Two assumptions about the pinned Cilium that the design depends on, which I flagged as unsettled rather than asserted because I read them against the v1.19 branch rather than the pinned v1.19.5 tag. Both are cheap to answer on a cluster and neither needed to block the merge.
Does toTLSRoutes consult allowedRoutes during ingestion? The controller refuses a TLSRoute that reaches a native-port passthrough listener from a namespace that listener does not admit, and therefore keeps the terminate listener. If Cilium's ingestion does not consult allowedRoutes, and the permissive port-443 listener answering the same hostname satisfies its namespace check, it would build the passthrough chain regardless — and two filter chains carrying one server name in a single Envoy listener is not a graceful failure. Reaching it needs a hand-written tlsPassthroughListeners entry, which no chart value produces today, so nothing in a shipped configuration does this; it is worth settling before the field is wired to chart values.
Does mergeStatusConditions produce a status ping-pong with this controller? Our merge keys on (ControllerName, ParentRef) (internal/controller/tenantgateway/conflict.go:956-982), while Cilium's appears to key on the parentRef alone. If so, whichever entry lands first is merged into by the other and rewritten on the next pass, and the two never converge — which would also make the conflicts in #4195 routine rather than rare. Both predate #3342.
The Phase 1 gate run that the design asks for is the natural place to answer both, since it already stands up a passthrough listener on a real cluster.
Activity
kvaps commentedon Sep 10, 2026
Half of this is answered. From the live run on #3342 (Cilium 1.19.5, terminate listeners on 443 plus a passthrough listener on 5432):
A TLSRoute reaching the native-port listener from a namespace that listener does not admit gets no filter chain at all, and the name goes on answering with the terminate certificate. Pinned to the listener it reads
Accepted=FalsewithNotAllowedByListeners; unpinned it readsAccepted=True, which is a status bug rather than a datapath one, since nothing is built either way. So the duplicate-filter-chain worry does not reproduce and the first question is closed.What is left is the second one. Cilium preserves a foreign controller's
RouteParentStatusentry verbatim across generation bumps, so there is no rewrite war between two controllers in general. But the branch's own controller was not deployed on that cluster, so this controller's writer against a live Cilium is still untested, and that is the pairing that would matter for the conflict rate.Narrowing the title and scope to that.
[-]gateway: confirm two Cilium v1.19.5 assumptions the passthrough design rests on[/-][+]gateway: check this controller's route-status writer against a live Cilium[/+]