Acerca de Cloud DNS para GKE

En este documento, se te ayuda a decidir si Cloud DNS para GKE es la solución de DNS adecuada para tu clúster. Puedes usar Cloud DNS para controlar la resolución de DNS de Pods y Services como alternativa a los proveedores de DNS alojados en clústeres, como kube-dns.

En el caso de los clústeres de Autopilot, Cloud DNS ya es el proveedor de DNS predeterminado. En el caso de los clústeres de Standard, puedes cambiar de kube-dns a Cloud DNS.

Este documento está dirigido a los usuarios de GKE, incluidos los desarrolladores, los administradores y los arquitectos. Para obtener más información sobre los roles comunes y las tareas de ejemplo en Google Cloud, consulta Roles y tareas comunes del usuario de GKE.

En este documento, se supone que estás familiarizado con los siguientes conceptos:

Cómo funciona Cloud DNS para GKE

Cuando usas Cloud DNS como proveedor de DNS para GKE, Cloud DNS proporciona resolución de DNS de Pods y Services sin necesidad de un proveedor de DNS alojado en el clúster. Los registros DNS de Pods y Services se aprovisionan de forma automática en Cloud DNS para los Services de nombres externos, sin interfaz gráfica y dirección IP del clúster.

Cloud DNS admite la especificación de DNS de Kubernetes completa y proporciona resolución para los registros A, AAAA, SRV y PTR para los servicios dentro de un clúster de GKE. Los registros PTR se implementan con reglas de política de respuesta. Usar Cloud DNS como proveedor de DNS para GKE ofrece los siguientes beneficios en comparación con el DNS alojado en el clúster:

  • Reducción de la sobrecarga: Elimina la necesidad de administrar servidores DNS alojados en clústeres. Cloud DNS no requiere escalamiento, supervisión ni administración manual de instancias de DNS, ya que es un servicio completamente administrado.
  • Alta escalabilidad y rendimiento: Resuelve las consultas de forma local para cada nodo de GKE con el objetivo de proporcionar una resolución de DNS de baja latencia y alta escalabilidad. Para obtener un rendimiento óptimo, en especial en clústeres a gran escala, considera habilitar NodeLocal DNSCache, que proporciona una capa de almacenamiento en caché adicional en el nodo.
  • Integración en Google Cloud Observability: habilita la supervisión y el registro de DNS. Para obtener más información, consulta Inhabilita y habilita el registro para zonas administradas privadas.

Arquitectura

Cuando Cloud DNS es el proveedor de DNS para GKE, un controlador se ejecuta como un Pod administrado por GKE. Este Pod se ejecuta en los nodos del plano de control de tu clúster y sincroniza los registros DNS del clúster en una zona de DNS privado administrada.

En el siguiente diagrama, se muestra cómo el plano de control y el plano de datos de Cloud DNS resuelven los nombres de clústeres:

Un Pod solicita la dirección IP de un servicio mediante Cloud DNS.
Resuelve nombres de clústeres con Cloud DNS

En el diagrama, el backend del servicio selecciona los Pods de backend en ejecución. El clouddns-controller crea un registro DNS para el backend del Service.

El frontend del Pod envía una solicitud de DNS para resolver la dirección IP del servicio llamado backend al servidor de metadatos local de Compute Engine en 169.254.169.254. El servidor de metadatos se ejecuta de forma local en el nodo y envía errores de caché a Cloud DNS.

Cloud DNS resuelve el nombre del servicio en diferentes direcciones IP según el tipo de servicio de Kubernetes. En el caso de los objetos Service ClusterIP, Cloud DNS resuelve el nombre del Service en su dirección IP virtual. En el caso de los objetos Service sin interfaz gráfica, resuelve el nombre del Service en la lista de direcciones IP de los extremos.

Después de que el Pod frontend resuelve la dirección IP, el Pod puede enviar tráfico al Service backend y a cualquier Pod detrás del Service.

Permisos de DNS

