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

Si se usa Cloud DNS como proveedor de DNS, los clientes que no estén en un clúster no podrán resolver y acceder directamente a los servicios de Kubernetes. Aun así, debes exponer los servicios externamente mediante un balanceador de carga y registrar las direcciones IP externas de su clúster en tu infraestructura de DNS.

Para obtener más información sobre cómo usar kube-dns como proveedor de DNS, consulta Descubrimiento de servicios y DNS.

Para saber cómo usar una versión personalizada de kube-dns o un proveedor de DNS personalizado, consulta Configurar un despliegue personalizado de kube-dns.

Cómo funciona Cloud DNS para GKE

Cloud DNS se puede usar como proveedor de DNS para GKE, lo que permite la resolución de DNS de pods y servicios con DNS gestionado que no requiere 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 ofrece 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ítica de respuesta.

Usar Cloud DNS como proveedor de DNS para GKE ofrece muchas ventajas con respecto al DNS alojado en el clúster:

• Elimina la sobrecarga de gestión del servidor DNS alojado en el clúster. Cloud DNS no requiere escalar, monitorizar ni gestionar instancias de DNS, ya que es un servicio totalmente gestionado alojado en la infraestructura de Google, que es altamente escalable.
• Resolución local de consultas DNS en cada nodo de GKE. Al igual que NodeLocal DNSCache, Cloud DNS almacena en caché las respuestas DNS de forma local, lo que proporciona una resolución de DNS de baja latencia y alta escalabilidad.
• Integración con Google Cloud Observability para la monitorización y el registro de 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 servicio backend selecciona los pods backend en ejecución. El clouddns-controller crea un registro DNS para el servicio backend.

El pod frontend 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 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. En función del tipo de servicio de Kubernetes, Cloud DNS resuelve el nombre del servicio en su dirección IP virtual (en el caso de los servicios de IP de clúster) o en la lista de direcciones IP de endpoint (en el caso de los servicios sin encabezado).

Una vez que el pod frontend resuelve la dirección IP, puede enviar tráfico al servicio backend y a los pods que haya detrás.

