7.10. Deployment Manager 템플릿을 사용하여 GCP의 사용자 프로비저닝 인프라에 클러스터 설치

프로세스

1. 이 항목의 VPC에 대한 Deployment Manager 템플릿 섹션에서 템플릿을 복사하여 사용자 컴퓨터에 01_vpc.py로 저장합니다. 이 템플릿은 클러스터에 필요한 VPC를 설명합니다.

2. 01_vpc.yaml 리소스 정의 파일을 생성합니다.

   $ cat <<EOF >01_vpc.yaml
   imports:
   - path: 01_vpc.py
   
   resources:
   - name: cluster-vpc
     type: 01_vpc.py
     properties:
       infra_id: '${INFRA_ID}' 1
       region: '${REGION}' 2
       master_subnet_cidr: '${MASTER_SUBNET_CIDR}' 3
       worker_subnet_cidr: '${WORKER_SUBNET_CIDR}' 4
   EOF

   1

   infra_id는 추출 단계에서 가져온 INFRA_ID 인프라 이름입니다.

   2

   region은 클러스터를 배포할 영역입니다(예: us-central1).

   3

   master_subnet_cidr은 마스터 서브넷의 CIDR입니다. (예: 10.0.0.0/17)

   4

   worker_subnet_cidr은 작업자 서브넷의 CIDR입니다. (예: 10.0.128.0/17)

3. gcloud CLI를 사용하여 배포를 생성합니다.

   $ gcloud deployment-manager deployments create ${INFRA_ID}-vpc --config 01_vpc.yaml

프로세스

1. 이 항목의 내부 로드 밸런서에 대한 Deployment Manager 템플릿 섹션에서 템플릿을 복사하여 사용자 컴퓨터에 02_lb_int.py로 저장합니다. 이 템플릿에서 클러스터에 필요한 내부 로드 밸런싱 개체를 설명합니다.
2. 외부 클러스터에 대해서도, 이 항목의 외부 로드 밸런서에 대한 Deployment Manager 템플릿 섹션에서 템플릿을 복사하여 사용자 컴퓨터에 02_lb_ext.py로 저장합니다. 이 템플릿에서 클러스터에 필요한 외부 로드 밸런싱 개체를 설명합니다.

3. 배포 템플릿이 사용하는 변수를 내보냅니다.

   1. 클러스터 네트워크 위치를 내보냅니다.

      $ export CLUSTER_NETWORK=(`gcloud compute networks describe ${INFRA_ID}-network --format json | jq -r .selfLink`)

   2. 컨트롤 플레인 서브넷 위치를 내보냅니다.

      $ export CONTROL_SUBNET=(`gcloud compute networks subnets describe ${INFRA_ID}-master-subnet --region=${REGION} --format json | jq -r .selfLink`)

   3. 클러스터가 사용하는 세 영역을 내보냅니다.

      $ export ZONE_0=(`gcloud compute regions describe ${REGION} --format=json | jq -r .zones[0] | cut -d "/" -f9`)

      $ export ZONE_1=(`gcloud compute regions describe ${REGION} --format=json | jq -r .zones[1] | cut -d "/" -f9`)

      $ export ZONE_2=(`gcloud compute regions describe ${REGION} --format=json | jq -r .zones[2] | cut -d "/" -f9`)

4. 02_infra.yaml 리소스 정의 파일을 생성합니다.

   $ cat <<EOF >02_infra.yaml
   imports:
   - path: 02_lb_ext.py
   - path: 02_lb_int.py 1
   resources:
   - name: cluster-lb-ext 2
     type: 02_lb_ext.py
     properties:
       infra_id: '${INFRA_ID}' 3
       region: '${REGION}' 4
   - name: cluster-lb-int
     type: 02_lb_int.py
     properties:
       cluster_network: '${CLUSTER_NETWORK}'
       control_subnet: '${CONTROL_SUBNET}' 5
       infra_id: '${INFRA_ID}'
       region: '${REGION}'
       zones: 6
       - '${ZONE_0}'
       - '${ZONE_1}'
       - '${ZONE_2}'
   EOF

   1 2

   외부 클러스터를 배포하는 경우에만 필요합니다.

   3

   infra_id는 추출 단계에서 가져온 INFRA_ID 인프라 이름입니다.

   4

   region은 클러스터를 배포할 영역입니다(예: us-central1).

   5

   control_subnet은 컨트롤 서브넷에 대한 URI입니다.

   6

   zones는 us-east1-b, us-east1-c 및 us-east1-d와 같이 컨트롤 플레인 인스턴스를 배포하는 영역입니다.

5. gcloud CLI를 사용하여 배포를 생성합니다.

   $ gcloud deployment-manager deployments create ${INFRA_ID}-infra --config 02_infra.yaml

6. 클러스터 IP 주소를 내보냅니다.

   $ export CLUSTER_IP=(`gcloud compute addresses describe ${INFRA_ID}-cluster-ip --region=${REGION} --format json | jq -r .address`)

7. 외부 클러스터의 경우 클러스터 공용 IP 주소도 내보냅니다.

   $ export CLUSTER_PUBLIC_IP=(`gcloud compute addresses describe ${INFRA_ID}-cluster-public-ip --region=${REGION} --format json | jq -r .address`)

프로세스

