15.6. 사용자 인프라의 Kuryr로 OpenStack에 클러스터 설치

프로세스

1. 명령줄에서 리포지토리를 추가합니다.

   1. Red Hat Subscription Manager에 등록합니다.

      $ sudo subscription-manager register # If not done already

   2. 최신 서브스크립션 데이터를 가져옵니다.

      $ sudo subscription-manager attach --pool=$YOUR_POOLID # If not done already

   3. 현재 리포지토리를 비활성화합니다.

      $ sudo subscription-manager repos --disable=* # If not done already

   4. 필요한 리포지토리를 추가합니다.

      $ sudo subscription-manager repos \
        --enable=rhel-8-for-x86_64-baseos-rpms \
        --enable=openstack-16-tools-for-rhel-8-x86_64-rpms \
        --enable=ansible-2.9-for-rhel-8-x86_64-rpms \
        --enable=rhel-8-for-x86_64-appstream-rpms

2. 모듈을 설치합니다.

   $ sudo yum install python3-openstackclient ansible python3-openstacksdk python3-netaddr

3. python 명령이 python3를 가리키는지 확인합니다.

   $ sudo alternatives --set python /usr/bin/python3

프로세스

1. OpenShift Cluster Manager 사이트의 인프라 공급자 페이지에 액세스합니다. Red Hat 계정이 있으면 사용자 자격 증명으로 로그인합니다. 계정이 없으면 계정을 만드십시오.
2. 인프라 공급자를 선택합니다.

3. 설치 유형 페이지로 이동한 다음, 운영 체제에 맞는 설치 프로그램을 다운로드하여 설치 구성 파일을 저장할 디렉터리에 파일을 저장합니다.

   중요

   설치 프로그램은 클러스터를 설치하는 데 사용하는 컴퓨터에 여러 파일을 만듭니다. 클러스터 설치를 마친 후 설치 프로그램과 설치 프로그램으로 생성되는 파일을 보관해야 합니다. 클러스터를 삭제하려면 두 파일이 모두 필요합니다.

   중요

   클러스터 설치에 실패하거나 설치 프로그램으로 만든 파일을 삭제해도 클러스터는 제거되지 않습니다. 클러스터를 제거하려면 해당 클라우드 공급자에 적용되는 OpenShift Container Platform 설치 제거 절차를 완료해야 합니다.

4. 설치 프로그램 파일의 압축을 풉니다. 예를 들어 Linux 운영 체제를 사용하는 컴퓨터에서 다음 명령을 실행합니다.

   $ tar -xvf openshift-install-linux.tar.gz

5. Red Hat OpenShift Cluster Manager에서 설치 풀 시크릿 을 다운로드합니다. 이 풀 시크릿을 사용하면 OpenShift Container Platform 구성 요소에 대한 컨테이너 이미지를 제공하는 Quay.io를 포함하여 인증 기관에서 제공하는 서비스로 인증할 수 있습니다.

프로세스

1. 로컬 시스템에 클러스터 노드의 인증에 사용할 기존 SSH 키 쌍이 없는 경우 새로 생성합니다. 예를 들어 Linux 운영 체제를 사용하는 컴퓨터에서 다음 명령을 실행합니다.

   $ ssh-keygen -t ed25519 -N '' -f <path>/<file_name> 1

   1

   새 SSH 키의 경로 및 파일 이름(예: ~/.ssh/id_ed25519 )을 지정합니다. 기존 키 쌍이 있는 경우 공개 키가 '~/.ssh 디렉터리에 있는지 확인하십시오.

   참고

   x86_64 아키텍처에 FIPS 검증 / 진행중인 모듈 (Modules in Process) 암호화 라이브러리를 사용하는 OpenShift Container Platform 클러스터를 설치하려면 ed25519 알고리즘을 사용하는 키를 생성하지 마십시오. 대신 rsa 또는 ecdsa 알고리즘을 사용하는 키를 생성합니다.

