Crea y usa credenciales a fin de importar imágenes desde Cloud Storage para el entorno de ejecución de VM en GDC.

En este documento, se muestra cómo crear y usar credenciales para acceder a Cloud Storage mediante el entorno de ejecución de VM en GDC. Un complemento de Cloud Storage te permite usar el importador de datos alojados en contenedores (CDI) para importar imágenes de VM desde buckets de Cloud Storage. Luego, puedes crear discos virtuales a partir de estas imágenes en Cloud Storage y adjuntarlos a las VM que se ejecutan en tu clúster. CDI se habilita de forma automática en un clúster que ejecuta el entorno de ejecución de VM en GDC.

Antes de comenzar

Para completar este documento, necesitas acceso a los siguientes recursos:

Descripción general de las credenciales

Para acceder a Cloud Storage, usa una cuenta de servicio que proporcione credenciales al bucket de almacenamiento. La cuenta de servicio requiere privilegios diferentes para acceder de forma correcta a un bucket de almacenamiento:

  • Bucket de almacenamiento público: Usa una cuenta de servicio para la identificación automática, pero no se requieren permisos específicos.
  • Bucket de almacenamiento privado: La cuenta de almacenamiento requiere el privilegio de visualizador o administrador para el bucket de almacenamiento.

Existen dos maneras de proporcionar las credenciales de la cuenta de servicio al CDI:

  • Configura las credenciales predeterminadas de la aplicación (ADC) de Google en los nodos de tu clúster. Para obtener más información, consulta Autentícate como cuenta de servicio.
  • Proporciona un Secret que contenga la clave de la cuenta de servicio para acceder a Cloud Storage. En el resto de este documento, se muestra cómo crear una clave y un Secret de cuenta de servicio.

Crear Secret

Pasa la clave de la cuenta de servicio a Kubernetes mediante un Secret creado en el espacio de nombres del volumen de datos. La sección data del Secret contiene una entrada para creds-gcp.json. El valor son los datos codificados en Base64 del archivo de claves de la cuenta de servicio. La CLI crea estos datos codificados en Base64 por ti. Si usas un manifiesto YAML para crear el Secret, primero crea un hash en Base64 del contenido del archivo de claves de tu cuenta de servicio.

CLI

  • Crea el Secret con kubectl:

    kubectl create secret generic SECRET_NAME \
      --from-file=creds-gcp.json=SERVICE_ACCOUNT_KEY_PATH \
      --namespace NAMESPACE_NAME
    

    Reemplaza los siguientes valores:

    • SECRET_NAME: Es el nombre del Secret.
    • SERVICE_ACCOUNT_KEY_PATH: Es la ruta de acceso al archivo de claves de la cuenta de servicio.
    • NAMESPACE_NAME: El espacio de nombres de tu Secret.
      • Crea tu Secret en el clúster en el que se ejecuta el CDI y en el mismo espacio de nombres que el volumen de datos. CDI se habilita de forma automática en un clúster que ejecuta el entorno de ejecución de VM en GDC.

Manifiesto

  1. Crea un manifiesto Secret, como my-secret.yaml, en el editor que elijas:

    nano my-secret.yaml
    
  2. Copia y pega el siguiente manifiesto YAML:

    apiVersion: v1
    data:
      creds-gcp.json: BASE64_SERVICE_ACCOUNT_FILE
    kind: Secret
    metadata:
      name: SECRET_NAME
      namespace: NAMESPACE_NAME
    type: Opaque
    

    Reemplaza los siguientes valores:

    • BASE64_SERVICE_ACCOUNT_FILE: Es el hash Base64 del contenido del archivo de claves de la cuenta de servicio.
    • SECRET_NAME: Es el nombre del Secret.
    • NAMESPACE_NAME: El espacio de nombres de tu Secret.
      • Crea tu Secret en el clúster en el que se ejecuta el CDI y en el mismo espacio de nombres que el volumen de datos. CDI se habilita de forma automática en un clúster que ejecuta el entorno de ejecución de VM en GDC.
  3. Guarda y cierra el manifiesto del Secret en el editor.

  4. Aplica el manifiesto del Secret con kubectl:

    kubectl apply -f my-secret.yaml
    

