12.2. 사용자 지정으로 OpenStack에 클러스터 설치

1. RHOSP CLI의 관리자로서 Swift에 액세스할 계정에 swiftoperator 역할을 추가하십시오.

   $ openstack role add --user <user> --project <project> swiftoperator

프로세스

1. 사용할 스토리지 클래스 및 가용성 영역을 지정하는 YAML 파일을 생성합니다. 예를 들면 다음과 같습니다.

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: custom-csi-storageclass
   provisioner: cinder.csi.openstack.org
   volumeBindingMode: WaitForFirstConsumer
   allowVolumeExpansion: true
   parameters:
     availability: <availability_zone_name>

   참고

   OpenShift Container Platform은 선택한 가용성 영역이 있는지 확인하지 않습니다. 구성을 적용하기 전에 가용성 영역의 이름을 확인합니다.

2. 명령줄에서 구성을 적용합니다.

   $ oc apply -f <storage_class_file_name>

   출력 예

   storageclass.storage.k8s.io/custom-csi-storageclass created

3. 스토리지 클래스와 openshift-image-registry 네임스페이스를 사용하는 PVC(영구 볼륨 클레임)를 지정하는 YAML 파일을 생성합니다. 예를 들면 다음과 같습니다.

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: csi-pvc-imageregistry
     namespace: openshift-image-registry 1
     annotations:
       imageregistry.openshift.io: "true"
   spec:
     accessModes:
     - ReadWriteOnce
     volumeMode: Filesystem
     resources:
       requests:
         storage: 100Gi 2
     storageClassName: <your_custom_storage_class> 3

   1

   네임스페이스 openshift-image-registry 를 입력합니다. 이 네임스페이스를 사용하면 Cluster Image Registry Operator에서 PVC를 사용할 수 있습니다.

   2

   선택 사항: 볼륨 크기를 조정합니다.

   3

   생성한 스토리지 클래스의 이름을 입력합니다.

4. 명령줄에서 구성을 적용합니다.

   $ oc apply -f <pvc_file_name>

   출력 예

   persistentvolumeclaim/csi-pvc-imageregistry created

5. 이미지 레지스트리 구성의 원래 영구 볼륨 클레임을 새 클레임으로 교체합니다.

   $ oc patch configs.imageregistry.operator.openshift.io/cluster --type 'json' -p='[{"op": "replace", "path": "/spec/storage/pvc/claim", "value": "csi-pvc-imageregistry"}]'

   출력 예

   config.imageregistry.operator.openshift.io/cluster patched

   다음 몇 분 동안 구성이 업데이트됩니다.

1. PVC 클레임 값이 PVC 정의에 제공한 이름과 동일한지 확인합니다.

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

   출력 예

   ...
   status:
       ...
       managementState: Managed
       pvc:
         claim: csi-pvc-imageregistry
   ...

2. PVC의 상태가 Bound 인지 확인합니다.

   $ oc get pvc -n openshift-image-registry csi-pvc-imageregistry

   출력 예

   NAME                   STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS             AGE
   csi-pvc-imageregistry  Bound    pvc-72a8f9c9-f462-11e8-b6b6-fa163e18b7b5   100Gi      RWO            custom-csi-storageclass  11m

프로세스

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. 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. 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. RHOSP 명령줄 인터페이스를 사용하여 컴퓨팅 시스템의 서버 그룹을 생성합니다. 예를 들면 다음과 같습니다.

   $ openstack \
       --os-compute-api-version=2.15 \
       server group create \
       --policy anti-affinity \
       my-openshift-worker-group

   자세한 내용은 서버 그룹 생성 명령 설명서를 참조하십시오.

2. 설치 프로그램이 포함된 디렉터리로 변경하고 매니페스트를 생성합니다.

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

   다음과 같습니다.

   installation_directory

   클러스터의 install-config.yaml 파일이 포함된 디렉토리의 이름을 지정합니다.

3. MachineSet 정의 파일인 manifests/99_openshift-cluster-api_worker-machineset-0.yaml 을 엽니다.

