Versionsinformationen finden Sie in den Versionshinweisen zu Distributed Cloud Connected.

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:

Optional: Distributed Cloud Edge Network API aktivieren
Optional: Netzwerkkonfiguration Ihrer mit Distributed Cloud verbundenen Zone initialisieren
Optional: Distributed Cloud-Netzwerk konfigurieren.
Distributed Cloud Connected-Cluster erstellen
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.
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.
Weisen Sie Nutzern mithilfe von RoleBinding und ClusterRoleBinding detaillierten rollenbasierten Zugriff auf die Clusterressourcen zu.
Optional: Unterstützung für die VM-Laufzeit in Google Distributed Cloud aktivieren, 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.
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.
Optional: Konfigurieren Sie den privaten Google-Zugriff, damit Ihre Pods über Cloud VPN aufGoogle Cloud APIs und Dienste zugreifen können.
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:

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

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

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.

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

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

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

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

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

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.

Ü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:

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.

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

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

Wenden Sie die Pod-Spezifikationsdatei mit dem folgenden Befehl auf den Cluster an:
```
kubectl apply -f sriovpod.yaml
```
Prüfen Sie mit dem folgenden Befehl, ob der Pod erfolgreich gestartet wurde:
```
kubectl get pods
```
Stellen Sie mit dem folgenden Befehl eine Befehlszeilenshell für den Pod her:
```
kubectl exec -it sriovpod -- sh
```

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.

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

Nächste Schritte

Best Practices für die Sicherheit anwenden

Arbeitslasten bereitstellen Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.