Cloud DNS tiene los siguientes alcances de DNS. Un clúster no puede operar en varios modos a la vez.

  • Permiso del clúster de GKE: los registros DNS solo se pueden resolver en el clúster, lo que equivale al comportamiento de kube-dns. Solo los nodos que se ejecutan en el clúster de GKE pueden resolver los nombres de los objetos Service. De forma predeterminada, los clústeres tienen nombres de DNS que terminan en *.cluster.local. Estos nombres de DNS solo se pueden ver dentro del clúster y no se superponen ni entran en conflicto con los nombres de DNS *.cluster.local para otros clústeres de GKE en el mismo proyecto. Este es el modo predeterminado.
    • Permiso adicional de VPC de Cloud DNS: El permiso adicional de VPC de Cloud DNS es una función opcional que extiende el permiso del clúster de GKE para que los Services sin interfaz gráfica se puedan resolver desde otros recursos en la VPC, como las VMs de Compute Engine o los clientes locales que se conectan a través de Cloud VPN o Cloud Interconnect. Este modo es un modo adicional que se habilita junto con el permiso del clúster. Puedes habilitar o inhabilitar este modo en tu clúster sin afectar el tiempo de actividad del DNS ni las capacidades del permiso del clúster.
  • Permiso de la VPC: Los registros DNS se pueden resolver dentro de toda la VPC. Las VMs de Compute Engine y los clientes locales pueden conectarse a través de Cloud Interconnect o Cloud VPN, y pueden resolver directamente los nombres de los servicios de GKE. Debes configurar un dominio personalizado único para cada clúster, lo que significa que todos los registros DNS del servicio y del Pod son únicos en la VPC. Este modo reduce las dificultades de comunicación entre los recursos de GKE y los que no lo son.

En la siguiente tabla, se enumeran las diferencias entre los permisos de DNS:

Función Permiso del clúster de GKE Permiso adicional de VPC de Cloud DNS Permiso de la VPC
Alcance de la visibilidad de DNS Solo dentro del clúster de GKE Solo clúster, con servicios sin interfaz gráfica que se pueden resolver en la red de VPC Toda la red de VPC
Resolución de servicio sin interfaz gráfica Se puede resolver dentro del clúster Se puede resolver dentro del clúster con el dominio `cluster.local` y en toda la VPC con el sufijo del clúster Se puede resolver dentro del clúster y en la VPC con el sufijo del clúster
Requisito de dominio único No; usa el dominio predeterminado `*.cluster.local` Sí, debes configurar un dominio personalizado único Sí, debes configurar un dominio personalizado único
Configuración Configuración predeterminada, sin pasos adicionales Opcional durante la creación del clúster
Se puede habilitar o inhabilitar en cualquier momento		 Debe configurarse durante la creación del clúster

Recursos de Cloud DNS

Cuando usas Cloud DNS como tu proveedor de DNS para el clúster de GKE, el controlador de Cloud DNS crea recursos en Cloud DNS para tu proyecto. Los recursos que crea GKE dependen del alcance de Cloud DNS.

Alcance Zona de búsqueda directa Zona de búsqueda inversa
Permiso del clúster 1 zona privada por clúster por zona de Compute Engine (en la región) 1 zona de política de respuesta por clúster por zona de Compute Engine (en la región)
Permiso adicional de VPC de Cloud DNS 1 zona privada por clúster por zona de Compute Engine (en la región) por clúster (zona global)
1 con alcance de VPC zona privada por clúster (zona global) 		1 zona de política de respuesta por clúster por zona de Compute Engine (en la región) por clúster (zona global)
1 con alcance de VPC zona de política de respuesta por clúster (zona global)
Permiso de la VPC 1 zona privada por clúster (zona global) 1 zona de política de respuesta por clúster (zona global)

La convención de nombres que se usa para estos recursos de Cloud DNS es la siguiente:

Alcance Zona de búsqueda directa Zona de búsqueda inversa
Permiso del clúster gke-CLUSTER_NAME-CLUSTER_HASH-dns gke-CLUSTER_NAME-CLUSTER_HASH-rp
Permiso adicional de VPC de Cloud DNS gke-CLUSTER_NAME-CLUSTER_HASH-dns para zonas con permiso de clúster
gke-CLUSTER_NAME-CLUSTER_HASH-dns-vpc para zonas con permiso de VPC 		gke-CLUSTER_NAME-CLUSTER_HASH-rp para zonas con permiso de clúster
gke-NETWORK_NAME_HASH-rp para zonas con permiso de VPC
Permiso de la VPC gke-CLUSTER_NAME-CLUSTER_HASH-dns gke-NETWORK_NAME_HASH-rp

