Core DNS für DNS in EKS Amazon-Clustern verwalten

CoreDNSist ein flexibler, erweiterbarer DNS Server, der als Kubernetes Cluster DNS dienen kann. Wenn Sie einen EKS Amazon-Cluster mit mindestens einem Knoten starten, werden standardmäßig zwei Replikate des CoreDNS Images bereitgestellt, unabhängig von der Anzahl der in Ihrem Cluster bereitgestellten Knoten. Die CoreDNS-Pods bieten die Namensauflösung für alle Pods im Cluster. Die CoreDNS-Pods können auf Fargate-Knoten bereitgestellt werden, wenn Ihr Cluster ein Definieren Sie, welche Pods Verwendung AWS Fargate beim Start verwendet wird mit einem Namespace enthält, der dem Namespace für das CoreDNS-deployment entspricht. Weitere Informationen zu CoreDNS finden Sie unter Verwenden von CoreDNS für die Serviceerkennung in der Kubernetes-Dokumenation.

CoreDNS-Versionen

In der folgenden Tabelle ist die neueste Version des EKS Amazon-Zusatztyps für jede Kubernetes Version aufgeführt.

Kubernetes-Version	1.30	1.29	1.28	1.27	1.26	1.25	1.24	1.23
	v1.11.1-eksbuild.11	v1.11.1-eksbuild.11	v1.10.1-eksbuild.13	v1.10.1-eksbuild.13	v1.9.3-eksbuild.17	v1.9.3-eksbuild.17	v1.9.3-eksbuild.17	v1.8.7-eksbuild.16

Wichtig

Wenn Sie dieses Add-on selbst verwalten, stimmen die Versionen in der Tabelle möglicherweise nicht mit den verfügbaren selbstverwalteten Versionen überein. Weitere Hinweise zur Aktualisierung des selbstverwalteten Typs dieses Add-ons finden Sie unter Aktualisieren Sie das EKS selbstverwaltete CoreDNS Amazon-Add-on.

Wichtige Überlegungen zum CoreDNS-Upgrade

• Um die Stabilität und Verfügbarkeit der CoreDNS Deployment zu verbessern, werden die Versionen v1.9.3-eksbuild.6 und neuer und v1.10.1-eksbuild.3 mit einem PodDisruptionBudget bereitgestellt. Wenn Sie ein vorhandenes PodDisruptionBudget bereitgestellt haben, schlägt Ihr Upgrade auf diese Versionen möglicherweise fehl. Schlägt das Upgrade fehl, sollte das Problem durch Ausführen einer der folgenden Aufgaben gelöst werden:

  • Wählen Sie beim Upgrade des EKS Amazon-Add-ons, die vorhandenen Einstellungen als Konfliktlösungsoption außer Kraft zu setzen. Wenn Sie weitere benutzerdefinierte Einstellungen für die Deployment vorgenommen haben, stellen Sie sicher, dass Sie Ihre Einstellungen vor dem Upgrade sichern, damit Sie Ihre anderen benutzerdefinierten Einstellungen nach dem Upgrade erneut anwenden können.

  • Entfernen Sie Ihr vorhandenes PodDisruptionBudget und versuchen Sie das Upgrade erneut.

• In EKS Add-On-Versionen v1.9.3-eksbuild.3 v1.10.1-eksbuild.6 und späteren Versionen CoreDNS Deployment legt das fest, readinessProbe dass der /ready Endpunkt verwendet wird. Dieser Endpunkt ist in der Corefile-Konfigurationsdatei für CoreDNS aktiviert.

  Wenn Sie eine benutzerdefinierte Corefile verwenden, müssen Sie das ready Plugin zur Konfiguration hinzufügen, sodass der /ready Endpunkt in CoreDNS aktiv ist, damit er von der Probe verwendet werden kann.

• In EKS Add-On-Versionen v1.9.3-eksbuild.7 v1.10.1-eksbuild.4 und späteren Versionen können Sie die ändernPodDisruptionBudget. Sie können das Add-on bearbeiten und diese Einstellungen in den optionalen Konfigurationseinstellungen mithilfe der Felder im folgenden Beispiel ändern. Dieses Beispiel zeigt das Standard-PodDisruptionBudget.

  {
      "podDisruptionBudget": {
          "enabled": true,
          "maxUnavailable": 1
          }
  }

  Sie können maxUnavailable oder minAvailable festlegen, aber Sie können nicht beide gleichzeitig in einem einzelnen PodDisruptionBudget festlegen. Weitere Informationen zu PodDisruptionBudgets finden Sie unter Angeben eines PodDisruptionBudget in der Kubernetes-Dokumentation.

  Beachten Sie, dass, wenn Sie enabled auf false festlegen, das PodDisruptionBudget nicht entfernt wird. Nachdem Sie dieses Feld auf false gesetzt haben, müssen Sie das PodDisruptionBudget-Objekt löschen. Ähnlich verhält es sich, wenn Sie das Add-on bearbeiten, um nach dem Upgrade auf eine Version mit einem PodDisruptionBudget eine ältere Version des Add-ons zu verwenden (das Add-On herunterstufen). Das PodDisruptionBudget wird nicht entfernt. Führen Sie den folgenden Befehl aus, um das PodDisruptionBudget zu löschen:

  kubectl delete poddisruptionbudget coredns -n kube-system
  

• Ändern Sie in EKS Add-On-Versionen v1.10.1-eksbuild.5 und höher die Standardtoleranz von node-role.kubernetes.io/master:NoSchedule node-role.kubernetes.io/control-plane:NoSchedule bis, sodass sie KEP 2067 entspricht. Weitere Informationen zu KEP 2067 finden Sie unter KEP-2067: Benennen Sie das kubeadm „master“ -Label und Taint in den Kubernetes Enhancement Proposals () um. KEPs GitHub

  In EKS Add-On-Versionen v1.8.7-eksbuild.8 v1.9.3-eksbuild.9 und späteren Versionen sind beide Toleranzen so eingestellt, dass sie mit jeder Version kompatibel sind. Kubernetes

• In EKS Add-On-Versionen v1.9.3-eksbuild.11 v1.10.1-eksbuild.7 und höher CoreDNS Deployment legt der einen Standardwert für topologySpreadConstraints fest. Der Standardwert stellt sicher, dass sie über die Availability Zones verteilt CoreDNS Pods sind, falls Knoten in mehreren Availability Zones verfügbar sind. Sie können einen benutzerdefinierten Wert festlegen, der anstelle des Standardwerts verwendet wird. Der Standardwert lautet wie folgt:

  topologySpreadConstraints:
    - maxSkew: 1
      topologyKey: topology.kubernetes.io/zone
      whenUnsatisfiable: ScheduleAnyway
      labelSelector:
        matchLabels:
          k8s-app: kube-dns

CoreDNSÜberlegungen zum 1.11 Upgrade

• In EKS Zusatzversionen v1.11.1-eksbuild.4 und späteren Versionen basiert das Container-Image auf einem minimalen Basis-Image, das von Amazon EKS Distro verwaltet wird. Es enthält nur minimale Pakete und keine Shells. Weitere Informationen finden Sie unter Amazon EKS Distro. Die Verwendung und Fehlerbehebung des CoreDNS Images bleiben unverändert.