7.2. OpenShift Container Platform 클러스터에 RHCOS 컴퓨팅 머신 추가

절차

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

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

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

   참고

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

3. 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

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

   중요

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

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

프로세스

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만 지원합니다.

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

프로세스

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

   $ oc get nodes

   출력 예

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

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

   참고

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

   참고

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

절차

1. 명령줄에서 openshift-machine-api 네임스페이스로 변경합니다.

   $ oc project openshift-machine-api

2. worker-user-data 시크릿에서 새 시크릿을 생성합니다.

   1. 시크릿의 userData 섹션을 텍스트 파일에 내보냅니다.

      $ oc get secret worker-user-data --template='{{index .data.userData | base64decode}}' | jq > userData.txt

   2. 텍스트 파일을 편집하여 새 노드에 사용하려는 파티션의 스토리지,파일 시스템, systemd 스탠자를 추가합니다. 필요에 따라 Ignition 구성 매개변수를 지정할 수 있습니다.

      참고

      ignition 스탠자의 값을 변경하지 마십시오.

      {
        "ignition": {
          "config": {
            "merge": [
              {
                "source": "https:...."
              }
            ]
          },
          "security": {
            "tls": {
              "certificateAuthorities": [
                {
                  "source": "data:text/plain;charset=utf-8;base64,.....=="
                }
              ]
            }
          },
          "version": "3.2.0"
        },
        "storage": {
          "disks": [
            {
              "device": "/dev/nvme1n1", 1
              "partitions": [
                {
                  "label": "var",
                  "sizeMiB": 50000, 2
                  "startMiB": 0 3
                }
              ]
            }
          ],
          "filesystems": [
            {
              "device": "/dev/disk/by-partlabel/var", 4
              "format": "xfs", 5
              "path": "/var" 6
            }
          ]
        },
        "systemd": {
          "units": [ 7
            {
              "contents": "[Unit]\nBefore=local-fs.target\n[Mount]\nWhere=/var\nWhat=/dev/disk/by-partlabel/var\nOptions=defaults,pquota\n[Install]\nWantedBy=local-fs.target\n",
              "enabled": true,
              "name": "var.mount"
            }
          ]
        }
      }

      1

      AWS 블록 장치의 절대 경로를 지정합니다.

      2

      데이터 파티션의 크기를 Mebibytes로 지정합니다.

      3

      파티션의 시작을 Mebibytes로 지정합니다. 데이터 파티션을 부트 디스크에 추가할 때 최소 25000MB(메비 바이트)가 권장됩니다. 루트 파일 시스템은 지정된 오프셋까지 사용 가능한 모든 공간을 채우기 위해 자동으로 크기가 조정됩니다. 값이 지정되지 않거나 지정된 값이 권장 최소값보다 작으면 생성되는 루트 파일 시스템의 크기가 너무 작아지고 RHCOS를 나중에 다시 설치할 때 데이터 파티션의 첫 번째 부분을 덮어 쓸 수 있습니다.

      4

      /var 파티션의 절대 경로를 지정합니다.

      5

      파일 시스템 형식을 지정합니다.

      6

      루트 파일 시스템이 마운트되는 위치와 관련하여 Ignition이 실행되는 동안 파일 시스템의 마운트 지점을 지정합니다. 이것은 실제 루트에서 마운트해야하는 위치와 반드시 동일하지는 않지만 동일하게 만드는 것이 좋습니다.

      7

      /dev/disk/by-partlabel/var 장치를 /var 파티션에 마운트하는 systemd 마운트 장치를 정의합니다.

   3. work-user-data 시크릿에서 disableTemplating 섹션을 텍스트 파일로 추출합니다.

      $ oc get secret worker-user-data --template='{{index .data.disableTemplating | base64decode}}' | jq > disableTemplating.txt

   4. 두 텍스트 파일에서 새 사용자 데이터 시크릿 파일을 생성합니다. 이 사용자 데이터 시크릿은 userData.txt 파일의 추가 노드 파티션 정보를 새로 생성된 노드에 전달합니다.

      $ oc create secret generic worker-user-data-x5 --from-file=userData=userData.txt --from-file=disableTemplating=disableTemplating.txt

