**Contribuisci a migliorare questa pagina**
Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Per contribuire a questa guida per l'utente, scegli il GitHub link **Modifica questa pagina** nel riquadro destro di ogni pagina.
Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Gestione di CoreDNS per DNS nei cluster Amazon EKS
**Suggerimento**
Con la modalità automatica di Amazon EKS, non devi installare o aggiornare componenti aggiuntivi di rete. Auto Mode include funzionalità di pod networking e bilanciamento del carico.
Per ulteriori informazioni, consulta [Automate cluster infrastructure with EKS Auto Mode](automode.md).
CoreDNS è un server DNS flessibile ed estensibile che può fungere da cluster DNS Kubernetes. Quando si avvia un cluster Amazon EKS con almeno un nodo, due repliche dell’immagine CoreDNS vengono distribuite per impostazione predefinita, indipendentemente dal numero di nodi distribuiti nel cluster. I contenitori CoreDNS forniscono la risoluzione dei nomi per tutti i pod del cluster. I pod CoreDNS possono essere distribuiti ai nodi Fargate se il cluster include un [profilo Fargate](fargate-profile.md) con un namespace che corrisponde al namespace del `deployment` CoreDNS. Per ulteriori informazioni su CoreDNS, consultare [Utilizzo di CoreDNS per l’individuazione dei servizi](https://kubernetes.io/docs/tasks/administer-cluster/coredns/) nella documentazione Kubernetes.
## Versioni di CoreDNS
La tabella seguente elenca la versione più recente del componente aggiuntivo di Amazon EKS disponibile per ogni versione di Kubernetes.
| Versione di Kubernetes | Versione di CoreDNS |
| --- | --- |
| 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 |
**Importante**
Se gestisci autonomamente questo componente aggiuntivo, le versioni nella tabella potrebbero non essere le stesse di quelle autogestite disponibili. Per ulteriori informazioni sull’aggiornamento del componente aggiuntivo del tipo autogestito, consulta [Aggiornamento del componente aggiuntivo CoreDNS autogestito di Amazon EKS](coredns-add-on-self-managed-update.md).
## Considerazioni importanti sull’aggiornamento di CoreDNS
+ Gli aggiornamenti CoreDNS utilizzano PodDisruptionBudget un 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:
+ Quando esegui l’aggiornamento del componente aggiuntivo Amazon EKS, scegli di sovrascrivere le impostazioni esistenti come opzione di risoluzione dei conflitti. Se hai effettuato altre impostazioni personalizzate su Implementazione, assicurati di eseguire il backup delle impostazioni prima dell’aggiornamento in modo da poter riapplicare le altre impostazioni personalizzate dopo l’aggiornamento.
+ Rimuovi `PodDisruptionBudget` esistente e riprova a eseguire l’aggiornamento.
+ 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 [Specificare a nella documentazione di Kubernetes PodDisruptionBudget](https://kubernetes.io/docs/tasks/run-application/configure-pdb/#specifying-a-poddisruptionbudget).*
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: Rinomina l'etichetta «master» e il taint di kubeadm in Kubernetes](https://github.com/kubernetes/enhancements/tree/master/keps/sig-cluster-lifecycle/kubeadm/2067-rename-master-label-taint#renaming-the-node-rolekubernetesiomaster-node-taint) Enhancement Proposals () on. KEPs* 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
```
### Considerazioni sugli aggiornamenti `v1.11` di CoreDNS
+ 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](https://gallery.ecr.aws/eks-distro-build-tooling/eks-distro-minimal-base) gestita da Amazon EKS Distro, che contiene pacchetti minimi e non ha shell. Per ulteriori informazioni, consulta [Amazon EKS Distro](https://distro.eks.amazonaws.com/). L’utilizzo e la risoluzione dei problemi dell’immagine CoreDNS rimangono gli stessi.