Además de las zonas mencionadas en la tabla anterior, el controlador de Cloud DNS crea las siguientes zonas en tu proyecto, según tu configuración:

Configuración de DNS personalizada Tipo de zona Convención de nombres de zonas
Dominio de stub Reenvío (zona global) gke-CLUSTER_NAME-CLUSTER_HASH-DOMAIN_NAME_HASH
Servidores de nombres upstream personalizados Reenvío (zona global) gke-CLUSTER_NAME-CLUSTER_HASH-upstream

Para obtener más información sobre cómo crear dominios de stub personalizados o servidores de nombres ascendentes personalizados, consulta Agrega agentes de resolución personalizados para dominios de stub.

Zonas administradas y zonas de reenvío

En el caso de los clústeres que usan el permiso del clúster para entregar tráfico de DNS interno, el controlador de Cloud DNS crea una zona de DNS administrada en cada zona de Compute Engine de la región a la que pertenece el clúster.

Por ejemplo, si implementas un clúster en la zona us-central1-c, el controlador de Cloud DNS crea una zona administrada en us-central1-a, us-central1-b, us-central1-c y us-central1-f.

Para cada stubDomain de DNS, el controlador de Cloud DNS crea una zona de reenvío.

Cloud DNS procesa cada DNS ascendente con una zona administrada con el nombre de DNS ..

Cuotas

Cloud DNS usa cuotas para limitar la cantidad de recursos que GKE puede crear para las entradas de DNS. Las cuotas y los límites para Cloud DNS pueden ser diferentes de las limitaciones de kube-dns para tu proyecto.

Las siguientes cuotas predeterminadas se aplican a cada zona administrada de tu proyecto cuando usas Cloud DNS para GKE:

Recurso de DNS de Kubernetes Recurso de Cloud DNS correspondiente Cuota
Cantidad de registros DNS Cantidad máxima de bytes por zona administrada 2,000,000 (50 MB como máximo para una zona administrada)
Cantidad de Pods por Service sin interfaz gráfica (IPv4 o IPv6) Cantidad de registros por conjunto de registros de recursos GKE 1.24 a 1.25: 1,000 (IPv4 o IPv6)
GKE 1.26 y versiones posteriores: 3,500 para IPv4 y 2,000 para IPv6
Cantidad de clústeres de GKE en un proyecto Cantidad de políticas de respuesta por proyecto 100
Cantidad de registros PTR por clúster Cantidad de reglas por política de respuesta 100,000

Límites de recursos

Los recursos de Kubernetes que creas por clúster contribuyen a los límites de recursos de Cloud DNS, como se describe en la siguiente tabla:

Límite Contribuye al límite
Conjuntos de registros de recursos por zona administrada Cantidad de servicios más la cantidad de extremos de servicio sin interfaz gráfica con nombres de host válidos por clúster.
Registros por conjunto de registros de recursos Cantidad de extremos por servicio sin interfaz gráfica. No afecta a otros tipos de servicios.
Cantidad de reglas por política de respuesta Por alcance de clúster, cantidad de servicios más extremos de servicio sin interfaz gráfica con nombres de host válidos por clúster. En el alcance de VPC, la cantidad de servicios más la cantidad de extremos sin interfaz gráfica con nombres de host de todos los clústeres de la VPC.

Si deseas obtener más información sobre cómo se crean los registros DNS para Kubernetes, consulta Descubrimiento de servicios basados en DNS de Kubernetes.

Más de un clúster por proyecto de servicio

A partir de las versiones 1.22.3-gke.700 y 1.21.6-gke.1500 de GKE, puedes crear clústeres en varios proyectos de servicio que hagan referencia a una VPC en el mismo proyecto host.

Compatibilidad con dominios de stub personalizados y servidores de nombres upstream

Cloud DNS para GKE admite dominios de stub personalizados y servidores de nombres ascendentes configurados con kube-dns ConfigMap. Esta asistencia solo está disponible para los clústeres de GKE Standard.

Cloud DNS traduce los valores stubDomains y upstreamNameservers en zonas de reenvío de Cloud DNS.

Extensiones de especificaciones

Para mejorar el descubrimiento de servicios y la compatibilidad con varios clientes y sistemas, puedes usar complementos sobre la especificación general de DNS de Kubernetes.