3. 새 노드에 대한 새 머신 세트를 생성합니다.

   1. AWS에 구성된 다음과 유사한 새 머신 세트 YAML 파일을 생성합니다. 필요한 파티션과 새로 생성된 사용자 데이터 시크릿을 추가합니다.

      작은 정보

      기존 머신 세트를 템플릿으로 사용하고 필요에 따라 새 노드에 대해 매개 변수를 변경합니다.

      apiVersion: machine.openshift.io/v1beta1
      kind: MachineSet
      metadata:
        labels:
          machine.openshift.io/cluster-api-cluster: auto-52-92tf4
        name: worker-us-east-2-nvme1n1 1
        namespace: openshift-machine-api
      spec:
        replicas: 1
        selector:
          matchLabels:
            machine.openshift.io/cluster-api-cluster: auto-52-92tf4
            machine.openshift.io/cluster-api-machineset: auto-52-92tf4-worker-us-east-2b
        template:
          metadata:
            labels:
              machine.openshift.io/cluster-api-cluster: auto-52-92tf4
              machine.openshift.io/cluster-api-machine-role: worker
              machine.openshift.io/cluster-api-machine-type: worker
              machine.openshift.io/cluster-api-machineset: auto-52-92tf4-worker-us-east-2b
          spec:
            metadata: {}
            providerSpec:
              value:
                ami:
                  id: ami-0c2dbd95931a
                apiVersion: awsproviderconfig.openshift.io/v1beta1
                blockDevices:
                - DeviceName: /dev/nvme1n1 2
                  ebs:
                    encrypted: true
                    iops: 0
                    volumeSize: 120
                    volumeType: gp2
                - DeviceName: /dev/nvme1n2 3
                  ebs:
                    encrypted: true
                    iops: 0
                    volumeSize: 50
                    volumeType: gp2
                credentialsSecret:
                  name: aws-cloud-credentials
                deviceIndex: 0
                iamInstanceProfile:
                  id: auto-52-92tf4-worker-profile
                instanceType: m6i.large
                kind: AWSMachineProviderConfig
                metadata:
                  creationTimestamp: null
                placement:
                  availabilityZone: us-east-2b
                  region: us-east-2
                securityGroups:
                - filters:
                  - name: tag:Name
                    values:
                    - auto-52-92tf4-worker-sg
                subnet:
                  id: subnet-07a90e5db1
                tags:
                - name: kubernetes.io/cluster/auto-52-92tf4
                  value: owned
                userDataSecret:
                  name: worker-user-data-x5 4

      1

      새 노드의 이름을 지정합니다.

      2

      AWS 블록 장치의 절대 경로를 지정합니다. 여기에는 암호화된 EBS 볼륨이 있습니다.

      3

      선택 사항: 추가 EBS 볼륨을 지정합니다.

      4

      사용자 데이터 시크릿 파일을 지정합니다.

   2. 머신 세트를 생성합니다.

      $ oc create -f <file-name>.yaml

      머신을 사용할 수 있는 데 다소 시간이 걸릴 수 있습니다.

4. 새 파티션과 노드가 생성되었는지 확인합니다.

   1. 머신 세트가 생성되었는지 확인합니다.

      $ oc get machineset

      출력 예

      NAME                                               DESIRED   CURRENT   READY   AVAILABLE   AGE
      ci-ln-2675bt2-76ef8-bdgsc-worker-us-east-1a        1         1         1       1           124m
      ci-ln-2675bt2-76ef8-bdgsc-worker-us-east-1b        2         2         2       2           124m
      worker-us-east-2-nvme1n1                           1         1         1       1           2m35s 1

      1

      이것은 새로운 머신 세트입니다.

   2. 새 노드가 생성되었는지 확인합니다.

      $ oc get nodes

      출력 예

      NAME                           STATUS   ROLES    AGE     VERSION
      ip-10-0-128-78.ec2.internal    Ready    worker   117m    v1.24.0+60f5a1c
      ip-10-0-146-113.ec2.internal   Ready    master   127m    v1.24.0+60f5a1c
      ip-10-0-153-35.ec2.internal    Ready    worker   118m    v1.24.0+60f5a1c
      ip-10-0-176-58.ec2.internal    Ready    master   126m    v1.24.0+60f5a1c
      ip-10-0-217-135.ec2.internal   Ready    worker   2m57s   v1.24.0+60f5a1c 1
      ip-10-0-225-248.ec2.internal   Ready    master   127m    v1.24.0+60f5a1c
      ip-10-0-245-59.ec2.internal    Ready    worker   116m    v1.24.0+60f5a1c

      1

      이것은 새로운 노드입니다.

   3. 새 노드에 사용자 지정 /var 파티션이 생성되었는지 확인합니다.

      $ oc debug node/<node-name> -- chroot /host lsblk

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

      $ oc debug node/ip-10-0-217-135.ec2.internal -- chroot /host lsblk

      출력 예

      NAME        MAJ:MIN  RM  SIZE RO TYPE MOUNTPOINT
      nvme0n1     202:0    0   120G  0 disk
      |-nvme0n1p1 202:1    0     1M  0 part
      |-nvme0n1p2 202:2    0   127M  0 part
      |-nvme0n1p3 202:3    0   384M  0 part /boot
      `-nvme0n1p4 202:4    0 119.5G  0 part /sysroot
      nvme1n1     202:16   0    50G  0 disk
      `-nvme1n1p1 202:17   0  48.8G  0 part /var 1

      1

      nvme1n1 장치가 /var 파티션에 마운트됩니다.