1. 고객 조직 만들기

예상 소요 시간: 3시간

기술 프로필: 배포 엔지니어

운영자는 조직을 만들어 고객이 플랫폼 인프라에 액세스할 수 있도록 할 수 있습니다. 조직을 만드는 데 필요한 권한을 얻으려면 보안 관리자에게 조직 관리자 역할을 부여해 달라고 요청하세요.

Organization 리소스는 Google Distributed Cloud (GDC) 오프라인 리소스 계층 구조의 루트 노드이며 조직에 속하는 모든 리소스는 조직 노드 아래에 그룹화됩니다. 이는 조직에 속하는 모든 리소스에 대한 중앙 집중식 가시성 및 제어를 제공합니다.

조직에 대한 자세한 내용은 조직 개요를 참고하세요.

1.1. 시작하기 전에

다음이 설치되어 있는지 확인합니다.

  • 시스템의 브라우저

  • Git 명령줄 인터페이스 (CLI)

  • kubectl CLI

  • gdcloud CLI

1.2. OC IT ADFS에서 OIDC 클라이언트 만들기

  1. ADFS OIDC 구성 안내를 참고하여 생성할 조직에 액세스할 수 있도록 ADFS에서 OpenID Connect (OIDC) 클라이언트를 만듭니다. OIDC 클라이언트의 클라이언트 ID와 클라이언트 보안 비밀번호를 기록합니다. 루트 관리자 클러스터, 기타 조직 관리자 클러스터 또는 ServiceNow와 같은 서비스에 연결할 때 클라이언트를 재사용해서는 안 됩니다.

  2. 만들 조직의 ADFS OIDC 클라이언트의 허용 목록에 다음 GKE Identity Service 콜백 URL을 추가합니다.

    https://ais-core.ORG_NAME.GDC_URL.GDC_DOMAIN/finish-login

    예를 들면 다음과 같습니다.

    • 조직 이름: operations
    • Distributed Cloud 인스턴스 이름: google
    • Distributed Cloud 도메인 이름: gdch.test

    이 경우 GKE Identity Service 콜백 URL은 https://ais-core.operations.google.gdch.test/finish-login입니다.

  3. GDC 유니버스의 각 영역에 대해 만든 ADFS OIDC 클라이언트의 허용 목록에 다음 GKE Identity Service 콜백 URL을 추가합니다.

    https://ais-core.ORG_NAME.ZONE.GDC_URL.GDC_DOMAIN/finish-login

    예를 들면 다음과 같습니다.

    • 조직 이름: operations
    • 영역 이름: zone-1
    • Distributed Cloud 인스턴스 이름: google
    • Distributed Cloud 도메인 이름: gdch.test

    이 경우 GKE Identity Service 콜백 URL은 https://ais-core.operations.zone-1.google.gdch.test/finish-login입니다.

  4. 다음 섹션에서 사용할 변수를 설정합니다.

    export ADFS_CERT_BASE64=ADFS_CERT_BASE64
export ADFS_CLIENT_ID=ADFS_CLIENT_ID
export ADFS_CLIENT_SECRET=ADFS_CLIENT_SECRET
export ADFS_ISSUER_URI=ADFS_ISSUER_URI

    변수를 다음 값으로 바꿉니다.

    변수정의
    ADFS_CERT_BASE64 base64로 인코딩된 adfs.pem 파일입니다.
    ADFS_CLIENT_ID ADFS 클라이언트 식별자입니다.
    ADFS_CLIENT_SECRET ADFS 클라이언트 공유 비밀번호입니다.
    ADFS_ISSUER_URI ADFS 발급기관 URI입니다. URI를 가져오려면 ADFS 서버의 /adfs/.well-known/openid-configuration 경로를 확인하세요.

    curl -s https://fs.opscenter.local/adfs/.well-known/openid-configuration | jq '.issuer' "https://fs.opscenter.local/adfs"

    일반적으로 값은 https://adfs.domain.com/adfs입니다.

1.3 전역 서브넷을 만들고 각 영역별로 분할

조직을 만들기 전에 IP 주소 관리 (IPAM) 공개 API 서브넷을 사용하여 전역 루트 서브넷을 만들고 각 영역에 맞게 분할해야 합니다. 이전에 v1 조직이 있었던 영역에 새 v2 조직을 만드는 경우 전역 서브넷을 만들기 전에 추가 기본 요건 페이지를 확인하세요.

전역 루트 서브넷은 조직 인프라 클러스터와 워크로드 VM을 비롯한 테넌트 조직 내의 모든 클러스터를 부트스트랩하기 위해 각 영역으로 분할된 루트 IP 주소 범위 (CIDR) 풀을 호스팅합니다. IP 주소 범위의 일부는 애니캐스트 IP 주소 풀로 루트 서브넷에 제공됩니다. 컨트롤러를 사용하여 각 영역에 전용 CIDR을 자동으로 할당하거나 각 영역에 CIDR을 수동으로 제공할 수 있습니다.

조직을 부트스트랩하려면 조직 입력 설문지 (OIQ)에서 내부 IP 주소 범위 입력을 받아야 합니다. 이러한 IP 주소 범위를 사용하여 전역 API 서버에서 전역 루트 서브넷을 만들어야 합니다.

각 전역 API 서버에 대해 서로 다른 루트 서브넷을 만들어야 합니다. OIQ 필드, 전역 루트 서브넷 이름, 전역 API 서버의 매핑은 다음 섹션에 제공됩니다.

1.3.1. OIQ의 CIDR 범위 정의

CIDR 범위는 서로 겹칠 수 없으며 zone-infra-cidr과도 겹칠 수 없습니다.

zone-infra-cidr는 각 영역에 있으며 고객이 정의한 경우 고객 접수 설문지 (CIQ)에서 가져올 수 있습니다.

zone-infra-cidr를 가져오려면 다음을 실행합니다.

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

다음은 YAML 출력의 예입니다.

apiVersion: system.private.gdc.goog/v1alpha1
kind: CIDRClaim
metadata:
  name: zone-infra-cidr
  namespace: gpc-system
spec:
  ipv4Spec:
    staticCidrBlocks:
    - 192.0.2.0/24
  ipv6Spec:
    staticCidrBlocks:
    - 2001:db8::/32
status:
  ipv4AllocationStatus:
    cidrBlocks:
    - 192.0.2.0/24
  ipv6AllocationStatus:
    cidrBlocks:
    - 2001:db8::/32

이 예에서 zone-infra-cidr은 192.0.2.0/24이므로 OIQ의 필드가 192.0.2.0/24과 중복되면 안 됩니다.

다음 표에는 OIQ 필드와 해당 기본 최소값이 나와 있습니다.

OIQ 필드 설명 최소 필수 크기 조직의 영역별 최소 크기 전역 루트 서브넷 이름 전역 API 서버
infraVPCCIDR 조직 콘솔, 관리 API, 서드 파티 서비스를 비롯한 시스템 워크로드 \( 15 - \lceil \log_2(ZoneNumber) \rceil \) 16 infra-vpc-root-cidr 전역 루트
defaultVPCCIDR 영역 간 기본 VPC의 사용자 워크로드 및 엔드포인트 \( 16 - \lceil \log_2(ZoneNumber) \rceil \) 16 default-vpc-root-cidr 글로벌 조직
orgAdminExternalCIDR 외부 네트워크와 조직 간의 관리 트래픽을 처리하는 경계 클러스터의 워크로드 및 엔드포인트 \( 22 - \lceil \log_2(ZoneNumber) \rceil \) 23 admin-external-root-cidr 전역 루트
orgDataExternalCIDR 외부 부하 분산기 및 이그레스 NAT와 같이 사용자가 외부에서 도달할 수 있는 워크로드 및 엔드포인트 \( 22 - \lceil \log_2(ZoneNumber) \rceil \) 23 data-external-root-cidr 전역 루트

기본 최소 권장 IP가 충분하지 않으면 수동 분할 프로세스에 따라 각 영역의 서브넷을 만들어야 합니다.

IPv4 서브넷 범위의 다음 제한사항을 고려하세요.

  • orgDataExternalCIDR, orgAdminExternalCIDR, infraVPCCIDR, defaultVPCCIDR는 서로 겹치거나 조직 내에 할당된 다른 범위와 겹치거나 피어링된 네트워크의 IPv4 범위와 겹치면 안 됩니다. 이러한 CIDR은 RFC 1918 비공개 주소 공간에서 가져옵니다.

    피어링된 네트워크: 인터커넥트 연결을 통해 외부 네트워크로 공지된 서브넷 또는 동일한 조직의 다른 VPC와 피어링된 서브넷일 수 있습니다.

  • 조직이 동일한 상호 연결 AttachmentGroup 리소스를 공유하는 경우 orgDataExternalCIDR 및 orgAdminExternalCIDR 값은 고유해야 합니다. 그렇지 않으면 다른 조직과의 중복이 허용됩니다.

1.3.2. 전역 루트 관리자 API 서버에서 전역 서브넷 만들기

조직을 만들기 전에 전역 루트 관리 API 서버에서 다음 서브넷을 만들어야 합니다.

  • infra-vpc-root-cidr
  • admin-external-root-cidr
  • data-external-root-cidr

이러한 서브넷은 각 영역에서 조직의 조직 인프라 클러스터를 부트스트랩하는 데 필요합니다.

  1. 조직에 할당할 조직 이름과 일치하는 이름의 네임스페이스가 있어야 합니다. 이 네임스페이스가 있는지 확인합니다.

    kubectl --kubeconfig GLOBAL_ROOT_ADMIN_KUBECONFIG get namespace

    이 네임스페이스가 없으면 만듭니다.

    kubectl --kubeconfig GLOBAL_ROOT_ADMIN_KUBECONFIG create namespace ORG_NAME

  2. ORG_NAME-infra-vpc-root-cidr.yaml과 같이 infra-vpc-root-cidr 서브넷 YAML 파일을 만듭니다.

    apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/vpc: infra-vpc
    ipam.gdc.goog/usage: network-root-range
  annotations:
    ipam.gdc.goog/pivot-destination: global-org
  name: infra-vpc-root-cidr
  namespace: ORG_NAME
spec:
  ipv4Request:
    cidr: INFRA_VPC_CIDR
  type: Root

  3. ORG_NAME-admin-external-root-cidr.yaml과 같이 admin-external-root-cidr 서브넷 YAML 파일을 만듭니다.

    apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/network-segment: admin
    ipam.gdc.goog/usage: network-root-range
  annotations:
    ipam.gdc.goog/pivot-destination: global-org
  name: admin-external-root-cidr
  namespace: ORG_NAME
spec:
  ipv4Request:
    cidr: ORG_ADMIN_EXTERNAL_CIDR
  type: Root

  4. ORG_NAME-data-external-root-cidr.yaml과 같이 data-external-root-cidr 서브넷 YAML 파일을 만듭니다.

    apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/network-segment: data
    ipam.gdc.goog/usage: network-root-range
  annotations:
    ipam.gdc.goog/pivot-destination: global-org
  name: data-external-root-cidr
  namespace: ORG_NAME
spec:
  ipv4Request:
    cidr: ORG_DATA_EXTERNAL_CIDR
  type: Root

  5. infra-vpc-root-cidr, admin-external-root-cidr, data-external-root-cidr 서브넷 YAML 파일을 루트 조직의 IAC 저장소에 복사합니다.

    cp YAML_FILE_PATH/ORG_NAME-infra-vpc-root-cidr.yaml \
    IAC_REPO_PATH/iac/infrastructure/global/orgs/root/
cp YAML_FILE_PATH/ORG_NAME-admin-external-root-cidr.yaml \
    IAC_REPO_PATH/iac/infrastructure/global/orgs/root/
cp YAML_FILE_PATH/ORG_NAME-data-external-root-cidr.yaml \
    IAC_REPO_PATH/iac/infrastructure/global/orgs/root/

  6. 조직의 루트에 있는 kustomization.yaml 파일에 새로 추가된 Subnet 정의가 있는지 확인합니다. IAC_REPO_PATH/iac/infrastructure/global/orgs/root/kustomization.yaml를 확인합니다.

    apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
metadata:
  name: global-root-kustomization
resources:
-   ... # existing resource items
- ORG_NAME-admin-external-root-cidr.yaml
- ORG_NAME-data-external-root-cidr.yaml
- ORG_NAME-infra-vpc-root-cidr.yaml

  7. 서브넷 YAML 파일을 스테이징하고 커밋합니다.

    git add "IAC_REPO_PATH/iac/infrastructure"
git commit

  8. 병합 요청을 만듭니다.

    git checkout -b ${USERNAME1}-branch
git -c http.sslVerify=false push -o merge_request.create origin {USERNAME1}-branch

  9. 코드 검토 및 병합을 기다립니다.

1.3.3. 영역의 루트 서브넷 분할

전역 루트 서브넷은 모든 영역의 루트 IP 주소 범위 (CIDR)를 호스팅합니다. 영역에서 IP 주소 범위를 사용하려면 먼저 전역 루트 서브넷을 영역에서 사용할 수 있도록 더 작은 서브넷으로 분할해야 합니다. 각 영역에는 루트 IP 주소 범위가 하나 이상 있어야 합니다.

IPAM에는 기존 영역에 대해 전역 루트 서브넷을 더 작은 서브넷으로 자동 분할하는 전역 컨트롤러가 있습니다. 관리자는 특정 영역에서 사용하는 정확한 CIDR 블록에 관심이 없는 경우 IPAM 컨트롤러에 위임하여 영역의 서브넷을 자동으로 나눌 수 있습니다. 컨트롤러는 전역 루트 서브넷의 생성을 모니터링하고 고정된 기본 접두사 길이로 각 영역의 서브넷을 만듭니다.

