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.

  12. Optional: Verbinden Sie den Distributed Cloud Connected-Cluster mitGoogle Cloud:

    1. VPN-Verbindung zu Ihrem Google Cloud -Projekt erstellen

    2. Prüfen Sie, ob die VPN-Verbindung funktioniert.

  13. Optional: Konfigurieren Sie den privaten Google-Zugriff, damit Ihre Pods über Cloud VPN aufGoogle Cloud APIs und Dienste zugreifen können.

  14. Optional: Private Service Connect konfigurieren, damit Ihre Pods über Cloud VPN aufGoogle Cloud APIs und -Dienste zugreifen können.

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

Container mit SR-IOV-Funktionen bereitstellen

Das folgende Beispiel veranschaulicht, wie Sie einen Pod bereitstellen, der die SR-IOV-Funktionen des Network Function Operator von Distributed Cloud Connected verwendet.

Distributed Cloud-Netzwerkkomponenten erstellen

Erstellen Sie die erforderlichen Netzwerkkomponenten für Ihre mit Distributed Cloud verbundene Bereitstellung wie folgt. Weitere Informationen zu diesen Komponenten finden Sie unter Netzwerkfunktionen von Distributed Cloud Connected.

  1. Netzwerk erstellen:

    gcloud edge-cloud networking networks create NETWORK_NAME \
    --location=REGION \
    --zone=ZONE_NAME \
    --mtu=MTU_SIZE

    Ersetzen Sie Folgendes:

    • NETWORK_NAME: Ein aussagekräftiger Name, der dieses Netzwerk eindeutig identifiziert.
    • REGION: die Google Cloud Region, zu der die Zielzone für Distributed Cloud gehört.
    • ZONE_NAME: Der Name der Zielzone, die mit Distributed Cloud verbunden ist.
    • MTU_SIZE: Die Größe der maximalen Übertragungseinheit (Maximum Transmission Unit, MTU) für dieses Netzwerk. Gültige Werte sind 1.500 und 9.000. Dieser Wert muss mit der MTU-Größe des default-Netzwerks übereinstimmen und für alle Netzwerke gleich sein.

  2. So erstellen Sie ein Subnetzwerk:

    gcloud edge-cloud networking subnets create SUBNETWORK_NAME \
    --network=NETWORK_NAME \
    --ipv4-range=IPV4_RANGE \
    --vlan-id=VLAN_ID \
    --location=REGION \
    --zone=ZONE_NAME

    Ersetzen Sie Folgendes:

    • SUBNETWORK_NAME: Ein aussagekräftiger Name, der dieses Subnetzwerk eindeutig identifiziert.
    • NETWORK_NAME: Das Netzwerk, das dieses Subnetzwerk kapselt.
    • IPV4_RANGE: der IPv4-Adressbereich, der von diesem Subnetz abgedeckt wird, im Format IP-Adresse/Präfix.
    • VLAN_ID: die Ziel-VLAN-ID für dieses Subnetzwerk.
    • REGION: Die Google Cloud Region, zu der die Zielzone für Distributed Cloud Connected gehört.
    • ZONE_NAME: Der Name der Zielzone, die mit Distributed Cloud verbunden ist.

  3. Behalten Sie den Status des Subnetzwerks im Blick, bis es erfolgreich erstellt wurde:

    watch -n 30 'gcloud edge-cloud networking subnets list \
    --location=REGION \
    --zone=ZONE_NAME

    Ersetzen Sie Folgendes:

    • REGION: Die Google Cloud Region, zu der die Zielzone für Distributed Cloud Connected gehört.
    • ZONE_NAME: Der Name der Zielzone, die mit Distributed Cloud verbunden ist.

    Der Status ändert sich von PENDING zu PROVISIONING und schließlich zu RUNNING.

    Notieren Sie die VLAN-ID, den CIDR-Block des Subnetzes und die Gateway-IP-Adresse für den CIDR-Block. Sie benötigen diese Werte später in diesem Verfahren.

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.

ToR-Switches für SR-IOV-Netzwerkfunktionen konfigurieren

