Usa Cloud DNS para GKE

En esta página, se explica cómo usar Cloud DNS como proveedor de DNS de Kubernetes para Google Kubernetes Engine (GKE).

Usar Cloud DNS como proveedor de DNS no permite que los clientes fuera de un clúster resuelvan Services de Kubernetes y lleguen a ellos directamente. Aún debes exponer los Services de forma externa mediante un balanceador de cargas y registrar sus direcciones IP externas del clúster en la infraestructura de DNS.

Si deseas obtener más información para usar kube-dns como proveedor de DNS, consulta Descubrimiento de servicios y DNS. Para aprender a usar una versión personalizada de kube-dns o un proveedor de DNS personalizado, consulta Configura una implementación personalizada de kube-dns.

Cómo funciona Cloud DNS para GKE

Cloud DNS se puede usar como proveedor de DNS para GKE, lo que proporciona una resolución de DNS del Pod y servicio con DNS administrado que no requiere un proveedor de DNS alojado en clústeres. Los registros DNS de Pods y servicios se aprovisionan de forma automática en Cloud DNS para los servicios 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 mediante reglas de política de respuesta.

Usar Cloud DNS como proveedor de DNS para GKE ofrece muchos beneficios en comparación con DNS alojado en clústeres:

  • Quita la sobrecarga de administrar el servidor DNS alojado en clústeres. Cloud DNS no requiere escalamiento, supervisión ni administración de instancias de DNS, ya que es un servicio completamente administrado alojado en la infraestructura de Google altamente escalable.
  • Resolución local de las consultas de DNS en cada nodo de GKE. De forma similar a NodeLocal DNSCache, Cloud DNS almacena en caché las respuestas de DNS de forma local, lo que proporciona baja resolución de DNS y baja latencia.
  • Integración con Google Cloud Observability para la supervisión y el registro 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 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.
Diagrama: Resuelve nombres de clústeres

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

El podfrontend envía una solicitud de DNS para resolver la dirección IP del servicio llamadabackend en elServidor de metadatos local de Compute Engine a169.254.169.254 El servidor de metadatos se ejecuta de forma local en el nodo y envía errores de caché a Cloud DNS.

El plano de datos de Cloud DNS se ejecuta de forma local en cada nodo de GKE o instancia de máquina virtual (VM) de Compute Engine. Según el tipo de servicio de Kubernetes, Cloud DNS resuelve el nombre del servicio a su dirección IP virtual, para los servicios de IP de clúster, o a la lista de direcciones IP de extremo, para los servicios sin interfaz gráfica.

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 servicio.

Permisos de DNS

Cloud DNS tiene dos tipos de permisos de DNS, permiso del clúster de GKE y permiso de la nube privada virtual (VPC). Un clúster no puede operar en ambos 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 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.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 alcance del clúster de GKE para que los Services sin interfaz gráfica se puedan resolver desde otros recursos en la VPC, como VMs de Compute Engine o clientes locales conectados mediante Cloud VPN o Cloud Interconnect. El permiso adicional de VPC es un modo extra que se habilita junto con el permiso del clúster que puedes habilitar o inhabilitar en tu clúster sin afectar el tiempo de actividad o la capacidad (permiso del clúster) de DNS.

  • Permiso de la VPC: Los registros DNS se pueden resolver dentro de toda la VPC. Las VM de Compute Engine y los clientes locales pueden conectarse mediante Cloud Interconnect o Cloud VPN y 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 el permiso del clúster de GKE, el permiso adicional de VPC de Cloud DNS y el permiso de la VPC:

Atributo 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 Se extiende a toda 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 ‘cluster.local’ y en toda la VPC con el sufijo del clúster Se puede resolver dentro del clúster y en la VPC mediante el sufijo del clúster
Requisito de dominio único No. Usa el valor 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 clúster
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 ascendentes 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

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 mediante una zona administrada con el nombre de DNS ..

Precios

Cuando Cloud DNS es el proveedor de DNS para clusteres de GKE Standard, las consultas de DNS de Pods dentro del clúster de GKE se facturan según los precios de Cloud DNS.

Las consultas a una zona del DNS con permiso de VPC administrada por GKE se facturan con los precios estándar de Cloud DNS.

Requisitos

La API de Cloud DNS debe estar habilitada en tu proyecto.

Cloud DNS para GKE tiene los siguientes requisitos para el alcance de clúster:

  • Para la versión Standard 1.24.7-gke.800, 1.25.3-gke.700 o posterior de GKE.
  • Para Autopilot, la versión 1.25.9-gke.400, 1.26.4-gke.500 o posterior de GKE.
  • Versión 411.0.0 o posterior de Google Cloud CLI.

