stack.basicstack.de/apps/observability/patches/coredns-dns-config.yaml

48 lines
2 KiB
YAML
Raw Normal View History

fix(dns): cap hostNetwork/coredns pod DNS at 3 upstreams (DEV-527) 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>
2026-08-23 12:05:12 +00:00
---
# 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