설치 후 구성

프로세스

1. Image Registry Operator 구성 오브젝트를 편집하고 networkAccess.type 을 Internal:로 설정합니다.

   $ oc edit configs.imageregistry/cluster

   # ...
   spec:
     # ...
      storage:
         azure:
           # ...
           networkAccess:
             type: Internal
   # ...

2. 선택 사항: Operator가 프로비저닝을 완료했는지 확인하려면 다음 명령을 입력합니다. 이 작업은 몇 분 정도 걸릴 수 있습니다.

   $ oc get configs.imageregistry/cluster -o=jsonpath="{.spec.storage.azure.privateEndpointName}" -w

3. 선택 사항: 경로에서 레지스트리를 노출하고 스토리지 계정을 비공개로 구성하는 경우 클러스터 외부의 가져오기를 계속 사용하려면 리디렉션을 비활성화해야 합니다. 다음 명령을 입력하여 Image Operator 구성에서 리디렉션을 비활성화합니다.

   $ oc patch configs.imageregistry cluster --type=merge -p '{"spec":{"disableRedirect": true}}'

   참고

   리디렉션이 활성화되면 클러스터 외부에서 이미지를 가져오지 않습니다.

검증

1. 다음 명령을 실행하여 레지스트리 서비스 이름을 가져옵니다.

   $ oc get imagestream -n openshift

   출력 예

   NAME   IMAGE REPOSITORY                                                 TAGS     UPDATED
   cli    image-registry.openshift-image-registry.svc:5000/openshift/cli   latest   8 hours ago
   ...

2. 다음 명령을 실행하여 디버그 모드를 시작합니다.

   $ oc debug node/<node_name>

3. 제안된 chroot 명령을 실행합니다. 예를 들면 다음과 같습니다.

   $ chroot /host

4. 다음 명령을 입력하여 컨테이너 레지스트리에 로그인합니다.

   $ podman login --tls-verify=false -u unused -p $(oc whoami -t) image-registry.openshift-image-registry.svc:5000

   출력 예

   Login Succeeded!

5. 다음 명령을 입력하여 레지스트리에서 이미지를 가져올 수 있는지 확인합니다.

   $ podman pull --tls-verify=false image-registry.openshift-image-registry.svc:5000/openshift/tools

   출력 예

   Trying to pull image-registry.openshift-image-registry.svc:5000/openshift/tools/openshift/tools...
   Getting image source signatures
   Copying blob 6b245f040973 done
   Copying config 22667f5368 done
   Writing manifest to image destination
   Storing signatures
   22667f53682a2920948d19c7133ab1c9c3f745805c14125859d20cede07f11f9

프로세스

1. Image Registry Operator 구성 오브젝트를 편집하고 VNet 및 서브넷 이름을 사용하여 프라이빗 끝점을 구성합니다.

   $ oc edit configs.imageregistry/cluster

   # ...
   spec:
     # ...
      storage:
         azure:
           # ...
           networkAccess:
             type: Internal
             internal:
               subnetName: <subnet_name>
               vnetName: <vnet_name>
               networkResourceGroupName: <network_resource_group_name>
   # ...

2. 선택 사항: Operator가 프로비저닝을 완료했는지 확인하려면 다음 명령을 입력합니다. 이 작업은 몇 분 정도 걸릴 수 있습니다.

   $ oc get configs.imageregistry/cluster -o=jsonpath="{.spec.storage.azure.privateEndpointName}" -w

   참고

   리디렉션이 활성화되면 클러스터 외부에서 이미지를 가져오지 않습니다.

검증

1. 다음 명령을 실행하여 레지스트리 서비스 이름을 가져옵니다.

   $ oc get imagestream -n openshift

   출력 예

   NAME   IMAGE REPOSITORY                                                 TAGS     UPDATED
   cli    image-registry.openshift-image-registry.svc:5000/openshift/cli   latest   8 hours ago
   ...

2. 다음 명령을 실행하여 디버그 모드를 시작합니다.

   $ oc debug node/<node_name>

3. 제안된 chroot 명령을 실행합니다. 예를 들면 다음과 같습니다.

   $ chroot /host

4. 다음 명령을 입력하여 컨테이너 레지스트리에 로그인합니다.

   $ podman login --tls-verify=false -u unused -p $(oc whoami -t) image-registry.openshift-image-registry.svc:5000

   출력 예

   Login Succeeded!

5. 다음 명령을 입력하여 레지스트리에서 이미지를 가져올 수 있는지 확인합니다.

   $ podman pull --tls-verify=false image-registry.openshift-image-registry.svc:5000/openshift/tools

   출력 예

   Trying to pull image-registry.openshift-image-registry.svc:5000/openshift/tools/openshift/tools...
   Getting image source signatures
   Copying blob 6b245f040973 done
   Copying config 22667f5368 done
   Writing manifest to image destination
   Storing signatures
   22667f53682a2920948d19c7133ab1c9c3f745805c14125859d20cede07f11f9

검증

1. 다음 명령을 실행하여 레지스트리 서비스 이름을 가져옵니다.

   $ oc get imagestream -n openshift

   출력 예

   NAME   IMAGE REPOSITORY                                           TAGS     UPDATED
   cli    default-route-openshift-image-registry.<cluster_dns>/cli   latest   8 hours ago
   ...

2. 다음 명령을 입력하여 컨테이너 레지스트리에 로그인합니다.

   $ podman login --tls-verify=false -u unused -p $(oc whoami -t) default-route-openshift-image-registry.<cluster_dns>

   출력 예

   Login Succeeded!

3. 다음 명령을 입력하여 레지스트리에서 이미지를 가져올 수 있는지 확인합니다.

   $ podman pull --tls-verify=false default-route-openshift-image-registry.<cluster_dns>
   /openshift/tools

   출력 예

   Trying to pull default-route-openshift-image-registry.<cluster_dns>/openshift/tools...
   Getting image source signatures
   Copying blob 6b245f040973 done
   Copying config 22667f5368 done
   Writing manifest to image destination
   Storing signatures
   22667f53682a2920948d19c7133ab1c9c3f745805c14125859d20cede07f11f9

프로세스

1. OpenShift CLI(oc)에 로그인합니다.

2. 다음 명령을 실행하여 클러스터에서 아키텍처 페이로드를 사용하는지 확인할 수 있습니다.

   $ oc adm release info -o jsonpath="{ .metadata.metadata}"

프로세스

1. Azure 계정에 로그인합니다.

   $ az login

2. 스토리지 계정을 생성하고 aarch64 가상 하드 디스크(VHD)를 스토리지 계정에 업로드합니다. OpenShift Container Platform 설치 프로그램은 리소스 그룹을 생성하지만 부팅 이미지는 사용자 지정 리소스 그룹에 업로드할 수도 있습니다.

   $ az storage account create -n ${STORAGE_ACCOUNT_NAME} -g ${RESOURCE_GROUP} -l westus --sku Standard_LRS 1

   1

   westus 오브젝트는 예제 영역입니다.

3. 생성한 스토리지 계정을 사용하여 스토리지 컨테이너를 생성합니다.

   $ az storage container create -n ${CONTAINER_NAME} --account-name ${STORAGE_ACCOUNT_NAME}