2. 공개 SSH 키를 확인합니다.

   $ cat <path>/<file_name>.pub

   예를 들어 다음을 실행하여 ~/.ssh/id_ed25519.pub 공개 키를 확인합니다.

   $ cat ~/.ssh/id_ed25519.pub

3. 아직 추가되지 않은 경우 로컬 사용자의 SSH 에이전트에 SSH 개인 키 ID를 추가합니다. 키의 SSH 에이전트 관리는 클러스터 노드에 암호 없는 SSH 인증을 수행하거나 ./openshift-install gather 명령을 사용하려는 경우 필요합니다.

   참고

   일부 배포에서는 ~/.ssh/id_rsa 및 ~/.ssh/id_dsa와 같은 기본 SSH 개인 키 ID가 자동으로 관리됩니다.

   1. ssh-agent 프로세스가 로컬 사용자에 대해 실행되지 않은 경우 백그라운드 작업으로 시작합니다.

      $ eval "$(ssh-agent -s)"

      출력 예

      Agent pid 31874

      참고

      클러스터가 FIPS 모드인 경우 FIPS 호환 알고리즘만 사용하여 SSH 키를 생성합니다. 키는 RSA 또는 ECDSA여야 합니다.

4. ssh-agent에 SSH 개인 키를 추가합니다.

   $ ssh-add <path>/<file_name> 1

   1

   SSH 개인 키의 경로 및 파일 이름을 지정합니다(예: ~/.ssh/id_ed25519).

   출력 예

   Identity added: /home/<you>/<path>/<file_name> (<computer_name>)

프로세스

1. Red Hat Customer Portal의 제품 다운로드 페이지에 로그인합니다.

2. Version 에서 Red Hat Enterprise Linux (RHEL) 8용 최신 OpenShift Container Platform 4.9 릴리스를 선택합니다.

   중요

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

3. RHCOS(Red Hat Enterprise Linux CoreOS) - OpenStack Image (QCOW)를 다운로드합니다.

4. 이미지 압축을 풉니다.

   참고

   RHOSP 이미지 압축을 풀어야 클러스터가 사용할 수 있습니다. 다운로드한 파일의 이름에 .gz 또는 .tgz와 같은 압축 확장자가 포함되지 않을 수 있습니다. 파일 압축 여부를 확인하려면 명령줄에서 다음을 입력합니다.

   $ file <name_of_downloaded_file>

5. 다운로드한 이미지에서 RHOSP CLI를 사용하여 이름이 rhcos인 이미지를 클러스터에 생성합니다.

   $ openstack image create --container-format=bare --disk-format=qcow2 --file rhcos-${RHCOS_VERSION}-openstack.qcow2 rhcos

   중요

   RHOSP 환경에 따라 이미지를 .raw 또는 .qcow2 형식으로 업로드할 수 있습니다. Ceph를 사용하는 경우 .raw 형식을 사용해야 합니다.

   주의

   설치 프로그램이 이름이 같은 여러 이미지를 발견하면 그 중 하나를 임의로 선택합니다. 이 동작을 방지하려면 RHOSP에서 리소스의 고유한 이름을 만듭니다.

프로세스

1. RHOSP CLI를 사용하여 '외부' 네트워크의 이름과 ID를 확인합니다.

   $ openstack network list --long -c ID -c Name -c "Router Type"

   출력 예

   +--------------------------------------+----------------+-------------+
   | ID                                   | Name           | Router Type |
   +--------------------------------------+----------------+-------------+
   | 148a8023-62a7-4672-b018-003462f8d7dc | public_network | External    |
   +--------------------------------------+----------------+-------------+

프로세스

