CoreDNS für DNS in Amazon EKS-Clustern verwalten

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:

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 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 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

In EKS-Add-On-Versionen v1.11.1-eksbuild.4 und höher basiert das Container-Image auf einem minimalen Basis-Image, das von Amazon EKS Distro verwaltet wird, minimale Pakete enthält und keine Shells hat. Weitere Informationen finden Sie unter Amazon-EKS-Distro. Die Verwendung und Fehlerbehebung des CoreDNS-Images bleibt unverändert.