Versionsinformationen finden Sie in den Versionshinweisen zu Distributed Cloud Connect.

Arbeitslasten bereitstellen

Auf dieser Seite werden die Schritte zum Bereitstellen von Arbeitslasten auf Ihrer Google Distributed Cloud Connected-Hardware und die Einschränkungen beschrieben, die Sie beim Konfigurieren Ihrer Arbeitslasten beachten müssen.

Bevor Sie diese Schritte ausführen, müssen Sie die Installationsanforderungen für Distributed Cloud Connected erfüllen und die Distributed Cloud Hardware bestellen.

Wenn die Google Distributed Cloud Connected-Hardware am ausgewählten Zielort eintrifft, ist sie mit Hardware Google Cloud,und einigen Netzwerkeinstellungen vorkonfiguriert, die Sie bei der Bestellung von Distributed Cloud Connected angegeben haben.

Google-Installateure führen die physische Installation durch und Ihr Systemadministrator verbindet Distributed Cloud Connected mit Ihrem lokalen Netzwerk.

Nachdem die Hardware mit Ihrem lokalen Netzwerk verbunden ist, kommuniziert sie mit Google Cloud um Softwareupdates herunterzuladen und eine Verbindung zu Ihrem Google Cloud Projekt herzustellen. Anschließend können Sie Knotenpools bereitstellen und Arbeitslasten in Distributed Cloud Connected bereitstellen.

Bereitstellungsübersicht

So stellen Sie eine Arbeitslast auf Ihrer Distributed Cloud Connected-Hardware bereit:

Optional: Aktivieren Sie die Distributed Cloud Edge Network API.
Optional: Initialisieren Sie die Netzwerkkonfiguration Ihrer Distributed Cloud Connected-Zone.
Optional: Konfigurieren Sie das Distributed Cloud-Netzwerk.
Erstellen Sie einen Distributed Cloud Connected-Cluster.
Optional: Aktivieren Sie die Unterstützung für vom Kunden verwaltete Verschlüsselungsschlüssel (Customer-Managed Encryption Keys, CMEK) für den lokalen Speicher , wenn Sie Cloud Key Management Service einbinden möchten, um die Unterstützung für CMEK für Ihre Arbeitslastdaten zu aktivieren. Informationen zur Verschlüsselung von Arbeitslastdaten in Distributed Cloud Connected finden Sie unter Sicherheit des lokalen Speichers.
Erstellen Sie einen Knotenpool. In diesem Schritt weisen Sie Knoten einem Knotenpool zu und konfigurieren den Knotenpool optional so, dass Cloud KMS verwendet wird, um die LUKS-Passphrase (Linux Unified Key Setup) zum Verschlüsseln von Arbeitslastdaten zu umschließen und zu entschlüsseln.
Rufen Sie Anmeldedaten für einen Cluster ab um den Cluster zu testen.
Gewähren Sie Nutzern Zugriff auf den Cluster, indem Sie ihnen die Rolle „Edge Container-Betrachter“ (roles/edgecontainer.viewer) oder die Rolle „Edge Container-Administrator“ (roles/edgecontainer.admin) für das Projekt zuweisen.
Weisen Sie Nutzern mit RoleBinding und ClusterRoleBinding einen detaillierten rollenbasierten Zugriff auf die Clusterressourcen zu.
Optional: Aktivieren Sie die Unterstützung für die VM-Laufzeit in Google Distributed Cloud, um Arbeitslasten auf virtuellen Maschinen in Distributed Cloud Connected auszuführen.
Optional: Aktivieren Sie die GPU-Unterstützung, um GPU-basierte Arbeitslasten in Distributed Cloud Connected auszuführen.

NGINX-Load-Balancer als Dienst bereitstellen

Das folgende Beispiel zeigt, wie Sie den NGINX-Server bereitstellen und als Dienst in einem Distributed Cloud Connected-Cluster verfügbar machen:

Erstellen Sie eine YAML-Datei mit dem Namen nginx-deployment.yaml und dem folgenden Inhalt:

apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
labels:
  app: nginx
spec:
replicas: 1
selector:
  matchLabels:
     app: nginx
