Anthos clusters on VMware is now Google Distributed Cloud (software only) for VMware. For more information, see the product overview.

Se usó la API de Cloud Translation para traducir esta página.

Administra clústeres desde la consola de Google Cloud

En este documento, se explica cómo hacer que Google Distributed Cloud esté disponible para su administración en la consola de Google Cloud. Esto incluye la administración básica, como la capacidad de acceder a los clústeres y ver sus cargas de trabajo, y cómo habilitar la administración del ciclo de vida de los clústeres para que puedas actualizar, borrar o actualizar clústeres.

Miembros de la flota y la consola

Todos los Google Distributed Cloud deben ser miembros de una flota, una forma unificada de ver y administrar varios clústeres y sus cargas de trabajo. Cada flota de clústeres está asociada con un proyecto host de flota.

En Google Distributed Cloud, un clúster de administrador se registra en una flota en el momento de la creación mediante la especificación del proyecto host de tu flota en la sección gkeConnect del archivo de configuración del clúster. Google Distributed Cloud usa esa información para registrar tu clúster en el proyecto de flota especificado. Si el registro falló, puedes volver a intentar el registro mediante la ejecución de gkectl update credentials register.

Ten en cuenta que, cuando vuelves a intentar el registro, no necesitas actualizar la clave de la cuenta de servicio del registro de conexión. En otras palabras, puedes seguir usando la cuenta de servicio original del registro de Connect. Para obtener más información sobre el comando, consulta Rota claves de cuentas de servicio.

En Google Distributed Cloud, un clúster de usuario se registra en una flota en el momento de la creación:

Cuando creas un clúster de usuario con gkectl, especificas el proyecto host de tu flota en la sección gkeConnect del archivo de configuración del clúster. Google Distributed Cloud usa esa información para registrar tu clúster en el proyecto de flota especificado.
Cuando creas un clúster de usuario mediante una herramienta estándar (la consola, Google Cloud CLI o Terraform), el clúster se convierte de forma automática en un miembro de la flota en el proyecto que especifiques.

Los miembros de la flota fuera de Google Cloud, como Google Distributed Cloud, se muestran en la consola del proyecto host de tu flota, junto con otros clústeres de flotas, como GKE en Google Cloud. En qué medida puedes administrar Google Distributed Cloud desde la consola depende de lo siguiente:

Si configuraste la autenticación, puedes acceder a los clústeres y ver sus cargas de trabajo y otros detalles.
Si habilitaste la administración del ciclo de vida del clúster para el clúster, también puedes actualizar, actualizar o borrar clústeres de usuario mediante la consola. Si esta función no está habilitada, solo puedes administrar el ciclo de vida del clúster mediante gkectl en la estación de trabajo de administrador.

Visualiza clústeres registrados

Todos tus clústeres de flotas se muestran en la página de descripción general de los clústeres de Google Kubernetes Engine en la consola. Esto te brinda una descripción general de toda tu flota y, para Google Distributed Cloud, te permite ver qué clústeres administra la API de GKE On-Prem.

Para ver los clústeres de tu flota, haz lo siguiente:

En la consola, ve a la página Descripción general de los clústeres de Google Kubernetes Engine.

Ir a los clústeres de GKE
Selecciona el proyecto de Google Cloud.
- Si se muestra vm GKE en VMware en la columna Tipo, la API de GKE On-Prem administra el clúster.
- Si se muestra Externo en la columna Tipo, la API de GKE On-Prem no administra el clúster.

Para ver más detalles sobre un clúster, los usuarios deben acceder y autenticarse en el clúster. Para ello, debes seguir estos pasos:

Configura un método de autenticación
Otorga a los usuarios roles específicos de Identity and Access Management

Configura la autenticación

Como se describió antes, todos los clústeres de flotas aparecen en las listas de clústeres de GKE y GKE Enterprise en la consola. Sin embargo, para ver más detalles, como los nodos y las cargas de trabajo (y para realizar tareas de administración del ciclo de vida del clúster si la función está habilitada), los usuarios deben acceder y autenticarse en el clúster. Para hacerlo, tus clústeres registrados deben configurarse con uno de los siguientes métodos de autenticación:

