CoreDNS für DNS in Amazon EKS-Clustern verwalten

Um die Stabilität und Verfügbarkeit des CoreDNS-Einsatzes zu verbessern, v1.10.1-eksbuild.3 werden Versionen v1.9.3-eksbuild.6 und höher mit einem bereitgestellt. PodDisruptionBudget Wenn Sie eine bestehende Version bereitgestellt habenPodDisruptionBudget, 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 v1.10.1-eksbuild.6 und höher legt das CoreDNS-Deployment fest, readinessProbe dass der Endpunkt verwendet wird/ready. Dieser Endpunkt ist in der Corefile Konfigurationsdatei für CoreDNS aktiviert.

Wenn Sie ein benutzerdefiniertes Plugin verwendenCorefile, müssen Sie das ready Plugin zur Konfiguration hinzufügen, sodass der /ready Endpunkt in CoreDNS aktiv ist, damit der Test ihn verwenden 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 festlegenminAvailable, aber Sie können nicht beide in einem einzigen festlegen. PodDisruptionBudget Weitere Informationen zu PodDisruptionBudgets finden Sie unter Angabe von a PodDisruptionBudget in der Kubernetes-Dokumentation.

Beachten Sie, dass, wenn Sie enabled auf einstellenfalse, der PodDisruptionBudget nicht entfernt wird. Nachdem Sie dieses Feld auf false gesetzt haben, müssen Sie das PodDisruptionBudget-Objekt löschen. Ebenso wird das Add-on PodDisruptionBudget nicht entfernt, wenn Sie das Add-on nach dem Upgrade auf eine Version mit einem so bearbeiten, dass es eine ältere Version des Add-ons verwendet (das Add-On herabstufen). PodDisruptionBudget 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 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 EKS-Add-On-Versionen v1.9.3-eksbuild.11 v1.10.1-eksbuild.7 und höher legt das CoreDNS-Deployment einen Standardwert für fest. topologySpreadConstraints Der Standardwert stellt sicher, dass die CoreDNS-Pods über die Availability Zones verteilt sind, 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. Es enthält nur minimale Pakete und keine Shells. Weitere Informationen finden Sie unter Amazon-EKS-Distro. Die Verwendung und Fehlerbehebung des CoreDNS-Images bleibt unverändert.