template:
  metadata:
     labels:
     app: nginx
  spec:
     containers:
     - name: nginx
     image: nginx:latest
     ports:
     - containerPort: 80

Wenden Sie die YAML-Datei mit dem folgenden Befehl auf den Cluster an:
```
kubectl apply -f nginx-deployment.yaml
```

Erstellen Sie eine YAML-Datei mit dem Namen nginx-service.yaml und dem folgenden Inhalt:

apiVersion: v1
kind: Service
metadata:
name: nginx-service
spec:
type: LoadBalancer
selector:
  app: nginx
  ports:
     - protocol: TCP
       port: 8080
       targetPort: 80

Wenden Sie die YAML-Datei mit dem folgenden Befehl auf den Cluster an:
```
kubectl apply -f nginx-deployment.yaml
```

Rufen Sie die externe IP-Adresse ab, die dem Dienst vom MetalLB-Load-Balancer zugewiesen wurde, indem Sie den folgenden Befehl ausführen:

kubectl get services

Die Ausgabe des Befehls sieht in etwa so aus:

NAME            TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)          AGE
nginx-service   LoadBalancer   10.51.195.25   10.100.68.104   8080:31966/TCP   11d

`NodeSystemConfigUpdate`-Ressourcen konfigurieren

Konfigurieren Sie für jeden Knoten im Cluster eine NodeSystemConfigUpdate-Ressource des Netzwerkfunktionsoperators so:

Listen Sie die Knoten auf, die im Knotenpool des Zielclusters ausgeführt werden, indem Sie den folgenden Befehl ausführen:
```
kubectl get nodes | grep -v master
```
Die Ausgabe des Befehls sieht in etwa so aus:
```
NAME                                 STATUS   ROLES       AGE     VERSION
pool-example-node-1-01-b2d82cc7      Ready    <none>      2d      v1.22.8-gke.200
pool-example-node-1-02-52ddvfc9      Ready    <none>      2d      v1.22.8-gke.200
```
Notieren Sie die zurückgegebenen Knotennamen und leiten Sie die Kurznamen ab. Für den Knoten pool-example-node-1-01-b2d82cc7 ist der Kurzname beispielsweise node101.

Erstellen Sie für jeden Knoten, den Sie im vorherigen Schritt notiert haben, eine eigene NodeSystemConfigUpdate-Ressourcendatei mit dem folgenden Inhalt:

apiVersion: networking.gke.io/v1
kind: NodeSystemConfigUpdate
metadata:
name: nodesystemconfigupdate-NODE_SHORT_NAME
namespace: nf-operator
spec:
kubeletConfig:
  cpuManagerPolicy: Static
  topologyManagerPolicy: SingleNumaNode
nodeName: NODE_NAME
osConfig:
  hugePagesConfig:
     ONE_GB: 2
     TWO_MB: 0
  isolatedCpusPerSocket:
     "0": 40
     "1": 40
sysctls:
  nodeLevel:
     net.core.rmem_max: "8388608"
     net.core.wmem_max: "8388608"

Ersetzen Sie Folgendes:

NODE_NAME: der vollständige Name des Zielknotens. Beispiel: pool-example-node-1-01-b2d82cc7.
NODE_SHORT_NAME: der Kurzname des Zielknotens, der aus seinem vollständigen Namen abgeleitet wurde. Beispiel: node101.

Nennen Sie jede Datei node-system-config-update-NODE_SHORT_NAME.yaml.

Wenden Sie jede der NodeSystemConfigUpdate-Ressourcendateien mit dem folgenden Befehl auf den Cluster an:
```
kubectl apply -f node-system-config-update-NODE_SHORT_NAME.yaml
```
Ersetzen Sie NODE_SHORT_NAME durch den Kurznamen des entsprechenden Zielknotens.

Wenn Sie die Ressourcen auf den Cluster anwenden, wird jeder betroffene Knoten neu gestartet. Das kann bis zu 30 Minuten dauern.
1. Prüfen Sie den Status der betroffenen Knoten, bis alle neu gestartet wurden:
```
kubectl get nodes | grep -v master
```
Der Status der einzelnen Knoten ändert sich von not-ready zu ready, sobald sie neu gestartet wurden.