영역 루트 서브넷 기본 고정 접두사 길이
defaultZoneInfraVPCSubnetSize 16
defaultZoneAdminVRFSubnetSize 23
defaultZoneDataVRFSubnetSize 23
defaultZoneDefaultVPCSubnetSize 16
defaultAnycastSubnetSize 26

IPAM 컨트롤러가 영역의 서브넷을 자동으로 분할하려면 전역 루트 서브넷의 이름이 고정되어야 합니다.

  • infra-vpc-root-cidr
  • admin-external-root-cidr
  • data-external-root-cidr
  • default-vpc-root-cidr

Subnet 리소스에 ipam.gdc.goog/pause-auto-division: true 주석을 설정하는 경우 특정 영역에서 사용하는 정확한 CIDR 블록을 수동으로 정의해야 합니다. 이름이 다른 전역 루트 서브넷을 만들면 ipam.gdc.goog/pause-auto-division 주석이 적용되지 않으며 전역 서브넷이 자동으로 분할되지 않습니다.

1.3.3.1. 영역의 루트 서브넷 자동 분할

전역 컨트롤러는 기존 영역에 대해 전역 루트 서브넷을 더 작은 서브넷으로 자동 분할합니다. 예를 들어 컨트롤러가 기존 영역의 전역 루트 서브넷을 더 작은 서브넷으로 분할하는 방법을 이해하려면 다음 워크플로를 참고하세요.

zone1 및 zone2라는 두 개의 영역이 있는 경우 org-1 네임스페이스의 OIQ에서 infraVPCCIDR(예: 10.0.0.0/16)를 사용하는 전역 루트 서브넷 infra-vpc-root-cidr의 예는 다음과 같습니다.

apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/vpc: infra-vpc
    ipam.gdc.goog/usage: network-root-range
  annotations:
    ipam.gdc.goog/pivot-destination: global-org
  name: infra-vpc-root-cidr
  namespace: org-1
spec:
  ipv4Request:
    cidr: 10.0.0.0/14
  type: Root

GDC 플랫폼에 배포되면 컨트롤러는 접두사 길이 /16으로 infra-vpc-zone1-root-cidr 및 infra-vpc-zone2-root-cidr라는 두 개의 하위 서브넷을 자동으로 만듭니다.

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-zone1-root-cidr
  namespace: org-1
spec:
  ipv4Request:
    prefixLength: 16
  zone: zone1
  propagationStrategy: SingleZone
  type: Branch
  parentReference:
    name: infra-vpc-root-cidr
    namespace: org-1

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-zone2-root-cidr
  namespace: org-1
spec:
  ipv4Request:
    prefixLength: 16
  zone: zone2
  propagationStrategy: SingleZone
  type: Branch
  parentReference:
    name: infra-vpc-root-cidr
    namespace: org-1

1.3.3.2. 영역의 루트 서브넷 수동 분할

이 섹션에서는 전역 루트 관리자 API 서버에서 전역 루트 서브넷을 만들 때 ipam.gdc.goog/pause-auto-division: true 주석을 설정했다고 가정합니다. 이 주석은 컨트롤러가 이러한 전역 루트 서브넷을 조정하도록 일시중지하므로 영역의 루트 서브넷과 애니캐스트 서브넷을 수동으로 만들 수 있습니다.

영역에 맞게 전역 루트 서브넷을 더 작은 서브넷으로 수동으로 분할하려면 다음 단계를 완료하세요.

  1. 유니버스의 영역을 나열합니다.

    kubectl --kubeconfig GLOBAL_ROOT_ADMIN_KUBECONFIG get zone -A

  2. 영역에 적용할 루트 서브넷의 전용 CIDR을 확인합니다. 유니버스의 각 영역에 대해 이 작업을 실행합니다.

  3. ORG_NAME-infra-vpc-zone1-root-cidr.yaml과 같은 YAML 파일에서 전용 CIDR을 영역의 서브넷에 할당합니다.

    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-zone1-root-cidr
  namespace: ORG_NAME
spec:
  ipv4Request:
    cidr: ZONAL_CIDR
  zone: ZONE_NAME
  propagationStrategy: SingleZone
  type: Branch
  parentReference:
    name: infra-vpc-root-cidr
    namespace: ORG_NAME

    GDC 유니버스의 각 영역에 대해 이 단계를 반복합니다.

  4. 애니캐스트 서브넷에 적용할 루트 서브넷의 전용 CIDR을 확인합니다.

  5. ORG_NAME-infra-vpc-anycast-cidr.yaml과 같은 YAML 파일에서 전용 CIDR을 애니캐스트 서브넷에 할당합니다.

    apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/vpc: infra-vpc
  annotations:
    ipam.gdc.goog/pivot-destination: global-org
  name: infra-vpc-anycast-cidr
  namespace: ORG_NAME
spec:
  ipv4Request:
    cidr: ANYCAST_CIDR
  propagationStrategy: None
  type: Branch
  parentReference:
    name: infra-vpc-root-cidr
    namespace: ORG_NAME

  6. 영역 서브넷 YAML 파일을 루트 조직의 IAC 저장소에 복사합니다. 예를 들어 두 개의 영역 서브넷 YAML 파일이 있는 경우

    cp YAML_FILE_PATH/ORG_NAME-infra-vpc-zone1-root-cidr.yaml \
    IAC_REPO_PATH/iac/infrastructure/global/orgs/root/
cp YAML_FILE_PATH/ORG_NAME-infra-vpc-zone2-root-cidr.yaml \
    IAC_REPO_PATH/iac/infrastructure/global/orgs/root/
cp YAML_FILE_PATH/ORG_NAME-infra-vpc-anycast-cidr.yaml \
    IAC_REPO_PATH/iac/infrastructure/global/orgs/root/

  7. 조직의 루트에 있는 kustomization.yaml 파일에 새로 추가된 Subnet 정의가 있는지 확인합니다. IAC_REPO_PATH/iac/infrastructure/global/orgs/root/kustomization.yaml를 확인합니다.

    apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
metadata:
  name: global-root-kustomization
resources:
-   ... # existing resource items
- ORG_NAME-infra-vpc-zone1-root-cidr.yaml
- ORG_NAME-infra-vpc-zone2-root-cidr.yaml
- ORG_NAME-infra-vpc-anycast-cidr.yaml

  8. 서브넷 YAML 파일을 스테이징하고 커밋합니다.

    git add "IAC_REPO_PATH/iac/infrastructure"
git commit

  9. 병합 요청을 만듭니다.

    git checkout -b ${USERNAME1}-branch
git -c http.sslVerify=false push -o merge_request.create origin {USERNAME1}-branch

  10. 코드 검토 및 병합을 기다립니다.

1.3.3.2.1. 인프라 VPC의 영역에 대한 루트 서브넷을 수동으로 분할하는 예

zone1 및 zone2라는 두 개의 영역이 있는 경우 org-1 네임스페이스의 OIQ에서 infraVPCCIDR(예: 192.0.2.0/24)를 사용하는 전역 루트 서브넷 infra-vpc-root-cidr의 예는 다음과 같습니다.

apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/vpc: infra-vpc
    ipam.gdc.goog/usage: network-root-range
  annotations:
    ipam.gdc.goog/pivot-destination: global-org
    ipam.gdc.goog/pause-auto-division: "true"
  name: infra-vpc-root-cidr
  namespace: org-1
spec:
  ipv4Request:
    cidr: 192.0.2.0/24
  type: Root

infra-vpc-zone1-root-cidr 및 infra-vpc-zone2-root-cidr라는 각 영역의 서브넷과 전용 CIDR을 사용하여 애니캐스트 서브넷 infra-vpc-anycast-cidr를 수동으로 만듭니다.

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-zone1-root-cidr
  namespace: org-1
spec:
  ipv4Request:
    cidr: 192.0.2.0/26
  zone: zone1
  propagationStrategy: SingleZone
  type: Branch
  parentReference:
    name: infra-vpc-root-cidr
    namespace: org-1

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-zone2-root-cidr
  namespace: org-1
spec:
  ipv4Request:
    cidr: 192.0.2.64/26
  zone: zone2
  propagationStrategy: SingleZone
  type: Branch
  parentReference:
    name: infra-vpc-root-cidr
    namespace: org-1

apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/vpc: infra-vpc
  annotations:
    ipam.gdc.goog/pivot-destination: global-org
  name: infra-vpc-anycast-cidr
  namespace: org-1
spec:
  ipv4Request:
    cidr: 192.0.2.128/26
  propagationStrategy: None
  type: Branch
  parentReference:
    name: infra-vpc-root-cidr
    namespace: org-1

모든 서브넷 YAML 파일을 IAC 저장소에 추가해야 합니다.

1.3.3.2.2. 데이터 네트워크 세그먼트의 영역 예시를 위한 루트 서브넷 수동 분할

zone1 및 zone2라는 두 개의 영역이 있는 경우 org-1 네임스페이스의 OIQ에서 orgDataExternalCIDR(예: 10.0.0.0/24)을 사용하는 전역 루트 서브넷 data-external-root-cidr의 예는 다음과 같습니다.

apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/network-segment: data
    ipam.gdc.goog/usage: network-root-range
  annotations:
    ipam.gdc.goog/pivot-destination: global-org
    ipam.gdc.goog/pause-auto-division: "true"
  name: data-external-root-cidr
  namespace: org-1
spec:
  ipv4Request:
    cidr: 10.0.0.0/24
  type: Root

data-external-zone1-root-cidr 및 data-external-zone2-root-cidr라는 각 영역의 서브넷과 전용 CIDR을 사용하여 애니캐스트 서브넷 data-global-anycast-cidr를 수동으로 만듭니다.

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-zone1-root-cidr
  namespace: org-1
spec:
  ipv4Request:
    cidr: 10.0.0.0/26
  zone: zone1
  propagationStrategy: SingleZone
  type: Branch
  parentReference:
    name: data-external-root-cidr
    namespace: org-1

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-zone2-root-cidr
  namespace: org-1
spec:
  ipv4Request:
    cidr: 10.0.0.64/26
  zone: zone2
  propagationStrategy: SingleZone
  type: Branch
  parentReference:
    name: data-external-root-cidr
    namespace: org-1

apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/network-segment: data
  annotations:
    ipam.gdc.goog/pivot-destination: global-org
  name: data-global-anycast-cidr
  namespace: org-1
spec:
  ipv4Request:
    cidr: 10.0.0.128/26
  propagationStrategy: None
  type: Branch
  parentReference:
    name: data-external-root-cidr
    namespace: org-1

모든 서브넷 YAML 파일을 IAC 저장소에 추가해야 합니다.

1.3.3.2.3. 관리 네트워크 세그먼트의 영역에 대한 루트 서브넷을 수동으로 분할하는 예

zone1 및 zone2라는 두 개의 영역이 있는 경우 org-1 네임스페이스의 OIQ에서 orgAdminExternalCIDR(예: 192.168.1.0/24)을 사용하는 전역 루트 서브넷 admin-external-root-cidr의 예는 다음과 같습니다.

apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/network-segment: admin
    ipam.gdc.goog/usage: network-root-range
  annotations:
    ipam.gdc.goog/pivot-destination: global-org
    ipam.gdc.goog/pause-auto-division: "true"
  name: admin-external-root-cidr
  namespace: org-1
spec:
  ipv4Request:
    cidr: 192.168.1.0/24
  type: Root

admin-external-zone1-root-cidr 및 admin-external-zone2-root-cidr라는 각 영역의 서브넷과 결정한 전용 CIDR이 있는 애니캐스트 서브넷 admin-global-anycast-cidr를 수동으로 만듭니다.

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-zone1-root-cidr
  namespace: org-1
spec:
  ipv4Request:
    cidr: 192.168.1.0/26
  zone: zone1
  propagationStrategy: SingleZone
  type: Branch
  parentReference:
    name: admin-external-root-cidr
    namespace: org-1

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-zone2-root-cidr
  namespace: org-1
spec:
  ipv4Request:
    cidr: 192.168.1.64/26
  zone: zone2
  propagationStrategy: SingleZone
  type: Branch
  parentReference:
    name: admin-external-root-cidr
    namespace: org-1

apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/network-segment: data
  annotations:
    ipam.gdc.goog/pivot-destination: global-org
  name: admin-global-anycast-cidr
  namespace: org-1
spec:
  ipv4Request:
    cidr: 192.168.1.128/26
  propagationStrategy: None
  type: Branch
  parentReference:
    name: admin-external-root-cidr
    namespace: org-1

모든 서브넷 YAML 파일을 IAC 저장소에 추가해야 합니다.

1.4. IAC로 조직 만들기

IAC를 사용하여 조직을 만듭니다.

  1. 사용 가능한 서버 및 서버 유형 목록을 생성합니다.

    kubectl get servers -n gpc-system -o jsonpath='{range .items[?(@.status.bareMetalHostStatus.provisionState=="available")]}{.metadata.name}{"\t"}{.spec.serverHardware.machineClassName}{"\t"}{.status.bareMetalHostStatus.provisionState}{"\n"}{end}'

    출력 예시는 다음과 같습니다.

    ag-aa-bm04   o1-standard1-64-gdc-metal   available
