Internal ServiceEntry hosts (<svc>.<domainSuffix>) don't resolve for sidecar-less pods / init containers
Nobody has claimed this yet.
- Dominant language
- Go Template
- Stars
- 2.3k
- Forks
- 186
- Avg merge
- 3d 11h
- Merged PRs (30d)
- 66
Description
**Is your feature request related to a problem? Please describe.**
apl-core exposes several internal hosts (keycloak, harbor, argocd, auth, api, console, …) as Istio `ServiceEntry`s under `.`. 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./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 `*.` (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 `.`. 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.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with apl-core's Istio ServiceEntry definitions and the oauth2-proxy wait-for-keycloak init container described in the issue. Trace how the internal host set and domainSuffix are configured, then determine where cluster DNS support can be generated alongside those entries. Done means sidecar-less pods and init containers resolve the listed internal hosts without downstream CoreDNS configuration.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- kubernetes
- Domain
- infrastructure, networking
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100