Pod für das Image-Caching konfigurieren

Sie können einen Pod, der in einem Distributed Cloud Connected-Cluster ausgeführt wird, so konfigurieren, dass sein Image im Cache gespeichert wird. Der Pod verwendet das im Cache gespeicherte Image, nachdem es zum ersten Mal aus dem Repository abgerufen wurde. Wenn der Speicherplatz des Knotens, auf dem der Pod gehostet wird, nicht mehr ausreicht, werden keine neuen Images im Cache gespeichert und der vorhandene Image-Cache wird geleert, damit Ihre Arbeitslasten ohne Unterbrechung ausgeführt werden können.

Ihre Pod-Konfiguration muss die folgenden Voraussetzungen erfüllen:

Sie müssen das Label gdce.baremetal.cluster.gke.io/cache-image: true für den Pod festlegen.
Wenn Sie ein privates Image-Repository verwenden, muss Ihre ImagePullSecret-Ressource vom Typ kubernetes.io/dockerconfigjson sein.
Sie müssen die Pull-Richtlinie des Pods auf IfNotPresent festlegen, damit immer die im Cache gespeicherte Kopie des Ziel-Images verwendet wird. Wenn keine im Cache gespeicherte Kopie lokal verfügbar ist, wird das Image aus dem Repository abgerufen.

Das folgende Beispiel zeigt eine Pod-Konfiguration, bei der das Caching aktiviert ist:

apiVersion: v1
kind: Pod
metadata:
  name: cached-image-pod
  labels:
    gdce.baremetal.cluster.gke.io/cache-image: "true"
spec:
  containers:
    - name: my-container
      image: your-private-image-repo/your-image:tag
      imagePullPolicy: IfNotPresent
  imagePullSecrets:
    - name: my-image-secret  # If using a private registry

Das nächste Beispiel zeigt eine Bereitstellungskonfiguration, bei der das Caching aktiviert ist:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cached-image-deployment
spec:
  template:
    metadata:
      labels:
        gdce.baremetal.cluster.gke.io/cache-image: "true"
    spec:
      containers:
        - name: my-container
          image: your-private-image-repo/your-image:tag
          imagePullPolicy: IfNotPresent
      imagePullSecrets:
        - name: my-image-secret  # If using a private registry

Einschränkungen für Distributed Cloud-Arbeitslasten

Wenn Sie Ihre Distributed Cloud Connected-Arbeitslasten konfigurieren, müssen Sie die in diesem Abschnitt beschriebenen Einschränkungen beachten. Diese Einschränkungen werden von Distributed Cloud Connected für alle Arbeitslasten erzwungen, die Sie auf Ihrer Distributed Cloud Connected-Hardware bereitstellen.

Limits für Linux-Arbeitslasten

Distributed Cloud Connected unterstützt nur die folgenden Linux-Berechtigungen für Arbeitslasten:

AUDIT_READ
AUDIT_WRITE
CHOWN
DAC_OVERRIDE
FOWNER
FSETID
IPC_LOCK
IPC_OWNER
KILL
MKNOD
NET_ADMIN
NET_BIND_SERVICE
NET_RAW
SETFCAP
SETGID
SETPCAP
SETUID
SYS_CHROOT
SYS_NICE
SYS_PACCT
SYS_PTRACE
SYS_RESOURCE
SYS_TIME

Einschränkungen für Namespaces

Distributed Cloud Connected unterstützt die folgenden Namespaces nicht:

hostPID
hostIPC
hostNetwork

Einschränkungen für Ressourcentypen

Distributed Cloud Connected unterstützt den Ressourcentyp CertificateSigningRequest nicht. Mit diesem Ressourcentyp kann ein Client ein X.509-Zertifikat anfordern, das auf einer Signaturanfrage basiert.

Einschränkungen für Sicherheitskontexte

Distributed Cloud Connected unterstützt den Sicherheitskontext im privilegierten Modus nicht.

Einschränkungen für die Pod-Bindung