ag-ab-bm07   o1-standard1-64-gdc-metal   available
ag-ab-bm11   o1-highmem1-96-gdc-metal    available
ag-ab-bm12   o1-highmem1-96-gdc-metal    available
ag-ab-bm13   o1-highmem1-96-gdc-metal    available
ag-ab-bm14   o1-highgpu1-48-gdc-metal    available
ag-ab-bm15   o1-highgpu1-48-gdc-metal    available
ag-ab-bm16   o1-highgpu1-48-gdc-metal    available

    나중에 --server-quota 및 --admin-server를 지정할 때 요청을 처리할 수 있는 available 서버가 충분해야 합니다.

  2. iac 저장소로 이동하여 새 조직의 디렉터리 구조를 추가합니다.

    mkdir -p infrastructure/global/orgs/root/ORG_NAME/

  3. Organization 커스텀 리소스를 만듭니다.

    gdcloud organizations config create --name ORG_NAME \
    --log-retention-policy LOG_RETENTION_POLICY \
    --kms-root-key-type KMS_ROOT_KEY_TYPE

    예를 들면 다음과 같습니다.

    gdcloud organizations config create --name org-1 \
    --log-retention-policy paAuditLogsRetentionTime=400,ioAuditLogsRetentionTime=2000,operationalLogsRetentionTime=90,metricsRetentionTime=90 \
    --kms-root-key-type ctm-root

    다음 변수를 바꿉니다.

    변수정의
    ORG_NAME 조직의 이름입니다. 조직 이름은 다음 기준을 충족해야 합니다.
    • 3~19자의 소문자 ASCII 문자, 숫자 또는 하이픈이어야 합니다.
    • 문자로 시작해야 합니다.
    • 후행 하이픈이 없습니다.
    • -system 문자열로 끝나면 안 됩니다.
    LOG_RETENTION_POLICY 감사 로그, 운영 로그, 측정항목의 보관 기간 구성(일)입니다.
    KMS_ROOT_KEY_TYPE 이 구성은 조직의 KMS에 선택된 루트 키 유형을 보유합니다. 모든 KMS 서비스에는 KMS에서 생성된 키를 암호화하는 루트 키가 있습니다. 기본적으로 KMS는 물리적 HSM으로 백업된 Thales CipherTrust Manager에 저장된 루트 키인 CTM 루트 키를 생성합니다. Kubernetes 보안 비밀로 저장된 소프트웨어 루트 키를 선택할 수도 있습니다. kmsRootKeyType에 ctm-root 또는 local-root을 전달합니다.

    생성된 Organization 커스텀 리소스 YAML 파일의 예는 다음과 유사합니다.

    apiVersion: resourcemanager.global.private.gdc.goog/v1alpha1
kind: Organization
metadata:
    namespace: gpc-system
    name: org-1
spec:
    type: Tenant
    logRetentionPolicy:
        paAuditLogsRetentionTime: 400
        ioAuditLogsRetentionTime: 2000
        operationalLogsRetentionTime: 90
        metricsRetentionTime: 90
    securityConfig:
      kmsRootKeyType: "ctm-root"

  4. 선택사항: 버전 1.14.2 이상에서는 노드 간 IPsec 암호화가 기본적으로 사용 중지되어 있습니다. 이 IPsec 암호화가 필요한 경우 Organization 커스텀 리소스 YAML 파일을 수정하고 주석을 추가하여 노드 간 IPsec 암호화를 사용 설정할 수 있습니다.

    metadata:
    annotations:
        n2n.security.private.gdc.goog/node-to-node-encryption-disabled: "false"

    이 주석의 값이 "false"이면 암호화가 사용 설정됩니다.

  5. 배포의 각 영역에 대해 OrganizationZonalConfig 커스텀 리소스를 만듭니다.

    gdcloud organizations zonal-configs create --name ORG_NAME \
    --zones=ZONES \
    --version GDC_VERSION \
    --server-quota SERVER_QUOTA \
    --storage-sku STORAGE_SIZE \
    --admin-server ADMIN_SERVER

    예를 들면 다음과 같습니다.

    gdcloud organizations zonal-configs create --name org-1 \
    --zones=us-central1-a,us-central1-b \
    --version 1.9.2-gdch.153 \
    --server-quota o1-highmem1-40-gdc-metal=1,o1-standard1-64-gdc-metal=2,o1-highmem1-96-gdc-metal=3,o1-highmem1-104-gdc-metal=4,o1-highmem1-448-gdc-metal=5,o1-highgpu1-48-gdc-metal=6 \
    --storage-sku block-standard=100Ti,file-standard=100Ti,object-standard=100Ti \
    --admin-server o1-standard1-64-gdc-metal=3

    다음 변수를 바꿉니다.

    변수정의
    ORG_NAME 조직의 이름입니다. 조직 이름은 다음 기준을 충족해야 합니다.
    • 3~30자의 소문자 ASCII 문자, 숫자 또는 하이픈이어야 합니다.
    • 문자로 시작해야 합니다.
    • 후행 하이픈이 없습니다.
    • -system 문자열로 끝나면 안 됩니다.
    ZONES 배포의 영역 이름입니다.
    GDC_VERSION 조직을 만들 GDC 시스템 버전입니다.
    SERVER_QUOTA 조직 관리자 클러스터와 시스템 클러스터가 자동 생성될 때 할당할 서버입니다. 사전 학습된 인공지능 및 머신러닝 (AI/ML) API와 같은 VM 기반 워크로드인 그래픽 처리 장치 (GPU) 리소스를 실행하려는 경우 조직을 만들 때 GPU 머신을 프로비저닝해야 합니다. 자세한 내용은 시스템 클러스터에 GPU 지원 사용 설정 섹션을 참고하세요.
    ADMIN_SERVER 서버 유형과 해당 서버 유형에 할당할 조직 관리 서버의 양을 나타내는 키-값 쌍입니다. 혼합 유형은 서버에서 지원되지 않습니다. 기본값은 o1-standard1-64-gdc-metal: 3입니다.
    STORAGE_SIZE 조직에 할당할 다양한 스토리지 유형의 크기입니다. 조직의 최소 블록 스토리지 크기는 250Gi이며 BlockStandard 플래그로 설정됩니다.

    생성된 OrganizationZonalConfig 커스텀 리소스 YAML 파일의 예는 다음과 유사합니다.

    apiVersion: resourcemanager.global.private.gdc.goog/v1alpha1
kind: OrganizationZonalConfig
metadata:
  namespace: gpc-system
  name: org-1-zone1-config
spec:
  organizationRef:
    name: org-1
  zone: zone1
  version: 1.5.0-gdch.11
  capacities:
    storage:
      block-standard: 10Ti
      file-standard: 10Ti
      object-nearline: 10Ti
      object-standard: 10Ti
    workloadServers:
      o1-highmem1-40-gdc-metal: 1

  6. 생성된 YAML 파일을 검토합니다. 파일은 HOME 디렉터리에 있습니다.

    1. 조직 유형을 확인합니다. 프로비저닝할 수 있는 조직 유형에는 두 가지가 있습니다.

      • 조직 v1 아키텍처 (v1 조직)
      • 조직 v2 아키텍처 (v2 조직)

      기본적으로 새 조직은 기능 게이트 설정에 따라 배포 유형을 기반으로 프로비저닝됩니다.

      • PRODUCTION 배포는 기본적으로 v2 조직을 생성합니다.
      • ACCREDITED 배포는 기본적으로 v1 조직을 생성합니다.

      배포 유형의 기본 조직 유형을 재정의해야 하는 드문 경우 생성된 Organization 커스텀 리소스에서 spec.compatibilityOptions.architectureOverridePolicy 필드를 사용하려는 조직 유형에 따라 ForceV1 또는 ForceV2로 업데이트합니다. 예를 들어 다음 스니펫은 ACCREDITED 배포에서 v2 조직을 강제로 만듭니다.

      ...

spec:
...
  compatibilityOptions:
    architectureOverridePolicy: ForceV2

...

    2. 저장용량, 컴퓨팅 성능과 같은 구성요소가 회사의 요구사항을 충족하는지 나머지 설정을 확인합니다.

  7. Organization 및 OrganizationZonalConfig 맞춤 리소스를 새 조직의 디렉터리에 있는 저장소에 복사합니다.

    cp YAML_FILE_PATH/ORG_NAME.yaml IAC_REPO_PATH/iac/infrastructure/global/orgs/root/ORG_NAME/

    cp YAML_FILE_PATH/ORG_NAME-ZONE.yaml IAC_REPO_PATH/iac/infrastructure/global/orgs/root/ORG_NAME/

    다음을 바꿉니다.

    • ORG_NAME: --name 매개변수를 사용하여 gdcloud organizations config create 명령어에서 정의한 조직 이름입니다.
    • ZONE: 배포의 각 영역 이름입니다. 영역 이름은 {generalRegion}-{regionQualifier}{regionCounter}-{zoneLetter} 형식을 사용하여 파생됩니다. 예를 들면 us-central1-b입니다. 지역 속성 값에 대한 설명은 고객 접수 설문지의 지역 섹션을 참고하세요.

  8. 새 조직의 kustomization.yaml 파일을 추가합니다.

    cat > IAC_REPO_PATH/iac/infrastructure/global/orgs/root/ORG_NAME/kustomization.yaml << EOF
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
metadata:
  name: ORG_NAME-kustomization
resources:
-   ORG_NAME.yaml
-   ORG_NAME-ZONE.yaml
EOF

  9. 새 조직을 루트 조직의 리소스로 추가합니다.

    1. 전역 루트 kustomization.yaml 파일을 엽니다.

      vim /iac/infrastructure/global/orgs/root/kustomization.yaml

    2. 기존 리소스 목록 끝에 새 Organization를 리소스로 추가합니다.

      apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
metadata:
  name: global-root-kustomization
resources:
-   ... # existing resource items
-   ORG_NAME

  10. 조직 YAML 파일과 kustomize 파일을 스테이징하고 커밋합니다.

    git add "IAC_REPO_PATH/iac/infrastructure"
git commit

  11. 병합 요청을 만듭니다.

    git checkout -b ${USERNAME1}-branch
git -c http.sslVerify=false push -o merge_request.create origin {USERNAME1}-branch

  12. 코드 검토 및 병합을 기다립니다.

  13. 전역 조직 및 영역 구성을 사용할 수 있는지 확인합니다.

    1. GDC 유니버스에서 전역 조직을 사용할 수 있는지 확인합니다.

      kubectl get organization -A

      출력은 다음과 비슷합니다.

      NAMESPACE    NAME    AGE
gpc-system   org     34s
gpc-system   root    14h

    2. 전역 조직 상태를 확인합니다.

      kubectl --kubeconfig GLOBAL_ROOT_ADMIN_KUBECONFIG \
    get organization/ORG_NAME -n gpc-system -o yaml

      YAML 출력의 status 조건이 True인지 확인합니다.

    3. 각 영역에서 조직 구성 상태를 확인합니다.

      kubeconfig --kubeconfig ROOT_ADMIN_KUBECONFIG \
    get organization/ORG_NAME -n gpc-system -o yaml

      영역 컨텍스트를 전환하려면 조직 상태를 확인하기 전에 gdcloud CLI를 사용하여 각 영역에 로그인합니다. 각 영역의 YAML 출력에 있는 status 조건이 True인지 확인합니다.

1.5. 전역 조직 API 서버에서 전역 서브넷 만들기

전역 API 서버가 실행된 후 platform 네임스페이스 내 조직의 전역 API 서버에서 default-vpc-root-cidr를 만들어야 합니다. 이 루트 서브넷은 사용자 클러스터와 같은 테넌트 조직 내 클러스터의 IP 주소와 VM 워크로드의 IP 주소를 할당합니다.

  1. default-vpc-root-cidr.yaml과 같이 default-vpc-root-cidr 서브넷 YAML 파일을 만듭니다.

    apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/allocation-preference: default
    ipam.gdc.goog/vpc: default-vpc
    ipam.gdc.goog/usage: network-root-range
  name: default-vpc-root-cidr # don't change the name if you want IPAM controller to automatically divide the zone's subnet.
  namespace: platform
spec:
  type: Root
  ipv4Request:
    cidr: DEFAULT_VPC_CIDR

  2. iac 저장소로 이동하여 전역 조직의 디렉터리 구조를 추가합니다.

    cd iac; mkdir -p infrastructure/global/orgs/ORG_NAME/

  3. default-vpc-root-cidr 서브넷 YAML 파일을 새 조직 디렉터리의 IAC 저장소에 복사합니다.

    cp YAML_FILE_PATH/default-vpc-root-cidr.yaml \
    IAC_REPO_PATH/iac/infrastructure/global/orgs/ORG_NAME/

  4. 새로 추가된 Subnet 정의를 사용하여 조직 폴더에 kustomization.yaml 파일을 만듭니다. IAC_REPO_PATH /iac/infrastructure/global/orgs/ORG_NAME/kustomization.yaml를 확인합니다.

    cat > infrastructure/global/orgs/ORG_NAME/kustomization.yaml << EOF
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
metadata:
  name: ORG_NAME-kustomization
resources:
- default-vpc-root-cidr.yaml
EOF

  5. 조직 YAML 파일과 kustomize 파일을 스테이징하고 커밋합니다.

    git add "IAC_REPO_PATH/iac/infrastructure"
git commit

  6. 병합 요청을 만듭니다.

    git checkout -b ${USERNAME1}-branch
git -c http.sslVerify=false push -o merge_request.create origin {USERNAME1}-branch

  7. 코드 검토 및 병합을 기다립니다.

전역 루트 관리자 클러스터의 전역 서브넷이 분할되는 방식과 마찬가지로 default-vpc-root-cidr도 분할되어 영역 조직이 IP 주소를 사용할 수 있도록 각 영역에 전파됩니다.

1.7. 조직 관리자 NTPRelay 구성

루트 관리자와 조직 관리자 NTPRelay 간의 인증을 수동으로 구성해야 합니다.

NTP-P0001.3 (루트 관리자 -> 조직 관리자 NTPRelay 암호화)에 따라 이 조직의 암호화를 구성합니다.

