1c3cd31381
Hetzner OS publishes 4 systemd-resolved upstreams and Kubernetes limits pod resolv.conf to 3 nameservers, so kubelet drops the 4th and fires a DNSConfigForming Warning event on every hostNetwork or dnsPolicy=Default pod restart. Silence the noise by pinning the pods to 3 explicit servers (same 3 kubelet was already picking). - apps/observability/patches/node-exporter-dns-config.yaml — strategic- merge patch adding dnsPolicy=None + dnsConfig to the kube-prometheus-stack node-exporter DaemonSet (Helm-managed, applied by hand) - apps/observability/patches/coredns-dns-config.yaml — companion patch for the k3s built-in CoreDNS Deployment. kubectl patch alone is not durable because the k3s addon controller reverts dnsPolicy; kept as a quick manual re-apply hook - infrastructure/k3s-manifests/coredns.yaml — the authoritative modified k3s addon manifest that must live at /var/lib/rancher/k3s/server/manifests/coredns.yaml on all 3 CP nodes - infrastructure/k3s-manifests/README-DEV-527.md — apply procedure, verification steps, and upgrade caveat Applied and verified on the live cluster: - node-exporter DaemonSet rolled with dnsPolicy=None; no DNSConfigForming events on current pods - coredns Deployment reconciled after pushing the modified manifest to all 3 CPs; new pod runs with dnsPolicy=None and 3-nameserver dnsConfig - internal + external DNS resolution still works Co-Authored-By: Paperclip <noreply@paperclip.ing>
47 lines
2 KiB
YAML
47 lines
2 KiB
YAML
---
|
|
# Strategic-merge patch capping the CoreDNS pod's DNS at three
|
|
# upstream servers to silence Kubernetes' DNSConfigForming warning
|
|
# (DEV-527).
|
|
#
|
|
# The Hetzner OS publishes four systemd-resolved upstreams
|
|
# (2a01:4ff:ff00::add:2, 2a01:4ff:ff00::add:1, 185.12.64.1, 185.12.64.2),
|
|
# and kubelet drops the fourth because Kubernetes limits pod resolv.conf
|
|
# to three nameservers. CoreDNS uses `dnsPolicy: Default` (inherit the
|
|
# node's resolv.conf) so it triggers the warning too.
|
|
#
|
|
# We keep the same three servers kubelet would have picked (the two
|
|
# Hetzner IPv6 anycast entries plus the first IPv4 entry) so CoreDNS's
|
|
# upstream forwarder (`forward . /etc/resolv.conf`) sees the same
|
|
# upstreams it already uses; only the noisy warning goes away.
|
|
# `dnsPolicy: None` is required so `dnsConfig` is authoritative —
|
|
# otherwise kubelet still merges the node's resolv.conf and we exceed
|
|
# the three-nameserver limit again.
|
|
#
|
|
# CoreDNS in k3s is an *Addon* whose source manifest lives on each
|
|
# control-plane node at `/var/lib/rancher/k3s/server/manifests/coredns.yaml`
|
|
# and is reconciled by the k3s addon controller. Applying this file
|
|
# via `kubectl patch` is durable in steady state (the addon controller
|
|
# only re-applies when the source file's checksum changes), but if the
|
|
# source file is ever regenerated (k3s upgrade, disaster recovery) the
|
|
# patch will be reverted. To keep the fix on regeneration, mirror the
|
|
# same `dnsPolicy` / `dnsConfig` block into the Deployment stanza of
|
|
# each CP node's `coredns.yaml` — see `docs/DEV-527-coredns-dns-config.md`.
|
|
#
|
|
# Apply / re-apply with:
|
|
# kubectl -n kube-system patch deployment coredns \
|
|
# --type=strategic \
|
|
# --patch-file=apps/observability/patches/coredns-dns-config.yaml
|
|
spec:
|
|
template:
|
|
spec:
|
|
dnsPolicy: None
|
|
dnsConfig:
|
|
nameservers:
|
|
- 2a01:4ff:ff00::add:2
|
|
- 2a01:4ff:ff00::add:1
|
|
- 185.12.64.1
|
|
searches:
|
|
- .
|
|
options:
|
|
- name: edns0
|
|
- name: trust-ad
|