Currently we rely on a fairly wonky controller that rewrites CoreDNS or other providers (#348) to add the '.substrate.ate.dev' single wildcard -> IP domain. This works but it doesn't feel great.
- This targets one/two DNS provider, but there are many we will need to add
- This makes subtrate responsible for reconciling a kubernetes system resource, that will quite plausibly get reconciled back by the core cluster infrastructure.
- Modifying only the cluster-local DNS means I cannot resolve it outside of the cluster
- 'my-counter-1.demo.actors.resources.substrate.ate.dev' style naming means we have two wildcards. DNS allows a single wildcard to cover multiple labels, but TLS doesn't. This means I cannot serve a
*.actors.resources.substrate.ate.dev TLS cert.
One option briefly discussed was using paths identify the actor. For example curl atenet.svc.cluster.local/actors/demo/my-counter/some/path would forward to 'my-counter' in 'demo' atespace and send to /some/path. One possible concern with this is it looks us into HTTP (unless we start doing CONNECT or something). Today, we are only implementing HTTP but the design would at least facilitate TLS as we could do SNI routing; moving to path based would remove that possibility.
Currently we rely on a fairly wonky controller that rewrites CoreDNS or other providers (#348) to add the '.substrate.ate.dev' single wildcard -> IP domain. This works but it doesn't feel great.
*.actors.resources.substrate.ate.devTLS cert.One option briefly discussed was using paths identify the actor. For example
curl atenet.svc.cluster.local/actors/demo/my-counter/some/pathwould forward to 'my-counter' in 'demo' atespace and send to /some/path. One possible concern with this is it looks us into HTTP (unless we start doing CONNECT or something). Today, we are only implementing HTTP but the design would at least facilitate TLS as we could do SNI routing; moving to path based would remove that possibility.