1. 이 항목의 프라이빗 DNS에 대한 Deployment Manager 템플릿 섹션에서 템플릿을 복사하여 사용자 컴퓨터에 02_dns.py로 저장합니다. 이 템플릿에서 클러스터에 필요한 프라이빗 DNS 개체를 설명합니다.

2. 02_dns.yaml 리소스 정의 파일을 생성합니다.

   $ cat <<EOF >02_dns.yaml
   imports:
   - path: 02_dns.py
   
   resources:
   - name: cluster-dns
     type: 02_dns.py
     properties:
       infra_id: '${INFRA_ID}' 1
       cluster_domain: '${CLUSTER_NAME}.${BASE_DOMAIN}' 2
       cluster_network: '${CLUSTER_NETWORK}' 3
   EOF

   1

   infra_id는 추출 단계에서 가져온 INFRA_ID 인프라 이름입니다.

   2

   cluster_domain은 클러스터의 도메인입니다(예: openshift.example.com).

   3

   cluster_network는 클러스터 네트워크에 대한 selfLink URL입니다.

3. gcloud CLI를 사용하여 배포를 생성합니다.

   $ gcloud deployment-manager deployments create ${INFRA_ID}-dns --config 02_dns.yaml

4. Deployment Manager의 제한으로 인해 템플릿을 통해 DNS 항목이 생성되지 않으므로 수동으로 생성해야 합니다.

   1. 내부 DNS 항목을 추가합니다.

      $ if [ -f transaction.yaml ]; then rm transaction.yaml; fi
      $ gcloud dns record-sets transaction start --zone ${INFRA_ID}-private-zone
      $ gcloud dns record-sets transaction add ${CLUSTER_IP} --name api.${CLUSTER_NAME}.${BASE_DOMAIN}. --ttl 60 --type A --zone ${INFRA_ID}-private-zone
      $ gcloud dns record-sets transaction add ${CLUSTER_IP} --name api-int.${CLUSTER_NAME}.${BASE_DOMAIN}. --ttl 60 --type A --zone ${INFRA_ID}-private-zone
      $ gcloud dns record-sets transaction execute --zone ${INFRA_ID}-private-zone

   2. 외부 클러스터의 경우 외부 DNS 항목도 추가합니다.

      $ if [ -f transaction.yaml ]; then rm transaction.yaml; fi
      $ gcloud dns record-sets transaction start --zone ${BASE_DOMAIN_ZONE_NAME}
      $ gcloud dns record-sets transaction add ${CLUSTER_PUBLIC_IP} --name api.${CLUSTER_NAME}.${BASE_DOMAIN}. --ttl 60 --type A --zone ${BASE_DOMAIN_ZONE_NAME}
      $ gcloud dns record-sets transaction execute --zone ${BASE_DOMAIN_ZONE_NAME}

프로세스

1. 이 항목의 방화벽 규칙에 대한 Deployment Manager 템플릿 섹션에서 템플릿을 복사하여 사용자 컴퓨터에 03_firewall.py로 저장합니다. 이 템플릿에서 클러스터에 필요한 보안 그룹을 설명합니다.

2. 03_firewall.yaml 리소스 정의 파일을 생성합니다.

   $ cat <<EOF >03_firewall.yaml
   imports:
   - path: 03_firewall.py
   
   resources:
   - name: cluster-firewall
     type: 03_firewall.py
     properties:
       allowed_external_cidr: '0.0.0.0/0' 1
       infra_id: '${INFRA_ID}' 2
       cluster_network: '${CLUSTER_NETWORK}' 3
       network_cidr: '${NETWORK_CIDR}' 4
   EOF

   1

   allowed_external_cidr은 부트스트랩 호스트에 클러스터 API 및 SSH 액세스가 가능한 CIDR 범위입니다. 내부 클러스터의 경우 이 값을 ${NETWORK_CIDR}로 설정합니다.

   2

   infra_id는 추출 단계에서 가져온 INFRA_ID 인프라 이름입니다.

   3

   cluster_network는 클러스터 네트워크에 대한 selfLink URL입니다.

   4

   network_cidr은 VPC 네트워크의 CIDR입니다(예: 10.0.0.0/16).

3. gcloud CLI를 사용하여 배포를 생성합니다.

   $ gcloud deployment-manager deployments create ${INFRA_ID}-firewall --config 03_firewall.yaml

프로세스

1. 이 항목의 IAM 역할에 대한 Deployment Manager 템플릿 섹션에서 템플릿을 복사하여 사용자 컴퓨터에 03_iam.py로 저장합니다. 이 템플릿에서 클러스터에 필요한 IAM 역할을 설명합니다.

2. 03_iam.yaml 리소스 정의 파일을 생성합니다.

   $ cat <<EOF >03_iam.yaml
   imports:
   - path: 03_iam.py
   resources:
   - name: cluster-iam
     type: 03_iam.py
     properties:
       infra_id: '${INFRA_ID}' 1
   EOF

   1

   infra_id는 추출 단계에서 가져온 INFRA_ID 인프라 이름입니다.

3. gcloud CLI를 사용하여 배포를 생성합니다.

   $ gcloud deployment-manager deployments create ${INFRA_ID}-iam --config 03_iam.yaml

4. 마스터 서비스 계정에 대한 변수를 내보냅니다.

   $ export MASTER_SERVICE_ACCOUNT=(`gcloud iam service-accounts list --filter "email~^${INFRA_ID}-m@${PROJECT_NAME}." --format json | jq -r '.[0].email'`)

