Acerca del descubrimiento de servicios

En este documento, se explica cómo el descubrimiento de servicios en Google Kubernetes Engine (GKE) simplifica la administración de aplicaciones y cómo extender el descubrimiento de servicios más allá de un solo clúster con los alcances de Cloud DNS, los servicios de varios clústeres (MCS) y Directorio de servicios.

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

Antes de leer este documento, asegúrate de comprender los siguientes conceptos:

Descripció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 extremos. El descubrimiento de servicios ayuda a garantizar que las aplicaciones siempre tengan acceso a las direcciones IP de los Pods actualizadas, incluso cuando se reprograman los Pods o se agregan Pods nuevos. GKE ofrece varias formas de implementar el descubrimiento de servicios, incluidas kube-dns, implementaciones personalizadas de kube-dns y Cloud DNS. Puedes optimizar aún más el rendimiento del DNS con NodeLocal DNSCache.

Beneficios del descubrimiento de servicios

El descubrimiento de servicios proporciona los siguientes beneficios:

  • Administració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 con nombres de Service lógicos, que se resuelven automáticamente en las direcciones IP de Pod correctas. Este enfoque simplifica la configuración, en especial en entornos dinámicos en los que las direcciones IP de los Pods pueden cambiar debido al ajuste de escala o la reprogramación.
  • Escalabilidad y resiliencia simplificadas: El descubrimiento de servicios simplifica la escalabilidad, ya que desacopla a los consumidores de servicios de las direcciones IP de los Pods, que cambian con frecuencia. A medida que se escala tu aplicación, o si los Pods fallan y se reemplazan, Kubernetes actualiza automáticamente qué Pods están disponibles para recibir tráfico para un Service determinado. El descubrimiento de servicios ayuda a garantizar que las solicitudes al nombre de Service estable se dirijan solo a los Pods en buen estado, lo que permite que tu aplicación se escale o se recupere de fallas sin intervención manual ni reconfiguración del cliente.
  • Alta disponibilidad: GKE usa el balanceo de cargas junto con el descubrimiento de servicios para garantizar la alta disponibilidad y mejorar la capacidad de respuesta de tus aplicaciones, incluso con cargas pesadas.

Balanceo de cargas con detección de servicios

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

  • Servicios internos: Para los servicios a los que solo se puede acceder dentro del clúster, el plano de datos de GKE (kube-proxy o Cilium) actúa como un balanceador de cargas. Distribuye el tráfico entrante de manera 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 balanceadores de cargas Google Cloud . Estos balanceadores de cargas incluyen balanceadores de cargas Google Cloud externos para el acceso público a Internet y balanceadores de cargas Google Cloud internos para el acceso dentro de tu red de nube privada virtual. Estos balanceadores de cargas distribuyen el tráfico entre los nodos de tu clúster. Luego, el plano de datos de cada nodo enruta aún más el tráfico a los Pods correspondientes.

Tanto en situaciones internas como externas, la detección de servicios actualiza continuamente la lista de Pods disponibles para cada Service. Esta actualización continua ayuda a garantizar que tanto el plano de datos (para los servicios internos) como los balanceadores de cargas Google Cloud (para los servicios externos) dirijan el tráfico solo a instancias en buen estado.

Casos de uso del descubrimiento de servicios

Los siguientes son casos de uso comunes para 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 deben interactuar. El descubrimiento de servicios permite que estas aplicaciones se encuentren y se intercambien información, incluso mientras se escala el clúster.
  • Habilita implementaciones sin tiempo de inactividad y mejora la resiliencia: El descubrimiento de servicios facilita las actualizaciones sin tiempo de inactividad para las aplicaciones, incluidas las implementaciones controladas y las implementaciones de versión canary. Automatiza el descubrimiento de nuevas versiones de servicios y cambia el tráfico a ellas, lo que ayuda a reducir el tiempo de inactividad durante la implementación y garantiza una transición sin problemas para los usuarios. El descubrimiento de servicios también mejora la resiliencia. Cuando un Pod falla en GKE, se implementa uno nuevo, y el descubrimiento de servicios registra el Pod nuevo y redirecciona 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 deben encontrarse y comunicarse entre sí. El descubrimiento de servicios proporciona esta capacidad a través del sistema de nombres de dominio (DNS). De manera similar a cómo usas el DNS para encontrar sitios web en Internet, los Pods en un clúster de GKE usan el DNS para ubicar y conectarse con los servicios a través de sus nombres de servicio. Este enfoque permite que los Pods interactúen de manera eficaz, independientemente de dónde se ejecuten en el clúster, y permite que las aplicaciones se comuniquen con nombres de servicio coherentes en lugar de direcciones IP inestables.

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

