Conéctate a clústeres registrados mediante la puerta de enlace de Connect

Las flotas en Google Cloud son grupos lógicos de clústeres de Kubernetes y otros recursos que se pueden administrar juntos y se crean mediante el registro de clústeres en Google Cloud. La puerta de enlace de Connect se basa en la potencia de las flotas para permitir que los usuarios de Anthos se conecten y ejecuten comandos contra clústeres miembros de la flota de forma sencilla, coherente y segura, sin importar si los clústeres están en Google Cloud, otras nubes públicas o locales, y facilita la automatización de los procesos de DevOps en todos tus clústeres.

En esta guía, se supone que ya estás familiarizado con algunos conceptos básicos de flotas y con el registro de clústeres en una flota. De lo contrario, puedes obtener más información en la Descripción general de la administración de flotas, la Descripción general de la creación de flotas y sus guías vinculadas. También debes estar familiarizado con las herramientas y los conceptos de Kubernetes, incluidos kubectl, client-go (si deseas usar la puerta de enlace con fines de automatización), el control de acceso basado en funciones (RBAC) y los recursos principales de Kubernetes.

De forma predeterminada, la puerta de enlace de Connect usa tu ID de Google para autenticarse en clústeres, compatible con proveedores de identidad externos que usan la federación de identidades de personal y con asistencia de autenticación basada en grupos a través de GKE Identity Service. Si quieres obtener más información sobre GKE Identity Service o usarlo como una opción de autenticación independiente de terceros, consulta Introducción a GKE Identity Service.

¿Por qué usar la puerta de enlace de conexión?

Existen muchos desafíos durante la administración de cargas de trabajo cuando los clústeres se ejecutan en varios entornos híbridos y de nube. Los clústeres pueden ejecutarse en diferentes nubes privadas virtuales (VPC) y aprovechar diferentes proveedores de identidad, lo que hace que la conectividad, la autenticación y la autorización sean más complicadas. A veces, es difícil descubrir qué clústeres existen en estos entornos.

La puerta de enlace de Connect facilita las siguientes tareas:

  • Descubrir qué clústeres existen (en Google Cloud, en otra nube pública o de forma local) y se registran en tu flota mediante una consulta simple.
  • Conéctate al clúster que desees con la misma infraestructura que usamos para mostrar los clústeres de GKE registrados en la consola de Google Cloud.
  • Autenticar con las mismas identidades que usas con los servicios de Google Cloud.
  • Autorizar de manera coherente en todos los clústeres registrados en una flota.

La puerta de enlace autentica tu identidad de Google Cloud y proporciona la conexión con el servidor de API del clúster a través del servicio de conexión.

Puedes interactuar con los clústeres directamente a través de la puerta de enlace mediante herramientas de línea de comandos que acepten una kubeconfig, como kubectl. También puedes aprovechar la puerta de enlace con facilidad mediante las canalizaciones de compilación y otra automatización de DevOps. Puedes ver un ejemplo de cómo hacerlo en nuestro instructivo Integración con Cloud Build.

También puedes usar el servicio de Connect para conectarte a clústeres registrados fuera de Google Cloud con tu identidad de Google Cloud en la consola de Google Cloud. Para ello, sigue las instrucciones en Accede a un clúster desde la consola de Google Cloud.

Cómo funciona

