A managed application's tenant-facing Services are its endpoints, and
the only way to publish one externally has been the chart boolean
`external`, which publishes one chart-chosen endpoint on one address
from no particular pool through five different render paths.
EndpointAttachment attaches one address, minted from an IPAddressClass
or bound from a reserved IPAddressClaim, to one tenant-facing Service
by rendering an additive LoadBalancer Service that mirrors the
endpoint's selector and ports. The mechanism therefore needs no
per-engine render knowledge and never touches the application's own
objects, and a reserved address survives every attachment and moves
between applications.
The endpoint check requires both the lineage labels and the
tenantresource marker: lineage alone also covers operator-internal
Services. Identity is by owner reference throughout, so a Service
carrying the ownership label without the reference is never adopted,
and a same-name recreated application does not inherit the previous
incarnation's attachments.
The VM datapath modes render the cozy-proxy Service contract unchanged
and are gated on a platform declaration rather than CNI detection: a
proxy skips a Service delegated to a name it does not claim while the
load balancer still attracts the address. Exclusivity is keyed on the
backend pod in both modes because cozy-proxy's egress map holds one
address per pod, and a whole-IP attachment with several ready backends
keeps its address dark instead of picking one.
The e2e suite is parked as disabled until the address substrate is
packaged; the unit tests carry the hold/move and identity proofs.
The kind lives in local.sdn.cozystack.io, the CRD-served half of the
sdn family the address substrate and cozyplane share, so stock
ResourceQuota counts keep working; the proposal text is being
corrected from cozystack.io to match.
Assisted-by: LLM
Signed-off-by: Timofei Larkin <lllamnyp@gmail.com>
Timofei Larkin
1d3ab0bb4c