Puertos con nombre

En esta sección, se explica cómo los puertos con nombre afectan los registros DNS que crea Cloud DNS para tu clúster de Kubernetes. Kubernetes define un conjunto mínimo de registros DNS obligatorios, pero Cloud DNS puede crear registros adicionales para su propio funcionamiento y para admitir varias funciones de Kubernetes. En las siguientes tablas, se ilustra la cantidad mínima de conjuntos de registros que puedes esperar, en los que "E" representa la cantidad de extremos y "P" representa la cantidad de puertos. Es posible que Cloud DNS cree registros adicionales.

Tipo de pila de IP Tipo de servicio Conjuntos de registros
Pila única ClusterIP
$$2+P$$
Sin interfaz gráfica
$$2+P+2E$$
Pila doble ClusterIP
$$3+P$$
Sin interfaz gráfica
$$3+P+3E$$
Consulta Servicios de pila única y pila doble para obtener más información sobre estos servicios.

Registros DNS adicionales creados por Cloud DNS

Cloud DNS puede crear registros DNS adicionales más allá de la cantidad mínima de conjuntos de registros. Estos registros tienen varios propósitos, incluidos los siguientes:

  • Registros SRV: Para el descubrimiento de servicios, Cloud DNS suele crear registros SRV. Estos registros proporcionan información sobre el puerto y el protocolo del servicio.
  • Registros AAAA (para pila doble): En las configuraciones de pila doble que usan IPv4 e IPv6, Cloud DNS crea registros A (para IPv4) y registros AAAA (para IPv6) para cada extremo.
  • Registros internos: Cloud DNS puede crear registros internos para su propia administración y optimización. Por lo general, estos registros no son directamente relevantes para los usuarios.
  • Servicios de LoadBalancer: Para los servicios de tipo LoadBalancer, Cloud DNS crea registros que se asocian con la dirección IP del balanceador de cargas externo.
  • Services sin interfaz gráfica: estos Services tienen una configuración de DNS distinta. Cada Pod obtiene su propio registro DNS, lo que permite que los clientes se conecten directamente a los Pods. Este enfoque es el motivo por el que el número de puerto no se multiplica en el cálculo del registro del Service sin interfaz gráfica.

Ejemplo: Considera un objeto Service llamado my-http-server que se encuentra en el espacio de nombres backend. Este Service expone dos puertos, 80 y 8080, para un Deployment con tres Pods. Por lo tanto, E = 3 y P = 2.

Tipo de pila de IP Tipo de servicio Conjuntos de registros
Pila única ClusterIP
$$2+2$$
Sin interfaz gráfica
$$2+2+2*3$$
Pila doble ClusterIP
$$3+2$$
Sin interfaz gráfica
$$3+2+3*3$$

Además de estos registros mínimos, Cloud DNS puede crear registros SRV y, en el caso de las redes de pila doble, registros AAAA. Si my-http-server es un Service de tipo LoadBalancer, se crean registros adicionales para la IP del balanceador de cargas. Nota: Cloud DNS agrega registros DNS complementarios según sea necesario. Los registros específicos que se crean dependen de factores como el tipo y la configuración del Service.

Problemas conocidos

En esta sección, se describen los problemas comunes que puedes encontrar cuando usas Cloud DNS con GKE, junto con posibles soluciones alternativas.

Terraform intenta volver a crear el clúster de Autopilot debido a un cambio de dns_config

Si usas terraform-provider-google o terraform-provider-google-beta, es posible que experimentes un problema en el que Terraform intenta volver a crear un clúster de Autopilot. Este error se produce porque los clústeres de Autopilot recién creados que ejecutan las versiones 1.25.9-gke.400, 1.26.4-gke.500 o 1.27.1-gke.400 o una versión posterior usan Cloud DNS como proveedor de DNS en lugar de kube-dns.

Este problema se resolvió en la versión 4.80.0 del proveedor de Terraform de Google Cloud.

Si no puedes actualizar la versión de terraform-provider-google o terraform-provider-google-beta, puedes agregar el parámetro de configuración lifecycle.ignore_changes al recurso para asegurarte de que google_container_cluster ignore los cambios en dns_config:

  lifecycle {
    ignore_changes = [
      dns_config,
    ]
  }

