CIDR für neue zonale Organisationen vorkonfigurieren

In einer GDC-Umgebung (Google Distributed Cloud) ohne Internetverbindung können Sie Organisationen der Version 1 oder 2 erstellen, die sich über mehrere Zonen erstrecken. Es gibt jedoch zwei Szenarien für die Organisationserstellung, die zusätzliche CIDR-Konfigurationen erfordern, bevor die Organisation erstellt werden kann:

In den folgenden Abschnitten werden diese Szenarien und die Voraussetzungen beschrieben, die Sie erfüllen müssen, bevor Sie die Organisation erstellen.

CIDR-Einstellungen für die v1-Organisation in der neuen Zone konfigurieren

Sie können eine v1-Organisation nicht standardmäßig in einer neuen Zone bereitstellen, da viele CIDR-Ansprüche, die für die v1-Organisation erforderlich sind, bereits der Stammorganisation zugewiesen sind.

Sie müssen auch die vorhandene Funktion für benutzerdefinierte IP-Adressen für die v1-Organisation verwenden.

CIDR-Einstellungen für Pläne

Erfassen Sie die vorhandenen CIDR-Einstellungen, die in Ihrer Zone konfiguriert sind, um CIDR-Überschneidungen in Ihrer neuen V1-Organisation zu vermeiden.

  1. So drucken Sie die vorhandene zone-infra-cidr-Ressource CIDRClaim:

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

  2. Prüfen Sie in der Ausgabe die Felder status.ipv4AllocationStatus.cidrBlocks und status.ipv6AllocationStatus.cidrBlocks für die Ressource CIDRClaim.

    Die folgende CIDRClaim-Ressource hat beispielsweise die CIDR-Blöcke 192.0.2.0/21, 198.51.100.0/26, 203.0.113.0/23 und 2001:db8::/66 reserviert:

    apiVersion: system.private.gdc.goog/v1alpha1
kind: CIDRClaim
metadata:
  name: zone-infra-cidr
  namespace: gpc-system
spec:
  ipv4Spec:
    staticCidrBlocks:
    - 192.0.2.0/21
    - 198.51.100.0/26
    - 203.0.113.0/23
  ipv6Spec:
    staticCidrBlocks:
    - 2001:db8::/66
status:
  ipv4AllocationStatus:
    cidrBlocks:
    - 192.0.2.0/21
    - 198.51.100.0/26
    - 203.0.113.0/23
  ipv6AllocationStatus:
    cidrBlocks:
    - 2001:db8::/66

    Notieren Sie sich diese CIDR-Blöcke, damit Sie sie beim Erstellen des benutzerdefinierten externen CIDR und des benutzerdefinierten internen CIDR für Ihre Organisation nicht verwenden.

  3. Prüfen Sie die zone-infra-cidr jeder Zone und notieren Sie sich, dass die vorhandenen CIDR-Blöcke nicht verwendet werden. So können Sie sie beim Erstellen des benutzerdefinierten CIDR für Ihre Organisation vermeiden. Verwenden Sie die gcloud CLI, um zwischen zonalen Kontexten zu wechseln.

  4. Alle vorhandenen Subnetze mit dem Label network-root-range ausgeben:

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

  5. Prüfen Sie die Felder status.ipv4Allocation.cidr und status.ipv6Allocation.cidr für jede Subnet-Ressource.

    Im folgenden Beispiel hat infra-vpc-root-cidr den CIDR-Bereich 192.0.2.0/15 reserviert:

    apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/usage: network-root-range
    ipam.gdc.goog/vpc: infra-vpc
  name: infra-vpc-root-cidr
  namespace: org-1
spec:
  ipv4Request:
    cidr: 192.0.2.0/15
  propagationStrategy: None
  type: Root
status:
    ipv4Allocation:
    cidr: 192.0.2.0/15

    Notieren Sie sich diese CIDRs, damit Sie sie beim Erstellen des benutzerdefinierten externen CIDR und des benutzerdefinierten internen CIDR für Ihre Organisation nicht verwenden.

Benutzerdefinierte IP-Adresse konfigurieren

Im Rahmen des v1-Organisations-Bootstrapping-Prozesses sind benutzerdefinierte externe und benutzerdefinierte interne CIDRs als Eingabe für die globale benutzerdefinierte Ressource OrganizationZonalConfig erforderlich, um das globale v1-Organisations-Bootstrapping zu unterstützen.

Fügen Sie der OrganizationZonalConfig-Ressourcenspezifikation die benutzerdefinierten IP-Adresskonfigurationen für den externen und den internen CIDR hinzu. Die benutzerdefinierten externen und internen CIDRs werden für die zonale Organisation in den CIDR-Ansprüchen org-namespace/org-custom-external-cidr bzw. org-namespace/org-custom-internal-cidr instanziiert. Alle anderen CIDR- und Subnetzansprüche dieser Organisation sind untergeordnete Elemente dieser beiden CIDR-Ansprüche:

...

spec:
  capacities:
    customIPConfig:
      externalCIDRs:
      - CUSTOM_EXTERNAL_CIDR
      internalCIDRs:
      - CUSTOM_INTERNAL_CIDR

