Version 1.14. This version is no longer supported. For information about how to upgrade to version 1.15, see Upgrading Anthos on bare metal in the 1.15 documentation. For more information about supported and unsupported versions, see the Version history page in the latest documentation.

Anmeldedaten erstellen und verwenden, um Images aus Cloud Storage für die VM-Laufzeit in Google Distributed Cloud zu importieren

In diesem Dokument erfahren Sie, wie Sie Anmeldedaten erstellen und verwenden, um über VM Runtime in Google Distributed Cloud auf Cloud Storage zuzugreifen. Mit einem Cloud Storage-Plug-in können Sie VM-Images aus Cloud Storage-Buckets mithilfe des Containerized Data Importer (CDI) importieren. Anschließend können Sie virtuelle Laufwerke aus diesen Images in Cloud Storage erstellen und an VMs anhängen, die in Ihrem Cluster ausgeführt werden. CDI wird automatisch in einem Cluster aktiviert, auf dem die VM-Laufzeit in Google Distributed Cloud ausgeführt wird.

Hinweise

Um dieses Dokument abzuschließen, benötigen Sie Zugriff auf die folgenden Ressourcen:

Zugriff auf Cluster von GKE on Bare Metal ab Version 1.12.0 (anthosBareMetalVersion: 1.12.0). Sie können einen beliebigen Clustertyp verwenden, der Arbeitslasten ausführen kann. Testen Sie bei Bedarf GKE on Bare Metal in Compute Engine oder lesen Sie die Übersicht über die Clustererstellung.
Ein Dienstkonto und einen Dienstkontoschlüssel, den Sie für den Cloud Storage-Zugriff verwenden möchten. Konfigurieren Sie bei Bedarf ein Dienstkonto, das auf einen Cloud Storage-Bucket zugreifen kann.

Anmeldedaten – Übersicht

Für den Zugriff auf Cloud Storage verwenden Sie ein Dienstkonto, das Anmeldedaten für den Storage-Bucket bereitstellt. Das Dienstkonto benötigt verschiedene Berechtigungen, um auf einen Storage-Bucket zugreifen zu können:

Öffentlicher Storage-Bucket: Sie verwenden ein Dienstkonto zur Selbstidentifikation, aber es sind keine spezifischen Berechtigungen erforderlich.
Privater Storage-Bucket: Für das Speicherkonto ist die Berechtigung Betrachter oder Administrator für den Storage-Bucket erforderlich.

Es gibt zwei Möglichkeiten, dem CDI die Anmeldedaten für das Dienstkonto bereitzustellen:

Konfigurieren Sie die Google-Standardanmeldedaten für Anwendungen auf den Knoten in Ihrem Cluster. Weitere Informationen finden Sie unter Authentifizierung als Dienstkonto.
Geben Sie ein Secret an, das den Schlüssel des Dienstkontos für den Zugriff auf Cloud Storage enthält. Im Rest dieses Dokuments erfahren Sie, wie Sie einen Dienstkontoschlüssel und ein Secret erstellen.

Secret erstellen

Sie übergeben den Dienstkontoschlüssel an Kubernetes mithilfe eines Secrets, das im Namespace des Daten-Volumes erstellt wurde. Der Abschnitt data des Secrets enthält einen Eintrag für creds-gcp.json. Der Wert entspricht den base64-codierten Daten der Dienstkonto-Schlüsseldatei. Über die Befehlszeile werden diese base64-codierten Daten für Sie erstellt. Wenn Sie das Secret mit einem YAML-Manifest erstellen, erstellen Sie zuerst einen base64-Hash des Inhalts Ihrer Dienstkonto-Schlüsseldatei.

CLI

Erstellen Sie das Secret mit kubectl:
```
kubectl create secret generic SECRET_NAME \
  --from-file=creds-gcp.json=SERVICE_ACCOUNT_KEY_PATH \
  --namespace NAMESPACE_NAME
```
Ersetzen Sie die folgenden Werte:
- SECRET_NAME: der Name Ihres Secrets.
- SERVICE_ACCOUNT_KEY_PATH: der Pfad zu Ihrer Dienstkonto-Schlüsseldatei.
- NAMESPACE_NAME: der Namespace für Ihr Secret.
  - Erstellen Sie das Secret in dem Cluster, in dem CDI ausgeführt wird, und im selben Namespace wie das Daten-Volume. CDI wird automatisch in einem Cluster aktiviert, auf dem die VM-Laufzeit in Google Distributed Cloud ausgeführt wird.

Manifest

Erstellen Sie in einem Editor Ihrer Wahl ein Secret-Manifest wie secret.yaml:
```
nano my-secret.yaml
```
Kopieren Sie das folgende YAML-Manifest und fügen Sie es ein:
```
apiVersion: v1
data:
  creds-gcp.json: BASE64_SERVICE_ACCOUNT_FILE
kind: Secret
metadata:
  name: SECRET_NAME
  namespace: NAMESPACE_NAME
type: Opaque
```
Ersetzen Sie die folgenden Werte:
- BASE64_SERVICE_ACCOUNT_FILE: der base64-Hash des Inhalts Ihrer Dienstkonto-Schlüsseldatei.
- SECRET_NAME: der Name Ihres Secrets.
- NAMESPACE_NAME: der Namespace für Ihr Secret.
  - Erstellen Sie das Secret in dem Cluster, in dem CDI ausgeführt wird, und im selben Namespace wie das Daten-Volume. CDI wird automatisch in einem Cluster aktiviert, auf dem die VM-Laufzeit in Google Distributed Cloud ausgeführt wird.
Speichern und schließen Sie das Secret-Manifest in Ihrem Editor.
Wenden Sie das Secret-Manifest mit kubectl an:
```
kubectl apply -f my-secret.yaml
```