5. 작업자 서비스 계정에 대한 변수를 내보냅니다.

   $ export WORKER_SERVICE_ACCOUNT=(`gcloud iam service-accounts list --filter "email~^${INFRA_ID}-w@${PROJECT_NAME}." --format json | jq -r '.[0].email'`)

6. 컴퓨팅 머신을 호스팅하는 서브넷의 변수를 내보냅니다.

   $ export COMPUTE_SUBNET=(`gcloud compute networks subnets describe ${INFRA_ID}-worker-subnet --region=${REGION} --format json | jq -r .selfLink`)

7. Deployment Manager의 제한으로 인해 템플릿을 통해 정책 바인딩이 생성되지 않으므로 수동으로 생성해야 합니다.

   $ gcloud projects add-iam-policy-binding ${PROJECT_NAME} --member "serviceAccount:${MASTER_SERVICE_ACCOUNT}" --role "roles/compute.instanceAdmin"
   $ gcloud projects add-iam-policy-binding ${PROJECT_NAME} --member "serviceAccount:${MASTER_SERVICE_ACCOUNT}" --role "roles/compute.networkAdmin"
   $ gcloud projects add-iam-policy-binding ${PROJECT_NAME} --member "serviceAccount:${MASTER_SERVICE_ACCOUNT}" --role "roles/compute.securityAdmin"
   $ gcloud projects add-iam-policy-binding ${PROJECT_NAME} --member "serviceAccount:${MASTER_SERVICE_ACCOUNT}" --role "roles/iam.serviceAccountUser"
   $ gcloud projects add-iam-policy-binding ${PROJECT_NAME} --member "serviceAccount:${MASTER_SERVICE_ACCOUNT}" --role "roles/storage.admin"
   
   $ gcloud projects add-iam-policy-binding ${PROJECT_NAME} --member "serviceAccount:${WORKER_SERVICE_ACCOUNT}" --role "roles/compute.viewer"
   $ gcloud projects add-iam-policy-binding ${PROJECT_NAME} --member "serviceAccount:${WORKER_SERVICE_ACCOUNT}" --role "roles/storage.admin"

8. 서비스 계정 키를 생성하여 나중에 사용할 수 있도록 로컬로 저장합니다.

   $ gcloud iam service-accounts keys create service-account-key.json --iam-account=${MASTER_SERVICE_ACCOUNT}

프로세스

1. RHCOS 이미지 미러 페이지에서 RHCOS 이미지를 가져옵니다.

   중요

   RHCOS 이미지는 OpenShift Container Platform 릴리스에 따라 변경되지 않을 수 있습니다. 설치하는 OpenShift Container Platform 버전과 같거나 그 이하의 버전 중 가장 최신 버전의 이미지를 다운로드해야 합니다. 지원되는 경우 OpenShift Container Platform 버전과 일치하는 이미지 버전을 사용합니다.

   rhcos-<version>-<arch>-gcp.<arch>.tar.gz 형식의 OpenShift Container Platform 버전 번호가 파일 이름에 포함되어 있습니다.

2. Google 스토리지 버킷을 생성합니다.

   $ gsutil mb gs://<bucket_name>

3. RHCOS 이미지를 Google 스토리지 버킷에 업로드합니다.

   $ gsutil cp <downloaded_image_file_path>/rhcos-<version>-x86_64-gcp.x86_64.tar.gz  gs://<bucket_name>

4. 업로드된 RHCOS 이미지 위치를 변수로 내보냅니다.

   $ export IMAGE_SOURCE=gs://<bucket_name>/rhcos-<version>-x86_64-gcp.x86_64.tar.gz

5. 클러스터 이미지를 생성합니다.

   $ gcloud compute images create "${INFRA_ID}-rhcos-image" \
       --source-uri="${IMAGE_SOURCE}"

프로세스

1. 이 항목의 부트스트랩 시스템에 대한 Deployment Manager 템플릿 섹션에서 템플릿을 복사하여 사용자 컴퓨터에 04_bootstrap.py로 저장합니다. 이 템플릿은 클러스터에 필요한 부트스트랩 시스템을 설명합니다.

2. 설치 프로그램에 필요한 RHCOS(Red Hat Enterprise Linux CoreOS) 이미지의 위치를 내보냅니다.

   $ export CLUSTER_IMAGE=(`gcloud compute images describe ${INFRA_ID}-rhcos-image --format json | jq -r .selfLink`)

3. 버킷을 생성하고 bootstrap.ign 파일을 업로드합니다.

   $ gsutil mb gs://${INFRA_ID}-bootstrap-ignition
   $ gsutil cp <installation_directory>/bootstrap.ign gs://${INFRA_ID}-bootstrap-ignition/

4. Ignition 구성 파일에 액세스하는 데 사용할 부트스트랩 인스턴스에 대한 서명된 URL을 생성합니다. 출력에서 URL을 변수로 내보냅니다.

   $ export BOOTSTRAP_IGN=`gsutil signurl -d 1h service-account-key.json gs://${INFRA_ID}-bootstrap-ignition/bootstrap.ign | grep "^gs:" | awk '{print $5}'`

