7.12. 사용자 프로비저닝 인프라가 있는 제한된 네트워크에서 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. 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이면 설치가 완료된 것입니다.