1.8. IAC를 사용하여 IO ID 공급업체를 조직에 연결

  1. ADFS 가이드를 참고하여 새 조직의 ADFS에서 OIDC 클라이언트를 만들고 OIDC 클라이언트의 클라이언트 ID와 클라이언트 보안 비밀을 기록해 둡니다.

  2. 조직 이름을 환경 변수로 설정합니다.

    export ORG_NAME=ORG_NAME

    ORG_NAME이 조직의 정확한 이름과 일치하는지 확인합니다.

  3. 루트 관리자 클러스터 kubeconfig 파일을 내보내고 다음 kubectl 명령어를 실행하여 클러스터 및 영역 이름을 가져옵니다.

    export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
kubectl get clusters -A
kubectl get zones -n mz-system

  4. 조직의 ioauthmethod.yaml 파일을 추가합니다.

    cat > infrastructure/global/orgs/${ORG_NAME}/ioauthmethod.yaml << EOF
apiVersion: iam.global.private.gdc.goog/v1alpha1
kind: IOAuthMethod
metadata:
  name: io-idp-authmethod
  namespace: gpc-system
oidc:
  certificateAuthorityData: ADFS_CERT_BASE64
  clientID: ADFS_ORG_CLIENT_ID
  clientSecret: ADFS_ORG_CLIENT_SECRET
  groupPrefix: gdch-infra-operator-
  groupsClaim: groups
  issuerURI: ADFS_ISSUER_URI
  scopes: openid email offline_access
  userClaim: email
  userPrefix: gdch-infra-operator-
  cloudConsoleRedirectURI: http://cloud.console.not.enabled
  kubectlRedirectURI: http://localhost:9879/callback
EOF

    다음 변수를 바꿉니다.

    변수정의
    ADFS_CERT_BASE64 ADFS가 자체 서명하는 데 사용하는 인증서의 base64 인코딩입니다. GKE Identity Service가 내부 ADFS 인스턴스와 보안 연결을 설정하는 데 필요합니다.
    ADFS_ORG_CLIENT_ID ADFS에 있는 조직 클라이언트의 OpenID Connect ID입니다.
    ADFS_ORG_CLIENT_SECRET ADFS에 등록된 조직 클라이언트의 OpenID Connect 보안 비밀번호입니다.
    ADFS_ISSUER_URI GKE Identity Service에서 ADFS로 리디렉션 로그인 요청을 허용하는 데 필요한 유효한 발급자 URI입니다.

  5. 조직의 initial-admin.yaml 파일을 추가합니다.

    cat > infrastructure/global/orgs/${ORG_NAME}/initial-admin.yaml << EOF
apiVersion: iam.private.gdc.goog/v1alpha1
kind: ExpirationClusterRoleBinding
metadata:
  name: iac-binding-USER-org-iam-admin
spec:
  expirationTimestamp: EXPIRATION
  roleRef:
    apiGroup: rbac.authorization.k8s.io
    kind: ClusterRole
    name: organization-iam-admin
  subjects:
    - apiGroup: rbac.authorization.k8s.io
      kind: User
      name: gdch-infra-operator-USER@opscenter.local
EOF

    다음 변수를 바꿉니다.

    변수정의
    USER 처음에 클러스터에 로그인하는 IO의 접두사가 있는 사용자 이름입니다. 사용자 이름에 접두사를 추가해야 합니다.
    EXPIRATION 시스템에서 액세스 권한을 취소하는 RFC 3339 형식 타임스탬프입니다. 예를 들면 "2020-11-14T00:20:12+00:00"입니다.

  6. 새로 만든 파일을 IAC_REPO_PATH /iac/infrastructure/global/orgs/ORG_NAME/kustomization.yaml의 kustomization.yaml 파일에 추가합니다.

    apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
metadata:
  name: ORG_NAME-kustomization
resources:
-   ... # existing resource items
- ioauthmethod.yaml
- initial-admin.yaml

  7. 조직 YAML 파일과 kustomize 파일을 스테이징하고 커밋합니다.

    git add "infrastructure/global"
git add "infrastructure/zonal"
git commit

  8. GitLab에 업데이트를 푸시합니다.

    git -c http.sslVerify=false push

  9. 코드 검토 및 병합을 기다립니다.

  10. 운영자가 조직에 액세스할 수 있는지 확인하려면 생성된 조직에 로그인하고 다음 명령어를 실행하여 조직의 ClientConfig에 ID 공급자 (IdP)가 있는지 확인합니다.

    1. 조직 아키텍처에 따라 관리자 클러스터 kubeconfig 파일을 설정합니다.

      • v1 조직의 경우 다음을 실행합니다.

        export KUBECONFIG=ORG_ADMIN_CLUSTER_KUBECONFIG

        ORG_ADMIN_CLUSTER_KUBECONFIG를 조직 관리자 클러스터 kubeconfig의 경로(예: /tmp/${ORG}-admin-kubeconfig)로 바꿉니다.

      • v2 조직의 경우 다음을 실행합니다.

        export KUBECONFIG=ORG_INFRA_CLUSTER_KUBECONFIG

        ORG_INFRA_CLUSTER_KUBECONFIG를 조직 인프라 클러스터 kubeconfig의 경로로 바꿉니다(예: /tmp/${ORG}-infra-kubeconfig).

    2. 조직의 ClientConfig에 IdP가 있는지 확인합니다.

      kubectl get ClientConfig default -n kube-public -o yaml

  11. 버전 1.14.3의 경우 인증된 모든 사용자가 gdcloud CLI를 사용하여 유니버스에서 영역을 볼 수 있도록 global-zone-viewer 역할을 수동으로 적용해야 합니다. 역할 및 역할 바인딩 리소스를 적용합니다.

    kubectl --kubeconfig ORG_GLOBAL_API_SERVER_KUBECONFIG apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: global-zone-viewer
  namespace: mz-system
rules:
- apiGroups:
  - location.mz.global.private.gdc.goog
  resources:
  - zones
  verbs:
  - get
  - list
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: global-zone-viewer-binding
  namespace: mz-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: global-zone-viewer
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:authenticated
EOF

    ORG_GLOBAL_API_SERVER_KUBECONFIG를 조직의 전역 API 서버 kubeconfig 파일로 바꿉니다. 자세한 내용은 kubeconfig 파일 수동 생성을 참고하세요.

1.9. 고객 ID 공급업체를 조직에 연결

고객 ID 공급업체 (IdP)를 조직에 연결하고 ID로 조직에 로그인하려면 다음 단계를 완료하세요.

  1. 조직 생성 중에 설정된 초기 IO 관리자 계정으로 CLI에서 로그인합니다. 이 계정은 조직 관리자 클러스터에서 org-iam-admin에 자동으로 바인딩됩니다.

  2. 고객에게 다음과 같은 전역 AIS 콜백 URL을 만들 조직을 위해 고객이 만든 OIDC 또는 SAML 클라이언트의 허용 목록에 추가해 달라고 요청합니다.

    https://ais-core.ORG_NAME.GDC_URL/finish-login

    예를 들어 GDC의 루트 URL이 .google.gdch.test이고 조직 이름이 operations이면 전역 AIS 콜백 URL은 https://ais-core.operations.google.gdch.test/finish-login입니다.

    SAML 클라이언트를 사용하는 경우 다음 전역 AIS SAML 콜백 URL도 허용 목록에 추가해야 합니다.

    https://ais-core.ORG_NAME.GDC_URL/saml-callback

  3. 고객에게 각 영역에 대해 고객이 만든 OIDC 또는 SAML 클라이언트의 허용 목록에 다음 AIS 콜백 URL을 추가하도록 요청합니다. 예를 들어 3개 영역 유니버스의 경우 영역 AIS 콜백 URL은 다음과 유사합니다.

    https://ais-core.ORG_NAME.ZONE_1.GDC_URL/finish-login

https://ais-core.ORG_NAME.ZONE_2.GDC_URL/finish-login

https://ais-core.ORG_NAME.ZONE_3.GDC_URL/finish-login

    GDC의 루트 URL이 .google.gdch.test이고, 영역 이름이 zone-1이고, 조직 이름이 operations인 경우 AIS 콜백 URL은 https://ais-core.operations.zone-1.google.gdch.test/finish-login입니다.

    SAML 클라이언트를 사용하는 경우 각 영역의 허용 목록에 다음 AIS SAML 콜백 URL도 추가해야 합니다.

    https://ais-core.ORG_NAME.ZONE_1.GDC_URL/saml-callback

https://ais-core.ORG_NAME.ZONE_2.GDC_URL/saml-callback

https://ais-core.ORG_NAME.ZONE_3.GDC_URL/saml-callback

  4. 조직 아키텍처에 따라 관리자 클러스터 kubeconfig 파일을 설정합니다. kubeconfig 변수를 이미 설정한 경우 이 단계를 건너뛰세요.

    • v1 조직의 경우 다음을 실행합니다.

        export KUBECONFIG=ORG_ADMIN_CLUSTER_KUBECONFIG

      ORG_ADMIN_CLUSTER_KUBECONFIG를 조직 관리자 클러스터 kubeconfig의 경로(예: /tmp/${ORG}-admin-kubeconfig)로 바꿉니다.

    • v2 조직의 경우 다음을 실행합니다.

        export KUBECONFIG=MANAGEMENT_API_SERVER_KUBECONFIG

      MANAGEMENT_API_SERVER_KUBECONFIG를 관리 API 서버 kubeconfig의 경로(예: /tmp/${ORG}-management-kubeconfig)로 바꿉니다.

  5. 새 조직에 대한 고객 요청 티켓에서 IdP가 OIDC를 사용하는지 또는 SAML을 사용하는지 결정합니다. 제공된 IdP 유형에 매핑되는 가이드를 따르세요.

OIDC로 설정

  1. identity-provider-config.yaml 파일을 만들고 PA의 계정 IdP 값을 조직 생성 티켓을 참고하여 입력합니다.

    cat << EOF > identity-provider-config.yaml
apiVersion: iam.global.gdc.goog/v1
kind: IdentityProviderConfig
metadata:
  name: pa-idp-oidc
  namespace: platform
spec:
  oidc:
    certificateAuthorityData: "PA_IDP_BASE64_ENCODED_CERTIFICATE"
    clientID: PA_IDP_CLIENT_ID
    clientSecret: PA_IDP_CLIENT_SECRET
    groupPrefix: PA_IDP_GROUP_CLAIM
    groupsClaim: PA_IDP_PREFIX
    issuerURI: PA_IDP_ISSUER_URI
    scopes: openid email profile
    userClaim: PA_IDP_USER_CLAIM
    userPrefix: PA_IDP_PREFIX
EOF

  2. 다음은 필드에 대한 자세한 설명입니다.

    속성 속성 유형 설명
    certificateAuthorityData 필수 OIDC 제공업체의 표준 base64 인코딩, PEM 형식 인증 기관 인증서입니다.
    clientID 필수 OpenID 제공업체에 인증을 요청하는 클라이언트 애플리케이션의 ID입니다.
    clientSecret 필수 OIDC 클라이언트 애플리케이션과 OIDC 제공업체 간에 공유된 보안 비밀입니다.
    extraParams 선택사항 인증 엔드포인트 요청과 함께 전송되는 쿼리 인코딩된 키-값 쌍의 쉼표로 구분된 목록입니다.
    groupPrefix 선택사항 기존 그룹과 충돌하지 않도록 그룹 클레임 앞에 추가할 접두사입니다. 일반적으로 여러 ID 공급업체를 구성할 때 사용됩니다.
    모든 그룹 이름 앞에 그룹 프리픽스를 포함해야 합니다. 예를 들어 그룹 접두사가 myprefix-이고 ID 제공업체에 groupA이라는 그룹이 있는 경우 정책이나 바인딩을 추가할 때 myprefix-groupA을 바인딩해야 합니다. 그룹 이름은 groupsClaim 필드에 설정됩니다.
    groupsClaim 선택사항 OIDC ID 토큰에서 사용자의 그룹 정보가 저장된 클레임의 이름입니다. 이 이름은 OIDC 제공업체의 그룹 멤버십 정보를 포함하는 클레임의 이름과 동일해야 합니다.
    issuerURI 필수 승인 요청이 OIDC 제공업체로 전송되는 URL입니다. 이 URI는 .well-known/openid-configuration 내부의 수준을 가리켜야 합니다.
    scopes 선택사항 openid 범위 외에 요청되는 액세스 권한을 지정하기 위한 쉼표로 구분된 식별자 목록입니다.
    userClaim 필수 사용자 이름이 저장된 OIDC ID 토큰의 클레임 이름입니다. 예를 들어 사용자 클레임이 email이면 OIDC 토큰에서 이 사용자 필드로 사용자가 식별됩니다.
    ID 토큰에 이 값이 없으면 인증이 실패합니다.
    userPrefix 선택사항 기존 사용자 이름과의 충돌을 방지하기 위해 사용자 클레임 앞에 추가되는 프리픽스입니다. 일반적으로 여러 ID 제공업체를 구성할 때 사용됩니다.
    예를 들어 사용자 클레임이 email이고 사용자 접두사가 prefix-이면 사용자가 prefix-sally@example.com으로 식별됩니다. 사용자가 sally@example.com이고 prefix- 프리픽스가 여러 ID 공급업체 간 구분을 위해 사용자에 프리픽스로 추가됩니다. groupPrefix 설정을 위해 이 표의 앞에서 설명한 대로 프리픽스 끝에 구분자를 삽입하는 것이 좋습니다.

  3. 선택사항: ID 공급업체에서 맞춤 속성을 사용하는 경우 먼저 IdP에서 속성을 구성합니다. 그런 다음 사용자 또는 그룹에 관한 추가 클레임(예: 부서 또는 생일)을 위해 identity-provider-config.yaml 파일의 oidc 섹션에 해당 키-값 쌍을 추가합니다. ID 공급업체 구성에 변경사항을 적용하면 GKE Identity Service에서 맞춤 속성을 인식합니다. 다음은 맞춤 속성의 예입니다.

      "attributeMapping": {
  "attribute.birthday": "assertion.birthday",
  "attribute.department": "assertion.department"
  }

  4. ID 공급업체 구성을 구성합니다.

    kubectl apply -f identity-provider-config.yaml

  5. 여러 시스템 구성요소가 다시 구성될 때까지 기다립니다.

  6. 웹브라우저에서 플랫폼 관리 UI 콘솔을 열어 구성을 확인합니다. 리디렉션 페이지에서 pa-idp-oidc로 로그인을 선택합니다. PA 계정 IdP 인스턴스로 리디렉션되고 PA 계정 IdP 인스턴스로 로그인한 후 플랫폼 관리자 UI 콘솔 페이지로 다시 리디렉션되면 구성이 완료된 것입니다. 그렇지 않으면 identity-provider-config.yaml의 값을 확인하고 이전 단계를 다시 적용합니다.

