Información sobre el descubrimiento de servicios

En este documento se explica cómo el descubrimiento de servicios en Google Kubernetes Engine (GKE) simplifica la gestión de aplicaciones y cómo ampliar el descubrimiento de servicios más allá de un solo clúster mediante los ámbitos de Cloud DNS, los servicios multiclúster (MCS) y el directorio de servicios.

Este documento está dirigido a usuarios, desarrolladores, administradores y arquitectos de GKE. Para obtener más información sobre los roles habituales y las tareas de ejemplo a las que hacemos referencia en el contenido, consulta Roles y tareas habituales de los usuarios de GKE Enterprise. Google Cloud

Antes de leer este documento, asegúrese de que conoce los siguientes conceptos:

Información general

El descubrimiento de servicios es un mecanismo que permite que los servicios y las aplicaciones se encuentren y se comuniquen entre sí de forma dinámica sin codificar direcciones IP ni configuraciones de endpoints. El descubrimiento de servicios ayuda a que las aplicaciones siempre tengan acceso a direcciones IP de pods actualizadas, incluso cuando se reprograman pods o se añaden nuevos. GKE ofrece varias formas de implementar el descubrimiento de servicios, como kube-dns, implementaciones personalizadas de kube-dns y Cloud DNS. Puedes optimizar aún más el rendimiento de DNS con NodeLocal DNSCache.

Ventajas del descubrimiento de servicios

El descubrimiento de servicios ofrece las siguientes ventajas:

  • Gestión de aplicaciones simplificada: el descubrimiento de servicios elimina la necesidad de codificar direcciones IP en las configuraciones de tus aplicaciones. Las aplicaciones se comunican mediante nombres de servicio lógicos, que se resuelven automáticamente en las direcciones IP de los pods correctas. Este enfoque simplifica la configuración, sobre todo en entornos dinámicos en los que las direcciones IP de los pods pueden cambiar debido al escalado o a la reprogramación.
  • Escalado y resiliencia simplificados: el descubrimiento de servicios simplifica el escalado al desacoplar los consumidores de servicios de las direcciones IP de los pods, que cambian con frecuencia. Mientras tu aplicación se escala o si los pods fallan y se sustituyen, Kubernetes actualiza automáticamente los pods que están disponibles para recibir tráfico de un servicio determinado. El descubrimiento de servicios ayuda a garantizar que las solicitudes al nombre de servicio estable se dirijan solo a pods en buen estado, lo que permite que tu aplicación se escale o se recupere de errores sin intervención manual ni reconfiguración del cliente.
  • Alta disponibilidad: GKE usa el balanceo de carga junto con el descubrimiento de servicios para garantizar la alta disponibilidad y mejorar la capacidad de respuesta de tus aplicaciones, incluso con cargas elevadas.

Balanceo de carga con descubrimiento de servicios

GKE ayuda a garantizar la alta disponibilidad de tus aplicaciones combinando diferentes niveles de balanceo de carga con el descubrimiento de servicios.

  • Servicios internos: para los servicios a los que solo se puede acceder desde el clúster, el plano de datos de GKE (kube-proxy o Cilium) actúa como balanceador de carga. Distribuye el tráfico entrante de forma uniforme entre varios pods en buen estado, lo que evita la sobrecarga y ayuda a garantizar una alta disponibilidad.
  • Servicios externos: para los servicios a los que se debe acceder desde fuera del clúster, GKE aprovisiona Google Cloud balanceadores de carga. Estos balanceadores de carga incluyen Google Cloud balanceadores de carga externos Google Cloud para el acceso público a Internet y Google Cloud balanceadores de carga internos Google Cloud para el acceso dentro de tu red de nube privada virtual. Estos balanceadores de carga distribuyen el tráfico entre los nodos de tu clúster. A continuación, el plano de datos de cada nodo enruta el tráfico a los pods correspondientes.

Tanto en los casos internos como externos, el descubrimiento de servicios actualiza continuamente la lista de pods disponibles de cada servicio. Esta actualización continua ayuda a asegurar que tanto el plano de datos (para los servicios internos) como los balanceadores de carga (para los servicios externos) dirijan el tráfico solo a instancias en buen estado. Google Cloud

Casos prácticos de descubrimiento de servicios