Führen Sie die Schritte in diesem Abschnitt aus, um die Netzwerkschnittstellen in jedem ToR-Switch von Distributed Cloud im verbundenen Rack von Distributed Cloud für den Betrieb von SR-IOV-Netzwerkfunktionen zu konfigurieren.

  1. Erstellen Sie eine Datei mit dem Namen mlnc6-pcie1-tor1-sriov.yaml und folgendem Inhalt. Diese Datei konfiguriert die erste Netzwerkschnittstelle auf dem ersten ToR-Switch.

      apiVersion: sriovnetwork.k8s.cni.cncf.io/v1
  kind: SriovNetworkNodePolicy
  metadata:
  name: mlnx6-pcie1-tor1-sriov
  namespace: sriov-network-operator
  spec:
  deviceType: netdevice
  isRdma: false
  linkType: eth
  mtu: 9000
  nicSelector:
     pfNames:
     - enp59s0f0np0
  nodeSelector:
     edgecontainer.googleapis.com/network-sriov.capable: "true"
  numVfs: 31
  priority: 99
  resourceName: mlnx6_pcie1_tor1_sriov

  2. Erstellen Sie eine Datei mit dem Namen mlnc6-pcie1-tor2-sriov.yaml und folgendem Inhalt. Diese Datei konfiguriert die zweite Netzwerkschnittstelle auf dem ersten ToR-Switch.

      apiVersion: sriovnetwork.k8s.cni.cncf.io/v1
  kind: SriovNetworkNodePolicy
  metadata:
  name: mlnx6-pcie1-tor2-sriov
  namespace: sriov-network-operator
  spec:
  deviceType: netdevice
  isRdma: false
  linkType: eth
  mtu: 9000
  nicSelector:
     pfNames:
     - enp59s0f1np1
  nodeSelector:
     edgecontainer.googleapis.com/network-sriov.capable: "true"
  numVfs: 31
  priority: 99
  resourceName: mlnx6_pcie1_tor2_sriov

  3. Erstellen Sie eine Datei mit dem Namen mlnc6-pcie2-tor1-sriov.yaml und folgendem Inhalt. Diese Datei konfiguriert die erste Netzwerkschnittstelle auf dem zweiten ToR-Switch.

      apiVersion: sriovnetwork.k8s.cni.cncf.io/v1
  kind: SriovNetworkNodePolicy
  metadata:
  name: mlnx6-pcie2-tor1-sriov
  namespace: sriov-network-operator
  spec:
  deviceType: netdevice
  isRdma: false
  linkType: eth
  mtu: 9000
  nicSelector:
     pfNames:
     - enp216s0f0np0
  nodeSelector:
     edgecontainer.googleapis.com/network-sriov.capable: "true"
  numVfs: 31
  priority: 99
  resourceName: mlnx6_pcie2_tor1_sriov

  4. Erstellen Sie eine Datei mit dem Namen mlnc6-pcie2-tor2-sriov.yaml und folgendem Inhalt. Diese Datei konfiguriert die zweite Netzwerkschnittstelle auf dem zweiten ToR-Switch.

      apiVersion: sriovnetwork.k8s.cni.cncf.io/v1
  kind: SriovNetworkNodePolicy
  metadata:
  name: mlnx6-pcie2-tor2-sriov
  namespace: sriov-network-operator
  spec:
  deviceType: netdevice
  isRdma: false
  linkType: eth
  mtu: 9000
  nicSelector:
     pfNames:
     - enp216s0f1np1
  nodeSelector:
     edgecontainer.googleapis.com/network-sriov.capable: "true"
  numVfs: 31
  priority: 99
  resourceName: mlnx6_pcie2_tor2_sriov

  5. Wenden Sie die ToR-Konfigurationsdateien mit den folgenden Befehlen auf den Cluster an:

    kubectl apply -f mlnc6-pcie1-tor1-sriov.yaml
kubectl apply -f mlnc6-pcie1-tor2-sriov.yaml
kubectl apply -f mlnc6-pcie2-tor1-sriov.yaml
kubectl apply -f mlnc6-pcie2-tor2-sriov.yaml

    Die betroffenen Knoten werden gesperrt, entleert und neu gestartet.

  6. Überwachen Sie den Status der Knoten mit dem folgenden Befehl:

    watch -n 5 'kubectl get sriovnetworknodestates -o yaml -A | \ 
grep "syncStatus\|pool-"|sed "N;s/\n/ /"'

    Wenn auf allen betroffenen Knoten syncStatus: Succeeded angezeigt wird, drücken Sie Strg+C, um die Überwachungsschleife zu beenden.

    Der Befehl gibt eine Ausgabe ähnlich der folgenden zurück, die angibt, dass die SR-IOV-Netzwerkfunktionen auf den ToR-Switches aktiviert wurden:

    Allocated resources:
(Total limits may be over 100 percent, i.e., overcommitted.)
Resource                       Requests     Limits
--------                       --------     ------
cpu                            2520m (3%)   7310m (9%)
memory                         3044Mi (1%)  9774Mi (3%)
ephemeral-storage              0 (0%)       0 (0%)
hugepages-1Gi                  0 (0%)       0 (0%)
hugepages-2Mi                  0 (0%)       0 (0%)
devices.kubevirt.io/kvm        0            0
devices.kubevirt.io/tun        0            0
devices.kubevirt.io/vhost-net  0            0
gke.io/mlnx6_pcie1_tor1_sriov  3            3
gke.io/mlnx6_pcie1_tor2_sriov  0            0
gke.io/mlnx6_pcie2_tor1_sriov  0            0
gke.io/mlnx6_pcie2_tor2_sriov  0            0

