Diese Seite wurde von der Cloud Translation API übersetzt.

Subnetze für das Arbeitslastnetzwerk konfigurieren

Für jede Air-Gap-Zone von Google Distributed Cloud (GDC) sind globale Stamm-Subnetze mit dem IPAM-Subnetz (IP Address Management) der öffentlichen API zugewiesen. Globale Stamm-Subnetze hosten den Stamm-IP-Adressbereich (CIDR), der in jede Zone aufgeteilt wird, um alle Cluster in der Mandantenorganisation zu booten, einschließlich des Infrastrukturclusters der Organisation und der Arbeitslast-VMs. Ein kleiner Teil des IP-Adressbereichs wird auch als Anycast-IP-Adresspool für Root-Subnetze zur Verfügung gestellt.

Nachdem eine Organisation erstellt wurde, können Sie die folgenden operativen Aufgaben für die Subnetze in Ihrem GDC-Universum ausführen:

Erstellen Sie die erforderlichen Subnetze für eine neue Zone.
Zusätzliche Subnetze für eine vorhandene Zone erstellen
Zusätzliche Knoten-Subnetze für die Organisation erstellen

Globale Subnetze für den Stammbereich für die neue Zone erstellen

Jede Zone muss globale Subnetze mit Root-Bereich haben. Während der Phase Erster Organisations-Bootstrap des GDC-Universums werden die globalen Subnetze automatisch für jede Zone generiert. Wenn jedoch nach der Erstinstallation eine neue Zone hinzugefügt wird, müssen Sie die globalen Subnetze des Stammbereichs für die neue Zone manuell erstellen.

CIDR-Bereich für die Subnetze des Netzwerk-Root-Bereichs der neuen Zone definieren

Ähnlich wie bei der Installationsanleitung für Organisationen zum Definieren eines CIDR-Bereichs dürfen sich die CIDR-Bereiche nicht überschneiden. Außerdem dürfen sie sich nicht mit zone-infra-cidr und den vorhandenen globalen Stamm-Subnetzen überschneiden. Das sind Subnetze mit dem Label ipam.gdc.goog/usage: network-root-range in ihrer benutzerdefinierten Ressourcenspezifikation.

Die zone-infra-cidr ist in jeder Zone vorhanden und kann aus dem Customer Intake Questionnaire (CIQ) abgerufen werden, sofern der Kunde sie definiert hat.

Führen Sie Folgendes aus, um die zone-infra-cidr abzurufen:

kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get cidrclaim -n gpc-system zone-infra-cidr

Notieren Sie sich den CIDR-Bereich.

Sie benötigen einen Namespace mit einem Namen, der mit dem Namen übereinstimmt, den Sie Ihrer Organisation zuweisen. Prüfen Sie, ob dieser Namespace vorhanden ist:
```
kubectl --kubeconfig GLOBAL_ROOT_ADMIN_KUBECONFIG get namespace ORG_NAME
```

Rufen Sie die vorhandenen globalen Root-Subnetze ab:

Führen Sie für den globalen Administrator-Root-Cluster Folgendes aus:

kubectl –kubeconfig GLOBAL_ROOT_ADMIN_KUBECONFIG get subnet \
    -n ORG_NAME  -l ipam.gdc.goog/usage=network-root-range

Führen Sie für den globalen API-Server für Organisationsadministratoren Folgendes aus:
```
kubectl –kubeconfig GLOBAL_ORG_API_SERVER_KUBECONFIG get subnet \
    -n platform -l ipam.gdc.goog/usage=network-root-range
```
Notieren Sie sich alle CIDR-Bereiche aus der Ausgabe.

Prüfen Sie, ob sich die neuen geplanten CIDR-Bereiche mit den vorherigen CIDR-Bereichen überschneiden.

Nachdem Sie bestätigt haben, dass Ihr neuer CIDR-Bereich für die neue Zone gültig ist, prüfen Sie, ob er den folgenden Regeln entspricht:

Feld für den CIDR-Bereich.	Mindestgröße	VPC/VRF	Globaler API-Server
`zoneInfraVPCCIDR`	17	Infra-VPC	Globale Root
`zoneDefaultVPCCIDR`	18	Standard-VPC	Globale Organisation
`zoneOrgAdminExternalCIDR`	23	Administratornetzwerksegment	Globale Root
`zoneOrgDataExternalCIDR`	23	Datensegment	Globale Root

Subnetze auf dem globalen API-Server für Administratorcluster erstellen

So erstellen Sie die Subnetze auf dem globalen Root-Admin-API-Server:

Listen Sie die Zonen in Ihrem Universum auf und suchen Sie nach dem Namen der neuen Zone:
```
kubectl --kubeconfig GLOBAL_ROOT_ADMIN_KUBECONFIG get zone -A
```

Erstellen Sie das Subnetz infra-vpc für den Netzwerk-Root-Bereich der Zone für die neue Zone der Organisation:

kubectl apply -f --kubeconfig GLOBAL_ROOT_ADMIN_KUBECONFIG - <<EOF
apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/vpc: infra-vpc
    ipam.gdc.goog/usage: zone-network-root-range
  annotations:
    ipam.gdc.goog/pivot-destination: global-org
  name: infra-vpc-NEW_ZONE_NAME-root-cidr
  namespace: ORG_NAME
spec:
  ipv4Request:
    cidr: zoneInfraVPCCIDR
  zone: NEW_ZONE_NAME
  propagationStrategy: SingleZone
  type: Root
EOF

Erstellen Sie das Subnetz für das Datennetzwerksegment des Root-Bereichs des Zonennetzwerks für die neue Zone der Organisation:

kubectl apply -f --kubeconfig GLOBAL_ROOT_ADMIN_KUBECONFIG - <<EOF
apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/network-segment: data
    ipam.gdc.goog/usage: zone-network-root-range
  annotations:
    ipam.gdc.goog/pivot-destination: global-org
  name: data-external-NEW_ZONE_NAME-root-cidr
  namespace: ORG_NAME
spec:
  ipv4Request:
    cidr: zoneOrgDataExternalCIDR
  zone: NEW_ZONE_NAME
  propagationStrategy: SingleZone
  type: Root
EOF

Erstellen Sie das Subnetz des Netzwerksegments für das Administratornetzwerk des Root-Bereichs des Zonennetzwerks für die neue Zone der Organisation:

kubectl apply -f --kubeconfig GLOBAL_ROOT_ADMIN_KUBECONFIG - <<EOF
apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/network-segment: admin
    ipam.gdc.goog/usage: zone-network-root-range
  annotations:
    ipam.gdc.goog/pivot-destination: global-org
  name: admin-external-NEW_ZONE_NAME-root-cidr
  namespace: ORG_NAME
spec:
  ipv4Request:
    cidr: zoneOrgAdminExternalCIDR
  zone: NEW_ZONE_NAME
  propagationStrategy: SingleZone
  type: Root
EOF

Subnetze auf dem API-Server für globale Organisationsadministratoren erstellen

Sie müssen das standardmäßige VPC-Subnetz im globalen API-Server des Organisationsadministrators der Organisation im Namespace platform erstellen, nachdem der API-Server ausgeführt wird.

Erstellen und wenden Sie die folgende benutzerdefinierte Subnet-Ressource an:

kubectl apply -f --kubeconfig=GLOBAL_ORG_API_SERVER_KUBECONFIG - <<EOF
apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/vpc: default-vpc
    ipam.gdc.goog/usage: zone-network-root-range
  name: default-vpc-NEW_ZONE_NAME-root-cidr
  namespace: platform
spec:
  type: Root
  ipv4Request:
    cidr: zoneDefaultVPCCIDR
  zone: NEW_ZONE_NAME
  propagationStrategy: SingleZone
EOF

Subnetze vergrößern

