26. 다중 영역 부트스트랩

예상 소요 시간: 3시간

작동 가능 구성요소 소유자: MZ

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

26.1. 개요

다중 영역 부트스트래핑에는 루트 전역 컨트롤 플레인 설정이 포함됩니다. 유니버스에서 첫 번째 영역은 전역 컨트롤 플레인을 설정합니다. 추가 영역이 전역 컨트롤 플레인에 참여합니다. 전역 컨트롤 플레인에 가입하는 것은 컨트롤 플레인을 설정하는 것보다 더 복잡한 프로세스입니다. 유니버스의 전역 컨트롤 플레인과 새 영역 간에 신뢰가 설정되어야 하기 때문입니다. 전역 컨트롤 플레인에 참여할 때는 다음 두 영역이 관련됩니다.

• 앵커 영역: 이미 전역 컨트롤 플레인의 일부인 영역입니다. 이 영역은 GitLab 인스턴스가 유니버스의 전역 API에 코드형 인프라 (IaC) 변경사항을 적용하는 데 사용되는 영역이어야 합니다.
• 조인 영역: 전역 컨트롤 플레인에 조인하는 영역입니다.

다중 영역 초기화에서 우주의 첫 번째 영역을 부트스트랩했습니다. 이 영역은 다른 영역이 유니버스에 참여할 때 앵커 영역 역할을 합니다.

유니버스에 이미 전역 API가 있고 유니버스에 참여하는 영역을 부트스트랩하는 경우 다음 단계를 완료합니다.

26.2. 유니버스에 참여하는 영역에서 멀티 영역 부트스트랩

계속하기 전에 앵커 영역에서 다중 영역을 부트스트랩했는지 확인합니다.

26.2.1. IO 도구 컨테이너 시작

보안 및 감사 가능성을 위해 다중 영역 부트스트랩 프로세스는 Kubernetes에 액세스하는 개인 사용자 인증 정보 (관리자 Kubernetes 구성 아님)와 민감한 작업을 실행할 권한 부여 요청에 대한 복수 사용자 승인 체계를 위한 IaC를 사용하여 실행해야 합니다. 부트스트랩 작업을 실행하는 데 필요한 모든 도구는 IO 도구 컨테이너에 포함되어 있습니다. OIC 환경에서 컨테이너를 시작하는 방법은 IO 도구 컨테이너 설정 OOPS-P0065 프로세스를 참고하세요. 글로벌 컨트롤 플레인에 참여하는 영역은 두 영역과 상호작용하며, 그중 하나 (앵커 영역)는 0일차 조건에서 작동하지 않으므로 앵커 영역의 보안이 손상되지 않도록 프로덕션 수준 인증 및 승인 조치를 사용해야 합니다.

26.2.2. Gitlab 저장소 초기화

코드형 인프라 설정에 구성된 ID 제공업체 (IdP)의 사용자 인증 정보를 사용하여 OOPS-P0066 프로세스에 따라 GitLab 사용자 액세스를 관리합니다.

앵커 영역의 IaC 저장소를 클론합니다.

git clone https://iac.GLOBAL_DNS_DOMAIN/gdch/iac.git /tmp/iac

GLOBAL_DNS_DOMAIN을 유니버스의 DNS 도메인으로 바꿉니다.

메시지가 표시되면 사용자 이름과 비밀번호를 입력합니다.

26.2.3. 필요한 역할 추가

액세스 및 권한 상승 프로세스 IAM-R0005 런북의 안내에 따라 필요한 클러스터 역할 및 역할 바인딩을 만듭니다.

• 참여 영역의 root-admin 클러스터에 mz-bootstrap-joining-editor 클러스터 역할이 있는 클러스터 역할 바인딩을 추가합니다.
• 앵커 영역의 root-admin 클러스터에 mz-bootstrap-anchor-reader 클러스터 역할이 있는 클러스터 역할 바인딩을 추가합니다.
• 앵커 영역의 전역 API에서 mz-system 네임스페이스에 mz-bootstrap-viewer 역할이 있는 역할 바인딩을 추가합니다.

26.2.4. 토큰 요청 만들기

전역 제어 영역에 참여할 때 전역 API 부트스트랩 토큰을 사용하여 참여하는 영역과 앵커 영역 간에 연락이 설정됩니다. 토큰 요청은 앵커 영역의 전역 API에서 토큰을 요청하는 데 사용됩니다.

