El sistema de nombres de dominio (DNS, por sus siglas en inglés) es un sistema que asocia varios tipos de información (como las direcciones IP) con nombres fáciles de recordar. De forma predeterminada, la mayoría de los clústeres de Kubernetes configuran automáticamente un servicio DNS interno para proporcionar un mecanismo ligero para el descubrimiento de servicios. La detección de servicios integrada permite que las aplicaciones se encuentren y comuniquen entre sí de forma más sencilla en los clústeres de Kubernetes, incluso cuando se crean, eliminan o cambian de nodo los pods y servicios.
Los detalles relacionados con la implementación del servicio DNS de Kubernetes han cambiado en las últimas versiones de Kubernetes. En este artículo, veremos las versiones kube-dns y CoreDNS del servicio DNS de Kubernetes. Revisaremos cómo funcionan y los registros DNS que genera Kubernetes.
Para comprender mejor el concepto de DNS antes de comenzar, consulte Introducción a terminología, componentes y conceptos relacionados con DNS. En el caso de los temas de Kubernetes con los que no esté familiarizado, puede consultar Introducción a Kubernetes.
Antes de la versión 1.11 de Kubernetes, el servicio DNS de Kubernetes se basaba en kube-dns. En la versión 1.11 se introdujo CoreDNS para solucionar algunos problemas de seguridad y estabilidad de kube-dns.
Independientemente del software que maneje los registros DNS reales, ambas implementaciones funcionan de manera similar:
Se crea un servicio llamado kube-dns
y uno o más pods.
El servicio kube-dns
escucha los eventos de service y endpoint de la API de Kubernetes y actualiza sus registros DNS según sea necesario. Estos eventos se activan cuando crea, actualiza o elimina servicios de Kubernetes y sus pods asociados.
kubelet fija cada opción /etc/resolv.conf
nameserver
de un pod nuevo en el IP del clúster del servicio kube-dns
, con las opciones search
adecuadas para permitir el uso de nombres de host más cortos:
nameserver 10.32.0.10
search namespace.svc.cluster.local svc.cluster.local cluster.local
options ndots:5
Las aplicaciones que se ejecutan en contenedores pueden resolver nombres de host como example-service.namespace
en las direcciones IP de clúster correctas.
El registro DNS completo A
de un servicio de Kubernetes tendrá el aspecto del siguiente ejemplo:
service.namespace.svc.cluster.local
Un pod tendría un registro en este formato y reflejaría la dirección IP real del pod:
10.32.0.125.namespace.pod.cluster.local
Además, se crean registros SRV
para los puertos con nombre de un servicio de Kubernetes:
_port-name._protocol.service.namespace.svc.cluster.local
Todo esto da como resultado un mecanismo incorporado de descubrimiento de servicios basado en DNS, en el cual su aplicación o microservicio puede orientarse a un nombre de host simple y uniforme para acceder a otros servicios o pods del clúster.
Debido a los sufijos de dominio de búsqueda que aparecen en el archivo resolv.conf,
a menudo no necesitará utilizar el nombre de host completo para establecer contacto con otro servicio. Si se orienta a un servicio en el mismo espacio de nombres, puede utilizar solo el nombre del servicio para contactarlo:
other-service
Si el servicio está en un espacio de nombres diferente, añádalo a la consulta:
other-service.other-namespace
Si se orienta a un pod, deberá usar al menos lo siguiente:
pod-ip.other-namespace.pod
Como hemos visto en el archivo resolv.conf
predeterminado, solo los sufijos .svc
se completan automáticamente. Por ello, debe asegurarse de especificar todo hasta .pod
.
Ahora que vimos los usos prácticos del servicio DNS de Kubernetes, vamos a repasar algunos detalles sobre las dos implementaciones diferentes.
Como se indicó en la sección anterior, en la versión 1.11 de Kubernetes se introdujo un nuevo software para gestionar el servicio kube-dns
. Los motivos que impulsaron el cambio fueron el aumento del rendimiento y de la seguridad del servicio. Veamos primero la implementación original de kube-dns
.
El servicio kube-dns
anterior a la versión 1.11 de Kubernetes se compone de tres contenedores que se ejecutan en un pod kube-dns
en el espacio de nombres kube-system
. Los tres contenedores son:
Las vulnerabilidades de seguridad en Dnsmasq y los problemas de rendimiento de ajuste de escala con SkyDNS llevaron a la creación de un sistema de reemplazo: CoreDNS.
A partir de la versión 1.11 de Kubernetes, un nuevo servicio DNS de Kubernetes, CoreDNS pasó a la categoría Accesible al mercado. Esto significa que está listo para su uso en producción y será el servicio DNS de clúster por defecto para muchas herramientas de instalación y proveedores de Kubernetes gestionados.
CoreDNS es un proceso único, escrito en Go, que abarca toda la funcionalidad del sistema anterior. Un único contenedor resuelve y almacena en caché las consultas del DNS, responde a las comprobaciones de estado y proporciona métricas.
Además de resolver problemas de rendimiento y seguridad, CoreDNS corrige algunos otros errores menores y añade algunas características nuevas:
autopath
puede mejorar los tiempos de respuesta del DNS cuando se resuelven nombres de host externos, ya que es más inteligente respecto de la iteración a través de cada uno de los sufijos de dominio de búsqueda que aparecen en resolv.conf
.10.32.0.125.namespace.pod.cluster.local
siempre se resolvería a 10.32.0.125
, incluso si el pod no existe realmente. CoreDNS tiene un modo de “pods verificados” que solo se resolverá con éxito si existe un pod con el IP correcto y en el espacio de nombres adecuado.Para obtener más información sobre CoreDNS y en la forma en que se diferencia de los kube-dns, puede leer el anuncio de accesibilidad al mercado de CoreDNS de Kubernetes.
Los operadores de Kubernetes a menudo quieren personalizar la forma en que sus pods y contenedores resuelven determinados dominios personalizados, o necesitan ajustar los servidores de nombres de cabecera o los sufijos de dominio de búsqueda configurados en resolv.conf
. Puede hacerlo con la opción dnsConfig
de las especificaciones de su pod:
apiVersion: v1
kind: Pod
metadata:
namespace: example
name: custom-dns
spec:
containers:
- name: example
image: nginx
dnsPolicy: "None"
dnsConfig:
nameservers:
- 203.0.113.44
searches:
- custom.dns.local
Al actualizar esta configuración, se reescribirá el archivo resolv.conf
de un pod para activar los cambios. La configuración se asigna directamente a las opciones estándares resolv.conf,
, por lo que la configuración anterior creará un archivo con las líneas 203.0.113.44
y search custom.dns.local
.
En este artículo, abarcamos aspectos básicos acerca de lo que el servicio DNS de Kubernetes proporciona a los desarrolladores, mostramos algunos ejemplos de registros DNS para servicios y pods, abordamos la implementación del sistema en las diferentes versiones de Kubernetes y destacamos algunas opciones de configuración adicionales disponibles para personalizar la forma en que sus pods resuelven las consultas de DNS.
Para obtener más información sobre el servicio DNS de Kubernetes, consulte la documentación oficial sobre DNS de Kubernetes para servicios y pods.
Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
Sign up for Infrastructure as a Newsletter.
Working on improving health and education, reducing inequality, and spurring economic growth? We'd like to help.
Get paid to write technical tutorials and select a tech-focused charity to receive a matching donation.