Los Pods en un clúster de GKE resuelven los nombres de DNS para los Services y otros Pods con una combinación de registros 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 Service:

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

El dominio predeterminado del clúster es cluster.local, pero puedes personalizarlo cuando crees el clúster. Por ejemplo, un objeto Service llamado my-web-app en el espacio de nombres predeterminado tendría el nombre de DNS my-web-app.default.svc.cluster.local.

El rol de /etc/resolv.conf

Para resolver estos nombres de DNS, los Pods dependen de su archivo /etc/resolv.conf. Este archivo de configuración le indica al Pod a qué servidor de nombres debe enviar sus consultas de DNS. La dirección IP del servidor de nombres que se indica 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 describe qué IP del servidor de nombres usa un Pod según 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 garantizar 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 controlar las solicitudes de DNS.
  • kube-dns Dirección IP del servicio: Se usa para la resolución estándar dentro del 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 a través de DNS. Los siguientes componentes trabajan en conjunto para resolver las consultas de DNS dentro de tu clúster:

  • kube-dns: Es el proveedor de DNS predeterminado dentro del clúster para los clústeres estándar de GKE. Se ejecuta como una implementación administrada de Pods en el espacio de nombres kube-system y supervisa la API de Kubernetes para detectar Services nuevos y crear los registros DNS necesarios.
  • Cloud DNS: Google CloudEs el servicio de DNS completamente administrado. Ofrece una alternativa altamente confiable y escalable a kube-dns y es el proveedor de DNS predeterminado para los clústeres de GKE Autopilot.
  • NodeLocal DNSCache: Es un complemento de GKE que mejora el rendimiento de la búsqueda de DNS. Ejecuta una caché de DNS en cada nodo de tu clúster y funciona con kube-dns o Cloud DNS para atender las consultas de DNS de forma local, lo que reduce la latencia y la carga en el 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.
  • Implementación personalizada de kube-dns: Es una Deployment que te permite implementar y administrar tu propia instancia de kube-dns, lo que te brinda 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 el 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 a pequeña y gran escala.
Cloud DNS Funciones avanzadas de DNS (zonas privadas, redireccionamiento del tráfico, balanceo de cargas global) y la integración con otros servicios de Google Cloud . Exponer servicios de forma externa, entornos de varios clústeres o clústeres con altas tasas de consultas de DNS (QPS)
Deployment personalizada de "kube-dns" Control adicional sobre la configuración, la asignación de recursos y la posibilidad de usar proveedores de DNS alternativos Clústeres a gran escala o necesidades específicas de DNS que requieren un escalamiento más agresivo o un control detallado sobre la asignación de recursos.

Descubrimiento de servicios fuera de un único clúster

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

Permiso de Cloud DNS

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

  • Permiso del clúster: Este es el comportamiento predeterminado de Cloud DNS. En este modo, Cloud DNS funciona de manera equivalente a kube-dns, ya que proporciona resolución de DNS exclusivamente para los recursos que se encuentran dentro del clúster. Los registros DNS solo se pueden resolver desde dentro del clúster y cumplen con el esquema estándar de Service de Kubernetes: <svc>.<ns>.svc.cluster.local.
  • Permiso adicional de VPC: Esta función opcional extiende el permiso del clúster, ya que permite que los Services sin interfaz gráfica se resuelvan desde otros recursos dentro de la misma red de VPC, como las VMs de Compute Engine o los clientes locales que se conectan a través de Cloud VPN o Cloud Interconnect.
  • Permiso de la VPC: Con esta configuración, los registros DNS de los servicios del clúster se pueden resolver en toda la red de VPC. Este enfoque significa que cualquier cliente que se encuentre 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 los servicios.

Si deseas obtener más información sobre el DNS de permiso de la VPC, consulta Usa Cloud DNS para GKE.

Service de varios clústeres