1. 병합 요청을 위한 새 브랜치를 만듭니다.

   cd /tmp/iac
   git checkout -b JOINING_ZONE_NAME-mz-token-request
   

   JOINING_ZONE_NAME을 섹션 끝에 있는 참고에 설명된 대로 고객 접수 설문지에서 파생된 영역 이름으로 바꿉니다.

2. 참여 영역에 로그인합니다. 자세한 내용은 gdcloud 명령줄 인터페이스를 참고하세요. 이는 다음 단계의 gdcloud 명령어가 조인 영역의 루트 관리자 클러스터와 상호작용하여 앵커 영역에서 조인 영역으로 부트스트랩 토큰을 안전하게 전송하기 위한 공개 키 암호화 키 쌍을 획득하기 때문에 필요합니다.

3. 토큰 요청 YAML 파일을 생성합니다.

   gdcloud system multi-zone create-token-request --cluster root --zone JOINING_ZONE_NAME --client-type api-join --namespace global-kube-system --output-file /tmp/iac/infrastructure/global/orgs/root/mz-token-request.yaml
   

4. kustomization.yaml 파일을 만들거나 업데이트합니다.

   1. 파일을 엽니다.

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

   2. 파일이 이미 있는 경우 resources 목록에 mz-token-request.yaml 항목을 추가합니다. 그렇지 않으면 전체 리소스 yaml을 추가합니다.

      참고: 서식이 지정된 텍스트를 붙여넣을 때 vim이 자동으로 서식을 지정하지 않도록 하려면 :set paste를 사용하세요.

      apiVersion: kustomize.config.k8s.io/v1beta1
      kind: Kustomization
      metadata:
        name: global-root-kustomization
      resources:
      - mz-token-request.yaml
      

   3. 파일을 저장하고 vim을 종료합니다.

5. 브랜치에 변경사항을 커밋합니다.

   참고: 변경사항을 커밋하려면 먼저 이름과 이메일 주소로 git을 구성해야 합니다.

   git add infrastructure
   git commit
   

6. 분기를 GitLab로 푸시합니다.

   git push
   

7. 변경사항을 main 브랜치에 병합합니다. 자세한 내용은 IAC-R0004 런북을 참고하세요.

26.2.5. 토큰 생성

다음 단계에 따라 참여하는 영역에서 부트스트랩 토큰을 만드세요.

1. 병합 요청을 위한 새 브랜치를 만듭니다.

   cd /tmp/iac
   git checkout main
   git pull --ff-only
   git checkout -b JOINING_ZONE_NAME-mz-token
   

2. 앵커 영역에 로그인합니다. 자세한 내용은 gdcloud 명령줄 인터페이스를 참고하세요. 이는 다음 단계의 gdcloud 명령어가 앵커 영역의 전역 API와 상호작용하여 부트스트랩 토큰을 만들고 암호화하기 때문에 필요합니다.

3. 토큰 YAML 파일을 생성합니다.

   gdcloud system multi-zone create-token --zone JOINING_ZONE_NAME --namespace global-kube-system --output-file /tmp/iac/infrastructure/zonal/zones/JOINING_ZONE_NAME/root-admin/mz-token.yaml
   

4. kustomization.yaml 파일을 만들거나 업데이트합니다.

   1. 파일을 엽니다.

      vim infrastructure/zonal/zones/JOINING_ZONE_NAME/root-admin/kustomization.yaml
      

   2. 파일이 이미 있는 경우 resources 목록에 mz-token.yaml 항목을 추가합니다. 그렇지 않으면 전체 리소스 YAML을 추가합니다.

      참고: 서식이 지정된 텍스트를 붙여넣을 때 vim이 자동으로 서식을 지정하지 않도록 하려면 :set paste를 사용하세요.

      apiVersion: kustomize.config.k8s.io/v1beta1
      kind: Kustomization
      metadata:
        name: root-admin-kustomization
      resources:
      - mz-token.yaml
      

   3. 파일을 저장하고 vim을 종료합니다.

5. 브랜치에 변경사항을 커밋합니다.

   참고: 변경사항을 커밋하려면 먼저 이름과 이메일 주소로 git을 구성해야 합니다.

   git add infrastructure
   git commit
   

6. 분기를 GitLab로 푸시합니다.

   git push
   

7. 변경사항을 main 브랜치에 병합합니다. 자세한 내용은 IAC-R0004 런북을 참고하세요.