A continuación se indican algunos casos prácticos habituales de la detección de servicios:

  • Arquitectura de microservicios: en una arquitectura de microservicios, las aplicaciones suelen constar de muchos servicios más pequeños e independientes que necesitan interactuar. El descubrimiento de servicios permite que estas aplicaciones se encuentren entre sí e intercambien información, incluso mientras se escala el clúster.
  • Habilita los despliegues sin tiempo de inactividad y mejora la resiliencia: el descubrimiento de servicios facilita las actualizaciones sin tiempo de inactividad de las aplicaciones, incluidos los lanzamientos controlados y los despliegues canary. Automatiza la detección de nuevas versiones de servicios y transfiere el tráfico a ellas, lo que ayuda a reducir el tiempo de inactividad durante el despliegue y a garantizar una transición fluida para los usuarios. El descubrimiento de servicios también mejora la resiliencia. Cuando un pod falla en GKE, se despliega uno nuevo y el descubrimiento de servicios registra el nuevo pod y redirige el tráfico a él, lo que ayuda a minimizar el tiempo de inactividad de la aplicación.

Cómo funciona el descubrimiento de servicios

En GKE, las aplicaciones suelen constar de varios pods que necesitan encontrarse y comunicarse entre sí. El descubrimiento de servicios proporciona esta función mediante el sistema de nombres de dominio (DNS). Al igual que usas DNS para encontrar sitios web en Internet, los pods de un clúster de GKE usan DNS para localizar servicios y conectarse a ellos mediante sus nombres de servicio. Este enfoque permite que los pods interactúen de forma eficaz, independientemente de dónde se ejecuten en el clúster, y permite que las aplicaciones se comuniquen mediante nombres de servicio coherentes en lugar de direcciones IP inestables.

Cómo realizan los pods la resolución de DNS

Los pods de un clúster de GKE resuelven los nombres de DNS de los servicios y otros pods mediante una combinación de registros de DNS generados automáticamente y su configuración de DNS local.

Nombres de DNS de servicio

Cuando creas un servicio de Kubernetes, GKE le asigna automáticamente un nombre de DNS. Este nombre sigue un formato predecible que cualquier Pod del clúster puede usar para acceder al Servicio:

<service-name>.<namespace>.svc.cluster.local

El dominio predeterminado del clúster es cluster.local, pero puede personalizarlo al crear el clúster. Por ejemplo, un servicio llamado my-web-app en el espacio de nombres predeterminado tendría el nombre de DNS my-web-app.default.svc.cluster.local.

El papel de /etc/resolv.conf

Para resolver estos nombres de DNS, los pods dependen de su archivo /etc/resolv.conf. Este archivo de configuración indica al pod a qué servidor de nombres debe enviar sus consultas de DNS. La dirección IP del servidor de nombres que aparece en este archivo depende de las funciones de DNS específicas que estén habilitadas en tu clúster de GKE. En la siguiente tabla se indica qué IP de servidor de nombres usa un pod en función de tu configuración:

Cloud DNS para GKE NodeLocal DNSCache Valor del servidor de nombres `/etc/resolv.conf`
Habilitado Habilitado `169.254.20.10`
Habilitado Inhabilitado `169.254.169.254`
Inhabilitado Habilitado Dirección IP del servicio `kube-dns`
Inhabilitado Inhabilitado Dirección IP del servicio `kube-dns`

Esta configuración ayuda a asegurar que las consultas de DNS del pod se dirijan al componente correcto:

  • NodeLocal DNSCache: proporciona búsquedas locales rápidas en el nodo.
  • IP del servidor de metadatos (169.254.169.254): se usa cuando Cloud DNS para GKE está habilitado sin NodeLocal DNSCache. Las consultas de DNS se dirigen a esta dirección IP, que Cloud DNS usa para interceptar y gestionar las solicitudes de DNS.
  • kube-dns Dirección IP de servicio: se usa para la resolución estándar en el clúster cuando Cloud DNS para GKE está inhabilitado.

Arquitectura de DNS en GKE

