feat(chart): add hostAliases value - #6588
Conversation
Expose the `Pod`'s `hostAliases` field so entries can be injected into `/etc/hosts`. This is useful when external-dns must reach a provider or webhook by a hostname that cannot be resolved by cluster DNS -- for example an on-premises provider whose TLS certificate is issued for a hostname with no IP SAN, where addressing it by IP would forgo certificate verification and addressing it by name would depend on the very records external-dns is responsible for publishing. The chart renders a fixed set of pod fields and already exposes the neighbouring `dnsPolicy` and `dnsConfig`, so this follows the same pattern. Defaults to an empty list, leaving the rendered `Pod` unchanged. Signed-off-by: Joseph Petersen <jop@moviestarplanet.com>
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
kubernetes-prow
Bot
added
the
cncf-cla: yes
|
Welcome @jetersen! |
kubernetes-prow
Bot
added
the
needs-ok-to-test
|
Hi @jetersen. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Regular contributors should join the org to skip this step. Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
kubernetes-prow
Bot
added
the
size/M
Signed-off-by: Joseph Petersen <jop@moviestarplanet.com>
|
/ok-to-test |
kubernetes-prow
Bot
added
ok-to-test
Coverage Report for CI Build 30314581549Warning Build has drifted: This PR's base is out of sync with its target branch, so coverage data may include unrelated changes. Coverage remained the same at 81.131%Details
Uncovered ChangesNo uncovered changes found. Coverage RegressionsNo coverage regressions found. Coverage Stats
💛 - Coveralls |
What does it do ?
Exposes the
Pod'shostAliasesfield as a chart value, rendered into the Deployment alongside the existingdnsPolicyanddnsConfig. Defaults to[], so the renderedPodis unchanged unless the value is set.Motivation
external-dnssometimes has to reach a provider or webhook by a hostname that cluster DNS cannot resolve.The case I hit: a UniFi controller whose API serves a publicly-trusted certificate issued for its hostname, with no IP SAN — and no public CA will issue one for an RFC1918 address. That leaves two bad options. Addressing it by IP means disabling certificate verification and sending an API key over an unverified connection. Addressing it by hostname means depending on the very DNS records
external-dnsis responsible for publishing, which deadlocks on a fresh cluster.hostAliasesresolves this cleanly: the hostname is pinned in the pod's/etc/hosts, consulted before any resolver, so TLS verifies against the real certificate with no DNS dependency. The same applies to any on-premises provider or webhook reachable only via a hostname that isn't in cluster DNS.The chart renders a fixed allowlist of pod fields, so there is currently no way to set this —
dnsConfigcannot map a name to an address, and a post-renderer is the only workaround.More
values.schema.jsonandREADME.mdwere regenerated withscripts/helm-tools.sh --schemaand--docs.helm unittestpasses (83 tests, including two new cases covering the default and configured behaviour).