Reenvía un Secret existente

En lugar de crear un Secret, puedes crear un SecretForwarder a fin de reenviar un Secret existente para su uso. SecretForwarder admite el reenvío de Secrets dentro del mismo clúster o en clústeres, por ejemplo, desde el clúster de administrador a un clúster de usuario.

Si quieres usar el Secret de destino para acceder a Cloud Storage, el Secret de origen debe tener una clave creds-gcp.json en su sección data.

En el mismo clúster

En el siguiente ejemplo de manifiesto SecretForwarder, se reenvía un Secret al mismo clúster:

apiVersion: baremetal.cluster.gke.io/v1
kind: SecretForwarder
metadata:
  name: cdi-gcs
  namespace: default
spec:
  inClusterTargetSecrets:
    name: gcs-sa
    namespaces:
    - default
  sourceSecret:
    name: gke-connect
    namespace: anthos-creds

En este ejemplo, se realizan las acciones siguientes:

  • Crea un SecretForwarder llamado cdi-gcs en el espacio de nombres default.
  • Reenvía el Secret gke-connect en el espacio de nombres anthos-creds a un Secret nuevo llamado gcs-sa en el espacio de nombres default.
  • Crea el Secret nuevo en el mismo clúster.

Para reenviar un Secret en el mismo clúster, completa los siguientes pasos:

  1. Crea un manifiesto SecretForwarder, como my-forwarded-secret.yaml, en el editor que elijas:

    nano my-forwarded-secret.yaml
    
  2. Copia y pega el siguiente manifiesto YAML:

    apiVersion: baremetal.cluster.gke.io/v1
    kind: SecretForwarder
    metadata:
      name: SECRET_FORWARDER_NAME
      namespace: NAMESPACE_NAME
    spec:
      inClusterTargetSecrets:
        name: TARGET_SECRET_NAME
        namespaces:
        - TARGET_NAMESPACE_NAME
      sourceSecret:
        name: SOURCE_SECRET_NAME
        namespace: SOURCE_NAMESPACE_NAME
    

    Reemplaza los siguientes valores:

    • SECRET_FORWARDER_NAME: Es el nombre de tu SecretForwarder.
    • NAMESPACE_NAME: Es el espacio de nombres de tu SecretForwarder.
    • TARGET_SECRET_NAME: Es el nombre del nuevo Secret.
    • TARGET_NAMESPACE_NAME: Son los espacios de nombres para tu nuevo Secret.
      • Crea tu Secret en el clúster en el que se ejecuta el CDI y en el mismo espacio de nombres que el volumen de datos. CDI se habilita de forma automática en un clúster que ejecuta el entorno de ejecución de VM en GDC.
    • SOURCE_SECRET_NAME: Es el nombre del Secret de origen que se reenviará.
    • SOURCE_NAMESPACE_NAME: Es el espacio de nombres de tu Secret de origen que se reenviará.
  3. Guarda y cierra el manifiesto SecretForwarder en tu editor.

  4. Aplica el manifiesto SecretForwarder mediante kubectl:

    kubectl apply -f my-forwarded-secret.yaml
    

En clústeres

En el siguiente manifiesto SecretForwarder de ejemplo, se reenvía un Secret a través de los clústeres:

apiVersion: baremetal.cluster.gke.io/v1
kind: SecretForwarder
metadata:
  name: cdi-gcs
  namespace: cluster-user1
spec:
  RemoteClusterTargetSecrets:
    name: gcs-sa
    namespaces:
    - default
  sourceSecret:
    name: gke-connect
    namespace: anthos-creds