Á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 son visibles 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.local Este 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 conectados mediante Cloud VPN o Cloud Interconnect. El ámbito de VPC adicional es un modo adicional que se habilita junto con el ámbito de clúster. Puedes habilitarlo o inhabilitarlo en tu clúster sin que afecte al tiempo de actividad ni a la capacidad del DNS (ámbito de 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 resolver directamente los nombres de servicio de GKE. Debes definir un dominio personalizado único para cada clúster, lo que significa que todos los registros DNS de servicios y pods 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:

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.

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

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

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

Para dar servicio al tráfico de DNS interno, el controlador de Cloud DNS crea una zona de DNS gestionada 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 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 ..

Requisitos

La API Cloud DNS debe estar habilitada en tu proyecto.

Cloud DNS para GKE tiene los siguientes requisitos para el ámbito del clúster:

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

Cloud DNS para GKE tiene los siguientes requisitos para el ámbito de VPC aditivo:

• GKE 1.28.3-gke.1430000 o una versión posterior.
• Tener instalada la versión 503.0.0 o una posterior de Google Cloud CLI.
• El clúster de GKE debe usar el ámbito de clúster de Cloud DNS como proveedor de DNS predeterminado.

Cloud DNS para GKE tiene los siguientes requisitos para el ámbito de VPC:

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

Restricciones y limitaciones

Se aplican las siguientes limitaciones:

• El ámbito de VPC no se admite en los clústeres de Autopilot, solo se admite el ámbito de clúster. Si necesitas resolver nombres de servicios sin interfaz gráfica que se ejecutan en clústeres de GKE Autopilot, debes usar el ámbito de VPC aditivo.

• Solo puedes habilitar el ámbito de VPC aditivo en clústeres de GKE Autopilot al crear el clúster. No se puede habilitar ni inhabilitar el ámbito de VPC aditivo en clústeres Autopilot de GKE.

• No se pueden crear clústeres con ámbito de VPC aditivo en proyectos de servicio de redes de VPC compartidas.

• Cloud DNS para GKE no está disponible para Assured Workloads con un régimen de cumplimiento de IL4. kube-dns se fuerza en estos entornos regulados.

• No se admiten los cambios manuales en las zonas DNS privadas gestionadas, ya que el controlador de Cloud DNS los sobrescribe. Las modificaciones en los registros DNS de esas zonas no se conservan cuando se reinicia el controlador.

• Después de habilitar Cloud DNS para GKE en un clúster, kube-dns sigue ejecutándose en el clúster. Para inhabilitar kube-dns, reduce a cero el escalado del despliegue y del escalador automático de kube-dns.

• No puedes cambiar el ámbito de DNS de un clúster después de haberlo definido con la marca --cluster-dns-scope. Si necesitas cambiar el ámbito de DNS, vuelve a crear el clúster con otro ámbito de DNS.

• Se aplican las limitaciones de los recursos de Cloud DNS. En concreto, solo se puede vincular una zona de política de respuesta a una red de VPC a la vez. En el caso de los clústeres con ámbitos de VPC y de VPC aditivos, la creación falla si ya hay una zona de política de respuestas que no sigue la convención de nomenclatura vinculada a la red de VPC del clúster.

• Las configuraciones de servidores DNS upstream y dominios stub personalizados se aplican a las configuraciones de DNS de pods y nodos. Los pods que usan redes de host o los procesos que se ejecutan directamente en el host también usan el dominio stub y las configuraciones de servidores de nombres upstream. Esta opción solo está disponible en el plan Estándar.

• Los dominios stub personalizados y los servidores de nombres upstream configurados a través de kube-dns ConfigMap se aplican automáticamente a Cloud DNS para el DNS de ámbito de clúster. El DNS con ámbito de VPC ignora el ConfigMap kube-dns y debes aplicar estas configuraciones directamente en Cloud DNS. Esta opción solo está disponible en el plan Estándar.

• No hay ninguna ruta de migración de kube-dns al ámbito de VPC, por lo que la operación es disruptiva. Vuelve a crear el clúster cuando cambies de kube-dns a ámbito de VPC o viceversa.

• En el caso del ámbito de la VPC, el intervalo de direcciones IP secundarias de los servicios no se debe compartir con ningún otro clúster de esa subred.

• En el ámbito de la VPC, la política de respuesta asociada a un registro PTR se adjunta a la red de VPC. Si hay otras políticas de respuesta vinculadas a la red del clúster, la resolución de registros PTR falla para las direcciones IP de servicio de Kubernetes.

• Si intentas crear un servicio sin interfaz gráfica con un número de pods que supere la cuota permitida, Cloud DNS no creará conjuntos de registros ni registros para el servicio.

• Los nombres de servicios y puertos están limitados a 62 caracteres, aunque las etiquetas DNS tienen un límite máximo de 63 caracteres. Esto se debe a que GKE añade un prefijo de guion bajo a los registros 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 de tu proyecto.

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

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:

Para obtener más información sobre cómo se crean los registros DNS de Kubernetes, consulta el artículo Descubrimiento de servicios basado en DNS de Kubernetes.

Antes de empezar

Antes de empezar, asegúrate de que has realizado las siguientes tareas:

• Habilita la API de Google Kubernetes Engine.
Habilitar la API de Google Kubernetes Engine
• Si quieres usar Google Cloud CLI para esta tarea, instálala y, a continuación, inicialízala. Si ya has instalado la gcloud CLI, obtén la versión más reciente ejecutando gcloud components update.

• Habilita la API Cloud DNS en tu proyecto:

  Habilitar la API de Cloud DNS

Habilitar el DNS de ámbito de clúster

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

En el siguiente diagrama se muestra cómo crea Cloud DNS 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 ámbito de DNS.

Habilitar el DNS de ámbito de clúster en un clúster nuevo

Clúster de Autopilot de GKE

Los nuevos clústeres de Autopilot de las versiones 1.25.9-gke.400, 1.26.4-gke.500 o posteriores tienen de forma predeterminada el ámbito de clúster de Cloud DNS.

Clúster de GKE Standard

Puedes crear un clúster estándar de GKE con el ámbito de clúster de Cloud DNS habilitado mediante la CLI de gcloud o la Trusted Cloud consola:

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

Habilitar el DNS de ámbito de clúster en un clúster

Clúster de Autopilot de GKE

No puedes migrar un clúster de Autopilot de GKE de kube-dns a un permiso de clúster de Cloud DNS. Para habilitar el ámbito de clúster de Cloud DNS, vuelve a crear los clústeres de Autopilot en la versión 1.25.9-gke.400, 1.26.4-gke.500 o posterior.

Clúster de GKE Standard

Puedes migrar un clúster estándar de GKE de kube-dns a Cloud DNS con ámbito de clúster mediante la CLI de gcloud o laTrusted Cloud consola en un clúster estándar de GKE.

Cuando migras un clúster, 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 en un clúster, los ajustes solo se aplicarán si actualizas los grupos de nodos o añades grupos de nodos 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 habilitando Cloud DNS como proveedor de DNS en cada grupo de nodos por separado. Un subconjunto de los nodos está operativo en todo momento, ya que algunos grupos de nodos usan kube-dns y otros usan Cloud DNS.

En los pasos siguientes, habilitará Cloud DNS en un clúster y, a continuación, actualizará sus grupos de nodos. Al actualizar los grupos de nodos, se vuelven a crear los nodos. Los nodos usan Cloud DNS para la resolución de DNS en lugar de kube-dns.

Habilitar el ámbito de VPC aditivo de Cloud DNS

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

Habilitar el ámbito de VPC aditivo de Cloud DNS en un clúster nuevo

Puedes habilitar el DNS de ámbito de VPC en un clúster de GKE nuevo mediante la CLI de gcloud o la Trusted Cloud consola.

Para Autopilot

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

Haz los cambios siguientes:

• CLUSTER_NAME: el nombre del clúster.
• UNIQUE_CLUSTER_DOMAIN: el nombre de un dominio. Debes asegurarte de que este nombre sea único en la VPC, ya que GKE no confirma este valor. No puedes cambiar este valor una vez que se haya definido. No debes usar un dominio que termine en ".local", ya que podrías tener problemas con la resolución de DNS.

Estándar

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

La marca --cluster-dns-scope=cluster es opcional porque cluster es el valor predeterminado.

Haz los cambios siguientes:

• CLUSTER_NAME: el nombre del clúster.
• UNIQUE_CLUSTER_DOMAIN: el nombre de un dominio. Debes asegurarte de que este nombre sea único en la VPC, ya que GKE no confirma este valor. No puedes cambiar este valor una vez que se haya definido. No debes usar un dominio que termine en ".local", ya que podrías tener problemas con la resolución de DNS.

Habilitar el ámbito de VPC aditivo de Cloud DNS en un clúster

Para habilitar el ámbito de VPC adicional de Cloud DNS en un clúster, primero debes habilitar Cloud DNS en el clúster y, a continuación, actualizar tus grupos de nodos. Al actualizar los grupos de nodos, se vuelven a crear los nodos. Los nodos usan Cloud DNS para la resolución de DNS en lugar de kube-dns.

Para habilitar el ámbito de VPC aditivo de Cloud DNS en un clúster, sigue estos pasos:

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

Haz los cambios siguientes:

• CLUSTER_NAME: el nombre del clúster.
• UNIQUE_CLUSTER_DOMAIN: el nombre de un dominio. Debes asegurarte de que este nombre sea único en la VPC, ya que GKE no confirma este valor. No puedes cambiar este valor una vez que se haya definido. No debes usar un dominio que termine en ".local", ya que podrías tener problemas con la resolución de DNS.
• COMPUTE_LOCATION: la ubicación de Compute Engine del clúster.

Habilitar el DNS de ámbito de VPC

En el DNS de ámbito de VPC, los nombres de DNS de un clúster se pueden resolver en toda la VPC. Cualquier cliente de la VPC puede resolver registros DNS del clúster.

El DNS con ámbito de VPC permite los siguientes casos prácticos:

• Descubrimiento de servicios sin encabezado para clientes que no son de GKE en la misma VPC.
• Resolución de servicios de GKE desde clientes locales o de nubes de terceros. Para obtener más información, consulta la política de servidores entrantes.
• Resolución de servicios en la que un cliente puede decidir con qué clúster quiere comunicarse mediante el dominio DNS del clúster personalizado.

En el siguiente diagrama, dos clústeres de GKE usan DNS con ámbito 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 máquina virtual se comunica con el servicio backend sin interfaz gráfica resolviendo backend.default.svc.cluster1. Cloud DNS resuelve el servicio sin encabezado en las IPs de los pods individuales del servicio y la VM se comunica directamente con las direcciones IP de los pods.

También puedes realizar este tipo de resolución desde otras redes cuando estén conectadas a la VPC a través de Cloud Interconnect o Cloud VPN. Las políticas de servidor DNS permiten que los clientes de las redes conectadas a la VPC resuelvan nombres en Cloud DNS, lo que incluye los servicios de GKE si el clúster usa DNS con ámbito de VPC.

Habilitar el DNS de ámbito de VPC en un clúster

La migración solo se admite en GKE Standard, no en GKE Autopilot.

Clúster de Autopilot de GKE

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

Clúster de GKE Standard

Puedes migrar un clúster de GKE de kube-dns a Cloud DNS con ámbito de VPC mediante gcloud CLI o la Trusted Cloud consola.

Después de habilitar Cloud DNS en un clúster, los ajustes solo se aplicarán si actualizas los grupos de nodos o añades grupos de nodos al clúster. Cuando actualizas un grupo de nodos, los nodos se vuelven a crear.

En los pasos siguientes, habilitará Cloud DNS en un clúster y, a continuación, actualizará sus grupos de nodos. Al actualizar los grupos de nodos, se vuelven a crear los nodos. Los nodos usan Cloud DNS para la resolución de DNS en lugar de kube-dns.

Verificar Cloud DNS

Verifica que Cloud DNS para GKE funcione correctamente en tu clúster:

1. Para comprobar que tus nodos usan Cloud DNS, conéctate a un pod de un nodo y ejecuta el comando cat /etc/resolv.conf:

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

   Sustituye POD_NAME por el nombre del pod.

   En función del modo de clúster, la salida será similar a la siguiente:

   Clúster de Autopilot de GKE

   nameserver 169.254.20.10
   

   Como NodeLocal DNSCache está habilitado de forma predeterminada en GKE Autopilot, el pod usa NodeLocal DNSCache.

   NodeLocal DNSCache solo reenvía la solicitud a Cloud DNS cuando la caché local no tiene una entrada para el nombre que se está buscando.

   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 la salida es una dirección IP similar a 10.x.y.10, el pod está usando kube-dns. Consulta la sección Solución de problemas para saber por qué tu pod sigue usando kube-dns.

   Si el resultado es 169.254.20.10, significa que has habilitado NodeLocal DNSCache en tu clúster y que el pod está usando NodeLocal DNSCache.

2. Despliega una aplicación de ejemplo 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 ejemplo con un servicio:

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

4. Comprueba que el servicio se haya implementado correctamente:

   kubectl get svc dns-test-svc
   

   El resultado debería ser 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 de tu clúster. En este ejemplo, la dirección IP virtual es 10.47.255.11.

5. Verifica que el nombre del servicio se haya creado como un registro en la zona DNS privada de tu clúster:

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

   Sustituye PRIVATE_DNS_ZONE por el nombre de la zona DNS gestionada.

   El resultado debería ser similar al siguiente:

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

Inhabilitar Cloud DNS para GKE

Clúster de Autopilot de GKE

No puedes inhabilitar Cloud DNS en un clúster Autopilot de GKE que se haya creado 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 ámbito de clúster de Cloud DNS mediante la CLI de gcloud o la Trusted Cloud consola en un clúster estándar de GKE.

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

Después de inhabilitar Cloud DNS en los clústeres estándar, actualiza los grupos de nodos asociados a tus clústeres. También puedes crear un nuevo grupo de nodos y programar tu carga de trabajo allí. Si no actualizas tus grupos de nodos, el espacio de nombres DNS seguirá apuntando a Cloud DNS, no a kube-dns.

Inhabilitar el ámbito de VPC aditivo de Cloud DNS

Cuando inhabilitas el ámbito de VPC aditivo de Cloud DNS en tu clúster, solo se eliminan los registros DNS de las zonas privadas asociadas a la red de VPC. Los registros de las zonas DNS privadas del clúster de GKE se mantendrán, gestionados por Cloud DNS para GKE, hasta que se elimine el servicio sin encabezado del clúster.

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

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

Sustituye CLUSTER_NAME por el nombre del clúster.

De esta forma, el clúster mantendrá habilitado el ámbito de clúster de Cloud DNS para proporcionar resolución de DNS desde el clúster.

Limpieza

Después de completar los ejercicios de esta página, sigue estos pasos para quitar recursos y evitar que se apliquen cargos no deseados a tu cuenta:

1. Elimina el servicio:

   kubectl delete service dns-test-svc
   

2. Elimina el pod:

   kubectl delete Pod dns-test
   

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

Usar Cloud DNS con VPC compartida

Cloud DNS para GKE admite VPC compartida tanto para el ámbito de la VPC como para el del clúster.

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

La cuenta de servicio de GKE del clúster de GKE no requiere Gestión de Identidades y Accesos (IAM) para el DNS fuera de su propio proyecto, ya que la zona gestionada y el clúster de GKE se encuentran en el 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 una VPC compartida y un ámbito de VPC de Cloud DNS, debes migrarlos manualmente siguiendo estos pasos:

• Actualiza los clústeres que tengan habilitada la VPC compartida a la versión 1.22.3-gke.700+ o 1.21.6-gke.1500+ de GKE.
• Migra la política de respuestas del proyecto de servicio al proyecto del host. Solo tienes que realizar esta migración una vez por cada red de VPC compartida.

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

Sigue estos pasos en tu proyecto de servicio:

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

   Ir a las zonas de Cloud DNS

2. Haga clic en la pestaña Zonas de política de respuesta.

3. Haz clic en la política de respuestas 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 del proyecto anfitrión, haz clic en delete para quitar la vinculación de red.

6. Haga clic en la pestaña Reglas de política de respuesta.

7. Selecciona todas las entradas de la tabla.

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

9. Haz clic en delete Eliminar política de respuesta.

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

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, se han añadido elementos a 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, mientras que 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.

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: Cloud DNS suele crear registros SRV para la detección de servicios. Estos registros proporcionan información sobre el puerto y el protocolo del servicio. Registros AAAA (para doble pila): en las configuraciones de doble pila (IPv4 e 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. Por lo general, estos registros no son directamente relevantes para los usuarios. Servicios LoadBalancer: en el caso de 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.

Además de estos registros mínimos, Cloud DNS puede crear registros SRV y, en el caso de las pilas duales, 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 creen dependerán de factores como el tipo de servicio y la configuración.

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 Terraform intente recrear 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 posterior 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 Trusted Cloud by S3NS.

Si no puede actualizar la versión de terraform-provider-google o terraform-provider-google-beta, puede añadir lifecycle.ignore_changes al recurso para asegurarse de que google_container_cluster ignore los cambios en dns_config:

  lifecycle {
    ignore_changes = [
      dns_config,
    ]
  }

Fallo en la resolución de DNS después de migrar de kube-dns a Cloud DNS con NodeLocal DNSCache habilitado

En esta sección se describe un problema conocido que se produce en los clústeres de GKE en Cloud DNS con NodeLocal DNSCache en el ámbito del clúster.

Después de migrar de kube-DNS a Cloud DNS con NodeLocal DNSCache habilitado en el clúster, es posible que el clúster experimente errores de resolución intermitentes.

Cuando se usa 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 Dataplane V2 está habilitado en el clúster mientras se usa kube-dns, NodeLocal DNSCache se ejecuta en una red aislada y está configurado para escuchar en 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

Después de actualizar el clúster a Cloud DNS, se cambia la configuración de NodeLocal DNSCache. Comprueba NodeLocal DNSCache:

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

El siguiente flujo de trabajo explica las entradas del archivo resolv.conf durante la migración y la recreación de nodos:

Antes de la migración

• Los pods tienen configurado resolv.conf en la IP de kube-dns (es decir, x.x.x.10).
• Los pods de caché local de nodos interceptan las solicitudes de DNS de los pods y escuchan lo siguiente:
  • (DPv1) ambas direcciones (bind 169.254.20.10 x.x.x.10).
  • (DPv2) Todas las direcciones IP de los pods (enlace 0.0.0.0).
• NodeLocal DNSCache funciona como caché y los pods de kube-dns no se ven sometidos a mucha presión.

Después de la migración

• Después de que el plano de control se actualice para usar Cloud DNS, los pods seguirán teniendo configurado resolv.conf con la IP de kube-dns (es decir, x.x.x.10). Esta configuración se mantiene porque GKE requiere que se vuelvan a crear los nodos para usar 169.254.20.10 .La configuración de Cloud DNS requiere 169.254.20.10
• Los pods de caché local de nodos solo escuchan en la dirección de NodeLocal DNSCache (enlace 169.254.20.10). La solicitud no se envía a los pods de caché local de nodos.
• Todas las solicitudes de los pods se envían directamente a los pods de kube-dns. Esta configuración genera un tráfico elevado en los pods.

Después de recrear los nodos o actualizar el grupo de nodos

• Los pods tienen resolv.conf configurado en la dirección IP de NodeLocal DNSCache (169.254.20.10).
• Los pods de caché local de nodos solo escuchan en la dirección de NodeLocal DNSCache (enlace 169.254.20.10) y reciben solicitudes de DNS de los pods de esta dirección IP.

Cuando los grupos de nodos usan la IP de kube-dns en resolv.conf antes de la recreación del grupo de nodos, un aumento del tráfico de consultas de DNS también aumenta el tráfico en los pods de kube-dns, lo que provoca errores intermitentes en las solicitudes de DNS. Para minimizar los errores, debes planificar esta migración durante los periodos de inactividad.

Solución de problemas

Para obtener información sobre cómo solucionar problemas de Cloud DNS, consulta las siguientes páginas:

• Para obtener asesoramiento sobre Cloud DNS en GKE, consulta el artículo Solucionar problemas de Cloud DNS en GKE.
• Para obtener asesoramiento específico sobre Cloud DNS, consulta el artículo Solucionar problemas de Cloud DNS.
• Para obtener consejos generales sobre cómo diagnosticar problemas de DNS de Kubernetes, consulta Depuración de la resolución de DNS.

Siguientes pasos

• Consulta una descripción general de cómo proporciona GKE DNS gestionado.
• Consulta el artículo DNS para servicios y pods para obtener una descripción general de cómo se usa el DNS en los clústeres de Kubernetes.
• Consulta información sobre los ámbitos y las jerarquías de Cloud DNS.
• Consulta información sobre cómo habilitar e inhabilitar el registro de zonas gestionadas privadas.