GKE proporciona una arquitectura flexible para el descubrimiento de servicios, principalmente mediante DNS. Los siguientes componentes funcionan conjuntamente para resolver las consultas de DNS en tu clúster:

  • kube-dns: el proveedor de DNS predeterminado en el clúster para los clústeres estándar de GKE. Se ejecuta como un despliegue gestionado de pods en el espacio de nombres kube-system y monitoriza la API de Kubernetes para detectar nuevos servicios y crear los registros DNS necesarios.
  • Cloud DNS: servicio de DNS totalmente gestionado. Google CloudOfrece una alternativa altamente escalable y fiable a kube-dns y es el proveedor de DNS predeterminado para los clústeres de Autopilot de GKE.
  • NodeLocal DNSCache: un complemento de GKE que mejora el rendimiento de las búsquedas de DNS. Ejecuta una caché de DNS en cada nodo de tu clúster, que funciona con kube-dns o Cloud DNS para atender las consultas de DNS de forma local, lo que reduce la latencia y la carga del proveedor de DNS central del clúster. En los clústeres de Autopilot de GKE, NodeLocal DNSCache está habilitado de forma predeterminada y no se puede anular.
  • Despliegue personalizado de kube-dns: un despliegue que te permite desplegar y gestionar tu propia instancia de kube-dns, lo que te da más control sobre la configuración y los recursos de kube-dns.

Elige tu proveedor de DNS

En la siguiente tabla se resumen los proveedores de DNS disponibles en GKE, incluidas sus funciones y cuándo elegir cada uno:

Proveedor Funciones Cuándo elegir
`kube-dns` Resolución de DNS en clúster para servicios y pods. Todos los clústeres con necesidades de redes estándar. La nueva versión de `kube-dns` es adecuada para clústeres pequeños y grandes.
Cloud DNS Funciones avanzadas de DNS (zonas privadas, direccionamiento del tráfico y balanceo de carga global) e integración con otros Google Cloud servicios. Exponer servicios externamente, entornos multiclúster o clústeres con altas tasas de consultas de DNS (QPS).
Despliegue personalizado de `kube-dns` Mayor control sobre la configuración y la asignación de recursos, así como la posibilidad de usar proveedores de DNS alternativos. Clústeres a gran escala o necesidades de DNS específicas que requieran un escalado más agresivo o un control detallado de la asignación de recursos.

Descubrimiento de servicios fuera de un solo clúster

Puedes ampliar el descubrimiento de servicios más allá de un solo clúster de GKE mediante los siguientes métodos:

Ámbito de Cloud DNS

Los clústeres que usan Cloud DNS para el DNS del clúster pueden operar en uno de los tres ámbitos disponibles:

  • Ámbito de clúster: es el comportamiento predeterminado de Cloud DNS. En este modo, Cloud DNS funciona de forma equivalente a kube-dns, ya que proporciona resolución de DNS exclusivamente para los recursos que se encuentran en el clúster. Los registros DNS solo se pueden resolver desde el clúster y se ajustan al esquema de servicio estándar de Kubernetes: <svc>.<ns>.svc.cluster.local.
  • Ámbito de VPC adicional: esta función opcional amplía el ámbito del clúster al permitir que los servicios sin encabezado se puedan resolver desde otros recursos de la misma red de VPC, como las VMs de Compute Engine o los clientes on-premise que se conectan mediante Cloud VPN o Cloud Interconnect.
  • Ámbito de VPC: con esta configuración, los registros DNS de los servicios de clúster se pueden resolver en toda la red de VPC. Con este enfoque, cualquier cliente que esté en la misma VPC o que esté conectado a ella (a través de Cloud VPN o Cloud Interconnect) puede resolver directamente los nombres de servicio.

Para obtener más información sobre el DNS con ámbito de VPC, consulta Usar Cloud DNS para GKE.

Servicios de varios clústeres

Los servicios multiclúster (MCS) permiten el descubrimiento de servicios y la gestión del tráfico en varios clústeres de GKE. MCS te permite crear aplicaciones que abarcan clústeres y, al mismo tiempo, mantener una experiencia de servicio unificada.

MCS utiliza el descubrimiento de servicios basado en DNS para conectar servicios entre clústeres. Cuando creas una instancia de MCS, se generan registros DNS con el formato <svc>.<ns>.svc.clusterset.local. Estos registros se resuelven en las direcciones IP de los endpoints del servicio en cada clúster participante.

