Gestione di CoreDNS per DNS nei cluster Amazon EKS

Gli aggiornamenti di CoreDNS utilizzano un PodDisruptionBudget per aiutare a mantenere la disponibilità del servizio DNS durante il processo di aggiornamento.

Per migliorare la stabilità e la disponibilità di Implementazione di CoreDNS, le versioni v1.9.3-eksbuild.6 e successive e v1.10.1-eksbuild.3 vengono distribuite con un PodDisruptionBudget. Se hai implementato un PodDisruptionBudget esistente, l’aggiornamento a queste versioni potrebbe non riuscire. Se l’aggiornamento non riesce, il problema dovrebbe essere risolto eseguendo una delle seguenti operazioni:

Nelle versioni aggiuntive EKS v1.9.3-eksbuild.3 e successive e v1.10.1-eksbuild.6 e successive, Implementazione di CoreDNS imposta il readinessProbe per utilizzare l’endpoint /ready. Questo endpoint è abilitato nel file di configurazione Corefile per CoreDNS.

Se utilizzi un dispositivo personalizzato Corefile, devi aggiungere il plug-in ready alla configurazione, in modo che l’endpoint /ready sia attivo in CoreDNS e possa essere utilizzato dalla sonda.

Nelle versioni aggiuntive EKS v1.9.3-eksbuild.7 e successive e v1.10.1-eksbuild.4 e successive, è possibile modificare il. PodDisruptionBudget È possibile modificare il componente aggiuntivo e modificare queste impostazioni nelle configurazioni facoltative utilizzando i campi dell’esempio seguente. Questo esempio mostra l’impostazione predefinita PodDisruptionBudget.

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

Puoi impostare maxUnavailable o minAvailable, ma non puoi impostare entrambi sullo stesso PodDisruptionBudget. Per ulteriori informazioni su PodDisruptionBudgets, consulta Specifying a PodDisruptionBudget nella documentazione di Kubernetes.

Tieni presente che, se imposti enabled su false, il PodDisruptionBudget non viene rimosso. Dopo aver impostato questo campo su false, è necessario eliminare l’oggetto PodDisruptionBudget. Allo stesso modo, se modifichi il componente aggiuntivo per utilizzarne una versione precedente (esegui il downgrade del componente aggiuntivo) dopo l’aggiornamento a una versione con un PodDisruptionBudget, questo non viene rimosso PodDisruptionBudget. Esegui il seguente comando per eliminare il PodDisruptionBudget:

kubectl delete poddisruptionbudget coredns -n kube-system

Nelle versioni dei componenti aggiuntivi di EKS v1.10.1-eksbuild.5 e successive, modifica la tolleranza predefinita da node-role.kubernetes.io/master:NoSchedule a node-role.kubernetes.io/control-plane:NoSchedule per conformarla a KEP 2067. Per ulteriori informazioni su KEP 2067, consulta KEP-2067: Rename the kubeadm "master" label and taint in Kubernetes Enhancement Proposals (KEPs) su GitHub.

Nelle versioni dei componenti aggiuntivi di EKS v1.8.7-eksbuild.8 e successive e v1.9.3-eksbuild.9 e successive, entrambe le tolleranze sono impostate per essere compatibili con tutte le versioni di Kubernetes.

Nelle versioni aggiuntive EKS v1.9.3-eksbuild.11 e v1.10.1-eksbuild.7 e successive, l’implementazione di CoreDNS imposta un valore predefinito per topologySpreadConstraints. Il valore predefinito garantisce che i pod CoreDNS siano distribuiti tra le zone di disponibilità se sono disponibili nodi in più zone di disponibilità. Puoi impostare un valore personalizzato che verrà utilizzato al posto di quello predefinito. Il valore predefinito è riportato di seguito:

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

Nelle versioni v1.11.1-eksbuild.4 e successive del componente aggiuntivo di EKS, l’immagine del container è basata su un’immagine di base minima gestita da Amazon EKS Distro, che contiene pacchetti minimi e non ha shell. Per ulteriori informazioni, consulta Amazon EKS Distro. L’utilizzo e la risoluzione dei problemi dell’immagine CoreDNS rimangono gli stessi.