SAML로 설정

  1. identity-provider-config.yaml 파일을 만들고 PA의 계정 IdP 값을 조직 생성 티켓에서 참조하여 파일을 채웁니다.

    cat << EOF > identity-provider-config.yaml
apiVersion: iam.global.gdc.goog/v1
kind: IdentityProviderConfig
metadata:
  name: pa-idp-saml
  namespace: platform
spec:
  saml:
    idpEntityID: PA_IDP_ISSUER_URI
    idpSingleSignOnURI: PA_IDP_SSO_URI
    groupPrefix: PA_IDP_PREFIX
    groupsAttribute: PA_IDP_GROUPS_ATTRIBUTE
    idpCertificateDataList: [PA_IDP_SAML_CERT]
    userAttribute: PA_IDP_USER_ATTRIBUTE
    userPrefix: PA_IDP_PREFIX
EOF

  2. 다음은 필드에 대한 자세한 설명입니다.

    .
    속성 속성 유형 설명
    idpCertificateDataList 필수 SAML 응답을 확인하는 데 사용되는 IDP 인증서입니다. 이러한 인증서는 표준 base64 인코딩 및 PEM 형식이어야 합니다. IdP 인증서 순환을 촉진하기 위해 최대 2개의 인증서만 지원됩니다.
    idpEntityID 필수 URI 형식으로 지정된 SAML 공급업체의 SAML 엔티티 ID입니다. 예: https://www.idp.com/saml
    idpSingleSignOnURI 필수 SAML 공급업체의 SSO 엔드포인트 URI입니다. 예: `https://www.idp.com/saml/sso`
    groupPrefix 선택사항 각 그룹 이름 앞에 추가할 선택적 접두사입니다.
    userPrefix 선택사항 사용자 이름 앞에 추가할 선택적 접두사입니다.
    userAttribute 선택사항 사용자 이름이 있는 SAML 응답의 속성 이름입니다. SAML 응답에 이 속성이 누락되면 인증이 실패합니다.
    groupsAttribute 선택사항 사용자의 그룹이 있는 SAML 응답의 속성 이름입니다.

  3. 선택사항: ID 공급업체에서 맞춤 속성을 사용하는 경우 먼저 IdP에서 속성을 구성합니다. 그런 다음 사용자 또는 그룹에 관한 추가 클레임(예: 부서 또는 생일)을 위해 identity-provider-config.yaml 파일의 saml 섹션에 해당 키-값 쌍을 추가합니다. ID 공급업체 구성에 변경사항을 적용하면 GKE Identity Service에서 맞춤 속성을 인식합니다. 다음은 맞춤 속성의 예입니다.

      "attributeMapping": {
  "attribute.birthday": "assertion.birthday",
  "attribute.department": "assertion.department"
  }

  4. ID 공급업체 구성 패치를 구성합니다.

    kubectl apply -f identity-provider-config.yaml

  5. 여러 시스템 구성요소가 다시 구성될 때까지 기다립니다.

  6. 웹브라우저에서 플랫폼 관리 UI 콘솔을 열어 구성을 확인합니다. 리디렉션 페이지에서 pa-idp-oidc로 로그인을 선택합니다. PA 계정 IdP 인스턴스로 리디렉션되고 PA 계정 IdP 인스턴스로 로그인한 후 플랫폼 관리자 UI 콘솔 페이지로 다시 리디렉션되면 구성이 완료된 것입니다. 그렇지 않으면 identity-provider-config.yaml의 값을 확인하고 이전 단계를 다시 적용합니다.

사용자 및 그룹 접두사

여러 IdP의 계정 간 이름 충돌을 방지하려면 분산형 클라우드의 모든 IdP에 대해 사용자 및 그룹 접두사를 설정해야 합니다. 이 접두사는 사용자 및 그룹 이름과 함께 사용하여 클러스터의 역할 바인딩에서 주체 이름을 연결합니다. 예를 들어 이름이 jack@example.com인 사용자의 경우 IdP의 사용자 접두사가 example-org-idp-이면 클러스터의 주체 이름은 example-org-idp-jack@example.com이 됩니다.

접두사 값을 결정하려면 다음 단계를 따르세요.

  • 계층 구조 수준 (루트, 조직, 프로젝트)을 포함합니다.
  • IdP 이름 (adfs, keycloak)을 포함합니다.
  • 프리픽스와 사용자 이름 사이에 구분자가 추가되지 않으므로 -와 같은 구분자 문자를 접미사로 추가하는 것이 좋습니다.

초기 관리자 할당

PA가 조직에 대한 초기 액세스 권한을 부여받으려면 조직의 관리자로 할당되어야 합니다. PA를 초기 관리자로 할당하려면 전역 API 서버에서 IAMRoleBinding를 만드세요.

kubectl apply -f --kubeconfig=GLOBAL_API_SERVER_KUBECONFIG - <<EOF
apiVersion: iam.global.gdc.goog/v1
kind: IAMRoleBinding
metadata:
  name: PA_INITIAL_ADMIN_EMAIL-binding
  namespace: platform
spec:
  roleRef:
    apiGroup: iam.global.gdc.goog
    kind: IAMRole
    name: organization-iam-admin
  subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: User
    name: PA_IDP_PREFIXPA_INITIAL_ADMIN_EMAIL
EOF

1.10 조직의 네트워크 연결 설정

새로 생성된 조직은 격리되어 있으며 외부 네트워크에서 액세스할 수 없습니다. 조직을 운영하려면 Interconnect 서비스를 사용하여 하나 이상의 외부 네트워크에 연결해야 합니다.

이 프로세스에는 논리적 연결을 정의하는 커스텀 리소스 집합을 구성하는 작업이 포함됩니다. 다음은 새 조직에 연결을 제공하는 두 가지 일반적인 시나리오입니다.

시나리오 1: 기존 공유 인터커넥트에 조직 연결

공유 네트워크에 기존 인터커넥트가 있는 경우 새 조직을 포함하도록 AttachmentGroup 및 RoutePolicy만 업데이트하면 됩니다.

  1. AttachmentGroup 업데이트: AttachmentGroup은 VLAN 연결 집합을 사용할 수 있는 조직을 지정합니다. AttachmentGroup YAML 파일을 수정하고 spec.entities 목록에 새 조직을 추가합니다. v2 조직의 경우 연결할 네트워크 domainType (OrgAdmin, OrgData 또는 OrgMixed)를 지정해야 합니다.

    AttachmentGroup 업데이트 예시:

    apiVersion: system.private.gdc.goog/v1alpha1
kind: AttachmentGroup
metadata:
  name: attachment-group-shared
  namespace: gpc-system
spec:
  identifier: shared-network
  entities:
  - orgName: existing-org-1 # Existing organization
    domainType: OrgMixed
  - orgName: new-customer-org # Add the new organization
    domainType: OrgMixed

  2. RoutePolicy 업데이트: RoutePolicy는 광고되는 IP 접두사를 정의합니다. 정책을 수정하고 새 조직의 외부 IP 서브넷을 spec.out.ipPrefixList에 추가합니다. 이렇게 하면 인바운드 트래픽이 조직에 도달할 수 있습니다.

    RoutePolicy 업데이트 예시:

    apiVersion: system.private.gdc.goog/v1alpha1
kind: RoutePolicy
metadata:
  name: shared-routepolicy
  namespace: gpc-system
spec:
  # ... other fields ...
  out:
    asPathAccessList:
    - action: Permit
      asPathRegex: ".*"
    ipPrefixList:
    - action: Permit
      ipPrefix: EXTERNAL_SUBNET_OF_EXISTING_ORG_1
    - action: Permit
      ipPrefix: EXTERNAL_SUBNET_OF_NEW_CUSTOMER_ORG # Add new prefix
    # ... deny rules ...

  3. 코드형 인프라 (IaC) 프로세스와 함께 kubectl apply를 사용하여 변경사항을 적용합니다.

시나리오 2: 새 Dedicated Interconnect 만들기

전용 연결의 경우 새로운 Interconnect 리소스를 만들어야 합니다. 전체 프로세스에는 순서대로 5개의 커스텀 리소스를 만드는 작업이 포함됩니다.

  1. 새 실제 연결마다 InterconnectLink를 만듭니다.
  2. 물리적 링크를 번들로 묶고 새 조직을 허용하는 InterconnectGroup를 만듭니다.
  3. AttachmentGroup를 만들고 entities 목록에 새 조직을 지정합니다.
  4. 이 전용 연결의 인바운드 및 아웃바운드 IP 접두사를 허용하는 RoutePolicy를 만듭니다.
  5. VLAN 및 BGP 세션을 정의하는 하나 이상의 InterconnectAttachment 리소스를 만듭니다.

각 리소스에 대한 포괄적인 예시와 자세한 단계는 인터커넥트 구성 문서를 참고하세요.

1.11 ServiceNow에 연결하도록 Alertmanager 웹훅 설정

MON-T0016의 단계에 따라 이슈 생성을 위해 Alertmanager 웹훅을 ServiceNow에 연결합니다.

1.12 조직의 결제 가격표 구성

조직의 결제 하위 구성요소에는 청구할 제품 또는 서비스가 커스텀 리소스 SKUDescription로 구성되어야 합니다. 단일 SKUDescription는 가격과 함께 청구될 단일 제품 또는 서비스를 설명합니다. 따라서 SKUDescription 객체 모음은 조직의 가격표로 간주할 수 있습니다. 다음 단계에서는 IAC에서 조직의 가격표를 구성합니다.

1.12.1 가격 시트 가져오기

조직의 SKUDescription 가격표 리소스가 아직 없는 경우 프로그램 관리 사무소 (PMO)에 문의하여 가격표를 받으세요. 가격 시트는 SKUDescription 리소스가 포함된 YAML 파일의 시리즈여야 합니다.

1.12.2 가격 시트가 공유되었는지 확인

가격 시트는 모든 조직에 공유하거나 조직별로 구성할 수 있습니다. PMO에서 가격 시트가 공유되었는지 여부를 알려줄 수 있습니다.

1.12.2.1 공유 가격 시트

가격 시트가 공유된 경우 가격 시트를 common-data 공유 IAC 폴더에 배치합니다.

  1. 이 조직이 처음 생성된 조직이 아닌 경우 가격 시트가 이미 공유 common-data 폴더에 있을 수 있습니다. 가격 시트가 있는 경우 2~4단계를 따랐는지 확인하고 5단계로 진행합니다.

  2. 가격 시트의 공유 폴더를 만듭니다.

    mkdir -p IAC_REPO_PATH/iac/infrastructure/common-data/bil/skudescriptions/

    IAC_REPO_PATH를 IAC 저장소의 경로로 바꿉니다.

  3. SKUDescription 가격표 YAML 리소스를 이 폴더에 저장합니다. 그 후 skudescriptions 폴더에는 영역별로 구분된 YAML 파일이 포함되어야 합니다. 결제 사용 사례에 맞게 폴더 구조와 YAML 파일을 구성합니다.

    • 파트너 운영 결제: Google에서 파트너에게 청구합니다. SKUDescription 리소스를 partner-billing-system 네임스페이스에 배치합니다.

    • 고객 결제: 파트너가 최종 사용자에게 청구합니다. SKUDescription 리소스를 billing-system 네임스페이스에 배치합니다.

    다음 예에서는 고객 청구 및 파트너 운영 청구 모델 파일 구조를 모두 보여줍니다. 각 모델에는 컴퓨팅과 스토리지라는 두 서비스가 표시되며 각 서비스에는 두 개의 YAML 파일이 있습니다.

    고객 결제:

    ├── customer
     ├── compute
     │   ├── compute-sku1.yaml
     │   └── compute-sku2.yaml
     └── storage
         ├── storage-sku1.yaml
         └── storage-sku2.yaml

    파트너 운영 결제:

    ├── partner
     ├── compute
     │   ├── partner-compute-sku1.yaml
     │   └── partner-compute-sku2.yaml
     └── storage
         ├── partner-storage-sku1.yaml
         └── partner-storage-sku2.yaml

  4. 모든 SKUDescription 가격표 YAML 파일이 포함된 디렉터리에 kustomization.yaml 파일이 있는지 확인합니다.

    touch IAC_REPO_PATH/iac/infrastructure/common-data/bil/skudescriptions/kustomization.yaml