4. OpenShift Container Platform 설치 프로그램 JSON 파일을 사용하여 URL 및 aarch64 VHD 이름을 추출해야 합니다.

   1. URL 필드를 추출하고 다음 명령을 실행하여 RHCOS_VHD_ORIGIN_URL 을 파일 이름으로 설정합니다.

      $ RHCOS_VHD_ORIGIN_URL=$(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' | jq -r '.architectures.aarch64."rhel-coreos-extensions"."azure-disk".url')

   2. 다음 명령을 실행하여 aarch64 VHD 이름을 추출하고 파일 이름으로 BLOB_NAME 으로 설정합니다.

      $ BLOB_NAME=rhcos-$(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' | jq -r '.architectures.aarch64."rhel-coreos-extensions"."azure-disk".release')-azure.aarch64.vhd

5. 공유 액세스 서명(SAS) 토큰을 생성합니다. 다음 명령을 사용하여 RHCOS VHD를 스토리지 컨테이너에 업로드하려면 이 토큰을 사용합니다.

   $ end=`date -u -d "30 minutes" '+%Y-%m-%dT%H:%MZ'`

   $ sas=`az storage container generate-sas -n ${CONTAINER_NAME} --account-name ${STORAGE_ACCOUNT_NAME} --https-only --permissions dlrw --expiry $end -o tsv`

6. RHCOS VHD를 스토리지 컨테이너에 복사합니다.

   $ az storage blob copy start --account-name ${STORAGE_ACCOUNT_NAME} --sas-token "$sas" \
    --source-uri "${RHCOS_VHD_ORIGIN_URL}" \
    --destination-blob "${BLOB_NAME}" --destination-container ${CONTAINER_NAME}

   다음 명령을 사용하여 복사 프로세스의 상태를 확인할 수 있습니다.

   $ az storage blob show -c ${CONTAINER_NAME} -n ${BLOB_NAME} --account-name ${STORAGE_ACCOUNT_NAME} | jq .properties.copy

   출력 예

   {
    "completionTime": null,
    "destinationSnapshot": null,
    "id": "1fd97630-03ca-489a-8c4e-cfe839c9627d",
    "incrementalCopy": null,
    "progress": "17179869696/17179869696",
    "source": "https://rhcos.blob.core.windows.net/imagebucket/rhcos-411.86.202207130959-0-azure.aarch64.vhd",
    "status": "success", 1
    "statusDescription": null
   }

   1

   status 매개변수에 success 오브젝트가 표시되면 복사 프로세스가 완료됩니다.

7. 다음 명령을 사용하여 이미지 모음을 만듭니다.

   $ az sig create --resource-group ${RESOURCE_GROUP} --gallery-name ${GALLERY_NAME}

   이미지 모음을 사용하여 이미지 정의를 만듭니다. 다음 예제 명령에서 rhcos-arm64 는 이미지 정의의 이름입니다.

   $ az sig image-definition create --resource-group ${RESOURCE_GROUP} --gallery-name ${GALLERY_NAME} --gallery-image-definition rhcos-arm64 --publisher RedHat --offer arm --sku arm64 --os-type linux --architecture Arm64 --hyper-v-generation V2

8. VHD의 URL을 가져와서 파일 이름으로 RHCOS_VHD_URL 으로 설정하려면 다음 명령을 실행합니다.

   $ RHCOS_VHD_URL=$(az storage blob url --account-name ${STORAGE_ACCOUNT_NAME} -c ${CONTAINER_NAME} -n "${BLOB_NAME}" -o tsv)

9. RHCOS_VHD_URL 파일, 스토리지 계정, 리소스 그룹 및 이미지 뷰를 사용하여 이미지 버전을 생성합니다. 다음 예에서 1.0.0 은 이미지 버전입니다.

   $ az sig image-version create --resource-group ${RESOURCE_GROUP} --gallery-name ${GALLERY_NAME} --gallery-image-definition rhcos-arm64 --gallery-image-version 1.0.0 --os-vhd-storage-account ${STORAGE_ACCOUNT_NAME} --os-vhd-uri ${RHCOS_VHD_URL}

10. 이제 arm64 부팅 이미지가 생성됩니다. 다음 명령을 사용하여 이미지 ID에 액세스할 수 있습니다.

    $ az sig image-version show -r $GALLERY_NAME -g $RESOURCE_GROUP -i rhcos-arm64 -e 1.0.0

    다음 예제 이미지 ID는 컴퓨팅 머신 세트의 re courseID 매개변수에 사용됩니다.

    resourceID예

    /resourceGroups/${RESOURCE_GROUP}/providers/Microsoft.Compute/galleries/${GALLERY_NAME}/images/rhcos-arm64/versions/1.0.0

프로세스

1. 다음 명령을 실행하여 Azure 계정에 로그인합니다.

   $ az login

2. 스토리지 계정을 생성하고 다음 명령을 실행하여 x86_64 가상 하드 디스크(VHD)를 스토리지 계정에 업로드합니다. OpenShift Container Platform 설치 프로그램은 리소스 그룹을 생성합니다. 그러나 부팅 이미지는 사용자 지정 이름이 지정된 리소스 그룹에 업로드할 수도 있습니다.

   $ az storage account create -n ${STORAGE_ACCOUNT_NAME} -g ${RESOURCE_GROUP} -l westus --sku Standard_LRS 1

   1

   westus 오브젝트는 예제 영역입니다.

3. 다음 명령을 실행하여 생성한 스토리지 계정을 사용하여 스토리지 컨테이너를 생성합니다.

   $ az storage container create -n ${CONTAINER_NAME} --account-name ${STORAGE_ACCOUNT_NAME}

4. OpenShift Container Platform 설치 프로그램 JSON 파일을 사용하여 URL 및 x86_64 VHD 이름을 추출합니다.

   1. URL 필드를 추출하고 다음 명령을 실행하여 RHCOS_VHD_ORIGIN_URL 을 파일 이름으로 설정합니다.

      $ RHCOS_VHD_ORIGIN_URL=$(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' | jq -r '.architectures.x86_64."rhel-coreos-extensions"."azure-disk".url')

   2. x86_64 VHD 이름을 추출하고 다음 명령을 실행하여 파일 이름으로 BLOB_NAME 으로 설정합니다.

      $ BLOB_NAME=rhcos-$(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' | jq -r '.architectures.x86_64."rhel-coreos-extensions"."azure-disk".release')-azure.x86_64.vhd

5. 공유 액세스 서명(SAS) 토큰을 생성합니다. 다음 명령을 실행하여 RHCOS VHD를 스토리지 컨테이너에 업로드하려면 이 토큰을 사용합니다.

   $ end=`date -u -d "30 minutes" '+%Y-%m-%dT%H:%MZ'`

   $ sas=`az storage container generate-sas -n ${CONTAINER_NAME} --account-name ${STORAGE_ACCOUNT_NAME} --https-only --permissions dlrw --expiry $end -o tsv`

6. 다음 명령을 실행하여 RHCOS VHD를 스토리지 컨테이너에 복사합니다.

   $ az storage blob copy start --account-name ${STORAGE_ACCOUNT_NAME} --sas-token "$sas" \
    --source-uri "${RHCOS_VHD_ORIGIN_URL}" \
    --destination-blob "${BLOB_NAME}" --destination-container ${CONTAINER_NAME}

   다음 명령을 실행하여 복사 프로세스의 상태를 확인할 수 있습니다.

   $ az storage blob show -c ${CONTAINER_NAME} -n ${BLOB_NAME} --account-name ${STORAGE_ACCOUNT_NAME} | jq .properties.copy

   출력 예

   {
    "completionTime": null,
    "destinationSnapshot": null,
    "id": "1fd97630-03ca-489a-8c4e-cfe839c9627d",
    "incrementalCopy": null,
    "progress": "17179869696/17179869696",
    "source": "https://rhcos.blob.core.windows.net/imagebucket/rhcos-411.86.202207130959-0-azure.aarch64.vhd",
    "status": "success", 1
    "statusDescription": null
   }

   1

   status 매개변수에 success 오브젝트가 표시되면 복사 프로세스가 완료됩니다.

7. 다음 명령을 실행하여 이미지 모음을 만듭니다.

   $ az sig create --resource-group ${RESOURCE_GROUP} --gallery-name ${GALLERY_NAME}

8. 이미지 모음을 사용하여 다음 명령을 실행하여 이미지 정의를 만듭니다.

   $ az sig image-definition create --resource-group ${RESOURCE_GROUP} --gallery-name ${GALLERY_NAME} --gallery-image-definition rhcos-x86_64 --publisher RedHat --offer x86_64 --sku x86_64 --os-type linux --architecture x64 --hyper-v-generation V2

   이 예제 명령에서 rhcos-x86_64 는 이미지 정의의 이름입니다.

9. VHD의 URL을 가져와서 파일 이름으로 RHCOS_VHD_URL 으로 설정하려면 다음 명령을 실행합니다.

   $ RHCOS_VHD_URL=$(az storage blob url --account-name ${STORAGE_ACCOUNT_NAME} -c ${CONTAINER_NAME} -n "${BLOB_NAME}" -o tsv)

10. RHCOS_VHD_URL 파일, 스토리지 계정, 리소스 그룹 및 이미지 개요를 사용하여 다음 명령을 실행하여 이미지 버전을 생성합니다.

    $ az sig image-version create --resource-group ${RESOURCE_GROUP} --gallery-name ${GALLERY_NAME} --gallery-image-definition rhcos-arm64 --gallery-image-version 1.0.0 --os-vhd-storage-account ${STORAGE_ACCOUNT_NAME} --os-vhd-uri ${RHCOS_VHD_URL}

    이 예에서 1.0.0 은 이미지 버전입니다.

11. 선택 사항: 다음 명령을 실행하여 생성된 x86_64 부팅 이미지의 ID에 액세스합니다.

    $ az sig image-version show -r $GALLERY_NAME -g $RESOURCE_GROUP -i rhcos-x86_64 -e 1.0.0

    다음 예제 이미지 ID는 컴퓨팅 머신 세트의 re courseID 매개변수에 사용됩니다.

    resourceID예

    /resourceGroups/${RESOURCE_GROUP}/providers/Microsoft.Compute/galleries/${GALLERY_NAME}/images/rhcos-x86_64/versions/1.0.0

프로세스

1. OpenShift CLI(oc)에 로그인합니다.

2. YAML 파일을 생성하고 클러스터에서 64비트 ARM 또는 64비트 x86 컴퓨팅 노드를 제어하는 컴퓨팅 머신 세트를 생성하는 구성을 추가합니다.

   Azure 64비트 ARM 또는 64비트 x86 컴퓨팅 노드의 MachineSet 오브젝트의 예

   apiVersion: machine.openshift.io/v1beta1
   kind: MachineSet
   metadata:
     labels:
       machine.openshift.io/cluster-api-cluster: <infrastructure_id>
       machine.openshift.io/cluster-api-machine-role: worker
       machine.openshift.io/cluster-api-machine-type: worker
     name: <infrastructure_id>-machine-set-0
     namespace: openshift-machine-api
   spec:
     replicas: 2
     selector:
       matchLabels:
         machine.openshift.io/cluster-api-cluster: <infrastructure_id>
         machine.openshift.io/cluster-api-machineset: <infrastructure_id>-machine-set-0
     template:
       metadata:
         labels:
           machine.openshift.io/cluster-api-cluster: <infrastructure_id>
           machine.openshift.io/cluster-api-machine-role: worker
           machine.openshift.io/cluster-api-machine-type: worker
           machine.openshift.io/cluster-api-machineset: <infrastructure_id>-machine-set-0
       spec:
         lifecycleHooks: {}
         metadata: {}
         providerSpec:
           value:
             acceleratedNetworking: true
             apiVersion: machine.openshift.io/v1beta1
             credentialsSecret:
               name: azure-cloud-credentials
               namespace: openshift-machine-api
             image:
               offer: ""
               publisher: ""
               resourceID: /resourceGroups/${RESOURCE_GROUP}/providers/Microsoft.Compute/galleries/${GALLERY_NAME}/images/rhcos-arm64/versions/1.0.0 1
               sku: ""
               version: ""
             kind: AzureMachineProviderSpec
             location: <region>
             managedIdentity: <infrastructure_id>-identity
             networkResourceGroup: <infrastructure_id>-rg
             osDisk:
               diskSettings: {}
               diskSizeGB: 128
               managedDisk:
                 storageAccountType: Premium_LRS
               osType: Linux
             publicIP: false
             publicLoadBalancer: <infrastructure_id>
             resourceGroup: <infrastructure_id>-rg
             subnet: <infrastructure_id>-worker-subnet
             userDataSecret:
               name: worker-user-data
             vmSize: Standard_D4ps_v5 2
             vnet: <infrastructure_id>-vnet
             zone: "<zone>"

   1

   resourceID 매개변수를 arm64 또는 amd64 부팅 이미지로 설정합니다.

   2

   vmSize 매개변수를 설치에 사용되는 인스턴스 유형으로 설정합니다. 일부 인스턴스 유형은 Standard_D4ps_v5 또는 D8ps 입니다.

3. 다음 명령을 실행하여 컴퓨팅 머신 세트를 생성합니다.

   $ oc create -f <file_name> 1

   1

   & lt;file_name >을 YAML 파일의 이름으로 컴퓨팅 머신 세트 구성으로 바꿉니다. 예: arm64-machine-set-0.yaml 또는 amd64-machine-set-0.yaml.

검증

1. 다음 명령을 실행하여 새 머신이 실행 중인지 확인합니다.

   $ oc get machineset -n openshift-machine-api

   출력에 생성한 머신 세트가 포함되어야 합니다.

   출력 예

   NAME                                                DESIRED  CURRENT  READY  AVAILABLE  AGE
   <infrastructure_id>-machine-set-0                   2        2      2          2  10m

2. 다음 명령을 실행하여 노드가 준비되고 예약 가능한지 확인할 수 있습니다.

   $ oc get nodes

프로세스

1. OpenShift CLI(oc)에 로그인합니다.

2. 다음 명령을 실행하여 클러스터에서 아키텍처 페이로드를 사용하는지 확인할 수 있습니다.

   $ oc adm release info -o jsonpath="{ .metadata.metadata}"

프로세스

1. OpenShift CLI(oc)에 로그인합니다.

2. YAML 파일을 생성하고 클러스터에서 64비트 ARM 또는 64비트 x86 컴퓨팅 노드를 제어하는 컴퓨팅 머신 세트를 생성하는 구성을 추가합니다.

   AWS 64비트 ARM 또는 x86 컴퓨팅 노드의 MachineSet 오브젝트의 예

   apiVersion: machine.openshift.io/v1beta1
   kind: MachineSet
   metadata:
     labels:
       machine.openshift.io/cluster-api-cluster: <infrastructure_id> 1
     name: <infrastructure_id>-aws-machine-set-0 2
     namespace: openshift-machine-api
   spec:
     replicas: 1
     selector:
       matchLabels:
         machine.openshift.io/cluster-api-cluster: <infrastructure_id> 3
         machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>-<zone> 4
     template:
       metadata:
         labels:
           machine.openshift.io/cluster-api-cluster: <infrastructure_id>
           machine.openshift.io/cluster-api-machine-role: <role> 5
           machine.openshift.io/cluster-api-machine-type: <role> 6
           machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>-<zone> 7
       spec:
         metadata:
           labels:
             node-role.kubernetes.io/<role>: ""
         providerSpec:
           value:
             ami:
               id: ami-02a574449d4f4d280 8
             apiVersion: awsproviderconfig.openshift.io/v1beta1
             blockDevices:
               - ebs:
                   iops: 0
                   volumeSize: 120
                   volumeType: gp2
             credentialsSecret:
               name: aws-cloud-credentials
             deviceIndex: 0
             iamInstanceProfile:
               id: <infrastructure_id>-worker-profile 9
             instanceType: m6g.xlarge 10
             kind: AWSMachineProviderConfig
             placement:
               availabilityZone: us-east-1a 11
               region: <region> 12
             securityGroups:
               - filters:
                   - name: tag:Name
                     values:
                       - <infrastructure_id>-node 13
             subnet:
               filters:
                 - name: tag:Name
                   values:
                     - <infrastructure_id>-subnet-private-<zone>
             tags:
               - name: kubernetes.io/cluster/<infrastructure_id> 14
                 value: owned
               - name: <custom_tag_name>
                 value: <custom_tag_value>
             userDataSecret:
               name: worker-user-data

   1 2 3 9 13 14

   클러스터를 프로비저닝할 때 설정한 클러스터 ID를 기반으로 하는 인프라 ID를 지정합니다. OpenShift CLI (oc) 패키지가 설치되어 있으면 다음 명령을 실행하여 인프라 ID를 얻을 수 있습니다.

   $ oc get -o jsonpath="{.status.infrastructureName}{'\n'}" infrastructure cluster

   4 7

   인프라 ID, 역할 노드 레이블 및 영역을 지정합니다.

   5 6

   추가할 역할 노드 레이블을 지정합니다.

   8

   노드의 AWS 리전의 RHCOS(Red Hat Enterprise Linux CoreOS) Amazon 머신 이미지(AMI)를 지정합니다. RHCOS AMI는 머신 아키텍처와 호환되어야 합니다.

   $ oc get configmap/coreos-bootimages \
   	  -n openshift-machine-config-operator \
   	  -o jsonpath='{.data.stream}' | jq \
   	  -r '.architectures.<arch>.images.aws.regions."<region>".image'

   10

   선택한 AMI의 CPU 아키텍처에 맞는 머신 유형을 지정합니다. 자세한 내용은 "AWS 64비트 ARM용 테스트 인스턴스 유형"을 참조하십시오.

   11

   영역을 지정합니다. 예를 들면 us-east-1a 입니다. 선택한 영역에 필요한 아키텍처가 있는 시스템이 있는지 확인합니다.

   12

   리전을 지정합니다. 예를 들면 us-east-1 입니다. 선택한 영역에 필요한 아키텍처가 있는 시스템이 있는지 확인합니다.

3. 다음 명령을 실행하여 컴퓨팅 머신 세트를 생성합니다.

   $ oc create -f <file_name> 1

   1

   & lt;file_name >을 YAML 파일의 이름으로 컴퓨팅 머신 세트 구성으로 바꿉니다. 예: aws-arm64-machine-set-0.yaml 또는 aws-amd64-machine-set-0.yaml.

검증

1. 다음 명령을 실행하여 컴퓨팅 머신 세트 목록을 확인합니다.

   $ oc get machineset -n openshift-machine-api

   출력에 생성한 머신 세트가 포함되어야 합니다.

   출력 예

   NAME                                                DESIRED  CURRENT  READY  AVAILABLE  AGE
   <infrastructure_id>-aws-machine-set-0                   2        2      2          2  10m

2. 다음 명령을 실행하여 노드가 준비되고 예약 가능한지 확인할 수 있습니다.

   $ oc get nodes

프로세스

1. OpenShift CLI(oc)에 로그인합니다.

2. 다음 명령을 실행하여 클러스터에서 아키텍처 페이로드를 사용하는지 확인할 수 있습니다.

   $ oc adm release info -o jsonpath="{ .metadata.metadata}"

프로세스

1. OpenShift CLI(oc)에 로그인합니다.

2. YAML 파일을 생성하고 클러스터에서 64비트 ARM 또는 64비트 x86 컴퓨팅 노드를 제어하는 컴퓨팅 머신 세트를 생성하는 구성을 추가합니다.

   GCP 64비트 ARM 또는 64비트 x86 컴퓨팅 노드의 MachineSet 오브젝트 예

   apiVersion: machine.openshift.io/v1beta1
   kind: MachineSet
   metadata:
     labels:
       machine.openshift.io/cluster-api-cluster: <infrastructure_id> 1
     name: <infrastructure_id>-w-a
     namespace: openshift-machine-api
   spec:
     replicas: 1
     selector:
       matchLabels:
         machine.openshift.io/cluster-api-cluster: <infrastructure_id>
         machine.openshift.io/cluster-api-machineset: <infrastructure_id>-w-a
     template:
       metadata:
         creationTimestamp: null
         labels:
           machine.openshift.io/cluster-api-cluster: <infrastructure_id>
           machine.openshift.io/cluster-api-machine-role: <role> 2
           machine.openshift.io/cluster-api-machine-type: <role>
           machine.openshift.io/cluster-api-machineset: <infrastructure_id>-w-a
       spec:
         metadata:
           labels:
             node-role.kubernetes.io/<role>: ""
         providerSpec:
           value:
             apiVersion: gcpprovider.openshift.io/v1beta1
             canIPForward: false
             credentialsSecret:
               name: gcp-cloud-credentials
             deletionProtection: false
             disks:
             - autoDelete: true
               boot: true
               image: <path_to_image> 3
               labels: null
               sizeGb: 128
               type: pd-ssd
             gcpMetadata: 4
             - key: <custom_metadata_key>
               value: <custom_metadata_value>
             kind: GCPMachineProviderSpec
             machineType: n1-standard-4 5
             metadata:
               creationTimestamp: null
             networkInterfaces:
             - network: <infrastructure_id>-network
               subnetwork: <infrastructure_id>-worker-subnet
             projectID: <project_name> 6
             region: us-central1 7
             serviceAccounts:
             - email: <infrastructure_id>-w@<project_name>.iam.gserviceaccount.com
               scopes:
               - https://www.googleapis.com/auth/cloud-platform
             tags:
               - <infrastructure_id>-worker
             userDataSecret:
               name: worker-user-data
             zone: us-central1-a

   1

   클러스터를 프로비저닝할 때 설정한 클러스터 ID를 기반으로 하는 인프라 ID를 지정합니다. 다음 명령을 실행하여 인프라 ID를 가져올 수 있습니다.

   $ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster

   2

   추가할 역할 노드 레이블을 지정합니다.

   3

   현재 컴퓨팅 머신 세트에 사용되는 이미지의 경로를 지정합니다. 이미지 경로에 프로젝트 및 이미지 이름이 필요합니다.

   프로젝트 및 이미지 이름에 액세스하려면 다음 명령을 실행합니다.

   $ oc get configmap/coreos-bootimages \
     -n openshift-machine-config-operator \
     -o jsonpath='{.data.stream}' | jq \
     -r '.architectures.aarch64.images.gcp'

   출력 예

     "gcp": {
       "release": "415.92.202309142014-0",
       "project": "rhcos-cloud",
       "name": "rhcos-415-92-202309142014-0-gcp-aarch64"
     }

   출력의 project 및 name 매개변수를 사용하여 머신 세트의 이미지 필드 경로를 생성합니다. 이미지 경로는 다음 형식을 따라야 합니다.

   $ projects/<project>/global/images/<image_name>

   4

   선택 사항: key:value 쌍 형식으로 사용자 지정 메타데이터를 지정합니다. 사용 사례의 예는 사용자 정의 메타데이터 설정에 대한 GCP 설명서를 참조하십시오.

   5

   선택한 OS 이미지의 CPU 아키텍처에 맞는 머신 유형을 지정합니다. 자세한 내용은 "64비트 ARM 인프라에서 GCP의 인스턴스 유형 테스트"을 참조하십시오.

   6

   클러스터에 사용하는 GCP 프로젝트의 이름을 지정합니다.

   7

   리전을 지정합니다. 예를 들면 us-central1 입니다. 선택한 영역에 필요한 아키텍처가 있는 시스템이 있는지 확인합니다.

3. 다음 명령을 실행하여 컴퓨팅 머신 세트를 생성합니다.

   $ oc create -f <file_name> 1

   1

   & lt;file_name >을 YAML 파일의 이름으로 컴퓨팅 머신 세트 구성으로 바꿉니다. 예: gcp-arm64-machine-set-0.yaml 또는 gcp-amd64-machine-set-0.yaml.

검증

1. 다음 명령을 실행하여 컴퓨팅 머신 세트 목록을 확인합니다.

   $ oc get machineset -n openshift-machine-api

   출력에 생성한 머신 세트가 포함되어야 합니다.

   출력 예

   NAME                                                DESIRED  CURRENT  READY  AVAILABLE  AGE
   <infrastructure_id>-gcp-machine-set-0                   2        2      2          2  10m

2. 다음 명령을 실행하여 노드가 준비되고 예약 가능한지 확인할 수 있습니다.

   $ oc get nodes

프로세스

1. OpenShift CLI(oc)에 로그인합니다.

2. 다음 명령을 실행하여 클러스터에서 아키텍처 페이로드를 사용하는지 확인할 수 있습니다.

   $ oc adm release info -o jsonpath="{ .metadata.metadata}"

프로세스

1. 다음 명령을 실행하여 클러스터에서 Ignition 구성 파일을 추출합니다.

   $ oc extract -n openshift-machine-api secret/worker-user-data-managed --keys=userData --to=- > worker.ign

2. 클러스터에서 내보낸 worker.ign Ignition 구성 파일을 HTTP 서버로 업로드합니다. 해당 파일의 URL을 기록해 둡니다.

3. Ignition 파일을 URL에서 사용할 수 있는지 확인할 수 있습니다. 다음 예제에서는 컴퓨팅 노드에 대한 Ignition 구성 파일을 가져옵니다.

   $ curl -k http://<HTTP_server>/worker.ign

4. 다음 명령으로 실행하여 새 머신을 부팅하기 위해 ISO 이미지에 액세스할 수 있습니다.

   RHCOS_VHD_ORIGIN_URL=$(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' | jq -r '.architectures.<architecture>.artifacts.metal.formats.iso.disk.location')

5. ISO 파일을 사용하여 추가 컴퓨팅 머신에 RHCOS를 설치합니다. 클러스터를 설치하기 전에 머신을 만들 때 사용한 것과 동일한 방법을 사용합니다.

   • ISO 이미지를 디스크에 굽고 직접 부팅합니다.
   • LOM 인터페이스에서 ISO 리디렉션을 사용합니다.

6. 옵션을 지정하거나 라이브 부팅 시퀀스를 중단하지 않고 RHCOS ISO 이미지를 부팅합니다. 설치 프로그램이 RHCOS 라이브 환경에서 쉘 프롬프트로 부팅될 때까지 기다립니다.

   참고

   RHCOS 설치 부팅 프로세스를 중단하여 커널 인수를 추가할 수 있습니다. 그러나 이 ISO 절차에서는 커널 인수를 추가하는 대신 다음 단계에 설명된 대로 coreos-installer 명령을 사용해야 합니다.

7. coreos-installer 명령을 실행하고 설치 요구 사항을 충족하는 옵션을 지정합니다. 최소한 노드 유형에 대한 Ignition 구성 파일과 설치할 장치를 가리키는 URL을 지정해야 합니다.

   $ sudo coreos-installer install --ignition-url=http://<HTTP_server>/<node_type>.ign <device> --ignition-hash=sha512-<digest> 12

   1

   core 사용자에게 설치를 수행하는 데 필요한 root 권한이 없으므로 sudo를 사용하여 coreos-installer 명령을 실행해야 합니다.

   2

   클러스터 노드에서 Ignition 구성 파일을 HTTP URL을 통해 가져오려면 --ignition-hash 옵션이 필요합니다. <digest>는 이전 단계에서 얻은 Ignition 구성 파일 SHA512 다이제스트입니다.

   참고

   TLS를 사용하는 HTTPS 서버를 통해 Ignition 구성 파일을 제공하려는 경우 coreos-installer를 실행하기 전에 내부 인증 기관(CA)을 시스템 신뢰 저장소에 추가할 수 있습니다.

   다음 예제에서는 /dev/sda 장치에 부트스트랩 노드 설치를 초기화합니다. 부트스트랩 노드의 Ignition 구성 파일은 IP 주소 192.168.1.2가 있는 HTTP 웹 서버에서 가져옵니다.

   $ sudo coreos-installer install --ignition-url=http://192.168.1.2:80/installation_directory/bootstrap.ign /dev/sda --ignition-hash=sha512-a5a2d43879223273c9b60af66b44202a1d1248fc01cf156c46d4a79f552b6bad47bc8cc78ddf0116e80c59d2ea9e32ba53bc807afbca581aa059311def2c3e3b

8. 머신 콘솔에서 RHCOS 설치 진행률을 모니터링합니다.

   중요

   OpenShift Container Platform 설치를 시작하기 전에 각 노드에서 성공적으로 설치되었는지 확인합니다. 설치 프로세스를 관찰하면 발생할 수 있는 RHCOS 설치 문제의 원인을 파악하는 데 도움이 될 수 있습니다.

9. 계속해서 클러스터에 추가 컴퓨팅 머신을 만듭니다.

프로세스

1. RHCOS 이미지의 PXE 또는 iPXE가 올바르게 설치되었는지 확인합니다.

   • PXE의 경우:

     DEFAULT pxeboot
     TIMEOUT 20
     PROMPT 0
     LABEL pxeboot
         KERNEL http://<HTTP_server>/rhcos-<version>-live-kernel-<architecture> 1
         APPEND initrd=http://<HTTP_server>/rhcos-<version>-live-initramfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/worker.ign coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img 2

     1

     HTTP 서버에 업로드한 라이브 kernel 파일의 위치를 지정합니다.

     2

     HTTP 서버에 업로드한 RHCOS 파일의 위치를 지정합니다. initrd 매개변수 값은 initramfs 파일의 위치이고 coreos.inst.ignition_url 매개변수 값은 작업자 Ignition 설정 파일의 위치이며 coreos.live.rootfs_url 매개 변수 값은 라이브 rootfs 파일의 위치입니다. coreos.inst.ignition_url 및 coreos.live.rootfs_url 매개변수는 HTTP 및 HTTPS만 지원합니다.

     참고

     이 구성은 그래픽 콘솔이 있는 시스템에서 직렬 콘솔 액세스를 활성화하지 않습니다. 다른 콘솔을 구성하려면 APPEND 행에 하나 이상의 console= 인수를 추가합니다. 예를 들어 console=tty0 console=ttyS0을 추가하여 첫 번째 PC 직렬 포트를 기본 콘솔로 설정하고 그래픽 콘솔을 보조 콘솔로 설정합니다. 자세한 내용은 Red Hat Enterprise Linux에서 직렬 터미널 및/또는 콘솔 설정 방법을 참조하십시오.

   • iPXE (x86_64 + aarch64)의 경우:

     kernel http://<HTTP_server>/rhcos-<version>-live-kernel-<architecture> initrd=main coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/worker.ign 1 2
     initrd --name main http://<HTTP_server>/rhcos-<version>-live-initramfs.<architecture>.img 3
     boot

     1

     HTTP 서버에 업로드한 RHCOS 파일의 위치를 지정합니다. kernel 매개변수 값은 커널 파일의 위치이며 initrd=main 인수는 UEFI 시스템에서 부팅하는 데 필요하며 coreos.live.rootfs_url 매개변수 값은 rootfs 파일의 위치이며 coreos.inst.ignition_url 매개변수 값은 작업자 Ignition 구성 파일의 위치입니다.

     2

     NIC를 여러 개 사용하는 경우 ip 옵션에 단일 인터페이스를 지정합니다. 예를 들어, eno1라는 NIC에서 DHCP를 사용하려면 ip=eno1:dhcp를 설정하십시오.

     3

     HTTP 서버에 업로드한 initramfs 파일의 위치를 지정합니다.

     참고

     이 구성은 그래픽 콘솔이 있는 머신에서 직렬 콘솔 액세스를 활성화하지 않습니다. 다른 콘솔을 구성하려면 kernel 행에 하나 이상의 console= 인수를 추가합니다. 예를 들어 console=tty0 console=ttyS0을 추가하여 첫 번째 PC 직렬 포트를 기본 콘솔로 설정하고 그래픽 콘솔을 보조 콘솔로 설정합니다. 자세한 내용은 How does one set up a serial terminal and/or console in Red Hat Enterprise Linux? 및 "Enabling the serial console for PXE and ISO installation" 섹션을 참조하십시오.

     참고

     aarch64 아키텍처에서 CoreOS kernel 을 부팅하려면 IMAGE_GZIP 옵션이 활성화된 iPXE 빌드 버전을 사용해야 합니다. iPXE의IMAGE_GZIP 옵션을 참조하십시오.

   • aarch64 에서 PXE ( UEFI 및 GRUB를 두 번째 단계로 사용)의 경우 :

     menuentry 'Install CoreOS' {
         linux rhcos-<version>-live-kernel-<architecture>  coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/worker.ign 1 2
         initrd rhcos-<version>-live-initramfs.<architecture>.img 3
     }

     1

     HTTP/TFTP 서버에 업로드한 RHCOS 파일의 위치를 지정합니다. kernel 매개변수 값은 TFTP 서버의 파일의 위치입니다. coreos.live.rootfs_url 매개변수 값은 rootfs 파일의 위치이며 coreos.inst.ignition_url 매개변수 값은 HTTP Server의 작업자 Ignition 구성 파일의 위치입니다.

     2

     NIC를 여러 개 사용하는 경우 ip 옵션에 단일 인터페이스를 지정합니다. 예를 들어, eno1라는 NIC에서 DHCP를 사용하려면 ip=eno1:dhcp를 설정하십시오.

     3

     TFTP 서버에 업로드한 initramfs 파일의 위치를 지정합니다.

2. PXE 또는 iPXE 인프라를 사용하여 클러스터에 필요한 컴퓨팅 머신을 만듭니다.

프로세스

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

   $ oc get nodes

   출력 예

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

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

   참고

   이전 출력에는 일부 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.30.3
   master-1  Ready     master  73m  v1.30.3
   master-2  Ready     master  74m  v1.30.3
   worker-0  Ready     worker  11m  v1.30.3
   worker-1  Ready     worker  11m  v1.30.3

   참고

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

프로세스

1. OpenShift CLI(oc)에 로그인합니다.

2. 다음 명령을 실행하여 클러스터에서 아키텍처 페이로드를 사용하는지 확인할 수 있습니다.

   $ oc adm release info -o jsonpath="{ .metadata.metadata}"

프로세스

1. 다음 명령을 실행하여 클러스터에서 Ignition 구성 파일을 추출합니다.

   $ oc extract -n openshift-machine-api secret/worker-user-data-managed --keys=userData --to=- > worker.ign

2. 클러스터에서 내보낸 worker.ign Ignition 구성 파일을 HTTP 서버로 업로드합니다. 이 파일의 URL을 기록해 둡니다.

3. Ignition 파일이 URL에서 사용 가능한지 확인할 수 있습니다. 다음 예제에서는 컴퓨팅 노드에 대한 Ignition 구성 파일을 가져옵니다.

   $ curl -k http://<http_server>/worker.ign

4. 다음 명령을 실행하여 RHEL 라이브 커널,initramfs, rootfs 파일을 다운로드합니다.

   $ curl -LO $(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' \
   | jq -r '.architectures.s390x.artifacts.metal.formats.pxe.kernel.location')

   $ curl -LO $(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' \
   | jq -r '.architectures.s390x.artifacts.metal.formats.pxe.initramfs.location')

   $ curl -LO $(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' \
   | jq -r '.architectures.s390x.artifacts.metal.formats.pxe.rootfs.location')

5. 다운로드한 RHEL 라이브 커널,initramfs 및 rootfs 파일을 추가하려는 RHCOS 게스트에서 액세스할 수 있는 HTTP 또는 HTTPS 서버로 이동합니다.

6. 게스트에 대한 매개변수 파일을 생성합니다. 다음 매개변수는 가상 머신에 고유합니다.

   • 선택 사항: 고정 IP 주소를 지정하려면 각각 콜론으로 구분된 다음 항목이 포함된 ip= 매개변수를 추가합니다.

     1. 컴퓨터의 IP 주소
     2. 빈 문자열
     3. 게이트웨이
     4. 넷 마스크
     5. hostname.domainname 형식의 시스템 호스트 및 도메인 이름. RHCOS가 설정하도록 하려면 이 값을 생략하십시오.
     6. 네트워크 인터페이스 이름. RHCOS가 설정하도록 하려면 이 값을 생략하십시오.
     7. 값이 없음입니다.
   • coreos.inst.ignition_url= 의 경우 worker.ign 파일의 URL을 지정합니다. HTTP 및 HTTPS 프로토콜만 지원됩니다.
   • coreos.live.rootfs_url= 의 경우 부팅 중인 커널 및 initramfs 와 일치하는 rootfs 아티팩트를 지정합니다. HTTP 및 HTTPS 프로토콜만 지원됩니다.

   • DASD 유형 디스크에 설치하려면 다음 작업을 완료합니다.

     1. coreos.inst.install_dev= 의 경우 /dev/dasda 를 지정합니다.
     2. rd.dasd=의 경우 RHCOS를 설치할 DASD를 지정합니다.

     3. 필요한 경우 추가 매개변수를 조정할 수 있습니다.

        다음은 추가-worker-dasd.parm 매개변수 파일 예제입니다.

        cio_ignore=all,!condev rd.neednet=1 \
        console=ttysclp0 \
        coreos.inst.install_dev=/dev/dasda \
        coreos.inst.ignition_url=http://<http_server>/worker.ign \
        coreos.live.rootfs_url=http://<http_server>/rhcos-<version>-live-rootfs.<architecture>.img \
        ip=<ip>::<gateway>:<netmask>:<hostname>::none nameserver=<dns> \
        rd.znet=qeth,0.0.bdf0,0.0.bdf1,0.0.bdf2,layer2=1,portno=0 \
        rd.dasd=0.0.3490 \
        zfcp.allow_lun_scan=0

        매개 변수 파일의 모든 옵션을 한 줄로 작성하고 줄 바꿈 문자가 없는지 확인합니다.

   • FCP 유형 디스크에 설치하려면 다음 작업을 완료합니다.

     1. RHCOS를 설치할 FCP 디스크를 지정하려면 rd.zfcp=<adapter>,<wwpn>,<lun>을 사용합니다. 다중 경로의 경우 추가 경로마다 이 단계를 반복합니다.

        참고

        여러 경로를 사용하여 설치할 때 나중에 문제가 발생할 수 있으므로 설치 후에 직접 멀티패스를 활성화해야 합니다.

     2. 설치 장치를 coreos.inst.install_dev=/dev/sda 로 설정합니다.

        참고

        NPIV로 추가 LUN을 구성하는 경우 FCP에는 zfcp.allow_lun_scan=0이 필요합니다. 예를 들어 CSI 드라이버를 사용하므로 zfcp.allow_lun_scan=1 을 활성화해야 하는 경우, 각 노드가 다른 노드의 부팅 파티션에 액세스할 수 없도록 NPIV를 구성해야 합니다.

     3. 필요한 경우 추가 매개변수를 조정할 수 있습니다.

        중요

        멀티패스를 완전히 활성화하려면 추가 설치 후 단계가 필요합니다. 자세한 내용은 머신 구성 의 "RHCOS에서 커널 인수를 사용하여 멀티패스 활성화"를 참조하십시오.

        다음은 다중 경로가 있는 작업자 노드의 additional-worker-fcp.parm 매개변수 파일 예제입니다.

        cio_ignore=all,!condev rd.neednet=1 \
        console=ttysclp0 \
        coreos.inst.install_dev=/dev/sda \
        coreos.live.rootfs_url=http://<http_server>/rhcos-<version>-live-rootfs.<architecture>.img \
        coreos.inst.ignition_url=http://<http_server>/worker.ign \
        ip=<ip>::<gateway>:<netmask>:<hostname>::none nameserver=<dns> \
        rd.znet=qeth,0.0.bdf0,0.0.bdf1,0.0.bdf2,layer2=1,portno=0 \
        zfcp.allow_lun_scan=0 \
        rd.zfcp=0.0.1987,0x50050763070bc5e3,0x4008400B00000000 \
        rd.zfcp=0.0.19C7,0x50050763070bc5e3,0x4008400B00000000 \
        rd.zfcp=0.0.1987,0x50050763071bc5e3,0x4008400B00000000 \
        rd.zfcp=0.0.19C7,0x50050763071bc5e3,0x4008400B00000000

        매개 변수 파일의 모든 옵션을 한 줄로 작성하고 줄 바꿈 문자가 없는지 확인합니다.

7. FTP를 사용하여 initramfs,커널, 매개 변수 파일 및 RHCOS 이미지를 z/VM으로 전송합니다. FTP를 사용하여 파일을 전송하고 가상 리더에서 부팅 하는 방법에 대한 자세한 내용은 IBM Z®에 설치 부팅을 참조하여 z/VM에 RHEL을 설치하는 방법을 참조하십시오.

8. z/VM 게스트 가상 머신의 가상 리더에 파일을 punch합니다.

   IBM® 문서의 PUNCH 를 참조하십시오.

   작은 정보

   CP PUNCH 명령을 사용하거나 Linux를 사용하는 경우 vmur 명령을 사용하여 두 개의 z/VM 게스트 가상 머신간에 파일을 전송할 수 있습니다.

9. 부트스트랩 시스템에서 CMS에 로그인합니다.

10. 다음 명령을 실행하여 리더의 부트스트랩 시스템을 IPL합니다.

    $ ipl c

    IBM® 문서의 IPL 을 참조하십시오.

프로세스

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

   $ oc get nodes

   출력 예

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

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

   참고

   이전 출력에는 일부 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.30.3
   master-1  Ready     master  73m  v1.30.3
   master-2  Ready     master  74m  v1.30.3
   worker-0  Ready     worker  11m  v1.30.3
   worker-1  Ready     worker  11m  v1.30.3

   참고

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

프로세스

1. OpenShift CLI(oc)에 로그인합니다.

2. 다음 명령을 실행하여 클러스터에서 아키텍처 페이로드를 사용하는지 확인할 수 있습니다.

   $ oc adm release info -o jsonpath="{ .metadata.metadata}"

프로세스

1. 다음 명령을 실행하여 클러스터에서 Ignition 구성 파일을 추출합니다.

   $ oc extract -n openshift-machine-api secret/worker-user-data-managed --keys=userData --to=- > worker.ign

2. 클러스터에서 내보낸 worker.ign Ignition 구성 파일을 HTTP 서버로 업로드합니다. 이 파일의 URL을 기록해 둡니다.

3. Ignition 파일이 URL에서 사용 가능한지 확인할 수 있습니다. 다음 예제에서는 컴퓨팅 노드에 대한 Ignition 구성 파일을 가져옵니다.

   $ curl -k http://<http_server>/worker.ign

4. 다음 명령을 실행하여 RHEL 라이브 커널,initramfs, rootfs 파일을 다운로드합니다.

   $ curl -LO $(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' \
   | jq -r '.architectures.s390x.artifacts.metal.formats.pxe.kernel.location')

   $ curl -LO $(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' \
   | jq -r '.architectures.s390x.artifacts.metal.formats.pxe.initramfs.location')

   $ curl -LO $(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' \
   | jq -r '.architectures.s390x.artifacts.metal.formats.pxe.rootfs.location')

5. 다운로드한 RHEL 라이브 커널,initramfs 및 rootfs 파일을 추가하려는 RHCOS 게스트에서 액세스할 수 있는 HTTP 또는 HTTPS 서버로 이동합니다.

6. 게스트에 대한 매개변수 파일을 생성합니다. 다음 매개변수는 가상 머신에 고유합니다.

   • 선택 사항: 고정 IP 주소를 지정하려면 각각 콜론으로 구분된 다음 항목이 포함된 ip= 매개변수를 추가합니다.

     1. 컴퓨터의 IP 주소
     2. 빈 문자열
     3. 게이트웨이
     4. 넷 마스크
     5. hostname.domainname 형식의 시스템 호스트 및 도메인 이름. RHCOS가 설정하도록 하려면 이 값을 생략하십시오.
     6. 네트워크 인터페이스 이름. RHCOS가 설정하도록 하려면 이 값을 생략하십시오.
     7. 값이 없음입니다.
   • coreos.inst.ignition_url= 의 경우 worker.ign 파일의 URL을 지정합니다. HTTP 및 HTTPS 프로토콜만 지원됩니다.
   • coreos.live.rootfs_url= 의 경우 부팅 중인 커널 및 initramfs 와 일치하는 rootfs 아티팩트를 지정합니다. HTTP 및 HTTPS 프로토콜만 지원됩니다.

   • DASD 유형 디스크에 설치하려면 다음 작업을 완료합니다.

     1. coreos.inst.install_dev= 의 경우 /dev/dasda 를 지정합니다.
     2. rd.dasd=의 경우 RHCOS를 설치할 DASD를 지정합니다.

     3. 필요한 경우 추가 매개변수를 조정할 수 있습니다.

        다음은 추가-worker-dasd.parm 매개변수 파일 예제입니다.

        cio_ignore=all,!condev rd.neednet=1 \
        console=ttysclp0 \
        coreos.inst.install_dev=/dev/dasda \
        coreos.inst.ignition_url=http://<http_server>/worker.ign \
        coreos.live.rootfs_url=http://<http_server>/rhcos-<version>-live-rootfs.<architecture>.img \
        ip=<ip>::<gateway>:<netmask>:<hostname>::none nameserver=<dns> \
        rd.znet=qeth,0.0.bdf0,0.0.bdf1,0.0.bdf2,layer2=1,portno=0 \
        rd.dasd=0.0.3490 \
        zfcp.allow_lun_scan=0

        매개 변수 파일의 모든 옵션을 한 줄로 작성하고 줄 바꿈 문자가 없는지 확인합니다.

   • FCP 유형 디스크에 설치하려면 다음 작업을 완료합니다.

     1. RHCOS를 설치할 FCP 디스크를 지정하려면 rd.zfcp=<adapter>,<wwpn>,<lun>을 사용합니다. 다중 경로의 경우 추가 경로마다 이 단계를 반복합니다.

        참고

        여러 경로를 사용하여 설치할 때 나중에 문제가 발생할 수 있으므로 설치 후에 직접 멀티패스를 활성화해야 합니다.

     2. 설치 장치를 coreos.inst.install_dev=/dev/sda 로 설정합니다.

        참고

        NPIV로 추가 LUN을 구성하는 경우 FCP에는 zfcp.allow_lun_scan=0이 필요합니다. 예를 들어 CSI 드라이버를 사용하므로 zfcp.allow_lun_scan=1 을 활성화해야 하는 경우, 각 노드가 다른 노드의 부팅 파티션에 액세스할 수 없도록 NPIV를 구성해야 합니다.

     3. 필요한 경우 추가 매개변수를 조정할 수 있습니다.

        중요

        멀티패스를 완전히 활성화하려면 추가 설치 후 단계가 필요합니다. 자세한 내용은 머신 구성 의 "RHCOS에서 커널 인수를 사용하여 멀티패스 활성화"를 참조하십시오.

        다음은 다중 경로가 있는 작업자 노드의 additional-worker-fcp.parm 매개변수 파일 예제입니다.

        cio_ignore=all,!condev rd.neednet=1 \
        console=ttysclp0 \
        coreos.inst.install_dev=/dev/sda \
        coreos.live.rootfs_url=http://<http_server>/rhcos-<version>-live-rootfs.<architecture>.img \
        coreos.inst.ignition_url=http://<http_server>/worker.ign \
        ip=<ip>::<gateway>:<netmask>:<hostname>::none nameserver=<dns> \
        rd.znet=qeth,0.0.bdf0,0.0.bdf1,0.0.bdf2,layer2=1,portno=0 \
        zfcp.allow_lun_scan=0 \
        rd.zfcp=0.0.1987,0x50050763070bc5e3,0x4008400B00000000 \
        rd.zfcp=0.0.19C7,0x50050763070bc5e3,0x4008400B00000000 \
        rd.zfcp=0.0.1987,0x50050763071bc5e3,0x4008400B00000000 \
        rd.zfcp=0.0.19C7,0x50050763071bc5e3,0x4008400B00000000

        매개 변수 파일의 모든 옵션을 한 줄로 작성하고 줄 바꿈 문자가 없는지 확인합니다.

7. initramfs, 커널, 매개 변수 파일 및 RHCOS 이미지를 LPAR로 전송합니다(예: FTP 사용). FTP 및 부팅을 사용하여 파일을 전송하는 방법에 대한 자세한 내용은 LPAR에서 RHEL을 설치하기 위해 IBM Z®에 설치 부팅을 참조하십시오.
8. 머신 부팅

프로세스

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

   $ oc get nodes

   출력 예

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

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

   참고

   이전 출력에는 일부 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.30.3
   master-1  Ready     master  73m  v1.30.3
   master-2  Ready     master  74m  v1.30.3
   worker-0  Ready     worker  11m  v1.30.3
   worker-1  Ready     worker  11m  v1.30.3

   참고

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

프로세스

1. OpenShift CLI(oc)에 로그인합니다.

2. 다음 명령을 실행하여 클러스터에서 아키텍처 페이로드를 사용하는지 확인할 수 있습니다.

   $ oc adm release info -o jsonpath="{ .metadata.metadata}"

프로세스

1. 다음 명령을 실행하여 클러스터에서 Ignition 구성 파일을 추출합니다.

   $ oc extract -n openshift-machine-api secret/worker-user-data-managed --keys=userData --to=- > worker.ign

2. 클러스터에서 내보낸 worker.ign Ignition 구성 파일을 HTTP 서버로 업로드합니다. 이 파일의 URL을 기록해 둡니다.

3. Ignition 파일이 URL에서 사용 가능한지 확인할 수 있습니다. 다음 예제에서는 컴퓨팅 노드에 대한 Ignition 구성 파일을 가져옵니다.

   $ curl -k http://<HTTP_server>/worker.ign

4. 다음 명령을 실행하여 RHEL 라이브 커널,initramfs, rootfs 파일을 다운로드합니다.

    $ curl -LO $(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' \
   | jq -r '.architectures.s390x.artifacts.metal.formats.pxe.kernel.location')

   $ curl -LO $(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' \
   | jq -r '.architectures.s390x.artifacts.metal.formats.pxe.initramfs.location')

   $ curl -LO $(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' \
   | jq -r '.architectures.s390x.artifacts.metal.formats.pxe.rootfs.location')

5. virt-install 을 시작하기 전에 다운로드한 RHEL 라이브 커널,initramfs 및 rootfs 파일을 HTTP 또는 HTTPS 서버로 이동합니다.

6. RHEL 커널,initramfs 및 Ignition 파일, 새 디스크 이미지, 조정된 parm 줄 인수를 사용하여 새 KVM 게스트 노드를 만듭니다.

   $ virt-install \
      --connect qemu:///system \
      --name <vm_name> \
      --autostart \
      --os-variant rhel9.4 \ 1
      --cpu host \
      --vcpus <vcpus> \
      --memory <memory_mb> \
      --disk <vm_name>.qcow2,size=<image_size> \
      --network network=<virt_network_parm> \
      --location <media_location>,kernel=<rhcos_kernel>,initrd=<rhcos_initrd> \ 2
      --extra-args "rd.neednet=1" \
      --extra-args "coreos.inst.install_dev=/dev/vda" \
      --extra-args "coreos.inst.ignition_url=http://<http_server>/worker.ign " \ 3
      --extra-args "coreos.live.rootfs_url=http://<http_server>/rhcos-<version>-live-rootfs.<architecture>.img" \ 4
      --extra-args "ip=<ip>::<gateway>:<netmask>:<hostname>::none" \ 5
      --extra-args "nameserver=<dns>" \
      --extra-args "console=ttysclp0" \
      --noautoconsole \
      --wait

   1

   os-variant 의 경우 RHCOS 컴퓨팅 머신의 RHEL 버전을 지정합니다. rhel9.4 는 권장 버전입니다. 지원되는 RHEL 버전의 운영 체제를 쿼리하려면 다음 명령을 실행합니다.

   $ osinfo-query os -f short-id

   참고

   os-variant 은 대소문자를 구분합니다.

   2

   --location에 대해 HTTP 또는 HTTPS 서버의 kernel/initrd 위치를 지정합니다.

   3

   worker.ign 구성 파일의 위치를 지정합니다. HTTP 및 HTTPS 프로토콜만 지원됩니다.

   4

   부팅하려는 커널 및 initramfs 의 rootfs 아티팩트 위치를 지정합니다. HTTP 및 HTTPS 프로토콜만 지원됩니다.

   5

   선택 사항: 호스트 이름 의 경우 클라이언트 시스템의 정규화된 호스트 이름을 지정합니다.

   참고

   HAProxy를 로드 밸런서로 사용하는 경우 /etc/haproxy/haproxy.cfg 구성 파일에서 ingress-router-443 및 ingress-router-80 에 대한 HAProxy 규칙을 업데이트합니다.

7. 계속해서 클러스터에 추가 컴퓨팅 머신을 만듭니다.

프로세스

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

   $ oc get nodes

   출력 예

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

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

   참고

   이전 출력에는 일부 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.30.3
   master-1  Ready     master  73m  v1.30.3
   master-2  Ready     master  74m  v1.30.3
   worker-0  Ready     worker  11m  v1.30.3
   worker-1  Ready     worker  11m  v1.30.3

   참고

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

프로세스

1. OpenShift CLI(oc)에 로그인합니다.

2. 다음 명령을 실행하여 클러스터에서 아키텍처 페이로드를 사용하는지 확인할 수 있습니다.

   $ oc adm release info -o jsonpath="{ .metadata.metadata}"

프로세스

1. 다음 명령을 실행하여 클러스터에서 Ignition 구성 파일을 추출합니다.

   $ oc extract -n openshift-machine-api secret/worker-user-data-managed --keys=userData --to=- > worker.ign

2. 클러스터에서 내보낸 worker.ign Ignition 구성 파일을 HTTP 서버로 업로드합니다. 해당 파일의 URL을 기록해 둡니다.

3. Ignition 파일을 URL에서 사용할 수 있는지 확인할 수 있습니다. 다음 예제에서는 컴퓨팅 노드에 대한 Ignition 구성 파일을 가져옵니다.

   $ curl -k http://<HTTP_server>/worker.ign

4. 다음 명령으로 실행하여 새 머신을 부팅하기 위해 ISO 이미지에 액세스할 수 있습니다.

   RHCOS_VHD_ORIGIN_URL=$(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' | jq -r '.architectures.<architecture>.artifacts.metal.formats.iso.disk.location')

5. ISO 파일을 사용하여 추가 컴퓨팅 머신에 RHCOS를 설치합니다. 클러스터를 설치하기 전에 머신을 만들 때 사용한 것과 동일한 방법을 사용합니다.

   • ISO 이미지를 디스크에 굽고 직접 부팅합니다.
   • LOM 인터페이스에서 ISO 리디렉션을 사용합니다.

6. 옵션을 지정하거나 라이브 부팅 시퀀스를 중단하지 않고 RHCOS ISO 이미지를 부팅합니다. 설치 프로그램이 RHCOS 라이브 환경에서 쉘 프롬프트로 부팅될 때까지 기다립니다.

   참고

   RHCOS 설치 부팅 프로세스를 중단하여 커널 인수를 추가할 수 있습니다. 그러나 이 ISO 절차에서는 커널 인수를 추가하는 대신 다음 단계에 설명된 대로 coreos-installer 명령을 사용해야 합니다.

7. coreos-installer 명령을 실행하고 설치 요구 사항을 충족하는 옵션을 지정합니다. 최소한 노드 유형에 대한 Ignition 구성 파일과 설치할 장치를 가리키는 URL을 지정해야 합니다.

   $ sudo coreos-installer install --ignition-url=http://<HTTP_server>/<node_type>.ign <device> --ignition-hash=sha512-<digest> 12

   1

   core 사용자에게 설치를 수행하는 데 필요한 root 권한이 없으므로 sudo를 사용하여 coreos-installer 명령을 실행해야 합니다.

   2

   클러스터 노드에서 Ignition 구성 파일을 HTTP URL을 통해 가져오려면 --ignition-hash 옵션이 필요합니다. <digest>는 이전 단계에서 얻은 Ignition 구성 파일 SHA512 다이제스트입니다.

   참고

   TLS를 사용하는 HTTPS 서버를 통해 Ignition 구성 파일을 제공하려는 경우 coreos-installer를 실행하기 전에 내부 인증 기관(CA)을 시스템 신뢰 저장소에 추가할 수 있습니다.

   다음 예제에서는 /dev/sda 장치에 부트스트랩 노드 설치를 초기화합니다. 부트스트랩 노드의 Ignition 구성 파일은 IP 주소 192.168.1.2가 있는 HTTP 웹 서버에서 가져옵니다.

   $ sudo coreos-installer install --ignition-url=http://192.168.1.2:80/installation_directory/bootstrap.ign /dev/sda --ignition-hash=sha512-a5a2d43879223273c9b60af66b44202a1d1248fc01cf156c46d4a79f552b6bad47bc8cc78ddf0116e80c59d2ea9e32ba53bc807afbca581aa059311def2c3e3b

8. 머신 콘솔에서 RHCOS 설치 진행률을 모니터링합니다.

   중요

   OpenShift Container Platform 설치를 시작하기 전에 각 노드에서 성공적으로 설치되었는지 확인합니다. 설치 프로세스를 관찰하면 발생할 수 있는 RHCOS 설치 문제의 원인을 파악하는 데 도움이 될 수 있습니다.

9. 계속해서 클러스터에 추가 컴퓨팅 머신을 만듭니다.

프로세스

1. RHCOS 이미지의 PXE 또는 iPXE가 올바르게 설치되었는지 확인합니다.

   • PXE의 경우:

     DEFAULT pxeboot
     TIMEOUT 20
     PROMPT 0
     LABEL pxeboot
         KERNEL http://<HTTP_server>/rhcos-<version>-live-kernel-<architecture> 1
         APPEND initrd=http://<HTTP_server>/rhcos-<version>-live-initramfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/worker.ign coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img 2

     1

     HTTP 서버에 업로드한 라이브 kernel 파일의 위치를 지정합니다.

     2

     HTTP 서버에 업로드한 RHCOS 파일의 위치를 지정합니다. initrd 매개변수 값은 initramfs 파일의 위치이고 coreos.inst.ignition_url 매개변수 값은 작업자 Ignition 설정 파일의 위치이며 coreos.live.rootfs_url 매개 변수 값은 라이브 rootfs 파일의 위치입니다. coreos.inst.ignition_url 및 coreos.live.rootfs_url 매개변수는 HTTP 및 HTTPS만 지원합니다.

     참고

     이 구성은 그래픽 콘솔이 있는 시스템에서 직렬 콘솔 액세스를 활성화하지 않습니다. 다른 콘솔을 구성하려면 APPEND 행에 하나 이상의 console= 인수를 추가합니다. 예를 들어 console=tty0 console=ttyS0을 추가하여 첫 번째 PC 직렬 포트를 기본 콘솔로 설정하고 그래픽 콘솔을 보조 콘솔로 설정합니다. 자세한 내용은 Red Hat Enterprise Linux에서 직렬 터미널 및/또는 콘솔 설정 방법을 참조하십시오.

   • iPXE (x86_64 + ppc64le):

     kernel http://<HTTP_server>/rhcos-<version>-live-kernel-<architecture> initrd=main coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/worker.ign 1 2
     initrd --name main http://<HTTP_server>/rhcos-<version>-live-initramfs.<architecture>.img 3
     boot

     1

     HTTP 서버에 업로드한 RHCOS 파일의 위치를 지정합니다. kernel 매개변수 값은 커널 파일의 위치이며 initrd=main 인수는 UEFI 시스템에서 부팅하는 데 필요하며 coreos.live.rootfs_url 매개변수 값은 rootfs 파일의 위치이며 coreos.inst.ignition_url 매개변수 값은 작업자 Ignition 구성 파일의 위치입니다.

     2

     NIC를 여러 개 사용하는 경우 ip 옵션에 단일 인터페이스를 지정합니다. 예를 들어, eno1라는 NIC에서 DHCP를 사용하려면 ip=eno1:dhcp를 설정하십시오.

     3

     HTTP 서버에 업로드한 initramfs 파일의 위치를 지정합니다.

     참고

     이 구성은 그래픽 콘솔이 있는 머신에서 직렬 콘솔 액세스를 활성화하지 않습니다. 다른 콘솔을 구성하려면 kernel 행에 하나 이상의 console= 인수를 추가합니다. 예를 들어 console=tty0 console=ttyS0을 추가하여 첫 번째 PC 직렬 포트를 기본 콘솔로 설정하고 그래픽 콘솔을 보조 콘솔로 설정합니다. 자세한 내용은 How does one set up a serial terminal and/or console in Red Hat Enterprise Linux? 및 "Enabling the serial console for PXE and ISO installation" 섹션을 참조하십시오.

     참고

     ppc64le 아키텍처에서 CoreOS 커널 을 부팅하려면 IMAGE_GZIP 옵션이 활성화된 iPXE 빌드 버전을 사용해야 합니다. iPXE의IMAGE_GZIP 옵션을 참조하십시오.

   • ppc64le 에서 PXE ( UEFI 및 GRUB를 두 번째 단계로 사용)의 경우 :

     menuentry 'Install CoreOS' {
         linux rhcos-<version>-live-kernel-<architecture>  coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/worker.ign 1 2
         initrd rhcos-<version>-live-initramfs.<architecture>.img 3
     }

     1

     HTTP/TFTP 서버에 업로드한 RHCOS 파일의 위치를 지정합니다. kernel 매개변수 값은 TFTP 서버의 파일의 위치입니다. coreos.live.rootfs_url 매개변수 값은 rootfs 파일의 위치이며 coreos.inst.ignition_url 매개변수 값은 HTTP Server의 작업자 Ignition 구성 파일의 위치입니다.

     2

     NIC를 여러 개 사용하는 경우 ip 옵션에 단일 인터페이스를 지정합니다. 예를 들어, eno1라는 NIC에서 DHCP를 사용하려면 ip=eno1:dhcp를 설정하십시오.

     3

     TFTP 서버에 업로드한 initramfs 파일의 위치를 지정합니다.

2. PXE 또는 iPXE 인프라를 사용하여 클러스터에 필요한 컴퓨팅 머신을 만듭니다.

프로세스

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

   $ oc get nodes

   출력 예

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

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

   참고

   이전 출력에는 일부 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 -o wide

   출력 예

   NAME               STATUS   ROLES                  AGE   VERSION   INTERNAL-IP      EXTERNAL-IP   OS-IMAGE                                                       KERNEL-VERSION                  CONTAINER-RUNTIME
   worker-0-ppc64le   Ready    worker                 42d   v1.30.3   192.168.200.21   <none>        Red Hat Enterprise Linux CoreOS 415.92.202309261919-0 (Plow)   5.14.0-284.34.1.el9_2.ppc64le   cri-o://1.30.3-3.rhaos4.15.gitb36169e.el9
   worker-1-ppc64le   Ready    worker                 42d   v1.30.3   192.168.200.20   <none>        Red Hat Enterprise Linux CoreOS 415.92.202309261919-0 (Plow)   5.14.0-284.34.1.el9_2.ppc64le   cri-o://1.30.3-3.rhaos4.15.gitb36169e.el9
   master-0-x86       Ready    control-plane,master   75d   v1.30.3   10.248.0.38      10.248.0.38   Red Hat Enterprise Linux CoreOS 415.92.202309261919-0 (Plow)   5.14.0-284.34.1.el9_2.x86_64    cri-o://1.30.3-3.rhaos4.15.gitb36169e.el9
   master-1-x86       Ready    control-plane,master   75d   v1.30.3   10.248.0.39      10.248.0.39   Red Hat Enterprise Linux CoreOS 415.92.202309261919-0 (Plow)   5.14.0-284.34.1.el9_2.x86_64    cri-o://1.30.3-3.rhaos4.15.gitb36169e.el9
   master-2-x86       Ready    control-plane,master   75d   v1.30.3   10.248.0.40      10.248.0.40   Red Hat Enterprise Linux CoreOS 415.92.202309261919-0 (Plow)   5.14.0-284.34.1.el9_2.x86_64    cri-o://1.30.3-3.rhaos4.15.gitb36169e.el9
   worker-0-x86       Ready    worker                 75d   v1.30.3   10.248.0.43      10.248.0.43   Red Hat Enterprise Linux CoreOS 415.92.202309261919-0 (Plow)   5.14.0-284.34.1.el9_2.x86_64    cri-o://1.30.3-3.rhaos4.15.gitb36169e.el9
   worker-1-x86       Ready    worker                 75d   v1.30.3   10.248.0.44      10.248.0.44   Red Hat Enterprise Linux CoreOS 415.92.202309261919-0 (Plow)   5.14.0-284.34.1.el9_2.x86_64    cri-o://1.30.3-3.rhaos4.15.gitb36169e.el9

   참고

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

프로세스

1. 64k 페이지 크기 커널을 실행할 노드에 레이블을 지정합니다.

   $ oc label node <node_name> <label>

   명령 예

   $ oc label node worker-arm64-01 node-role.kubernetes.io/worker-64k-pages=

2. ARM64 아키텍처 및 worker-64k-pages 역할을 사용하는 작업자 역할이 포함된 머신 구성 풀을 생성합니다.

   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfigPool
   metadata:
     name: worker-64k-pages
   spec:
     machineConfigSelector:
       matchExpressions:
         - key: machineconfiguration.openshift.io/role
           operator: In
           values:
           - worker
           - worker-64k-pages
     nodeSelector:
       matchLabels:
         node-role.kubernetes.io/worker-64k-pages: ""
         kubernetes.io/arch: arm64

3. 컴퓨팅 노드에 시스템 구성을 생성하여 64k-pages 매개변수로 64k-pages 를 활성화합니다.

   $ oc create -f <filename>.yaml

   MachineConfig의 예

   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     labels:
       machineconfiguration.openshift.io/role: "worker-64k-pages" 1
     name: 99-worker-64kpages
   spec:
     kernelType: 64k-pages 2

   1

   사용자 지정 머신 구성 풀에서 machineconfiguration.openshift.io/role 레이블의 값을 지정합니다. 예제 MachineConfig는 worker-64k-pages 레이블을 사용하여 worker-64k-pages 풀에서 64k 페이지를 활성화합니다.

   2

   원하는 커널 유형을 지정합니다. 유효한 값은 64k-pages 및 default입니다.

   참고

   64k-pages 유형은 64비트 ARM 아키텍처 기반 컴퓨팅 노드에서만 지원됩니다. 실시간 유형은 64비트 x86 아키텍처 기반 컴퓨팅 노드에서만 지원됩니다.

프로세스

1. 다음 명령을 실행하여 openshift-multiarch-tuning-operator 라는 새 프로젝트를 생성합니다.

   $ oc create ns openshift-multiarch-tuning-operator

2. OperatorGroup 오브젝트를 생성합니다.

   1. OperatorGroup 오브젝트를 생성하기 위한 구성으로 YAML 파일을 생성합니다.

      OperatorGroup 오브젝트를 생성하기 위한 YAML 구성의 예

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: openshift-multiarch-tuning-operator
        namespace: openshift-multiarch-tuning-operator
      spec: {}

   2. 다음 명령을 실행하여 OperatorGroup 오브젝트를 생성합니다.

      $ oc create -f <file_name> 1

      1

      & lt;file_name >을 OperatorGroup 오브젝트 구성이 포함된 YAML 파일의 이름으로 바꿉니다.

3. Subscription 오브젝트를 생성합니다.

   1. Subscription 오브젝트를 생성하기 위한 구성으로 YAML 파일을 생성합니다.

      Subscription 오브젝트를 생성하기 위한 YAML 구성의 예

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: openshift-multiarch-tuning-operator
        namespace: openshift-multiarch-tuning-operator
      spec:
        channel: stable
        name: multiarch-tuning-operator
        source: redhat-operators
        sourceNamespace: openshift-marketplace
        installPlanApproval: Automatic
        startingCSV: multiarch-tuning-operator.v1.0.0

   2. 다음 명령을 실행하여 Subscription 오브젝트를 생성합니다.

      $ oc create -f <file_name> 1

      1

      & lt;file_name >을 Subscription 오브젝트 구성이 포함된 YAML 파일의 이름으로 바꿉니다.

검증

1. Multiarch Tuning Operator가 설치되었는지 확인하려면 다음 명령을 실행합니다.

   $ oc get csv -n openshift-multiarch-tuning-operator

   출력 예

   NAME                               DISPLAY                     VERSION   REPLACES                              PHASE
   multiarch-tuning-operator.v1.0.0   Multiarch Tuning Operator   1.0.0     multiarch-tuning-operator.v0.9.0      Succeeded

   Operator가 Succeeded 단계에 있는 경우 설치가 성공적으로 수행됩니다.

2. 선택 사항: OperatorGroup 오브젝트가 생성되었는지 확인하려면 다음 명령을 실행합니다.

   $ oc get operatorgroup -n openshift-multiarch-tuning-operator

   출력 예

   NAME                                        AGE
   openshift-multiarch-tuning-operator-q8zbb   133m

3. 선택 사항: Subscription 오브젝트가 생성되었는지 확인하려면 다음 명령을 실행합니다.

   $ oc get subscription -n openshift-multiarch-tuning-operator

   출력 예

   NAME                        PACKAGE                     SOURCE                  CHANNEL
   multiarch-tuning-operator   multiarch-tuning-operator   redhat-operators        stable

프로세스

1. OpenShift Container Platform 웹 콘솔에 로그인합니다.
2. Operators → OperatorHub 로 이동합니다.
3. 검색 필드에 Multiarch Tuning Operator 를 입력합니다.
4. Multiarch Tuning Operator 를 클릭합니다.
5. 버전 목록에서 Multiarch Tuning Operator 버전을 선택합니다.
6. 설치를 클릭합니다.

7. Operator 설치 페이지에서 다음 옵션을 설정합니다.

   1. Update Channel 을 stable 로 설정합니다.
   2. 설치 모드를 클러스터의 모든 네임스페이스로 설정합니다.

   3. 설치된 네임스페이스 를 Operator 권장 네임스페이스로 설정하거나 네임스페이스 를 선택합니다.

      권장 Operator 네임스페이스는 openshift-multiarch-tuning-operator 입니다. openshift-multiarch-tuning-operator 네임스페이스가 없으면 Operator 설치 중에 생성됩니다.

      네임스페이스 선택을 선택하는 경우 프로젝트 선택 목록에서 Operator의 네임스페이스를 선택해야 합니다.

   4. 업데이트 승인을 자동 또는 수동으로 업데이트합니다.

      자동 업데이트를 선택하면 OLM(Operator Lifecycle Manager)은 개입 없이 Multiarch Tuning Operator의 실행 중인 인스턴스를 자동으로 업데이트합니다.

      수동 업데이트를 선택하면 OLM에서 업데이트 요청을 생성합니다. 클러스터 관리자는 Multiarch Tuning Operator를 최신 버전으로 업데이트하기 위해 업데이트 요청을 수동으로 승인해야 합니다.

8. 선택 사항: 이 네임스페이스에서 Operator 권장 클러스터 모니터링 활성화 확인란을 선택합니다.
9. 설치를 클릭합니다.

검증

1. Operators → 설치된 Operator로 이동합니다.
2. openshift-multiarch-tuning-operator 네임스페이스에서 Status 필드를 Succeeded 로 사용하여 Multiarch Tuning Operator 가 나열되어 있는지 확인합니다.

프로세스

1. OpenShift CLI(oc)에 로그인합니다.

2. 다음 명령을 실행하여 ClusterPodPlacementConfig 오브젝트를 삭제합니다.

   $ oc delete clusterpodplacementconfig cluster

프로세스

1. OpenShift Container Platform 웹 콘솔에 로그인합니다.
2. Operators → 설치된 Operator로 이동합니다.
3. 설치된 Operator 페이지에서 Multiarch Tuning Operator 를 클릭합니다.
4. Cluster Pod 배치 구성 탭을 클릭합니다.
5. 옵션 메뉴에서 Delete ClusterPodPlacementConfig 를 선택합니다.
6. 삭제를 클릭합니다.

프로세스

1. 다음 명령을 실행하여 Multiarch Tuning Operator의 서브스크립션 오브젝트 이름을 가져옵니다.

   $ oc get subscription.operators.coreos.com -n <namespace> 1

   1

   <namespace>를 Multiarch Tuning Operator를 설치 제거할 네임스페이스의 이름으로 바꿉니다.

   출력 예

   NAME                                  PACKAGE                     SOURCE             CHANNEL
   openshift-multiarch-tuning-operator   multiarch-tuning-operator   redhat-operators   stable

2. 다음 명령을 실행하여 Multiarch Tuning Operator의 currentCSV 값을 가져옵니다.

   $ oc get subscription.operators.coreos.com <subscription_name> -n <namespace> -o yaml | grep currentCSV 1

   1

   <subscription_name>을 Subscription 오브젝트 이름으로 바꿉니다. 예: openshift-multiarch-tuning-operator. <namespace>를 Multiarch Tuning Operator를 설치 제거할 네임스페이스의 이름으로 바꿉니다.

   출력 예

   currentCSV: multiarch-tuning-operator.v1.0.0

3. 다음 명령을 실행하여 Subscription 오브젝트를 삭제합니다.

   $ oc delete subscription.operators.coreos.com <subscription_name> -n <namespace> 1

   1

   <subscription_name>을 Subscription 오브젝트 이름으로 바꿉니다. <namespace>를 Multiarch Tuning Operator를 설치 제거할 네임스페이스의 이름으로 바꿉니다.

   출력 예

   subscription.operators.coreos.com "openshift-multiarch-tuning-operator" deleted

4. 다음 명령을 실행하여 currentCSV 값을 사용하여 대상 네임스페이스에서 Multiarch Tuning Operator의 CSV를 삭제합니다.

   $ oc delete clusterserviceversion <currentCSV_value> -n <namespace> 1

   1

   & lt;currentCSV& gt;를 Multiarch Tuning Operator의 currentCSV 값으로 바꿉니다. 예: multiarch-tuning-operator.v1.0.0. <namespace>를 Multiarch Tuning Operator를 설치 제거할 네임스페이스의 이름으로 바꿉니다.

   출력 예

   clusterserviceversion.operators.coreos.com "multiarch-tuning-operator.v1.0.0" deleted

프로세스

1. OpenShift Container Platform 웹 콘솔에 로그인합니다.
2. Operators → OperatorHub 로 이동합니다.
3. 검색 필드에 Multiarch Tuning Operator 를 입력합니다.
4. Multiarch Tuning Operator 를 클릭합니다.
5. 세부 정보 탭을 클릭합니다.
6. 작업 메뉴에서 Operator 설치 제거를 선택합니다.
7. 메시지가 표시되면 설치 제거를 클릭합니다.

검증

1. Operators → 설치된 Operator로 이동합니다.
2. 설치된 Operator 페이지에서 Multiarch Tuning Operator 가 나열되어 있지 않은지 확인합니다.

프로세스

1. 다음 명령을 실행하여 클러스터에 있는 컴퓨팅 머신 세트를 확인합니다.

   $ oc get machinesets.machine.openshift.io -n openshift-machine-api

   컴퓨팅 머신 세트는 <clusterid>-worker-<aws-region-az> 형식으로 나열됩니다.

2. 다음 명령을 실행하여 클러스터에 있는 컴퓨팅 시스템을 확인합니다.

   $ oc get machines.machine.openshift.io -n openshift-machine-api

3. 다음 명령을 실행하여 삭제할 컴퓨팅 머신에 주석을 설정합니다.

   $ oc annotate machines.machine.openshift.io/<machine_name> -n openshift-machine-api machine.openshift.io/delete-machine="true"

4. 다음 명령 중 하나를 실행하여 컴퓨팅 머신 세트를 확장합니다.

   $ oc scale --replicas=2 machinesets.machine.openshift.io <machineset> -n openshift-machine-api

   또는 다음을 수행합니다.

   $ oc edit machinesets.machine.openshift.io <machineset> -n openshift-machine-api

   작은 정보

   다음 YAML을 적용하여 컴퓨팅 머신 세트를 확장할 수 있습니다.

   apiVersion: machine.openshift.io/v1beta1
   kind: MachineSet
   metadata:
     name: <machineset>
     namespace: openshift-machine-api
   spec:
     replicas: 2

   컴퓨팅 머신 세트를 확장 또는 축소할 수 있습니다. 새 머신을 사용할 수 있을 때 까지 몇 분 정도 소요됩니다.

   중요

   기본적으로 머신 컨트롤러는 성공할 때까지 머신이 지원하는 노드를 드레이닝하려고 합니다. Pod 중단 예산을 잘못 구성하는 등 일부 상황에서는 드레이닝 작업이 성공하지 못할 수 있습니다. 드레이닝 작업이 실패하면 머신 컨트롤러에서 머신 제거를 진행할 수 없습니다.

   특정 머신에서 machine.openshift.io/exclude-node-draining 에 주석을 달아 노드 드레이닝을 건너뛸 수 있습니다.

1. Scheduler Operator CR을 편집하여 기본 클러스터 수준 노드 선택기를 추가합니다.

   $ oc edit scheduler cluster

   노드 선택기를 사용하는 Scheduler Operator CR의 예

   apiVersion: config.openshift.io/v1
   kind: Scheduler
   metadata:
     name: cluster
   ...
   spec:
     defaultNodeSelector: type=user-node,region=east 1
     mastersSchedulable: false

   1

   적절한 <key>:<value> 쌍을 사용하여 노드 선택기를 추가합니다.

   변경 후 openshift-kube-apiserver 프로젝트의 pod가 재배포될 때까지 기다립니다. 이 작업은 몇 분 정도 걸릴 수 있습니다. 기본 클러스터 수준 노드 선택기는 Pod가 재배포된 후 적용됩니다.

2. 컴퓨팅 머신 세트를 사용하거나 노드를 직접 편집하여 노드에 라벨을 추가합니다.

   • 노드를 생성할 때 컴퓨팅 머신 세트에서 관리하는 노드에 라벨을 추가하려면 컴퓨팅 머신 세트를 사용합니다.

     1. 다음 명령을 실행하여 MachineSet 오브젝트에 라벨을 추가합니다.

        $ oc patch MachineSet <name> --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"<key>"="<value>","<key>"="<value>"}}]'  -n openshift-machine-api 1

        1

        각 라벨에 <key>/<value> 쌍을 추가합니다.

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

        $ oc patch MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"type":"user-node","region":"east"}}]'  -n openshift-machine-api

        작은 정보

        다음 YAML을 적용하여 컴퓨팅 머신 세트에 라벨을 추가할 수도 있습니다.

        apiVersion: machine.openshift.io/v1beta1
        kind: MachineSet
        metadata:
          name: <machineset>
          namespace: openshift-machine-api
        spec:
          template:
            spec:
              metadata:
                labels:
                  region: "east"
                  type: "user-node"

     2. oc edit 명령을 사용하여 라벨이 MachineSet 오브젝트에 추가되었는지 확인합니다.

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

        $ oc edit MachineSet abc612-msrtw-worker-us-east-1c -n openshift-machine-api

        MachineSet 오브젝트의 예

        apiVersion: machine.openshift.io/v1beta1
        kind: MachineSet
          ...
        spec:
          ...
          template:
            metadata:
          ...
            spec:
              metadata:
                labels:
                  region: east
                  type: user-node
          ...

     3. 0 으로 축소하고 노드를 확장하여 해당 컴퓨팅 머신 세트와 연결된 노드를 재배포합니다.

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

        $ oc scale --replicas=0 MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c -n openshift-machine-api

        $ oc scale --replicas=1 MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c -n openshift-machine-api

     4. 노드가 준비되고 사용 가능한 경우 oc get 명령을 사용하여 라벨이 노드에 추가되었는지 확인합니다.

        $ oc get nodes -l <key>=<value>

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

        $ oc get nodes -l type=user-node

        출력 예

        NAME                                       STATUS   ROLES    AGE   VERSION
        ci-ln-l8nry52-f76d1-hl7m7-worker-c-vmqzp   Ready    worker   61s   v1.30.3

   • 라벨을 노드에 직접 추가합니다.

     1. 노드의 Node 오브젝트를 편집합니다.

        $ oc label nodes <name> <key>=<value>

        예를 들어 노드에 라벨을 지정하려면 다음을 수행합니다.

        $ oc label nodes ci-ln-l8nry52-f76d1-hl7m7-worker-b-tgq49 type=user-node region=east

        작은 정보

        다음 YAML을 적용하여 노드에 라벨을 추가할 수도 있습니다.

        kind: Node
        apiVersion: v1
        metadata:
          name: <node_name>
          labels:
            type: "user-node"
            region: "east"

     2. oc get 명령을 사용하여 노드에 라벨이 추가되었는지 확인합니다.

        $ oc get nodes -l <key>=<value>,<key>=<value>

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

        $ oc get nodes -l type=user-node,region=east

        출력 예

        NAME                                       STATUS   ROLES    AGE   VERSION
        ci-ln-l8nry52-f76d1-hl7m7-worker-b-tgq49   Ready    worker   17m   v1.30.3

1. 중간 작업자 대기 시간 프로필로 이동합니다.

   1. node.config 오브젝트를 편집합니다.

      $ oc edit nodes.config/cluster

   2. Add spec.workerLatencyProfile: MediumUpdateAverageReaction:

      node.config 오브젝트의 예

      apiVersion: config.openshift.io/v1
      kind: Node
      metadata:
        annotations:
          include.release.openshift.io/ibm-cloud-managed: "true"
          include.release.openshift.io/self-managed-high-availability: "true"
          include.release.openshift.io/single-node-developer: "true"
          release.openshift.io/create-only: "true"
        creationTimestamp: "2022-07-08T16:02:51Z"
        generation: 1
        name: cluster
        ownerReferences:
        - apiVersion: config.openshift.io/v1
          kind: ClusterVersion
          name: version
          uid: 36282574-bf9f-409e-a6cd-3032939293eb
        resourceVersion: "1865"
        uid: 0c0f7a4c-4307-4187-b591-6155695ac85b
      spec:
        workerLatencyProfile: MediumUpdateAverageReaction 1
      
      # ...

      1

      중간 작업자 대기 시간을 지정합니다.

      변경 사항이 적용되므로 각 작업자 노드의 예약이 비활성화됩니다.

2. 선택 사항: 낮은 작업자 대기 시간 프로필로 이동합니다.

   1. node.config 오브젝트를 편집합니다.

      $ oc edit nodes.config/cluster

   2. spec.workerLatencyProfile 값을 LowUpdateSlowReaction:으로 변경합니다.

      node.config 오브젝트의 예

      apiVersion: config.openshift.io/v1
      kind: Node
      metadata:
        annotations:
          include.release.openshift.io/ibm-cloud-managed: "true"
          include.release.openshift.io/self-managed-high-availability: "true"
          include.release.openshift.io/single-node-developer: "true"
          release.openshift.io/create-only: "true"
        creationTimestamp: "2022-07-08T16:02:51Z"
        generation: 1
        name: cluster
        ownerReferences:
        - apiVersion: config.openshift.io/v1
          kind: ClusterVersion
          name: version
          uid: 36282574-bf9f-409e-a6cd-3032939293eb
        resourceVersion: "1865"
        uid: 0c0f7a4c-4307-4187-b591-6155695ac85b
      spec:
        workerLatencyProfile: LowUpdateSlowReaction 1
      
      # ...

      1

      낮은 작업자 대기 시간 정책 사용을 지정합니다.

프로세스

1. 컴퓨팅 머신 세트 CR(사용자 정의 리소스) 샘플이 포함된 새 YAML 파일을 만들고 <file_name>.yaml이라는 이름을 지정합니다.

   <clusterID> 및 <role> 매개 변수 값을 설정해야 합니다.

2. 선택 사항: 특정 필드에 설정할 값이 확실하지 않은 경우 클러스터에서 기존 컴퓨팅 머신 세트를 확인할 수 있습니다.

   1. 클러스터의 컴퓨팅 머신 세트를 나열하려면 다음 명령을 실행합니다.

      $ oc get machinesets -n openshift-machine-api

      출력 예

      NAME                                DESIRED   CURRENT   READY   AVAILABLE   AGE
      agl030519-vplxk-worker-us-east-1a   1         1         1       1           55m
      agl030519-vplxk-worker-us-east-1b   1         1         1       1           55m
      agl030519-vplxk-worker-us-east-1c   1         1         1       1           55m
      agl030519-vplxk-worker-us-east-1d   0         0                             55m
      agl030519-vplxk-worker-us-east-1e   0         0                             55m
      agl030519-vplxk-worker-us-east-1f   0         0                             55m

   2. 특정 컴퓨팅 머신 세트 CR(사용자 정의 리소스)의 값을 보려면 다음 명령을 실행합니다.

      $ oc get machineset <machineset_name> \
        -n openshift-machine-api -o yaml

      출력 예

      apiVersion: machine.openshift.io/v1beta1
      kind: MachineSet
      metadata:
        labels:
          machine.openshift.io/cluster-api-cluster: <infrastructure_id> 1
        name: <infrastructure_id>-<role> 2
        namespace: openshift-machine-api
      spec:
        replicas: 1
        selector:
          matchLabels:
            machine.openshift.io/cluster-api-cluster: <infrastructure_id>
            machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>
        template:
          metadata:
            labels:
              machine.openshift.io/cluster-api-cluster: <infrastructure_id>
              machine.openshift.io/cluster-api-machine-role: <role>
              machine.openshift.io/cluster-api-machine-type: <role>
              machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>
          spec:
            providerSpec: 3
              ...

      1

      클러스터 인프라 ID입니다.

      2

      기본 노드 레이블입니다.

      참고

      사용자 프로비저닝 인프라가 있는 클러스터의 경우 컴퓨팅 머신 세트는 worker 및 infra 유형 머신만 생성할 수 있습니다.

      3

      컴퓨팅 머신 세트 CR의 <providerSpec> 섹션에 있는 값은 플랫폼에 따라 다릅니다. CR의 <providerSpec> 매개변수에 대한 자세한 내용은 공급자의 샘플 컴퓨팅 머신 세트 CR 구성을 참조하십시오.

3. 다음 명령을 실행하여 MachineSet CR을 생성합니다.

   $ oc create -f <file_name>.yaml

프로세스

1. 애플리케이션 노드 역할을 수행할 작업자 노드에 레이블을 추가합니다.

   $ oc label node <node-name> node-role.kubernetes.io/app=""

2. 인프라 노드 역할을 수행할 작업자 노드에 레이블을 추가합니다.

   $ oc label node <node-name> node-role.kubernetes.io/infra=""

3. 해당 노드에 infra 역할 및 app 역할이 있는지 확인합니다.

   $ oc get nodes

4. 기본 클러스터 수준 노드 선택기를 생성합니다. 기본 노드 선택기는 모든 네임스페이스에서 생성된 Pod에 적용됩니다. 이렇게 하면 Pod의 기존 노드 선택기와 교차점이 생성되어 Pod의 선택기가 추가로 제한됩니다.

   중요

   기본 노드 선택기 키가 Pod 라벨 키와 충돌하는 경우 기본 노드 선택기가 적용되지 않습니다.

   그러나 Pod를 예약할 수 없게 만들 수 있는 기본 노드 선택기를 설정하지 마십시오. 예를 들어 Pod의 라벨이 node-role.kubernetes.io/master=""와 같은 다른 노드 역할로 설정된 경우 기본 노드 선택기를 node-role.kubernetes.io/infra=""와 같은 특정 노드 역할로 설정하면 Pod를 예약할 수 없게 될 수 있습니다. 따라서 기본 노드 선택기를 특정 노드 역할로 설정할 때 주의해야 합니다.

   또는 프로젝트 노드 선택기를 사용하여 클러스터 수준 노드 선택기 키 충돌을 방지할 수 있습니다.

   1. Scheduler 오브젝트를 편집합니다.

      $ oc edit scheduler cluster

   2. 적절한 노드 선택기를 사용하여 defaultNodeSelector 필드를 추가합니다.

      apiVersion: config.openshift.io/v1
      kind: Scheduler
      metadata:
        name: cluster
      spec:
        defaultNodeSelector: node-role.kubernetes.io/infra="" 1
      # ...

      1

      이 예제 노드 선택기는 기본적으로 인프라 노드에 Pod를 배포합니다.

   3. 파일을 저장하여 변경 사항을 적용합니다.

프로세스

1. 특정 레이블이 있는 인프라 노드로 할당하려는 노드에 레이블을 추가합니다.

   $ oc label node <node_name> <label>

   $ oc label node ci-ln-n8mqwr2-f76d1-xscn2-worker-c-6fmtx node-role.kubernetes.io/infra=

2. 작업자 역할과 사용자 지정 역할을 모두 포함하는 머신 구성 풀을 머신 구성 선택기로 생성합니다.

   $ cat infra.mcp.yaml

   출력 예

   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfigPool
   metadata:
     name: infra
   spec:
     machineConfigSelector:
       matchExpressions:
         - {key: machineconfiguration.openshift.io/role, operator: In, values: [worker,infra]} 1
     nodeSelector:
       matchLabels:
         node-role.kubernetes.io/infra: "" 2

   1

   작업자 역할 및 사용자 지정 역할을 추가합니다.

   2

   노드에 추가한 레이블을 nodeSelector로 추가합니다.

   참고

   사용자 지정 머신 구성 풀은 작업자 풀의 머신 구성을 상속합니다. 사용자 지정 풀은 작업자 풀을 대상으로 하는 머신 구성을 사용하지만 사용자 지정 풀을 대상으로 하는 변경 사항만 배포할 수 있는 기능을 추가합니다. 사용자 지정 풀은 작업자 풀에서 리소스를 상속하므로 작업자 풀을 변경하면 사용자 지정 풀에도 영향을 줍니다.

3. YAML 파일이 있으면 머신 구성 풀을 생성할 수 있습니다.

   $ oc create -f infra.mcp.yaml

4. 머신 구성을 확인하고 인프라 구성이 성공적으로 렌더링되었는지 확인합니다.

   $ oc get machineconfig

   출력 예

   NAME                                                        GENERATEDBYCONTROLLER                      IGNITIONVERSION   CREATED
   00-master                                                   365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             31d
   00-worker                                                   365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             31d
   01-master-container-runtime                                 365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             31d
   01-master-kubelet                                           365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             31d
   01-worker-container-runtime                                 365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             31d
   01-worker-kubelet                                           365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             31d
   99-master-1ae2a1e0-a115-11e9-8f14-005056899d54-registries   365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             31d
   99-master-ssh                                                                                          3.2.0             31d
   99-worker-1ae64748-a115-11e9-8f14-005056899d54-registries   365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             31d
   99-worker-ssh                                                                                          3.2.0             31d
   rendered-infra-4e48906dca84ee702959c71a53ee80e7             365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             23m
   rendered-master-072d4b2da7f88162636902b074e9e28e            5b6fb8349a29735e48446d435962dec4547d3090   3.2.0             31d
   rendered-master-3e88ec72aed3886dec061df60d16d1af            02c07496ba0417b3e12b78fb32baf6293d314f79   3.2.0             31d
   rendered-master-419bee7de96134963a15fdf9dd473b25            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             17d
   rendered-master-53f5c91c7661708adce18739cc0f40fb            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             13d
   rendered-master-a6a357ec18e5bce7f5ac426fc7c5ffcd            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             7d3h
   rendered-master-dc7f874ec77fc4b969674204332da037            5b6fb8349a29735e48446d435962dec4547d3090   3.2.0             31d
   rendered-worker-1a75960c52ad18ff5dfa6674eb7e533d            5b6fb8349a29735e48446d435962dec4547d3090   3.2.0             31d
   rendered-worker-2640531be11ba43c61d72e82dc634ce6            5b6fb8349a29735e48446d435962dec4547d3090   3.2.0             31d
   rendered-worker-4e48906dca84ee702959c71a53ee80e7            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             7d3h
   rendered-worker-4f110718fe88e5f349987854a1147755            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             17d
   rendered-worker-afc758e194d6188677eb837842d3b379            02c07496ba0417b3e12b78fb32baf6293d314f79   3.2.0             31d
   rendered-worker-daa08cc1e8f5fcdeba24de60cd955cc3            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             13d

   rendered-infra-* 접두사가 있는 새 머신 구성이 표시되어야 합니다.

5. 선택 사항: 사용자 지정 풀에 변경 사항을 배포하려면 infra와 같은 사용자 지정 풀 이름을 레이블로 사용하는 머신 구성을 생성합니다. 필수 사항은 아니며 지침 용도로만 표시됩니다. 이렇게 하면 인프라 노드에 고유한 사용자 지정 구성을 적용할 수 있습니다.

   참고

   새 머신 구성 풀을 생성한 후 MCO는 해당 풀에 대해 새로 렌더링된 구성과 해당 풀의 관련 노드를 다시 부팅하여 새 구성을 적용합니다.

   1. 머신 구성을 생성합니다.

      $ cat infra.mc.yaml

      출력 예

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfig
      metadata:
        name: 51-infra
        labels:
          machineconfiguration.openshift.io/role: infra 1
      spec:
        config:
          ignition:
            version: 3.2.0
          storage:
            files:
            - path: /etc/infratest
              mode: 0644
              contents:
                source: data:,infra

      1

      노드에 추가한 레이블을 nodeSelector로 추가합니다.

   2. 머신 구성을 인프라 레이블 노드에 적용합니다.

      $ oc create -f infra.mc.yaml

6. 새 머신 구성 풀을 사용할 수 있는지 확인합니다.

   $ oc get mcp

   출력 예

   NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
   infra    rendered-infra-60e35c2e99f42d976e084fa94da4d0fc    True      False      False      1              1                   1                     0                      4m20s
   master   rendered-master-9360fdb895d4c131c7c4bebbae099c90   True      False      False      3              3                   3                     0                      91m
   worker   rendered-worker-60e35c2e99f42d976e084fa94da4d0fc   True      False      False      2              2                   2                     0                      91m

   이 예에서는 작업자 노드가 인프라 노드로 변경되었습니다.

프로세스

1. 인프라 노드에 테인트를 추가하여 사용자 워크로드를 예약하지 않도록합니다.

   1. 노드에 테인트가 있는지 확인합니다.

      $ oc describe nodes <node_name>

      샘플 출력

      oc describe node ci-ln-iyhx092-f76d1-nvdfm-worker-b-wln2l
      Name:               ci-ln-iyhx092-f76d1-nvdfm-worker-b-wln2l
      Roles:              worker
       ...
      Taints:             node-role.kubernetes.io/infra:NoSchedule
       ...

      이 예에서는 노드에 테인트가 있음을 보여줍니다. 다음 단계에서 Pod에 허용 오차를 추가할 수 있습니다.

   2. 사용자 워크로드를 예약하지 않도록 테인트를 구성하지 않은 경우 다음을 수행합니다.

      $ oc adm taint nodes <node_name> <key>=<value>:<effect>

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

      $ oc adm taint nodes node1 node-role.kubernetes.io/infra=reserved:NoSchedule

      작은 정보

      다음 YAML을 적용하여 테인트를 추가할 수도 있습니다.

      kind: Node
      apiVersion: v1
      metadata:
        name: <node_name>
        labels:
          ...
      spec:
        taints:
          - key: node-role.kubernetes.io/infra
            effect: NoSchedule
            value: reserved
        ...

      이 예에서는 키node-role.kubernetes.io/infra 및 taint 효과 NoSchedule이 있는 node1에 taint를 배치합니다. NoSchedule 효과가 있는 노드는 taint를 허용하는 pod만 예약하지만 기존 pod는 노드에서 예약된 상태를 유지할 수 있습니다.

      참고

      descheduler를 사용하면 노드 taint를 위반하는 pod가 클러스터에서 제거될 수 있습니다.

   3. NoSchedule Effect와 위의 테인트와 함께 NoExecute Effect를 사용하여 테인트를 추가합니다.

      $ oc adm taint nodes <node_name> <key>=<value>:<effect>

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

      $ oc adm taint nodes node1 node-role.kubernetes.io/infra=reserved:NoExecute

      작은 정보

      다음 YAML을 적용하여 테인트를 추가할 수도 있습니다.

      kind: Node
      apiVersion: v1
      metadata:
        name: <node_name>
        labels:
          ...
      spec:
        taints:
          - key: node-role.kubernetes.io/infra
            effect: NoExecute
            value: reserved
        ...

      이 예에서는 node-role.kubernetes.io/infra 및 taint 효과 NoExecute 가 있는 node1 에 taint를 배치합니다. NoExecute 효과가 있는 노드는 테인트를 허용하는 Pod만 예약합니다. 이 효과에서는 일치하는 톨러레이션이 없는 노드에서 기존 Pod를 제거합니다.

2. 라우터, 레지스트리 및 모니터링 워크로드와 같이 인프라 노드에서 예약하려는 pod 구성에 대한 허용 오차를 추가합니다. 다음 코드를 Pod 개체 사양에 추가합니다.

   tolerations:
     - effect: NoSchedule 1
       key: node-role.kubernetes.io/infra 2
       value: reserved 3
     - effect: NoExecute 4
       key: node-role.kubernetes.io/infra 5
       operator: Exists 6
       value: reserved 7

   1

   노드에 추가한 효과를 지정합니다.

   2

   노드에 추가한 키를 지정합니다.

   3

   노드에 추가한 키-값 쌍 taint의 값을 지정합니다.

   4

   노드에 추가한 효과를 지정합니다.

   5

   노드에 추가한 키를 지정합니다.

   6

   노드에 elasticsearch 키가 있는 taint를 요구하도록 Exists Operator를 지정합니다.

   7

   노드에 추가한 키-값 쌍 taint의 값을 지정합니다.

   이 허용 오차는 oc adm taint 명령으로 생성된 taint와 일치합니다. 이 허용 오차가 있는 pod를 인프라 노드에 예약할 수 있습니다.

   참고

   OLM을 통해 설치된 Operator의 pod를 인프라 노드로 이동할 수는 없습니다. Operator pod를 이동하는 기능은 각 Operator의 구성에 따라 다릅니다.

3. 스케줄러를 사용하여 pod를 인프라 노드에 예약합니다. 자세한 내용은 노드에서 pod 배치 제어에 대한 설명서를 참조하십시오.

프로세스

1. 라우터 Operator의 IngressController 사용자 정의 리소스를 표시합니다.

   $ oc get ingresscontroller default -n openshift-ingress-operator -o yaml

   명령 출력은 다음 예제와 유사합니다.

   apiVersion: operator.openshift.io/v1
   kind: IngressController
   metadata:
     creationTimestamp: 2019-04-18T12:35:39Z
     finalizers:
     - ingresscontroller.operator.openshift.io/finalizer-ingresscontroller
     generation: 1
     name: default
     namespace: openshift-ingress-operator
     resourceVersion: "11341"
     selfLink: /apis/operator.openshift.io/v1/namespaces/openshift-ingress-operator/ingresscontrollers/default
     uid: 79509e05-61d6-11e9-bc55-02ce4781844a
   spec: {}
   status:
     availableReplicas: 2
     conditions:
     - lastTransitionTime: 2019-04-18T12:36:15Z
       status: "True"
       type: Available
     domain: apps.<cluster>.example.com
     endpointPublishingStrategy:
       type: LoadBalancerService
     selector: ingresscontroller.operator.openshift.io/deployment-ingresscontroller=default

2. ingresscontroller 리소스를 편집하고 infra 레이블을 사용하도록 nodeSelector를 변경합니다.

   $ oc edit ingresscontroller default -n openshift-ingress-operator

     spec:
       nodePlacement:
         nodeSelector: 1
           matchLabels:
             node-role.kubernetes.io/infra: ""
         tolerations:
         - effect: NoSchedule
           key: node-role.kubernetes.io/infra
           value: reserved
         - effect: NoExecute
           key: node-role.kubernetes.io/infra
           value: reserved

   1

   적절한 값이 설정된 nodeSelector 매개변수를 이동하려는 구성 요소에 추가합니다. 표시된 형식으로 nodeSelector를 사용하거나 노드에 지정된 값에 따라 <key>: <value> 쌍을 사용할 수 있습니다. 인프라 노드에 테인트를 추가한 경우 일치하는 허용 오차도 추가합니다.

3. 라우터 pod가 infra 노드에서 실행되고 있는지 확인합니다.

   1. 라우터 pod 목록을 표시하고 실행중인 pod의 노드 이름을 기록해 둡니다.

      $ oc get pod -n openshift-ingress -o wide

      출력 예

      NAME                              READY     STATUS        RESTARTS   AGE       IP           NODE                           NOMINATED NODE   READINESS GATES
      router-default-86798b4b5d-bdlvd   1/1      Running       0          28s       10.130.2.4   ip-10-0-217-226.ec2.internal   <none>           <none>
      router-default-955d875f4-255g8    0/1      Terminating   0          19h       10.129.2.4   ip-10-0-148-172.ec2.internal   <none>           <none>

      이 예에서 실행중인 pod는 ip-10-0-217-226.ec2.internal 노드에 있습니다.

   2. 실행중인 pod의 노드 상태를 표시합니다.

      $ oc get node <node_name> 1

      1

      pod 목록에서 얻은 <node_name>을 지정합니다.

      출력 예

      NAME                          STATUS  ROLES         AGE   VERSION
      ip-10-0-217-226.ec2.internal  Ready   infra,worker  17h   v1.30.3

      역할 목록에 infra가 포함되어 있으므로 pod가 올바른 노드에서 실행됩니다.

프로세스

1. config/instance 개체를 표시합니다.

   $ oc get configs.imageregistry.operator.openshift.io/cluster -o yaml

   출력 예

   apiVersion: imageregistry.operator.openshift.io/v1
   kind: Config
   metadata:
     creationTimestamp: 2019-02-05T13:52:05Z
     finalizers:
     - imageregistry.operator.openshift.io/finalizer
     generation: 1
     name: cluster
     resourceVersion: "56174"
     selfLink: /apis/imageregistry.operator.openshift.io/v1/configs/cluster
     uid: 36fd3724-294d-11e9-a524-12ffeee2931b
   spec:
     httpSecret: d9a012ccd117b1e6616ceccb2c3bb66a5fed1b5e481623
     logging: 2
     managementState: Managed
     proxy: {}
     replicas: 1
     requests:
       read: {}
       write: {}
     storage:
       s3:
         bucket: image-registry-us-east-1-c92e88cad85b48ec8b312344dff03c82-392c
         region: us-east-1
   status:
   ...

2. config/instance 개체를 편집합니다.

   $ oc edit configs.imageregistry.operator.openshift.io/cluster

   spec:
     affinity:
       podAntiAffinity:
         preferredDuringSchedulingIgnoredDuringExecution:
         - podAffinityTerm:
             namespaces:
             - openshift-image-registry
             topologyKey: kubernetes.io/hostname
           weight: 100
     logLevel: Normal
     managementState: Managed
     nodeSelector: 1
       node-role.kubernetes.io/infra: ""
     tolerations:
     - effect: NoSchedule
       key: node-role.kubernetes.io/infra
       value: reserved
     - effect: NoExecute
       key: node-role.kubernetes.io/infra
       value: reserved

   1

   적절한 값이 설정된 nodeSelector 매개변수를 이동하려는 구성 요소에 추가합니다. 표시된 형식으로 nodeSelector를 사용하거나 노드에 지정된 값에 따라 <key>: <value> 쌍을 사용할 수 있습니다. infrasructure 노드에 테인트를 추가한 경우 일치하는 톨러레이션도 추가합니다.

3. 레지스트리 pod가 인프라 노드로 이동되었는지 검증합니다.

   1. 다음 명령을 실행하여 레지스트리 pod가 있는 노드를 식별합니다.

      $ oc get pods -o wide -n openshift-image-registry

   2. 노드에 지정된 레이블이 있는지 확인합니다.

      $ oc describe node <node_name>

      명령 출력을 확인하고 node-role.kubernetes.io/infra가 LABELS 목록에 있는지 확인합니다.

프로세스

1. cluster-monitoring-config 구성 맵을 편집하고 infra 레이블을 사용하도록 nodeSelector 를 변경합니다.

   $ oc edit configmap cluster-monitoring-config -n openshift-monitoring

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: cluster-monitoring-config
     namespace: openshift-monitoring
   data:
     config.yaml: |+
       alertmanagerMain:
         nodeSelector: 1
           node-role.kubernetes.io/infra: ""
         tolerations:
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoSchedule
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoExecute
       prometheusK8s:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
         tolerations:
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoSchedule
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoExecute
       prometheusOperator:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
         tolerations:
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoSchedule
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoExecute
       metricsServer:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
         tolerations:
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoSchedule
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoExecute
       kubeStateMetrics:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
         tolerations:
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoSchedule
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoExecute
       telemeterClient:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
         tolerations:
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoSchedule
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoExecute
       openshiftStateMetrics:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
         tolerations:
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoSchedule
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoExecute
       thanosQuerier:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
         tolerations:
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoSchedule
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoExecute
       monitoringPlugin:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
         tolerations:
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoSchedule
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoExecute

   1

   적절한 값이 설정된 nodeSelector 매개변수를 이동하려는 구성 요소에 추가합니다. 표시된 형식으로 nodeSelector를 사용하거나 노드에 지정된 값에 따라 <key>: <value> 쌍을 사용할 수 있습니다. 인프라 노드에 테인트를 추가한 경우 일치하는 허용 오차도 추가합니다.

2. 모니터링 pod가 새 머신으로 이동하는 것을 확인합니다.

   $ watch 'oc get pod -n openshift-monitoring -o wide'

3. 구성 요소가 infra 노드로 이동하지 않은 경우 이 구성 요소가 있는 pod를 제거합니다.

   $ oc delete pod -n openshift-monitoring <pod>

   삭제된 pod의 구성 요소가 infra 노드에 다시 생성됩니다.

1. OpenShift Container Platform 웹 콘솔에서 관리 → 사용자 지정 리소스 정의 페이지로 전환합니다.
2. 사용자 지정 리소스 정의 페이지에서 FeatureGate를 클릭합니다.
3. 사용자 정의 리소스 정의 세부 정보 페이지에서 인스턴스 탭을 클릭합니다.
4. 클러스터 기능 게이트를 클릭한 다음 YAML 탭을 클릭합니다.

5. 특정 기능 세트를 추가하려면 클러스터 인스턴스를 편집합니다.

   주의

   클러스터에서 TechPreviewNoUpgrade 기능 세트를 활성화하면 취소할 수 없으며 마이너 버전 업데이트를 방지할 수 없습니다. 프로덕션 클러스터에서 이 기능 세트를 활성화해서는 안 됩니다.

   FeatureGate 사용자 지정 리소스 샘플

   apiVersion: config.openshift.io/v1
   kind: FeatureGate
   metadata:
     name: cluster 1
   # ...
   spec:
     featureSet: TechPreviewNoUpgrade 2

   1

   FeatureGate CR의 이름은 cluster이어야 합니다.

   2

   활성화할 기능 세트를 추가합니다.

   • TechPreviewNoUpgrade를 사용하면 특정 기술 프리뷰 기능을 사용할 수 있습니다.

   변경 사항을 저장하면 새 머신 구성이 생성되면 머신 구성 풀이 업데이트되고 변경 사항이 적용되는 동안 각 노드의 예약이 비활성화됩니다.

1. 웹 콘솔의 관리자 화면에서 컴퓨팅 → 노드로 이동합니다.
2. 노드를 선택합니다.
3. 노드 세부 정보 페이지에서 터미널을 클릭합니다.

4. 터미널 창에서 root 디렉토리를 /host 로 변경합니다.

   sh-4.2# chroot /host

5. kubelet.conf 파일을 확인합니다.

   sh-4.2# cat /etc/kubernetes/kubelet.conf

   샘플 출력

   # ...
   featureGates:
     InsightsOperatorPullingSCA: true,
     LegacyNodeRoleBehavior: false
   # ...

   true 로 나열된 기능은 클러스터에서 활성화됩니다.

   참고

   나열된 기능은 OpenShift Container Platform 버전에 따라 다릅니다.

1. cluster라는 FeatureGate CR을 편집합니다.

   $ oc edit featuregate cluster

   주의

   클러스터에서 TechPreviewNoUpgrade 기능 세트를 활성화하면 취소할 수 없으며 마이너 버전 업데이트를 방지할 수 없습니다. 프로덕션 클러스터에서 이 기능 세트를 활성화해서는 안 됩니다.

   FeatureGate 사용자 지정 리소스 샘플

   apiVersion: config.openshift.io/v1
   kind: FeatureGate
   metadata:
     name: cluster 1
   # ...
   spec:
     featureSet: TechPreviewNoUpgrade 2

   1

   FeatureGate CR의 이름은 cluster이어야 합니다.

   2

   활성화할 기능 세트를 추가합니다.

   • TechPreviewNoUpgrade를 사용하면 특정 기술 프리뷰 기능을 사용할 수 있습니다.

   변경 사항을 저장하면 새 머신 구성이 생성되면 머신 구성 풀이 업데이트되고 변경 사항이 적용되는 동안 각 노드의 예약이 비활성화됩니다.

1. 웹 콘솔의 관리자 화면에서 컴퓨팅 → 노드로 이동합니다.
2. 노드를 선택합니다.
3. 노드 세부 정보 페이지에서 터미널을 클릭합니다.

4. 터미널 창에서 root 디렉토리를 /host 로 변경합니다.

   sh-4.2# chroot /host

5. kubelet.conf 파일을 확인합니다.

   sh-4.2# cat /etc/kubernetes/kubelet.conf

   샘플 출력

   # ...
   featureGates:
     InsightsOperatorPullingSCA: true,
     LegacyNodeRoleBehavior: false
   # ...

   true 로 나열된 기능은 클러스터에서 활성화됩니다.

   참고

   나열된 기능은 OpenShift Container Platform 버전에 따라 다릅니다.

프로세스

1. APIServer 오브젝트를 수정합니다.

   $ oc edit apiserver

2. spec.encryption.type 필드를 aesgcm 또는 aescbc 로 설정합니다.

   spec:
     encryption:
       type: aesgcm 1

   1

   AES-GCM 암호화의 aesgcm 또는 AES-CBC 암호화를 위한 aescbc 로 설정합니다.

3. 파일을 저장하여 변경 사항을 적용합니다.

   암호화 프로세스가 시작됩니다. etcd 데이터베이스 크기에 따라 이 프로세스를 완료하는 데 20분 이상 걸릴 수 있습니다.

4. etcd 암호화에 성공했는지 확인합니다.

   1. OpenShift API 서버의 Encrypted 상태 조건을 검토하여 해당 리소스가 성공적으로 암호화되었는지 확인합니다.

      $ oc get openshiftapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'

      암호화에 성공하면 출력에 EncryptionCompleted가 표시됩니다.

      EncryptionCompleted
      All resources encrypted: routes.route.openshift.io

      출력에 EncryptionInProgress가 표시되는 경우에도 암호화는 계속 진행 중입니다. 몇 분 기다린 후 다시 시도합니다.

   2. 쿠버네티스 API 서버의 Encrypted 상태 조건을 검토하여 해당 리소스가 성공적으로 암호화되었는지 확인합니다.

      $ oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'

      암호화에 성공하면 출력에 EncryptionCompleted가 표시됩니다.

      EncryptionCompleted
      All resources encrypted: secrets, configmaps

      출력에 EncryptionInProgress가 표시되는 경우에도 암호화는 계속 진행 중입니다. 몇 분 기다린 후 다시 시도합니다.

   3. OpenShift OAuth API 서버의 Encrypted 상태 조건을 검토하여 해당 리소스가 성공적으로 암호화되었는지 확인합니다.

      $ oc get authentication.operator.openshift.io -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'

      암호화에 성공하면 출력에 EncryptionCompleted가 표시됩니다.

      EncryptionCompleted
      All resources encrypted: oauthaccesstokens.oauth.openshift.io, oauthauthorizetokens.oauth.openshift.io

      출력에 EncryptionInProgress가 표시되는 경우에도 암호화는 계속 진행 중입니다. 몇 분 기다린 후 다시 시도합니다.

프로세스

1. APIServer 오브젝트를 수정합니다.

   $ oc edit apiserver

2. 암호화 필드 유형을 identity로 설정합니다.

   spec:
     encryption:
       type: identity 1

   1

   identity 유형이 기본값이며, 이는 암호화가 수행되지 않음을 의미합니다.

3. 파일을 저장하여 변경 사항을 적용합니다.

   암호 해독 프로세스가 시작됩니다. 클러스터 크기에 따라 이 프로세스를 완료하는 데 20분 이상 걸릴 수 있습니다.

4. etcd 암호 해독에 성공했는지 확인합니다.

   1. OpenShift API 서버의 Encrypted 상태 조건을 검토하여 해당 리소스의 암호가 성공적으로 해독되었는지 확인합니다.

      $ oc get openshiftapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'

      암호 해독에 성공하면 출력에 DecryptionCompleted가 표시됩니다.

      DecryptionCompleted
      Encryption mode set to identity and everything is decrypted

      출력에 DecryptionInProgress가 표시되면 암호 해독이 여전히 진행 중임을 나타냅니다. 몇 분 기다린 후 다시 시도합니다.

   2. 쿠버네티스 API 서버의 Encrypted 상태 조건을 검토하여 해당 리소스의 암호가 성공적으로 해독되었는지 확인합니다.

      $ oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'

      암호 해독에 성공하면 출력에 DecryptionCompleted가 표시됩니다.

      DecryptionCompleted
      Encryption mode set to identity and everything is decrypted

      출력에 DecryptionInProgress가 표시되면 암호 해독이 여전히 진행 중임을 나타냅니다. 몇 분 기다린 후 다시 시도합니다.

   3. OpenShift API 서버의 Encrypted 상태 조건을 검토하여 해당 리소스의 암호가 성공적으로 해독되었는지 확인합니다.

      $ oc get authentication.operator.openshift.io -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'

      암호 해독에 성공하면 출력에 DecryptionCompleted가 표시됩니다.

      DecryptionCompleted
      Encryption mode set to identity and everything is decrypted

      출력에 DecryptionInProgress가 표시되면 암호 해독이 여전히 진행 중임을 나타냅니다. 몇 분 기다린 후 다시 시도합니다.

프로세스

1. 컨트롤 플레인 노드의 root로 디버그 세션을 시작합니다.

   $ oc debug --as-root node/<node_name>

2. 디버그 쉘에서 root 디렉토리를 /host 로 변경합니다.

   sh-4.4# chroot /host

3. 클러스터 전체 프록시가 활성화된 경우 다음 명령을 실행하여 NO_PROXY,HTTP_PROXY 및 HTTPS_PROXY 환경 변수를 내보냅니다.

   $ export HTTP_PROXY=http://<your_proxy.example.com>:8080

   $ export HTTPS_PROXY=https://<your_proxy.example.com>:8080

   $ export NO_PROXY=<example.com>

4. 디버그 쉘에서 cluster-backup.sh 스크립트를 실행하고 백업을 저장할 위치를 전달합니다.

   작은 정보

   cluster-backup.sh 스크립트는 etcd Cluster Operator의 구성 요소로 유지 관리되며 etcdctl snapshot save 명령 관련 래퍼입니다.

   sh-4.4# /usr/local/bin/cluster-backup.sh /home/core/assets/backup

   스크립트 출력 예

   found latest kube-apiserver: /etc/kubernetes/static-pod-resources/kube-apiserver-pod-6
   found latest kube-controller-manager: /etc/kubernetes/static-pod-resources/kube-controller-manager-pod-7
   found latest kube-scheduler: /etc/kubernetes/static-pod-resources/kube-scheduler-pod-6
   found latest etcd: /etc/kubernetes/static-pod-resources/etcd-pod-3
   ede95fe6b88b87ba86a03c15e669fb4aa5bf0991c180d3c6895ce72eaade54a1
   etcdctl version: 3.4.14
   API version: 3.4
   {"level":"info","ts":1624647639.0188997,"caller":"snapshot/v3_snapshot.go:119","msg":"created temporary db file","path":"/home/core/assets/backup/snapshot_2021-06-25_190035.db.part"}
   {"level":"info","ts":"2021-06-25T19:00:39.030Z","caller":"clientv3/maintenance.go:200","msg":"opened snapshot stream; downloading"}
   {"level":"info","ts":1624647639.0301006,"caller":"snapshot/v3_snapshot.go:127","msg":"fetching snapshot","endpoint":"https://10.0.0.5:2379"}
   {"level":"info","ts":"2021-06-25T19:00:40.215Z","caller":"clientv3/maintenance.go:208","msg":"completed snapshot read; closing"}
   {"level":"info","ts":1624647640.6032252,"caller":"snapshot/v3_snapshot.go:142","msg":"fetched snapshot","endpoint":"https://10.0.0.5:2379","size":"114 MB","took":1.584090459}
   {"level":"info","ts":1624647640.6047094,"caller":"snapshot/v3_snapshot.go:152","msg":"saved","path":"/home/core/assets/backup/snapshot_2021-06-25_190035.db"}
   Snapshot saved at /home/core/assets/backup/snapshot_2021-06-25_190035.db
   {"hash":3866667823,"revision":31407,"totalKey":12828,"totalSize":114446336}
   snapshot db and kube resources are successfully saved to /home/core/assets/backup

   이 예제에서는 컨트롤 플레인 호스트의 /home/core/assets/backup/ 디렉토리에 두 개의 파일이 생성됩니다.

   • snapshot_<datetimestamp>.db:이 파일은 etcd 스냅샷입니다. cluster-backup.sh 스크립트는 유효성을 확인합니다.

   • static_kuberesources_<datetimestamp>.tar.gz: 이 파일에는 정적 pod 리소스가 포함되어 있습니다. etcd 암호화가 활성화되어 있는 경우 etcd 스냅 샷의 암호화 키도 포함됩니다.

     참고

     etcd 암호화가 활성화되어 있는 경우 보안상의 이유로 이 두 번째 파일을 etcd 스냅 샷과 별도로 저장하는 것이 좋습니다. 그러나 이 파일은 etcd 스냅 샷에서 복원하는데 필요합니다.

     etcd 암호화는 키가 아닌 값만 암호화합니다. 즉, 리소스 유형, 네임 스페이스 및 개체 이름은 암호화되지 않습니다.

프로세스

1. 복구 호스트로 사용할 컨트롤 플레인 호스트를 선택합니다. 이는 복구 작업을 실행할 호스트입니다.

2. 복구 호스트를 포함하여 각 컨트롤 플레인 노드에 SSH 연결을 설정합니다.

   복원 프로세스가 시작된 후 kube-apiserver 에 액세스할 수 없으므로 컨트롤 플레인 노드에 액세스할 수 없습니다. 따라서 다른 터미널에서 각 컨트롤 플레인 호스트에 대한 SSH 연결을 설정하는 것이 좋습니다.

   중요

   이 단계를 완료하지 않으면 컨트롤 플레인 호스트에 액세스하여 복구 프로세스를 완료할 수 없으며 이 상태에서 클러스터를 복구할 수 없습니다.

3. etcd 백업 디렉터리를 복구 컨트롤 플레인 호스트에 복사합니다.

   이 절차에서는 etcd 스냅샷과 정적 pod의 리소스가 포함된 백업 디렉터리를 복구 컨트롤 플레인 호스트의 /home/core/ 디렉터리에 복사하는 것을 전제로 합니다.

4. 다른 컨트롤 플레인 노드에서 고정 Pod를 중지합니다.

   참고

   복구 호스트에서 정적 Pod를 중지할 필요가 없습니다.

   1. 복구 호스트가 아닌 컨트롤 플레인 호스트에 액세스합니다.

   2. 다음을 실행하여 kubelet 매니페스트 디렉토리에서 기존 etcd pod 파일을 이동합니다.

      $ sudo mv -v /etc/kubernetes/manifests/etcd-pod.yaml /tmp

   3. 다음을 사용하여 etcd pod가 중지되었는지 확인합니다.

      $ sudo crictl ps | grep etcd | egrep -v "operator|etcd-guard"

      이 명령의 출력이 비어 있지 않으면 몇 분 기다렸다가 다시 확인하십시오.

   4. 다음을 실행하여 kubelet 매니페스트 디렉토리에서 기존 kube-apiserver 파일을 이동합니다.

      $ sudo mv -v /etc/kubernetes/manifests/kube-apiserver-pod.yaml /tmp

   5. 다음을 실행하여 kube-apiserver 컨테이너가 중지되었는지 확인합니다.

      $ sudo crictl ps | grep kube-apiserver | egrep -v "operator|guard"

      이 명령의 출력이 비어 있지 않으면 몇 분 기다렸다가 다시 확인하십시오.

   6. 다음을 사용하여 kubelet 매니페스트 디렉토리에서 기존 kube-controller-manager 파일을 이동합니다.

      $ sudo mv -v /etc/kubernetes/manifests/kube-controller-manager-pod.yaml /tmp

   7. 다음을 실행하여 kube-controller-manager 컨테이너가 중지되었는지 확인합니다.

      $ sudo crictl ps | grep kube-controller-manager | egrep -v "operator|guard"

      이 명령의 출력이 비어 있지 않으면 몇 분 기다렸다가 다시 확인하십시오.

   8. 다음을 사용하여 kubelet 매니페스트 디렉토리에서 기존 kube-scheduler 파일을 이동합니다.

      $ sudo mv -v /etc/kubernetes/manifests/kube-scheduler-pod.yaml /tmp

   9. 다음을 사용하여 kube-scheduler 컨테이너가 중지되었는지 확인합니다.

      $ sudo crictl ps | grep kube-scheduler | egrep -v "operator|guard"

      이 명령의 출력이 비어 있지 않으면 몇 분 기다렸다가 다시 확인하십시오.

   10. 다음 예와 함께 etcd 데이터 디렉터리를 다른 위치로 이동합니다.

       $ sudo mv -v /var/lib/etcd/ /tmp

   11. /etc/kubernetes/manifests/keepalived.yaml 파일이 있고 노드가 삭제되면 다음 단계를 따르십시오.

       1. kubelet 매니페스트 디렉토리에서 /etc/kubernetes/manifests/keepalived.yaml 파일을 이동합니다.

          $ sudo mv -v /etc/kubernetes/manifests/keepalived.yaml /tmp

       2. keepalived 데몬에서 관리하는 컨테이너가 중지되었는지 확인합니다.

          $ sudo crictl ps --name keepalived

          이 명령의 출력은 비어 있어야합니다. 비어 있지 않은 경우 몇 분 기다렸다가 다시 확인하십시오.

       3. 컨트롤 플레인에 VIP가 할당되어 있는지 확인합니다.

          $ ip -o address | egrep '<api_vip>|<ingress_vip>'

       4. 보고된 각 VIP에 대해 다음 명령을 실행하여 제거합니다.

          $ sudo ip address del <reported_vip> dev <reported_vip_device>

   12. 복구 호스트가 아닌 다른 컨트롤 플레인 호스트에서 이 단계를 반복합니다.
5. 복구 컨트롤 플레인 호스트에 액세스합니다.

6. keepalived 데몬이 사용 중인 경우 복구 컨트롤 플레인 노드가 VIP를 소유하고 있는지 확인합니다.

   $ ip -o address | grep <api_vip>

   VIP 주소가 있는 경우 출력에 강조 표시됩니다. VIP가 잘못 설정되거나 구성되지 않은 경우 이 명령은 빈 문자열을 반환합니다.

7. 클러스터 전체의 프록시가 활성화되어 있는 경우 NO_PROXY, HTTP_PROXY 및 https_proxy 환경 변수를 내보내고 있는지 확인합니다.

   작은 정보

   oc get proxy cluster -o yaml의 출력을 확인하여 프록시가 사용 가능한지 여부를 확인할 수 있습니다. httpProxy, httpsProxy 및 noProxy 필드에 값이 설정되어 있으면 프록시가 사용됩니다.

8. 복구 컨트롤 플레인 호스트에서 복원 스크립트를 실행하고 etcd 백업 디렉터리에 경로를 전달합니다.

   $ sudo -E /usr/local/bin/cluster-restore.sh /home/core/assets/backup

   스크립트 출력 예

   ...stopping kube-scheduler-pod.yaml
   ...stopping kube-controller-manager-pod.yaml
   ...stopping etcd-pod.yaml
   ...stopping kube-apiserver-pod.yaml
   Waiting for container etcd to stop
   .complete
   Waiting for container etcdctl to stop
   .............................complete
   Waiting for container etcd-metrics to stop
   complete
   Waiting for container kube-controller-manager to stop
   complete
   Waiting for container kube-apiserver to stop
   ..........................................................................................complete
   Waiting for container kube-scheduler to stop
   complete
   Moving etcd data-dir /var/lib/etcd/member to /var/lib/etcd-backup
   starting restore-etcd static pod
   starting kube-apiserver-pod.yaml
   static-pod-resources/kube-apiserver-pod-7/kube-apiserver-pod.yaml
   starting kube-controller-manager-pod.yaml
   static-pod-resources/kube-controller-manager-pod-7/kube-controller-manager-pod.yaml
   starting kube-scheduler-pod.yaml
   static-pod-resources/kube-scheduler-pod-8/kube-scheduler-pod.yaml

   cluster-restore.sh 스크립트는 etcd,kube-apiserver,kube-controller-manager 및 kube-scheduler Pod가 중지되고 복원 프로세스가 끝날 때 시작되었음을 표시해야합니다.

   참고

   마지막 etcd 백업 후 노드 인증서가 업데이트된 경우 복원 프로세스에서 노드가 NotReady 상태가 될 수 있습니다.

9. 노드가 Ready 상태인지 확인합니다.

   1. 다음 명령을 실행합니다.

      $ oc get nodes -w

      샘플 출력

      NAME                STATUS  ROLES          AGE     VERSION
      host-172-25-75-28   Ready   master         3d20h   v1.30.3
      host-172-25-75-38   Ready   infra,worker   3d20h   v1.30.3
      host-172-25-75-40   Ready   master         3d20h   v1.30.3
      host-172-25-75-65   Ready   master         3d20h   v1.30.3
      host-172-25-75-74   Ready   infra,worker   3d20h   v1.30.3
      host-172-25-75-79   Ready   worker         3d20h   v1.30.3
      host-172-25-75-86   Ready   worker         3d20h   v1.30.3
      host-172-25-75-98   Ready   infra,worker   3d20h   v1.30.3

      모든 노드가 상태를 보고하는 데 몇 분이 걸릴 수 있습니다.

   2. 노드가 NotReady 상태에 있는 경우 노드에 로그인하고 각 노드의 /var/lib/kubelet/pki 디렉토리에서 모든 PEM 파일을 제거합니다. 웹 콘솔의 터미널 창을 사용하거나 노드에 SSH를 수행할 수 있습니다.

      $  ssh -i <ssh-key-path> core@<master-hostname>

      샘플 pki 디렉토리

      sh-4.4# pwd
      /var/lib/kubelet/pki
      sh-4.4# ls
      kubelet-client-2022-04-28-11-24-09.pem  kubelet-server-2022-04-28-11-24-15.pem
      kubelet-client-current.pem              kubelet-server-current.pem

10. 모든 컨트롤 플레인 호스트에서 kubelet 서비스를 다시 시작합니다.

    1. 복구 호스트에서 다음을 실행합니다.

       $ sudo systemctl restart kubelet.service

    2. 다른 모든 컨트롤 플레인 호스트에서 이 단계를 반복합니다.

11. 보류 중인 인증서 서명 요청(CSR)을 승인합니다.

    참고

    3개의 스케줄링 가능한 컨트롤 플레인 노드로 구성된 단일 노드 클러스터 또는 클러스터와 같은 작업자 노드가 없는 클러스터에는 승인할 보류 중인 CSR이 없습니다. 이 단계에서 나열된 모든 명령을 건너뛸 수 있습니다.

    1. 다음을 실행하여 현재 CSR 목록을 가져옵니다.

       $ oc get csr

       출력 예

       NAME        AGE    SIGNERNAME                                    REQUESTOR                                                                   CONDITION
       csr-2s94x   8m3s   kubernetes.io/kubelet-serving                 system:node:<node_name>                                                     Pending 1
       csr-4bd6t   8m3s   kubernetes.io/kubelet-serving                 system:node:<node_name>                                                     Pending 2
       csr-4hl85   13m    kubernetes.io/kube-apiserver-client-kubelet   system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending 3
       csr-zhhhp   3m8s   kubernetes.io/kube-apiserver-client-kubelet   system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending 4
       ...

       1 1 2

       kubelet 서비스 끝점에 대해 노드에서 요청한 보류 중인 kubelet 서비스 CSR입니다.

       3 4

       node-bootstrapper 노드 부트스트랩 인증 정보로 요청된 보류 중인 kubelet 클라이언트 CSR.

    2. CSR의 세부 정보를 검토하여 다음을 실행하여 유효한지 확인합니다.

       $ oc describe csr <csr_name> 1

       1

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

    3. 다음을 실행하여 각 유효한 node-bootstrapper CSR을 승인합니다.

       $ oc adm certificate approve <csr_name>

    4. 사용자 프로비저닝 설치의 경우 다음을 실행하여 각 유효한 kubelet 서비스 CSR을 승인합니다.

       $ oc adm certificate approve <csr_name>

12. 단일 멤버 컨트롤 플레인이 제대로 시작되었는지 확인합니다.

    1. 복구 호스트에서 다음을 사용하여 etcd 컨테이너가 실행 중인지 확인합니다.

       $ sudo crictl ps | grep etcd | egrep -v "operator|etcd-guard"

       출력 예

       3ad41b7908e32       36f86e2eeaaffe662df0d21041eb22b8198e0e58abeeae8c743c3e6e977e8009                                                         About a minute ago   Running             etcd                                          0                   7c05f8af362f0

    2. 복구 호스트에서 다음을 사용하여 etcd pod가 실행 중인지 확인합니다.

       $ oc -n openshift-etcd get pods -l k8s-app=etcd

       출력 예

       NAME                                             READY   STATUS      RESTARTS   AGE
       etcd-ip-10-0-143-125.ec2.internal                1/1     Running     1          2m47s

       상태가 Pending 또는 출력에 두 개 이상의 etcd pod가 나열된 경우 몇 분 기다렸다가 다시 확인하십시오.

13. OVNKubernetes 네트워크 플러그인을 사용하는 경우 ovnkube-controlplane Pod를 다시 시작해야 합니다.

    1. 다음을 실행하여 모든 ovnkube-controlplane Pod를 삭제합니다.

       $ oc -n openshift-ovn-kubernetes delete pod -l app=ovnkube-control-plane

    2. 다음을 사용하여 모든 ovnkube-controlplane Pod가 재배포되었는지 확인합니다.

       $ oc -n openshift-ovn-kubernetes get pod -l app=ovnkube-control-plane

14. OVN-Kubernetes 네트워크 플러그인을 사용하는 경우 하나씩 모든 노드에서 OVN(Open Virtual Network) Kubernetes Pod를 다시 시작합니다. 다음 단계를 사용하여 각 노드에서 OVN-Kubernetes Pod를 다시 시작합니다.

    중요

    다음 순서로 OVN-Kubernetes Pod를 다시 시작

    1. 복구 컨트롤 플레인 호스트
    2. 다른 컨트롤 플레인 호스트(사용 가능한 경우)
    3. 기타 노드
    참고

    승인 Webhook 검증 및 변경으로 Pod를 거부할 수 있습니다. failurePolicy 가 Fail 로 설정된 추가 Webhook를 추가하면 Pod를 거부하고 복원 프로세스가 실패할 수 있습니다. 클러스터 상태를 복원하는 동안 Webhook를 저장하고 삭제하여 이 문제를 방지할 수 있습니다. 클러스터 상태가 성공적으로 복원되면 Webhook를 다시 활성화할 수 있습니다.

    또는 클러스터 상태를 복원하는 동안 failurePolicy 를 Ignore 로 일시적으로 설정할 수 있습니다. 클러스터 상태가 성공적으로 복원되면 failurePolicy 를 Fail 로 설정할 수 있습니다.

    1. northbound 데이터베이스(nbdb) 및 southbound 데이터베이스(sbdb)를 제거합니다. SSH(Secure Shell)를 사용하여 복구 호스트 및 나머지 컨트롤 플레인 노드에 액세스하고 다음을 실행합니다.

       $ sudo rm -f /var/lib/ovn-ic/etc/*.db

    2. OpenVSwitch 서비스를 다시 시작합니다. SSH(Secure Shell)를 사용하여 노드에 액세스하고 다음 명령을 실행합니다.

       $ sudo systemctl restart ovs-vswitchd ovsdb-server

    3. 다음 명령을 실행하여 노드에서 ovnkube-node Pod를 삭제하고 <node>를 다시 시작하는 노드의 이름으로 교체합니다.

       $ oc -n openshift-ovn-kubernetes delete pod -l app=ovnkube-node --field-selector=spec.nodeName==<node>

    4. 다음을 사용하여 ovnkube-node Pod가 다시 실행 중인지 확인합니다.

       $ oc -n openshift-ovn-kubernetes get pod -l app=ovnkube-node --field-selector=spec.nodeName==<node>

       참고

       Pod를 다시 시작하는 데 몇 분이 걸릴 수 있습니다.

15. 복구되지 않은 다른 컨트롤 플레인 시스템을 삭제하고 다시 생성합니다. 머신이 다시 생성되면 새 버전이 강제 생성되고 etcd 가 자동으로 확장됩니다.

    • 사용자가 프로비저닝한 베어 메탈 설치를 사용하는 경우 원래에 사용한 것과 동일한 방법을 사용하여 컨트롤 플레인 시스템을 다시 생성할 수 있습니다. 자세한 내용은 " bare metal에 사용자 프로비저닝 클러스터 설치"를 참조하십시오.

      주의

      복구 호스트에 대한 시스템을 삭제하고 다시 생성하지 마십시오.

    • 설치 관리자 프로비저닝 인프라를 실행 중이거나 Machine API를 사용하여 머신을 생성한 경우 다음 단계를 따르십시오.

      주의

      복구 호스트에 대한 시스템을 삭제하고 다시 생성하지 마십시오.

      설치 관리자 프로비저닝 인프라에 베어 메탈 설치의 경우 컨트롤 플레인 머신이 다시 생성되지 않습니다. 자세한 내용은 " 베어 메탈 컨트롤 플레인 노드 교체"를 참조하십시오.

      1. 손실된 컨트롤 플레인 호스트 중 하나에 대한 머신을 가져옵니다.

         cluster-admin 사용자로 클러스터에 액세스할 수 있는 터미널에서 다음 명령을 실행합니다.

         $ oc get machines -n openshift-machine-api -o wide

         출력 예:

         NAME                                        PHASE     TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
         clustername-8qw5l-master-0                  Running   m4.xlarge   us-east-1   us-east-1a   3h37m   ip-10-0-131-183.ec2.internal   aws:///us-east-1a/i-0ec2782f8287dfb7e   stopped 1
         clustername-8qw5l-master-1                  Running   m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-143-125.ec2.internal   aws:///us-east-1b/i-096c349b700a19631   running
         clustername-8qw5l-master-2                  Running   m4.xlarge   us-east-1   us-east-1c   3h37m   ip-10-0-154-194.ec2.internal    aws:///us-east-1c/i-02626f1dba9ed5bba  running
         clustername-8qw5l-worker-us-east-1a-wbtgd   Running   m4.large    us-east-1   us-east-1a   3h28m   ip-10-0-129-226.ec2.internal   aws:///us-east-1a/i-010ef6279b4662ced   running
         clustername-8qw5l-worker-us-east-1b-lrdxb   Running   m4.large    us-east-1   us-east-1b   3h28m   ip-10-0-144-248.ec2.internal   aws:///us-east-1b/i-0cb45ac45a166173b   running
         clustername-8qw5l-worker-us-east-1c-pkg26   Running   m4.large    us-east-1   us-east-1c   3h28m   ip-10-0-170-181.ec2.internal   aws:///us-east-1c/i-06861c00007751b0a   running

         1

         손실된 컨트롤 플레인 호스트인 ip-10-0-131-183.ec2.internal 의 컨트롤 플레인 시스템입니다.

      2. 다음을 실행하여 손실된 컨트롤 플레인 호스트의 시스템을 삭제합니다.

         $ oc delete machine -n openshift-machine-api clustername-8qw5l-master-0 1

         1

         손실된 컨트롤 플레인 호스트의 컨트롤 플레인 시스템의 이름을 지정합니다.

         손실된 컨트롤 플레인 호스트의 시스템을 삭제한 후 새 시스템이 자동으로 프로비저닝됩니다.

      3. 다음을 실행하여 새 시스템이 생성되었는지 확인합니다.

         $ oc get machines -n openshift-machine-api -o wide

         출력 예:

         NAME                                        PHASE          TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
         clustername-8qw5l-master-1                  Running        m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-143-125.ec2.internal   aws:///us-east-1b/i-096c349b700a19631   running
         clustername-8qw5l-master-2                  Running        m4.xlarge   us-east-1   us-east-1c   3h37m   ip-10-0-154-194.ec2.internal    aws:///us-east-1c/i-02626f1dba9ed5bba  running
         clustername-8qw5l-master-3                  Provisioning   m4.xlarge   us-east-1   us-east-1a   85s     ip-10-0-173-171.ec2.internal    aws:///us-east-1a/i-015b0888fe17bc2c8  running 1
         clustername-8qw5l-worker-us-east-1a-wbtgd   Running        m4.large    us-east-1   us-east-1a   3h28m   ip-10-0-129-226.ec2.internal   aws:///us-east-1a/i-010ef6279b4662ced   running
         clustername-8qw5l-worker-us-east-1b-lrdxb   Running        m4.large    us-east-1   us-east-1b   3h28m   ip-10-0-144-248.ec2.internal   aws:///us-east-1b/i-0cb45ac45a166173b   running
         clustername-8qw5l-worker-us-east-1c-pkg26   Running        m4.large    us-east-1   us-east-1c   3h28m   ip-10-0-170-181.ec2.internal   aws:///us-east-1c/i-06861c00007751b0a   running

         1

         새 시스템 clustername-8qw5l-master-3 이 생성되고 단계가 Provisioning 에서 Running 으로 변경된 후 준비됩니다.

         새 시스템을 만드는 데 몇 분이 소요될 수 있습니다. etcd 클러스터 Operator는 머신 또는 노드가 정상 상태로 돌아올 때 자동으로 동기화됩니다.

      4. 복구 호스트가 아닌 모든 컨트롤 플레인 호스트에 대해 이 단계를 반복합니다.

16. 다음을 입력하여 쿼럼 가드를 끕니다.

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": {"useUnsupportedUnsafeNonHANonProductionUnstableEtcd": true}}}'

    이 명령을 사용하면 시크릿을 성공적으로 다시 생성하고 정적 Pod를 롤아웃할 수 있습니다.

17. 복구 호스트 내의 별도의 터미널 창에서 다음을 실행하여 복구 kubeconfig 파일을 내보냅니다.

    $ export KUBECONFIG=/etc/kubernetes/static-pod-resources/kube-apiserver-certs/secrets/node-kubeconfigs/localhost-recovery.kubeconfig

18. etcd 를 강제로 재배포합니다.

    복구 kubeconfig 파일을 내보낸 동일한 터미널 창에서 다음을 실행합니다.

    $ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge 1

    1

    forceRedeploymentReason 값은 고유해야하므로 타임 스탬프가 추가됩니다.

    etcd 재배포가 시작됩니다.

    etcd 클러스터 Operator가 재배포를 수행하면 기존 노드가 초기 부트스트랩 확장과 유사한 새 Pod로 시작됩니다.

19. 다음을 입력하여 쿼럼 가드를 다시 켭니다.

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": null}}'

20. 다음을 실행하여 unsupportedConfigOverrides 섹션이 오브젝트에서 제거되었는지 확인할 수 있습니다.

    $ oc get etcd/cluster -oyaml

21. 모든 노드가 최신 버전으로 업데이트되었는지 확인합니다.

    cluster-admin 사용자로 클러스터에 액세스할 수 있는 터미널에서 다음을 실행합니다.

    $ oc get etcd -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'

    etcd 의 NodeInstallerProgressing 상태 조건을 검토하여 모든 노드가 최신 버전인지 확인합니다. 업데이트가 성공적으로 실행되면 출력에 AllNodesAtLatestRevision이 표시됩니다.

    AllNodesAtLatestRevision
    3 nodes are at revision 7 1

    1

    이 예에서 최신 버전 번호는 7입니다.

    출력에 2 nodes are at revision 6; 1 nodes are at revision 7와 같은 여러 버전 번호가 표시되면 이는 업데이트가 아직 진행 중임을 의미합니다. 몇 분 기다린 후 다시 시도합니다.

22. etcd 를 재배포한 후 컨트롤 플레인에 새 롤아웃을 강제 적용합니다. kubelet이 내부 로드 밸런서를 사용하여 API 서버에 연결되어 있기 때문에 kube-apiserver 는 다른 노드에 다시 설치됩니다.

    cluster-admin 사용자로 클러스터에 액세스할 수 있는 터미널에서 다음을 실행합니다.

    1. kube-apiserver 에 대해 새 롤아웃을 강제 적용합니다.

       $ oc patch kubeapiserver cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge

       모든 노드가 최신 버전으로 업데이트되었는지 확인합니다.

       $ oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'

       NodeInstallerProgressing 상태 조건을 확인하고 모든 노드가 최신 버전인지 확인합니다. 업데이트가 성공적으로 실행되면 출력에 AllNodesAtLatestRevision이 표시됩니다.

       AllNodesAtLatestRevision
       3 nodes are at revision 7 1

       1

       이 예에서 최신 버전 번호는 7입니다.

       출력에 2 nodes are at revision 6; 1 nodes are at revision 7와 같은 여러 버전 번호가 표시되면 이는 업데이트가 아직 진행 중임을 의미합니다. 몇 분 기다린 후 다시 시도합니다.

    2. 다음 명령을 실행하여 Kubernetes 컨트롤러 관리자에 대해 새 롤아웃을 강제 적용합니다.

       $ oc patch kubecontrollermanager cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge

       다음을 실행하여 모든 노드가 최신 버전으로 업데이트되었는지 확인합니다.

       $ oc get kubecontrollermanager -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'

       NodeInstallerProgressing 상태 조건을 확인하고 모든 노드가 최신 버전인지 확인합니다. 업데이트가 성공적으로 실행되면 출력에 AllNodesAtLatestRevision이 표시됩니다.

       AllNodesAtLatestRevision
       3 nodes are at revision 7 1

       1

       이 예에서 최신 버전 번호는 7입니다.

       출력에 2 nodes are at revision 6; 1 nodes are at revision 7와 같은 여러 버전 번호가 표시되면 이는 업데이트가 아직 진행 중임을 의미합니다. 몇 분 기다린 후 다시 시도합니다.

    3. 다음을 실행하여 kube-scheduler 에 새 롤아웃을 강제 적용합니다.

       $ oc patch kubescheduler cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge

       다음을 사용하여 모든 노드가 최신 버전으로 업데이트되었는지 확인합니다.

       $ oc get kubescheduler -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'

       NodeInstallerProgressing 상태 조건을 확인하고 모든 노드가 최신 버전인지 확인합니다. 업데이트가 성공적으로 실행되면 출력에 AllNodesAtLatestRevision이 표시됩니다.

       AllNodesAtLatestRevision
       3 nodes are at revision 7 1

       1

       이 예에서 최신 버전 번호는 7입니다.

       출력에 2 nodes are at revision 6; 1 nodes are at revision 7와 같은 여러 버전 번호가 표시되면 이는 업데이트가 아직 진행 중임을 의미합니다. 몇 분 기다린 후 다시 시도합니다.

23. 다음을 실행하여 플랫폼 Operator를 모니터링합니다.

    $ oc adm wait-for-stable-cluster

    이 프로세스는 최대 15분이 걸릴 수 있습니다.

24. 모든 컨트롤 플레인 호스트가 클러스터를 시작하여 참여하고 있는지 확인합니다.

    클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다.

    $ oc -n openshift-etcd get pods -l k8s-app=etcd

    출력 예

    etcd-ip-10-0-143-125.ec2.internal                2/2     Running     0          9h
    etcd-ip-10-0-154-194.ec2.internal                2/2     Running     0          9h
    etcd-ip-10-0-173-171.ec2.internal                2/2     Running     0          9h

1. 다음과 같은 오브젝트 정의를 사용하여 YAML 파일을 만듭니다.

   apiVersion: policy/v1 1
   kind: PodDisruptionBudget
   metadata:
     name: my-pdb
   spec:
     minAvailable: 2  2
     selector:  3
       matchLabels:
         name: my-pod

   1

   PodDisruptionBudget 은 policy/v1 API 그룹의 일부입니다.

   2

   동시에 사용할 수 필요가 있는 최소 pod 수 입니다. 정수 또는 백분율 (예: 20 %)을 지정하는 문자열을 사용할 수 있습니다.

   3

   리소스 집합에 대한 라벨 쿼리입니다. matchLabels 및 matchExpressions의 결과는 논리적으로 결합됩니다. 프로젝트의 모든 포드를 선택하려면 이 매개변수(예: selector {} )를 비워 둡니다.

   또는 다음을 수행합니다.

   apiVersion: policy/v1 1
   kind: PodDisruptionBudget
   metadata:
     name: my-pdb
   spec:
     maxUnavailable: 25% 2
     selector: 3
       matchLabels:
         name: my-pod

   1

   PodDisruptionBudget 은 policy/v1 API 그룹의 일부입니다.

   2

   동시에 사용할 수없는 최대 pod 수입니다. 정수 또는 백분율 (예: 20 %)을 지정하는 문자열을 사용할 수 있습니다.

   3

   리소스 집합에 대한 라벨 쿼리입니다. matchLabels 및 matchExpressions의 결과는 논리적으로 결합됩니다. 프로젝트의 모든 포드를 선택하려면 이 매개변수(예: selector {} )를 비워 둡니다.

2. 다음 명령을 실행하여 오브젝트를 프로젝트에 추가합니다.

   $ oc create -f </path/to/file> -n <project_name>

프로세스

1. PodDisruptionBudget 오브젝트를 정의하는 YAML 파일을 생성하고 비정상 Pod 제거 정책을 지정합니다.

   pod-disruption-budget.yaml 파일의 예

   apiVersion: policy/v1
   kind: PodDisruptionBudget
   metadata:
     name: my-pdb
   spec:
     minAvailable: 2
     selector:
       matchLabels:
         name: my-pod
     unhealthyPodEvictionPolicy: AlwaysAllow 1

   1

   비정상 Pod 제거 정책으로 IfHealthyBudget 또는 AlwaysAllow 중 하나를 선택합니다. unhealthyPodEvictionPolicy 필드가 비어 있는 경우 기본값은 IfHealthyBudget 입니다.

2. 다음 명령을 실행하여 PodDisruptionBudget 오브젝트를 생성합니다.

   $ oc create -f pod-disruption-budget.yaml

프로세스

1. 클러스터의 kubeconfig 파일과 클러스터를 설치하는 데 사용한 설치 프로그램이 RHEL 8 시스템에 있는지 확인합니다. 이를 수행하는 한 가지 방법으로 클러스터 설치에 사용된 머신과 동일한 머신을 사용하는 것입니다.
2. 컴퓨팅 머신으로 사용하려는 모든 RHEL 호스트에 액세스하도록 머신을 구성합니다. SSH 프록시 또는 VPN을 사용하는 Bastion를 포함하여 회사에서 허용하는 모든 방법을 사용할 수 있습니다.

3. Playbook을 실행하는 머신에서 모든 RHEL 호스트에 대한 SSH 액세스 권한이있는 사용자를 구성하십시오.

   중요

   SSH 키 기반 인증을 사용하는 경우 SSH 에이전트를 사용하여 키를 관리해야합니다.

4. 아직 등록하지 않은 경우 RHSM으로 머신을 등록하고 OpenShift 서브스크립션이 있는 풀을 머신에 연결합니다.

   1. RHSM으로 머신를 등록합니다.

      # subscription-manager register --username=<user_name> --password=<password>

   2. RHSM에서 최신 서브스크립션 데이터를 가져옵니다.

      # subscription-manager refresh

   3. 사용 가능한 서브스크립션을 나열하십시오.

      # subscription-manager list --available --matches '*OpenShift*'

   4. 이전 명령의 출력에서 OpenShift Container Platform 서브스크립션의 풀 ID를 찾아서 이를 연결합니다.

      # subscription-manager attach --pool=<pool_id>

5. OpenShift Container Platform 4.17에 필요한 리포지토리를 활성화합니다.

   # subscription-manager repos \
       --enable="rhel-8-for-x86_64-baseos-rpms" \
       --enable="rhel-8-for-x86_64-appstream-rpms" \
       --enable="rhocp-4.17-for-rhel-8-x86_64-rpms"

6. openshift-ansible을 포함한 필수 패키지를 설치합니다.

   # yum install openshift-ansible openshift-clients jq

   openshift-ansible 패키지는 설치 프로그램 유틸리티를 제공하고 Ansible, Playbook 및 관련 구성 파일과 같이 RHEL 컴퓨팅 노드를 클러스터에 추가하는데 필요한 다른 패키지를 가져옵니다. openshift-clients는 oc CLI를 제공하고 jq 패키지는 명령 행에서 JSON 출력 표시 방법을 개선할 수 있습니다.

1. 각 호스트에서 RHSM으로 동륵합니다.

   # subscription-manager register --username=<user_name> --password=<password>

2. RHSM에서 최신 서브스크립션 데이터를 가져옵니다.

   # subscription-manager refresh

3. 사용 가능한 서브스크립션을 나열하십시오.

   # subscription-manager list --available --matches '*OpenShift*'

4. 이전 명령의 출력에서 OpenShift Container Platform 서브스크립션의 풀 ID를 찾아서 이를 연결합니다.

   # subscription-manager attach --pool=<pool_id>

5. 모든 yum 저장소를 비활성화합니다.

   1. 활성화된 모든 RHSM 저장소를 비활성화합니다.

      # subscription-manager repos --disable="*"

   2. 나머지 yum 저장소를 나열하고 repo id 아래에 해당 이름을 적어 둡니다.

      # yum repolist

   3. yum-config-manager를 사용하여 나머지 yum 리포지토리를 비활성화합니다.

      # yum-config-manager --disable <repo_id>

      또는 모든 리포지토리를 비활성화합니다.

      # yum-config-manager --disable \*

      사용 가능한 리포지토리가 많으면 몇 분의 시간이 소요될 수 있습니다.

6. OpenShift Container Platform 4.17에 필요한 리포지토리를 활성화합니다.

   # subscription-manager repos \
       --enable="rhel-8-for-x86_64-baseos-rpms" \
       --enable="rhel-8-for-x86_64-appstream-rpms" \
       --enable="rhocp-4.17-for-rhel-8-x86_64-rpms" \
       --enable="fast-datapath-for-rhel-8-x86_64-rpms"

7. 호스트에서 firewalld를 중지하고 비활성화합니다.

   # systemctl disable --now firewalld.service

   참고

   나중에 firewalld를 활성화할 수 없습니다. 활성화하면 작업자의 OpenShift Container Platform 로그에 액세스할 수 없습니다.