...

Für sowohl den benutzerdefinierten externen CIDR als auch den benutzerdefinierten internen CIDR muss Folgendes zutreffen:

  • Eindeutig in der OrganizationZonalConfig-Ressource für jede Zone.
  • Eindeutig in der OrganizationZonalConfig-Ressource für jede vorhandene v1-Organisation in allen Zonen.
  • Darf sich nicht mit dem zone-infra-cidr für die einzelnen Zonen überschneiden.
  • Darf sich nicht mit globalen Subnetzen mit dem Label ipam.gdc.goog/usage=network-root-range überschneiden.

Wenn diese Anforderungen erfüllt sind, können Sie mit den Bootstrap-Schritten für die Standardorganisation fortfahren, um die v1-Organisation in der neuen Zone zu booten.

CIDR-Einstellungen für die Version 2 der Organisation in der vorhandenen Zone konfigurieren

Wenn Sie eine v2-Organisation in einer vorhandenen Zone bereitstellen möchten, müssen Sie die CIDRClaim-Ressource gpc-system/zone-infra-cidr manuell erstellen. Außerdem darf sich der CIDR-Block im neuen CIDR-Anspruch nicht mit Folgendem überschneiden:

  • Die gpc-system/instance--CIDR-Ansprüche in der Zone.

  • Alle gpc-system/zone-infra-cidr- oder gpc-system/instance--CIDR-Ansprüche in anderen Zonen des Universums.

CIDR-Einstellungen für Pläne

  1. Vorhandene CIDRClaim-Ressourcen ausgeben:

    kubectl --kubeconfig=ROOT_ADMIN_KUBECONFIG get cidrclaim -n gpc-system

  2. Prüfen Sie die Felder status.ipv4AllocationStatus.cidrBlocks und status.ipv6AllocationStatus.cidrBlocks für jede CIDRClaim-Ressource in der Ausgabe.

    Die folgende CIDRClaim-Ressource hat beispielsweise die CIDR-Blöcke 192.0.2.0/21, 198.51.100.0/26, 203.0.113.0/23 und 2001:db8::/66 reserviert:

    apiVersion: system.private.gdc.goog/v1alpha1
kind: CIDRClaim
metadata:
  name: instance-external-cidr
  namespace: gpc-system
spec:
  ipv4Spec:
    staticCidrBlocks:
    - 192.0.2.0/21
    - 198.51.100.0/26
    - 203.0.113.0/23
  ipv6Spec:
    staticCidrBlocks:
    - 2001:db8::/66
status:
  ipv4AllocationStatus:
    cidrBlocks:
    - 192.0.2.0/21
    - 198.51.100.0/26
    - 203.0.113.0/23
  ipv6AllocationStatus:
    cidrBlocks:
    - 2001:db8::/66

    Notieren Sie sich diese CIDR-Blöcke, damit Sie sie beim Erstellen des zone-infra-cidr für Ihre V2-Organisation nicht verwenden.

zone-infra-cidr-CIDR-Anspruch erstellen

  1. Suchen Sie in jeder Zone Ihres Universums nach den folgenden CIDR-Ansprüchen mit dem Namespace gpc-system und notieren Sie sie:

    • instance-external-cidr
    • instance-internal-pod-network-cidr
    • instance-internal-cluster-ip-cidr
    • instance-internal-physical-network-cidr
    • instance-internal-cidr
    • zone-infra-cidr

    Mit dem folgenden Befehl werden beispielsweise die instance-external-cidr-CIDR-Ansprüche für die aktuelle Zone zurückgegeben:

    kubectl --kubeconfig=ROOT_ADMIN_KUBECONFIG get cidrclaim -n gpc-system instance-external-cidr

    Verwenden Sie die gcloud CLI, um zwischen zonalen Kontexten zu wechseln.

  2. Erstellen Sie eine CIDRClaim-Ressource mit dem Namen zone-infra-cidr, die sich nicht mit den zuvor geprüften CIDR-Ansprüchen überschneidet:

    kubectl --kubeconfig=ROOT_ADMIN_KUBECONFIG apply -f - <<EOF
apiVersion: system.private.gdc.goog/v1alpha1
kind: CIDRClaim
metadata:
  name: zone-infra-cidr
  namespace: gpc-system
spec:
  ipv4Spec:
    staticCidrBlocks:
    - IPV4_CIDR
  ipv6Spec:
    staticCidrBlocks:
    - IPV6_CIDR
EOF

    Die IPv4- und IPv6-CIDRs müssen eindeutig sein und dürfen sich nicht mit vorhandenen instance--CIDR-Ansprüchen im gpc-system-Namespace in der aktuellen Zone oder in anderen vorhandenen Zonen überschneiden.

  3. Prüfen Sie den Status von zone-infra-cidr, um sicherzugehen, dass er bereit ist:

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

    Nachdem der CIDR-Anspruch Ready ist, können Sie mit den Standard-Bootstrap-Schritten für die Organisation fortfahren, um die V2-Organisation in der neuen Zone zu booten.