新しいゾーン組織の CIDR を事前構成する

Google Distributed Cloud（GDC）のエアギャップ環境では、複数のゾーンにまたがる v1 または v2 の組織を作成できます。ただし、組織を作成する前に追加の CIDR 構成が必要になる組織の作成シナリオが 2 つあります。

• 新しいゾーンに v1 組織を作成します。
• 以前に v1 組織があったゾーンに v2 組織を作成する。

以降のセクションでは、これらのシナリオと、組織を作成する前に完了しておく必要のある前提条件について説明します。

新しいゾーンで v1 組織の CIDR 設定を構成する

多くの CIDR 請求がルート組織にすでに割り当てられているため、デフォルトでは新しいゾーンに v1 組織をプロビジョニングできません。

また、v1 組織には既存のカスタム IP アドレス機能を使用する必要があります。

プランの CIDR 設定

ゾーンで構成されている既存の CIDR 設定を収集して、新しい v1 組織で CIDR の重複を回避できるようにします。

1. 既存の zone-infra-cidr CIDRClaim リソースを出力します。

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

2. 出力から CIDRClaim リソースの status.ipv4AllocationStatus.cidrBlocks フィールドと status.ipv6AllocationStatus.cidrBlocks フィールドを確認します。

   たとえば、次の CIDRClaim リソースは、192.0.2.0/21、198.51.100.0/26、203.0.113.0/23、2001:db8::/66 の CIDR ブロックを予約しています。

   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
   

   これらの CIDR ブロックをメモしておくと、組織のカスタム外部 CIDR とカスタム内部 CIDR を作成するときに、これらの CIDR ブロックの使用を回避できます。

3. 各ゾーンの zone-infra-cidr を確認し、既存の CIDR ブロックが使用されていないことを確認します。これにより、組織のカスタム CIDR を作成するときに、既存の CIDR ブロックの使用を回避できます。ゾーン コンテキストを切り替えるには、gdcloud CLI を使用します。

4. network-root-range ラベルが付いている既存のサブネットをすべて出力します。

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

5. 各 Subnet リソースの status.ipv4Allocation.cidr フィールドと status.ipv6Allocation.cidr フィールドを確認します。

   たとえば、次の infra-vpc-root-cidr は 192.0.2.0/15 CIDR を予約しています。

   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
   

   これらの CIDR をメモしておくと、組織のカスタム外部 CIDR とカスタム内部 CIDR を作成するときに、これらの CIDR の使用を回避できます。

カスタム IP アドレスを構成する

v1 組織のブートストラップ プロセスの一環として、グローバル v1 組織のブートストラップをサポートするために、カスタム外部 CIDR とカスタム内部 CIDR をグローバル OrganizationZonalConfig カスタム リソースへの入力として指定する必要があります。

OrganizationZonalConfig リソース仕様で、外部 CIDR と内部 CIDR のカスタム IP アドレス構成を追加する必要があります。カスタム外部 CIDR とカスタム内部 CIDR は、ゾーン組織の org-namespace/org-custom-external-cidr CIDR クレームと org-namespace/org-custom-internal-cidr CIDR クレームにそれぞれインスタンス化されます。この組織の他のすべての CIDR クレームとサブネット クレームは、次の 2 つの CIDR クレームの子です。

...

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

...

カスタム外部 CIDR とカスタム内部 CIDR の両方で、次の条件を満たしている必要があります。

• 各ゾーンの OrganizationZonalConfig リソース内で一意。
• すべてのゾーンの既存の v1 組織ごとに OrganizationZonalConfig リソース内で一意。
• 各ゾーンの zone-infra-cidr と重複することはできません。
• ipam.gdc.goog/usage=network-root-range ラベルが付いたグローバル サブネットと重複することはできません。

これらの要件を満たしたら、デフォルトの組織のブートストラップ手順を続行して、新しいゾーンで v1 組織をブートストラップできます。

既存のゾーンで v2 組織の CIDR 設定を構成する

既存のゾーンに v2 組織をプロビジョニングするには、CIDRClaim リソース gpc-system/zone-infra-cidr を手動で作成する必要があります。また、新しい CIDR 請求内の CIDR ブロックが次のものと重複しないようにする必要があります。

• ゾーン内の gpc-system/instance- CIDR クレーム。

• ユニバースの他のゾーンにある gpc-system/zone-infra-cidr または gpc-system/instance- CIDR 請求。

プランの CIDR 設定

1. 既存の CIDRClaim リソースを出力します。

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

2. 出力から、各 CIDRClaim リソースの status.ipv4AllocationStatus.cidrBlocks フィールドと status.ipv6AllocationStatus.cidrBlocks フィールドを確認します。

   たとえば、次の CIDRClaim リソースは、192.0.2.0/21、198.51.100.0/26、203.0.113.0/23、2001:db8::/66 の CIDR ブロックを予約しています。

   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
   

   これらの CIDR ブロックをメモして、v2 組織の zone-infra-cidr を作成するときにこれらのブロックを使用しないようにします。

zone-infra-cidr CIDR 請求を作成する

1. ユニバースの各ゾーンで、Namespace gpc-system を使用して次の CIDR クレームを見つけてメモします。

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

   たとえば、次のコマンドは、現在のゾーンの instance-external-cidr CIDR クレームを返します。

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

   ゾーン コンテキストを切り替えるには、gdcloud CLI を使用します。

2. 以前に確認した CIDR クレームと重複しない zone-infra-cidr という名前の CIDRClaim リソースを作成します。

   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
   

   IPv4 と IPv6 の CIDR は一意である必要があり、現在のゾーンまたは他の既存のゾーンの gpc-system 名前空間にある既存の instance- CIDR クレームと重複することはできません。

3. zone-infra-cidr のステータスをチェックして、準備ができていることを確認します。

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

   CIDR クレームが Ready になったら、デフォルトの組織ブートストラップ手順を続行して、新しいゾーンで v2 組織をブートストラップできます。