Usa Cloud DNS para GKE


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

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.

Descripción general

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 e 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 alojado de Google.
  • 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 en Google Cloud's operations suite para la supervisión y el registro de DNS
  • Un DNS de permiso de VPC para la resolución del servicio de Kubernetes de varios clústeres, varios entornos y VPC.

Arquitectura

Cuando Cloud DNS es el proveedor de DNS para GKE, un controlador se ejecuta como un Pod administrado por GKE. Este Pod sincroniza los registros DNS del clúster en una zona de DNS privada y 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 Pod frontend envía una solicitud de DNS para la dirección IP del servicio backend al servidor de metadatos local de Compute Engine en 169.254.169.254. Esta operación se ejecuta de manera local en el nodo y envía errores de caché a Cloud DNS.

El plano de datos de Cloud DNS se ejecuta localmente dentro de cada 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 o a la lista de direcciones IP de extremo.

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

Precios

Cuando Cloud DNS es el proveedor de DNS para GKE, las consultas de DNS de Pods dentro del clúster de GKE se facturan según los precios de Cloud DNS. Las consultas de DNS a una zona DNS de permiso del clúster administrada por GKE no se cobran durante la vista previa, pero se comenzará a facturar en la disponibilidad general (DG).

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

Requisitos

Cloud DNS para GKE tiene los siguientes requisitos:

  • Versión de GKE 1.18 o posterior para clústeres nuevos, o versión 1.19 o posterior de GKE para clústeres existentes.
  • SDK de Cloud versión 341.0.0 o posterior.

Restricciones

Cloud DNS para GKE tiene las siguientes restricciones:

  • Solo disponible para clústeres de GKE en Google Cloud.
  • Después de habilitar Cloud DNS para GKE en un clúster, no puedes inhabilitarlo en el clúster y kube-dns continuará ejecutándose en el clúster. Puedes inhabilitar kube-dns mediante el escalamiento de la implementación 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.
  • Cloud DNS es una infraestructura global con dependencias globales, diferente de los proveedores de DNS, como kube-dns, en los que toda la infraestructura de DNS existe de forma local dentro del clúster. Esta restricción solo se aplica durante la vista previa.
  • 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.
  • 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.
  • Para el alcance de VPC, el rango secundario de los servicios no se debe compartir con ningún otro clúster de esa subred.

Antes de comenzar

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

Establece la configuración de gcloud predeterminada mediante uno de los siguientes métodos:

  • Usa gcloud init si deseas ver una explicación sobre cómo configurar parámetros predeterminados.
  • Usa gcloud config para establecer el ID, la zona y la región del proyecto de manera individual.

Usa gcloud init

Si recibes el error One of [--zone, --region] must be supplied: Please specify location, completa esta sección.

  1. Ejecuta gcloud init y sigue las instrucciones:

    gcloud init

    Si usas SSH en un servidor remoto, usa la marca --console-only para evitar que el comando abra un navegador:

    gcloud init --console-only
  2. Sigue las instrucciones a fin de autorizar a gcloud para que use tu cuenta de Google Cloud.
  3. Crea una configuración nueva o selecciona una existente.
  4. Elige un proyecto de Google Cloud.
  5. Elige una zona predeterminada de Compute Engine para clústeres zonales o una región para clústeres regionales o de Autopilot.

Usa gcloud config

  • Establece tu ID del proyecto predeterminado:
    gcloud config set project PROJECT_ID
  • Si trabajas con clústeres zonales, establece tu zona de procesamiento predeterminada:
    gcloud config set compute/zone COMPUTE_ZONE
  • Si trabajas con clústeres de Autopilot o regionales, configura tu región de procesamiento predeterminada:
    gcloud config set compute/region COMPUTE_REGION
  • Actualiza gcloud a la versión más reciente:
    gcloud components update

DNS del permiso 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

Puedes crear un clúster con Cloud DNS del permiso del clúster habilitado con el siguiente comando:

gcloud beta container clusters create CLUSTER_NAME \
  --cluster-dns clouddns --cluster-dns-scope cluster \
  --cluster-version VERSION \
  [--zone ZONE_NAME | --region REGION_NAME]

Reemplaza lo siguiente:

  • CLUSTER_NAME: el nombre del clúster
  • VERSION: la versión de GKE, que debe ser 1.18 o posterior. También puedes usar la marca --release-channel para seleccionar un canal de versiones. El canal de versiones debe tener una versión predeterminada 1.18 o posterior.
  • ZONE_NAME o REGION_NAME: la ubicación del clúster. Estos argumentos son mutuamente excluyentes. Para obtener más información, consulta Tipos de clústeres.

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

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