5. 04_bootstrap.yaml 리소스 정의 파일을 생성합니다.

   $ cat <<EOF >04_bootstrap.yaml
   imports:
   - path: 04_bootstrap.py
   
   resources:
   - name: cluster-bootstrap
     type: 04_bootstrap.py
     properties:
       infra_id: '${INFRA_ID}' 1
       region: '${REGION}' 2
       zone: '${ZONE_0}' 3
   
       cluster_network: '${CLUSTER_NETWORK}' 4
       control_subnet: '${CONTROL_SUBNET}' 5
       image: '${CLUSTER_IMAGE}' 6
       machine_type: 'n1-standard-4' 7
       root_volume_size: '128' 8
   
       bootstrap_ign: '${BOOTSTRAP_IGN}' 9
   EOF

   1

   infra_id는 추출 단계에서 가져온 INFRA_ID 인프라 이름입니다.

   2

   region은 클러스터를 배포할 영역입니다(예: us-central1).

   3

   zone은 부트스트랩 인스턴스를 배포할 영역입니다(예: us-central1-b).

   4

   cluster_network는 클러스터 네트워크에 대한 selfLink URL입니다.

   5

   control_subnet은 컨트롤 서브넷에 대한 selfLink URL입니다.

   6

   image는 RHCOS 이미지에 대한 selfLink URL입니다.

   7

   machine_type은 인스턴스의 시스템 유형입니다(예: n1-standard-4).

   8

   root_volume_size는 부트스트랩 시스템의 부팅 디스크 크기입니다.

   9

   bootstrap_ign은 서명된 URL을 생성할 때 출력되는 URL입니다.

6. gcloud CLI를 사용하여 배포를 생성합니다.

   $ gcloud deployment-manager deployments create ${INFRA_ID}-bootstrap --config 04_bootstrap.yaml

7. Deployment Manager의 제한으로 인해 템플릿을 통해 로드 밸랜서 멤버십이 관리되지 않으므로 수동으로 부트스트랩 시스템을 추가해야 합니다.

   1. 내부 로드 밸런서 인스턴스 그룹에 부트스트랩 인스턴스를 추가합니다.

      $ gcloud compute instance-groups unmanaged add-instances \
          ${INFRA_ID}-bootstrap-instance-group --zone=${ZONE_0} --instances=${INFRA_ID}-bootstrap

   2. 내부 로드 밸런서 백엔드 서비스에 부트스트랩 인스턴스 그룹을 추가합니다.

      $ gcloud compute backend-services add-backend \
          ${INFRA_ID}-api-internal-backend-service --region=${REGION} --instance-group=${INFRA_ID}-bootstrap-instance-group --instance-group-zone=${ZONE_0}

프로세스

1. 이 항목의 컨트롤 플레인 시스템에 대한 Deployment Manager 템플릿 섹션에서 템플릿을 복사하여 사용자 컴퓨터에 05_control_plane.py로 저장합니다. 이 템플릿은 클러스터에 필요한 컨트롤 플레인 시스템을 설명합니다.

2. 리소스 정의에 필요한 다음 변수를 내보냅니다.

   $ export MASTER_IGNITION=`cat <installation_directory>/master.ign`

3. 05_control_plane.yaml 리소스 정의 파일을 생성합니다.

   $ cat <<EOF >05_control_plane.yaml
   imports:
   - path: 05_control_plane.py
   
   resources:
   - name: cluster-control-plane
     type: 05_control_plane.py
     properties:
       infra_id: '${INFRA_ID}' 1
       zones: 2
       - '${ZONE_0}'
       - '${ZONE_1}'
       - '${ZONE_2}'
   
       control_subnet: '${CONTROL_SUBNET}' 3
       image: '${CLUSTER_IMAGE}' 4
       machine_type: 'n1-standard-4' 5
       root_volume_size: '128'
       service_account_email: '${MASTER_SERVICE_ACCOUNT}' 6
   
       ignition: '${MASTER_IGNITION}' 7
   EOF

   1

   infra_id는 추출 단계에서 가져온 INFRA_ID 인프라 이름입니다.

   2

   zones은 컨트롤 플레인 인스턴스를 배포할 영역입니다(예: us-central1-a, us-central1-b, us-central1-c).

   3

   control_subnet은 컨트롤 서브넷에 대한 selfLink URL입니다.

   4

   image는 RHCOS 이미지에 대한 selfLink URL입니다.

   5

   machine_type은 인스턴스의 시스템 유형입니다(예: n1-standard-4).

   6

   service_account_email은 사용자가 생성한 마스터 서비스 계정의 이메일 주소입니다.

   7

   ignition은 master.ign 파일의 내용입니다.

4. gcloud CLI를 사용하여 배포를 생성합니다.

   $ gcloud deployment-manager deployments create ${INFRA_ID}-control-plane --config 05_control_plane.yaml

5. Deployment Manager의 제한으로 인해 템플릿을 통해 로드 밸랜서 멤버십이 관리되지 않으므로 수동으로 컨트롤 플레인 시스템을 추가해야 합니다.

   • 다음 명령을 실행하여 적절한 인스턴스 그룹에 컨트롤 플레인 머신을 추가합니다.

     $ gcloud compute instance-groups unmanaged add-instances ${INFRA_ID}-master-${ZONE_0}-instance-group --zone=${ZONE_0} --instances=${INFRA_ID}-master-0
     $ gcloud compute instance-groups unmanaged add-instances ${INFRA_ID}-master-${ZONE_1}-instance-group --zone=${ZONE_1} --instances=${INFRA_ID}-master-1
     $ gcloud compute instance-groups unmanaged add-instances ${INFRA_ID}-master-${ZONE_2}-instance-group --zone=${ZONE_2} --instances=${INFRA_ID}-master-2

   • 외부 클러스터의 경우 다음 명령을 실행하여 대상 풀에 컨트롤 플레인 머신을 추가해야 합니다.

     $ gcloud compute target-pools add-instances ${INFRA_ID}-api-target-pool --instances-zone="${ZONE_0}" --instances=${INFRA_ID}-master-0
     $ gcloud compute target-pools add-instances ${INFRA_ID}-api-target-pool --instances-zone="${ZONE_1}" --instances=${INFRA_ID}-master-1
     $ gcloud compute target-pools add-instances ${INFRA_ID}-api-target-pool --instances-zone="${ZONE_2}" --instances=${INFRA_ID}-master-2

