가용성이 높은 컨테이너 애플리케이션 배포

이 페이지에서는 Google Distributed Cloud (GDC) 에어 갭에서 강력한 고가용성 (HA) Kubernetes 컨테이너 애플리케이션을 빌드하기 위한 권장 배포 전략을 제공합니다. 여러 GDC 영역에 컨테이너 애플리케이션을 배포하고 비동기 스토리지 복제를 구성하여 예기치 않은 다운타임이나 지역 재해 발생 시 애플리케이션과 데이터를 복구할 수 있어야 합니다.

이 페이지는 조직의 애플리케이션 워크로드를 만드는 애플리케이션 운영자 그룹 내 개발자를 위한 페이지입니다. 자세한 내용은 GDC 오프라인 문서 대상을 참고하세요.

목표

• GDC 유니버스의 두 개 이상의 영역에 Kubernetes 클러스터를 만듭니다.
• 전역 부하 분산을 구성합니다.
• 각 영역 Kubernetes 클러스터에 컨테이너 워크로드를 배포합니다.
• 스토리지를 프로비저닝하고 포드에 연결합니다.
• 블록 스토리지 또는 객체 스토리지를 사용하여 비동기 스토리지 복제를 구성합니다.

시작하기 전에

• 사용 가능한 영역이 여러 개인 GDC 유니버스에서 작업하고 있는지 확인합니다. gdcloud zones list을 실행하여 유니버스에서 사용 가능한 영역을 나열합니다. 자세한 내용은 유니버스에 있는 영역 나열을 참고하세요.

• 조직 IAM 관리자에게 다음 역할을 부여해 달라고 요청하세요.

  • 컨테이너 워크로드를 만들고 관리하는 네임스페이스 관리자 (namespace-admin) 역할

  • Kubernetes 클러스터와 해당 노드 풀을 만들고 관리하는 사용자 클러스터 관리자 (user-cluster-admin) 및 사용자 클러스터 개발자(user-cluster-developer) 역할

  • 부하 분산기 관리자 (load-balancer-admin) 및 전역 부하 분산기 관리자 (global-load-balancer-admin) 역할 부하 분산기를 만들고 관리하려면 이 역할이 있어야 합니다.

  • 볼륨 복제 전역 관리자 역할 (app-volume-replication-admin-global). 볼륨 복제를 관리하려면 이 역할이 있어야 합니다.

  • 영역 간 프로젝트 네트워크 정책을 만들고 관리하는 전역 PNP 관리자 (global-project-networkpolicy-admin) 역할

  • Harbor 인스턴스 관리자 (harbor-instance-admin), Harbor 인스턴스 뷰어(harbor-instance-viewer), Harbor 프로젝트 생성자(harbor-project-creator) 역할 이러한 역할은 Artifact Registry에서 컨테이너 이미지를 만들고 관리하는 데 필요합니다.

  • 블록 스토리지 리소스의 볼륨 복제 관계를 관리하는 볼륨 복제 전역 관리자 (app-volume-replication-admin-global) 역할

  • 스토리지 버킷을 만들고 관리하는 프로젝트 버킷 객체 관리자 (project-bucket-object-admin) 및 프로젝트 버킷 관리자 (project-bucket-admin) 역할

  자세한 내용은 역할 설명을 참고하세요.

• gdcloud CLI를 설치 및 구성하고 영역 및 전역 컨텍스트를 구성합니다. 자세한 내용은 영역 간 리소스 관리를 참고하세요.

• 전역 API 서버, 관리 API 서버, Kubernetes 클러스터에 적절한 kubeconfig 파일이 설정된 kubectl CLI를 설치하고 구성합니다. 자세한 내용은 kubeconfig 파일 수동 생성을 참고하세요.

여러 영역에 Kubernetes 클러스터 만들기

Kubernetes 클러스터는 영역 리소스이므로 각 영역에 별도로 클러스터를 만들어야 합니다.

콘솔

1. 탐색 메뉴에서 Kubernetes Engine > 클러스터를 선택합니다.

   중요: Kubernetes 클러스터를 만드는 동안 범위 선택기에서 프로젝트를 선택할 수 없습니다. 이는 클러스터가 조직 범위로 지정되어 있기 때문입니다. 자세한 내용은 리소스 계층 구조를 참고하세요.

2. 클러스터 만들기를 클릭합니다.

3. 이름 필드에 클러스터 이름을 지정합니다.

4. 클러스터의 Kubernetes 버전을 선택합니다.

5. 클러스터를 만들 영역을 선택합니다.

6. 프로젝트 연결을 클릭하고 클러스터에 연결할 기존 프로젝트를 선택합니다. 그런 다음 저장을 클릭하고 프로젝트 세부정보 페이지에서 클러스터를 만든 후 프로젝트를 연결하거나 연결 해제할 수 있습니다. 컨테이너 워크로드를 배포하려면 클러스터에 연결된 프로젝트가 있어야 합니다.

7. 다음을 클릭합니다.

8. 클러스터의 네트워크 설정을 구성합니다. 클러스터를 만든 후에는 이러한 네트워크 설정을 변경할 수 없습니다. Kubernetes 클러스터의 기본 및 유일하게 지원되는 인터넷 프로토콜은 인터넷 프로토콜 버전 4 (IPv4)입니다.

   1. 부하 분산기 IP 주소 풀 크기(예: 20)를 지정합니다.

   2. 사용할 서비스 CIDR (클래스 없는 도메인 간 라우팅)을 선택합니다. 배포된 서비스(예: 부하 분산기)에는 이 범위의 IP 주소가 할당됩니다.

      중요: 범위는 클러스터 및 노드 풀 리소스의 다른 IP 주소 범위와 충돌하지 않는 모든 RFC 1918 범위일 수 있습니다. 자세한 내용은 RFC 1918을 참고하세요. URL에 액세스하려면 인터넷에 연결해야 합니다. 이 URL은 오프라인 환경 외부에서 액세스를 제공합니다.

   3. 사용할 포드 CIDR을 선택합니다. 클러스터는 이 범위에서 포드와 VM에 IP 주소를 할당합니다.

   4. 다음을 클릭합니다.

9. 클러스터에 대해 자동 생성된 기본 노드 풀의 세부정보를 검토합니다. 수정을 클릭하여 기본 노드 풀을 수정합니다.

   중요: 클러스터에서 그래픽 처리 장치(GPU) 워크로드를 실행하려면 클러스터에 GPU 머신 유형을 프로비저닝해야 합니다. 자세한 내용은 클러스터 노드 머신 유형을 참고하세요.