Puedes migrar un clúster de GKE existente de kube-dns al permiso del clúster de Cloud DNS.

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 a los nodos de GKE nuevos que se agregan 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.

  1. Actualiza el clúster existente:

    gcloud beta container clusters update CLUSTER_NAME \
      --cluster-dns clouddns --cluster-dns-scope cluster
    

    Reemplaza lo siguiente:

    • CLUSTER_NAME: el nombre del clúster

    La respuesta es similar al ejemplo a continuación:

    Enabling CloudDNS is a one-way operation. Once enabled, this
    configuration cannot be disabled. All the node pools in the cluster
    need to be re-created by the user to start using CloudDNS for DNS
    lookups. It is highly recommended to complete this step shortly after
    enabling CloudDNS.
    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 usan Cloud DNS para la resolución de DNS hasta que vuelvas a crear tus nodos o agregues nodos nuevos al clúster.

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

    gcloud beta container clusters upgrade CLUSTER_NAME \
      --node-pool POOL_NAME \
      --cluster-version VERSION
    

    Reemplaza lo siguiente:

    • CLUSTER_NAME: el nombre del clúster
    • POOL_NAME: el nombre del grupo de nodos que se actualizará
    • VERSION: la versión de GKE, que debe ser 1.18 o posterior. También puedes usar la marca --release-channel para seleccionar un canal de versiones. El canal de versiones debe tener una versión predeterminada 1.18 o posterior.

    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 de forma manual 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.

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

    El resultado es similar al siguiente:

    nameserver 169.254.169.254
    

    Si el resultado es una dirección IP similar a 10.x.y.10, el Pod usa kube-dns. Si el resultado es 169.254.20.10, el Pod usa NodeLocalDNS. 169.254.169.254 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.

Verifica el DNS del permiso del clúster

A fin de verificar que Cloud DNS para GKE funcione de forma correcta en tu clúster, sigue estos pasos:

  1. Implementa una aplicación de ejemplo en tu clúster con el siguiente comando:

    kubectl run dns-test --image gcr.io/google-samples/hello-app:2.0
    
  2. Use el siguiente comando para exponer la aplicación de ejemplo mediante un servicio:

    kubectl expose pod dns-test --name dns-test-svc --port 8080
    
  3. Verifica que el servicio se haya implementado de forma correcta:

    kubectl get svc dns-test-svc
    

    El resultado es similar al siguiente:

    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.

  4. Conéctate a un Pod mediante kubectl exec y resuelve el nombre del servicio con el comando nslookup para confirmar que Cloud DNS esté entregando registros DNS dentro del clúster:

    kubectl exec -it dns-test -- nslookup dns-test-svc
    

    El resultado es similar al siguiente:

    Server:   169.254.169.254
    Address:  169.254.169.254#53
    
    Non-authoritative answer:
    Name: dns-test-svc.default.svc.cluster.local
    Address: 10.47.255.11
    

    La respuesta muestra que Cloud DNS resolvió el nombre del servicio dns-test-svc en la IP virtual del clúster, 10.47.255.11.

Realice una limpieza

Después de completar el ejercicio, 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.

DNS del permiso 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.
  • 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 resolver nombres en Cloud DNS, incluidos los servicios de GKE si el clúster usa DNS del permiso de VPC.

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

Puedes crear un clúster nuevo con Cloud DNS del permiso de VPC habilitado con el siguiente comando:

gcloud beta container clusters create CLUSTER_NAME \
  --cluster-dns clouddns --cluster-dns-scope vpc \
  --cluster-version VERSION \
  --cluster-dns-domain CUSTOM_DOMAIN \
  [--zone ZONE_NAME | --region REGION_NAME]

Reemplaza lo siguiente:

  • CLUSTER_NAME: el nombre del clúster
  • VERSION: la versión de GKE, que debe ser 1.18 o posterior. También puedes usar la marca --release-channel para seleccionar un canal de versiones. El canal de versiones debe tener una versión predeterminada 1.18 o posterior.
  • ZONE_NAME o REGION_NAME: la ubicación del clúster. Estos argumentos son mutuamente excluyentes. Para obtener más información, consulta Tipos de clústeres.
  • 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.

Usa Cloud DNS con 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.

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 el permiso del clúster de GKE.

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

Soluciona problemas

Consulta Depura la resolución de DNS para obtener información general sobre el diagnóstico de problemas de DNS de Kubernetes y Solución de problemas a fin de obtener más información sobre el diagnóstico de problemas con Cloud DNS.

También puedes habilitar Logging de Cloud DNS.

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.18 o posterior de GKE a fin de crear clústeres nuevos, o la versión 1.19 o posterior de GKE para clústeres existentes.

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 al siguiente:

    nameserver 169.254.169.254
    

    Si el resultado es una dirección IP similar a 10.x.y.10, el Pod usa kube-dns. Si el resultado es 169.254.20.10, el Pod usa NodeLocalDNS.

  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 al siguiente:

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

¿Qué sigue?