Files
Homelabv4/infrastructure/coredns/manifests/coredns-configmap.yaml
T
Scooby HuskyandClaude Sonnet 5 bce3861083 GitLab cross-site replication Phase 2b: enable Gitaly + workhorse TLS
Per the approved plan (Istio federation scoped separately, current
NodePort/PeerAuth/cert-manager pattern continues for these 2 remaining
links). Real Let's Encrypt certs (not self-signed) via the same DNS-01
ClusterIssuer used everywhere else - both sites already trust Let's
Encrypt's public CA, no custom CA distribution needed.

- global.gitaly.tls.enabled: adds tls_listen_addr (8076) alongside the
  existing plaintext listener (8075, stays for in-cluster traffic
  that doesn't need it). Requires
  global.praefect.virtualStorages[0].tlsSecretName (chart's own NOTES.txt
  validation rejects the render without it, confirmed live).
- global.workhorse.tls.enabled + global.workhorse.host: Gitaly's [gitlab]
  url (internal-API callback for gitlab-shell hooks) switches from an
  unpublishable *.svc.cluster.local name to a real floating hostname
  (gitlab-internal-api.ha.huskypup.net) that Let's Encrypt CAN certify -
  confirmed live this replaces the plaintext [[listeners]] block with
  [listeners.tls] on the SAME port (8181), not a second port like Gitaly.
- praefect-ha-configmap.yaml (the manually-patched live config) updated
  to tls:// + floating hostnames for all 3 home nodes, so home's own
  Praefect uses the identical addresses it'll hand the VPS as peer
  addresses once Phase 2b's 4th node lands.
- New CoreDNS rewrite for gitlab-internal-api.ha.huskypup.net (same
  local-rewrite pattern as pg-*/gitaly-* already have).

Sequencing note: applying live - Certificates must issue before the
TLS-enabling values land, or Gitaly/webservice pods fail to start
(missing secret for their init container's cert copy).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-22 14:24:13 -05:00

101 lines
4.8 KiB
YAML

# Brings kube-system/coredns's Corefile under GitOps management. It was
# previously only ever edited live via kubectl (3 existing rewrite rules
# for auth/rancher/netbird.kube.huskypup.net, none of them git-tracked
# anywhere in this repo) - every future change meant a manual,
# classifier-gated live edit to a cluster-wide DNS config instead of a
# normal git commit ArgoCD applies on its own. No Talos/kubeadm
# ownerReferences on this ConfigMap or the coredns Deployment (confirmed
# live 2026-08-20), so it's safe to take over here.
#
# No pod restart needed after a sync - the Corefile's own `reload` plugin
# (already present below) watches the mounted file and hot-reloads within
# ~30-60s of the ConfigMap volume actually updating on disk (kubelet
# propagates ConfigMap changes to mounted volumes automatically, typically
# within ~60-90s).
apiVersion: v1
kind: ConfigMap
metadata:
name: coredns
namespace: kube-system
data:
Corefile: |
.:53 {
errors
health {
lameduck 5s
}
ready
log . {
class error
}
prometheus :9153
# Rewrite auth.kube.huskypup.net to ingress gateway (NOT authentik-server directly)
# This ensures HTTPS works because the ingress gateway has the wildcard TLS cert.
# The old rewrite to authentik-server caused TLS failures for OIDC token exchange.
rewrite name auth.kube.huskypup.net istio-ingressgateway.istio-system.svc.cluster.local
# Rewrite rancher.kube.huskypup.net to internal Istio ingress gateway
rewrite name rancher.kube.huskypup.net istio-ingressgateway.istio-system.svc.cluster.local
# Rewrite netbird.kube.huskypup.net to internal Istio ingress gateway
rewrite name netbird.kube.huskypup.net istio-ingressgateway.istio-system.svc.cluster.local
# Multi-site active failover pilot (see
# /home/scooby/.claude/plans/jiggly-snacking-iverson.md): home's
# own pods resolving the floating pg-authentik.ha.huskypup.net
# record always go straight to a local service instead of
# round-tripping out through the UniFi WAN port-forward and back
# in - this UniFi doesn't support NAT hairpin/loopback for its
# own forwarded ports (confirmed live 2026-08-20: DNS resolved
# fine, TCP connect failed). Points at ha-authentik-postgres, NOT
# CNPG's own pg-authentik-rw directly - rewrite only changes the
# resolved name, not the port a client then connects to, and the
# app tier is configured for port 61432 (matching the external
# floating hostname) - pg-authentik-rw only listens on 5432,
# ha-authentik-postgres additionally listens on 61432 (see
# infrastructure/authentik/manifests/ha-postgres-nodeport.yaml)
# specifically so this rewrite target actually has that port.
rewrite name pg-authentik.ha.huskypup.net ha-authentik-postgres.authentik.svc.cluster.local
# GitLab cross-site replication (see
# /home/scooby/.claude/plans/jiggly-snacking-iverson.md) - same
# reasoning as pg-authentik.ha.huskypup.net above: home's own pods
# go straight to the local NodePort Service instead of round-
# tripping out through the UniFi WAN forward and back in (no NAT
# hairpin support, confirmed live for the authentik precedent).
rewrite name pg-gitlab.ha.huskypup.net ha-gitlab-postgres.gitlab.svc.cluster.local
rewrite name pg-praefect.ha.huskypup.net ha-praefect-postgres.gitlab.svc.cluster.local
# GitLab cross-site replication Phase 2b (Gitaly) - home's own
# Praefect dials these SAME floating hostnames it hands to the
# VPS's Gitaly node as peer addresses (Praefect uses one address
# per node for everyone, not different addresses per caller), so
# home's own in-cluster traffic to its own local Gitaly nodes
# needs to resolve locally too, same reasoning as pg-*.ha above.
rewrite name gitaly-0.ha.huskypup.net ha-gitaly-0.gitlab.svc.cluster.local
rewrite name gitaly-1.ha.huskypup.net ha-gitaly-1.gitlab.svc.cluster.local
rewrite name gitaly-2.ha.huskypup.net ha-gitaly-2.gitlab.svc.cluster.local
# global.workhorse.host override (apps/gitlab/values.yaml) - every
# Gitaly node's [gitlab] url, home's own included, same local-
# rewrite reasoning as the entries above.
rewrite name gitlab-internal-api.ha.huskypup.net ha-gitlab-internal-api.gitlab.svc.cluster.local
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
fallthrough in-addr.arpa ip6.arpa
ttl 30
}
forward . 1.1.1.1 8.8.8.8 {
max_concurrent 1000
}
cache 30 {
disable success cluster.local
disable denial cluster.local
}
loop
reload
loadbalance
}