Arbeitslasten bereitstellen

Auf dieser Seite werden die Schritte zum Bereitstellen von Arbeitslasten auf Ihrer mit Google Distributed Cloud verbundenen Hardware und die Einschränkungen beschrieben, die 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.

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 IhremGoogle Cloud -Projekt herzustellen. Anschließend können Sie Knotenpools bereitstellen und Arbeitslasten in Distributed Cloud Connect bereitstellen.

Bereitstellungsübersicht

So stellen Sie eine Arbeitslast auf Ihrer mit Distributed Cloud verbundenen Hardware bereit:

  1. Optional: Distributed Cloud Edge Network API aktivieren

  2. Optional: Netzwerkkonfiguration Ihrer mit Distributed Cloud verbundenen Zone initialisieren

  3. Optional: Distributed Cloud-Netzwerk konfigurieren.

  4. Distributed Cloud Connected-Cluster erstellen

  5. 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, wählen Sie diese Option aus. Informationen dazu, wie Distributed Cloud Connected Arbeitslastdaten verschlüsselt, finden Sie unter Sicherheit des lokalen Speichers.

  6. 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.

  7. Rufen Sie Anmeldedaten für einen Cluster ab, um den Cluster zu testen.

  8. 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.

  9. Weisen Sie Nutzern mithilfe von RoleBinding und ClusterRoleBinding detaillierten rollenbasierten Zugriff auf die Clusterressourcen zu.

  10. Optional: Unterstützung für die VM-Laufzeit in Google Distributed Cloud aktivieren, um Arbeitslasten auf virtuellen Maschinen in Distributed Cloud Connected auszuführen.

  11. 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:

  1. 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

  2. Wenden Sie die YAML-Datei mit dem folgenden Befehl auf den Cluster an:

    kubectl apply -f nginx-deployment.yaml

  3. 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

  4. Wenden Sie die YAML-Datei mit dem folgenden Befehl auf den Cluster an:

    kubectl apply -f nginx-deployment.yaml

  5. Rufen Sie die externe IP-Adresse ab, die dem Dienst vom MetalLB-Load-Balancer zugewiesen wurde. Verwenden Sie dazu den folgenden Befehl:

    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 wie folgt.

  1. 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 Kurznamen ab. Der Kurzname des Knotens pool-example-node-1-01-b2d82cc7 ist beispielsweise node101.

  2. 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.

  3. 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 in ready, sobald sie neu gestartet wurden.

Pod für das Zwischenspeichern von Bildern 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 beginnt mit der Verwendung des im Cache gespeicherten Images, 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 Image-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 Kopie im Cache lokal 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 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

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

Einschränkungen des Sicherheitskontexts

Distributed Cloud Connected unterstützt den Sicherheitskontext im 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 keine von Nutzern erstellten Pods auf Steuerungsebenenknoten ausgeführt werden. 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-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 der Bearbeitung von configMap-Ressourcen zum Festlegen von Load-Balancing-IP-Adressbereichen
  • nf-operator
  • oclcm-system
  • prediction
  • rm-system
  • robinio
  • saas-system
  • vm-system

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

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

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

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

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

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 auf Clusterebene angegebene Standardlaufzeitklasse überschrieben. 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

Wenn Sie die Laufzeitklasse gvisor 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 Isolation zwischen der Arbeitslast und dem Host bietet.

Nächste Schritte