Este documento 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 gestionar la resolución de DNS de pods y servicios como alternativa a los proveedores de DNS alojados en clústeres, como kube-dns.
En 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 usuarios de GKE, incluidos desarrolladores, administradores y arquitectos. Para obtener más información sobre los roles y las tareas de ejemplo habituales en Google Cloud, consulta Roles y tareas de usuario habituales de GKE Enterprise.
En este documento se da por hecho que conoces 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 servicios sin necesidad de un proveedor de DNS alojado en el clúster. Los registros DNS de los pods y los servicios se aprovisionan automáticamente en Cloud DNS para la dirección IP del clúster, los servicios sin encabezado y los servicios de nombres externos.
Cloud DNS admite la especificación completa de DNS de Kubernetes y proporciona resolución para los registros A, AAAA, SRV y PTR de los servicios de un clúster de GKE. Los registros PTR se implementan mediante reglas de políticas de respuesta. Usar Cloud DNS como proveedor de DNS para GKE ofrece las siguientes ventajas con respecto al DNS alojado en el clúster:
- Sobrecarga reducida: elimina la necesidad de gestionar servidores DNS alojados en clústeres. Cloud DNS no requiere que se escale, monitorice ni gestione manualmente las instancias de DNS, ya que es un servicio totalmente gestionado.
- Alto rendimiento y escalabilidad: resuelve las consultas de forma local en cada nodo de GKE para proporcionar una resolución de DNS de baja latencia y altamente escalable. Para obtener un rendimiento óptimo, sobre todo en clústeres a gran escala, te recomendamos que habilites NodeLocal DNSCache, que proporciona una capa de caché adicional en el nodo.
- Integración con Google Cloud Observability: permite monitorizar y registrar el DNS. Para obtener más información, consulta el artículo Habilitar e inhabilitar el registro de zonas gestionadas privadas.
Arquitectura
Cuando Cloud DNS es el proveedor de DNS de GKE, un controlador se ejecuta como un pod gestionado 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 DNS privada gestionada.
En el siguiente diagrama se muestra cómo resuelven los nombres de clúster el plano de control y el plano de datos de Cloud DNS:
En el diagrama, el backend de 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 los fallos de caché a Cloud DNS.
Cloud DNS resuelve el nombre del servicio en diferentes direcciones IP en función del tipo de servicio de Kubernetes. En el caso de los ClusterIP, Cloud DNS resuelve el nombre del servicio en su dirección IP virtual. En el caso de los servicios sin encabezado, resuelve el nombre del servicio en la lista de direcciones IP de los endpoints.
Una vez que el frontend del pod resuelve la dirección IP, el pod puede enviar tráfico al backend del servicio y a cualquier pod que esté detrás del servicio.
.Ámbitos de DNS
Cloud DNS tiene los siguientes ámbitos de DNS. Un clúster no puede funcionar en varios modos simultáneamente.
- Ámbito del clúster de GKE: los registros DNS solo se pueden resolver dentro del clúster, que es el mismo comportamiento que
kube-dns. Solo los nodos que se ejecutan en el clúster de GKE pueden resolver nombres de servicio. De forma predeterminada, los clústeres tienen nombres DNS que terminan en*.cluster.local. Estos nombres de DNS solo se pueden ver en el clúster y no se superponen ni entran en conflicto con los nombres de DNS de otros clústeres de GKE del mismo proyecto.*.cluster.localEste es el modo predeterminado.- Ámbito de VPC adicional de Cloud DNS: el ámbito de VPC adicional de Cloud DNS es una función opcional que amplía el ámbito del clúster de GKE para que los servicios sin encabezado se puedan resolver desde otros recursos de la VPC, como las VMs de Compute Engine o los clientes on-premise que estén conectados mediante Cloud VPN o Cloud Interconnect. Este modo es un modo adicional que se habilita junto con el ámbito del clúster. Puedes habilitar o inhabilitar este modo en tu clúster sin que afecte al tiempo de actividad del DNS ni a las funciones del ámbito del clúster.
- Ámbito de la VPC: los registros DNS se pueden resolver en toda la VPC. Las VMs de Compute Engine y los clientes on-premise pueden conectarse mediante Cloud Interconnect o Cloud VPN, y pueden resolver directamente los nombres de servicio de GKE. Debe definir un dominio personalizado único para cada clúster, lo que significa que todos los registros DNS de servicio y de pod son únicos en la VPC. Este modo reduce la fricción de la comunicación entre los recursos de GKE y los que no son de GKE.
En la siguiente tabla se enumeran las diferencias entre los ámbitos de DNS:
| Función | Permiso de clúster de GKE | Ámbito de VPC adicional de Cloud DNS | Ámbito de VPC |
|---|---|---|---|
| Ámbito de visibilidad de DNS | Solo dentro del clúster de GKE | Solo para clústeres, con servicios sin encabezado que se pueden resolver en la red VPC | Toda la red VPC |
| Resolución de servicios sin interfaz gráfica | Se puede resolver en el clúster | Se puede resolver en el clúster mediante el dominio `cluster.local` y en la VPC mediante el sufijo del clúster. | Se puede resolver en el clúster y en la VPC mediante el sufijo del clúster. |
| Requisito de dominio único | No, usa el dominio predeterminado `*.cluster.local`. | Sí, debes definir un dominio personalizado único | Sí, debes definir un dominio personalizado único |
| Configuración | Predeterminado, sin pasos adicionales | Opcional al crear el 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 proveedor de DNS para tu clúster de GKE, el controlador de Cloud DNS crea recursos en Cloud DNS para tu proyecto. Los recursos que crea GKE dependen del ámbito de Cloud DNS.
| Ámbito | Zona de búsqueda directa | Zona de búsqueda inversa |
|---|---|---|
| Ámbito de clúster | 1 zona privada por clúster y por zona de Compute Engine (en la región) | 1 zona de política de respuesta por clúster y por zona de Compute Engine (en la región) |
| Ámbito de VPC adicional de Cloud DNS | 1 zona privada por clúster por zona de Compute Engine (en la región) por clúster (zona global)
1 zona privada con ámbito de VPC 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 zona de política de respuesta con ámbito de VPC por clúster (zona global) |
| Ámbito de 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 nomenclatura que se usa para estos recursos de Cloud DNS es la siguiente:
| Ámbito | Zona de búsqueda directa | Zona de búsqueda inversa |
|---|---|---|
| Ámbito de clúster | gke-CLUSTER_NAME-CLUSTER_HASH-dns |
gke-CLUSTER_NAME-CLUSTER_HASH-rp |
| Ámbito de VPC adicional de Cloud DNS | gke-CLUSTER_NAME-CLUSTER_HASH-dns
para zonas con ámbito de clúster
gke-CLUSTER_NAME-CLUSTER_HASH-dns-vpc
para zonas con ámbito de VPC
|
gke-CLUSTER_NAME-CLUSTER_HASH-rp
para zonas con ámbito de clúster
gke-NETWORK_NAME_HASH-rp para zonas con ámbito de VPC |
| Ámbito de VPC | gke-CLUSTER_NAME-CLUSTER_HASH-dns |
gke-NETWORK_NAME_HASH-rp |
Además de las zonas que se mencionan en la tabla anterior, el controlador de Cloud DNS crea las siguientes zonas en tu proyecto, en función de tu configuración:
| Configuración de DNS personalizada | Tipo de zona | Convención de nomenclatura de zonas |
|---|---|---|
| Dominio de stub | Reenvío (zona global) | gke-CLUSTER_NAME-CLUSTER_HASH-DOMAIN_NAME_HASH |
| Servidores de nombres ascendentes personalizados | Reenvío (zona global) | gke-CLUSTER_NAME-CLUSTER_HASH-upstream |
Para obtener más información sobre cómo crear dominios stub personalizados o servidores de nombres upstream personalizados, consulta Añadir resoluciones personalizadas para dominios stub.
Zonas gestionadas y zonas de reenvío
En el caso de los clústeres que usan el ámbito de clúster para servir tráfico DNS interno, el controlador de Cloud DNS crea una zona DNS gestionada en cada zona de Compute Engine de la región a la que pertenece el clúster.
Por ejemplo, si despliegas un clúster en la zona us-central1-c, el controlador de Cloud DNS crea una zona gestionada en us-central1-a, us-central1-b, us-central1-c y us-central1-f.
Por cada DNS stubDomain, el controlador de Cloud DNS crea una zona de reenvío.
Cloud DNS procesa cada DNS upstream mediante una zona gestionada con el . nombre de DNS.
Cuotas
Cloud DNS usa cuotas para limitar el número de recursos que GKE puede crear para las entradas DNS. Las cuotas y los límites de Cloud DNS pueden ser diferentes de las limitaciones de kube-dns para tu proyecto.
Cuando usas Cloud DNS para GKE, se aplican las siguientes cuotas predeterminadas a cada zona gestionada de tu proyecto:
| Recurso DNS de Kubernetes | Recurso de Cloud DNS correspondiente | Cuota |
|---|---|---|
| Número de registros DNS | Número máximo de bytes por zona gestionada | 2.000.000 (50 MB como máximo para una zona gestionada) |
| Número de pods por servicio sin encabezado (IPv4 o IPv6) | Número de registros por conjunto de registros de recursos | GKE 1.24 a 1.25: 1000 (IPv4 o IPv6) GKE 1.26 y versiones posteriores: 3500 para IPv4 y 2000 para IPv6 |
| Número de clústeres de GKE en un proyecto | Número de políticas de respuesta por proyecto | 100 |
| Número de registros PTR por clúster | Número 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, tal como se describe en la siguiente tabla:
| Límite | Contribución al límite |
|---|---|
| Conjuntos de registros de recursos por zona gestionada | Número de servicios más número de endpoints de servicio sin encabezado con nombres de host válidos por clúster. |
| Registros por conjunto de registros de recursos | Número de endpoints por servicio sin encabezado. No afecta a otros tipos de servicios. |
| Número de reglas por política de respuesta | En el caso del ámbito de clúster, se trata del número de servicios más el número de endpoints de servicio sin encabezado con nombres de host válidos por clúster. En el caso del ámbito de VPC, el número de servicios más el número de endpoints sin encabezado con nombres de host de todos los clústeres de la VPC. |
Para obtener más información sobre cómo se crean los registros DNS para Kubernetes, consulta Descubrimiento de servicios basado 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.
Admite dominios stub personalizados y servidores de nombres upstream
Cloud DNS para GKE admite dominios stub personalizados y servidores de nombres upstream configurados mediante kube-dns ConfigMap. Esta asistencia solo está disponible para clústeres estándar de GKE.
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 además de la especificación general de DNS de Kubernetes.
Puertos con nombre
En esta sección se explica cómo afectan los puertos con nombre a 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 muestra el número mínimo de conjuntos de registros que puedes esperar, donde "E" representa el número de endpoints y "P" representa el número de puertos.
Cloud DNS puede crear 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 dual | ClusterIP | $$3+P$$ |
| Sin interfaz gráfica | $$3+P+3E$$ |
|
| Consulta Servicios de pila única y de pila dual para obtener más información sobre los servicios de pila única y de pila dual. | ||
Registros DNS adicionales creados por Cloud DNS
Cloud DNS puede crear registros DNS adicionales que superen el número mínimo de conjuntos de registros. Estos registros tienen varios fines, entre los que se incluyen 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 doble pila): en las configuraciones de doble pila que usan tanto IPv4 como IPv6, Cloud DNS crea registros A (para IPv4) y registros AAAA (para IPv6) para cada endpoint.
- Registros internos: Cloud DNS puede crear registros internos para su propia gestión y optimización. Estos registros no suelen ser relevantes directamente para los usuarios.
- Servicios LoadBalancer: para los servicios de tipo
LoadBalancer, Cloud DNS crea registros asociados a la dirección IP del balanceador de carga externo. - Servicios sin interfaz gráfica: los servicios sin interfaz gráfica tienen una configuración de DNS distinta. Cada pod tiene su propio registro DNS, lo que permite que los clientes se conecten directamente a los pods. Por eso, el número de puerto no se multiplica en el cálculo del registro de servicio sin encabezado.
Ejemplo: Supongamos que hay un servicio llamado my-http-server en el espacio de nombres backend. Este servicio expone dos puertos, el 80 y el 8080, para un
despliegue 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 dual | 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 dual, registros AAAA. Si my-http-server es un servicio de tipo LoadBalancer, se crearán registros adicionales para la IP del balanceador de carga. Nota: Cloud DNS añade registros DNS complementarios según sea necesario. Los registros específicos que se crean dependen de factores como el tipo de servicio y la configuración.
Problemas conocidos
En esta sección se describen los problemas habituales que pueden surgir al usar Cloud DNS con GKE, así como 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 Terraform intente 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 ha resuelto 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 añadir el ajuste 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 de los clústeres de GKE que están en Cloud DNS y que tienen habilitado NodeLocal DNSCache en el ámbito del clúster.
Si 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 comprobar 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 debería ser similar al 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 todas las direcciones IP de los pods (0.0.0.0). El resultado debería ser similar al siguiente:
bind 0.0.0.0
bind 0.0.0.0
Una vez que el clúster se actualiza a Cloud DNS, se cambia la configuración de NodeLocal DNSCache. Para comprobar 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 debería ser similar al 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.confconfigurado con la dirección IPkube-dns(por ejemplo,x.x.x.10). - Los pods de NodeLocal DNSCache interceptan las solicitudes 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 los pods (enlace 0.0.0.0).
- NodeLocal DNSCache funciona como caché y se ejerce una carga mínima en los
kube-dnspods.
Después de la migración
- Una vez que el plano de control se haya actualizado para usar Cloud DNS, los pods seguirán teniendo el archivo
resolv.confconfigurado con la dirección IPkube-dns(por ejemplo,x.x.x.10). Los pods conservarán esta configuración deresolv.confhasta que se vuelva a crear su nodo. Cuando Cloud DNS con NodeLocal DNSCache está habilitado, los pods deben configurarse para usar169.254.20.10como servidor de nombres, pero este cambio solo se aplica a los pods de los 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 (bind 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 mucho tráfico en los pods.
Después de volver a crear un nodo o de actualizar un grupo 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 (bind 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, el aumento del tráfico de consultas de DNS también aumenta el tráfico en los pods kube-dns. Este aumento puede provocar fallos intermitentes en las solicitudes de DNS. Para minimizar los errores, debes planificar esta migración durante los periodos de inactividad.