프로세스

1. 설치 프로그램이 포함된 디렉터리로 변경하고 다음 명령을 실행합니다.

   $ ./openshift-install wait-for bootstrap-complete --dir <installation_directory> \ 1
       --log-level info 2

   1

   <installation_directory>는 설치 파일을 저장한 디렉터리의 경로를 지정합니다.

   2

   다른 설치 세부 사항을 보려면 info 대신 warn, debug 또는 error를 지정합니다.

   FATAL 경고 없이 명령이 종료되면 프로덕션 컨트롤 플레인이 초기화된 것입니다.

2. 부트스트랩 리소스를 삭제합니다.

   $ gcloud compute backend-services remove-backend ${INFRA_ID}-api-internal-backend-service --region=${REGION} --instance-group=${INFRA_ID}-bootstrap-instance-group --instance-group-zone=${ZONE_0}
   $ gsutil rm gs://${INFRA_ID}-bootstrap-ignition/bootstrap.ign
   $ gsutil rb gs://${INFRA_ID}-bootstrap-ignition
   $ gcloud deployment-manager deployments delete ${INFRA_ID}-bootstrap

프로세스

1. 이 항목의 작업자 시스템에 대한 Deployment Manager 템플릿 섹션에서 템플릿을 복사하여 사용자 컴퓨터에 06_worker.py로 저장합니다. 이 템플릿에서 클러스터에 필요한 작업자 시스템을 설명합니다.

2. 리소스 정의가 사용하는 변수를 내보냅니다.

   1. 컴퓨팅 시스템을 호스팅하는 서브넷을 내보냅니다.

      $ export COMPUTE_SUBNET=(`gcloud compute networks subnets describe ${INFRA_ID}-worker-subnet --region=${REGION} --format json | jq -r .selfLink`)

   2. 서비스 계정의 이메일 주소를 내보냅니다.

      $ export WORKER_SERVICE_ACCOUNT=(`gcloud iam service-accounts list --filter "email~^${INFRA_ID}-w@${PROJECT_NAME}." --format json | jq -r '.[0].email'`)

   3. 컴퓨팅 시스템 Ignition 구성 파일의 위치를 내보냅니다.

      $ export WORKER_IGNITION=`cat <installation_directory>/worker.ign`

3. 06_worker.yaml 리소스 정의 파일을 생성합니다.

   $ cat <<EOF >06_worker.yaml
   imports:
   - path: 06_worker.py
   
   resources:
   - name: 'worker-0' 1
     type: 06_worker.py
     properties:
       infra_id: '${INFRA_ID}' 2
       zone: '${ZONE_0}' 3
       compute_subnet: '${COMPUTE_SUBNET}' 4
       image: '${CLUSTER_IMAGE}' 5
       machine_type: 'n1-standard-4' 6
       root_volume_size: '128'
       service_account_email: '${WORKER_SERVICE_ACCOUNT}' 7
       ignition: '${WORKER_IGNITION}' 8
   - name: 'worker-1'
     type: 06_worker.py
     properties:
       infra_id: '${INFRA_ID}' 9
       zone: '${ZONE_1}' 10
       compute_subnet: '${COMPUTE_SUBNET}' 11
       image: '${CLUSTER_IMAGE}' 12
       machine_type: 'n1-standard-4' 13
       root_volume_size: '128'
       service_account_email: '${WORKER_SERVICE_ACCOUNT}' 14
       ignition: '${WORKER_IGNITION}' 15
   EOF

   1

   name은 작업자 머신의 이름입니다(예: worker-0).

   2 9

   infra_id는 추출 단계에서 가져온 INFRA_ID 인프라 이름입니다.

   3 10

   zone은 작업자 시스템을 배포할 영역입니다(예: us-central1-a).

   4 11

   compute_subnet은 컴퓨팅 서브넷에 대한 selfLink URL입니다.

   5 12

   image는 RHCOS 이미지에 대한 selfLink URL입니다. ¹

   6 13

   machine_type은 인스턴스의 시스템 유형입니다(예: n1-standard-4).

   7 14

   service_account_email은 사용자가 생성한 작업자 서비스 계정의 이메일 주소입니다.

   8 15

   ignition은 worker.ign 파일의 내용입니다.

4. 선택사항: 추가 인스턴스를 시작하려면 06_worker.yaml 리소스 정의 파일에 06_worker.py 형식의 추가 리소스를 포함시키십시오.

5. gcloud CLI를 사용하여 배포를 생성합니다.

   $ gcloud deployment-manager deployments create ${INFRA_ID}-worker --config 06_worker.yaml