Distributed Cloud Connected unterstützt die Bindung von Pods an Host-Ports im Namespace HostNetwork nicht. Außerdem ist der Namespace HostNetwork nicht verfügbar.

Einschränkungen für `hostPath`-Volumes

Distributed Cloud Connected lässt nur die folgenden hostPath-Volumes mit Lese-/Schreibzugriff zu:

/dev/hugepages
/dev/infiniband
/dev/vfio
/dev/char
/sys/devices

Einschränkungen für den Ressourcentyp `PersistentVolumeClaim`

Distributed Cloud Connected lässt nur die folgenden PersistentVolumeClaim-Ressourcentypen zu:

csi
nfs
local

Einschränkungen für Volumetypen

Distributed Cloud Connected lässt nur die folgenden Volumetypen zu:

configMap
csi
downwardAPI
emptyDir
hostPath
nfs
persistentVolumeClaim
projected
secret

Einschränkungen für Pod-Toleranzen

Distributed Cloud Connected lässt keine von Nutzern erstellten Pods auf Steuerungsebenenknoten zu. Insbesondere lässt Distributed Cloud Connected keine Pods zu, die die folgenden Toleranzschlüssel haben:

""
node-role.kubernetes.io/master
node-role.kubernetes.io/control-plane

Einschränkungen für die Identitätswechsel

Distributed Cloud Connected unterstützt keine Identitätswechsel für Nutzer oder Gruppen.

Einschränkungen für Management-Namespaces

Distributed Cloud Connected lässt keinen Zugriff auf die folgenden Namespaces zu:

ai-system
ai-speech-system
ai-ocr-system
ai-translation-system
anthos-identity-service
cert-manager
dataproc-system
dataproc-PROJECT_ID
dns-system
g-istio-system
gke-connect
gke-managed-metrics-server
gke-operators
g-ospf-servicecontrol-system
g-ospf-system
g-pspf-system
gke-system
gpc-backup-system
iam-system
kube-node-lease
kube-public
kube-system mit Ausnahme des Löschens von ippools.whereabouts.cni.cncf.io
metallb-system mit Ausnahme des Bearbeitens von configMap-Ressourcen zum Festlegen von IP-Adressbereichen für den Load-Balancer
nf-operator
oclcm-system
prediction
rm-system
robinio
saas-system
vm-system

PROJECT_ID steht für die ID des Ziel Google Cloud projekts.

Vermeiden Sie die Verwendung von Namespaces, deren Namen das Präfix g- enthält. Solche Namespaces sind in der Regel reservierte Namespaces, die von Distributed Cloud Connected verwendet werden.

Einschränkungen für Webhooks

Distributed Cloud Connected schränkt Webhooks so ein:

Jeder mutierende Webhook, den Sie erstellen, schließt automatisch den Namespace kube-system aus.
Mutierende Webhooks sind für die folgenden Ressourcentypen deaktiviert:
- nodes
- persistentvolumes
- certificatesigningrequests
- tokenreviews

Einschränkungen für die Pod-Priorität

In Distributed Cloud Connected müssen Sie die Priorität Ihrer Arbeitslast-Pods auf einen Wert unter 500000000 festlegen.

Laufzeitklasse für einen Pod konfigurieren

In Distributed Cloud Connected können Sie die Laufzeitklasse für einen Pod in seiner Konfiguration mit dem Feld runtimeClassName angeben. Dadurch wird die Standardlaufzeitklasse überschrieben, die auf Clusterebene angegeben ist. Die verfügbaren Laufzeitklassen sind runc und gvisor. Beispiel:

apiVersion: v1
kind: Pod
metadata:
  name: myPod
spec:
  runtimeClassName: gvisor
  containers:
  - name: myPod
    image: myPodImage
  restartPolicy: OnFailure

Wenn Sie dies in Ihrer Pod-Konfiguration weglassen, verwendet der Pod die auf Clusterebene angegebene Klasse. Die Standardlaufzeitklasse auf Clusterebene ist runc, es sei denn, Sie konfigurieren eine Standardlaufzeitklasse mit dem --default-container-runtime Parameter, wie unter Cluster erstellen und verwalten beschrieben.

