En este documento, se te ayudará 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 los clústeres estándar, 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 de usuario y tareas comunes de GKE Enterprise.
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 automáticamente 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.
- Alto rendimiento y escalabilidad: Resuelve las consultas de forma local para cada nodo de GKE y proporciona 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 con Google Cloud Observability: Permite el registro y la supervisión de DNS. Si deseas 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 privada 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:
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 servicio.
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 servicios ClusterIP, Cloud DNS resuelve el nombre del servicio en su dirección IP virtual; en el caso de los servicios sin interfaz gráfica, resuelve el nombre del servicio en la lista de direcciones IP de extremo.
Después de que el Pod de frontend resuelve la dirección IP, el Pod puede enviar tráfico al Service de 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 dentro del 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 servicios. 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.localpara 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 con 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 |
|---|---|---|---|
| Permiso 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 alcance 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 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 servicio 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 que se configuran 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 especificación
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 la 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 doble para obtener más información sobre los servicios de pila única y doble. | ||
Registros DNS adicionales creados por Cloud DNS
Es posible que Cloud DNS cree 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 LoadBalancer: Para los servicios de tipo
LoadBalancer, Cloud DNS crea registros asociados con la dirección IP del balanceador de cargas externo. - Servicios sin interfaz gráfica: Los servicios sin interfaz gráfica 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 la razón por la que el número de puerto no se multiplica en el cálculo de registros del servicio 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, el 80 y el 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 servicio.
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 posteriores 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 tu 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 está configurado 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 del nodo:
Antes de la migración
- Los Pods tienen el archivo
resolv.confconfigurado en la dirección IPkube-dns(por ejemplo,x.x.x.10). - Los Pods de NodeLocal DNSCache interceptan las solicitudes de DNS de los Pods y escuchan en los siguientes puertos:
- (DPv1) Ambas direcciones (bind 169.254.20.10 x.x.x.10).
- (DPv2) Todas las direcciones IP de Pod (enlaza 0.0.0.0).
- NodeLocal DNSCache funciona como una caché y se aplica una carga mínima a los Pods
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.confconfigurado en la dirección IPkube-dns(por ejemplo,x.x.x.10). Los Pods conservan esta configuración deresolv.confhasta que se vuelve a crear su nodo. Cuando se habilita Cloud DNS con NodeLocal DNSCache, los Pods deben configurarse para usar169.254.20.10como 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 (enlace 169.254.20.10). Las solicitudes no se dirigen 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 la recreación de nodos o la actualización de grupos de nodos
- Los Pods tienen el archivo
resolv.confconfigurado 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 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 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.