**Ayude a mejorar esta página**
Para contribuir a esta guía del usuario, elija el enlace **Edit this page on GitHub** que se encuentra en el panel derecho de cada página.
# Administración de CoredNS para DNS en clústeres de Amazon EKS
**sugerencia**
Con el modo automático de Amazon EKS, no necesita instalar ni actualizar los complementos de red. El modo automático ofrece capacidades para la conexión en red de pods y el equilibrio de carga.
Para obtener más información, consulte [Automatización de la infraestructura de clústeres con el modo automático de EKS](automode.md).
CoreDNS es un servidor de DNS flexible y extensible que puede servir como el DNS del clúster de Kubernetes. Al lanzar un clúster de Amazon EKS con al menos un nodo, se implementan dos réplicas de la imagen de CoreDNS de forma predeterminada, independientemente del número de nodos implementados en el clúster. Los pods de CoreDNS proporcionan resolución de nombres para todos los pods del clúster. Los pods de CoreDNS se pueden implementar en los nodos de Fargate si su clúster incluye un [perfil de Fargate](fargate-profile.md) con un espacio de nombres que coincida con el espacio de nombres para la `deployment` de CoreDNS. A fin de obtener más información sobre CoreDNS, consulte [Uso de CoreDNS para la detección de servicios](https://kubernetes.io/docs/tasks/administer-cluster/coredns/) en la documentación de Kubernetes.
## Versiones de CoreDNS
En la siguiente tabla se muestra la versión más reciente del tipo de complemento de Amazon EKS para cada versión de Kubernetes.
| Versión de Kubernetes | Versión de 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**
Si administra este complemento, es posible que las versiones de la tabla no sean las mismas que las versiones autoadministradas disponibles. Para obtener más información acerca de la actualización de complementos autoadministrados, consulte [Actualización del complemento autoadministrado CoreDNS de Amazon EKS](coredns-add-on-self-managed-update.md).
## Consideraciones importantes sobre la actualización de CoreDNS
+ Las actualizaciones de CoreDNS utilizan un PodDisruptionBudget para ayudar a mantener la disponibilidad del servicio DNS durante el proceso de actualización.
+ Para mejorar la estabilidad y la disponibilidad de la implementación de CoreDNS, la versión `v1.9.3-eksbuild.6` y posteriores y `v1.10.1-eksbuild.3` se implementan con `PodDisruptionBudget`. Si ha implementado un `PodDisruptionBudget` existente, la actualización a estas versiones podría fallar. Si se produce un error en la actualización, se solucionará el problema al completar una de las siguientes tareas:
+ Al actualizar el complemento Amazon EKS, elija anular la configuración existente como opción de resolución de conflictos. Si ha hechos otros ajustes personalizados en la implementación, asegúrese de hacer una copia de seguridad de los ajustes antes de efectuar la actualización para poder volver a aplicar los demás ajustes personalizados después de la actualización.
+ Elimine el `PodDisruptionBudget` que ya tiene y vuelva a intentar la actualización.
+ En la versión `v1.9.3-eksbuild.3` y posteriores del complemento de EKS y `v1.10.1-eksbuild.6` y posteriores, la implementación de CoreDNS establece `readinessProbe` para usar el punto de conexión `/ready`. Este punto de conexión se habilita en el archivo de configuración `Corefile` de CoreDNS.
Si utiliza un `Corefile` personalizado, debe agregar el complemento `ready` a la configuración, para que el punto de conexión `/ready` esté activo en CoreDNS de modo que lo pueda utilizar la sonda.
+ En las versiones del complemento de EKS `v1.9.3-eksbuild.7` y posteriores, y `v1.10.1-eksbuild.4` y posteriores, puede cambiar el objeto `PodDisruptionBudget`. Puede editar el complemento y cambiar esta configuración en **Valores de configuración opcionales** mediante los campos del siguiente ejemplo. En este ejemplo se muestra el objeto `PodDisruptionBudget` predeterminado.
```
{
"podDisruptionBudget": {
"enabled": true,
"maxUnavailable": 1
}
}
```
Puede establecer `maxUnavailable` o `minAvailable`, pero no puede establecer ambos en un solo `PodDisruptionBudget`. Para obtener más información sobre `PodDisruptionBudgets`, consulte [Especificación de un PodDisruptionBudget](https://kubernetes.io/docs/tasks/run-application/configure-pdb/#specifying-a-poddisruptionbudget) en la *documentación de Kubernetes*.
Tenga en cuenta que si establece `enabled` como `false`, no se elimina `PodDisruptionBudget`. Después de establecer este campo como `false`, debe eliminar el objeto `PodDisruptionBudget`. Del mismo modo, si edita el complemento para que utilice una versión anterior (es decir, desactualiza el complemento) después de actualizarlo a una versión con un objeto `PodDisruptionBudget`, no se elimina `PodDisruptionBudget`. Para eliminar el objeto `PodDisruptionBudget`, puede ejecutar el siguiente comando:
```
kubectl delete poddisruptionbudget coredns -n kube-system
```
+ En las versiones complementarias de EKS `v1.10.1-eksbuild.5` y posteriores, cambie la tolerancia predeterminada de `node-role.kubernetes.io/master:NoSchedule` a `node-role.kubernetes.io/control-plane:NoSchedule` para cumplir con el KEP 2067. Para obtener más información sobre KEP 2067, consulte[KEP-2067: Rename the kubeadm "master" label and taint](https://github.com/kubernetes/enhancements/tree/master/keps/sig-cluster-lifecycle/kubeadm/2067-rename-master-label-taint#renaming-the-node-rolekubernetesiomaster-node-taint) en *Kubernetes Enhancement Proposals (KEPs)* en GitHub.
En las versiones del complemento de EKS `v1.8.7-eksbuild.8` y posteriores y `v1.9.3-eksbuild.9` y posteriores, ambas tolerancias están configuradas para que sean compatibles con todas las versiones de Kubernetes.
+ En las versiones del complemento de EKS `v1.9.3-eksbuild.11` y `v1.10.1-eksbuild.7` y posteriores, la implementación de CoreDNS establece un valor predeterminado para `topologySpreadConstraints`. El valor predeterminado garantiza que los pods de CoreDNS se distribuyan entre las zonas de disponibilidad si hay nodos en varias zonas de disponibilidad disponibles. Puede establecer un valor personalizado que se utilizará en lugar del valor predeterminado. El valor predeterminado es el siguiente:
```
topologySpreadConstraints:
- maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: ScheduleAnyway
labelSelector:
matchLabels:
k8s-app: kube-dns
```
### Consideraciones sobre la actualización de CoreDNS `v1.11`
+ En las versiones complementarias de EKS `v1.11.1-eksbuild.4` y posteriores, la imagen del contenedor está basada en una [imagen básica mínima](https://gallery.ecr.aws/eks-distro-build-tooling/eks-distro-minimal-base) mantenida por Amazon EKS Distro, el cual contiene paquetes mínimos y no contiene intérpretes de comandos. Para obtener más información, consulte [¿Qué es Amazon EKS Distro?](https://distro.eks.amazonaws.com/) El uso y la solución de problemas de la imagen de CoreDNS siguen siendo los mismos.