Wenn Sie die Laufzeitklasse entweder auf Pod- oder Clusterebene ändern, müssen Sie die betroffenen Pods neu starten, damit die Änderung wirksam wird.

Laufzeitklasse `gvisor`

Wenn Sie die gvisor Laufzeitklasse angeben, wird der Pod auf die sichere Laufzeit der Open Container Initiative (OCI) umgestellt , die auf gVisor basiert. gVisor ist eine Sandboxing-Lösung, die eine starke Isolierung zwischen der Arbeitslast und ihrem Host bietet.

VPC Service Controls-Integration konfigurieren

Führen Sie die Schritte in diesem Abschnitt aus, um die Integration der Distributed Cloud Edge Container API mit VPC Service Controls zu konfigurieren. Hier finden Sie weitere Informationen:

Erforderliche Regeln für ausgehenden Traffic

Sie müssen die in diesem Abschnitt beschriebenen Regeln für ausgehenden Traffic konfigurieren, um die Distributed Cloud Edge Container API in VPC Service Controls einzubinden. Informationen zur Syntax von Regeln für ausgehenden Traffic finden Sie in der Referenz zu Regeln für ausgehenden Traffic. Egress rules reference.

Zugriff auf die Maschinen-Zone und das Google Cloud Projekt

Mit dieser Regel kann die aufrufende Identität auf die Maschinen-Zone und das Google Cloud Projekt zugreifen, wenn sie Aufrufe mit der Distributed Cloud Edge Container API ausführt. Diese Regel gilt, wenn sich die Maschine und der Cluster nicht im selben Google Cloud Projekt befinden und das Maschinen Google Cloud Projekt außerhalb des Perimeters liegt. Diese Regel ist erforderlich, wenn Sie die Distributed Cloud Edge Container API innerhalb des Perimeters mit VPC Service Controls eingeschränkt haben.

Das folgende Beispiel zeigt eine egressFrom-Konfiguration für diese Regel im JSON-Format:

egressFrom:
  identityType: ANY_SERVICE_ACCOUNT
  sources:
    - accessLevel: "*"

Das folgende Beispiel zeigt eine egressTo-Konfiguration für diese Regel:

egressTo:
 resources:
 - "projects/280968151686"
 operations:
   - serviceName: "edgecontainer.googleapis.com"
     methodSelectors:
       - method: "*"

Erforderliche Regeln für eingehenden Traffic

Sie müssen die in diesem Abschnitt beschriebenen Regeln für eingehenden Traffic konfigurieren, um die Distributed Cloud Edge Container API in VPC Service Controls einzubinden. Informationen zur Syntax von Regeln für eingehenden Traffic finden Sie in der Referenz zu Regeln für eingehenden Traffic.

Zugriff auf die Distributed Cloud Edge Container API

Mit dieser Regel können bestimmte Identitäten auf die Distributed Cloud Edge Container API zugreifen und mit ihr interagieren. Sie müssen diese Regel konfigurieren, wenn Sie die Distributed Cloud Edge Container API innerhalb des Perimeters mit VPC Service Controls eingeschränkt haben und die Identität, die die Distributed Cloud Edge Container API aufruft, außerhalb des Perimeters liegt.

Das folgende Beispiel zeigt eine ingressFrom-Konfiguration für diese Regel:

ingressFrom:
   sources:
     - accessLevel: '*'
   identities:
     - serviceAccount:testuser@kubernetesedge-e2e-testing.iam.gserviceaccount.com

Das folgende Beispiel zeigt eine ingressTo-Konfiguration für diese Regel:

ingressTo:
 resources:
 - "*"
 operations:
   - serviceName: "edgecontainer.googleapis.com"
     methodSelectors:
       - method: "*"

Zugriff auf die Connect API und die Security Token Service API

Mit dieser Regel können Arbeitslasten auf die Connect API und die Security Token Service API zugreifen. Sie müssen diese Regel konfigurieren, wenn Sie den Zugriff auf die Connect API und die Security Token Service API innerhalb des Perimeters mit VPC Service Controls eingeschränkt haben. Informationen zum Einrichten von Zugriffsrichtlinien auf IP-Adressenebene finden Sie unter IP-Adresse.