Usa kube-dns

En esta página, se describe cómo Google Kubernetes Engine (GKE) implementa el descubrimiento de servicios con kube-dns, el proveedor predeterminado de DNS para clústeres de GKE.

Para los clústeres Autopilot, no puedes modificar la configuración predeterminada de kube-dns.

Arquitectura

Cuando creas un clúster, GKE implementa Pods de kube-dns en el espacio de nombres kube-system de forma automática. Los Pods acceden a la implementación de kube-dns a través del servicio correspondiente que agrupa los Pods de kube-dns y les proporciona una sola dirección IP (ClusterIP). De forma predeterminada, todos los Pods de un clúster usan este servicio para resolver consultas de DNS. En el siguiente diagrama, se muestra la relación entre los Pods y el servicio de kube-dns.

Relación entre los Pods y el servicio de kube-dns

kube-dns escala para satisfacer las demandas del DNS del clúster. Este escalamiento es controlado por kube-dns-autoscaler, un Pod que se implementa de forma predeterminada en todos los clústeres de GKE. kube-dns-autoscaler ajusta la cantidad de réplicas en la implementación de kube-dns según la cantidad de nodos y núcleos del clúster.

kube-dns admite hasta 1,000 extremos por servicio sin interfaz gráfica.

Cómo se configura el DNS del pod

El kubelet que se ejecuta en cada nodo configura el etc/resolv.conf del Pod para usar el ClusterIP del servicio de kube-dns. En la siguiente configuración de ejemplo, se muestra que la dirección IP del servicio de kube-dns es 10.0.0.10. Esta dirección IP es diferente en otros clústeres.

nameserver 10.0.0.10
search default.svc.cluster.local svc.cluster.local cluster.local c.my-project-id.internal google.internal
options ndots:5

kube-dns es el servidor de nombres autorizado para el dominio del clúster (cluster.local) y resuelve los nombres externos de forma recurrente. Los nombres cortos que no están completamente calificados, como myservice, primero se completan con rutas de acceso de búsqueda local.

Agrega agentes de resolución personalizados para dominios stub

Puedes modificar ConfigMap para kube-dns a fin de establecer dominios stub como parte de la infraestructura de DNS dentro de los clústeres.

Los dominios stub te permiten configurar agentes de resolución por dominio personalizados para que kube-dns reenvíe las solicitudes de DNS a servidores DNS ascendentes específicos cuando se resuelvan estos dominios.

En el siguiente manifiesto de ConfigMap de ejemplo para kube-dns, se incluye una configuración stubDomains que establece agentes de resolución personalizados para el dominio example.com.

apiVersion: v1
kind: ConfigMap
metadata:
  labels:
    addonmanager.kubernetes.io/mode: EnsureExists
  name: kube-dns
  namespace: kube-system
data:
  stubDomains: |
    {
      "example.com": [
        "8.8.8.8",
        "8.8.4.4",
        "1.1.1.1",
        "1.0.0.1"
      ]
    }

Ejecuta el siguiente comando para abrir un editor de texto:

kubectl edit configmap kube-dns -n kube-system

Reemplaza el contenido del archivo por el manifiesto y, luego, sal del editor de texto para aplicar el manifiesto al clúster.

Nameservers ascendentes

Si modificas el ConfigMap de kube-dns para incluir upstreamNameservers, kube-dns reenvía todas las solicitudes de DNS, excepto *.cluster.local a esos servidores. Esto incluye metadata.internal y *.google.internal, que el servidor ascendente no puede resolver.

Si habilitas la federación de identidades para cargas de trabajo para GKE o cualquier carga de trabajo que dependa de la resolución metadata.internal para retener la resolución de nombres *.internal, agrega stubDomain al ConfigMap.

data:
  stubDomains: |
    {
      "internal": [
        "169.254.169.254"
      ]
    }
  upstreamNameservers: |
    ["8.8.8.8"]

Problemas conocidos

Límite del dominio de búsqueda

Existe un límite de 6 dominios de búsqueda de DNS para /etc/resolv.conf. Si defines más de 6 dominios de búsqueda, aparecerá la siguiente advertencia cuando ejecutes el comando kubectl describe pod:

Search Line limits were exceeded, some search paths have been omitted, the applied search line is: default.svc.cluster.local svc.cluster.local cluster.local c.<project ID>.internal google.internal

Esta advertencia se registra en Cloud Logging en la sección de registros del contenedor.

Para resolver este problema, quita las rutas de búsqueda adicionales de la configuración.

Considera el límite de upstreamNameservers

Kubernetes impone un límite de hasta tres valores upstreamNameservers. Si defines más de tres upstreamNameservers, verás el siguiente error en Cloud Logging en los registros de implementación kube-dns:

Invalid configuration: upstreamNameserver cannot have more than three entries (value was &TypeMeta{Kind:,APIVersion:,}), ignoring update

Cuando esto sucede, kube-dns se comporta como si no tuviera upstreamNameservers configurado. Para resolver este problema, quita el upstreamNameservers adicional de la configuración.

Limitaciones de rendimiento con kube-dns

Si tienes una latencia alta con búsquedas de DNS o fallas de resolución de DNS con el proveedor de kube-dns predeterminado, esto podría deberse a lo siguiente:

  • Realiza búsquedas de DNS frecuentes en tu carga de trabajo
  • Implementa una mayor densidad de Pods por nodo.
  • Ejecuta kube-dns en VMs puntuales o interrumpibles, lo que puede provocar eliminaciones inesperadas de nodos y problemas de resolución de DNS posteriores

Para mejorar los tiempos de búsqueda de DNS, puedes elegir una de las siguientes opciones:

  • Evita ejecutar componentes críticos del sistema, como kube-dns en VMs interrumpibles o interrumpibles. El uso de VMs Spot o interrumpibles para DNS puede causar fallas e interrumpir tu clúster.
  • Como prácticas recomendadas, crea al menos un grupo de nodos compuesto por VMs estándar (interrumpibles o no Spot) para alojar componentes críticos del sistema, como kube-dns. Para garantizar que las cargas de trabajo críticas solo se programen en el grupo de nodos confiable que impida que se ejecuten en VMs Spot o interrumpibles, puedes usar taints y tolerancias para VMs Spot.
  • Habilitar NodeLocal DNSCache
  • Scale up kube-dns.
  • Asegúrate de que tu aplicación use funciones basadas en dns.resolve* en lugar de la función basada en dns.lookup, ya que dns.lookup es síncrona. Las funciones dns.resolve* siempre realizan una consulta de DNS asíncrona en la red.

Registros DNS de servicio

kube-dns solo crea registros DNS para los servicios que tienen extremos{track-name="k8sLink" track-type="concept"}.

TTL grande de servidores ascendentes DNS

Si kube-dns recibe una respuesta de DNS de un agente de resolución de DNS ascendente con un TTL grande o “infinito”, mantiene este valor de TTL para la entrada de DNS en la caché. La entrada nunca vence y podría crear una discrepancia entre la entrada y la dirección IP real resuelta para el nombre de TTL.

GKE resuelve este problema en las siguientes versiones del plano de control mediante la configuración de un valor de TTL máximo en 30 segundos para cualquier respuesta de DNS que tenga un TTL superior a 30 segundos:

  • 1.21.14-gke.9100
  • 1.22.15-gke.2100
  • 1.23.13-gke.500
  • 1.24.7-gke.500
  • 1.25.2-gke.500 o superior

Este comportamiento es similar a NodeLocal DNSCache.

¿Qué sigue?