Identidad de Google: Esta opción permite que los usuarios accedan con su identidad de Google Cloud, que es la dirección de correo electrónico asociada a tu cuenta de Google Cloud. Usa esta opción si tus usuarios ya tienen acceso a Google Cloud con una identidad de Google Cloud. Si creaste el clúster en la consola, puedes acceder a él con tu identidad de Google, pero deberás configurar la autenticación para otros usuarios.

Acceder con la identidad de Google es el enfoque más simple para la autenticación en la consola, en especial si estás probando Google Distributed Cloud con una instalación mínima, así que describimos cómo configurarlo con más detalle. a continuación, en Configura la autenticación de identidad de Google.
OpenID Connect (OIDC): Esta opción permite que los usuarios accedan a los clústeres desde la consola con su identidad desde un proveedor de identidad de OIDC de terceros, como Okta o Microsoft AD FS. Se recomienda usar esta opción si tus usuarios tienen nombres de usuario, contraseñas y membresías de grupos de seguridad existentes de tu proveedor. Puedes obtener información para configurar la autenticación OIDC de terceros para tus clústeres en las siguientes guías:
- Configura clústeres para GKE Identity Service con OIDC: En esta guía, se muestra cómo configurar la autenticación de OIDC por clúster.
- Configura GKE Identity Service para una flota: Esta opción te permite configurar OIDC a nivel de la flota.
Token del portador: Si las soluciones anteriores que ofrece Google no son adecuadas para tu organización, puedes configurar la autenticación con una cuenta de servicio de Kubernetes y con su token del portador para acceder. Para obtener más información, consulta Configura un token del portador.

Otorga roles necesarios

El acceso a la consola se controla mediante Identity and Access Management (IAM). Estos roles de IAM son necesarios, independientemente del método de autenticación que elijas. Para administrar el ciclo de vida del clúster en la consola, debes otorgar algunos roles de IAM.

Para permitir que los usuarios accedan a la consola, como mínimo, debes otorgar los siguientes roles:
- roles/container.viewer Este rol permite que los usuarios vean la página de clústeres de GKE y otros recursos de contenedores en la consola. Para obtener más información sobre los permisos incluidos en este rol o sobre cómo otorgar un rol con permisos de lectura y escritura, consulta Roles de Kubernetes Engine en la documentación de IAM.
- roles/gkehub.viewer Este rol permite que los usuarios vean clústeres fuera de Google Cloud en la consola. Si deseas obtener detalles sobre los permisos incluidos en este rol o para otorgar un rol con permisos de lectura y escritura, consulta Roles de GKE Hub en la documentación de IAM.
Para permitir que los usuarios administren el ciclo de vida del clúster en la consola, otorga el rol de IAM roles/gkeonprem.admin. El rol roles/gkeonprem.admin otorga a los usuarios acceso de administrador a la API de GKE On-Prem, que la consola usa para administrar el ciclo de vida del clúster. Para obtener más detalles sobre los permisos incluidos en este rol, consulta Roles de GKE On-Prem en la documentación de IAM.

Con los siguientes comandos, se muestra cómo otorgar los roles mínimos necesarios para administrar el ciclo de vida del clúster en la consola:

gcloud projects add-iam-policy-binding FLEET_HOST_PROJECT_ID \
    --member=MEMBER \
    --role=roles/container.viewer

gcloud projects add-iam-policy-binding FLEET_HOST_PROJECT_ID \
    --member=MEMBER \
    --role=roles/gkehub.viewer

gcloud projects add-iam-policy-binding FLEET_HOST_PROJECT_ID \
    --member=MEMBER \
    --role=roles/gkeonprem.admin

Donde:

FLEET_HOST_PROJECT_ID es el proyecto host de la flota. En el caso de los clústeres creados con gkectl, este es el proyecto que configuraste en la sección gkeConnect del archivo de configuración del clúster de usuario. En el caso de los clústeres creados en la consola, este es el proyecto que elegiste cuando se creó el clúster.
MEMBER es la dirección de correo electrónico del usuario en el formato user:emailID, por ejemplo: user:alice@example.com.

Habilita la administración del ciclo de vida de los clústeres en la consola

Los clústeres de usuario creados mediante herramientas estándar (la consola, gcloud CLI o Terraform) se inscriben de forma automática en la API de GKE On-Prem y te permiten realizar tareas de administración del ciclo de vida de los clústeres en la consola. Si deseas habilitar esta función para los clústeres de usuarios creados mediante gkectl, sigue los pasos en Configura un clúster de usuario para que lo administre la API de GKE On-Prem. Cuando la administración del ciclo de vida del clúster está habilitada, puedes realizar las siguientes tareas desde la consola:

Configura la autenticación de identidad de Google

Para permitir que los usuarios accedan al clúster con su identidad de Google, debes configurar lo siguiente:

Los usuarios necesitan roles específicos de Identity and Access Management (IAM) para poder ver los clústeres y, además, interactuar con ellos en la consola en la lista de clústeres de GKE.
Se deben agregar los usuarios a las políticas de control de acceso basado en roles (RBAC) de Kubernetes que la puerta de enlace de Connect necesita para acceder al servidor de la API de Kubernetes del clúster medianteAgente de Connect.

Configura la autorización de RBAC

Cada servidor de la API de Kubernetes de cada clúster debe poder autorizar las solicitudes que provienen de la consola. Para configurar la autorización, debes configurar las políticas de control de acceso basado en roles (RBAC) de Kubernetes en cada clúster.

Si usaste una herramienta estándar para crear el clúster de usuarios, es posible que ya tengas las políticas de RBAC adecuadas que te otorgan acceso administrativo completo al clúster. La API de GKE On-Prem agrega tu Cuenta de Google automáticamente como administrador en los siguientes casos:

Creaste el clúster de usuario en la consola.
Creaste el clúster de usuario con gcloud CLI y tu Cuenta de Google se especificó en la marca --admin-users en el comando create del clúster.
Creaste el clúster de usuario mediante Terraform y se especificó tu Cuenta de Google en el campo authorization.admin_users.username.

Los clústeres de usuario creados con gkectl no te otorgan las políticas de RBAC para administrar el clúster con la consola. Debes agregarte después de crear el clúster. Sin importar la herramienta que usaste para crear el clúster, puedes agregar a otras personas como administradores después de crear el clúster.

Puedes usar cualquiera de las siguientes formas para otorgar acceso de administrador al clúster. Se proporcionan dos comandos gcloud diferentes.

El comando gcloud ... generate-gateway-rbac debe ejecutarse en tu estación de trabajo de administrador porque requiere acceso al kubeconfig y al contexto del clúster (que, por lo general, solo se encuentran en la estación de trabajo de administrador). El comando generate-gateway-rbac te permite personalizar las políticas de RBAC, pero las direcciones de correo electrónico de los usuarios no se mostrarán como administradores en la sección Detalles del clúster en la consola.
El comando gcloud ... update se puede ejecutar en tu estación de trabajo de administrador o en cualquier computadora que tenga acceso a la API de GKE On-Prem.

`generate-gateway-rbac`