10. 노드 풀을 추가로 만들려면 노드 풀 추가를 선택합니다. 기본 노드 풀을 수정하거나 새 노드 풀을 추가할 때 다음 옵션을 사용하여 맞춤설정합니다.

    1. 노드 풀의 이름을 할당합니다. 노드 풀을 만든 후에는 이름을 수정할 수 없습니다.
    2. 노드 풀에서 만들 워커 노드 수를 지정합니다.

    3. 워크로드 요구사항에 가장 적합한 머신 클래스를 선택합니다. 다음 설정 목록을 확인하세요.

       • 머신 유형
       • CPU
       • 메모리

    4. 저장을 클릭합니다.

    5. 만들기를 클릭하여 클러스터를 만듭니다.

11. GDC 유니버스의 각 영역에 대해 이 단계를 반복합니다. HA 전략에 필요한 모든 영역에 Kubernetes 클러스터가 있는지 확인합니다.

API

API를 직접 사용하여 새 Kubernetes 클러스터를 만들려면 각 GDC 영역에 맞춤 리소스를 적용하세요.

1. Cluster 커스텀 리소스를 만들고 영역의 관리 API 서버에 배포합니다.

   kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF \
   apiVersion: cluster.gdc.goog/v1
   kind: Cluster
   metadata:
     name: CLUSTER_NAME
     namespace: platform
   spec:
     clusterNetwork:
       podCIDRSize: POD_CIDR
       serviceCIDRSize: SERVICE_CIDR
     initialVersion:
       kubernetesVersion: KUBERNETES_VERSION
     loadBalancer:
       ingressServiceIPSize: LOAD_BALANCER_POOL_SIZE
     nodePools:
     - machineTypeName: MACHINE_TYPE
       name: NODE_POOL_NAME
       nodeCount: NUMBER_OF_WORKER_NODES
       taints: TAINTS
       labels: LABELS
       acceleratorOptions:
         gpuPartitionScheme: GPU_PARTITION_SCHEME
     releaseChannel:
       channel: UNSPECIFIED
   EOF
   

   다음을 바꿉니다.

   • MANAGEMENT_API_SERVER: 영역별 관리 API 서버의 kubeconfig 경로입니다. 자세한 내용은 영역 컨텍스트로 전환을 참고하세요.
   • CLUSTER_NAME: 클러스터의 이름입니다. 클러스터 이름은 -system로 끝나면 안 됩니다. -system 접미사는 GDC에서 생성한 클러스터용으로 예약되어 있습니다.
   • POD_CIDR: 포드 가상 IP 주소 (VIP)가 할당되는 네트워크 범위의 크기입니다. 설정하지 않으면 기본값 21이 사용됩니다.
   • SERVICE_CIDR: 서비스 VIP가 할당되는 네트워크 범위의 크기입니다. 설정되지 않은 경우 기본값 23이 사용됩니다.
   • KUBERNETES_VERSION: 클러스터의 Kubernetes 버전입니다(예: 1.26.5-gke.2100). 구성할 수 있는 Kubernetes 버전을 나열하려면 클러스터에 사용 가능한 Kubernetes 버전 나열을 참고하세요.
   • LOAD_BALANCER_POOL_SIZE: 부하 분산기 서비스에서 사용하는 중복되지 않는 IP 주소 풀의 크기입니다. 설정되지 않은 경우 기본값 20이 사용됩니다.
   • MACHINE_TYPE: 노드 풀의 작업자 노드에 사용할 머신 유형입니다. 구성할 수 있는 항목은 사용 가능한 머신 유형을 참고하세요.
   • NODE_POOL_NAME: 노드 풀의 이름입니다.
   • NUMBER_OF_WORKER_NODES: 노드 풀에서 프로비저닝할 워커 노드 수입니다.
   • TAINTS: 이 노드 풀의 노드에 적용할 테인트입니다. 이 필드는 선택 사항입니다.
   • LABELS: 이 노드 풀의 노드에 적용할 라벨입니다. 키-값 쌍 목록을 포함합니다. 이 필드는 선택사항입니다.
   • GPU_PARTITION_SCHEME: GPU 워크로드(예: mixed-2)를 실행하는 경우 GPU 파티셔닝 스킴입니다. 이 필드가 설정되지 않은 경우 GPU가 파티셔닝되지 않습니다. 사용 가능한 다중 인스턴스 GPU (MIG) 프로필은 지원되는 MIG 프로필을 참고하세요.
   참고: 클러스터 노드 풀을 만든 후에는 GPU 파티셔닝과 같은 노드 구성을 수정할 수 없습니다.

2. HA 전략을 위해 컨테이너 애플리케이션을 호스팅하려는 각 영역에 대해 이전 단계를 반복합니다.

부하 분산기 구성

여러 영역의 포드 간에 트래픽을 분산하려면 부하 분산기를 만드세요. 외부 부하 분산기 (ELB)와 내부 부하 분산기 (ILB)를 만들 수 있으며, 둘 다 영역별 또는 전역으로 구성할 수 있습니다. 이 예에서는 컨테이너 애플리케이션에 전역 ILB와 전역 ELB를 구성합니다.

전역 내부 부하 분산기 만들기

내부 부하 분산기 (ILB)는 조직에 할당된 내부 IP 주소 풀에서 조직 내 서비스를 노출합니다. ILB 서비스는 조직 외부의 엔드포인트에서 액세스할 수 없습니다.

컨테이너 워크로드용 전역 ILB를 만들려면 다음 단계를 완료하세요.

gdcloud

gdcloud CLI를 사용하여 포드 워크로드를 타겟팅하는 ILB를 만듭니다.

이 ILB는 Backend 객체에 정의된 라벨과 일치하는 프로젝트의 모든 워크로드를 타겟팅합니다. Backend 커스텀 리소스는 영역으로 범위가 지정되어야 합니다.

gdcloud CLI를 사용하여 ILB를 만들려면 다음 단계를 따르세요.

1. 포드가 실행되는 각 영역에 영역별 Backend 리소스를 만들어 ILB의 엔드포인트를 정의합니다.

   gdcloud compute backends create BACKEND_NAME \
       --labels=LABELS \
       --project=PROJECT \
       --cluster=CLUSTER_NAME \
       --zone=ZONE
   

   다음을 바꿉니다.

   • BACKEND_NAME: 선택한 백엔드 리소스의 이름입니다(예: my-backend).
   • LABELS: 이 백엔드 리소스에 사용할 포드 간 엔드포인트를 정의하는 선택기입니다(예: app=web).
   • PROJECT: 프로젝트의 이름
   • CLUSTER_NAME: 정의된 선택기의 범위가 제한되는 Kubernetes 클러스터입니다. 이 필드를 지정하지 않으면 지정된 라벨이 있는 모든 엔드포인트가 선택됩니다. 이 필드는 선택사항입니다.
   • ZONE: 이 호출에 사용할 영역입니다. 영역 플래그가 필요한 모든 명령어에 대해 영역 플래그를 미리 설정하려면 gdcloud config set core/zone ZONE를 실행하세요. 영역 플래그는 멀티 영역 환경에서만 사용할 수 있습니다. 이 필드는 선택사항입니다.

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

