**Unterstützung für die Verbesserung dieser Seite beitragen**
Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Um zu diesem Benutzerhandbuch beizutragen, wählen Sie den GitHub Link **Diese Seite bearbeiten auf**, der sich im rechten Bereich jeder Seite befindet.
Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Verwalten von CoreDNS für DNS in Amazon-EKS-Clustern
**Tipp**
Mit Amazon EKS Auto Mode ist es nicht erforderlich, Netzwerk-Add-Ons zu installieren oder zu aktualisieren. Der Automatikmodus umfasst Funktionen für Pod-Netzwerke und Load Balancing.
Weitere Informationen finden Sie unter [Automatisieren der Cluster-Infrastruktur mit dem EKS-Automatikmodus](automode.md).
CoreDNS ist ein flexibler, erweiterbarer DNS-Server, der als Kubernetes-Cluster-DNS dienen kann. Wenn Sie einen Amazon-EKS-Cluster mit mindestens einem Knoten starten, werden standardmäßig zwei Replikate des CoreDNS-Image bereitgestellt, unabhängig von der Anzahl der in Ihrem Cluster bereitgestellten Knoten. Die CoreDNS-Pods bieten eine Namensauflösung für alle Pods im Cluster. Die CoreDNS-Pods können in Fargate-Knoten bereitgestellt werden, wenn Ihr Cluster ein [Fargate-Profil](fargate-profile.md) mit einem Namespace enthält, der mit dem Namespace für CoreDNS `deployment` übereinstimmt. Weitere Informationen zu CoreDNS finden Sie unter [Verwenden von CoreDNS für die Serviceerkennung](https://kubernetes.io/docs/tasks/administer-cluster/coredns/) in der Kubernetes-Dokumentation.
## CoreDNS-Versionen
In der folgenden Tabelle ist die neueste Version des Amazon-EKS-Add-On-Typs für jede Kubernetes-Version aufgeführt.
| Kubernetes-Version | CoreDNS-Version |
| --- | --- |
| 1,35 | v1.13.2-eksbuild.4 |
| 1,34 | v1.13.2-eksbuild.4 |
| 1.33 | v1.13.2-eksbuild.4 |
| 1.32 | v1.11.4-eksbuild.33 |
| 1.31 | v1.11.4-eksbuild.33 |
| 1,30 | v1.11.4-eksbuild.33 |
**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 [Aktualisierung des selbstverwalteten CoreDNS-Amazon-EKS-Add-Ons](coredns-add-on-self-managed-update.md).
## Wichtige Überlegungen zum CoreDNS-Upgrade
+ CoreDNS-Updates verwenden a PodDisruptionBudget , um die Verfügbarkeit des DNS-Dienstes während des Aktualisierungsvorgangs aufrechtzuerhalten.
+ Um die Stabilität und Verfügbarkeit der CoreDNS-Bereitstellung zu verbessern, werden Versionen `v1.9.3-eksbuild.6` und höher sowie `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:
+ Wenn Sie das Upgrade des Amazon-EKS-Add-ons durchführen, entscheiden Sie sich dafür, die vorhandenen Einstellungen als Konfliktlösungsoption zu überschreiben. Wenn Sie weitere benutzerdefinierte Einstellungen für die Bereitstellung 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` und höher sowie `v1.10.1-eksbuild.6` und höher legt die CoreDNS-Bereitstellung `readinessProbe` für die Verwendung des `/ready`-Endpunkts fest. 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` und höher sowie `v1.10.1-eksbuild.4` und höher können Sie das `PodDisruptionBudget` ändern. 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 finden Sie unter `PodDisruptionBudgets` Specifying [a PodDisruptionBudget](https://kubernetes.io/docs/tasks/run-application/configure-pdb/#specifying-a-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` auf `node-role.kubernetes.io/control-plane:NoSchedule`, um sie an KEP 2067 anzupassen. *Weitere Informationen zu KEP 2067 finden Sie unter [KEP-2067: Rename the kubeadm „master“ -Label and taint in den Kubernetes Enhancement](https://github.com/kubernetes/enhancements/tree/master/keps/sig-cluster-lifecycle/kubeadm/2067-rename-master-label-taint#renaming-the-node-rolekubernetesiomaster-node-taint) Proposals () on. KEPs* GitHub
In den EKS-Add-On-Versionen `v1.8.7-eksbuild.8` und höher `v1.9.3-eksbuild.9` und höher sind beide Toleranzen so eingestellt, dass sie mit jeder Kubernetes-Version kompatibel sind.
+ In den EKS-Add-On-Versionen `v1.9.3-eksbuild.11` und `v1.10.1-eksbuild.7` und höher legt die CoreDNS-Bereitstellung einen Standardwert für `topologySpreadConstraints` fest. Der Standardwert stellt sicher, dass die CoreDNS-Pods über die Availability Zones verteilt werden, wenn 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
```
### Überlegungen zum CoreDNS `v1.11` Upgrade
+ In EKS-Add-On-Versionen `v1.11.1-eksbuild.4` und höher basiert das Container-Image auf einem [minimalen Basis-Image](https://gallery.ecr.aws/eks-distro-build-tooling/eks-distro-minimal-base), das von Amazon EKS Distro verwaltet wird, minimale Pakete enthält und keine Shells hat. Weitere Informationen finden Sie unter [Amazon-EKS-Distro](https://distro.eks.amazonaws.com/). Die Verwendung und Fehlerbehebung des CoreDNS-Images bleibt unverändert.