1. GCP Marketplace 이미지를 사용하려면 사용할 오퍼를 지정합니다.

   • OpenShift Container Platform: https://www.googleapis.com/compute/v1/projects/redhat-marketplace-public/global/images/redhat-coreos-ocp-48-x86-64-202210040145
   • OpenShift Platform Plus: https://www.googleapis.com/compute/v1/projects/redhat-marketplace-public/global/images/redhat-coreos-opp-48-x86-64-202206140145
   • OpenShift Kubernetes Engine: https://www.googleapis.com/compute/v1/projects/redhat-marketplace-public/global/images/redhat-coreos-oke-48-x86-64-202206140145

프로세스

1. Red Hat 고객 포털에서 OpenShift Container Platform 다운로드 페이지로 이동합니다.
2. 버전 드롭다운 메뉴에서 적절한 버전을 선택합니다.
3. OpenShift v4.9 Linux Client 항목 옆에 있는 지금 다운로드를 클릭하고 파일을 저장합니다.

4. 아카이브의 압축을 풉니다.

   $ tar xvf <file>

5. oc 바이너리를 PATH에 있는 디렉터리에 배치합니다.

   PATH를 확인하려면 다음 명령을 실행합니다.

   $ echo $PATH

프로세스

1. Red Hat 고객 포털에서 OpenShift Container Platform 다운로드 페이지로 이동합니다.
2. 버전 드롭다운 메뉴에서 적절한 버전을 선택합니다.
3. OpenShift v4.9 Windows Client 항목 옆에 있는 지금 다운로드를 클릭하고 파일을 저장합니다.
4. ZIP 프로그램으로 아카이브의 압축을 풉니다.

5. oc 바이너리를 PATH에 있는 디렉터리로 이동합니다.

   PATH를 확인하려면 명령 프롬프트를 열고 다음 명령을 실행합니다.

   C:\> path

프로세스

1. Red Hat 고객 포털에서 OpenShift Container Platform 다운로드 페이지로 이동합니다.
2. 버전 드롭다운 메뉴에서 적절한 버전을 선택합니다.
3. OpenShift v4.9 MacOSX Client 항목 옆에 있는 지금 다운로드를 클릭하고 파일을 저장합니다.
4. 아카이브의 압축을 해제하고 압축을 풉니다.

5. oc 바이너리 PATH의 디렉터리로 이동합니다.

   PATH를 확인하려면 터미널을 열고 다음 명령을 실행합니다.

   $ echo $PATH

프로세스

1. kubeadmin 인증 정보를 내보냅니다.

   $ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1

   1

   <installation_directory>는 설치 파일을 저장한 디렉터리의 경로를 지정합니다.

2. 내보낸 구성을 사용하여 oc 명령을 성공적으로 실행할 수 있는지 확인합니다.

   $ oc whoami

   출력 예

   system:admin

프로세스

1. 클러스터가 시스템을 인식하는지 확인합니다.

   $ oc get nodes

   출력 예

   NAME      STATUS    ROLES   AGE  VERSION
   master-0  Ready     master  63m  v1.22.1
   master-1  Ready     master  63m  v1.22.1
   master-2  Ready     master  64m  v1.22.1

   출력에 생성된 모든 시스템이 나열됩니다.

   참고

   이전 출력에는 일부 CSR이 승인될 때까지 컴퓨팅 노드(작업자 노드라고도 함)가 포함되지 않을 수 있습니다.

2. 보류 중인 CSR을 검토하고 클러스터에 추가한 각 시스템에 대해 Pending 또는 Approved 상태의 클라이언트 및 서버 요청이 표시되는지 확인합니다.

   $ oc get csr

   출력 예

   NAME        AGE     REQUESTOR                                                                   CONDITION
   csr-8b2br   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
   csr-8vnps   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
   ...

   예에서는 두 시스템이 클러스터에 참여하고 있습니다. 목록에는 승인된 CSR이 더 많이 나타날 수도 있습니다.

3. CSR이 승인되지 않은 경우, 추가된 시스템에 대한 모든 보류 중인 CSR이 Pending 상태로 전환된 후 클러스터 시스템의 CSR을 승인합니다.

   참고

   CSR은 교체 주기가 자동으로 만료되므로 클러스터에 시스템을 추가한 후 1시간 이내에 CSR을 승인하십시오. 한 시간 내에 승인하지 않으면 인증서가 교체되고 각 노드에 대해 두 개 이상의 인증서가 표시됩니다. 이러한 인증서를 모두 승인해야 합니다. 클라이언트 CSR이 승인되면 Kubelet은 인증서에 대한 보조 CSR을 생성하므로 수동 승인이 필요합니다. 그러면 Kubelet에서 동일한 매개변수를 사용하여 새 인증서를 요청하는 경우 인증서 갱신 요청은 machine-approver에 의해 자동으로 승인됩니다.

   참고

   베어 메탈 및 기타 사용자 프로비저닝 인프라와 같이 머신 API를 사용하도록 활성화되지 않는 플랫폼에서 실행되는 클러스터의 경우 CSR(Kubelet service Certificate Request)을 자동으로 승인하는 방법을 구현해야 합니다. 요청이 승인되지 않으면 API 서버가 kubelet에 연결될 때 서비스 인증서가 필요하므로 oc exec, oc rsh, oc logs 명령을 성공적으로 수행할 수 없습니다. Kubelet 엔드 포인트에 연결하는 모든 작업을 수행하려면 이 인증서 승인이 필요합니다. 이 방법은 새 CSR을 감시하고 CSR이 system:node 또는 system:admin 그룹의 node-bootstrapper 서비스 계정에 의해 제출되었는지 확인하고 노드의 ID를 확인합니다.

   • 개별적으로 승인하려면 유효한 CSR 각각에 대해 다음 명령을 실행하십시오.

     $ oc adm certificate approve <csr_name> 1

     1

     <csr_name>은 현재 CSR 목록에 있는 CSR의 이름입니다.

   • 보류 중인 CSR을 모두 승인하려면 다음 명령을 실행하십시오.

     $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs --no-run-if-empty oc adm certificate approve

     참고

     일부 Operator는 일부 CSR이 승인될 때까지 사용할 수 없습니다.