2. 전역 BackendService 리소스를 만듭니다.

   gdcloud compute backend-services create BACKEND_SERVICE_NAME \
       --project=PROJECT \
       --target-ports=TARGET_PORTS \
       --global
   

   다음을 바꿉니다.

   • BACKEND_SERVICE_NAME: 백엔드 서비스의 이름입니다.
   • PROJECT: 프로젝트의 이름
   • TARGET_PORTS: 이 백엔드 서비스가 변환하는 대상 포트의 쉼표로 구분된 목록입니다. 각 대상 포트는 프로토콜, 전달 규칙의 포트, 백엔드 인스턴스의 포트를 지정합니다. 타겟 포트를 여러 개 지정할 수 있습니다. 이 필드는 TCP:80:8080과 같은 protocol:port:targetport 형식이어야 합니다. 이 필드는 선택사항입니다.

3. 각 영역에서 이전에 만든 Backend 리소스에 BackendService 리소스를 추가합니다.

   gdcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
       --backend-zone=ZONE \
       --backend=BACKEND_NAME \
       --project=PROJECT \
       --global
   

   다음을 바꿉니다.

   • BACKEND_SERVICE_NAME: 전역 백엔드 서비스의 이름입니다.
   • ZONE: 백엔드의 영역입니다.
   • BACKEND_NAME: 영역 백엔드의 이름입니다.
   • PROJECT: 프로젝트의 이름

   이전 단계에서 만든 각 영역 백엔드에 대해 이 단계를 완료합니다.

4. 서비스가 제공되는 가상 IP 주소 (VIP)를 정의하는 내부 ForwardingRule 리소스를 만듭니다.

   gdcloud compute forwarding-rules create FORWARDING_RULE_INTERNAL_NAME \
       --backend-service=BACKEND_SERVICE_NAME \
       --cidr=CIDR \
       --ip-protocol-port=PROTOCOL_PORT \
       --load-balancing-scheme=INTERNAL \
       --project=PROJECT \
       --global
   

   다음을 바꿉니다.

   • FORWARDING_RULE_INTERNAL_NAME: 전달 규칙의 이름입니다.
   • CIDR: 전달 규칙에 사용할 CIDR입니다. 이 필드는 선택사항입니다. 지정하지 않으면 IPv4/32 CIDR이 전역 IP 주소 풀에서 자동으로 예약됩니다. 이 전달 규칙과 동일한 네임스페이스에 있는 Subnet 리소스의 이름을 지정합니다. Subnet 리소스는 전역 서브넷의 요청 및 할당 정보를 나타냅니다. Subnet 리소스에 관한 자세한 내용은 서브넷 관리를 참고하세요.
   • PROTOCOL_PORT: 전달 규칙에서 노출할 프로토콜 및 포트입니다. 이 필드는 ip-protocol=TCP:80 형식이어야 합니다. 노출된 포트는 실제 애플리케이션이 컨테이너 내에서 노출하는 포트와 동일해야 합니다.

5. 구성된 ILB를 검증하려면 생성된 각 객체에서 Ready 조건을 확인합니다. VIP에 대한 curl 요청으로 트래픽을 확인합니다.

   1. 할당된 VIP를 가져오려면 전달 규칙을 설명하세요.

      gdcloud compute forwarding-rules describe FORWARDING_RULE_INTERNAL_NAME --global
      

   2. 전달 규칙의 필드에 지정된 포트에서 VIP로 curl 요청을 사용하여 트래픽을 확인합니다.

      curl http://FORWARDING_RULE_VIP:PORT
      

   다음을 바꿉니다.

   • FORWARDING_RULE_VIP: 전달 규칙의 VIP입니다.
   • PORT: 전달 규칙의 포트 번호입니다.

API

KRM API를 사용하여 컨테이너 워크로드를 타겟팅하는 ILB를 만듭니다. 이 ILB는 Backend 객체에 정의된 라벨과 일치하는 프로젝트의 모든 워크로드를 타겟팅합니다. KRM API를 사용하여 전역 ILB를 만들려면 다음 단계를 따르세요.

1. ILB의 엔드포인트를 정의하는 Backend 리소스를 만듭니다. 컨테이너 워크로드가 배치된 각 영역에 대해 Backend 리소스를 만듭니다.

   kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
   apiVersion: networking.gdc.goog/v1
   kind: Backend
   metadata:
     namespace: PROJECT
     name: BACKEND_NAME
   spec:
     clusterName: CLUSTER_NAME
     endpointsLabels:
       matchLabels:
         app: APP_NAME
   EOF
   

   다음을 바꿉니다.

   • MANAGEMENT_API_SERVER: 영역 관리 API 서버의 kubeconfig 경로입니다. 자세한 내용은 영역 컨텍스트로 전환을 참고하세요.
   • PROJECT: 프로젝트의 이름
   • BACKEND_NAME: Backend 리소스의 이름입니다.
   • CLUSTER_NAME: 정의된 선택기의 범위가 제한되는 Kubernetes 클러스터입니다. 이 필드를 지정하지 않으면 지정된 라벨이 있는 모든 엔드포인트가 선택됩니다. 이 필드는 선택사항입니다.
   • APP_NAME: 컨테이너 애플리케이션의 이름입니다.

   각 영역에 동일한 Backend 리소스를 사용하거나 각 영역에 다른 라벨 집합이 있는 Backend 리소스를 만들 수 있습니다.

2. 이전에 만든 Backend 리소스를 사용하여 BackendService 객체를 만듭니다. HealthCheck 리소스를 포함해야 합니다.

   kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
   apiVersion: networking.global.gdc.goog/v1
   kind: BackendService
   metadata:
     namespace: PROJECT
     name: BACKEND_SERVICE_NAME
   spec:
     backendRefs:
     - name: BACKEND_NAME
       zone: ZONE
     healthCheckName: HEALTH_CHECK_NAME
     targetPorts:
     - port: PORT
       protocol: PROTOCOL
       targetPort: TARGET_PORT
   EOF
   

   다음을 바꿉니다.

   • GLOBAL_API_SERVER: 전역 API 서버의 kubeconfig 경로입니다.
   • PROJECT: 프로젝트의 이름
   • BACKEND_SERVICE_NAME: BackendService 리소스에 선택한 이름입니다.
   • HEALTH_CHECK_NAME: 이전에 만든 HealthCheck 리소스의 이름입니다.
   • BACKEND_NAME: 영역 Backend 리소스의 이름입니다.

   • ZONE: Backend 리소스가 있는 영역입니다. backendRefs 필드에 백엔드를 여러 개 지정할 수 있습니다. 예를 들면 다음과 같습니다.

     - name: my-backend-1
       zone: us-east1-a
     - name: my-backend-2
       zone: us-east1-b
     

     targetPorts 필드는 선택사항입니다. 이 리소스는 이 BackendService 리소스가 변환하는 포트를 나열합니다. 이 객체를 사용하는 경우 다음 값을 제공하세요.

   • PORT: 서비스에서 노출하는 포트입니다.

   • PROTOCOL: 트래픽이 일치해야 하는 레이어 4 프로토콜입니다. TCP와 UDP만 지원됩니다.

   • TARGET_PORT: 값이 변환되는 포트입니다(예: 8080). 값은 지정된 객체에서 반복될 수 없습니다.

     targetPorts의 예는 다음과 같습니다.

     targetPorts:
       - port: 80
         protocol: TCP
         targetPort: 8080
     