1. clouds.yaml 파일을 만듭니다.

   • RHOSP 배포에 Horizon 웹 UI가 포함되어 있으면 그 안에 clouds.yaml 파일을 만듭니다.

     중요

     auth 필드에 암호를 추가해야 합니다. clouds.yaml과 별도의 파일에 비밀을 저장할 수도 있습니다.

   • RHOSP 배포에 Horizon 웹 UI가 포함되어 있지 않거나 Horizon을 사용하지 않으려면 파일을 직접 만듭니다. clouds.yaml에 대한 자세한 내용은 RHOSP 문서의 구성 파일을 참조하십시오.

     clouds:
       shiftstack:
         auth:
           auth_url: http://10.10.14.42:5000/v3
           project_name: shiftstack
           username: shiftstack_user
           password: XXX
           user_domain_name: Default
           project_domain_name: Default
       dev-env:
         region_name: RegionOne
         auth:
           username: 'devuser'
           password: XXX
           project_name: 'devonly'
           auth_url: 'https://10.10.14.22:5001/v2.0'

2. RHOSP 설치에서 끝점 인증을 위해 자체 서명된 CA(인증 기관) 인증서를 사용하는 경우:

   1. 인증 기관 파일을 시스템에 복사합니다.

   2. cacerts 키를 clouds.yaml 파일에 추가합니다. 값은 CA 인증서에 대한 루트가 아닌 액세스 가능한 절대 경로여야 합니다.

      clouds:
        shiftstack:
          ...
          cacert: "/etc/pki/ca-trust/source/anchors/ca.crt.pem"

      작은 정보

      사용자 지정 CA 인증서로 설치 관리자를 실행한 후 cloud-provider-config 키맵에서 ca-cert.pem 키의 값을 편집하여 인증서를 업데이트할 수 있습니다. 명령줄에서 다음을 실행합니다.

      $ oc edit configmap -n openshift-config cloud-provider-config

3. clouds.yaml 파일을 다음 위치 중 하나에 배치합니다.

   1. OS_CLIENT_CONFIG_FILE 환경 변수의 값
   2. 현재 디렉터리
   3. Unix 전용 사용자 구성 디렉터리(예: ~/.config/openstack/clouds.yaml)

   4. Unix 전용 사이트 구성 디렉터리(예: /etc/openstack/clouds.yaml)

      설치 프로그램은 clouds.yaml을 이 순서대로 검색합니다.

프로세스

1. install-config.yaml 파일을 생성합니다.

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

      $ ./openshift-install create install-config --dir <installation_directory> 1

      1

      <installation_directory>는 설치 프로그램이 생성하는 파일을 저장할 디렉터리 이름을 지정합니다.

      중요

      비어 있는 디렉터리를 지정합니다. 부트스트랩 X.509 인증서와 같은 일부 설치 자산은 단기간에 만료되므로 설치 디렉터리를 재사용해서는 안 됩니다. 다른 클러스터 설치의 개별 파일을 재사용하려면 해당 파일을 사용자 디렉터리에 복사하면 됩니다. 그러나 설치 자산의 파일 이름은 릴리스간에 변경될 수 있습니다. 따라서 이전 OpenShift Container Platform 버전에서 설치 파일을 복사할 때는 주의하십시오.

   2. 화면에 나타나는 지시에 따라 클라우드에 대한 구성 세부 사항을 입력합니다.

      1. 선택사항: 클러스터 시스템에 액세스하는 데 사용할 SSH 키를 선택합니다.

         참고

         설치 디버깅 또는 재해 복구를 수행하려는 프로덕션 OpenShift Container Platform 클러스터의 경우 ssh-agent 프로세스가 사용하는 SSH 키를 지정합니다.

      2. 대상 플랫폼으로 openstack을 선택합니다.
      3. 클러스터 설치에 사용할 RHOSP(Red Hat OpenStack Platform) 외부 네트워크 이름을 지정합니다.
      4. OpenShift API에 대한 외부 액세스에 사용할 부동 IP 주소를 지정합니다.
      5. 컨트롤 플레인 노드에 사용할 최소 16GB의 RAM과 컴퓨팅 노드에 8GB RAM이 있는 RHOSP 플레이버를 지정합니다.
      6. 클러스터를 배포할 기본 도메인을 선택합니다. 모든 DNS 레코드는 이 기본 도메인의 하위 도메인이 되므로 클러스터 이름을 포함합니다.
      7. 클러스터 이름을 입력합니다. 이름은 14자 이하여야 합니다.
      8. Red Hat OpenShift Cluster Manager에서 풀 시크릿 을 붙여넣습니다.