Die öffentliche Subnet-Ressource unterstützt kein automatisches Upscaling. Wenn Sie einer vom Kunden verwalteten VPC oder einem Netzwerksegment einen weiteren CIDR-Bereich hinzufügen möchten, müssen Sie neue Subnetze erstellen und sie mit bestimmten Labels gruppieren. Aufgrund des erforderlichen Zugriffs auf den Root-Administratorcluster kann ein Kunde seine Subnetze nicht unabhängig skalieren.

Regeln für die Subnetzgruppierung

Subnetze werden anhand von Labels in verschiedene Kategorien eingeteilt:

Kategorie	Label
Standard-VPC	`ipam.gdc.goog/vpc: default-vpc`
Infra-VPC	`ipam.gdc.goog/vpc: infra-vpc`
Administratornetzwerksegment	`ipam.gdc.goog/network-segment: admin`
Datensegment	`ipam.gdc.goog/network-segment: data`

Beim ersten Bootstrap wurden im OIQ (Organization Intake Questionnaire) vier CIDR-Bereiche angegeben. Diese vier globalen Subnetze wurden während der Erstellung der Kundenorganisation auf dem globalen API-Server erstellt. Diese globalen Subnetze sind der CIDR-Bereich auf Stammebene für jede Kategorie in allen Zonen einer Organisation. Alle globalen Subnetze auf Stammebene haben das Label ipam.gdc.goog/usage: network-root-range.

Für jede Zone wird im globalen API-Server ein untergeordnetes globales Subnetz erstellt, indem es aus den Subnetzen auf Stammebene herausgeschnitten wird. In jedem untergeordneten globalen Subnetz wird der CIDR-Bereich für eine Kategorie in der jeweiligen Zone gehostet. Das Subnetz hat das Label ipam.gdc.goog/usage: zone-network-root-range. Das globale untergeordnete Subnetz für eine Zone wird automatisch in die jeweilige Zone übertragen.

Typische Anwendungsfälle für Upscaling

Für die effizienteste Zuweisung zusätzlicher Subnetze zum Hochskalieren Ihrer vorhandenen Subnetze sollten Sie die empfohlenen Anwendungsfälle für jede Subnetzkategorie berücksichtigen. Legen Sie die Kategorie fest, die Sie hochskalieren möchten, bevor Sie mit der Hochskalierung beginnen.

Standard-VPC

Subnetze in default-vpc werden hauptsächlich verwendet, um die Pod- und Dienst-CIDRs für den freigegebenen Service-Cluster, den Nutzercluster und default-vpc-default-node-subnet für die Clusterknoten-IP-Adresse und die Arbeitslast-IP-Adresse für die Organisation zuzuweisen.

Das Erstellen eines Nutzerclusters schlägt häufig fehl, wenn das Subnetz skaliert werden muss.

Das Erstellen eines Nutzerclusters kann fehlschlagen, weil das übergeordnete Subnetz für den Pod- oder Dienst-CIDR-Block des Nutzerclusters nicht gefunden werden kann. Eine Beispielnachricht für diesen Fehler sieht etwa so aus:

could not find parent for subnet platform/user-vm-1-service-cidr

Dieses Problem kann verschiedene Ursachen haben, die direkt mit der Notwendigkeit zusammenhängen, ein Subnetz zu skalieren. Führen Sie die folgenden Schritte aus, um dies zu überprüfen:

Prüfen Sie die Felder podCIDRSize und serviceCIDRSize im Abschnitt .spec.clusterNetwork der benutzerdefinierten Cluster-Ressource:

kubectl --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG get cluster \
    -n platform USER_CLUSTER_NAME -oyaml

Die Ausgabe sieht dann ungefähr so aus:

Example:
spec:
  clusterNetwork:
    podCIDRSize: 20
    serviceCIDRSize: 20

Suchen Sie die übergeordneten Subnetze des vorhandenen Subnetzes:

kubectl --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG get subnet -n platform  -l \
    ipam.gdc.goog/vpc=default-vpc,ipam.gdc.goog/usage=zone-network-root-range

