Is your feature request related to a problem? Please describe.
apl-core exposes several internal hosts (keycloak, harbor, argocd, auth, api, console, …) as Istio ServiceEntrys under <svc>.<domainSuffix>. These resolve fine for mesh/sidecar'd pods, but sidecar-less pods and init containers can't resolve them — there's no in-cluster DNS record backing the ServiceEntry host. apl-core's own components hit this: the oauth2-proxy wait-for-keycloak init container is sidecar-less by definition and polls https://keycloak.<domainSuffix>/realms/otomi at boot, but the name doesn't resolve, so it can't even reach the CA/TLS failure — it fails at DNS.
Describe the solution you'd like
Ship in-cluster DNS resolution for the internal ServiceEntry hosts apl-core defines, so sidecar-less/init workloads resolve them out of the box — e.g. a CoreDNS rewrite/hosts entry for *.<domainSuffix> (or real ClusterIP Services) generated alongside the ServiceEntries. apl-core is best positioned to know the full host set (it defines the ServiceEntries).
Describe alternatives you've considered
We maintain a CoreDNS *.internal rewrite downstream so sidecar-less/init consumers can resolve <svc>.<domainSuffix>. It works but couples us to apl-core's host set and domainSuffix templating, and every adopter re-discovers it as an opaque "init container loops forever" failure.
Additional context
This is the DNS-resolution counterpart to the CA-trust half of #3388 (the oauth2-proxy wait-for-keycloak init container also can't trust the custom-CA cert). The two are independent: even with the CA fixed, the host still has to resolve. Fixing both is what lets apl-core's own init containers reach Ready unaided.
Is your feature request related to a problem? Please describe.
apl-core exposes several internal hosts (keycloak, harbor, argocd, auth, api, console, …) as Istio
ServiceEntrys under<svc>.<domainSuffix>. These resolve fine for mesh/sidecar'd pods, but sidecar-less pods and init containers can't resolve them — there's no in-cluster DNS record backing the ServiceEntry host. apl-core's own components hit this: the oauth2-proxywait-for-keycloakinit container is sidecar-less by definition and pollshttps://keycloak.<domainSuffix>/realms/otomiat boot, but the name doesn't resolve, so it can't even reach the CA/TLS failure — it fails at DNS.Describe the solution you'd like
Ship in-cluster DNS resolution for the internal ServiceEntry hosts apl-core defines, so sidecar-less/init workloads resolve them out of the box — e.g. a CoreDNS rewrite/hosts entry for
*.<domainSuffix>(or real ClusterIP Services) generated alongside the ServiceEntries. apl-core is best positioned to know the full host set (it defines the ServiceEntries).Describe alternatives you've considered
We maintain a CoreDNS
*.internalrewrite downstream so sidecar-less/init consumers can resolve<svc>.<domainSuffix>. It works but couples us to apl-core's host set and domainSuffix templating, and every adopter re-discovers it as an opaque "init container loops forever" failure.Additional context
This is the DNS-resolution counterpart to the CA-trust half of #3388 (the oauth2-proxy
wait-for-keycloakinit container also can't trust the custom-CA cert). The two are independent: even with the CA fixed, the host still has to resolve. Fixing both is what lets apl-core's own init containers reach Ready unaided.