이 페이지는 Cloud Translation API를 통해 번역되었습니다.

새 영역 조직의 CIDR 사전 구성

Google Distributed Cloud (GDC) 에어갭 유니버스에서는 여러 영역에 걸쳐 있는 v1 또는 v2 조직을 만들 수 있습니다. 하지만 조직을 만들기 전에 추가 CIDR 구성이 필요한 조직 생성 시나리오가 두 가지 있습니다.

새 영역에 v1 조직 만들기
이전에 v1 조직이 있던 영역에 v2 조직을 만듭니다.

다음 섹션에서는 이러한 시나리오와 조직을 만들기 전에 완료해야 하는 기본 요건을 다룹니다.

새 영역에서 v1 조직의 CIDR 설정 구성

v1 조직에 필요한 많은 CIDR 클레임이 이미 루트 조직에 할당되어 있으므로 기본적으로 새 영역에서 v1 조직을 프로비저닝할 수 없습니다.

v1 조직의 경우 기존 맞춤 IP 주소 기능도 사용해야 합니다.

계획 CIDR 설정

새 v1 조직에서 CIDR이 중복되지 않도록 영역에 구성된 기존 CIDR 설정을 수집합니다.

기존 zone-infra-cidr CIDRClaim 리소스를 출력합니다.

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

출력에서 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 블록을 기록해 둡니다.

각 영역의 zone-infra-cidr를 확인하고 기존 CIDR 블록은 사용되지 않으므로 조직의 맞춤 CIDR을 만들 때 사용하지 않도록 합니다. 영역 컨텍스트를 전환하려면 gdcloud CLI를 사용하세요.

network-root-range 라벨이 있는 기존 서브넷을 모두 출력합니다.

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

각 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을 기록해 둡니다.

맞춤 IP 주소 구성

v1 조직 부트스트랩 프로세스의 일환으로 전역 v1 조직 부트스트랩을 지원하기 위해 맞춤 외부 및 맞춤 내부 CIDR이 전역 OrganizationZonalConfig 맞춤 리소스의 입력으로 필요합니다.

OrganizationZonalConfig 리소스 사양에서 외부 CIDR 및 내부 CIDR의 맞춤 IP 주소 구성을 추가해야 합니다. 맞춤 외부 및 맞춤 내부 CIDR은 영역 조직의 org-namespace/org-custom-external-cidr 및 org-namespace/org-custom-internal-cidr CIDR 클레임에 각각 인스턴스화됩니다. 이 조직의 다른 모든 CIDR 소유권 주장과 서브넷 소유권 주장은 다음 두 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 설정

기존 CIDRClaim 리소스를 출력합니다.

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

출력에서 각 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

v2 조직의 zone-infra-cidr를 만들 때 사용하지 않도록 이러한 CIDR 블록을 기록해 둡니다.

`zone-infra-cidr` CIDR 소유권 주장 만들기

유니버스의 각 영역에서 네임스페이스 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를 사용하세요.

이전에 확인한 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 클레임과 겹칠 수 없습니다.

zone-infra-cidr의 상태를 확인하여 준비되었는지 확인합니다.
```
kubectl --kubeconfig=ROOT_ADMIN_KUBECONFIG \
    get cidrclaim -n gpc-system zone-infra-cidr
```
CIDR 클레임이 Ready이면 기본 조직 부트스트랩 단계를 계속하여 새 영역에서 v2 조직을 부트스트랩할 수 있습니다.

새 영역 조직의 CIDR 사전 구성

새 영역에서 v1 조직의 CIDR 설정 구성

계획 CIDR 설정

맞춤 IP 주소 구성

기존 영역에서 v2 조직의 CIDR 설정 구성

계획 CIDR 설정

zone-infra-cidr CIDR 소유권 주장 만들기

`zone-infra-cidr` CIDR 소유권 주장 만들기