4. 이제 클라이언트 요청이 승인되었으므로 클러스터에 추가한 각 머신의 서버 요청을 검토해야 합니다.

   $ oc get csr

   출력 예

   NAME        AGE     REQUESTOR                                                                   CONDITION
   csr-bfd72   5m26s   system:node:ip-10-0-50-126.us-east-2.compute.internal                       Pending
   csr-c57lv   5m26s   system:node:ip-10-0-95-157.us-east-2.compute.internal                       Pending
   ...

5. 나머지 CSR이 승인되지 않고 Pending 상태인 경우 클러스터 머신의 CSR을 승인합니다.

   • 개별적으로 승인하려면 유효한 CSR 각각에 대해 다음 명령을 실행하십시오.

     $ oc adm certificate approve <csr_name> 1

     1

     <csr_name>은 현재 CSR 목록에 있는 CSR의 이름입니다.

   • 보류 중인 CSR을 모두 승인하려면 다음 명령을 실행하십시오.

     $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approve

6. 모든 클라이언트 및 서버 CSR이 승인된 후 머신은 Ready 상태가 됩니다. 다음 명령을 실행하여 확인합니다.

   $ oc get nodes

   출력 예

   NAME      STATUS    ROLES   AGE  VERSION
   master-0  Ready     master  73m  v1.22.1
   master-1  Ready     master  73m  v1.22.1
   master-2  Ready     master  74m  v1.22.1
   worker-0  Ready     worker  11m  v1.22.1
   worker-1  Ready     worker  11m  v1.22.1

   참고

   머신이 Ready 상태로 전환하는 데 서버 CSR의 승인 후 몇 분이 걸릴 수 있습니다.

프로세스

1. 인그레스 라우터가 로드 밸런서를 생성하고 EXTERNAL-IP 필드를 채울 때까지 기다립니다.

   $ oc -n openshift-ingress get service router-default

   출력 예

   NAME             TYPE           CLUSTER-IP      EXTERNAL-IP      PORT(S)                      AGE
   router-default   LoadBalancer   172.30.18.154   35.233.157.184   80:32288/TCP,443:31215/TCP   98

2. 영역에 A 레코드를 추가합니다.

   • A 레코드를 사용하려면,

     1. 라우터 IP 주소에 대한 변수를 내보냅니다.

        $ export ROUTER_IP=`oc -n openshift-ingress get service router-default --no-headers | awk '{print $4}'`

     2. 프라이빗 영역에 A 레코드를 추가합니다.

        $ if [ -f transaction.yaml ]; then rm transaction.yaml; fi
        $ gcloud dns record-sets transaction start --zone ${INFRA_ID}-private-zone
        $ gcloud dns record-sets transaction add ${ROUTER_IP} --name \*.apps.${CLUSTER_NAME}.${BASE_DOMAIN}. --ttl 300 --type A --zone ${INFRA_ID}-private-zone
        $ gcloud dns record-sets transaction execute --zone ${INFRA_ID}-private-zone

     3. 외부 클러스터의 경우 퍼블릭 영역에 A 레코드를 추가합니다.

        $ if [ -f transaction.yaml ]; then rm transaction.yaml; fi
        $ gcloud dns record-sets transaction start --zone ${BASE_DOMAIN_ZONE_NAME}
        $ gcloud dns record-sets transaction add ${ROUTER_IP} --name \*.apps.${CLUSTER_NAME}.${BASE_DOMAIN}. --ttl 300 --type A --zone ${BASE_DOMAIN_ZONE_NAME}
        $ gcloud dns record-sets transaction execute --zone ${BASE_DOMAIN_ZONE_NAME}

   • 와일드카드를 사용하지 않고 명시적 도메인을 추가하려면 클러스터의 현재 경로에 대한 항목을 생성합니다.

     $ oc get --all-namespaces -o jsonpath='{range .items[*]}{range .status.ingress[*]}{.host}{"\n"}{end}{end}' routes

     출력 예

     oauth-openshift.apps.your.cluster.domain.example.com
     console-openshift-console.apps.your.cluster.domain.example.com
     downloads-openshift-console.apps.your.cluster.domain.example.com
     alertmanager-main-openshift-monitoring.apps.your.cluster.domain.example.com
     grafana-openshift-monitoring.apps.your.cluster.domain.example.com
     prometheus-k8s-openshift-monitoring.apps.your.cluster.domain.example.com

프로세스