3. 서비스가 제공되는 가상 IP 주소 (VIP)를 정의하는 내부 ForwardingRule 리소스를 만듭니다.

   kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
   apiVersion: networking.global.gdc.goog/v1
   kind: ForwardingRuleInternal
   metadata:
     namespace: PROJECT
     name: FORWARDING_RULE_INTERNAL_NAME
   spec:
     cidrRef: CIDR
     ports:
     - port: PORT
       protocol: PROTOCOL
     backendServiceRef:
       name: BACKEND_SERVICE_NAME
   EOF
   

   다음을 바꿉니다.

   • GLOBAL_API_SERVER: 전역 API 서버의 kubeconfig 경로입니다.
   • PROJECT: 프로젝트의 이름
   • FORWARDING_RULE_INTERNAL_NAME: ForwardingRuleInternal 리소스에 선택한 이름입니다.
   • CIDR: 전달 규칙에 사용할 CIDR입니다. 이 필드는 선택사항입니다. 지정하지 않으면 IPv4/32 CIDR이 전역 IP 주소 풀에서 자동으로 예약됩니다. 이 전달 규칙과 동일한 네임스페이스에 있는 Subnet 리소스의 이름을 지정합니다. Subnet 리소스는 전역 서브넷의 요청 및 할당 정보를 나타냅니다. Subnet 리소스에 관한 자세한 내용은 서브넷 관리를 참고하세요.
   • PORT: 전달 규칙에서 노출할 포트입니다. ports 필드를 사용하여 이 전달 규칙으로 구성된 백엔드로 패킷이 전달되는 L4 포트 배열을 지정합니다. 포트를 하나 이상 지정해야 합니다. port 필드를 사용하여 포트 번호를 지정합니다. 노출된 포트는 실제 애플리케이션이 컨테이너 내에서 노출하는 포트와 동일해야 합니다.

   • PROTOCOL: 전달 규칙에 사용할 프로토콜입니다(예: TCP). ports 배열의 항목은 다음과 같이 표시되어야 합니다.

     ports:
     - port: 80
       protocol: TCP
     

4. 구성된 ILB를 검증하려면 생성된 각 객체에서 Ready 조건을 확인합니다. VIP에 대한 curl 요청으로 트래픽을 확인합니다.

   1. VIP를 검색합니다.

      kubectl get forwardingruleinternal -n PROJECT
      

      출력은 다음과 같이 표시됩니다.

      NAME           BACKENDSERVICE                  CIDR              READY
      ilb-name       BACKEND_SERVICE_NAME            192.0.2.0/32      True
      

   2. 전달 규칙의 필드에 지정된 포트에서 VIP에 curl 요청을 전송하여 트래픽을 테스트합니다.

      curl http://FORWARDING_RULE_VIP:PORT
      

      다음을 바꿉니다.

      • FORWARDING_RULE_VIP: 전달 규칙의 VIP입니다.
      • PORT: 전달 규칙의 필드 포트 번호입니다.

전역 외부 부하 분산기 만들기

외부 부하 분산기 (ELB)는 더 큰 인스턴스 외부 IP 주소 풀에서 조직에 할당된 풀의 IP 주소에서 조직 외부에서 액세스할 수 있도록 서비스를 노출합니다.

컨테이너 워크로드의 전역 ELB를 만들려면 다음 단계를 완료하세요.

gdcloud

gdcloud CLI를 사용하여 Backend 객체에 정의된 라벨과 일치하는 프로젝트의 모든 워크로드를 타겟팅하는 전역 ELB를 만듭니다. Backend 커스텀 리소스는 영역으로 범위가 지정되어야 합니다.

1. ELB 서비스가 작동하려면 이 ELB 서비스의 워크로드로 트래픽을 허용하도록 정책에서 맞춤 ProjectNetworkPolicy 데이터 전송을 구성하고 적용해야 합니다. 네트워크 정책은 부하 분산기 자체가 아닌 워크로드에 대한 액세스를 제어합니다. ELB는 워크로드를 고객 네트워크에 노출하므로 외부 트래픽이 워크로드 포트(예: 8080)로 이동하도록 허용하는 명시적 네트워크 정책이 필요합니다.

   이 ELB의 워크로드로 트래픽을 허용할 외부 CIDR 주소를 지정합니다.

   kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
   apiVersion: networking.global.gdc.goog/v1
   kind: ProjectNetworkPolicy
   metadata:
     namespace: PROJECT
     name: allow-inbound-traffic-from-external
   spec:
     policyType: Ingress
     subject:
       subjectType: UserWorkload
     ingress:
     - from:
       - ipBlock:
           cidr: CIDR
       ports:
       - protocol: TCP
         port: PORT
   EOF
   

   다음을 바꿉니다.

   • GLOBAL_API_SERVER: 전역 API 서버의 kubeconfig 경로입니다. 글로벌 API 서버의 kubeconfig 파일을 아직 생성하지 않은 경우 kubeconfig 파일 수동 생성을 참고하세요.
   • PROJECT: 프로젝트의 이름
   • CIDR: ELB에 액세스해야 하는 외부 CIDR입니다. 이 정책은 외부 부하 분산기가 소스 외부 IP 주소를 유지하고 반환 경로에서 부하 분산기를 우회하는 직접 서버 반환 (DSR)을 사용하므로 필요합니다. 자세한 내용은 조직 간 트래픽을 위한 전역 수신 방화벽 규칙 만들기를 참고하세요.
   • PORT: 부하 분산기 뒤에 있는 포드의 백엔드 포트입니다. 이 값은 Service 리소스의 매니페스트에 있는 .spec.ports[].targetPortfield 필드에서 찾을 수 있습니다. 이 필드는 선택사항입니다.

   이 구성은 프로젝트 내부의 모든 리소스에 지정된 CIDR 범위에 대한 액세스 권한을 제공합니다.

   참고: gdcloud CLI는 전역 프로젝트 네트워크 정책을 만드는 명령어를 지원하지 않으므로 KRM API를 대신 사용해야 합니다.