NetworkAttachmentDefinition-Ressource konfigurieren

Konfigurieren Sie eine NetworkAttachmentDefinition-Ressource für den Cluster so:

  1. Erstellen Sie eine Datei mit dem Namen network-attachment-definition.yaml und mit folgendem Inhalt:

    apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
name: sriov-net1
annotations:
  k8s.v1.cni.cncf.io/resourceName: gke.io/mlnx6_pcie1_tor1_sriov
spec:
config: '{
"type": "sriov",
"cniVersion": "0.3.1",
"vlan": VLAN_ID,
"name": "sriov-network",
"ipam": {
  "type": "host-local",
  "subnet": "SUBNETWORK_CIDR",
  "routes": [{
     "dst": "0.0.0.0/0"
  }],
  "gateway": "GATEWAY_ADDRESS"
}
}'

Ersetzen Sie Folgendes:

  • VLAN_ID: die VLAN-ID des Subnetzwerks, das Sie zuvor in dieser Anleitung erstellt haben.
  • SUBNETWORK_CIDR: Der CIDR-Block für das Subnetzwerk.
  • GATEWAY_ADDRESS: die Gateway-IP-Adresse für das Subnetzwerk.

  1. Wenden Sie die Ressource mit dem folgenden Befehl auf den Cluster an:

    kubectl apply -f network-attachment-definition.yaml

Pod mit SR-IOV-Netzwerkfunktionen bereitstellen

Führen Sie die Schritte in diesem Abschnitt aus, um einen Pod mit SR-IOV-Netzwerkfunktionen im Cluster bereitzustellen. Das Feld annotations in der Konfigurationsdatei des Pods gibt den Namen der NetworkAttachmentDefinition-Ressource an, die Sie zuvor in dieser Anleitung erstellt haben, sowie den Namespace, in dem sie bereitgestellt wurde (default in diesem Beispiel).

  1. Erstellen Sie eine Pod-Spezifikationsdatei mit dem Namen sriovpod.yaml und folgendem Inhalt:

         apiVersion: v1
     kind: Pod
     metadata:
     name: sriovpod
     annotations:
        k8s.v1.cni.cncf.io/networks: default/sriov-net1
     spec:
     containers:
     - name: sleeppodsriov
        command: ["sh", "-c", "trap : TERM INT; sleep infinity & wait"]
        image: busybox
        securityContext:
           capabilities:
           add:
              - NET_ADMIN

  2. Wenden Sie die Pod-Spezifikationsdatei mit dem folgenden Befehl auf den Cluster an:

    kubectl apply -f sriovpod.yaml

  3. Prüfen Sie mit dem folgenden Befehl, ob der Pod erfolgreich gestartet wurde:

    kubectl get pods

  4. Stellen Sie mit dem folgenden Befehl eine Befehlszeilenshell für den Pod her:

    kubectl exec -it sriovpod -- sh

  5. Prüfen Sie mit dem folgenden Befehl in der Pod-Shell, ob der Pod über die SR-IOV-Netzwerkfunktionsoperatorfunktion mit den ToR-Switches kommuniziert:

    ip addr

    Die Ausgabe des Befehls sieht in etwa so aus:

    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
   inet 127.0.0.1/8 scope host lo
      valid_lft forever preferred_lft forever
   inet6 ::1/128 scope host 
      valid_lft forever preferred_lft forever
51: net1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 9000 qdisc mq qlen 1000
   link/ether 2a:af:96:a5:42:ab brd ff:ff:ff:ff:ff:ff
   inet 192.168.100.11/25 brd 192.168.100.127 scope global net1
      valid_lft forever preferred_lft forever
228: eth0@if229: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue qlen 1000
   link/ether 46:c9:1d:4c:bf:32 brd ff:ff:ff:ff:ff:ff
   inet 10.10.3.159/32 scope global eth0
      valid_lft forever preferred_lft forever
   inet6 fe80::44c9:1dff:fe4c:bf32/64 scope link 
      valid_lft forever preferred_lft forever

    Die für die net1-Schnittstelle zurückgegebenen Informationen geben an, dass eine Netzwerkverbindung zwischen den ToR-Switches und dem Pod hergestellt wurde.

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
  • sriov-fec-system
  • sriov-network-operator
  • 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