La resolución de DNS falla después de migrar de kube-dns a Cloud DNS con NodeLocal DNSCache habilitado

En esta sección, se describe un problema conocido para los clústeres de GKE que se encuentran en Cloud DNS y que tienen habilitado NodeLocal DNSCache en el permiso del clúster.

Cuando NodeLocal DNSCache está habilitado en el clúster y migras de kube-dns a Cloud DNS, es posible que el clúster experimente errores de resolución intermitentes.

Si usas kube-dns con NodeLocal DNSCache habilitado en el clúster, NodeLocal DNSCache se configura para escuchar en ambas direcciones: la dirección de NodeLocal DNSCache y la dirección de kube-dns.

Para verificar el estado de NodeLocal DNSCache, ejecuta el siguiente comando:

kubectl get cm -n kube-system node-local-dns -o json | jq .data.Corefile -r | grep bind

El resultado es similar a lo siguiente:

    bind 169.254.20.10 x.x.x.10
    bind 169.254.20.10 x.x.x.10

Si GKE Dataplane V2 está habilitado en el clúster y este usa kube-dns, NodeLocal DNSCache se ejecuta en una red aislada y se configura para escuchar en todas las direcciones IP de Pods (0.0.0.0). El resultado es similar a lo siguiente:

    bind 0.0.0.0
    bind 0.0.0.0

Después de que el clúster se actualiza a Cloud DNS, se cambia la configuración de NodeLocal DNSCache. Para verificar la configuración de NodeLocal DNSCache, ejecuta el siguiente comando:

kubectl get cm -n kube-system node-local-dns -o json | jq .data.Corefile -r | grep bind

El resultado es similar a lo siguiente:

    bind 169.254.20.10
    bind 169.254.20.10

En el siguiente flujo de trabajo, se explican las entradas del archivo resolv.conf antes y después de la migración y la recreación de nodos:

Antes de la migración

  • Los Pods tienen el archivo resolv.conf configurado en la dirección IP kube-dns (por ejemplo, x.x.x.10).
  • Los Pods de NodeLocal DNSCache interceptan las solicitudes de DNS de los Pods y escuchan lo siguiente:
    • (DPv1) Ambas direcciones (bind 169.254.20.10 x.x.x.10).
    • (DPv2) todas las direcciones IP de Pods (vincular 0.0.0.0).
  • NodeLocal DNSCache funciona como una caché y se aplica una carga mínima en los Pods de kube-dns.

Después de la migración

  • Después de que se actualiza el plano de control para usar Cloud DNS, los Pods aún tienen el archivo resolv.conf configurado en la dirección IP de kube-dns (por ejemplo, x.x.x.10). Los Pods conservan esta configuración de resolv.conf hasta que se vuelve a crear su nodo. Cuando se habilita Cloud DNS con NodeLocal DNSCache, los Pods se deben configurar para usar 169.254.20.10 como servidor de nombres, pero este cambio solo se aplica a los Pods en nodos que se crearon o volvieron a crear después de la migración a Cloud DNS.
  • Los Pods de NodeLocal DNSCache solo escuchan en la dirección de NodeLocal DNSCache (vinculación 169.254.20.10). Las solicitudes no se envían a los Pods de NodeLocal DNSCache.
  • Todas las solicitudes de los Pods se envían directamente a los Pods de kube-dns. Esta configuración genera un tráfico alto en los Pods.

Después de volver a crear el nodo o actualizar el grupo de nodos

  • Los Pods tienen el archivo resolv.conf configurado para usar la dirección IP de NodeLocal DNSCache (169.254.20.10).
  • Los Pods de NodeLocal DNSCache solo escuchan en la dirección de NodeLocal DNSCache (enlace 169.254.20.10) y reciben solicitudes de DNS de los Pods en esta dirección IP.

Cuando los grupos de nodos usan la dirección IP de kube-dns en el archivo resolv.conf antes de que se vuelva a crear el grupo de nodos, un aumento en el tráfico de consultas de DNS también incrementa el tráfico en los Pods de kube-dns. Este aumento puede causar fallas intermitentes en las solicitudes de DNS. Para minimizar los errores, debes planificar esta migración durante los períodos de inactividad.

¿Qué sigue?