En este ejemplo, se realizan las acciones siguientes:

  • Crea un SecretForwarder llamado cdi-gcs en el espacio de nombres cluster-user1.
  • Reenvía el Secret gke-connect en el espacio de nombres anthos-creds a un Secret nuevo llamado gcs-sa en el espacio de nombres default.
  • Crea el Secret nuevo en el clúster llamado user1.

Para reenviar un Secret en el mismo clúster, completa los siguientes pasos:

  1. Crea un manifiesto SecretForwarder, como my-forwarded-secret.yaml, en el editor que elijas:

    nano my-forwarded-secret.yaml
    
  2. Copia y pega el siguiente manifiesto YAML:

    apiVersion: baremetal.cluster.gke.io/v1
    kind: SecretForwarder
    metadata:
      name: SECRET_FORWARDER_NAME
      namespace: NAMESPACE_NAME
    spec:
      RemoteClusterTargetSecrets:
        name: TARGET_SECRET_NAME
        namespaces:
        - TARGET_NAMESPACE_NAME
      sourceSecret:
        name: SOURCE_SECRET_NAME
        namespace: SOURCE_NAMESPACE_NAME
    

    Reemplaza los siguientes valores:

    • SECRET_FORWARDER_NAME: Es el nombre de tu SecretForwarder en el clúster remoto.
    • NAMESPACE_NAME: Es el espacio de nombres de tu SecretForwarder en el clúster remoto.
    • TARGET_SECRET_NAME: Es el nombre del Secret nuevo en el clúster remoto.
    • TARGET_NAMESPACE_NAME: Son los espacios de nombres para tu Secret nuevo en el clúster remoto.
      • Crea tu Secret en el clúster en el que se ejecuta el CDI y en el mismo espacio de nombres que el volumen de datos. CDI se habilita de forma automática en un clúster que ejecuta el entorno de ejecución de VM en GDC.
    • SOURCE_SECRET_NAME: Es el nombre del Secret de origen que se reenviará.
    • SOURCE_NAMESPACE_NAME: Es el espacio de nombres de tu Secret de origen que se reenviará.
  3. Guarda y cierra el manifiesto SecretForwarder en tu editor.

  4. Aplica el manifiesto SecretForwarder en el clúster de administrador mediante kubectl con el KUBECONFIG del clúster de administrador:

    kubectl apply -f my-forwarded-secret.yaml
    

Usa un Secret para importar una imagen

Para usar el Secret a fin de importar una imagen desde Cloud Storage cuando creas un disco virtual y una VM, completa los siguientes pasos:

  1. Crea un manifiesto que defina VirtualMachineDisk y VirtualMachine, como my-vm.yaml, en el editor que elijas:

    nano my-vm.yaml
    
  2. Copia y pega la siguiente definición de YAML:

    apiVersion: vm.cluster.gke.io/v1
    kind: VirtualMachineDisk
    metadata:
      name: VM_NAME-boot-dv
    spec:
      size: 20Gi
      source:
        gcs:
          url: IMAGE_URL
          secretRef: SECRET_NAME
    ---
    apiVersion: vm.cluster.gke.io/v1
    kind: VirtualMachine
    metadata:
      name: VM_NAME
    spec:
      interfaces:
        - name: eth0
          networkName: pod-network
          default: true
      disks:
        - boot: true
          virtualMachineDiskName: VM_NAME-boot-dv
    

    Reemplaza los siguientes valores:

    • VM_NAME: Es el nombre de tu VM.
    • IMAGE_URL: Es la URL de tu imagen de disco de Cloud Storage, que puede ser gs://my-images-bucket/disk.qcow2.
    • SECRET_NAME: Es el nombre de tu Secret.
  3. Guarda y cierra el manifiesto en tu editor.

  4. Crea la VM y el disco con kubectl:

    kubectl apply -f my-vm.yaml
    

¿Qué sigue?