Conéctate a la estación de trabajo de administrador.
Ejecuta el siguiente comando para actualizar los componentes:
```
gcloud components update
```
Genera y aplica las políticas de RBAC a tu clúster para usuarios y cuentas de servicio:
```
gcloud container fleet memberships generate-gateway-rbac  \
    --membership=MEMBERSHIP_NAME \
    --role=ROLE \
    --users=USERS \
    --project=FLEET_HOST_PROJECT_ID \
    --kubeconfig=KUBECONFIG_PATH \
    --context=KUBECONFIG_CONTEXT \
    --apply
```
Reemplaza lo siguiente:
- MEMBERSHIP_NAME: el nombre que se usa para representar de manera inequívoca el clúster en su flota. En Google Distributed Cloud, el nombre de la membresía y el nombre del clúster son los mismos.
- ROLE: El rol de Kubernetes que deseas otorgar a los usuarios en el clúster. Para otorgar a los usuarios acceso completo a cada recurso del clúster en todos los espacios de nombres, especifica clusterrole/cluster-admin. Para proporcionar acceso de solo lectura, especifica clusterrole/view. También puedes crear un rol personalizado, por ejemplo: role/mynamespace/namespace-reader. El rol personalizado ya debe existir antes de ejecutar el comando.
- USERS: Son las direcciones de correo electrónico de los usuarios (cuentas de usuario o cuentas de servicio) a los que deseas otorgar los permisos, como una lista separada por comas. Por ejemplo: --users=foo@example.com,test-acct@test-project.iam.gserviceaccount.com
- FLEET_HOST_PROJECT_ID el ID del proyecto host de la flota.
- KUBECONFIG_PATH: la ruta local en el que el kubeconfig que contiene una entrada para el clúster se almacena.
- KUBECONFIG_CONTEXT: Es el contexto del clúster como aparece en el archivo kubeconfig. Puedes obtener el contexto actual de la línea de comandos ejecutando kubectl config current-context. Independientemente de si usas o no el contexto actual, asegúrate de que funcione para acceder al clúster mediante la ejecución de un comando simple, como el siguiente:
```
kubectl get namespaces \
  --kubeconfig=KUBECONFIG_PATH \
  --context=KUBECONFIG_CONTEXT
```
Después de ejecutar gcloud container fleet memberships generate-gateway-rbac, verás algo similar al siguiente al final del resultado, que se trunca para facilitar la lectura:
```
Validating input arguments.
Specified Cluster Role is: clusterrole/cluster-admin
Generated RBAC policy is:
--------------------------------------------
...
Applying the generate RBAC policy to cluster with kubeconfig: /usr/local/google/home/foo/.kube/config, context: kind-kind
Writing RBAC policy for user: foo@example.com to cluster.
Successfully applied the RBAC policy to cluster.
```
Este es el contexto para acceder al clúster a través de la puerta de enlace de Connect.

Para conocer más detalles sobre el comando generate-gateway-rbac, consulta la guía de referencia de la CLI de gcloud.

`update`

Ejecuta el siguiente comando para actualizar los componentes:
```
gcloud components update
```
Para cada usuario al que se le debe otorgar el rol clusterrole/cluster-admin, incluye la marca --admin-users y ejecuta el siguiente comando. No puedes especificar varios usuarios en una sola marca. Asegúrate de incluir tu Cuenta de Google en el comando, ya que el comando reemplaza la lista de concesiones con los usuarios que especificas en el comando.
```
gcloud container vmware clusters update USER_CLUSTER_NAME \
  --admin-users YOUR_GOOGLE_ACCOUNT \
  --admin-users ADMIN_GOOGLE_ACCOUNT_1 \
```

Además de otorgar el rol clusterrole/cluster-admin de Kubernetes, el comando otorga las políticas de RBAC que los usuarios necesitan para acceder al clúster a través de la puerta de enlace de Connect.

Console

Para aplicar las políticas de RBAC a los usuarios, realiza los siguientes pasos en la consola:

En la consola, ve a la página Descripción general de los clústeres de Google Kubernetes Engine.

Ir a los clústeres de GKE
Selecciona el proyecto de Google Cloud en el que se encuentra el clúster de usuario.
En la lista de clústeres, haz clic en el nombre del clúster para mostrar sus detalles.
En la sección Autorización, haz clic en el botón de edición Usuarios administradores.
Ingresa la dirección de correo electrónico del usuario que deseas agregar como administrador del clúster en el panel Editar autorización. Para agregar más usuarios administradores, haz clic en Agregar usuario administrador.
Cuando termines de agregar usuarios, haz clic en Guardar cambios.