Cloud DNS para GKE tiene los siguientes requisitos para el permiso adicional de VPC:

  • Para la versión Standard 1.24.7-gke.800, 1.25.3-gke.700 o posterior de GKE.
  • Para Autopilot, versión 1.28 de GKE o posterior.
  • Versión 471.0.0 de Google Cloud CLI.
  • El clúster de GKE debe usar el permiso de clúster de Cloud DNS como proveedor de DNS predeterminado.

Cloud DNS para GKE tiene los siguientes requisitos para el alcance de clúster:

  • Para Standard, la versión 1.19 de GKE o una posterior.
  • Versión 364.0.0 o posterior de Google Cloud CLI.
  • La API de Cloud DNS debe estar habilitada en tu proyecto.

Restricciones y limitaciones

Se aplica la siguiente limitación:

  • El permiso de la VPC no es compatible con los clústeres de Autopilot, solo se admite el permiso del clúster. Si necesitas resolver nombres de servicios sin interfaz gráfica que se ejecutan en clústeres de GKE Autopilot, debes usar el permiso de VPC adicional.
  • Cloud DNS no cumple con un régimen de cumplimiento de nivel de impacto 4 (IL4). Cloud DNS para GKE no se puede usar en una carga de trabajo garantizada con un régimen de cumplimiento de IL4. Debes usar kube-dns en ese entorno regulado. Para los clústeres de Autopilot de GKE, la selección de kube-dns o Cloud DNS se realiza de forma automática en función de tu régimen de cumplimiento.
  • Los cambios manuales a las zonas del DNS privadas administradas no son compatibles y el controlador de Cloud DNS los reemplaza. Las modificaciones en los registros DNS de esas zonas no persisten cuando se reinicia el controlador.
  • Después de habilitar Cloud DNS para GKE en un clúster, kube-dns continuará ejecutándose en el clúster. Puedes inhabilitar kube-dns mediante el escalamiento del Deployment de kube-dns y el escalador automático a cero.
  • No puedes cambiar el permiso de DNS en un clúster después de haber establecido el permiso con la marca --cluster-dns-scope. Si necesitas cambiar el permiso de DNS, vuelve a crear el clúster con otro permiso de DNS.
  • Los dominios personalizados de stub y los parámetros de configuración del servidor DNS ascendentes se aplican a la configuración de DNS de Pods y nodos. Los Pods que usan redes del host o procesos que se ejecutan directamente en el host también usan el dominio de stub y los parámetros de configuración de servidores de nombres ascendentes. Esto solo se admite en las versiones estándar.
  • Los dominios de stub personalizados y los servidores de nombres ascendentes configurados a través de kube-dns Configmap se aplican de forma automática a Cloud DNS para el DNS del permiso del clúster. El DNS del permiso de VPC ignora el kube-dns ConfigMap y debes aplicar estas opciones de configuración directamente en Cloud DNS. Esto solo se admite en las versiones estándar.
  • No hay una ruta de migración de kube-dns al permiso de VPC; la operación es perjudicial. Vuelve a crear el clúster cuando cambies de kube-dns al permiso de VPC, o viceversa.
  • En el caso del alcance de VPC, el rango de direcciones IP secundario para los objetos Service no debe compartirse con ningún otro clúster de esa subred.
  • Para el alcance de VPC, la política de respuesta asociada con un registro PTR se adjunta a la red de VPC. Si hay alguna otra política de respuesta vinculada a la red del clúster, la resolución del registro PTR falla para las direcciones IP del servicio de Kubernetes.
  • Si intentas crear un servicio sin interfaz gráfica con una cantidad de pods que exceda la cuota permitida, Cloud DNS no creará conjuntos de registros ni registros para el servicio.

Cuotas