2. install-config.yaml 파일을 수정합니다. 사용 가능한 매개변수에 대한 자세한 정보는 “설치 구성 매개변수” 섹션에서 확인할 수 있습니다.

3. 여러 클러스터를 설치하는 데 사용할 수 있도록 install-config.yaml 파일을 백업합니다.

   중요

   install-config.yaml 파일은 설치 과정에서 사용됩니다. 이 파일을 재사용하려면 지금 백업해야 합니다.

절차

1. OpenShift Container Platform 설치 프로그램이 포함된 디렉터리로 변경하고 클러스터에 대한 Kubernetes 매니페스트를 생성합니다.

   $ ./openshift-install create manifests --dir <installation_directory> 1

   1

   <installation_directory>는 사용자가 만든 install-config.yaml 파일이 포함된 설치 디렉터리를 지정합니다.

2. 컨트롤 플레인 시스템 및 컴퓨팅 머신 세트를 정의하는 Kubernetes 매니페스트 파일을 제거합니다.

   $ rm -f openshift/99_openshift-cluster-api_master-machines-*.yaml openshift/99_openshift-cluster-api_worker-machineset-*.yaml

   이러한 리소스는 사용자가 직접 생성하고 관리하기 때문에 초기화할 필요가 없습니다.

   • 시스템 API로 머신 세트 파일을 보존하여 컴퓨팅 시스템을 생성할 수 있지만 사용자 환경과 일치하도록 해당 참조를 업데이트해야 합니다.

3. <installation_directory>/manifests/cluster-scheduler-02-config.yml Kubernetes 매니페스트 파일의 mastersSchedulable 매개변수가 false로 설정되어 있는지 확인합니다. 이 설정으로 인해 컨트롤 플레인 머신에서 포드가 예약되지 않습니다.

   1. <installation_directory>/manifests/cluster-scheduler-02-config.yml 파일을 엽니다.
   2. mastersSchedulable 매개변수를 찾아서 값을 False로 설정되어 있는지 확인합니다.
   3. 파일을 저장하고 종료합니다.

4. Ignition 구성 파일을 생성하려면 설치 프로그램이 포함된 디렉터리에서 다음 명령을 실행합니다.

   $ ./openshift-install create ignition-configs --dir <installation_directory> 1

   1

   <installation_directory>는 동일한 설치 디렉터리를 지정합니다.

   설치 디렉터리의 부트스트랩, 컨트롤 플레인 및 컴퓨팅 노드에 대한 Ignition 구성 파일이 생성됩니다. kubeadmin-password 및 kubeconfig 파일은 ./<installation_directory>/auth 디렉터리에 생성됩니다.

   .
   ├── auth
   │   ├── kubeadmin-password
   │   └── kubeconfig
   ├── bootstrap.ign
   ├── master.ign
   ├── metadata.json
   └── worker.ign

5. 메타데이터 파일의 infraID 키를 환경 변수로 내보냅니다.

   $ export INFRA_ID=$(jq -r .infraID metadata.json)

프로세스