Los servicios de varios clústeres (MCS) permiten el descubrimiento de servicios y la administración del tráfico en varios clústeres de GKE. MCS te permite compilar aplicaciones que abarcan clústeres y, a la vez, mantener una experiencia de servicio unificada.

Los MCS aprovechan el descubrimiento de servicios basado en DNS para conectar servicios en todos los clústeres. Cuando creas una instancia de MCS, se generan registros DNS en el formato <svc>.<ns>.svc.clusterset.local. Estos registros se resuelven en las direcciones IP de los extremos del Service en cada clúster participante.

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

Directorio de servicios para GKE

El Directorio de servicios para GKE proporciona un registro unificado para el descubrimiento de servicios en tus implementaciones de Kubernetes y de terceros. El Directorio de servicios puede registrar servicios de GKE y de terceros en un solo registro.

El Directorio de servicios es particularmente útil si deseas lo siguiente:

  • Un solo registro para las aplicaciones de Kubernetes y de terceros para que se detecten entre sí
  • Una herramienta de descubrimiento de servicios administrados
  • La capacidad de almacenar metadatos sobre tu Servicio a los que otros clientes pueden acceder
  • La capacidad de configurar permisos de acceso a nivel de cada servicio Los servicios del Directorio de servicios se pueden resolver con DNS, HTTP y gRPC. El Directorio de servicios está integrado en Cloud DNS y puede propagar registros de Cloud DNS que coincidan con los servicios del Directorio de servicios.

Para obtener más información, consulta Configura el Directorio de servicios para GKE.

Optimiza el rendimiento del DNS y aplica las prácticas recomendadas

Para garantizar un descubrimiento de servicios confiable y eficiente, especialmente en clústeres a gran escala o con mucho tráfico, considera las siguientes prácticas recomendadas y estrategias de optimización.

Optimiza el rendimiento con NodeLocal DNSCache

En el caso de los clústeres que tienen una alta densidad de Pods o las aplicaciones que generan un gran volumen de consultas de DNS, puedes mejorar las velocidades 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 realiza una solicitud de DNS, la solicitud va a la caché que se encuentra en el mismo nodo. Este enfoque 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 Configura NodeLocal DNSCache.

Cómo escalar tu proveedor de DNS

Si usas kube-dns y experimentas tiempos de espera intermitentes, en especial durante períodos de tráfico alto, es posible que debas ajustar la cantidad de réplicas de kube-dns. kube-dns-autoscaler ajusta la cantidad de réplicas según la cantidad de nodos y núcleos del clúster, y sus parámetros se pueden ajustar para implementar más réplicas antes.

Para obtener instrucciones detalladas, consulta Cómo escalar kube-dns.

Prácticas recomendadas generales

  • Selecciona el proveedor de DNS adecuado: Elige tu proveedor de DNS según las necesidades de tu clúster. Se recomienda Cloud DNS para cargas de trabajo con un QPS alto, entornos de varios clústeres y cuando necesitas integración con tu red de VPC más amplia. La nueva versión de kube-dns es adecuada para una amplia variedad de clústeres, desde pequeños hasta grandes, que tienen necesidades estándar de descubrimiento de servicios dentro del clúster.
  • Evita las VMs Spot o las VMs interrumpibles para kube-dns: Ayuda a garantizar la estabilidad del servicio DNS de tu clúster evitando ejecutar componentes críticos del sistema, como kube-dns, en VMs Spot o VMs interrumpibles. Las finalizaciones inesperadas de nodos pueden provocar problemas de resolución de DNS.
  • Usa nombres de servicio claros y descriptivos: Adopta convenciones de nombres coherentes y significativas para tus servicios, de modo que las configuraciones de las aplicaciones sean más fáciles de leer y mantener.
  • Organiza con espacios de nombres: Usa espacios de nombres de Kubernetes para agrupar servicios relacionados. Este enfoque ayuda a evitar conflictos de nombres y mejora la organización de los recursos del clúster.
  • Supervisa y valida el DNS: Supervisa periódicamente las métricas y los registros de DNS para identificar posibles problemas antes de que afecten tus aplicaciones. Prueba periódicamente la resolución de DNS desde tus Pods para asegurarte de que el descubrimiento de servicios funcione según lo esperado.

¿Qué sigue?