2. 각 영역에서 Backend 리소스를 만들어 ELB의 엔드포인트를 정의합니다.

   gdcloud compute backends create BACKEND_NAME \
     --labels=LABELS \
     --project=PROJECT \
     --cluster=CLUSTER_NAME \
     --zone=ZONE
   

   다음을 바꿉니다.

   • BACKEND_NAME: 백엔드 리소스의 이름입니다(예: my-backend).
   • LABELS: 이 백엔드 리소스에 사용할 포드 간 엔드포인트를 정의하는 선택기입니다(예: app=web).
   • PROJECT: 프로젝트의 이름
   • CLUSTER_NAME: 정의된 선택기의 범위가 제한되는 Kubernetes 클러스터입니다. 이 필드를 지정하지 않으면 지정된 라벨이 있는 모든 엔드포인트가 선택됩니다. 이 필드는 선택사항입니다.
   • ZONE: 이 호출에 사용할 영역입니다. 영역 플래그가 필요한 모든 명령어에 대해 영역 플래그를 미리 설정하려면 gdcloud config set core/zone ZONE를 실행하세요. 영역 플래그는 멀티 영역 환경에서만 사용할 수 있습니다. 이 필드는 선택사항입니다.

   각 영역에 동일한 Backend 리소스를 사용하거나 각 영역에 다른 라벨 집합이 있는 Backend 리소스를 만들 수 있습니다.

3. 전역 BackendService 리소스를 만듭니다.

   gdcloud compute backend-services create BACKEND_SERVICE_NAME \
     --project=PROJECT \
     --target-ports=TARGET_PORTS \
     --health-check=HEALTH_CHECK_NAME \
     --global
   

   다음을 바꿉니다.

   • BACKEND_SERVICE_NAME: 이 백엔드 서비스에 선택한 이름입니다.
   • PROJECT: 프로젝트의 이름
   • TARGET_PORTS: 이 백엔드 서비스가 변환하는 대상 포트의 쉼표로 구분된 목록입니다. 각 대상 포트는 프로토콜, 전달 규칙의 포트, 백엔드 인스턴스의 포트를 지정합니다. 타겟 포트를 여러 개 지정할 수 있습니다. 이 필드는 TCP:80:8080과 같은 protocol:port:targetport 형식이어야 합니다. 이 필드는 선택사항입니다.
   • HEALTH_CHECK_NAME: 상태 점검 리소스의 이름입니다. 이 필드는 선택사항입니다.

4. 이전에 만든 영역 Backend 리소스에 전역 BackendService 리소스를 추가합니다.

   gdcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
     --backend=BACKEND_NAME \
     --backend-zone=ZONE \
     --project=PROJECT \
     --global
   

   이전 단계에서 만든 각 영역 백엔드에 대해 이 단계를 완료합니다.

5. 서비스가 제공되는 VIP를 정의하는 외부 ForwardingRule 리소스를 만듭니다.

   gdcloud compute forwarding-rules create FORWARDING_RULE_EXTERNAL_NAME \
     --backend-service=BACKEND_SERVICE_NAME \
     --cidr=CIDR \
     --ip-protocol-port=PROTOCOL_PORT \
     --load-balancing-scheme=EXTERNAL \
     --project=PROJECT \
     --global
   

   다음을 바꿉니다.

   • FORWARDING_RULE_EXTERNAL_NAME: 전달 규칙의 이름입니다.
   • CIDR: 전달 규칙에 사용할 CIDR입니다. 이 필드는 선택사항입니다. 지정하지 않으면 IPv4/32 CIDR이 전역 IP 주소 풀에서 자동으로 예약됩니다. 이 전달 규칙과 동일한 네임스페이스에 있는 Subnet 리소스의 이름을 지정합니다. Subnet 리소스는 전역 서브넷의 요청 및 할당 정보를 나타냅니다. Subnet 리소스에 관한 자세한 내용은 서브넷 관리를 참고하세요.
   • PROTOCOL_PORT: 전달 규칙에서 노출할 프로토콜 및 포트입니다. 이 필드는 ip-protocol=TCP:80 형식이어야 합니다. 노출된 포트는 실제 애플리케이션이 컨테이너 내에서 노출하는 포트와 동일해야 합니다.
   • PROJECT: 프로젝트의 이름

6. 구성된 ELB를 검증하려면 생성된 각 객체에서 Ready 조건을 확인합니다. VIP에 대한 curl 요청으로 트래픽을 확인합니다.

   1. 할당된 VIP를 가져오려면 전달 규칙을 설명하세요.

      gdcloud compute forwarding-rules describe FORWARDING_RULE_EXTERNAL_NAME
      

   2. 전달 규칙의 PROTOCOL_PORT 필드에 지정된 포트에서 VIP에 대한 curl 요청으로 트래픽을 확인합니다.

      curl http://FORWARDING_RULE_VIP:PORT
      

      다음을 바꿉니다.

      • FORWARDING_RULE_VIP: 전달 규칙의 VIP입니다.
      • PORT: 전달 규칙의 PROTOCOL_PORT 필드에 있는 포트 번호입니다.

API

KRM API를 사용하여 포드 워크로드를 타겟팅하는 ELB를 만듭니다. 이 ELB는 Backend 객체에 정의된 라벨과 일치하는 프로젝트의 모든 워크로드를 타겟팅합니다. KRM API를 사용하여 영역 ELB를 만들려면 다음 단계를 따르세요.

1. ELB 서비스가 작동하려면 이 ELB 서비스의 워크로드로 트래픽을 허용하도록 정책에서 맞춤 ProjectNetworkPolicy 데이터 전송을 구성하고 적용해야 합니다. 네트워크 정책은 부하 분산기 자체가 아닌 워크로드에 대한 액세스를 제어합니다. ELB는 워크로드를 고객 네트워크에 노출하므로 외부 트래픽이 워크로드 포트(예: 8080)로 이동하도록 허용하는 명시적 네트워크 정책이 필요합니다.

   이 ELB의 워크로드로 트래픽을 허용할 외부 CIDR 주소를 지정합니다.

   kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
   apiVersion: networking.global.gdc.goog/v1
   kind: ProjectNetworkPolicy
   metadata:
     namespace: PROJECT
     name: allow-inbound-traffic-from-external
   spec:
     policyType: Ingress
     subject:
       subjectType: UserWorkload
     ingress:
     - from:
       - ipBlock:
           cidr: CIDR
       ports:
       - protocol: TCP
         port: PORT
   EOF
   

   다음을 바꿉니다.

   • GLOBAL_API_SERVER: 전역 API 서버의 kubeconfig 경로입니다. 글로벌 API 서버의 kubeconfig 파일을 아직 생성하지 않은 경우 kubeconfig 파일 수동 생성을 참고하세요.
   • PROJECT: 프로젝트의 이름
   • CIDR: ELB에 액세스해야 하는 외부 CIDR입니다. 이 정책은 외부 부하 분산기가 소스 외부 IP 주소를 유지하고 반환 경로에서 부하 분산기를 우회하는 직접 서버 반환 (DSR)을 사용하므로 필요합니다. 자세한 내용은 조직 간 트래픽을 위한 전역 수신 방화벽 규칙 만들기를 참고하세요.
   • PORT: 부하 분산기 뒤에 있는 포드의 백엔드 포트입니다. 이 값은 Service 리소스의 매니페스트에 있는 .spec.ports[].targetPortfield 필드에서 찾을 수 있습니다. 이 필드는 선택사항입니다.
   참고: 이 구성은 프로젝트 내의 모든 리소스에 지정된 CIDR 범위에 대한 액세스 권한을 제공합니다.