1. 클러스터 설치를 완료합니다.

   $ ./openshift-install --dir <installation_directory> wait-for install-complete 1

   출력 예

   INFO Waiting up to 30m0s for the cluster to initialize...

   1

   <installation_directory>는 설치 파일을 저장한 디렉터리의 경로를 지정합니다.

   중요

   • 설치 프로그램에서 생성하는 Ignition 구성 파일에 24시간 후에 만료되는 인증서가 포함되어 있습니다. 이 인증서는 그 후에 갱신됩니다. 인증서를 갱신하기 전에 클러스터가 종료되고 24시간이 지난 후에 클러스터가 다시 시작되면 클러스터는 만료된 인증서를 자동으로 복구합니다. 예외적으로 kubelet 인증서를 복구하려면 대기 중인 node-bootstrapper 인증서 서명 요청(CSR)을 수동으로 승인해야 합니다. 자세한 내용은 Recovering from expired control plane certificates 문서를 참조하십시오.
   • 클러스터를 설치한 후 24시간에서 22시간까지의 인증서가 교체되기 때문에 생성된 후 12시간 이내에 Ignition 구성 파일을 사용하는 것이 좋습니다. 12시간 이내에 Ignition 구성 파일을 사용하면 설치 중에 인증서 업데이트가 실행되는 경우 설치 실패를 방지할 수 있습니다.

2. 클러스터의 실행 상태를 관찰합니다.

   1. 다음 명령을 실행하여 현재 클러스터 버전과 상태를 확인합니다.

      $ oc get clusterversion

      출력 예

      NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
      version             False       True          24m     Working towards 4.5.4: 99% complete

   2. 다음 명령을 실행하여 컨트롤 플레인에서 관리하되는 운영자를 CVO(Cluster Version Operator)별로 확인합니다.

      $ oc get clusteroperators

      출력 예

      NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
      authentication                             4.5.4     True        False         False      7m56s
      cloud-credential                           4.5.4     True        False         False      31m
      cluster-autoscaler                         4.5.4     True        False         False      16m
      console                                    4.5.4     True        False         False      10m
      csi-snapshot-controller                    4.5.4     True        False         False      16m
      dns                                        4.5.4     True        False         False      22m
      etcd                                       4.5.4     False       False         False      25s
      image-registry                             4.5.4     True        False         False      16m
      ingress                                    4.5.4     True        False         False      16m
      insights                                   4.5.4     True        False         False      17m
      kube-apiserver                             4.5.4     True        False         False      19m
      kube-controller-manager                    4.5.4     True        False         False      20m
      kube-scheduler                             4.5.4     True        False         False      20m
      kube-storage-version-migrator              4.5.4     True        False         False      16m
      machine-api                                4.5.4     True        False         False      22m
      machine-config                             4.5.4     True        False         False      22m
      marketplace                                4.5.4     True        False         False      16m
      monitoring                                 4.5.4     True        False         False      10m
      network                                    4.5.4     True        False         False      23m
      node-tuning                                4.5.4     True        False         False      23m
      openshift-apiserver                        4.5.4     True        False         False      17m
      openshift-controller-manager               4.5.4     True        False         False      15m
      openshift-samples                          4.5.4     True        False         False      16m
      operator-lifecycle-manager                 4.5.4     True        False         False      22m
      operator-lifecycle-manager-catalog         4.5.4     True        False         False      22m
      operator-lifecycle-manager-packageserver   4.5.4     True        False         False      18m
      service-ca                                 4.5.4     True        False         False      23m
      service-catalog-apiserver                  4.5.4     True        False         False      23m
      service-catalog-controller-manager         4.5.4     True        False         False      23m
      storage                                    4.5.4     True        False         False      17m

   3. 다음 명령어를 실행하여 클러스터 Pod를 확인합니다.

      $ oc get pods --all-namespaces

      출력 예

      NAMESPACE                                               NAME                                                                READY     STATUS      RESTARTS   AGE
      kube-system                                             etcd-member-ip-10-0-3-111.us-east-2.compute.internal                1/1       Running     0          35m
      kube-system                                             etcd-member-ip-10-0-3-239.us-east-2.compute.internal                1/1       Running     0          37m
      kube-system                                             etcd-member-ip-10-0-3-24.us-east-2.compute.internal                 1/1       Running     0          35m
      openshift-apiserver-operator                            openshift-apiserver-operator-6d6674f4f4-h7t2t                       1/1       Running     1          37m
      openshift-apiserver                                     apiserver-fm48r                                                     1/1       Running     0          30m
      openshift-apiserver                                     apiserver-fxkvv                                                     1/1       Running     0          29m
      openshift-apiserver                                     apiserver-q85nm                                                     1/1       Running     0          29m
      ...
      openshift-service-ca-operator                           openshift-service-ca-operator-66ff6dc6cd-9r257                      1/1       Running     0          37m
      openshift-service-ca                                    apiservice-cabundle-injector-695b6bcbc-cl5hm                        1/1       Running     0          35m
      openshift-service-ca                                    configmap-cabundle-injector-8498544d7-25qn6                         1/1       Running     0          35m
      openshift-service-ca                                    service-serving-cert-signer-6445fc9c6-wqdqn                         1/1       Running     0          35m
      openshift-service-catalog-apiserver-operator            openshift-service-catalog-apiserver-operator-549f44668b-b5q2w       1/1       Running     0          32m
      openshift-service-catalog-controller-manager-operator   openshift-service-catalog-controller-manager-operator-b78cr2lnm     1/1       Running     0          31m

   현재 클러스터 버전이 AVAILABLE이면 설치가 완료된 것입니다.