Die Ausgabe sieht dann ungefähr so aus:

Example:
NAME                     PARENT   READY   IPV4 CIDR        IPV6 CIDR
default-vpc-zone0-cidr            True    198.51.100.0/18

Alle Subnetze finden, die von den übergeordneten Subnetzen zugewiesen werden:

kubectl --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG get subnet -n platform  -l \
    ipam.gdc.goog/vpc=default-vpc,ipam.gdc.goog/usage!=zone-network-root-range

Die Ausgabe sieht dann ungefähr so aus:

Example:
default-vpc-default-node-subnet       {"name":"default-vpc-zone0-cidr","namespace":"platform"}   True    198.51.100.0/23
g-org-1-shared-service-pod-cidr       {"name":"default-vpc-zone0-cidr","namespace":"platform"}   True    198.51.16.0/20
g-org-1-shared-service-service-cidr   {"name":"default-vpc-zone0-cidr","namespace":"platform"}   True    198.51.2.0/23
user-vm-1-pod-cidr                    {"name":"default-vpc-zone0-cidr","namespace":"platform"}   True    198.51.8.0/21
user-vm-1-service-cidr                {"name":"default-vpc-zone0-cidr","namespace":"platform"}   True    198.51.4.0/23
user-vm-2-pod-cidr                    {"name":"default-vpc-zone0-cidr","namespace":"platform"}   True    198.51.32.0/21
user-vm-2-service-cidr                {"name":"default-vpc-zone0-cidr","namespace":"platform"}   True    198.51.6.0/23

In diesem Beispiel wurden einem übergeordneten CIDR-Bereich von /18 vier CIDR-Bereiche von /23, ein CIDR-Bereich von /20 und zwei CIDR-Bereiche von /21 zugewiesen. Der neue Nutzercluster fordert einen CIDR-Bereich von /20 für podCIDRSize und einen CIDR-Bereich von /20 für serviceCIDRSize an, was nicht ausreicht.

In diesem Fall müssen Sie der Standard-VPC weitere Subnetze für eine Kategorie hinzufügen.

Infra-VPC

Subnetze in infra-vpc werden hauptsächlich verwendet, um die Pod- und Dienst-CIDRs einer Organisation für den Infrastruktur- und Perimeter-Cluster der Organisation sowie die Knoten-IP-Adresse für den Perimeter-Cluster zuzuweisen.

Da dies zur Einrichtung der internen GDC-Infrastruktur gehört und jede Organisation nur einen Organisationsinfrastrukturcluster und einen Perimetercluster hat, sind für infra-vpc in der Regel keine Upscale-Vorgänge erforderlich.

Administratornetzwerksegment

Subnetze im Verwaltungsnetzwerksegment werden hauptsächlich verwendet, um IP-Adressen im VRF (Virtual Routing and Forwarding) des Organisationsadministrators zuzuweisen. In der Organisation wurde ein Standard-Knotensubnetz oder das Subnetz mit Gateway-Informationen erstellt. In diesem Standardsubnetz werden die IP-Adressen für die IP-Adresse des Organisationsinfrastruktur-Clusterknotens und die IP-Adresse des Perimeter-Clusterknotens zugewiesen.

Da das Administratornetzwerksegment zur internen GDC-Infrastruktur gehört und jede Organisation nur einen Organisationsinfrastruktur-Cluster und einen Perimeter-Cluster haben kann, muss dieses Subnetz in der Regel nicht skaliert werden.

Datensegment

Subnetze im Datensegment des Netzwerks werden hauptsächlich verwendet, um IP-Adressen im VRF für Organisationsdaten zuzuweisen. In der Organisation wurde ein Standardknoten-Subnetz oder ein Subnetz mit Gateway-Informationen erstellt. In diesem Standardsubnetz werden die IP-Adressen für die Knoten-IP-Adresse des Infrastrukturclusters der Organisation und die Knoten-IP-Adresse des Perimeterclusters zugewiesen.