2. ELB의 엔드포인트를 정의하는 Backend 리소스를 만듭니다. 워크로드가 배치된 각 영역에 대해 Backend 리소스를 만듭니다.

   kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
   apiVersion: networking.gdc.goog/v1
   kind: Backend
   metadata:
     namespace: PROJECT
     name: BACKEND_NAME
   spec:
     clusterName: CLUSTER_NAME
     endpointsLabels:
       matchLabels:
         app: APP_NAME
   EOF
   

   다음을 바꿉니다.

   • MANAGEMENT_API_SERVER: 영역 관리 API 서버의 kubeconfig 경로입니다. 타겟 영역의 API 서버에 대한 kubeconfig 파일을 아직 생성하지 않은 경우 kubeconfig 파일 수동 생성을 참고하세요.
   • PROJECT: 프로젝트의 이름
   • BACKEND_NAME: Backend 리소스 이름입니다.
   • CLUSTER_NAME: 정의된 선택기의 범위가 제한되는 Kubernetes 클러스터입니다. 이 필드를 지정하지 않으면 지정된 라벨이 있는 모든 엔드포인트가 선택됩니다. 이 필드는 선택사항입니다.
   • APP_NAME: 컨테이너 애플리케이션의 이름입니다.

   각 영역에 동일한 Backend 리소스를 사용하거나 각 영역에 다른 라벨 집합이 있는 Backend 리소스를 만들 수 있습니다.

3. 이전에 만든 Backend 리소스를 사용하여 BackendService 객체를 만듭니다.

   kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
   apiVersion: networking.global.gdc.goog/v1
   kind: BackendService
   metadata:
     namespace: PROJECT
     name: BACKEND_SERVICE_NAME
   spec:
     backendRefs:
     - name: BACKEND_NAME
       zone: ZONE
     healthCheckName: HEALTH_CHECK_NAME
   EOF
   

   다음을 바꿉니다.

   • BACKEND_SERVICE_NAME: BackendService 리소스에 선택한 이름입니다.
   • HEALTH_CHECK_NAME: 이전에 만든 HealthCheck 리소스의 이름입니다. 포드 워크로드에 대해 ELB를 구성하는 경우 이 필드를 포함하지 마세요.
   • ZONE: Backend 리소스가 있는 영역입니다. backendRefs 필드에 백엔드를 여러 개 지정할 수 있습니다. 예를 들면 다음과 같습니다.

   - name: my-backend-1
     zone: us-east1-a
   - name: my-backend-2
     zone: us-east1-b
   

4. 서비스가 제공되는 VIP를 정의하는 외부 ForwardingRule 리소스를 만듭니다.

   kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
   apiVersion: networking.global.gdc.goog/v1
   kind: ForwardingRuleExternal
   metadata:
     namespace: PROJECT
     name: FORWARDING_RULE_EXTERNAL_NAME
   spec:
     cidrRef: CIDR
     ports:
     - port: PORT
       protocol: PROTOCOL
     backendServiceRef:
       name: BACKEND_SERVICE_NAME
   EOF
   

   다음을 바꿉니다.

   • FORWARDING_RULE_EXTERNAL_NAME: ForwardingRuleExternal 리소스에 선택한 이름입니다.
   • CIDR: 전달 규칙에 사용할 CIDR입니다. 이 필드는 선택사항입니다. 지정하지 않으면 IPv4/32 CIDR이 전역 IP 주소 풀에서 자동으로 예약됩니다. 이 전달 규칙과 동일한 네임스페이스에 있는 Subnet 리소스의 이름을 지정합니다. Subnet 리소스는 전역 서브넷의 요청 및 할당 정보를 나타냅니다. Subnet 리소스에 관한 자세한 내용은 서브넷 관리를 참고하세요.
   • PORT: 전달 규칙에서 노출할 포트입니다. ports 필드를 사용하여 이 전달 규칙으로 구성된 백엔드로 패킷이 전달되는 L4 포트 배열을 지정합니다. 포트를 하나 이상 지정해야 합니다. port 필드를 사용하여 포트 번호를 지정합니다. 노출된 포트는 실제 애플리케이션이 컨테이너 내에서 노출하는 포트와 동일해야 합니다.
   • PROTOCOL: 전달 규칙에 사용할 프로토콜입니다(예: TCP). ports 배열의 항목은 다음과 같이 표시되어야 합니다.

   ports:
   - port: 80
     protocol: TCP
   

5. 구성된 ELB를 검증하려면 생성된 각 객체에서 Ready 조건을 확인합니다. curl 요청을 VIP에 전송하여 트래픽을 테스트해 보세요.

   1. 프로젝트의 VIP를 가져옵니다.

      kubectl get forwardingruleexternal -n PROJECT
      

      출력은 다음과 같이 표시됩니다.

      NAME           BACKENDSERVICE                  CIDR              READY
      elb-name       BACKEND_SERVICE_NAME            192.0.2.0/32      True
      

   2. 전달 규칙의 PORT 필드에 지정된 포트에서 VIP로 curl 요청을 보내 트래픽을 확인합니다.

      curl http://FORWARDING_RULE_VIP:PORT
      

      FORWARDING_RULE_VIP:PORT를 전달 규칙의 VIP 및 포트(예: 192.0.2.0:80)로 바꿉니다.

각 영역 클러스터에 컨테이너 워크로드 배포

컨테이너 워크로드는 전역 리소스가 아니므로 각 컨테이너 애플리케이션을 영역 Kubernetes 클러스터에 별도로 배포해야 합니다.

1. Kubernetes 클러스터를 호스팅하는 영역에 로그인합니다.

   gdcloud config set core/zone ZONE
   

2. 관리형 Harbor 레지스트리에서 컨테이너 이미지를 사용할 수 있는지 확인합니다. 자세한 내용은 컨테이너 앱 배포 튜토리얼을 참고하세요.