26.2.6. 부트스트랩 리소스 만들기

참여 영역의 루트 관리자 클러스터에서 부트스트랩 리소스를 만들려면 다음 단계를 따르세요.

1. 병합 요청을 위한 새 브랜치를 만듭니다.

   cd /tmp/iac
   git checkout main
   git pull --ff-only
   git checkout -b JOINING_ZONE_NAME-mz-bootstrap
   

2. 앵커 영역에 로그인합니다. 자세한 내용은 gdcloud 명령줄 인터페이스를 참고하세요. 이는 가입 작업 중에 다음 단계의 gdcloud 명령어가 앵커 영역의 루트 관리자 클러스터와 상호작용하여 앵커 영역의 전역 API와 상호작용하기 위한 연결 정보를 가져오기 때문에 필요합니다.

3. 부트스트랩 YAML 파일을 생성합니다.

   gdcloud system multi-zone create-bootstrap --type join --output-file /tmp/iac/infrastructure/zonal/zones/JOINING_ZONE_NAME/root-admin/mz-bootstrap.yaml
   

4. kustomization.yaml 파일을 만들거나 업데이트합니다.

   1. 파일을 엽니다.

      vim infrastructure/zonal/zones/JOINING_ZONE_NAME/root-admin/kustomization.yaml
      

   2. 파일이 이미 있는 경우 resources 목록에 mz-token.yaml 항목을 추가합니다. 그렇지 않으면 전체 리소스 YAML을 추가합니다.

      참고: 서식이 지정된 텍스트를 붙여넣을 때 vim이 자동으로 서식을 지정하지 않도록 하려면 :set paste를 사용하세요.

      apiVersion: kustomize.config.k8s.io/v1beta1
      kind: Kustomization
      metadata:
        name: root-admin-kustomization
      resources:
      - mz-bootstrap.yaml
      

   3. 파일을 저장하고 vim을 종료합니다.

5. 브랜치에 변경사항을 커밋합니다.

   참고: 변경사항을 커밋하려면 먼저 이름과 이메일 주소로 git을 구성해야 합니다.

   git add infrastructure
   git commit
   

6. 분기를 GitLab로 푸시합니다.

   git push
   

7. 변경사항을 main 브랜치에 병합합니다. 자세한 내용은 IAC-R0004 런북을 참고하세요.

변경사항이 병합되면 IaC는 Bootstrap 리소스를 새 영역의 루트 관리자 클러스터에 전파하여 조정합니다. 이는 비동기 작업이므로 병합 후 즉시 전역 API를 사용할 수 없습니다.

26.2.7. 글로벌 API의 배포 성공 검사

전역 API의 배포를 확인하려면 다음 단계를 따르세요.

1. 참여 영역에 로그인합니다. 자세한 내용은 gdcloud 명령줄 인터페이스를 참고하세요.

2. 루트 전역 API (global-api)의 Kubernetes 구성을 가져옵니다. 자세한 내용은 IAM-R0004 런북을 참고하세요.

3. 참여 영역의 전역 API와의 연결을 확인합니다.

   kubectl version
   

26.2.8. 키 쌍 정리

앵커 영역에서 조인 영역으로 부트스트랩 토큰을 전송하는 데 사용된 키 쌍을 삭제하려면 다음 단계를 따르세요.

1. 참여 영역에 로그인합니다. 자세한 내용은 gdcloud 명령줄 인터페이스를 참고하세요.

2. 루트 관리자 클러스터 (root-admin)의 Kubernetes 구성을 가져옵니다. 자세한 내용은 IAM-R0004 런북을 참고하세요.

3. 다음 명령어를 실행하여 키 쌍을 삭제합니다.

   kubectl delete keypair -n global-kube-system kp
   

26.2.9. 토큰 요청 정리

토큰 요청 YAML 파일을 삭제하려면 다음 단계를 따르세요.

1. 병합 요청을 위한 새 브랜치를 만듭니다.

   cd /tmp/iac
   git checkout main
   git pull --ff-only
   git checkout -b JOINING_ZONE_NAME-mz-token-request-delete
   

2. 토큰 요청 YAML 파일을 삭제합니다.

   rm /tmp/iac/infrastructure/global/orgs/root/mz-token-request.yaml
   