Da das Datensegment zum internen GDC-Infrastruktur-Setup gehört und jede Organisation nur einen Organisationsinfrastruktur-Cluster und einen Perimeter-Cluster haben kann, ist in der Regel keine Aufskalierung dieses Subnetzes erforderlich.

Einer Kategorie weitere Subnetze hinzufügen

Sie können einer Kategorie je nach Subnetztyp weitere Subnetze hinzufügen. Die folgenden Typen kommen für das Hinzufügen weiterer Subnetze infrage:

Infra-VPC
Administratornetzwerksegment
Datensegment
Standard-VPC

Bestimmen Sie den Subnetztyp, für den Sie weitere Subnetze hinzufügen möchten, und führen Sie dann die folgenden Schritte für diesen Subnetztyp aus:

Rufen Sie im globalen Root-Admin-API-Server den Root-Subnetztyp ab und prüfen Sie das CIDR-Feld maskSize aus subnet.status.ipv4Allocation.cidr:
```
kubectl --kubeconfig GLOBAL_ROOT_ADMIN_KUBECONFIG get subnet -n ORG_NAME \
    -l ipam.gdc.goog/SUBNET_TYPE,ipam.gdc.goog/usage=network-root-range
```
Ersetzen Sie Folgendes:
- GLOBAL_ROOT_ADMIN_KUBECONFIG: der Pfad zur kubeconfig-Datei des Stammadministratorclusters.
- ORG_NAME: der Name der Organisation.
- SUBNET_TYPE: der Subnetztyp, z. B. vpc=infra-vpc, network-segment=admin, network-segment=data oder vpc=default-vpc.
Notieren Sie sich diesen Wert als die gesamte CIDR, auf die später verwiesen wird.
Rufen Sie alle untergeordneten Subnetze des Stamm-Subnetzes ab und prüfen Sie das CIDR-Feld maskSize jedes Subnetzes aus subnet.status.ipv4Allocation.cidr:
```
kubectl --kubeconfig GLOBAL_ROOT_ADMIN_KUBECONFIG get subnet -n ORG_NAME \
    -l ipam.gdc.goog/SUBNET_TYPE,ipam.gdc.goog/usage!=network-root-range
```
Notieren Sie sich jeden Wert als verwendeten CIDR, auf den später verwiesen wird.
Berechnen Sie den verfügbaren CIDR des Subnetzes anhand des gesamten CIDR und des verwendeten CIDR. Wenn der verfügbare CIDR-Bereich nicht groß genug ist, um das neue Subnetz zuzuweisen, fügen Sie ein neues globales Subnetz für den Netzwerk-Root-Bereich hinzu. Fahren Sie dann mit dem nächsten Schritt fort.
Erstellen Sie das neue Subnetz auf dem globalen Root-Admin-API-Server:
```
kubectl --kubeconfig GLOBAL_ROOT_ADMIN_KUBECONFIG apply -f - <<EOF
apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/SUBNET_TYPE_LABEL
    ipam.gdc.goog/usage: zone-network-root-range
  annotations:
    ipam.gdc.goog/pivot-destination: global-org
  name: SUBNET_NAME
  namespace: ORG_NAME
spec:
  ipv4Request:
    prefixLength: CIDR_PREFIX_LENGTH
  zone: ZONE_NAME
  propagationStrategy: SingleZone
  type: Branch
  parentReference:
    name: PARENT_SUBNET_NAME
    namespace: ORG_NAME
EOF
```
Ersetzen Sie Folgendes:
- GLOBAL_ROOT_ADMIN_KUBECONFIG: der Pfad zur kubeconfig-Datei des Stammadministratorclusters.
- SUBNET_TYPE_LABEL: Der Subnetztyp, der einer der folgenden Werte sein muss: vpc: infra-vpc, network-segment: admin, network-segment: data oder vpc: default-vpc.
- SUBNET_NAME: der Name des neuen Subnetzes.
- ORG_NAME: der Name der Organisation.
- CIDR_PREFIX_LENGTH: die Präfixlänge des neuen Subnetzes, z. B. 20.
- ZONE_NAME: Der Zonenname für das Subnetz, z. B. zone1.
- PARENT_SUBNET_NAME: der Name des übergeordneten Subnetzes, z. B. infra-vpc-root-cidr, admin-external-root-cidr, data-external-root-cidr oder default-vpc-root-cidr.
Prüfen Sie, ob das Subnetz bereit ist, indem Sie prüfen, ob der Status Ready vom Typ true ist.
Prüfen Sie, ob im globalen API-Server der Organisation ein globales Subnetz erstellt wurde und ob es bereit ist:
```
kubectl --kubeconfig GLOBAL_ORG_ADMIN_KUBECONFIG get subnet -n NAMESPACE -l \
    ipam.gdc.goog/SUBNET_TYPE,ipam.gdc.goog/usage=zone-network-root-range
```
Ersetzen Sie NAMESPACE durch den Namespace für das Subnetz. Verwenden Sie infra-network für das infra-vpc-Subnetz und platform für die anderen Subnetztypen.

