0 Fork 0

Files

T

matsandClaude Sonnet 5.5 467733a7f9 Remove the ConfigMap, RPZ and managed-directory editors the cluster objects replace

Zones, address redirects, inline rules, lists and groups are cluster objects now
(see the previous commits and deploy/MIGRATION.md), so the mechanisms that held
them are gone:

* internal/kubezones and the resolver's service-account access to a ConfigMap,
  the address-overrides read/write path and its poller, the zone-file poller and
  the Local zones editor with its /api/local-zones routes.
* localzone.Managed, the directory of console-written master files, and the
  blocklist.managed_zones key. The resolver now writes no zone data at all; its
  zone hooks only list. The shared half of that file (the record validator, the
  renderer and the round-trip check) stays as zonestate.go, because DNSZone
  rendering is built on it. Its tests are ported to RenderZone, which keeps the
  coverage of every editable record type, wildcards, relative owners, the
  SOA/NS rule and the delegation rule.
* Tests of the removed write paths: the contract test now builds its zone from a
  DNSZone, and a new test pins that every zone write route on the resolver is
  refused and changes nothing.

Standalone installs keep editing master files on disk and SIGHUP, and the
YAML-backed domain, client, upstream and settings editors, which have not moved.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>

2026-10-16 10:17:17 +02:00

3.6 KiB

Raw Blame History

Moving a ConfigMap deployment to cluster objects

Until now the console edited zones and address redirects by writing two ConfigMaps (fancy-dns-zones, fancy-dns-rpz) through the resolver's service account, and the domains page rewrote the config file. Those mechanisms are gone. Everything the console edits is now an object:

Was	Is
`zone--<apex>.zone` keys in the `fancy-dns-zones` ConfigMap	`DNSZone`
`address-overrides.rpz` in the `fancy-dns-rpz` ConfigMap	`AddressOverride` (one per name)
`blocklist.allow_entries` / `block_entries`	`DomainRule` (`inline-allow`, `inline-block`)
`blocklist.lists` with a URL	`BlockList`
`acl.groups`	`ClientGroup`
listeners, upstreams, cache, `default_policy`	still the resolver's YAML

The old resolver does not read the objects and the new one does not read the ConfigMaps, so the order below matters: create the objects while the old resolver is still serving, switch, then delete the ConfigMaps. Nothing here deletes anything until the last step.

1. Install the definitions and permissions

kubectl apply -f deploy/k8s/crds/crds.yaml
kubectl apply -k deploy/k8s/crds            # lets the resolver's service account read the objects
kubectl apply -f deploy/k8s/console/console.yaml   # the console, which writes them (create its two Secrets first)

2. Convert what you have

The command reads the two ConfigMaps from the cluster and, if you give it the resolver's config.yaml, its URL lists, inline entries and ACL groups. By default it only prints manifests.

kubectl -n dns get cm fancy-dns-config -o jsonpath='{.data.config\.yaml}' > /tmp/config.yaml

FANCYDNS_API_KEY=unused \
fancy-dns-console migrate -kube-namespace dns -config /tmp/config.yaml > migrated.yaml

(FANCYDNS_API_KEY=unused: the config expands ${VAR} references and refuses an unset one; the value is not used.) Read migrated.yaml, and read what the command printed on stderr:

converted: lines say what became an object and what to remove from the config.
NOT converted: lines are things it could not represent faithfully (a zone with a record type the console does not write, a list that is a file on the pod, a name that is not a legal object name). Those stay where they are.

Commit migrated.yaml if you manage the cluster with GitOps, or apply it:

fancy-dns-console migrate -kube-namespace dns -config /tmp/config.yaml -apply

It is safe to run again: objects are created or updated, never duplicated.

3. Switch the resolver

Start it with -kube (the StatefulSet in deploy/k8s/10-deployment.yaml does).
In config.yaml, remove what moved: the edge-router-x-address-overrides list and any other list you converted, acl.groups, the inline entries, blocklist.managed_zones and the fancy-dns-zones glob in local_zones.
Roll it out.

4. Check before you delete anything

kubectl -n dns get dnszones,addressoverrides,clientgroups,blocklists,domainrules
curl -s https://<console>/api/status      # components.degraded must not mention kubernetes
dig @<resolver> <a name from each zone and override>

A rejected object is not a silent failure: it is logged by the resolver, the node reports "kubernetes: objects rejected" as degraded, and an object that was valid before keeps its last good version.

5. Delete the old ConfigMaps

Only now:

kubectl -n dns delete cm fancy-dns-zones fancy-dns-rpz

If your GitOps tool prunes, remove them from the repository after step 4, not before: they hold the only copy of the data until the objects exist.

3.6 KiB Raw Blame History