3. 컨테이너 워크로드의 매니페스트 파일을 만들고 영역 Kubernetes 클러스터에 배포합니다.

   kubectl --kubeconfig KUBERNETES_CLUSTER -n PROJECT \
       apply -f - <<EOF
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: DEPLOYMENT_NAME
   spec:
     replicas: NUMBER_OF_REPLICAS
     selector:
       matchLabels:
         run: APP_NAME
     template:
       metadata:
         labels:
           run: APP_NAME
       spec:
         containers:
         - name: CONTAINER_NAME
           image: HARBOR_INSTANCE_URL/HARBOR_PROJECT_NAME/IMAGE:TAG
   EOF
   

   다음을 바꿉니다.

   • KUBERNETES_CLUSTER: 컨테이너 워크로드를 배포할 영역 Kubernetes 클러스터의 kubeconfig 파일입니다. 영역 Kubernetes 클러스터의 kubeconfig 파일을 아직 생성하지 않은 경우 kubeconfig 파일 수동 생성에서 자세한 내용을 확인하세요.
   • PROJECT: 컨테이너 워크로드를 배포할 프로젝트 네임스페이스입니다.
   • DEPLOYMENT_NAME: 컨테이너 배포의 이름입니다.
   • NUMBER_OF_REPLICAS: 배포에서 관리하는 복제된 Pod 객체 수입니다.
   • APP_NAME: 배포 내에서 실행할 애플리케이션의 이름입니다.
   • CONTAINER_NAME: 컨테이너의 이름입니다.
   • HARBOR_INSTANCE_URL: Harbor 인스턴스의 URL입니다(예: harbor-1.org-1.zone1.google.gdc.test.). Harbor 인스턴스의 URL을 가져오려면 Harbor 레지스트리 인스턴스 보기를 참고하세요.
   • HARBOR_PROJECT_NAME: Harbor 프로젝트의 이름입니다(예: my-project).
   • IMAGE: 이미지 이름입니다(예: nginx).
   • TAG: 가져올 이미지 버전의 태그입니다(예: 1.0).

4. GDC 유니버스의 각 영역에 대해 이전 단계를 반복합니다. 컨테이너 애플리케이션이 HA 전략에 원하는 모든 영역에 있는지 확인합니다.

Kubernetes를 사용하여 컨테이너 애플리케이션 노출

GDC 유니버스의 다른 리소스에서 액세스할 수 있도록 컨테이너 애플리케이션을 노출해야 합니다.

1. type: LoadBalancer의 Service 리소스를 만듭니다. 이 리소스는 네트워크를 통해 애플리케이션의 포드를 노출합니다.

   kubectl --kubeconfig KUBERNETES_CLUSTER -n PROJECT \
   apiVersion: v1
   kind: Service
   metadata:
     name: SERVICE_NAME
   spec:
     selector:
       app: APP_NAME
     ports:
       - port: 80
         protocol: TCP
     type: LoadBalancer
   EOF
   

   다음을 바꿉니다.

   • KUBERNETES_CLUSTER: 컨테이너 워크로드를 배포할 영역 Kubernetes 클러스터의 kubeconfig 파일입니다.
   • PROJECT: 컨테이너 워크로드가 있는 프로젝트 네임스페이스입니다.
   • SERVICE_NAME: 부하 분산기 서비스의 이름입니다.
   • APP_NAME: 컨테이너 애플리케이션에 적용한 라벨입니다.

2. 모든 네트워크 트래픽을 기본 네임스페이스로 허용하는 NetworkPolicy 커스텀 리소스를 만듭니다.

   kubectl --kubeconfig KUBERNETES_CLUSTER -n PROJECT \
   apiVersion: networking.k8s.io/v1
   kind: NetworkPolicy
   metadata:
     annotations:
     name: allow-all
   spec:
     ingress:
     - from:
       - ipBlock:
           cidr: 0.0.0.0/0
     podSelector: {}
     policyTypes:
     - Ingress
   EOF
   

포드용 영구 스토리지 프로비저닝

애플리케이션 포드에 영구 스토리지를 제공하려면 PersistentVolumeClaim 리소스 (PVC)를 만들어야 합니다.

다음 안내에서는 GDC standard-rwo StorageClass를 사용하여 볼륨을 만드는 방법을 보여줍니다.

1. PersistentVolumeClaim 리소스를 만듭니다. 예를 들어 ReadWriteOnce 액세스 모드와 standard-rwo 스토리지 클래스로 구성합니다.

   kubectl --kubeconfig KUBERNETES_CLUSTER \
       --namespace PROJECT apply -f - <<EOF
   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: PVC_NAME
   spec:
     accessModes:
       - ReadWriteOnce
     resources:
       requests:
         storage: 10Gi
     storageClassName: standard-rwo
   EOF
   

   다음을 바꿉니다.

   • KUBERNETES_CLUSTER: Kubernetes 클러스터의 kubeconfig 파일입니다.
   • PROJECT: PVC를 만들 프로젝트 네임스페이스입니다.
   • PVC_NAME: PersistentVolumeClaim 객체의 이름입니다.

2. PersistentVolume (PV) 객체는 동적으로 프로비저닝됩니다. Kubernetes 클러스터에서 새 PV의 상태를 확인합니다.

   kubectl get pv --kubeconfig KUBERNETES_CLUSTER
   

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

   NAME       CAPACITY   ACCESS MODES   STATUS      CLAIM     STORAGECLASS   AGE
   pvc-uuidd  10Gi       RWO            Bound       pvc-name  standard-rwo   60s
   

3. PVC를 사용하도록 컨테이너 워크로드를 구성합니다. 다음은 standard-rwo PVC를 사용하는 포드 매니페스트의 예입니다.

   kubectl --kubeconfig KUBERNETES_CLUSTER \
       --namespace PROJECT apply -f - <<EOF
   apiVersion: apps/v1
   kind: Pod
   metadata:
     name: web-server-deployment
     labels:
       app: APP_LABEL
   spec:
     containers:
     - name: CONTAINER_NAME
       image: HARBOR_INSTANCE_URL/HARBOR_PROJECT_NAME/IMAGE:TAG
       volumeMounts:
       - mountPath: MOUNT_PATH
         name: data
     volumes:
     - name: data
       persistentVolumeClaim:
         claimName: PVC_NAME
   EOF
   

   다음을 바꿉니다.

   • KUBERNETES_CLUSTER: 컨테이너 워크로드를 배포할 Kubernetes 클러스터의 kubeconfig 파일입니다.
   • PROJECT: PVC가 상주하는 프로젝트 네임스페이스입니다.
   • APP_LABEL: 컨테이너 애플리케이션에 적용한 라벨입니다.
   • CONTAINER_NAME: 컨테이너의 이름입니다.
   • HARBOR_INSTANCE_URL: Harbor 인스턴스의 URL입니다(예: harbor-1.org-1.zone1.google.gdc.test.). Harbor 인스턴스의 URL을 가져오려면 Harbor 레지스트리 인스턴스 보기를 참고하세요.
   • HARBOR_PROJECT_NAME: Harbor 프로젝트의 이름입니다(예: my-project).
   • IMAGE: 이미지 이름입니다(예: nginx).
   • TAG: 가져오려는 이미지 버전의 태그입니다(예: 1.0).
   • MOUNT_PATH: 볼륨을 마운트할 포드 내부의 경로입니다.
   • PVC_NAME: 생성한 PVC입니다.