Prüfen Sie, ob das zonale Subnetz im Organisations-Namespace des Administratorclusters auf Stammebene erstellt wurde und bereit ist:

kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get subnet -n ORG_NAME \
    -l ipam.gdc.goog/SUBNET_TYPE,ipam.gdc.goog/usage=zone-network-root-range

Prüfen Sie, ob das zonale Subnetz auf dem Management API-Server im Namespace platform erstellt wurde und bereit ist:

kubectl --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG get subnet -n NAMESPACE \
    -l ipam.gdc.goog/SUBNET_TYPE,ipam.gdc.goog/usage=zone-network-root-range

Die Subnetz-Hochskalierung für Ihre Organisation in der von Ihnen angegebenen Zone ist abgeschlossen. Ihre Administratoren können aus dem neuen Subnetz weitere untergeordnete Subnetze erstellen.

Neues globales Subnetz für den Netzwerk-Root-Bereich hinzufügen

Globale Subnetze mit dem Label ipam.gdc.goog/usage: network-root-range enthalten den CIDR für alle Zonen dieser Kategorie. Wenn das Limit erreicht ist, müssen Sie ein neues network-root-range-Subnetz auf dem globalen API-Server erstellen. Bei Bedarf können Sie mehrere globale Stamm-Subnetze erstellen.

So erstellen Sie ein neues network-root-range-Subnetz:

Erstellen Sie eine YAML-Datei, z. B. subnet-network-root.yaml, für das globale Subnetz des neuen Netzwerk-Root-Bereichs:
```
apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/SUBNET_TYPE
    ipam.gdc.goog/usage: network-root-range
  annotations:
    ipam.gdc.goog/pivot-destination: global-org
  name: SUBNET_NAME
  namespace: ORG_NAME
spec:
  ipv4Request:
    cidr: NEW_CIDR
  type: Root
```
Ersetzen Sie Folgendes:
- SUBNET_TYPE: Der Subnetztyp, der einer der folgenden Werte sein muss: vpc: infra-vpc, network-segment: admin, network-segment: data oder vpc: default-vpc.
- API_SERVER_ANNOTATION: Die Anmerkung, mit der angegeben wird, dass dieses Subnetz zu einem anderen API-Server wechseln muss. Verwenden Sie ipam.gdc.goog/pivot-destination: global-org für infra-vpc oder die Segmente „Administrator“ und „Datanet-Arbeit“. Wenn Sie einen neuen default-vpc-Stammbereich hinzufügen, legen Sie diese Anmerkung nicht fest.
- SUBNET_NAME: der Name des neuen Subnetzes.
- ORG_NAME: der Name der Organisation.
- NEW_CIDR: der neue CIDR-Bereich für das Subnetz. Dieser CIDR darf sich nicht mit einem CIDR in allen vorhandenen Subnetzen mit dem Label ipam.gdc.goog/usage: network-root-range auf demselben globalen Root-Admin-API-Server überschneiden.