Zum Hauptinhalt springen
  1. Beiträge/
  2. Kleines Homelab/
  3. k3s-prod: Kubernetes Cluster Konfiguration und Anwendungsbereitstellung/

CoreDNS

··373 Wörter· ·
Inhaltsverzeichnis

CoreDNS
#

Quelle
#

Das Projekt basiert auf dem CoreDNS GitHub Repository. Das Helm-Chart stammt aus dem CoreDNS Helm Charts Repository.

Dokumentation
#

Funktion
#

CoreDNS ist ein fundamentaler Bestandteil des Kubernetes-Clusters und verantwortlich für die Namensauflösung (DNS). Es ermöglicht Pods und Services, sich gegenseitig über ihre Namen zu finden (z.B. my-service.my-namespace.svc.cluster.local). Es ist so konfiguriert, dass es Anfragen für interne Cluster-Domains beantwortet und alle anderen Anfragen an Upstream-DNS-Server weiterleitet.

Lokale Anpassungen
#

Die Konfiguration erfolgt über die values.yaml-Datei.

Wichtige Einstellungen
#

  • Replikas: Es werden drei Replikate von CoreDNS betrieben, um Hochverfügbarkeit zu gewährleisten.
  • Dual-Stack: Der Service ist für den Dual-Stack-Betrieb (IPv4 und IPv6) konfiguriert.
  • Plugins: Eine Reihe von Plugins ist aktiviert, darunter:
    • kubernetes: Für die Auflösung von Kubernetes-Services und -Pods.
    • forward: Leitet Anfragen, die nicht vom kubernetes-Plugin aufgelöst werden können, an die DNS-Server in /etc/resolv.conf weiter — mit policy sequential, damit die Reihenfolge der Datei gilt und nicht der Zufall.
    • cache: Cacht DNS-Antworten, um die Latenz zu verringern und die Last auf den Upstream-Servern zu reduzieren.
    • prometheus: Stellt Metriken für das Monitoring bereit.
  • Interne Zonen: Zonen, die es nur im LAN gibt (Active Directory, Router, Reverse-Lookup), beantwortet dieses CoreDNS nicht selbst, sondern reicht sie an die App nameserver weiter. Dort liegen die Weiterleitungsziele an einer Stelle, statt hier ein zweites Mal gepflegt zu werden. Angesprochen wird sie über die ClusterIP: der Service läuft mit externalTrafficPolicy: Local, über seine LoadBalancer-Adresse fragten CoreDNS-Pods auf Nodes ohne nameserver-Replica ins Leere.
  • Upstreams: Die /etc/resolv.conf der Pods stammt nicht von systemd-resolved, sondern aus einer eigenen Datei, die Ansible auf jede Node schreibt und kubelet per resolv-conf untergeschoben bekommt. Damit ist die Upstream-Liste auf allen Nodes identisch und bleibt unter dem kubelet-Limit von drei Nameservern.
  • Scheduling: CoreDNS-Pods werden bevorzugt auf den Control-Plane-Nodes ausgeführt und sind über topologySpreadConstraints auf verschiedene Nodes und Zonen verteilt, um die Ausfallsicherheit zu erhöhen.

Installation
#

Die Anwendung wird mittels Kustomize und Helm durch ArgoCD im Kubernetes-Cluster bereitgestellt. Die Konfiguration befindet sich im apps/coredns-Verzeichnis. Eine manuelle Installation kann mit folgendem Befehl durchgeführt werden:

1kubectl kustomize --enable-helm apps/coredns | kubectl apply -n kube-system -f -

Abhängigkeiten
#

CoreDNS ist eine Kernkomponente von Kubernetes und hat keine externen Anwendungsabhängigkeiten, ist aber für die Funktion fast aller anderen Anwendungen im Cluster kritisch.

Fabrice Kirchner
Autor
Fabrice Kirchner
stolzer Vater, Nerd, Admin