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

Zur Verbesserung der Stabilität und Verfügbarkeit des CoreDNS Deployment, Versionen v1.9.3-eksbuild.6 und höher und v1.10.1-eksbuild.3 werden mit einem bereitgestelltPodDisruptionBudget. 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:

In EKS Zusatzversionen v1.9.3-eksbuild.3 und späteren Versionen v1.10.1-eksbuild.6 und immer später CoreDNS Deployment legt festreadinessProbe, dass der /ready Endpunkt verwendet wird. Dieser Endpunkt ist in der Corefile Konfigurationsdatei für aktiviert CoreDNS.

Wenn Sie ein benutzerdefiniertes Plugin verwendenCorefile, müssen Sie das ready Plugin zur Konfiguration hinzufügen, damit der /ready Endpunkt in aktiv ist CoreDNS damit die Sonde verwendet werden kann.

In EKS Zusatzversionen 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 finden Sie PodDisruptionBudgets unter Spezifizieren von a PodDisruptionBudget im 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, sodass node-role.kubernetes.io/control-plane:NoSchedule sie KEP 2067 entspricht. Weitere Informationen zu KEP 2067 finden Sie unter KEP-2067: Benennen Sie das kubeadm „master“ -Label und Taint um in den Kubernetes Enhancement Proposals () auf 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 allen kompatibel sind Kubernetes Version.

In EKS Add-On-Versionen v1.9.3-eksbuild.11 v1.10.1-eksbuild.7 und später CoreDNS Deployment legt einen Standardwert für festtopologySpreadConstraints. Der Standardwert stellt sicher, dass CoreDNS Pods sind auf die Availability Zones verteilt, 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

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 Das Bild bleibt gleich.