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 mediante los permisos de Cloud DNS, los servicios de varios clústeres (MCS) y el Directorio de servicios.

Este documento está destinado 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 Google Cloud el contenido de, consulta Roles y tareas comunes del usuario de GKE.

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 de forma rígida las direcciones IP ni las configuraciones de extremos. El descubrimiento de servicios ayuda a garantizar que las aplicaciones siempre tengan acceso a direcciones IP de Pod actualizadas, incluso cuando se reprograman los Pods o se agregan Pods nuevos. GKE ofrece varias formas de implementar el descubrimiento de servicios, incluidos kube-dns, las implementaciones personalizadas de kube-dns y Cloud DNS. Puedes optimizar aún más el rendimiento de 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 de forma rígida las direcciones IP en las configuraciones de tu aplicación. Las aplicaciones se comunican mediante nombres de servicio 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 Pod pueden cambiar debido al escalamiento o la reprogramación.
  • Escalamiento y resiliencia simplificados: El descubrimiento de servicios simplifica el escalamiento mediante la separación de los consumidores de servicios de las direcciones IP de Pod, que cambian con frecuencia. Mientras 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 servicio determinado. El descubrimiento de servicios ayuda a garantizar que las solicitudes al nombre de servicio estable se dirijan solo a los Pods en buen estado, lo que permite que tu aplicación se escale o se recupere de las 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 descubrimiento de servicios

GKE ayuda a garantizar la alta disponibilidad de tus aplicaciones mediante la combinación de 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 en varios Pods en buen estado, lo que evita la sobrecarga y ayuda a garantizar la alta disponibilidad.
  • Servicios externos: Para los servicios a los que se debe acceder desde fuera del clúster, GKE aprovisiona Google Cloud balanceadores de cargas. Estos balanceadores de cargas incluyen balanceadores de cargas externos Google Cloud para el acceso público a Internet y balanceadores de cargas internos Google Cloud 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 adecuados.

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

Casos de uso para el descubrimiento de servicios

Los siguientes son casos de uso comunes para el descubrimiento 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 e 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 canary. Automatiza el descubrimiento de versiones nuevas del servicio 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 mediante el sistema de nombres de dominio (DNS). De manera similar a cómo usas DNS para encontrar sitios web en Internet, los Pods de un clúster de GKE usan DNS para ubicar y conectarse con los servicios mediante sus nombres de servicio. Este enfoque permite que los Pods interactúen de manera eficaz, sin importar 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 los Pods realizan la resolución de DNS

Los Pods de un clúster de GKE resuelven los nombres de DNS para los servicios y otros Pods mediante 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 servicio:

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

El dominio del clúster predeterminado es cluster.local, pero puedes personalizar el dominio cuando creas 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 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 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 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.
  • Dirección IP del servicio kube-dns: 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 el uso de DNS. Los siguientes componentes trabajan juntos para resolver consultas de DNS dentro de tu clúster:

  • kube-dns: Es el proveedor de DNS predeterminado en el clúster para los clústeres de GKE Standard. Se ejecuta como una implementación administrada de Pods en el espacio de nombres kube-system y supervisa la API de Kubernetes para obtener servicios nuevos y crear los registros DNS necesarios.
  • Cloud DNS: Google CloudEs el servicio de DNS completamente administrado de Google Cloud. Ofrece una alternativa altamente escalable y confiable 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, que funciona con kube-dns o Cloud DNS para entregar consultas de DNS de forma local, lo que reduce la latencia y la carga en el proveedor de DNS central del clúster. En el caso de los clústeres de Autopilot de GKE, NodeLocal DNSCache está habilitado de forma predeterminada y no se puede anular.
  • Implementación kube-dns personalizada: Es una Deployment que te permite implementar y administrar tu propia instancia de kube-dns, lo que proporciona 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 elegirlo
`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 versión nueva de `kube-dns` es adecuada para clústeres pequeños y a gran escala.
Cloud DNS Funciones avanzadas de DNS (zonas privadas, dirección de tráfico, balanceo de cargas global y la integración con otros Google Cloud servicios) Exponer servicios de forma externa, entornos de varios clústeres o para 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 el potencial para usar proveedores de DNS alternativos Clústeres a gran escala o necesidades de DNS específicas 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 y proporciona resolución de DNS exclusivamente para los recursos que están dentro del clúster. Los registros DNS solo se pueden resolver desde el clúster y cumplen con el esquema estándar de servicio 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 servicios sin interfaz gráfica se puedan resolver desde otros recursos dentro de la misma red de VPC, como VMs de Compute Engine o clientes locales que se conectan mediante 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 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 los servicios.

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

Servicios 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 mientras mantienes una experiencia de servicio unificada.

MCS aprovecha 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 de <svc>.<ns>.svc.clusterset.local. Estos registros se resuelven en las direcciones IP de los extremos del servicio 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) administra esta distribución de tráfico en cada nodo, lo que ayuda a garantizar una comunicación y un balanceo de cargas eficientes 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 el servicio a los que otros clientes puedan acceder
  • La capacidad de configurar permisos de acceso en un nivel por servicio Los servicios del Directorio de servicios se pueden resolver mediante DNS, HTTP y gRPC. El Directorio de servicios está integrado en Cloud DNS y puede propagar registros de Cloud DNS que coinciden con los servicios del Directorio de servicios.

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

Optimiza el rendimiento de DNS y las prácticas recomendadas

Para garantizar un descubrimiento de servicios confiable y eficiente, en especial 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 aplicaciones que generan un gran volumen de consultas de DNS, puedes mejorar las velocidades de búsqueda de DNS si habilitas 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 está 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.

Escala tu proveedor de DNS

Si usas kube-dns y experimentas tiempos de espera intermitentes, en especial durante períodos de mucho tráfico, es posible que debas escalar la cantidad de réplicas de kube-dns. kube-dns-autoscaler ajusta la cantidad de réplicas en función de 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 Configura una implementación personalizada de kube-dns Deployment.

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 de QPS altas, entornos de varios clústeres y cuando necesitas integración con tu red de VPC más amplia. La versión nueva 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 en el clúster.
  • Evita las VMs interrumpibles o las VMs interrumpibles para kube-dns: Para garantizar la estabilidad del servicio DNS de tu clúster, no ejecutes componentes críticos del sistema, como kube-dns en VMs interrumpibles 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 para que las configuraciones de 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 como se espera.

¿Qué sigue?