Versionsinformationen finden Sie in den Versionshinweisen zu Distributed Cloud Connected.

Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

Arbeitslasten bereitstellen

Auf dieser Seite wird beschrieben, wie Sie Arbeitslasten auf Ihrer mit Google Distributed Cloud Connected verbundenen Hardware bereitstellen, und welche Einschränkungen Sie bei der Konfiguration Ihrer Arbeitslasten beachten müssen.

Bevor Sie diese Schritte ausführen, müssen Sie die Anforderungen für die Installation von 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 Cloudund einigen Netzwerkeinstellungen vorkonfiguriert, die Sie bei der Bestellung von Distributed Cloud Connected angegeben haben.

Ihr von Google zertifizierter Systemintegrator führt 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 IhremGoogle 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 mit Distributed Cloud verbundenen Hardware bereit:

Optional: Distributed Cloud Edge Network API aktivieren
Optional: Initialisieren Sie die Netzwerkkonfiguration Ihrer mit Distributed Cloud verbundenen Zone.
Optional: Distributed Cloud-Netzwerk konfigurieren.
Distributed Cloud Connected-Cluster erstellen Sie können den Fortschritt der Bereitstellung verfolgen, um sicherzugehen, dass der Cluster bereit ist, bevor Sie fortfahren.
Optional: Unterstützung für vom Kunden verwaltete Verschlüsselungsschlüssel (CMEK) für den lokalen Speicher aktivieren, wenn Sie Cloud Key Management Service einbinden möchten, um die Unterstützung für CMEK für Ihre Arbeitslastdaten zu aktivieren. Informationen dazu, wie Distributed Cloud Connected Arbeitslastdaten verschlüsselt, finden Sie unter Sicherheit des lokalen Speichers.
Erstellen Sie einen Knotenpool. In diesem Schritt weisen Sie einem Knotenpool Knoten zu und konfigurieren den Knotenpool optional so, dass Cloud KMS zum Ein- und Auspacken der LUKS-Passphrase (Linux Unified Key Setup) zum Verschlüsseln von Arbeitslastdaten verwendet wird.
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 Viewer (roles/edgecontainer.viewer) oder Edge Container Admin (roles/edgecontainer.admin) für das Projekt zuweisen.
Nutzern mithilfe von RoleBinding und ClusterRoleBinding detaillierten rollenbasierten Zugriff auf die Clusterressourcen zuweisen.
Optional: VM Runtime on GDC konfigurieren, 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 mit Distributed Cloud verbundenen Cluster verfügbar machen:

Erstellen Sie eine YAML-Datei mit dem Namen nginx-deployment.yaml und folgendem 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 folgendem 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-Netzwerkfunktionsoperatorressource so:

Mit dem folgenden Befehl können Sie die Knoten auflisten, die im Knotenpool des Zielclusters ausgeführt werden:
```
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 sich die zurückgegebenen Knotennamen und leiten Sie die entsprechenden Kurznamen ab. Der Kurzname des Knotens pool-example-node-1-01-b2d82cc7 ist beispielsweise node101.

Erstellen Sie für jeden Knoten, den Sie im vorherigen Schritt aufgezeichnet haben, eine eigene NodeSystemConfigUpdate-Ressourcendatei mit folgendem 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 wird. Beispiel: node101.

Benennen Sie jede Datei mit 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. Behalten Sie den Status der betroffenen Knoten im Blick, bis alle erfolgreich 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 mit Distributed Cloud verbundenen 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 auf dem Knoten, auf dem der Pod gehostet wird, der Speicherplatz ausgeht, werden keine neuen Bilder im Cache gespeichert und der vorhandene Bild-Cache wird geleert, damit Ihre Arbeitslasten weiterhin ohne Unterbrechung ausgeführt werden.

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 Pod auf IfNotPresent festlegen, damit immer die im Cache gespeicherte Kopie des Ziel-Images verwendet wird. Wenn keine lokale Kopie im Cache verfügbar ist, wird das Image aus dem Repository abgerufen.

Das folgende Beispiel zeigt eine Pod-Konfiguration mit aktiviertem Caching:

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 mit aktiviertem Caching:

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 mit Distributed Cloud verbundenen 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 mit Distributed Cloud verbundenen 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

Namespace-Einschränkungen

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 dem ein Client auf Grundlage einer Signieranfrage die Ausstellung eines X.509-Zertifikats anfordern kann.

Einschränkungen des Sicherheitskontexts

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

Einschränkungen bei der Pod-Bindung

Distributed Cloud Connected unterstützt das Binden von Pods an Hostports im HostNetwork-Namespace nicht. Außerdem ist der Namespace HostNetwork nicht verfügbar.

`hostPath` Volumenbeschränkungen

Distributed Cloud Connected erlaubt nur die folgenden hostPath-Volumes mit Lese-/Schreibzugriff:

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

`PersistentVolumeClaim` Einschränkungen für Ressourcentypen

Distributed Cloud Connected unterstützt nur die folgenden PersistentVolumeClaim-Ressourcentypen:

csi
nfs
local

Einschränkungen für Volumetypen

Distributed Cloud Connected unterstützt nur die folgenden Volumetypen:

configMap
csi
downwardAPI
emptyDir
hostPath
nfs
persistentVolumeClaim
projected
secret

Einschränkungen bei der Pod-Toleranz

Mit Distributed Cloud Connected können Nutzer keine Pods auf Steuerungsebenenknoten erstellen. Insbesondere lässt Distributed Cloud Connected keine Planung von Pods mit den folgenden Toleranzschlüsseln zu:

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

Einschränkungen bei der Identitätsübernahme

Distributed Cloud Connected unterstützt keine Identitätsübernahme von Nutzern oder Gruppen.

Einschränkungen für Verwaltungs-Namespaces

Distributed Cloud Connected erlaubt keinen Zugriff auf die folgenden Namespaces:

ai-system
ai-speech-system
ai-ocr-system
ai-translation-system
anthos-creds
anthos-identity-service
capi-system
capi-kubeadm-bootstrap-system
cert-manager
cert-manager-cluster-resources
dataproc-system
dataproc-PROJECT_ID
dns-system
g-istio-system
gke-connect
gke-managed-metrics-server
gke-operators
gke-system
gpu-system
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 der Bearbeitung von configMap-Ressourcen zum Festlegen von Load-Balancing-IP-Adressbereichen
nf-operator
oclcm-system
prediction
prom-monitoring
rm-system
robinio
robin-admin
saas-system
vm-system

PROJECT_ID steht für die ID des Google Cloud Zielprojekts.

Vermeiden Sie die Verwendung von Namespaces, deren Namen das Präfix g- enthalten. Solche Namespaces sind in der Regel ein reservierter Namespace, der von Distributed Cloud Connected verwendet wird.

Webhook-Einschränkungen

Bei Distributed Cloud Connected gelten für Webhooks die folgenden Einschränkungen:

Bei jedem mutierenden Webhook, den Sie erstellen, wird der Namespace kube-system automatisch ausgeschlossen.
Mutating Webhooks sind für die folgenden Ressourcentypen deaktiviert:
- nodes
- persistentvolumes
- certificatesigningrequests
- tokenreviews

Laufzeitklasse für einen Pod konfigurieren

Mit Distributed Cloud Connected können Sie die Laufzeitklasse für einen Pod in seiner Konfiguration mit dem Feld runtimeClassName angeben. Dadurch wird die standardmäßige Laufzeitklasse ü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, sofern Sie keine Standardlaufzeitklasse mit dem Parameter --default-container-runtime konfigurieren, 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.

`gvisor`-Laufzeitklasse

Durch Angabe der Laufzeitklasse gvisor wird der Pod auf die sichere Laufzeit der Open Container Initiative (OCI) auf Basis von gVisor umgestellt. gVisor ist eine Sandboxing-Lösung, die eine starke Isolation zwischen der Arbeitslast und ihrem Host einführt.

VPC Service Controls-Integration konfigurieren

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

Laufzeitpriorität für einen Pod angeben

Mit Distributed Cloud Connected können Sie in der Konfiguration eines Pods mit dem Feld priorityClassName eine Prioritätsklasse für den Pod angeben. In diesem Feld wird der Name einer PriorityClass-Ressource angegeben, die die Zielpriorität festlegt. Beispiel:

kind: PriorityClass
metadata:
  name: high-priority-class
value: 5100000
globalDefault: false
description: "High priority class for user workloads."

Geben Sie den Namen der Prioritätsklasse in Ihrer Pod-Konfiguration an, wie im folgenden Beispiel gezeigt:

apiVersion: v1
kind: Pod
metadata:
  name: myPod
spec:
  priorityClassName: high-priority-class
  containers:
  - name: myPod
    image: myPodImage 
  restartPolicy: OnFailure

Wenn Sie eine Prioritätsklasse angeben, wird die Standard-Pod-Priorität von 0 überschrieben. Legen Sie für kritische Arbeitslasten die Priorität auf einen Wert zwischen 5000001 und 1000000000 fest. Bei Distributed Cloud Connected werden Arbeitslasten mit niedrigerer Priorität automatisch unterbrochen.

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 zu integrieren. Informationen zur Syntax von Regeln für ausgehenden Traffic finden Sie in der Referenz zu Regeln für ausgehenden Traffic.

Zugriff auf die Maschinenzone und das Google Cloud Projekt

Mit dieser Regel kann die aufrufende Identität auf die Maschinenzone und das Google Cloud -Projekt zugreifen, wenn Aufrufe über die Distributed Cloud Edge Container API erfolgen. Diese Regel gilt, wenn sich der Computer und der Cluster nicht im selbenGoogle Cloud -Projekt befinden und das 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.

Im Folgenden finden Sie ein Beispiel für eine egressFrom-Konfiguration für diese Regel im JSON-Format:

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

Hier sehen Sie ein Beispiel für 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 zu integrieren. Informationen zur Syntax von Regeln für eingehenden Traffic finden Sie unter 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, sich außerhalb des Perimeters befindet.

Hier sehen Sie ein Beispiel für eine ingressFrom-Konfiguration für diese Regel:

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

Hier sehen Sie ein Beispiel für 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.