cd IAC_REPO_PATH/iac/infrastructure/common-data/bil/skudescriptions/
kustomize edit add resource */*.yaml

  5. ORG_CLUSTER 환경 변수를 내보냅니다.

    • v1 조직의 경우 다음을 실행합니다.

      export ORG_CLUSTER=ORG_ADMIN_CLUSTER_NAME

    • v2 조직의 경우 다음을 실행합니다.

      export ORG_CLUSTER=ORG_INFRA_CLUSTER_NAME

  6. 조직에 skudescriptions 결제 디렉터리를 만듭니다.

    • v1 조직의 경우:

      mkdir -p IAC_REPO_PATH/iac/infrastructure/zonal/zones/ZONE_NAME/ORG_CLUSTER_NAME/bil/skudescriptions

    • v2 조직의 경우:

      mkdir -p IAC_REPO_PATH/iac/infrastructure/zonal/zones/ZONE_NAME/ORG_CLUSTER_NAME-management/bil/skudescriptions

    조직 버전 유형에 따라 ORG_CLUSTER_NAME을 조직의 관리자 클러스터 이름으로 바꿉니다.

  7. 조직에 일반 가격표를 포함합니다.

    • v1 조직의 경우:

      cat > IAC_REPO_PATH/iac/infrastructure/zonal/zones/ZONE_NAME/ORG_CLUSTER_NAME/bil/skudescriptions/kustomization.yaml << EOF
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ../../../../common-data/bil/skudescriptions
EOF

    • v2 조직의 경우:

      cat > IAC_REPO_PATH/iac/infrastructure/zonal/zones/ZONE_NAME/ORG_CLUSTER_NAME-management/bil/skudescriptions/kustomization.yaml << EOF
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ../../../../common-data/bil/skudescriptions
EOF

  8. YAML 파일을 스테이징하고 커밋한 후 파일을 맞춤설정합니다.

    cd IAC_REPO_PATH
git add "iac"
git commit

  9. GitLab에 업데이트를 푸시합니다.

    git -c http.sslVerify=false push

  10. 코드 검토 및 병합을 기다립니다.

  11. 해당 결제 모델의 지정된 클러스터에 SKUDescription 객체가 있는지 확인합니다.

    조직 유형에 따라 KUBECONFIG 값을 내보냅니다.

    • v1 조직의 경우 다음을 실행합니다.

      export KUBECONFIG=ORG_ADMIN_CLUSTER_KUBECONFIG

      ORG_ADMIN_CLUSTER_KUBECONFIG를 조직 관리자 클러스터 kubeconfig의 경로(예: /tmp/${ORG}-admin-kubeconfig)로 바꿉니다.

    • v2 조직의 경우 다음을 실행합니다.

      export KUBECONFIG=MANAGEMENT_API_SERVER_KUBECONFIG

      MANAGEMENT_API_SERVER_KUBECONFIG를 관리 API 서버 kubeconfig의 경로(예: /tmp/${ORG}-management-kubeconfig)로 바꿉니다.

    kubectl CLI를 실행합니다.

    고객 결제:

    
kubectl get SKUDescription -n billing-system

    파트너 결제:

    
kubectl get SKUDescription -n partner-billing-system

1.12.2.2 조직별 가격 시트

가격 시트가 조직에만 적용되는 경우 조직 클러스터 폴더에 가격 시트를 배치해야 합니다.

  1. 조직 클러스터에 skudescriptions 결제 디렉터리를 만듭니다.

    • v1 조직의 경우:

      mkdir -p IAC_REPO_PATH/iac/infrastructure/zonal/zones/ZONE_NAME/ORG_CLUSTER_NAME/bil/skudescriptions

    • v2 조직의 경우:

      mkdir -p IAC_REPO_PATH/iac/infrastructure/zonal/zones/ZONE_NAME/ORG_CLUSTER_NAME-management/bil/skudescriptions

  2. SKUDescription 가격표 YAML 리소스를 이 폴더에 저장합니다. 그 후 skudescriptions 폴더에는 영역별로 구분된 YAML 파일이 있어야 합니다. 다음 예에서는 각각 두 개의 YAML 파일이 있는 컴퓨팅 및 스토리지라는 두 개의 서비스를 볼 수 있습니다.

    .
├── compute
│   ├── compute-sku1.yaml
│   └── compute-sku2.yaml
└── storage
    ├── storage-sku1.yaml
    └── storage-sku2.yaml

  3. 모든 SKUDescription 가격표 YAML 파일이 포함된 디렉터리에 kustomization.yaml 파일이 있는지 확인합니다.

    • v1 조직의 경우:

      touch IAC_REPO_PATH/iac/infrastructure/zonal/zones/ZONE_NAME/ORG_CLUSTER_NAME/bil/skudescriptions/kustomization.yaml
cd IAC_REPO_PATH/iac/infrastructure/zonal/zones/ZONE_NAME/ORG_CLUSTER_NAME/bil/skudescriptions/
kustomize edit add resource */*.yaml

    • v2 조직의 경우:

      touch IAC_REPO_PATH/iac/infrastructure/zonal/zones/ZONE_NAME/ORG_CLUSTER_NAME-management/bil/skudescriptions/kustomization.yaml