1. 다음 Python 스크립트를 실행합니다. 이 스크립트는 부트스트랩 Ignition 파일을 수정하여 호스트 이름 및 사용 가능한 경우 실행 시 CA 인증서 파일을 설정합니다.

   import base64
   import json
   import os
   
   with open('bootstrap.ign', 'r') as f:
       ignition = json.load(f)
   
   files = ignition['storage'].get('files', [])
   
   infra_id = os.environ.get('INFRA_ID', 'openshift').encode()
   hostname_b64 = base64.standard_b64encode(infra_id + b'-bootstrap\n').decode().strip()
   files.append(
   {
       'path': '/etc/hostname',
       'mode': 420,
       'contents': {
           'source': 'data:text/plain;charset=utf-8;base64,' + hostname_b64
       }
   })
   
   ca_cert_path = os.environ.get('OS_CACERT', '')
   if ca_cert_path:
       with open(ca_cert_path, 'r') as f:
           ca_cert = f.read().encode()
           ca_cert_b64 = base64.standard_b64encode(ca_cert).decode().strip()
   
       files.append(
       {
           'path': '/opt/openshift/tls/cloud-ca-cert.pem',
           'mode': 420,
           'contents': {
               'source': 'data:text/plain;charset=utf-8;base64,' + ca_cert_b64
           }
       })
   
   ignition['storage']['files'] = files;
   
   with open('bootstrap.ign', 'w') as f:
       json.dump(ignition, f)

2. RHOSP CLI를 사용하여 부트스트랩 Ignition 파일을 사용하는 이미지를 생성합니다.

   $ openstack image create --disk-format=raw --container-format=bare --file bootstrap.ign <image_name>

3. 이미지의 세부 사항을 가져옵니다.

   $ openstack image show <image_name>

   file 값을 기록해 둡니다. 해당 패턴은 v2/images/<image_ID>/file입니다.

   참고

   생성된 이미지가 활성화되어 있는지 확인합니다.

4. 이미지 서비스의 공용 주소를 검색합니다.

   $ openstack catalog show image

5. 공용 주소를 이미지 file 값과 결합하고 그 결과를 저장 위치로 저장합니다. 위치 패턴은 <image_service_public_URL>/v2/images/<image_ID>/file입니다.

6. 인증 토큰을 생성하고 토큰 ID를 저장합니다.

   $ openstack token issue -c id -f value

7. $INFRA_ID-bootstrap-ignition.json 파일에 다음 내용을 삽입하고 사용자 값과 일치하도록 자리 표시자를 편집합니다.

   {
     "ignition": {
       "config": {
         "merge": [{
           "source": "<storage_url>", 1
           "httpHeaders": [{
             "name": "X-Auth-Token", 2
             "value": "<token_ID>" 3
           }]
         }]
       },
       "security": {
         "tls": {
           "certificateAuthorities": [{
             "source": "data:text/plain;charset=utf-8;base64,<base64_encoded_certificate>" 4
           }]
         }
       },
       "version": "3.2.0"
     }
   }

   1

   ignition.config.merge.source 값을 부트스트랩 Ignition 파일 스토리지 URL로 바꿉니다.

   2

   httpHeaders의 name을 "X-Auth-Token"으로 설정합니다.

   3

   httpHeaders의 value를 토큰의 ID로 설정합니다.

   4

   부트스트랩 Ignition 파일 서버가 자체 서명 인증서를 사용하는 경우 base64 인코딩 인증서를 포함합니다.

8. 보조 Ignition 구성 파일을 저장합니다.

프로세스

1. 선택사항: inventory.yaml 플레이북에 외부 네트워크값을 추가합니다.

   inventory.yaml Ansible 플레이북의 외부 네트워크 값 예

   ...
         # The public network providing connectivity to the cluster. If not
         # provided, the cluster external connectivity must be provided in another
         # way.
   
         # Required for os_api_fip, os_ingress_fip, os_bootstrap_fip.
         os_external_network: 'external'
   ...

   중요

   inventory.yaml 파일에 os_external_network 값을 지정하지 않은 경우 VM이 Glance 및 외부 연결에 직접 액세스할 수 있는지 확인해야 합니다.