Este es el flujo que realiza un usuario o un servicio típico (como una canalización de IC/EC) para usar la puerta de enlace de Connect después de configurar la autenticación y la autorización adecuadas. A fin de obtener instrucciones más detalladas para usuarios, consulta nuestra guía de uso.

  1. El usuario o servicio descubre clústeres mediante la enumeración de recursos de membresía de la flota con Google Cloud CLI.

    gcloud container fleet memberships list

  2. El usuario o servicio recupera el kubeconfig específico de la puerta de enlace de Connect necesario para llegar al clúster seleccionado mediante Google Cloud CLI.

    gcloud container fleet memberships get-credentials membership-name

    Si ya estás familiarizado con el uso de la CLI de gcloud con GKE, esto es similar a ejecutar gcloud container clusters get-credentials con tu cuenta de Google Cloud, lo que te permite (si tienes autorización) acceder a cualquier clúster registrado y conectado dentro de la flota de tu proyecto.

  3. El usuario o servicio ejecuta sus comandos como lo haría normalmente con kubectl o client-go, mediante el archivo kubeconfig descargado.

    1. La puerta de enlace de conexión conecta al usuario/servicio, y se verifica la autorización para garantizar que tenga permiso para usar la puerta de enlace.
    2. La solicitud se reenvía a través del servicio de Connect y del agente de Connect al servidor de la API de Kubernetes correspondiente.
    3. El servidor de la API de Kubernetes autoriza la solicitud, lo que requiere que el agente de conexión esté autorizado para hacerse pasar por el usuario o servicio, y que el usuario o servicio está autorizado para ejecutar la solicitud deseada.

Asistencia de Grupos de Google

En el flujo estándar descrito en la sección anterior, la solicitud del usuario se autoriza en función de su ID individual. Sin embargo, en muchos casos, resulta útil autorizar a los usuarios sobre la base de su pertenencia a Grupos de Google. La autorización basada en la pertenencia a un grupo significa que no tienes que configurar una autorización distinta para cada cuenta, lo que simplifica la administración de las políticas y facilita su auditoría. Por ejemplo, puedes compartir con facilidad el acceso al clúster a un equipo, sin la necesidad de agregar o quitar usuarios individuales de los clústeres cuando se unen al equipo o salen de él. Con algunos ajustes adicionales a través del servicio de identidad de GKE, puedes configurar la puerta de enlace de Connect para obtener la información de membresía del Grupo de Google del usuario.

Puedes obtener más información sobre cómo funciona esta función y cómo configurarla en Configura la puerta de enlace de Connect con Grupos de Google.

Si quieres usar esta función con clústeres conectados o con otros entornos de clústeres de GKE, comunícate con Atención al cliente de Cloud o con el equipo de la puerta de enlace de Connect.

Compatibilidad con identidades de terceros

Además de trabajar con usuarios y grupos de Google Workspace, la puerta de enlace de Connect admite la autorización mediante identidades de terceros, como Azure Active Directory y Okta. Mediante la federación de identidades de personal, puedes usar un proveedor de identidad externo para autenticar y autorizar a un personal (un grupo de usuarios, como empleados, socios y contratistas) que use Identity and Access Management, de modo que los usuarios puedan acceder a los servicios de Google Cloud, como la puerta de enlace de Connect. Con algunos ajustes adicionales mediante el servicio de identidad de GKE, puedes configurar la puerta de enlace de Connect para obtener información de pertenencia a grupos de terceros para los usuarios.

La función de identidad de terceros de la puerta de enlace de Connect es compatible con GKE en VMware y GKE en Bare Metal a partir de la versión 1.13 de Anthos. Para los clústeres conectados, esta función está disponible en GKE Enterprise 1.16 y versiones posteriores.

Puedes obtener más información sobre cómo funciona esta función y cómo configurarla en Configura la puerta de enlace de Connect con identidades de terceros.

Si lo prefieres, puedes configurar la autenticación de terceros por completo con GKE Identity Service. Para ello, sigue las instrucciones en su documentación.

Latencia

La latencia total de una solicitud a través de la puerta de enlace se puede dividir en dos partes: el RTT (tiempo de ida y vuelta) del servicio de la puerta de enlace de Connect al agente de Connect, y el tiempo de ejecución de la solicitud dentro del clúster. La latencia adicional que aporta el RTT es de p95<500 ms y p99<1 s. Ten en cuenta que la mayoría de los comandos kubectl realiza una serie de varias solicitudes diferentes, cada una de las cuales requiere un recorrido de ida y vuelta, antes de procesar una respuesta al usuario.

Próximos pasos