Cuando un cliente de un clúster accede a un MCS, las solicitudes se dirigen al endpoint disponible más cercano de cualquiera de los clústeres participantes. kube-proxy (o Cilium en GKE Dataplane V2) gestiona esta distribución del tráfico en cada nodo, lo que ayuda a garantizar una comunicación eficiente y el equilibrio de carga en los clústeres.

Service Directory para GKE

Service Directory para GKE proporciona un registro unificado para el descubrimiento de servicios en tus implementaciones de Kubernetes y no Kubernetes. Service Directory puede registrar servicios de GKE y que no sean de GKE en un único registro.

Directorio de servicios es especialmente útil si quieres hacer lo siguiente:

  • Un único registro para que las aplicaciones de Kubernetes y las que no lo son se descubran entre sí.
  • Una herramienta de descubrimiento de servicios gestionados.
  • La capacidad de almacenar metadatos sobre tu servicio a los que puedan acceder otros clientes.
  • Posibilidad de definir permisos de acceso a nivel de servicio. Los servicios de Service Directory se pueden resolver mediante DNS, HTTP y gRPC. Service Directory está integrado con Cloud DNS y puede rellenar registros de Cloud DNS que coincidan con los servicios de Service Directory.

Para obtener más información, consulta Configurar Service Directory para GKE.

Optimizar el rendimiento y las prácticas recomendadas de DNS

Para garantizar que el descubrimiento de servicios sea fiable y eficiente, sobre todo en clústeres a gran escala o con mucho tráfico, te recomendamos que sigas estas prácticas recomendadas y estrategias de optimización.

Optimizar el rendimiento con NodeLocal DNSCache

En los clústeres que tienen una alta densidad de pods o en las aplicaciones que generan un gran volumen de consultas de DNS, puedes mejorar la velocidad de búsqueda de DNS habilitando NodeLocal DNSCache. NodeLocal DNSCache es un complemento de GKE que ejecuta una caché de DNS en cada nodo de tu clúster. Cuando un pod hace una solicitud de DNS, la solicitud va a la caché que está en el mismo nodo. Este método reduce la latencia y el tráfico de red.

Para obtener más información sobre cómo habilitar y configurar esta función, consulta Configurar NodeLocalDNSCache.

Ajustar la escala de tu proveedor de DNS

Si usas kube-dns y experimentas tiempos de espera intermitentes, sobre todo durante periodos de mucho tráfico, puede que tengas que aumentar el número de réplicas de kube-dns. kube-dns-autoscaler ajusta el número de réplicas en función del número de nodos y núcleos del clúster, y sus parámetros se pueden ajustar para desplegar más réplicas antes.

Para obtener instrucciones detalladas, consulta Escalar kube-dns.

Prácticas recomendadas generales

  • Selecciona el proveedor de DNS adecuado: elige el proveedor de DNS en función de las necesidades de tu clúster. Cloud DNS se recomienda para cargas de trabajo con un gran número de consultas por segundo, entornos multiclúster y cuando necesites integrar tu red VPC. La nueva versión de kube-dns es adecuada para una amplia gama de clústeres, desde pequeños hasta grandes, que tienen necesidades estándar de descubrimiento de servicios en el clúster.
  • Evita usar máquinas virtuales de Spot o máquinas virtuales interrumpibles para kube-dns: ayuda a garantizar la estabilidad del servicio DNS de tu clúster. Para ello, no ejecutes componentes críticos del sistema, como kube-dns, en máquinas virtuales de Spot o máquinas virtuales interrumpibles. Las finalizaciones inesperadas de nodos pueden provocar problemas de resolución de DNS.
  • Usa nombres de servicio claros y descriptivos: adopta convenciones de nomenclatura coherentes y significativas para tus servicios, de modo que las configuraciones de las aplicaciones sean más fáciles de leer y mantener.
  • Organizar con espacios de nombres: usa espacios de nombres de Kubernetes para agrupar servicios relacionados. Este enfoque ayuda a evitar conflictos de nomenclatura y mejora la organización de los recursos del clúster.
  • Monitoriza y valida el DNS: monitoriza periódicamente las métricas y los registros del DNS para identificar posibles problemas antes de que afecten a tus aplicaciones. Prueba periódicamente la resolución de DNS desde tus pods para asegurarte de que el descubrimiento de servicios funciona correctamente.

Siguientes pasos