3. kustomization.yaml 파일을 업데이트합니다.

   1. 파일을 엽니다.

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

   2. resources 목록에서 mz-token-request.yaml 항목을 삭제하고 파일을 저장한 후 vim을 종료합니다.

4. 브랜치에 변경사항을 커밋합니다.

   참고: 변경사항을 커밋하려면 먼저 이름과 이메일 주소로 git을 구성해야 합니다.

   git add infrastructure
   git commit
   

5. 분기를 GitLab로 푸시합니다.

   git push
   

6. 변경사항을 main 브랜치에 병합합니다. 자세한 내용은 IAC-R0004 런북을 참고하세요.

26.2.10. 토큰 정리

참여 영역에서 전역 API를 사용할 수 있게 되면 더 이상 필요하지 않으므로 토큰을 삭제합니다.

1. 병합 요청을 위한 새 브랜치를 만듭니다.

   cd /tmp/iac
   git checkout main
   git pull --ff-only
   git checkout -b JOINING_ZONE_NAME-mz-token-delete
   

2. 토큰 YAML 파일을 삭제합니다.

   rm /tmp/iac/infrastructure/zonal/zones/JOINING_ZONE_NAME/root-admin/mz-token.yaml
   

3. kustomization.yaml 파일이 이미 있는 경우 업데이트합니다.

   1. 파일을 엽니다.

      vim infrastructure/zonal/zones/JOINING_ZONE_NAME/root-admin/kustomization.yaml
      

   2. resources 목록에서 mz-token.yaml 항목을 삭제하고 파일을 저장하고 vim을 종료합니다.

4. 브랜치에 변경사항을 커밋합니다.

   참고: 변경사항을 커밋하려면 먼저 이름과 이메일 주소로 git을 구성해야 합니다.

   git add infrastructure
   git commit
   

5. 분기를 GitLab로 푸시합니다.

   git push
   

6. 변경사항을 main 브랜치에 병합합니다. 자세한 내용은 IAC-R0004 런북을 참고하세요.

26.2.11. 다른 시간대와 시간 동기화

1. NTP P0007 - 다중 영역 SyncServer 구성에 따라 이 영역의 시간을 다른 영역과 동기화합니다.

26.2.12. 글로벌 API가 정상인지 확인

전역 API 부트스트랩 프로세스가 완료되면 상태 확인을 실행하여 API가 정상인지 확인합니다.

1. 루트 관리자 클러스터의 API 서버에서 영역 이름을 가져옵니다.

   export ZONE_NAME=$(kubectl get controlplane -n mz-system cp -o jsonpath='{.spec.zone}')
   

2. 전역 API의 마지막 하트비트 타임스탬프를 확인합니다.

   kubectl get globalapizone -n mz-system ${ZONE_NAME} -o yaml
   

   하트비트 타임스탬프는 status.lastHeartbeat에 채워집니다. 타임스탬프는 30초마다 업데이트됩니다. 정상적인 전역 API의 마지막 하트비트 타임스탬프는 30초 이내입니다.

26.2.13. 글로벌 etcd CA의 만료일 연장

전역 etcd의 인증 기관 (CA)의 만료일은 90일입니다. 글로벌 etcd는 여러 GDC 영역에 인스턴스가 배포된 etcd 클러스터입니다. CA를 순환하는 자동화가 없습니다.

이 안내는 이미 다중 영역 유니버스에 참여한 기존 영역에 적용해야 합니다. 기존 영역이 업데이트된 후 이 유니버스에 참여할 다음 영역은 이 섹션을 건너뛸 수 있습니다.

26.2.13.1. 만료일 확인

기존 영역에서 루트 관리자 클러스터의 관리자 Kubernetes 구성을 사용합니다. CA의 만료일을 확인합니다.

export CA_NAME=$(kubectl get etcdca etcd -n global-kube-system -o jsonpath="{.spec.rootCA.name}")

kubectl get secret $CA_NAME -n global-kube-system -o jsonpath="{.data.tls\.crt}" | base64 -d | openssl x509 -enddate -noout -in -

만료일이 이미 1년으로 설정되어 있다면 더 이상 조치를 취하지 않아도 됩니다. 1년 미만인 경우 기간이 더 긴 CA 순환을 참고하세요.

26.2.13.2. 기간이 더 긴 CA 순환

MZ-T0001에 따라 CA를 순환합니다. 새 CA의 인증서 사양에 duration: 8760h 값이 포함되어 있는지 확인합니다.