2. 선택사항: 외부 네트워크 및 부동 IP(FIP) 주소값을 inventory.yaml 플레이북에 추가합니다.

   inventory.yaml Ansible 플레이북의 FIP 값 예

   ...
         # OpenShift API floating IP address. If this value is non-empty, the
         # corresponding floating IP will be attached to the Control Plane to
         # serve the OpenShift API.
         os_api_fip: '203.0.113.23'
   
         # OpenShift Ingress floating IP address. If this value is non-empty, the
         # corresponding floating IP will be attached to the worker nodes to serve
         # the applications.
         os_ingress_fip: '203.0.113.19'
   
         # If this value is non-empty, the corresponding floating IP will be
         # attached to the bootstrap machine. This is needed for collecting logs
         # in case of install failure.
         os_bootstrap_fip: '203.0.113.20'

   중요

   os_api_fip 및 os_ingress_fip에 대한 값을 정의하지 않으면 설치 후 네트워크 구성을 수행해야 합니다.

   os_bootstrap_fip의 값을 정의하지 않으면 설치 프로그램이 실패한 설치에서 디버깅 정보를 다운로드할 수 없습니다.

   자세한 정보는 "환경에 대한 액세스 활성화"를 참조하십시오.

3. 명령줄에서 security-groups.yaml 플레이북을 실행하여 보안 그룹을 생성합니다.

   $ ansible-playbook -i inventory.yaml security-groups.yaml

4. 명령줄에서 network.yaml 플레이북을 실행하여 네트워크, 서브넷 및 라우터를 생성합니다.

   $ ansible-playbook -i inventory.yaml network.yaml

5. 선택사항: Nova 서버가 사용하는 기본 해결 프로그램을 제어하려면 RHOSP CLI 명령을 실행합니다.

   $ openstack subnet set --dns-nameserver <server_1> --dns-nameserver <server_2> "$INFRA_ID-nodes"

프로세스

1. 명령줄에서 작업 디렉터리를 플레이북의 위치로 변경합니다.

2. 명령줄에서 bootstrap.yaml 플레이북을 실행합니다.

   $ ansible-playbook -i inventory.yaml bootstrap.yaml

3. 부트스트랩 서버가 활성화된 후 로그를 보고 Ignition 파일이 수신되었는지 확인합니다.

   $ openstack console log show "$INFRA_ID-bootstrap"

프로세스

1. 명령줄에서 작업 디렉터리를 플레이북의 위치로 변경합니다.
2. 컨트롤 플레인 Ignition 구성 파일이 작업 디렉터리에 없으면 파일을 디렉터리에 복사합니다.

3. 명령줄에서 control-plane.yaml 플레이북을 실행합니다.

   $ ansible-playbook -i inventory.yaml control-plane.yaml

4. 다음 명령을 실행하여 부트스트랩 프로세스를 모니터링합니다.

   $ openshift-install wait-for bootstrap-complete

   컨트롤 플레인 시스템이 실행 중이고 클러스터에 연결되었음을 확인하는 메시지가 표시됩니다.

   INFO API v1.22.1 up
   INFO Waiting up to 30m0s for bootstrapping to complete...
   ...
   INFO It is now safe to remove the bootstrap resources

프로세스

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

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

   1

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

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

   $ oc whoami

   출력 예

   system:admin

프로세스

1. 명령줄에서 작업 디렉터리를 플레이북의 위치로 변경합니다.

2. 명령줄에서 down-bootstrap.yaml 플레이북을 실행합니다.

   $ ansible-playbook -i inventory.yaml down-bootstrap.yaml

프로세스

1. 명령줄에서 작업 디렉터리를 플레이북의 위치로 변경합니다.

2. 명령줄에서 플레이북을 실행합니다.

   $ ansible-playbook -i inventory.yaml compute-nodes.yaml

프로세스

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

   $ oc get nodes

   출력 예

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

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

   참고

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

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

   $ oc get csr

   출력 예

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

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

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

   참고

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

   참고

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

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

     $ oc adm certificate approve <csr_name> 1

     1

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

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

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

     참고

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

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

   $ oc get csr

   출력 예

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

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

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

     $ oc adm certificate approve <csr_name> 1

     1

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

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

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

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

   $ oc get nodes

   출력 예

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

   참고

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