Cloud DNS usa cuotas a fin de limitar la cantidad de recursos que GKE puede crear para las entradas de DNS. Las cuotas y límites para Cloud DNS y 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/IPv6) Cantidad de registros por conjunto de registros de recursos GKE 1.24 a 1.25: 1,000 (IPv4/IPv6)
GKE 1.26 y versiones posteriores: 3,500/2,000 (IPv4/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.

Antes de comenzar

Antes de comenzar, asegúrate de haber realizado las siguientes tareas:

  • Habilita la API de Google Kubernetes Engine.
    • Habilitar la API de Google Kubernetes Engine
  • Si deseas usar Google Cloud CLI para esta tarea, instala y, luego, inicializa gcloud CLI. Si ya instalaste gcloud CLI, ejecuta gcloud components update para obtener la versión más reciente.

Habilita el DNS del alcance del clúster

En el DNS del permiso de clúster, solo los nodos que se ejecutan en el clúster de GKE pueden resolver los nombres de servicio, y estos no entran en conflicto entre los clústeres. Este comportamiento es el mismo que kube-dns en clústeres de GKE, lo que significa que puedes migrar clústeres de kube-dns al permiso de clústeres de Cloud DNS sin tiempo de inactividad ni cambios en las aplicaciones.

En el siguiente diagrama, se muestra cómo Cloud DNS crea una zona de DNS privada para un clúster de GKE. Solo los procesos y los Pods que se ejecutan en los nodos del clúster pueden resolver los registros DNS del clúster, ya que solo los nodos están en el permiso de DNS.

Pods en nodos diferentes que resuelven servicios dentro del clúster de GKE.
Diagrama: DNS del permiso de clúster

Habilita el DNS del permiso de clúster en un clúster nuevo

Clúster de GKE Autopilot

Clústeres de Autopilot nuevos en la versión 1.25.9-gke.400, 1.26.4-gke.500 o posterior, de forma predeterminada con el permiso del clúster de Cloud DNS.

Clúster de GKE Standard

Puedes crear un clúster de GKE Standard con el permiso del clúster de Cloud DNS habilitado mediante la CLI de gcloud o la consola de Google Cloud:

gcloud

Crea un clúster con la marca --cluster-dns:

gcloud container clusters create CLUSTER_NAME \
    --cluster-dns=clouddns \
    --cluster-dns-scope=cluster \
    --location=COMPUTE_LOCATION

Reemplaza lo siguiente:

La marca --cluster-dns-scope=cluster es opcional en el comando, ya que cluster es el valor predeterminado.

Consola

  1. Ve a la página de Google Kubernetes Engine en la consola de Google Cloud.

    Ir a Google Kubernetes Engine

  2. Haz clic en Crear.

  3. En el panel de navegación, en Clúster, haz clic en Herramientas de redes.

  4. En la sección Proveedor de DNS, haz clic en Cloud DNS.

  5. Selecciona Alcance del clúster.

  6. Configura tu clúster según sea necesario.

  7. Haz clic en Crear.

Habilita el DNS del permiso del clúster en un clúster existente

Clúster de GKE Autopilot

No puedes migrar un clúster de GKE Autopilot existente de kube-dns al permiso del clúster de Cloud DNS. Para habilitar el permiso del clúster de Cloud DNS, vuelve a crear los clústeres de Autopilot en las versiones 1.25.9-gke.400, 1.26.4-gke.500 o posteriores.

Clúster de GKE Standard

Puedes migrar un clúster de GKE existente de kube-dns al permiso del clúster de Cloud DNS mediante la CLI de gcloud o la consola de Google Cloud en un clúster de GKE Standard.

Cuando migras un clúster existente, los nodos del clúster no usan Cloud DNS como proveedor de DNS hasta que vuelves a crear los nodos.

Después de habilitar Cloud DNS para un clúster, la configuración solo se aplica si actualizas grupos de nodos existentes o si agregas grupos de nodos nuevos al clúster. Cuando actualizas un grupo de nodos, los nodos se vuelven a crear.

También puedes migrar clústeres que tengan aplicaciones en ejecución sin interrumpir la comunicación del clúster si habilitas Cloud DNS como proveedor de DNS en cada grupo de nodos por separado. Un subconjunto de nodos está operativo en todo momento porque algunos grupos de nodos usan kube-dns y otros usan Cloud DNS.

En los siguientes pasos, habilitarás Cloud DNS para un clúster y, luego, actualizarás los grupos de nodos. La actualización de los grupos de nodos vuelve a crear los nodos. Luego, los nodos usan Cloud DNS para la resolución de DNS en lugar de kube-dns.

gcloud

  1. Actualiza el clúster existente:

    gcloud container clusters update CLUSTER_NAME \
    --cluster-dns=clouddns \
    --cluster-dns-scope=cluster \
    --location=COMPUTE_LOCATION

    Reemplaza lo siguiente:

    La respuesta es similar al ejemplo a continuación:

    All the node-pools in the cluster need to be re-created by the user to start using Cloud DNS for DNS lookups. It is highly recommended to complete this step
shortly after enabling Cloud DNS.
Do you want to continue (Y/n)?

    Después de confirmar, el controlador de Cloud DNS se ejecuta en el plano de control de GKE, pero tus Pods no usarán Cloud DNS para la resolución de DNS hasta que actualices tu grupo de nodos o agregues grupos de nodos nuevos al clúster.

  2. Actualiza los grupos de nodos en el clúster para usar Cloud DNS:

    gcloud container clusters upgrade CLUSTER_NAME \
    --node-pool=POOL_NAME \
    --location=COMPUTE_LOCATION

    Reemplaza lo siguiente:

    • CLUSTER_NAME: el nombre del clúster
    • POOL_NAME: el nombre del grupo de nodos que se actualizará

    Si el grupo de nodos y el plano de control ejecutan la misma versión, primero actualiza el plano de control, como se describe en Actualiza manualmente el plano de control y, luego, realiza la actualización del grupo de nodos.

    Confirma la respuesta y repite este comando para cada grupo de nodos del clúster. Si tu clúster tiene un solo grupo de nodos, omite la marca --node-pool.

Consola

  1. Ve a la página de Google Kubernetes Engine en la consola de Google Cloud.

    Ir a Google Kubernetes Engine

  2. Haz clic en el nombre del clúster que deseas modificar.

  3. En Herramientas de redes, en el campo Proveedor de DNS, haz clic en Editar proveedor de DNS.

  4. Haz clic en Cloud DNS.

  5. Haz clic en Alcance del clúster.

  6. Haz clic en Guardar cambios.

Habilita el permiso adicional de VPC de Cloud DNS

En esta sección, se describen los pasos para habilitar o inhabilitar el permiso adicional de VPC de Cloud DNS, como un complemento del permiso del clúster de Cloud DNS.

Habilita el permiso adicional de VPC de Cloud DNS en un clúster nuevo

Puedes habilitar el DNS de permiso de VPC en un clúster nuevo de GKE con glcoud CLI o la consola de Google Cloud.

Para Autopilot

gcloud container clusters create-auto CLUSTER_NAME \
    --additive-vpc-scope-dns-domain=UNIQUE_CLUSTER_DOMAIN

Reemplaza lo siguiente:

  • CLUSTER_NAME: el nombre del clúster
  • UNIQUE_CLUSTER_DOMAIN: Es el nombre de un dominio. Debes asegurarte de que este nombre sea único dentro de la VPC, ya que GKE no confirma este valor. No puedes cambiar este valor después de configurarlo. No debes usar un dominio que termine en “.local” o podrías experimentar fallas en la resolución de DNS.

Para Estándar

gcloud container clusters create CLUSTER_NAME \
    --cluster-dns-scope=cluster \
    --additive-vpc-scope-dns-domain=UNIQUE_CLUSTER_DOMAIN

Reemplaza lo siguiente:

  • CLUSTER_NAME: el nombre del clúster
  • UNIQUE_CLUSTER_DOMAIN: Es el nombre de un dominio. Debes asegurarte de que este nombre sea único dentro de la VPC, ya que GKE no confirma este valor. No puedes cambiar este valor después de configurarlo. No debes usar un dominio que termine en “.local” o podrías experimentar fallas en la resolución de DNS.

Habilita el permiso adicional de VPC de Cloud DNS en un clúster existente

Para habilitar el permiso adicional de VPC de Cloud DNS en un clúster existente, primero debes habilitar Cloud DNS para un clúster y, luego, actualizar tus grupos de nodos. La actualización de los grupos de nodos vuelve a crear los nodos. Luego, los nodos usan Cloud DNS para la resolución de DNS en lugar de kube-dns.

Para habilitar el permiso adicional de VPC de Cloud DNS en un clúster existente, haz lo siguiente:

gcloud container clusters update CLUSTER_NAME \
    --enable-additive-vpc-scope \
    --additive-vpc-scope-dns-domain=UNIQUE_CLUSTER_DOMAIN

Reemplaza lo siguiente:

  • CLUSTER_NAME: el nombre del clúster
  • UNIQUE_CLUSTER_DOMAIN: Es el nombre de un dominio. Debes asegurarte de que este nombre sea único dentro de la VPC, ya que GKE no confirma este valor. No puedes cambiar este valor después de configurarlo. No debes usar un dominio que termine en “.local” o podrías experimentar fallas en la resolución de DNS.

Habilita el DNS de alcance de VPC

En el DNS del permiso de VPC, los nombres de DNS de un clúster se pueden resolver dentro de la VPC completa. Cualquier cliente en la VPC puede resolver los registros DNS del clúster.

El DNS del permiso de VPC habilita los siguientes casos de uso:

  • Descubrimiento de servicios sin interfaz gráfica para clientes que no son de GKE dentro de la misma VPC.
  • Resolución del Servicio de GKE de clientes locales o de la nube de terceros. Para obtener más información, consulta Política del servidor entrante.
  • La resolución del servicio en la que un cliente puede decidir con qué clúster se desea comunicar, mediante el dominio DNS personalizado del clúster.

En el siguiente diagrama, dos clústeres de GKE usan DNS del permiso de VPC en la misma VPC. Ambos clústeres tienen un dominio DNS personalizado, .cluster1 y .cluster2, en lugar del dominio .cluster.local predeterminado. Una VM se comunica con el servicio de backend sin interfaz gráfica mediante la resolución de backend.default.svc.cluster1. Cloud DNS resuelve el Service sin interfaz gráfica a las IP del Pod individuales en el Service, y la VM se comunica directamente con las IP del Pod.

Clientes que resuelven servicios sin interfaz gráfica desde fuera del clúster de GKE.
Diagrama: DNS del permiso de VPC

También puedes realizar este tipo de resolución desde otras redes cuando te conectas a la VPC a través de Cloud Interconnect o Cloud VPN. Las políticas de servidor DNS permiten a los clientes de redes conectadas a la VPC resolver nombres en Cloud DNS, incluidos los servicios de GKE si el clúster usa DNS del permiso de VPC.

Habilita el DNS de VPC en un clúster existente

La migración solo es compatible con GKE Estándar y no con GKE Autopilot.

Clúster de GKE Autopilot

No puedes migrar un clúster de GKE Autopilot de kube-dns al permiso de la VPC de Cloud DNS.

Clúster de GKE Standard

Puedes migrar un clúster de GKE existente de kube-dns al permiso de VPC de Cloud DNS mediante la CLI de gcloud o la consola de Google Cloud.

Después de habilitar Cloud DNS para un clúster, la configuración solo se aplica si actualizas grupos de nodos existentes o si agregas grupos de nodos nuevos al clúster. Cuando actualizas un grupo de nodos, estos se vuelven a crear.

En los siguientes pasos, habilitarás Cloud DNS para un clúster y, luego, actualizarás los grupos de nodos. La actualización de los grupos de nodos vuelve a crear los nodos. Luego, los nodos usan Cloud DNS para la resolución de DNS en lugar de kube-dns.

gcloud

  1. Actualiza el clúster existente:

    gcloud container clusters update CLUSTER_NAME \
    --cluster-dns=clouddns \
    --cluster-dns-scope=vpc \
    --cluster-dns-domain=CUSTOM_DOMAIN \
    --location=COMPUTE_LOCATION

    Reemplaza lo siguiente:

    • CLUSTER_NAME: el nombre del clúster
    • COMPUTE_LOCATION: la ubicación de Compute Engine para el clúster.
    • CUSTOM_DOMAIN: Es el nombre de un dominio. Debes asegurarte de que este nombre sea único dentro de la VPC, ya que GKE no confirma este valor. No puedes cambiar este valor después de configurarlo. No debes usar un dominio que termine en “.local” o podrías experimentar fallas en la resolución de DNS.

    La respuesta es similar al ejemplo a continuación:

    All the node-pools in the cluster need to be re-created by the user to start using Cloud DNS for DNS lookups. It is highly recommended to complete this step
shortly after enabling Cloud DNS.
Do you want to continue (Y/n)?

    Después de confirmar, el controlador de Cloud DNS se ejecuta en el plano de control de GKE. Tus Pods no usan Cloud DNS para la resolución de DNS hasta que actualices tu grupo de nodos o agregues grupos de nodos nuevos al clúster.

  2. Actualiza los grupos de nodos en el clúster para usar Cloud DNS:

    gcloud container clusters upgrade CLUSTER_NAME \
    --node-pool=POOL_NAME

    Reemplaza lo siguiente:

    • CLUSTER_NAME: el nombre del clúster
    • POOL_NAME: el nombre del grupo de nodos que se actualizará

    Si el grupo de nodos y el plano de control ejecutan la misma versión, primero actualiza el plano de control, como se describe en Actualiza manualmente el plano de control y, luego, realiza la actualización del grupo de nodos.

    Confirma la respuesta y repite este comando para cada grupo de nodos del clúster. Si tu clúster tiene un solo grupo de nodos, omite la marca --node-pool.

Consola

  1. Ve a la página de Google Kubernetes Engine en la consola de Google Cloud.

    Ir a Google Kubernetes Engine

  2. Haz clic en el nombre del clúster que deseas modificar.

  3. En Herramientas de redes, en el campo Proveedor de DNS, haz clic en Editar proveedor de DNS.

  4. Haz clic en Cloud DNS.

  5. Haz clic en Permiso de la VPC.

  6. Haga clic en Guardar cambios.

Verifica Cloud DNS

Verifica que Cloud DNS para GKE funcione de forma correcta en tu clúster:

  1. Para verificar que los nodos usen Cloud DNS, conéctate a un Pod en un nodo y ejecuta el comando cat /etc/resolv.conf:

    kubectl exec -it POD_NAME -- cat /etc/resolv.conf | grep nameserver

    Reemplaza POD_NAME con el nombre del pod.

    Según el modo de clúster, el resultado es similar al siguiente:

    Clúster de GKE Autopilot

    nameserver 169.254.20.10

    Debido a que NodeLocal DNSCache está habilitado de forma predeterminada en GKE Autopilot, el Pod usa NodeLocal DNSCache.

    Solo cuando la caché local no tiene una entrada para el nombre que se busca, NodeLocal DNSCache reenvía la solicitud a Cloud DNS.

    Clúster de GKE Standard

    nameserver 169.254.169.254

    El Pod usa 169.254.169.254 como nameserver, que es la dirección IP del servidor de metadatos en el que el plano de datos de Cloud DNS escucha las solicitudes en el puerto 53. Los nodos ya no usan la dirección del servicio kube-dns para la resolución de DNS, y toda la resolución de DNS se produce en el nodo local.

    Si el resultado es una dirección IP similar a 10.x.y.10, el Pod usa kube-dns. Consulta la sección Soluciona problemas para comprender por qué tu Pod aún usa kube-dns.

    Si el resultado es 169.254.20.10, significa que habilitaste NodeLocal DNSCache en tu clúster y el Pod usa NodeLocal DNSCache.

  2. Implementa una aplicación de muestra en tu clúster.

    kubectl run dns-test --image us-docker.pkg.dev/google-samples/containers/gke/hello-app:2.0

  3. Expón la aplicación de muestra con un Service:

    kubectl expose pod dns-test --name dns-test-svc --port 8080

  4. Verifica que el Service se haya implementado de forma correcta:

    kubectl get svc dns-test-svc

    El resultado es similar a este:

    NAME           TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
dns-test-svc   ClusterIP   10.47.255.11    <none>        8080/TCP   6m10s

    El valor de CLUSTER-IP es la dirección IP virtual del clúster. En este ejemplo, la dirección IP virtual es 10.47.255.11.

  5. Verifica que el nombre de tu Service se haya creado como un registro en la zona de DNS privado para tu clúster:

    gcloud dns record-sets list \
    --zone=PRIVATE_DNS_ZONE \
    --name=dns-test-svc.default.svc.cluster.local.

    Reemplaza PRIVATE_DNS_ZONE por el nombre de la zona de DNS administrada.

    El resultado es similar a este:

    NAME: dns-test-svc.default.svc.cluster.local.
TYPE: A
TTL: 30
DATA: 10.47.255.11

Inhabilita Cloud DNS para GKE

Clúster de GKE Autopilot

No puedes inhabilitar Cloud DNS en un clúster de GKE Autopilot que se creó con Cloud DNS de forma predeterminada. Consulta los requisitos para obtener más información sobre los clústeres de Autopilot de GKE que usan Cloud DNS de forma predeterminada.

Clúster de GKE Standard

Puedes inhabilitar el permiso del clúster de Cloud DNS con la CLI de gcloud o la consola de Google Cloud en un clúster de GKE Standard.

gcloud

Actualiza el clúster para usar kube-dns:

gcloud container clusters update CLUSTER_NAME \
    --cluster-dns=default

Consola

  1. Ve a la página de Google Kubernetes Engine en la consola de Google Cloud.

    Ir a Google Kubernetes Engine

  2. Haz clic en el nombre del clúster que deseas modificar.

  3. En Herramientas de redes, en el campo Proveedor de DNS, haz clic en Editar proveedor de DNS.

  4. Haz clic en Kube-dns.

  5. Haz clic en Guardar cambios.

Inhabilita el permiso adicional de VPC de Cloud DNS

Cuando inhabilitas el permiso adicional de VPC de Cloud DNS para tu clúster, solo se borran los registros DNS de las zonas privadas conectadas a la red de VPC. Los registros en las zonas privadas del DNS del clúster de GKE permanecerán administrados por Cloud DNS para GKE hasta que el Service sin interfaz gráfica se borre del clúster.

Para inhabilitar el permiso adicional de VPC de Cloud DNS, ejecuta el siguiente comando:

gcloud container clusters update CLUSTER_NAME \
    --disable-additive-vpc-scope

Reemplaza CLUSTER_NAME por el nombre del clúster.

Esto mantendrá habilitado el clúster con el permiso del clúster de Cloud DNS para proporcionar resolución de DNS desde el clúster.

Limpia

Después de completar los ejercicios de esta página, sigue estos pasos para quitar los recursos a fin de prevenir cobros no deseados en tu cuenta:

  1. Borra el servicio:

    kubectl delete service dns-test-svc

  2. Borra el Pod:

    kubectl delete Pod dns-test

  3. También puedes borrar el clúster.

Usa Cloud DNS con una VPC compartida

Cloud DNS para GKE admite la VPC compartida para la VPC y el permiso del clúster.

El controlador de GKE crea una zona privada administrada en el mismo proyecto que el clúster de GKE.

La cuenta de servicio de GKE para el clúster de GKE no requiere la administración de identidades y accesos (IAM) para el DNS fuera de su propio proyecto porque la zona administrada y el clúster de GKE residen dentro del mismo proyecto.

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. Si ya tienes clústeres que usan la VPC compartida y el permiso de la VPC de Cloud DNS, debes migrarlos de forma manual con los siguientes pasos:

  • Actualiza tus clústeres existentes con la VPC compartida habilitada en la versión 1.22.3-gke.700+ o 1.21.6-gke.1500+ de GKE.
  • Migra la política de respuesta del proyecto de servicio al proyecto host. Solo debes realizar esta migración una vez por cada red de VPC compartida.

Puedes migrar tu política de respuesta con la consola de Google Cloud.

Realiza los siguientes pasos en tu proyecto de servicio:

  1. Ir a la página Zonas de Cloud DNS

    Ir a Zonas de Cloud DNS

  2. Haz clic en la pestaña Zonas de políticas de respuesta.

  3. Haz clic en la política de respuesta de tu red de VPC. Puedes identificar la política de respuesta por la descripción, que es similar a “Política de respuesta para clústeres de GKE en la red NETWORK_NAME”.

  4. Haz clic en la pestaña En uso por.

  5. Junto al nombre de tu proyecto host, haz clic en para quitar la vinculación de red.

  6. Haz clic en la pestaña Reglas de las políticas de respuesta.

  7. Selecciona todas las entradas en la tabla.

  8. Haz clic en Quitar reglas de la política de respuesta.

  9. Haz clic en Borrar política de respuesta.

Después de borrar la política de respuesta, el controlador de DNS crea la política de respuesta en el proyecto host de forma automática. Los clústeres de otros proyectos de servicio comparten esta política de respuesta.

Compatibilidad con dominios de stub personalizados y servidores de nombres ascendentes

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.

Problemas conocidos

Terraform tiene previsto volver a crear el clúster de Autopilot debido al 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 la versión 1.25.9-gke.400, 1.26.4-gke.500, 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 lifecycle.ignore_changes al recurso para asegurarte de que google_container_cluster ignore los cambios en dns_config:

  lifecycle {
    ignore_changes = [
      dns_config,
    ]
  }

Soluciona problemas

Si deseas obtener información para habilitar el registro de DNS, consulta Habilita o inhabilita el registro para zonas administradas privadas.

Para obtener más información sobre cómo solucionar problemas de DNS, consulta Solución de problemas de DNS en GKE.

No se puede actualizar el clúster existente ni crear uno con Cloud DNS habilitado

Asegúrate de usar la versión correcta. Cloud DNS para GKE requiere la versión 1.19 o posterior de GKE para los clústeres que usan el permiso de VPC, o la versión 1.24.7-gke.800, 1.25.3-gke.700 o posterior para los clústeres que usan el permiso del clúster.

Los Pods usan kube-dns incluso después de que se habilite Cloud DNS en un clúster existente.

Asegúrate de haber actualizado o recreado tus grupos de nodos después de habilitar Cloud DNS en el clúster. Hasta que este paso esté completo, los Pods seguirán usando kube-dns.

El Pod no puede resolver las búsquedas de DNS

  1. Para verificar que el Pod use Cloud DNS, conéctate a un Pod y ejecuta el comando cat /etc/resolv.conf:

    kubectl exec -it POD_NAME -- cat /etc/resolv.conf | grep nameserver

    Reemplaza POD_NAME con el nombre del pod.

    El resultado es similar a este:

    nameserver 169.254.169.254

    Si el resultado es una dirección IP similar a 10.x.y.10 o 34.118.224.10 (solo en clústeres de GKE Autopilot con las versiones 1.27 y posteriores), el Pod usa kube-dns. Si el resultado es 169.254.20.10, el Pod usa NodeLocal DNSCache.

  2. Confirma que la zona administrada existe y contiene la entrada de DNS necesaria:

    gcloud dns managed-zones list --format list

    El resultado es similar a este:

     - creationTime: 2021-02-12T19:24:37.045Z
   description: Private zone for GKE cluster "cluster1" with cluster suffix "cluster.local" in project "project-243723"
   dnsName: cluster.local.
   id: 5887499284756055830
   kind: dns#managedZone
   name: gke-cluster1-aa94c1f9-dns
   nameServers: ['ns-gcp-private.googledomains.com.']
   privateVisibilityConfig: {'kind': 'dns#managedZonePrivateVisibilityConfig'}
   visibility: private

    El valor de name en la respuesta muestra que Google Cloud creó una zona privada llamada gke-cluster1-aa94c1f9-dns.

  3. Verifica que Cloud DNS contenga entradas para tu clúster:

    gcloud dns record-sets list --zone ZONE_NAME | grep SERVICE_NAME

    Reemplaza lo siguiente:

    • ZONE_NAME: El nombre de la zona privada
    • SERVICE_NAME: El nombre del servicio

    El resultado muestra que Cloud DNS contiene un registro A para el dominio dns-test.default.svc.cluster.local. y la dirección IP de tu clúster, 10.47.255.11:

    dns-test.default.svc.cluster.local.                A     30     10.47.255.11

  4. Habilita el registro de Cloud DNS para realizar un seguimiento de las consultas. Cada entrada de registro contiene información sobre la consulta, incluida la latencia de DNS.

Las búsquedas de DNS en los nodos fallan después de habilitar Cloud DNS en un clúster

Si habilitas el permiso del clúster de Cloud DNS en un clúster de GKE que tiene dominios de stub personalizados o servidores de nombres ascendentes, la configuración personalizada se aplica a los nodos y a los Pods del clúster porque Cloud DNS no puede distinguir entre un Pod y un nodo de solicitudes de DNS Las búsquedas de DNS en los nodos pueden fallar si el servidor ascendente personalizado no puede resolver las consultas.

No se puede actualizar el clúster existente ni crear uno con el permiso adicional de VPC de Cloud DNS habilitado

Asegúrate de usar la versión correcta. El permiso adicional de VPC de Cloud DNS requiere la versión de GKE 1.28 o posterior.

El Pod no puede resolver las búsquedas de DNS

  1. Para verificar que el Pod use Cloud DNS, conéctate a un Pod y ejecuta el comando cat /etc/resolv.conf:

    kubectl exec -it POD_NAME -- cat /etc/resolv.conf | grep nameserver

    Reemplaza POD_NAME con el nombre del pod.

    El resultado es similar a este:

    nameserver 169.254.169.254

    Si el resultado es una dirección IP similar a 10.x.y.10 o 34.118.224.10 (solo en clústeres de GKE Autopilot con las versiones 1.27 y posteriores), el Pod usa kube-dns. Si el resultado es 169.254.20.10, el Pod usa NodeLocal DNSCache.

  2. Confirma que la zona administrada existe y contiene la entrada de DNS necesaria:

    gcloud dns managed-zones list --format list

    El resultado es similar a este:

    gke-cluster-1-cbdc0678-dns  cluster.local.   Private zone for GKE cluster "cluster-1" with cluster suffix "cluster.local." in project "PROJECT_NAME" with scope "CLUSTER_SCOPE"  private
gke-cluster-1-cbdc-dns-vpc  CLUSTER_DOMAIN.  Private zone for GKE cluster "cluster-1" with cluster suffix "CLUSTER_DOMAIN." in project "PROJECT_NAME" with scope "VPC_SCOPE"     private

    El valor de name en la respuesta muestra que Google Cloud creó una zona privada llamada gke-cluster1-aa94c1f9-dns.

  3. Verifica que Cloud DNS contenga entradas para tu clúster en zonas administradas:

    gcloud dns record-sets list --zone ZONE_NAME | grep SERVICE_NAME

    Reemplaza lo siguiente:

    • ZONE_NAME: El nombre de la zona privada
    • SERVICE_NAME: El nombre del servicio

    El resultado es similar al siguiente:

    my-service.default.svc.cluster.local.                A     30     10.47.255.11

    El valor de name en la respuesta muestra que Google Cloud creó una zona privada llamada gke-cluster1-aa94c1f9-dns.

  4. Para las búsquedas de DNS inversas, verifica que Cloud DNS contenga entradas para tu clúster en políticas de respuesta:

    gcloud dns response-policies list --format="table(responsePolicyName, description)"

    El resultado es similar al siguiente:

      gke-NETWORK_HASH-rp        Response Policy for GKE clusters on network "VPC_NAME".
  gke-cluster-1-52c8f518-rp  Response Policy for GKE cluster "cluster-1" with cluster suffix "cluster.local." in project "khamed-gke-dev" with scope "CLUSTER_SCOPE".

    El valor de name en la respuesta muestra que Google Cloud creó una zona privada llamada gke-cluster1-aa94c1f9-rp.

  5. Para las búsquedas de DNS inversas, verifica que Cloud DNS contenga entradas para tu clúster en políticas de respuesta:

      gcloud dns response-policies rules list ZONE_NAME --format="table(localData.localDatas[0].name, localData.localDatas[0].rrdatas[0])"

    Reemplaza ZONE_NAME por el nombre de la zona privada.

    El resultado es similar al siguiente:

      1.240.27.10.in-addr.arpa.    kubernetes.default.svc.cluster.local.
  52.252.27.10.in-addr.arpa.   default-http-backend.kube-system.svc.cluster.local.
  10.240.27.10.in-addr.arpa.   kube-dns.kube-system.svc.cluster.local.
  146.250.27.10.in-addr.arpa.  metrics-server.kube-system.svc.cluster.local.

¿Qué sigue?