4. spec.template.spec.providerSpec.value 속성 아래에 있는 정의에 속성 serverGroupID 를 추가합니다. 예를 들면 다음과 같습니다.

   apiVersion: machine.openshift.io/v1beta1
   kind: MachineSet
   metadata:
     labels:
       machine.openshift.io/cluster-api-cluster: <infrastructure_ID>
       machine.openshift.io/cluster-api-machine-role: <node_role>
       machine.openshift.io/cluster-api-machine-type: <node_role>
     name: <infrastructure_ID>-<node_role>
     namespace: openshift-machine-api
   spec:
     replicas: <number_of_replicas>
     selector:
       matchLabels:
         machine.openshift.io/cluster-api-cluster: <infrastructure_ID>
         machine.openshift.io/cluster-api-machineset: <infrastructure_ID>-<node_role>
     template:
       metadata:
         labels:
           machine.openshift.io/cluster-api-cluster: <infrastructure_ID>
           machine.openshift.io/cluster-api-machine-role: <node_role>
           machine.openshift.io/cluster-api-machine-type: <node_role>
           machine.openshift.io/cluster-api-machineset: <infrastructure_ID>-<node_role>
       spec:
         providerSpec:
           value:
             apiVersion: openstackproviderconfig.openshift.io/v1alpha1
             cloudName: openstack
             cloudsSecret:
               name: openstack-cloud-credentials
               namespace: openshift-machine-api
             flavor: <nova_flavor>
             image: <glance_image_name_or_location>
             serverGroupID: aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee 1
             kind: OpenstackProviderSpec
             networks:
             - filter: {}
               subnets:
               - filter:
                   name: <subnet_name>
                   tags: openshiftClusterID=<infrastructure_ID>
             securityGroups:
             - filter: {}
               name: <infrastructure_ID>-<node_role>
             serverMetadata:
               Name: <infrastructure_ID>-<node_role>
               openshiftClusterID: <infrastructure_ID>
             tags:
             - openshiftClusterID=<infrastructure_ID>
             trunk: true
             userDataSecret:
               name: <node_role>-user-data
             availabilityZone: <optional_openstack_availability_zone>

   1

   서버 그룹의 UUID를 여기에 추가합니다.

5. 선택 사항: manifests/99_openshift-cluster-api_worker-machineset-0.yaml 파일을 백업합니다. 설치 프로그램은 클러스터를 생성할 때 manifests/ 디렉터리를 삭제합니다.

프로세스

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. 설치 프로그램이 포함된 디렉터리로 변경하고 클러스터 배포를 초기화합니다.

   $ ./openshift-install create cluster --dir <installation_directory> \ 1
       --log-level=info 2

   1

   <installation_directory> 값으로 사용자 지정한 ./install-config.yaml 파일의 위치를 지정합니다.

   2

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

   참고

   호스트에 구성된 클라우드 공급자 계정에 클러스터를 배포하기에 충분한 권한이 없는 경우, 설치 프로세스가 중단되고 누락된 권한을 알리는 메시지가 표시됩니다.

   클러스터 배포가 완료되면 웹 콘솔로 연결되는 링크와 kubeadmin 사용자의 인증 정보가 포함된 클러스터 액세스 지침이 사용자 터미널에 표시됩니다.

   출력 예

   ...
   INFO Install complete!
   INFO To access the cluster as the system:admin user when using 'oc', run 'export KUBECONFIG=/home/myuser/install_dir/auth/kubeconfig'
   INFO Access the OpenShift web-console here: https://console-openshift-console.apps.mycluster.example.com
   INFO Login to the console with user: "kubeadmin", and password: "4vYBz-Ee6gm-ymBZj-Wt5AL"
   INFO Time elapsed: 36m22s

   참고

   설치에 성공하면 클러스터 액세스 및 인증 정보도 <installation_directory>/.openshift_install.log로 출력됩니다.

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

   설치 프로그램에서 생성되는 파일이나 설치 프로그램을 삭제해서는 안 됩니다. 클러스터를 삭제하려면 두 가지가 모두 필요합니다.

프로세스

1. 클러스터 환경에서 관리자의 kubeconfig 파일을 내보냅니다.

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

   1

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

   kubeconfig 파일에는 CLI에서 올바른 클러스터 및 API 서버에 클라이언트를 연결하는 데 사용하는 클러스터에 대한 정보가 포함되어 있습니다.

2. 배포 후 생성된 컨트롤 플레인 및 컴퓨팅 시스템을 확인합니다.

   $ oc get nodes

3. 클러스터 버전을 확인합니다.

   $ oc get clusterversion

4. Operator 상태를 확인합니다.

   $ oc get clusteroperator

5. 클러스터에서 실행 중인 모든 Pod를 확인합니다.

   $ oc get pods -A

프로세스

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

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

   1

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

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

   $ oc whoami

   출력 예

   system:admin