Introducción al servicio DNS de Kubernetes

Introducción

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.

¿Qué proporciona el servicio DNS de 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:

  resolv.conf

  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.

Ejemplo de registros DNS de Kubernetes

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.

Búsqueda de dominios y resolución de nombres de host más cortos

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.

Detalles de las implementaciones del DNS de Kubernetes

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.

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:

• kube-dns: contenedor que ejecuta SkyDNS, que realiza la resolución de consultas DNS.
• dnsmasq: solucionador de DNS popular y ligero, y caché que almacena las respuestas de SkyDNS.
• sidecar: contenedor sidecar que maneja la generación de informes de métricas y responde a los chequeos de salud para el servicio.

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.

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:

• Se corrigieron algunos problemas de incompatibilidad entre el uso de stubDomains y servicios externos.
• CoreDNS puede mejorar el balanceo de carga de round-robin basado en DNS aleatorizando el orden en el que proporciona determinados registros.
• Una función denominada 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.
• Con kube-dns 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.

Opciones de configuración adicionales

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.

Conclusión

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.