Vorhandenes Secret weiterleiten

Anstatt ein Secret zu erstellen, können Sie einen SecretForwarder erstellen, um ein vorhandenes Secret zur Verwendung weiterzuleiten. Der SecretForwarder unterstützt das Weiterleiten von Secrets innerhalb desselben Clusters oder über Cluster hinweg, z. B. vom Administratorcluster an einen Nutzercluster.

Damit mit dem Ziel-Secret auf Cloud Storage zugegriffen werden kann, muss das Quell-Secret im Abschnitt data einen creds-gcp.json-Schlüssel haben.

Gleicher Cluster

Im folgenden Beispiel wird mit dem SecretForwarder-Manifest ein Secret im selben Cluster weitergeleitet:

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

Dieses Beispiel tut Folgendes:

Erstellt einen SecretForwarder namens cdi-gcs im Namespace default.
Leitet das Secret namens gke-connect im Namespace anthos-creds an ein neues Secret mit dem Namen gcs-sa im Namespace default weiter.
Erstellt das neue Secret im selben Cluster.

Führen Sie die folgenden Schritte aus, um ein Secret im selben Cluster weiterzuleiten:

Erstellen Sie in einem Editor Ihrer Wahl ein SecretForwarder-Manifest wie my-forwarded-secret.yaml:
```
nano my-forwarded-secret.yaml
```
Kopieren Sie das folgende YAML-Manifest und fügen Sie es ein:
```
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
```
Ersetzen Sie die folgenden Werte:
- SECRET_FORWARDER_NAME: der Name für Ihren SecretForwarder.
- NAMESPACE_NAME: Namespace für Ihren SecretForwarder.
- TARGET_SECRET_NAME: der Name des neuen Secrets.
- TARGET_NAMESPACE_NAME: die Namespaces für Ihr neues Secret.
  - Erstellen Sie das Secret in dem Cluster, in dem CDI ausgeführt wird, und im selben Namespace wie das Daten-Volume. CDI wird automatisch in einem Cluster aktiviert, auf dem die VM-Laufzeit in Google Distributed Cloud ausgeführt wird.
- SOURCE_SECRET_NAME: der Name des Quell-Secrets, das weitergeleitet werden soll.
- SOURCE_NAMESPACE_NAME: der Namespace des Quell-Secrets, das weitergeleitet werden soll.
Speichern und schließen Sie das Manifest SecretForwarder in Ihrem Editor.
Wenden Sie das SecretForwarder-Manifest mit kubectl an:
```
kubectl apply -f my-forwarded-secret.yaml
```

Clusterübergreifend

Im folgenden SecretForwarder-Beispielmanifest wird ein Secret über Cluster hinweg weitergeleitet:

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

Dieses Beispiel tut Folgendes:

Erstellt einen SecretForwarder namens cdi-gcs im Namespace cluster-user1.
Leitet das Secret namens gke-connect im Namespace anthos-creds an ein neues Secret mit dem Namen gcs-sa im Namespace default weiter.
Erstellt das neue Secret im Cluster mit dem Namen user1.

Führen Sie die folgenden Schritte aus, um ein Secret im selben Cluster weiterzuleiten:

Erstellen Sie in einem Editor Ihrer Wahl ein SecretForwarder-Manifest wie my-forwarded-secret.yaml:
```
nano my-forwarded-secret.yaml
```
Kopieren Sie das folgende YAML-Manifest und fügen Sie es ein:
```
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
```
Ersetzen Sie die folgenden Werte:
- SECRET_FORWARDER_NAME: der Name Ihres SecretForwarders im Remote-Cluster.
- NAMESPACE_NAME: der Namespace für Ihren SecretForwarder im Remote-Cluster.
- TARGET_SECRET_NAME: der Name des neuen Secrets im Remote-Cluster.
- TARGET_NAMESPACE_NAME: die Namespaces für Ihr neues Secret im Remote-Cluster.
  - Erstellen Sie das Secret in dem Cluster, in dem CDI ausgeführt wird, und im selben Namespace wie das Daten-Volume. CDI wird automatisch in einem Cluster aktiviert, auf dem die VM-Laufzeit in Google Distributed Cloud ausgeführt wird.
- SOURCE_SECRET_NAME: der Name des Quell-Secrets, das weitergeleitet werden soll.
- SOURCE_NAMESPACE_NAME: der Namespace des Quell-Secrets, das weitergeleitet werden soll.
Speichern und schließen Sie das Manifest SecretForwarder in Ihrem Editor.
Wenden Sie das SecretForwarder-Manifest im Administratorcluster mithilfe von kubectl mit der KUBECONFIG des Administratorclusters an:
```
kubectl apply -f my-forwarded-secret.yaml
```

Image mit einem Secret importieren

Führen Sie die folgenden Schritte aus, um mit dem Secret ein Image aus Cloud Storage zu importieren, wenn Sie ein virtuelles Laufwerk und eine VM erstellen:

Erstellen Sie ein Manifest, das eine VirtualMachineDisk und VirtualMachine definiert, z. B. my-vm.yaml, in dem Editor Ihrer Wahl:
```
nano my-vm.yaml
```

Kopieren Sie die folgende YAML-Definition und fügen Sie sie ein:

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

Ersetzen Sie die folgenden Werte:

VM_NAME: der Name Ihrer VM.
IMAGE_URL: die URL zu Ihrem Laufwerk-Image in Cloud Storage, z. B. gs://my-images-bucket/disk.qcow2.
SECRET_NAME: der Name Ihres Secrets.

Speichern und schließen Sie das Manifest in Ihrem Editor.
Erstellen Sie die VM und das Laufwerk mit kubectl:
```
kubectl apply -f my-vm.yaml
```

Nächste Schritte

Virtuelle Laufwerke erstellen und verwalten