비동기 스토리지 복제 구성

GDC 멀티 영역 유니버스는 재해 복구 시나리오를 위해 비동기 모드에서 볼륨 및 버킷과 같은 복제된 스토리지 리소스를 사용할 수 있습니다. 이러한 스토리지 리소스 옵션은 동일한 리전의 두 영역 간에 비동기 데이터 복제를 제공합니다. 비동기 복제는 백그라운드에서 발생하므로 재해 발생 시 복구 지점 목표 (RPO)가 낮지만 0은 아닙니다. 복제된 모든 데이터는 온라인 상태이며 즉시 액세스할 수 있지만 보조 영역에 쓰기를 사용 설정하려면 수동 장애 조치 절차가 필요할 수 있습니다.

컨테이너 애플리케이션에 다음 비동기 스토리지 복제 유형 중 하나를 선택할 수 있습니다.

• 비동기 객체 복제
• 비동기 블록 복제

객체 스토리지를 위한 이중 영역 버킷 만들기

객체 스토리지 데이터는 데이터가 두 영역 모두에 저장되는 단일 버킷에 기록됩니다. 데이터는 영역 간에 비동기식으로 복사되므로 특정 시점에 영역에 동일한 객체 버전이 포함되지 않을 수 있지만 추가 변경사항이 없으면 결국 동일해집니다. 볼륨 복제와 달리 복제된 버킷은 영역 파티션 중에 쓰기 가능합니다. 객체에 대한 각 쓰기는 다른 버전을 생성하며, 연결이 복원된 후에는 두 영역의 최신 버전이 최종 상태가 됩니다.

1. 인프라 운영자 (IO)가 객체 스토리지를 위한 영역 간 비동기 복제에 필요한 BucketLocationConfig 커스텀 리소스를 만들었는지 확인합니다. 이 리소스는 루트 전역 API 서버에 배포해야 합니다.

2. 이중 영역 Bucket 커스텀 리소스를 만듭니다.

   kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
   apiVersion: object.global.gdc.goog/v1
   kind: Bucket
   metadata:
     name: BUCKET_NAME
     namespace: PROJECT
   spec:
     location: LOCATION_NAME
     description: Sample DZ Bucket
     storageClass: Standard
   EOF
   

   다음을 바꿉니다.

   • GLOBAL_API_SERVER: 전역 API 서버의 kubeconfig 파일입니다.
   • BUCKET_NAME: 스토리지 버킷의 이름입니다.
   • PROJECT: 버킷이 있는 프로젝트의 이름입니다.
   • LOCATION_NAME: 버킷의 객체 데이터가 상주하는 물리적 위치입니다. 이는 기존 BucketLocation 리소스의 이름에 매핑되어야 합니다. 조직의 전역 API 서버에 사용 가능한 BucketLocation 리소스 목록을 쿼리하려면 kubectl --kubeconfig GLOBAL_API_SERVER bucketlocations을 실행합니다. BucketLocation 리소스가 없으면 IO에 문의하여 비동기 복제를 사용 설정했는지 확인하세요.

영역 간 비동기 블록 스토리지 복제 구성

복제된 블록 스토리지는 기본 볼륨과 보조 볼륨 간에 블록 동등성을 유지하는 비동기식으로 복제된 볼륨 (PV)을 제공합니다. 비동기적 특성으로 인해 보조 볼륨은 과거의 특정 시점의 기본 영역 상태를 반영합니다 (0이 아닌 RPO). 보조 볼륨은 복제의 타겟으로 남아 있는 동안 마운트할 수 없으므로 관계를 종료하고 쓰기가 발생하도록 수동으로 개입해야 합니다.

소스 영역 데이터를 사용할 수 없게 되는 경우 장애 조치에 사용할 수 있는 복제된 데이터를 만들려면 영역 간 스토리지 복제 관계를 구성해야 합니다. 이는 컨테이너 애플리케이션에 블록 스토리지를 사용하는 경우에 관련이 있습니다.

시작하기 전에 인프라 운영자 (IO)가 영역 간 블록 스토리지 복제를 허용하도록 StorageClusterPeering 및 StorageVirtualMachinePeering 커스텀 리소스를 만들고 구성했는지 확인합니다. 이 리소스는 루트 전역 API 서버에 배포해야 합니다.

1. VolumeReplicationRelationship 커스텀 리소스 YAML 파일을 만들고 전역 API 서버에 배포합니다.

   kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
   apiVersion: storage.global.gdc.goog/v1
   kind: VolumeReplicationRelationship
   metadata:
     name: PVC_REPL_NAME
     namespace: PROJECT
   spec:
     source:
       pvc:
         clusterRef: SOURCE_PVC_CLUSTER
         pvcRef: SOURCE_PVC
       zoneRef: SOURCE_ZONE
   destination:
       pvc:
         clusterRef: DEST_PVC_CLUSTER
       zoneRef: DEST_ZONE
   EOF
   

   다음을 바꿉니다.

   • GLOBAL_API_SERVER: 전역 API 서버의 kubeconfig 파일입니다.
   • PVC_REPL_NAME: 볼륨 복제 관계의 이름입니다.
   • PROJECT: 스토리지 인프라가 있는 프로젝트입니다.
   • SOURCE_PVC_CLUSTER: PVC가 호스팅되는 Kubernetes 클러스터입니다.
   • SOURCE_PVC: 복제할 소스 영역의 PVC입니다.
   • SOURCE_ZONE: PVC가 호스팅되는 소스 영역입니다.
   • DEST_PVC_CLUSTER: PVC를 복제할 대상 Kubernetes 클러스터입니다.
   • DEST_ZONE: PVC를 복제할 대상 영역입니다.

2. 소스 영역을 어떤 이유로든 사용할 수 없는 경우 대상 영역으로의 복제를 중지하는 대상 영역에 VolumeFailover 커스텀 리소스를 만듭니다.

   kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
   apiVersion: storage.gdc.goog/v1
   kind: VolumeFailover
   metadata:
     name: PVC_FAILOVER_NAME
     namespace: PROJECT
   spec:
     volumeReplicationRelationshipRef: PVC_REPL_NAME
   EOF
   

   다음을 바꿉니다.

   • MANAGEMENT_API_SERVER: 영역 관리 API 서버의 kubeconfig 파일입니다.
   • PVC_FAILOVER_NAME: PVC 장애 조치의 이름입니다.
   • PROJECT: 스토리지 인프라가 있는 프로젝트입니다.
   • PVC_REPL_NAME: 볼륨 복제 관계의 이름입니다.

다음 단계

• 고가용성을 위한 Kubernetes 워크로드
• GDC의 컨테이너 워크로드
• 다중 영역 개요