cd IAC_REPO_PATH/iac/infrastructure/zonal/zones/ZONE_NAME/ORG_CLUSTER_NAME-management/bil/skudescriptions/
kustomize edit add resource */*.yaml

  4. 조직의 루트에 있는 kustomization.yaml 파일에 새로 추가된 bil/skudescriptions 폴더가 있는지 확인합니다. v1 조직의 경우 IAC_REPO_PATH/iac/infrastructure/zonal/zones/ZONE_NAME/ORG_CLUSTER_NAME/kustomization.yaml, v2 조직의 경우 IAC_REPO_PATH/iac/infrastructure/zonal/zones/ZONE_NAME/ORG_CLUSTER_NAME-management/kustomization.yaml을 확인합니다.

    apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
-   ... # existing resource items
-   bil/skudescriptions

  5. YAML 파일과 kustomize 파일을 스테이징하고 커밋합니다.

    cd IAC_REPO_PATH
git add "iac"
git commit

  6. GitLab에 업데이트를 푸시합니다.

    git -c http.sslVerify=false push

  7. 코드 검토 및 병합을 기다립니다.

  8. 지정된 클러스터에 SKUDescription 객체가 있는지 확인합니다.

    • v1 조직의 경우 다음을 실행합니다.

      export KUBECONFIG=ORG_ADMIN_CLUSTER_KUBECONFIG

kubectl get SKUDescription -n billing-system

      ORG_ADMIN_CLUSTER_KUBECONFIG를 조직 관리자 클러스터 kubeconfig의 경로(예: /tmp/${ORG}-admin-kubeconfig)로 바꿉니다.

    • v2 조직의 경우 다음을 실행합니다.

      export KUBECONFIG=MANAGEMENT_API_SERVER_KUBECONFIG

kubectl get SKUDescription -n billing-system

      MANAGEMENT_API_SERVER_KUBECONFIG를 관리 API 서버 kubeconfig의 경로(예: /tmp/${ORG}-management-kubeconfig)로 바꿉니다. .

1.13 결제 반복 사용량 생성

Distributed Cloud는 반복 청구되는 재고 관리 단위 (SKU)를 제공합니다. 하지만 Distributed Cloud는 특정 SKU의 사용 비용을 추적하지 않습니다. 이러한 정보를 관리하려면 RecurringUsage 리소스를 사용하세요. 반복 사용량 생성에 관한 자세한 내용과 안내는 반복 사용량 생성을 참고하세요.

1.14 조직의 결제 구성

결제 하위 구성요소는 결제 시작 시간이 될 때까지 조직의 비용을 계산하지 않습니다. 결제 시작 시간의 기본값은 9999-01-01T00:00:00-07:00입니다. 따라서 조직이 준비된 것으로 간주되면 IO에서 청구 시작 시간을 재정의하여 청구 워크플로를 시작합니다.

1.14.1 결제 시작 시간 가져오기

청구 시작 시간은 계약에 명시된 서비스 기간의 시작 시간이어야 합니다. 조직의 결제 시작 시간이 아직 없는 경우 프로그램 관리 사무소 (PMO)에 문의하여 정보를 확인하세요.

1.14.2 결제 지불 계정을 조직에 매핑

Google Distributed Cloud (GDC) 에어갭 환경에서는 프로젝트 및 조직의 비용을 추적하기 위해 결제 계정이 필요합니다. 결제 계정을 조직 또는 프로젝트에 연결하지 않으면 리소스와 연결된 비용 데이터가 손실됩니다.

고객에게 서비스 사용량을 청구하려면 조직 내 모든 결제 계정에서 단일 가격표를 사용합니다.

1.14.2.1 시작하기 전에

계속하기 전에 보안 관리자에게 다음 필수 역할을 부여해 달라고 요청하세요. 이러한 역할은 프로젝트 수준 결제의 경우 프로젝트 네임스페이스에 바인딩되고 조직 수준 결제의 경우 플랫폼 네임스페이스에 바인딩됩니다.

  • 조직 결제 계정 관리자: BillingAccount 리소스를 생성, 관리, 바인딩합니다. 보안 관리자에게 organization-billing-account-admin 역할을 부여해 달라고 요청하세요.

  • 조직 결제 계정 사용자: BillingAccount 리소스를 읽고, 나열하고, 바인딩합니다. 보안 관리자에게 organization-billing-account-user 역할을 부여해 달라고 요청하세요.

  • 조직 결제 계정 관리자: BillingAccountBinding 리소스를 읽고, 나열하고, 만들고, 업데이트합니다. 보안 관리자에게 organization-billing-manager 역할을 부여해 달라고 요청하세요.

1.14.2.2 새 결제 계정 만들기

결제 계정은 name 및 namespace로 고유하게 식별됩니다. 결제 계정을 만들려면 커스텀 리소스를 사용하여 name 및 namespace를 설정하세요.

  1. YAML 파일을 만들고 BillingAccount 커스텀 리소스와 다음 콘텐츠를 추가합니다.

    apiVersion: billing.gdc.goog/v1
kind: BillingAccount
metadata:
  namespace: platform
  name: BIL_ACCOUNT_NAME
spec:
  displayName: BIL_DISPLAY_NAME
  paymentSystemConfig:
    cloudBillingConfig:
      accountID: "012345-6789AB-CDEF01"

    다음 변수를 바꿉니다.

    • BIL_ACCOUNT_NAME: 결제 계정의 이름입니다. 예를 들면 다음과 같습니다. test-billing-account
    • BIL_DISPLAY_NAME: 결제 계정 표시 이름입니다. 예를 들면 다음과 같습니다. "Test Billing Account"

  2. 결제 구성 유형을 확인합니다. Distributed Cloud 결제 계정에는 다음 결제 구성 중 하나가 있어야 합니다.

    • cloudBillingConfig: 기본 결제 구성입니다. 이 구성은 Cloud Billing 계정 ID를 저장합니다.

    • customConfig: 파트너가 조직에 청구하기 위해 결제 구성을 저장하는 맞춤 구성입니다. customConfig는 필수 키 payment-config-type이 있는 키-값 문자열의 사전을 지원합니다.

    다음 예는 다양한 결제 구성을 위한 BillingAccount YAML 파일 스니펫을 보여줍니다.

    cloudBillingConfig

    spec:
  paymentSystemConfig:
    cloudBillingConfig:
      accountID: CLOUD_BILLING_ACCOUNT_ID

    CLOUD_BILLING_ACCOUNT_ID를Google Cloud 청구 계정 ID로 바꿉니다.

    customConfig

    spec:
  paymentSystemConfig:
    customConfig:
      "payment-config-type": PAYMENT_CONFIG_TYPE

    PAYMENT_CONFIG_TYPE을 맞춤 결제 구성에 선택한 결제 구성 유형으로 바꿉니다.

    조직의 customConfig 구성 정보가 없는 경우 다음 세부정보를 입력합니다.

    spec:
  paymentSystemConfig:
    customConfig:
      "payment-config-type": "N/A"

    다음 YAML 파일은 cloudBillingConfig 구성이 포함된 완전한 BillingAccount 리소스를 보여줍니다.

    apiVersion: billing.gdc.goog/v1
kind: BillingAccount
metadata:
  namespace: platform
  name: test-billing-account
spec:
  displayName: "Test Billing Account"
  paymentSystemConfig:
    cloudBillingConfig:
      accountID: "012345-6789AB-CDEF01"

  3. 커스텀 리소스 YAML 파일을 저장합니다. kubectl CLI를 실행하여 청구할 특정 조직 또는 프로젝트의 조직 클러스터에 리소스를 적용합니다.

    kubectl --kubeconfig $ORG_KUBECONFIG apply -f billingaccount.yaml

조직을 BillingAccount에 연결하려면 다음 단계를 따르세요.

  1. 다음 콘텐츠를 YAML 파일 billingaccountbinding.yaml에 추가합니다.

    • billingAccountRef 섹션에서 연결하려는 BillingAccount의 name 필드에 있는 콘텐츠로 name 필드를 채웁니다.
    • metadata 섹션에서 BillingAccount 리소스의 동일한 필드의 콘텐츠로 namespace 필드를 채웁니다. 이 예에서 조직 네임스페이스는 platform입니다.
    apiVersion: billing.gdc.goog/v1
kind: BillingAccountBinding
metadata:
  name: billing
  namespace: platform
spec:
  billingAccountRef:
    name: BIL_ACCOUNT_NAME
    namespace: platform

  2. billingaccountbinding.yaml 파일을 적용합니다.

    kubectl --kubeconfig $ORG_KUBECONFIG apply -f billingaccountbinding.yaml

1.14.3 시작하기 전에

계속하기 전에 보안 관리자에게 billing-system 네임스페이스의 조직 관리 클러스터에 대한 빌 모니터(bil-monitor) 역할을 부여해 달라고 요청하세요. 이 권한을 사용하면 유효성 검사를 위해 관련 리소스를 읽을 수 있습니다.

1.14.4 결제 시작 시간 재정의

  1. 다음 경로로 두 개의 YAML 파일을 만듭니다.

    • infrastructure/zonal/zones/ZONE_NAME/root-admin/components/bil/ORG_NAME/bil-monetizer-override.yaml개

    • infrastructure/zonal/zones/ZONE_NAME/root-admin/components/bil/ORG_NAME/bil-invoice-override.yaml개

      • 필요한 하위 디렉터리가 누락된 경우 각 파일에 대해 필요한 하위 디렉터리를 만듭니다.

  2. SubcomponentOverride 리소스와 다음 내용을 각 파일에 추가합니다.

    고객 결제:

    • bil-monetizer-override.yaml 파일:

      apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
  name: bil-monetizer
  namespace: ORG_NAME
spec:
  subComponentRef: bil-monetizer
  backend:
    operableParameters:
      billingStartTime: BILLING_START_TIME
      billingTimezone: BILLING_TIMEZONE

    • bil-invoice-override.yaml 파일:

      apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
  name: bil-invoice
  namespace: ORG_NAME
spec:
  subComponentRef: bil-invoice
  backend:
    operableParameters:
      billingStartTime: BILLING_START_TIME
      billingTimezone: BILLING_TIMEZONE

    파트너 운영 결제:

    • 각 YAML 파일의 끝에 enablePartnerBilling: true 플래그를 추가합니다.

    • bil-monetizer-override.yaml 파일:

      apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
  name: bil-monetizer
  namespace: ORG_NAME
spec:
  subComponentRef: bil-monetizer
  backend:
    operableParameters:
      billingStartTime: BILLING_START_TIME
      billingTimezone: BILLING_TIMEZONE
      enablePartnerBilling: true

    • bil-invoice-override.yaml 파일:

      apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
  name: bil-invoice
  namespace: ORG_NAME
spec:
  subComponentRef: bil-invoice
  backend:
    operableParameters:
      billingStartTime: BILLING_START_TIME
      billingTimezone: BILLING_TIMEZONE
      enablePartnerBilling: true

    다음 변수를 바꿉니다.

    • ORG_NAME: 조직 이름 예를 들면 org-1입니다.

    • BILLING_START_TIME: 결제 워크플로를 시작할 타임스탬프입니다.타임스탬프는 RFC 3339 형식을 따라야 합니다. 예를 들어 청구 워크플로가 2024년 1월 1일에 미국 및 캐나다 태평양 표준시 (UTC-8) 시간대로 시작되는 경우 타임스탬프 값을 2024-01-01T00:00:00-08:00로 추가합니다.

    • BILLING_TIMEZONE: 결제 워크플로의 시간대입니다. 시간대는 RFC 3339 형식을 따라야 합니다. 예를 들어 청구 시간대가 미국 및 캐나다 태평양 표준시 (UTC-8)인 경우 시간대 값을 PST8PDT로 추가합니다.

    • bil-monetizer-override-mp.yaml 파일:

      apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
  name: bil-monetizer
  namespace: ORG_NAME-mp
spec:
  subComponentRef: bil-monetizer
  backend:
    operableParameters:
      billingStartTime: BILLING_START_TIME
      billingTimezone: BILLING_TIMEZONE
      enablePartnerBilling: true

    • bil-invoice-override-mp.yaml 파일:

      apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
  name: bil-invoice
  namespace: ORG_NAME-mp
spec:
  subComponentRef: bil-invoice
  backend:
    operableParameters:
      billingStartTime: BILLING_START_TIME
      billingTimezone: BILLING_TIMEZONE
      enablePartnerBilling: true

  3. YAML 파일을 infrastructure/zonal/zones/ZONE_NAME/root-admin/components/bil/ORG_NAME 폴더에 저장합니다.

  4. 필요한 kustomization 파일과 함께 YAML 파일이 포함된 풀 요청을 만듭니다.

1.14.5 결제 시작 시간 검증

수익 창출 도구의 결제 시작 시간과 인보이스 생성을 재정의했는지 확인합니다.

kubectl --kubeconfig ORG_ADMIN_KUBECONFIG \
    get deployment billing-monetizer -n billing-system \
    -o jsonpath='{.spec.template.spec.containers[0].args}{"\n"}'

kubectl --kubeconfig ORG_ADMIN_KUBECONFIG \
    get cronjob billing-ig-job -n billing-system \
    -o jsonpath='{.spec.jobTemplate.spec.template.spec.containers[0].args}{"\n"}'

1.15 조직의 관리자 클러스터에서 객체 스토리지 프록시의 네트워크 정책 구성

1.15.1 네트워크 정책 YAML 파일 만들기

allow-obs-system-ingress-traffic 네트워크 정책 YAML 파일(예: networkpolicy.yaml)을 만듭니다.

  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    annotations:
      policy.network.gke.io/enable-logging: "true"
      resourcemanager.gdc.goog/propagated-name: allow-obs-system-ingress-traffic
    name: allow-obs-system-ingress-traffic
    namespace: obj-system
  spec:
    ingress:
    - from:
      - namespaceSelector:
          matchLabels:
            resourcemanager.gdc.goog/project-name: obs-system
    podSelector: {}
    policyTypes:
    - Ingress

1.15.2 조직의 관리자 클러스터에 네트워크 정책 적용

kubectl --kubeconfig ORG_ADMIN_KUBECONFIG apply -f networkpolicy.yaml

1.16. 백업 사이트 만들기

재해 복구 지원을 활용하는 경우 백업 사이트에 대해 이전 단계를 다시 완료해야 합니다. 재해 복구가 사용 설정되어 있지 않으면 이 섹션을 건너뛰세요.

  1. 1.4절을 따르세요. - 1.9. 백업 사이트용 다른 조직을 만듭니다.

1.17. 조직 만들기 문제 해결

1.17.1. 배포된 모든 리소스가 정상이고 존재하는지 확인

조직 생성 프로세스는 여러 Kubernetes 클러스터에 걸쳐 여러 리소스를 만듭니다. 먼저 배포된 리소스를 확인하여 상태가 양호한지 확인합니다. 다음 섹션에서는 operations라는 조직에 생성된 리소스를 간략히 설명합니다.

1.17.2. 루트 관리자 클러스터에 배포된 모든 리소스 확인

다음 단계를 완료하여 루트 관리자 클러스터의 모든 리소스가 정상이고 존재하는지 확인합니다.

  1. IAM-R0004에 따라 루트 관리자 클러스터에 필요한 kubeconfig 구성을 가져옵니다. 다음 확인 안내에 따라 다음 환경 변수와 별칭을 설정해야 합니다.

    export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
export ORG="ORG_NAME"
alias k=kubectl

  2. 방화벽 리소스를 사용할 수 있는지 확인합니다.

    1. 방화벽에 SSH 연결을 설정하고 새로 생성된 vsys가 있는지 확인합니다.

      show config running | match 'vsys[0-9] '

      출력은 다음과 비슷합니다.

      vsys1 {
vsys2 {

    2. FirewallVirtualSystem 리소스를 확인합니다.

      k get firewallvirtualsystem -n gpc-system

      출력은 다음과 비슷합니다.

      NAME                                   AGE
kb-ab-fw01-internal-vsys2-operations   4d19h
kb-ab-fw01-vsys-root-admin             13d
kb-ac-fw01-internal-vsys2-operations   4d19h
kb-ac-fw01-vsys-root-admin             13d

  3. 스토리지 리소스를 사용할 수 있는지 확인합니다.

    1. StorageVirtualMachine 리소스를 확인합니다.

      k get StorageVirtualMachine -n gpc-system

      출력은 다음과 비슷합니다.

      NAME               STORAGEORG   MGMTIP      READY   AGE
operations-admin   operations   10.0.2.10   True    5d22h
operations-user    operations   10.0.2.18   True    5d22h
root-admin         root         10.0.2.2    True    13d

  4. HSM 리소스를 사용할 수 있는지 확인합니다.

    1. HSM을 확인합니다.

      k get hsms -n gpc-system

      출력은 다음과 비슷합니다.

      NAMESPACE    NAME          AGE    IP               READY   REASON
gpc-system   zk-aa-hsm01   2h     198.51.100.192   True    ReconcileHSMSuccess
gpc-system   zk-aa-hsm02   2h     198.51.100.193   True    ReconcileHSMSuccess
gpc-system   zk-ab-hsm01   2h     198.51.100.194   True    ReconcileHSMSuccess

    2. HSM 클러스터를 확인합니다.

      k get hsmcluster -n gpc-system

      출력은 다음과 비슷합니다.

      NAMESPACE    NAME          AGE   READY   REASON
gpc-system   hsmcluster    38h   True    ReconcileHSMClusterSuccess

    3. HSM 테넌트를 확인합니다.

      k get hsmtenant -A

      출력은 다음과 비슷합니다.

      NAMESPACE    NAME         AGE     READY   REASON
gpc-system   root         13d     True    ReconcileHSMTenantSuccess
operations   operations   5d22h   True    ReconcileHSMTenantSuccess

  5. 머신 및 노드 리소스를 사용할 수 있는지 확인합니다.

    1. AddressPoolClaim 리소스를 확인합니다.

      k get addresspoolclaims -A

      출력은 다음과 비슷합니다.

      NAMESPACE    NAME                                              AGE
operations   admin-control-plane-node-pool                     5d23h
operations   operations-admin-dns-default-ipv4-ipc             5d23h
operations   operations-admin-load-balancer-default-ipv4-ipc   5d23h

    2. NodePoolClaim 리소스를 확인합니다.

      k get nodepoolclaims -A

      출력은 다음과 비슷합니다.

      NAMESPACE    NAME                            AGE
operations   admin-control-plane-node-pool   5d23h
root         root-admin-control-plane        13d

    3. NodePool 리소스를 확인합니다.

      k get nodepool -A

      출력은 다음과 비슷합니다.

      NAMESPACE    NAME                            READY   RECONCILING   STALLED   UNDERMAINTENANCE   UNKNOWN
operations   admin-control-plane-node-pool   3       0             0         0                  0
root         root-admin-control-plane        3       0             0         0                  0

    4. 베어메탈 클러스터를 확인합니다.

      k get baremetalclusters -A

      출력은 다음과 비슷합니다.

      NAMESPACE    NAME               CLUSTER            READY
operations   operations-admin   operations-admin   true
root         root-admin         root-admin         true

    5. 베어메탈 머신을 확인합니다.

      k get baremetalmachines -A

      출력은 다음과 비슷합니다.

      NAMESPACE    NAME           CLUSTER            READY   INSTANCEID                 MACHINE
operations   10.251.82.28   operations-admin   true    baremetal://10.251.82.28   10.251.82.28
operations   10.251.82.29   operations-admin   true    baremetal://10.251.82.29   10.251.82.29
operations   10.251.82.30   operations-admin   true    baremetal://10.251.82.30   10.251.82.30
root         10.251.80.2    root-admin         true    baremetal://10.251.80.2    10.251.80.2
root         10.251.80.3    root-admin         true    baremetal://10.251.80.3    10.251.80.3
root         10.251.80.4    root-admin         true    baremetal://10.251.80.4    10.251.80.4

    6. 서버를 확인합니다. provisioned 상태입니다.

      k get servers -n gpc-system | grep provisioned

      출력은 다음과 비슷합니다.

      kb-aa-bm01   13d          o1-highmem1-40-gdc-metal    10.251.252.61   10.251.80.2              10.251.252.62   provisioned   true
kb-aa-bm02   13d          o1-standard1-64-gdc-metal   10.251.252.63   10.251.82.28             10.251.252.64   provisioned   true
kb-aa-bm03   13d          o1-standard1-64-gdc-metal   10.251.252.65   10.251.82.29             10.251.252.66   provisioned   true
kb-aa-bm04   13d          o1-standard1-64-gdc-metal   10.251.252.67   10.251.82.30             10.251.252.68   provisioned   true
kb-aa-bm08   13d          o1-highmem1-96-gdc-metal    10.251.252.75   10.0.35.2                10.251.252.76   provisioned   true
kb-aa-bm10   13d          o1-highmem1-96-gdc-metal    10.251.252.79   10.0.35.4                10.251.252.80   provisioned   true
kb-aa-bm14   13d          o1-highgpu1-48-gdc-metal    10.251.252.87   10.0.35.9                10.251.252.88   provisioned   true
kb-aa-bm15   13d          o1-highgpu1-48-gdc-metal    10.251.252.89   10.0.35.10               10.251.252.90   provisioned   true
kb-aa-bm16   13d          o1-highgpu1-48-gdc-metal    10.251.252.91   10.0.35.11               10.251.252.92   provisioned   true
kb-ab-bm01   13d          o1-highmem1-40-gdc-metal    10.251.253.61   10.251.80.3              10.251.253.62   provisioned   true
kb-ac-bm01   13d          o1-highmem1-40-gdc-metal    10.251.254.61   10.251.80.4              10.251.254.62   provisioned   true

    7. Kubernetes 클러스터를 확인합니다.

      k get cluster -A

      출력은 다음과 비슷합니다.

      NAMESPACE    NAME               AGE
operations   operations-admin   5d23h
root         root-admin         13d

    8. kubeconfig의 보안 비밀을 확인합니다.

      k get secrets -A | grep kubeconfig

      출력은 다음과 비슷합니다.

      operations    operations-admin-kubeconfig   Opaque        1      5d22h
root          root-admin-kubeconfig         Opaque        1      13d

1.17.3. v1 조직 클러스터에 배포된 모든 리소스 확인

다음 단계를 완료하여 v1 조직의 조직 관리자 클러스터와 시스템 클러스터에 있는 모든 리소스가 정상이고 존재하는지 확인합니다. v2 조직이 있는 경우 다음 섹션으로 건너뜁니다.

1.17.3.1. 조직 관리자 클러스터에 배포된 모든 리소스 확인

  1. IAM-R0004에 따라 루트 관리자 클러스터에 필요한 kubeconfig 구성을 가져옵니다. 다음 확인 안내에 따라 다음 환경 변수와 별칭을 설정해야 합니다.

    export ORG="ORG_NAME"
export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
k get secrets -n ${ORG} ${ORG}-admin-kubeconfig -o jsonpath='{.data.value}' \
    | base64 -d > /tmp/${ORG}-admin-kubeconfig
export ORG_ADMIN_KUBECONFIG=/tmp/${ORG}-admin-kubeconfig
alias ka="kubectl --kubeconfig ${ORG_ADMIN_KUBECONFIG}"

  2. 머신 및 노드 리소스를 사용할 수 있는지 확인합니다.

    1. 베어메탈 클러스터를 확인합니다.

      ka get baremetalclusters -A

      출력은 다음과 비슷합니다.

      NAMESPACE                    NAME                 CLUSTER              READY
operations-system-cluster    operations-system    operations-system    true

    2. 베어메탈 머신을 확인합니다.

      ka get baremetalmachines -A

      출력은 다음과 비슷합니다.

      NAMESPACE                    NAME            CLUSTER              READY   INSTANCEID                  MACHINE
operations-system-cluster    10.0.35.10      operations-system    true    baremetal://10.0.35.10      10.0.35.10
operations-system-cluster    10.0.35.11      operations-system    true    baremetal://10.0.35.11      10.0.35.11
operations-system-cluster    10.0.35.2       operations-system    true    baremetal://10.0.35.2       10.0.35.2
operations-system-cluster    10.0.35.3       operations-system    true    baremetal://10.0.35.3       10.0.35.3
operations-system-cluster    10.0.35.4       operations-system    true    baremetal://10.0.35.4       10.0.35.4
operations-system-cluster    10.0.35.9       operations-system    true    baremetal://10.0.35.9       10.0.35.9
operations-system-cluster    10.251.82.205   operations-system    true    baremetal://10.251.82.205   10.251.82.205
operations-system-cluster    10.251.82.206   operations-system    true    baremetal://10.251.82.206   10.251.82.206
operations-system-cluster    10.251.82.207   operations-system    true    baremetal://10.251.82.207   10.251.82.207
operations-system-cluster    10.251.82.232   operations-system    true    baremetal://10.251.82.232   10.251.82.232

    3. 머신을 확인합니다.

      ka get machines -A

      출력은 다음과 비슷합니다.

      NAMESPACE                    NAME            NODEPOOL
operations-system-cluster    10.0.35.10      worker-node-pool-o1-highgpu1-48-gdc-metal
operations-system-cluster    10.0.35.11      worker-node-pool-o1-highgpu1-48-gdc-metal
operations-system-cluster    10.0.35.2       worker-node-pool-o1-highmem1-96-gdc-metal
operations-system-cluster    10.0.35.3       worker-node-pool-o1-highmem1-96-gdc-metal
operations-system-cluster    10.0.35.4       worker-node-pool-o1-highmem1-96-gdc-metal
operations-system-cluster    10.0.35.9       worker-node-pool-o1-highgpu1-48-gdc-metal
operations-system-cluster    10.251.82.205   control-plane-node-pool
operations-system-cluster    10.251.82.206   control-plane-node-pool
operations-system-cluster    10.251.82.207   control-plane-node-pool
operations-system-cluster    10.251.82.232   control-plane-node-pool

    4. VirtualmachinesInstance 리소스를 확인합니다.

      ka get virtualmachineinstances -A

      출력은 다음과 비슷합니다.

      NAMESPACE                    NAME          AGE     PHASE     IP              NODENAME     READY
operations-system-cluster    vm-19753801   2d16h   Running   10.251.82.207   kb-aa-bm02   True
operations-system-cluster    vm-3661f750   4d19h   Running   10.251.82.232   kb-aa-bm03   True
operations-system-cluster    vm-3c77c480   5d20h   Running   10.251.82.206   kb-aa-bm04   True

    5. NodePool 리소스를 확인합니다.

      ka get nodepools -A

      출력은 다음과 비슷합니다.

      NAMESPACE                    NAME                                        READY   RECONCILING   STALLED   UNDERMAINTENANCE   UNKNOWN
operations-system-cluster    control-plane-node-pool                     3       0             0         0                  0
operations-system-cluster    worker-node-pool-o1-highgpu1-48-gdc-metal   3       0             0         0                  0
operations-system-cluster    worker-node-pool-o1-highmem1-96-gdc-metal   2       0             0         0                  0

    6. Kubernetes 클러스터를 확인합니다.

      ka get clusters -A

      출력은 다음과 비슷합니다.

      NAMESPACE                    NAME                 AGE
operations-system-cluster    operations-system    5d20h

    7. 노드를 확인합니다.

      ka get nodes -A

      출력은 다음과 비슷합니다.

      NAME         STATUS   ROLES                  AGE     VERSION
kb-aa-bm02   Ready    control-plane,master   5d23h   v1.23.5-gke.1505
kb-aa-bm03   Ready    control-plane,master   5d23h   v1.23.5-gke.1505
kb-aa-bm04   Ready    control-plane,master   5d23h   v1.23.5-gke.1505

    8. kubeconfig의 보안 비밀을 확인합니다.

      ka get secret -n ${ORG}-system-cluster ${ORG}-system-kubeconfig

      출력은 다음과 비슷합니다.

      NAME                           TYPE     DATA   AGE
operations-system-kubeconfig   Opaque   1      5d20h

1.17.3.2. 시스템 사용자 클러스터에 배포된 모든 리소스 확인

다음 단계에 따라 시스템 클러스터의 모든 리소스가 정상이고 존재하는지 확인합니다.

  1. IAM-R0004에 따라 루트 관리자 클러스터에 필요한 kubeconfig 구성을 가져옵니다. 다음 확인 안내에 따라 다음 환경 변수와 별칭을 설정해야 합니다.

    export ORG="ORG_NAME"
export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
k get secrets -n ${ORG} ${ORG}-admin-kubeconfig -o jsonpath='{.data.value}' \
    | base64 -d > /tmp/${ORG}-admin-kubeconfig
export ORG_ADMIN_KUBECONFIG=/tmp/${ORG}-admin-kubeconfig
alias ka="kubectl --kubeconfig ${ORG_ADMIN_KUBECONFIG}"
ka get secret -n ${ORG}-system-cluster ${ORG}-system-kubeconfig -o jsonpath='{.data.value}' \
    | base64 -d > /tmp/${ORG}-system-kubeconfig
export SYSTEM_KUBECONFIG=/tmp/${ORG}-system-kubeconfig
alias ku="kubectl --kubeconfig ${SYSTEM_KUBECONFIG}"

  2. 머신 및 노드 리소스를 사용할 수 있는지 확인합니다.

    1. VirtualmachineInstance 리소스를 확인합니다.

      ku get vmi -A

      출력은 다음과 비슷합니다 (사용자 클러스터가 생성된 경우).

      NAMESPACE       NAME            AGE     PHASE     IP            NODENAME     READY
gdc-vm-infra   vm-61aa554d     3d21h   Running   10.0.35.6     kb-aa-bm10   True
gdc-vm-infra   vm-b627da1f     3d21h   Running   10.0.35.5     kb-aa-bm08   True

    2. 노드를 확인합니다.

      ku get nodes

      출력은 다음과 비슷합니다.

      NAME          STATUS                     ROLES                  AGE     VERSION
kb-aa-bm10    Ready                      worker                 5d20h   v1.23.5-gke.1505
kb-aa-bm14    Ready                      worker                 38h     v1.23.5-gke.1505
kb-aa-bm15    Ready                      worker                 38h     v1.23.5-gke.1505
kb-aa-bm16    Ready                      worker                 38h     v1.23.5-gke.1505
vm-19753801   Ready                      control-plane,master   5d21h   v1.23.5-gke.1505
vm-3661f750   Ready                      control-plane,master   4d20h   v1.23.5-gke.1505
vm-3c77c480   Ready                      control-plane,master   5d20h   v1.23.5-gke.1505

    3. GPU 할당을 확인합니다.

      ku get gpuallocations -A

      출력은 다음과 비슷합니다.

      NAMESPACE   NAME         ALLOCATED   DEVICEMODEL
vm-system   kb-aa-bm14   true        A100 PCIe 40GB
vm-system   kb-aa-bm15   true        A100 PCIe 40GB
vm-system   kb-aa-bm16

1.17.4. v2 조직 클러스터에 배포된 모든 리소스 확인

v2 조직의 조직 인프라 클러스터에 있는 모든 리소스가 정상이고 존재하는지 확인하려면 다음 단계를 완료하세요. v1 조직이 있는 경우 이 섹션을 건너뛰세요.

  1. IAM-R0004에 따라 루트 관리자 클러스터에 필요한 kubeconfig 구성을 가져옵니다. 다음 확인 안내에 따라 다음 환경 변수와 별칭을 설정해야 합니다.

    export ORG="ORG_NAME"
export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
k get secrets -n ${ORG} ${ORG}-admin-kubeconfig -o jsonpath='{.data.value}' \
    | base64 -d > /tmp/${ORG}-admin-kubeconfig
export ORG_ADMIN_KUBECONFIG=/tmp/${ORG}-admin-kubeconfig
alias ka="kubectl --kubeconfig ${ORG_ADMIN_KUBECONFIG}"

  2. 노드와 API 서버가 정상 상태인지 확인합니다.

    1. 노드를 확인합니다.

      ka get nodes -A

      출력은 다음과 비슷합니다.

      NAME         STATUS   ROLES                  AGE     VERSION
kb-aa-bm02   Ready    control-plane,master   5d23h   v1.23.5-gke.1505
kb-aa-bm03   Ready    control-plane,master   5d23h   v1.23.5-gke.1505
kb-aa-bm04   Ready    control-plane,master   5d23h   v1.23.5-gke.1505
kb-aa-bm05   Ready    worker                 5d23h   v1.23.5-gke.1505
kb-aa-bm06   Ready    worker                 5d23h   v1.23.5-gke.1505
kb-aa-bm07   Ready    worker                 5d23h   v1.23.5-gke.1505

    2. kubeconfig의 보안 비밀을 확인합니다.

      ka get secret -n management-kube-system kube-admin-remote-kubeconfig

      출력은 다음과 비슷합니다.

      NAME                           TYPE     DATA   AGE
kube-admin-remote-kubeconfig   Opaque   1      5d20h

  3. 해당하는 경우 GPU 할당을 확인하여 GPU 리소스가 준비되었는지 확인합니다.

    ka get gpuallocations -A

    출력은 다음과 비슷합니다.

    NAMESPACE   NAME         ALLOCATED   DEVICEMODEL
vm-system   kb-aa-bm14   true        A100 PCIe 40GB
vm-system   kb-aa-bm15   true        A100 PCIe 40GB
vm-system   kb-aa-bm16

1.17.5. 모든 조직 리소스가 조정되었는지 확인

타겟이 zone-1 및 zone-2의 두 영역으로 operations 조직을 만드는 것이라고 가정할 때 전역 및 영역 루트 관리자 클러스터의 모든 조직 관련 리소스가 정상이고 존재함을 확인하려면 다음 단계를 완료하세요.

  1. 전역 루트 관리자 API 액세스에 따라 전역 API 서버에 액세스하고 전역 루트 관리자 API kubectl에 다음 별칭을 사용합니다.

    alias kga='kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG
export ORG="ORG_NAME"

  2. 전역 조직 리소스를 사용할 수 있는지 확인합니다.

    1. 전역 Organization 리소스를 확인합니다.

      kga get organization -A

      출력은 다음과 비슷합니다.

      NAMESPACE    NAME         READY
gpc-system   operations
gpc-system   root

    2. 전역 OrganizationReplica 리소스를 확인합니다.

      kga get organizationreplica -A

      출력은 다음과 비슷합니다.

      NAMESPACE    NAME               AGE
gpc-system   operations-zone1   3d16h
gpc-system   operations-zone2   3d16h
gpc-system   root-zone1         3d17h
gpc-system   root-zone2         3d16h

    3. 전역 OrganizationZonalConfig 리소스를 확인합니다.

      kga get organizationzonalconfig -A

      출력은 다음과 비슷합니다.

      NAMESPACE    NAME                      AGE
gpc-system   operations-zone1-config   3d16h
gpc-system   operations-zone2-config   3d16h

    4. 전역 OrganizationZonalConfigReplica 리소스를 확인합니다.

      kga get organizationzonalconfigreplica -A

      출력은 다음과 비슷합니다.

      NAMESPACE    NAME                             AGE
gpc-system   operations-zone1-config-zone1    3d16h
gpc-system   operations-zone1-config-zone2    3d16h
gpc-system   operations-zone2-config-zone1    3d16h
gpc-system   operations-zone2-config-zone2    3d16h

  3. 영역별 루트 관리자 클러스터의 kubeconfig 구성 별칭을 설정합니다.

    alias ka='kubectl --kubeconfig /root/GDC_VERSION/root-admin/root-admin-kubeconfig'

  4. 영역별 조직 리소스를 사용할 수 있는지 확인합니다.

    1. Organization 리소스를 확인합니다.

      ka get organization -A

      출력은 다음과 비슷합니다.

      NAMESPACE    NAME         READY
gpc-system   operations   True
gpc-system   root         True

    2. OrganizationReplica 리소스를 확인합니다.

      ka get organizationreplica -A

      출력은 다음과 비슷합니다.

      NAMESPACE    NAME         AGE
gpc-system   operations   3d16h
gpc-system   root         3d17h

    3. OrganizationZonalConfigReplica 리소스를 확인합니다.

      ka get organizationzonalconfigreplica -A

      출력은 다음과 비슷합니다.

      NAMESPACE    NAME                       AGE
gpc-system   operations-zone1-config    3d16h
gpc-system   operations-zone2-config    3d16h

  5. 모든 주소에서 조직에 액세스하도록 허용에 따라 소스 사이트에서 백업 사이트로 조직 관리자 클러스터의 DCI 트래픽을 허용합니다.