Red Hat Summit Red Hat Summit지원콘솔개발자평가판 시작연락처

설치 후 구성

OpenShift Container Platform 4.16

OpenShift Container Platform의 Day 2 운영

Red Hat OpenShift Documentation Team

초록

이 문서는 OpenShift Container Platform의 설치 후 수행되는 작업에 대한 지침을 제공합니다.

1장. 설치 후 구성 개요
링크 복사

OpenShift Container Platform을 설치한 후 클러스터 관리자는 다음 구성 요소를 구성하고 사용자 지정할 수 있습니다.

  • 머신
  • 베어 메탈
  • Cluster
  • 노드
  • 네트워크
  • 스토리지
  • 사용자
  • 알림 및 알림

1.1. 설치 후 구성 작업
링크 복사

설치 후 구성 작업을 수행하여 요구 사항에 맞게 환경을 구성할 수 있습니다.

다음은 이러한 구성에 대한 세부 정보입니다.

  • 운영 체제 기능 구성: MCO(Machine Config Operator)는 MachineConfig 오브젝트를 관리합니다. MCO를 사용하면 노드 및 사용자 정의 리소스를 구성할 수 있습니다.

  • 베어 메탈 노드 구성: Bare Metal Operator(BMO)를 사용하여 베어 메탈 호스트를 관리할 수 있습니다. BMO는 다음 작업을 완료할 수 있습니다.

    • 호스트의 하드웨어 세부 정보를 검사하고 베어 메탈 호스트에 보고합니다.
    • 펌웨어를 검사하고 BIOS 설정을 구성합니다.
    • 원하는 이미지로 호스트를 프로비저닝합니다.
    • 호스트를 프로비저닝하기 전이나 후에 호스트의 디스크 콘텐츠를 정리합니다.

  • 클러스터 기능을 구성합니다. OpenShift Container Platform 클러스터의 다음 기능을 수정할 수 있습니다.

    • 이미지 레지스트리
    • 네트워킹 구성
    • 이미지 빌드 동작
    • ID 공급자
    • etcd 구성
    • 워크로드를 처리하는 머신 세트 생성
    • 클라우드 공급자 인증 정보 관리

  • 프라이빗 클러스터 구성: 기본적으로 설치 프로그램은 공개적으로 액세스 가능한 DNS 및 끝점을 사용하여 OpenShift Container Platform을 프로비저닝합니다. 내부 네트워크 내에서만 클러스터에 액세스할 수 있도록 하려면 다음 구성 요소를 구성하여 비공개로 설정합니다.

    • DNS
    • Ingress 컨트롤러
    • API 서버

  • 노드 작업 수행: 기본적으로 OpenShift Container Platform은 RHCOS(Red Hat Enterprise Linux CoreOS) 컴퓨팅 머신을 사용합니다. 다음 노드 작업을 수행할 수 있습니다.

    • 컴퓨팅 시스템을 추가하고 제거합니다.
    • 테인트 및 허용 오차를 추가하고 제거합니다.
    • 노드당 최대 Pod 수를 구성합니다.
    • 장치 관리자를 활성화합니다.

  • 사용자 구성: 사용자는 OAuth 액세스 토큰을 사용하여 API에 자신을 인증할 수 있습니다. 다음 작업을 수행하도록 OAuth를 구성할 수 있습니다.

    • ID 공급자를 지정합니다.
    • 역할 기반 액세스 제어를 사용하여 사용자에게 권한을 정의하고 부여합니다.
    • OperatorHub에서 Operator를 설치합니다.
  • 경고 알림 구성: 기본적으로 웹 콘솔의 경고 UI에 실행 경고가 표시됩니다. 외부 시스템에 경고 알림을 보내도록 OpenShift Container Platform을 구성할 수도 있습니다.

2장. 프라이빗 클러스터 설정
링크 복사

OpenShift Container Platform 버전 4.16 클러스터를 설치한 후 일부 핵심 구성 요소를 프라이빗으로 설정할 수 있습니다.

2.1. 프라이빗 클러스터 정보
링크 복사

기본적으로 OpenShift Container Platform은 공개적으로 액세스 가능한 DNS 및 엔드 포인트를 사용하여 프로비저닝됩니다. 프라이빗 클러스터를 배포한 후 DNS, Ingress 컨트롤러 및 API 서버를 프라이빗으로 설정할 수 있습니다.

중요

클러스터에 퍼블릭 서브넷이 있는 경우 관리자가 생성한 로드 밸런서 서비스에 공개적으로 액세스할 수 있습니다. 클러스터 보안을 위해 이러한 서비스에 개인용으로 명시적으로 주석이 추가되었는지 확인합니다.

2.1.1. DNS
링크 복사

설치 프로그램이 프로비저닝한 인프라에 OpenShift Container Platform을 설치하는 경우 설치 프로그램은 기존 퍼블릭 영역에 레코드를 만들고 가능한 경우 클러스터 자체 DNS 확인을 위한 프라이빗 영역을 만듭니다. 퍼블릭 영역과 프라이빗 영역 모두에서 설치 프로그램 또는 클러스터는 API 서버에 대한 * .apps, Ingress 개체, api의 DNS 항목을 만듭니다.

퍼블릭 영역과 프라이빗 영역의 * .apps 레코드는 동일하므로 퍼블릭 영역을 삭제하면 프라이빗 영역이 클러스터에 대한 모든 DNS 확인을 완벽하게 제공합니다.

2.1.2. Ingress 컨트롤러
링크 복사

기본 Ingress 개체는 퍼블릭으로 생성되기 때문에 로드 밸런서는 인터넷에 연결되어 퍼블릭 서브넷에서 사용됩니다.

사용자가 사용자 정의 기본 인증서를 구성할 때까지 Ingress Operator가 자리 표시자로 사용될 Ingress Controller의 기본 인증서를 생성합니다. 프로덕션 클러스터에서는 operator가 생성한 기본 인증서를 사용하지 마십시오. Ingress Operator에서는 자체 서명 인증서 또는 생성된 기본 인증서가 순환되지 않습니다. Operator가 생성한 기본 인증서는 구성하는 사용자 정의 기본 인증서의 자리 표시자로 사용됩니다.

2.1.3. API 서버
링크 복사

기본적으로 설치 프로그램은 API 서버가 내부 트래픽 및 외부 트래픽 모두에 사용할 적절한 네트워크로드 밸런서를 만듭니다.

AWS (Amazon Web Services)에서 별도의 퍼블릭 및 프라이빗 로드 밸런서가 생성됩니다. 클러스터에서 사용하기 위해 내부 포트에서 추가 포트를 사용할 수 있다는 점을 제외하고 로드 밸런서는 동일합니다. 설치 프로그램이 API 서버 요구 사항에 따라 로드 밸런서를 자동으로 생성하거나 제거하더라도 클러스터는 이를 관리하거나 유지하지 않습니다. API 서버에 대한 클러스터의 액세스 권한을 유지하는 한 로드 밸런서를 수동으로 변경하거나 이동할 수 있습니다. 퍼블릭 로드 밸런서의 경우 포트 6443이 열려있고 상태 확인은 HTTPS의 / readyz 경로에 대해 설정되어 있습니다.

Google Cloud에서는 내부 및 외부 API 트래픽을 모두 관리하기 위해 단일 로드 밸런서가 생성되므로 로드 밸런서를 수정할 필요가 없습니다.

Microsoft Azure에서는 퍼블릭 및 프라이빗 로드 밸런서가 모두 생성됩니다. 그러나 현재 구현에 한계가 있기 때문에 프라이빗 클러스터에서 두 로드 밸런서를 유지합니다.

2.2. 프라이빗 영역에 게시할 DNS 레코드 구성
링크 복사

퍼블릭 또는 프라이빗이든 관계없이 모든 OpenShift Container Platform 클러스터의 경우 DNS 레코드는 기본적으로 퍼블릭 영역에 게시됩니다.

퍼블릭 영역을 클러스터 DNS 구성에서 제거하여 DNS 레코드가 공용으로 노출되지 않도록 할 수 있습니다. 내부 도메인 이름, 내부 IP 주소 또는 조직의 클러스터 수와 같은 중요한 정보를 노출하지 않으려거나 단순히 레코드를 공개적으로 게시하지 않아도 될 수 있습니다. 클러스터 내의 서비스에 연결할 수 있는 모든 클라이언트가 프라이빗 영역의 DNS 레코드가 있는 프라이빗 DNS 서비스를 사용하는 경우 클러스터의 퍼블릭 DNS 레코드가 필요하지 않습니다.

클러스터를 배포한 후 DNS CR(사용자 정의 리소스)을 수정하여 프라이빗 영역만 사용하도록 DNS 를 수정할 수 있습니다. 이러한 방식으로 DNS CR을 수정하면 이후에 생성된 모든 DNS 레코드가 퍼블릭 DNS 서버에 게시되지 않으므로 내부 사용자에게 격리된 DNS 레코드에 대한 지식이 유지됩니다. 이 작업은 클러스터를 비공개로 설정하거나 DNS 레코드를 공개적으로 확인할 수 없는 경우 수행할 수 있습니다.

또는 프라이빗 클러스터에서도 클라이언트가 해당 클러스터에서 실행되는 애플리케이션의 DNS 이름을 확인할 수 있으므로 DNS 레코드에 대한 퍼블릭 영역을 유지할 수 있습니다. 예를 들어 조직에는 공용 인터넷에 연결된 머신이 있고 개인 IP 주소에 연결하기 위해 특정 개인 IP 범위에 대한 VPN 연결을 설정할 수 있습니다. 이러한 시스템의 DNS 조회는 퍼블릭 DNS를 사용하여 해당 서비스의 프라이빗 주소를 확인한 다음 VPN을 통해 프라이빗 주소에 연결합니다.

프로세스

  1. 다음 명령을 실행하고 출력을 모니터링하여 클러스터의 DNS CR을 확인합니다. 

    $ oc get dnses.config.openshift.io/cluster -o yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    apiVersion: config.openshift.io/v1
kind: DNS
metadata:
  creationTimestamp: "2019-10-25T18:27:09Z"
  generation: 2
  name: cluster
  resourceVersion: "37966"
  selfLink: /apis/config.openshift.io/v1/dnses/cluster
  uid: 0e714746-f755-11f9-9cb1-02ff55d8f976
spec:
  baseDomain: <base_domain>
  privateZone:
    tags:
      Name: <infrastructure_id>-int
      kubernetes.io/cluster/<infrastructure_id>: owned
  publicZone:
    id: Z2XXXXXXXXXXA4
status: {}
    Copy to Clipboard Toggle word wrap

    spec 섹션에는 프라이빗 영역과 퍼블릭 영역이 모두 포함되어 있습니다.

  2. 다음 명령을 실행하여 DNS CR을 패치하여 퍼블릭 영역을 제거합니다. 

    $ oc patch dnses.config.openshift.io/cluster --type=merge --patch='{"spec": {"publicZone": null}}'
    Copy to Clipboard Toggle word wrap

    출력 예

    dns.config.openshift.io/cluster patched
    Copy to Clipboard Toggle word wrap

    Ingress Operator는 IngressController 오브젝트에 대한 DNS 레코드를 생성할 때 DNS CR 정의를 참조합니다. 프라이빗 영역만 지정하면 개인 레코드만 생성됩니다.

    중요

    퍼블릭 영역을 제거해도 기존 DNS 레코드는 수정되지 않습니다. 더 이상 공개적으로 게시되지 않으려면 이전에 게시된 퍼블릭 DNS 레코드를 수동으로 삭제해야 합니다.

검증

  • 클러스터의 DNS CR을 확인하고 다음 명령을 실행하고 출력을 관찰하여 퍼블릭 영역이 제거되었는지 확인합니다. 

    $ oc get dnses.config.openshift.io/cluster -o yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    apiVersion: config.openshift.io/v1
kind: DNS
metadata:
  creationTimestamp: "2019-10-25T18:27:09Z"
  generation: 2
  name: cluster
  resourceVersion: "37966"
  selfLink: /apis/config.openshift.io/v1/dnses/cluster
  uid: 0e714746-f755-11f9-9cb1-02ff55d8f976
spec:
  baseDomain: <base_domain>
  privateZone:
    tags:
      Name: <infrastructure_id>-int
      kubernetes.io/cluster/<infrastructure_id>-wfpg4: owned
status: {}
    Copy to Clipboard Toggle word wrap

2.3. Ingress 컨트롤러를 프라이빗으로 설정
링크 복사

클러스터를 배포한 후 프라이빗 영역만 사용하도록 Ingress 컨트롤러를 변경할 수 있습니다.

프로세스

  1. 내부 엔드 포인트만 사용하도록 기본 Ingress 컨트롤러를 변경합니다. 

    $ oc replace --force --wait --filename - <<EOF
apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  namespace: openshift-ingress-operator
  name: default
spec:
  endpointPublishingStrategy:
    type: LoadBalancerService
    loadBalancer:
      scope: Internal
EOF
    Copy to Clipboard Toggle word wrap

    출력 예

    ingresscontroller.operator.openshift.io "default" deleted
ingresscontroller.operator.openshift.io/default replaced
    Copy to Clipboard Toggle word wrap

    퍼블릭 DNS 항목이 제거되고 프라이빗 영역 항목이 업데이트됩니다.

2.4. API 서버를 프라이빗으로 제한
링크 복사

AWS (Amazon Web Services) 또는 Microsoft Azure에 클러스터를 배포한 후 프라이빗 영역만 사용하도록 API 서버를 재구성할 수 있습니다.

전제 조건

  • OpenShift CLI (oc)를 설치합니다.
  • admin 권한이 있는 사용자로 웹 콘솔에 액세스합니다.

프로세스

  1. 클라우드 공급자의 웹 포털 또는 콘솔에서 다음 작업을 수행합니다.

    1. 적절한 로드 밸런서 구성 요소를 찾아서 삭제합니다.

      • AWS의 경우 외부 로드 밸런서를 삭제합니다. 프라이빗 영역의 API DNS 항목은 동일한 설정을 사용하는 내부 로드 밸런서를 가리키므로 내부 로드 밸런서를 변경할 필요가 없습니다.
      • Azure의 경우 공용 로드 밸런서의 api-internal-v4 규칙을 삭제합니다.
    2. Azure의 경우 Ingress 컨트롤러 끝점 게시 범위를 Internal. 자세한 내용은 " Ingress 컨트롤러 끝점 게시 범위를 Internal로 구성"에서 참조하십시오.
    3. Azure 공용 로드 밸런서의 경우 Ingress 컨트롤러 끝점 게시 범위를 Internal로 구성하고 공용 로드 밸런서에 기존 인바운드 규칙이 없는 경우 백엔드 주소 풀에 아웃바운드 트래픽을 제공하려면 아웃바운드 규칙을 명시적으로 생성해야 합니다. 자세한 내용은 아웃 바운드 규칙 추가에 대한 Microsoft Azure 설명서를 참조하십시오.
    4. 퍼블릭 영역의 api.$clustername.$yourdomain 또는 api.$clustername DNS 항목을 삭제합니다.

  2. AWS 클러스터: 외부 로드 밸런서를 제거합니다.

    중요

    설치 관리자 프로비저닝 인프라(IPI) 클러스터에 대해서만 다음 단계를 실행할 수 있습니다. UPI(사용자 프로비저닝 인프라) 클러스터의 경우 외부 로드 밸런서를 수동으로 제거하거나 비활성화해야 합니다.

    • 클러스터에서 컨트롤 플레인 머신 세트를 사용하는 경우 컨트롤 플레인 머신 세트 사용자 정의 리소스의 행을 삭제하여 퍼블릭 또는 외부 로드 밸런서를 구성합니다. 

      # ...
providerSpec:
  value:
# ...
    loadBalancers:
    - name: lk4pj-ext
      1 
      
      type: network
      2 
      
    - name: lk4pj-int
      type: network
# ...
      Copy to Clipboard Toggle word wrap
      1
      -ext 로 끝나는 외부 로드 밸런서의 name 값을 삭제합니다.
      2
      외부 로드 밸런서의 유형 값을 삭제합니다.

    • 클러스터에서 컨트롤 플레인 머신 세트를 사용하지 않는 경우 각 컨트롤 플레인 시스템에서 외부 로드 밸런서를 삭제해야 합니다.

      1. 터미널에서 다음 명령을 실행하여 클러스터 시스템을 나열합니다. 

        $ oc get machine -n openshift-machine-api
        Copy to Clipboard Toggle word wrap

        출력 예

        NAME                            STATE     TYPE        REGION      ZONE         AGE
lk4pj-master-0                  running   m4.xlarge   us-east-1   us-east-1a   17m
lk4pj-master-1                  running   m4.xlarge   us-east-1   us-east-1b   17m
lk4pj-master-2                  running   m4.xlarge   us-east-1   us-east-1a   17m
lk4pj-worker-us-east-1a-5fzfj   running   m4.xlarge   us-east-1   us-east-1a   15m
lk4pj-worker-us-east-1a-vbghs   running   m4.xlarge   us-east-1   us-east-1a   15m
lk4pj-worker-us-east-1b-zgpzg   running   m4.xlarge   us-east-1   us-east-1b   15m
        Copy to Clipboard Toggle word wrap

        컨트롤 플레인 시스템에는 이름에 master 가 포함되어 있습니다.

      2. 각 컨트롤 플레인 시스템에서 외부 로드 밸런서를 제거합니다.

        1. 다음 명령을 실행하여 컨트롤 플레인 머신 오브젝트를 다음과 같이 편집합니다. 

          $ oc edit machines -n openshift-machine-api <control_plane_name>
          1
          Copy to Clipboard Toggle word wrap
          1
          수정할 컨트롤 플레인 머신 오브젝트의 이름을 지정합니다.

        2. 다음 예에 표시된 외부 로드 밸런서를 설명하는 행을 제거합니다. 

          # ...
providerSpec:
  value:
# ...
    loadBalancers:
    - name: lk4pj-ext
          1 
          
      type: network
          2 
          
    - name: lk4pj-int
      type: network
# ...
          Copy to Clipboard Toggle word wrap
          1
          -ext 로 끝나는 외부 로드 밸런서의 name 값을 삭제합니다.
          2
          외부 로드 밸런서의 유형 값을 삭제합니다.
        3. 변경 사항을 저장하고 오브젝트 사양을 종료합니다.
        4. 각 컨트롤 플레인 시스템에 대해 이 프로세스를 반복합니다.

2.5. Azure에서 프라이빗 스토리지 끝점 구성
링크 복사

OpenShift Container Platform이 프라이빗 Azure 클러스터에 배포될 때 프라이빗 스토리지 계정을 원활하게 구성할 수 있도록 이미지 레지스트리 Operator를 활용하여 Azure에서 프라이빗 엔드포인트를 사용할 수 있습니다. 이를 통해 공용 스토리지 끝점을 노출하지 않고 이미지 레지스트리를 배포할 수 있습니다.

중요

엔드포인트가 Microsoft Azure Red Hat OpenShift 클러스터를 복구할 수 없는 상태가 될 수 있으므로 Microsoft Azure Red Hat OpenShift(ARO)에 프라이빗 스토리지 끝점을 구성하지 마십시오.

다음 두 가지 방법 중 하나로 Azure에서 프라이빗 스토리지 끝점을 사용하도록 이미지 레지스트리 Operator를 구성할 수 있습니다.

  • VNet 및 서브넷 이름을 검색하도록 이미지 레지스트리 Operator 구성
  • 사용자 제공 Azure Virtual Network(VNet) 및 서브넷 이름 사용

2.5.1. Azure에서 프라이빗 스토리지 끝점을 구성하는 제한 사항
링크 복사

Azure에서 프라이빗 스토리지 끝점을 구성할 때 다음 제한 사항이 적용됩니다.

  • 프라이빗 스토리지 끝점을 사용하도록 이미지 레지스트리 Operator를 구성하면 스토리지 계정에 대한 공용 네트워크 액세스가 비활성화됩니다. 결과적으로 OpenShift Container Platform 외부의 레지스트리에서 이미지를 가져오는 것은 레지스트리 Operator 구성에서 disableRedirect: true 를 설정하여만 작동합니다. 리디렉션이 활성화되면 레지스트리는 스토리지 계정에서 직접 이미지를 가져오도록 클라이언트를 리디렉션합니다. 이는 비활성화된 공용 네트워크 액세스로 인해 더 이상 작동하지 않습니다. 자세한 내용은 "Azure에서 프라이빗 스토리지 끝점을 사용할 때 리디렉션 비활성화"를 참조하십시오.
  • Image Registry Operator는 이 작업을 실행 취소할 수 없습니다.

다음 절차에서는 VNet 및 서브넷 이름을 검색하도록 Image Registry Operator를 구성하여 Azure에 프라이빗 스토리지 끝점을 설정하는 방법을 보여줍니다.

사전 요구 사항

  • Azure에서 실행되도록 이미지 레지스트리를 구성했습니다.

  • 설치 관리자 프로비저닝 인프라 설치 방법을 사용하여 네트워크가 설정되었습니다.

    사용자 지정 네트워크 설정이 있는 사용자는 "사용자 제공 VNet 및 서브넷 이름으로 Azure에서 프라이빗 스토리지 끝점 구성"을 참조하십시오.

프로세스

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

    $ oc edit configs.imageregistry/cluster
    Copy to Clipboard Toggle word wrap 
    # ...
spec:
  # ...
   storage:
      azure:
        # ...
        networkAccess:
          type: Internal
# ...
    Copy to Clipboard Toggle word wrap

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

    $ oc get configs.imageregistry/cluster -o=jsonpath="{.spec.storage.azure.privateEndpointName}" -w
    Copy to Clipboard Toggle word wrap

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

    $ oc patch configs.imageregistry cluster --type=merge -p '{"spec":{"disableRedirect": true}}'
    Copy to Clipboard Toggle word wrap
    참고

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

검증

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

    $ oc registry info --internal=true
    Copy to Clipboard Toggle word wrap

    출력 예

    image-registry.openshift-image-registry.svc:5000
    Copy to Clipboard Toggle word wrap

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

    $ oc debug node/<node_name>
    Copy to Clipboard Toggle word wrap

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

    $ chroot /host
    Copy to Clipboard Toggle word wrap

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

    $ podman login --tls-verify=false -u unused -p $(oc whoami -t) image-registry.openshift-image-registry.svc:5000
    Copy to Clipboard Toggle word wrap

    출력 예

    Login Succeeded!
    Copy to Clipboard Toggle word wrap

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

    $ podman pull --tls-verify=false image-registry.openshift-image-registry.svc:5000/openshift/tools
    Copy to Clipboard Toggle word wrap

    출력 예

    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
    Copy to Clipboard Toggle word wrap

다음 절차에 따라 공용 네트워크 액세스가 비활성화되고 Azure의 프라이빗 스토리지 끝점 뒤에 노출되는 스토리지 계정을 구성합니다.

사전 요구 사항

  • Azure에서 실행되도록 이미지 레지스트리를 구성했습니다.
  • Azure 환경에 사용되는 VNet 및 서브넷 이름을 알아야 합니다.
  • 네트워크가 Azure의 별도의 리소스 그룹에 구성된 경우 해당 이름도 알고 있어야 합니다.

프로세스

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

    $ oc edit configs.imageregistry/cluster
    Copy to Clipboard Toggle word wrap 
    # ...
spec:
  # ...
   storage:
      azure:
        # ...
        networkAccess:
          type: Internal
          internal:
            subnetName: <subnet_name>
            vnetName: <vnet_name>
            networkResourceGroupName: <network_resource_group_name>
# ...
    Copy to Clipboard Toggle word wrap

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

    $ oc get configs.imageregistry/cluster -o=jsonpath="{.spec.storage.azure.privateEndpointName}" -w
    Copy to Clipboard Toggle word wrap
    참고

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

검증

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

    $ oc registry info --internal=true
    Copy to Clipboard Toggle word wrap

    출력 예

    image-registry.openshift-image-registry.svc:5000
    Copy to Clipboard Toggle word wrap

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

    $ oc debug node/<node_name>
    Copy to Clipboard Toggle word wrap

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

    $ chroot /host
    Copy to Clipboard Toggle word wrap

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

    $ podman login --tls-verify=false -u unused -p $(oc whoami -t) image-registry.openshift-image-registry.svc:5000
    Copy to Clipboard Toggle word wrap

    출력 예

    Login Succeeded!
    Copy to Clipboard Toggle word wrap

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

    $ podman pull --tls-verify=false image-registry.openshift-image-registry.svc:5000/openshift/tools
    Copy to Clipboard Toggle word wrap

    출력 예

    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
    Copy to Clipboard Toggle word wrap

기본적으로 이미지 레지스트리를 사용할 때 리디렉션이 활성화됩니다. 리디렉션을 사용하면 레지스트리 Pod의 트래픽을 오브젝트 스토리지로 오프로드하여 가져오기가 빨라집니다. 리디렉션이 활성화되고 스토리지 계정이 개인 경우 클러스터 외부의 사용자는 레지스트리에서 이미지를 가져올 수 없습니다.

경우에 따라 클러스터 외부의 사용자가 레지스트리에서 이미지를 가져올 수 있도록 리디렉션을 비활성화해야 하는 경우도 있습니다.

다음 절차에 따라 리디렉션을 비활성화합니다.

사전 요구 사항

  • Azure에서 실행되도록 이미지 레지스트리를 구성했습니다.
  • 경로를 구성했습니다.

프로세스

  • 이미지 레지스트리 구성에서 리디렉션을 비활성화하려면 다음 명령을 입력합니다. 

    $ oc patch configs.imageregistry cluster --type=merge -p '{"spec":{"disableRedirect": true}}'
    Copy to Clipboard Toggle word wrap

검증

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

    $ oc registry info
    Copy to Clipboard Toggle word wrap

    출력 예

    default-route-openshift-image-registry.<cluster_dns>
    Copy to Clipboard Toggle word wrap

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

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

    출력 예

    Login Succeeded!
    Copy to Clipboard Toggle word wrap

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

    $ podman pull --tls-verify=false default-route-openshift-image-registry.<cluster_dns>
/openshift/tools
    Copy to Clipboard Toggle word wrap

    출력 예

    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
    Copy to Clipboard Toggle word wrap

3장. 베어 메탈 구성
링크 복사

베어 메탈 호스트에 OpenShift Container Platform을 배포할 때 프로비저닝 전이나 후에 호스트를 변경해야 하는 경우가 있습니다. 여기에는 호스트의 하드웨어, 펌웨어 및 펌웨어 세부 정보 검사가 포함될 수 있습니다. 디스크 포맷 또는 수정 가능한 펌웨어 설정을 변경할 수도 있습니다.

3.1. 사용자 관리 로드 밸런서의 서비스
링크 복사

기본 로드 밸런서 대신 사용자 관리 로드 밸런서를 사용하도록 OpenShift Container Platform 클러스터를 구성할 수 있습니다.

중요

사용자 관리 로드 밸런서 구성은 벤더의 로드 밸런서에 따라 다릅니다.

이 섹션의 정보와 예제는 지침용으로만 사용됩니다. 벤더의 로드 밸런서에 대한 자세한 내용은 벤더 설명서를 참조하십시오.

Red Hat은 사용자 관리 로드 밸런서에 대해 다음 서비스를 지원합니다.

  • Ingress 컨트롤러
  • OpenShift API
  • OpenShift MachineConfig API

사용자 관리 로드 밸런서에 대해 이러한 서비스 중 하나 또는 모두를 구성할지 여부를 선택할 수 있습니다. Ingress 컨트롤러 서비스만 구성하는 것은 일반적인 구성 옵션입니다. 각 서비스를 더 잘 이해하려면 다음 다이어그램을 참조하십시오.

그림 3.1. OpenShift Container Platform 환경에서 작동하는 Ingress 컨트롤러를 보여주는 네트워크 워크플로의 예

OpenShift Container Platform 환경에서 작동하는 Ingress 컨트롤러의 네트워크 워크플로 예제를 보여주는 이미지입니다.

그림 3.2. OpenShift Container Platform 환경에서 작동하는 OpenShift API를 보여주는 네트워크 워크플로우의 예

OpenShift Container Platform 환경에서 작동하는 OpenShift API의 네트워크 워크플로 예제를 보여주는 이미지입니다.

그림 3.3. OpenShift Container Platform 환경에서 작동하는 OpenShift MachineConfig API를 보여주는 네트워크 워크플로우의 예

OpenShift Container Platform 환경에서 작동하는 OpenShift MachineConfig API의 네트워크 워크플로 예제를 보여주는 이미지입니다.

사용자 관리 로드 밸런서에 대해 지원되는 구성 옵션은 다음과 같습니다.

  • 노드 선택기를 사용하여 Ingress 컨트롤러를 특정 노드 세트에 매핑합니다. 이 세트의 각 노드에 고정 IP 주소를 할당하거나 DHCP(Dynamic Host Configuration Protocol)에서 동일한 IP 주소를 수신하도록 각 노드를 구성해야 합니다. 인프라 노드는 일반적으로 이러한 유형의 구성을 수신합니다.

  • 서브넷의 모든 IP 주소를 대상으로 지정합니다. 이 구성은 로드 밸런서 대상을 재구성하지 않고 해당 네트워크 내에서 노드를 생성하고 삭제할 수 있으므로 유지 관리 오버헤드를 줄일 수 있습니다. /27 또는 /28 과 같은 작은 네트워크에 머신 세트를 사용하여 Ingress Pod를 배포하는 경우 로드 밸런서 대상을 단순화할 수 있습니다.

    작은 정보

    머신 구성 풀의 리소스를 확인하여 네트워크에 존재하는 모든 IP 주소를 나열할 수 있습니다.

OpenShift Container Platform 클러스터에 대한 사용자 관리 로드 밸런서를 구성하기 전에 다음 정보를 고려하십시오.

  • 프런트 엔드 IP 주소의 경우 프런트 엔드 IP 주소, Ingress 컨트롤러의 로드 밸런서 및 API 로드 밸런서에 동일한 IP 주소를 사용할 수 있습니다. 이 기능에 대해서는 벤더의 설명서를 확인하십시오.

  • 백엔드 IP 주소의 경우 사용자 관리 로드 밸런서의 수명 동안 OpenShift Container Platform 컨트롤 플레인 노드의 IP 주소가 변경되지 않아야 합니다. 다음 작업 중 하나를 완료하여 이 작업을 수행할 수 있습니다.

    • 각 컨트롤 플레인 노드에 고정 IP 주소를 할당합니다.
    • 노드가 DHCP 리스를 요청할 때마다 DHCP에서 동일한 IP 주소를 수신하도록 각 노드를 구성합니다. 공급 업체에 따라 DHCP 리스를 IP 예약 또는 정적 DHCP 할당의 형태로 될 수 있습니다.
  • Ingress 컨트롤러 백엔드 서비스의 사용자 관리 로드 밸런서에서 Ingress 컨트롤러를 실행하는 각 노드를 수동으로 정의합니다. 예를 들어 Ingress 컨트롤러가 정의되지 않은 노드로 이동하는 경우 연결 중단이 발생할 수 있습니다.

3.1.1. 사용자 관리 로드 밸런서 구성
링크 복사

기본 로드 밸런서 대신 사용자 관리 로드 밸런서를 사용하도록 OpenShift Container Platform 클러스터를 구성할 수 있습니다.

중요

사용자 관리 로드 밸런서를 구성하기 전에 "사용자 관리 로드 밸런서의 서비스" 섹션을 읽으십시오.

사용자 관리 로드 밸런서에 대해 구성할 서비스에 적용되는 다음 사전 요구 사항을 읽으십시오.

참고

클러스터에서 실행되는 MetalLB는 사용자 관리 로드 밸런서로 작동합니다.

OpenShift API 사전 요구 사항

  • 프런트 엔드 IP 주소를 정의했습니다.

  • TCP 포트 6443 및 22623은 로드 밸런서의 프런트 엔드 IP 주소에 노출됩니다. 다음 항목을 확인합니다.

    • 포트 6443은 OpenShift API 서비스에 대한 액세스를 제공합니다.
    • 포트 22623은 노드에 Ignition 시작 구성을 제공할 수 있습니다.
  • 프런트 엔드 IP 주소와 포트 6443은 OpenShift Container Platform 클러스터 외부의 위치로 시스템의 모든 사용자가 연결할 수 있습니다.
  • 프런트 엔드 IP 주소와 포트 22623은 OpenShift Container Platform 노드에서만 연결할 수 있습니다.
  • 로드 밸런서 백엔드는 포트 6443 및 22623의 OpenShift Container Platform 컨트롤 플레인 노드와 통신할 수 있습니다.

Ingress 컨트롤러 사전 요구 사항

  • 프런트 엔드 IP 주소를 정의했습니다.
  • TCP 포트 443 및 80은 로드 밸런서의 프런트 엔드 IP 주소에 노출됩니다.
  • 프런트 엔드 IP 주소, 포트 80 및 포트 443은 OpenShift Container Platform 클러스터 외부에 있는 위치로 시스템의 모든 사용자가 연결할 수 있습니다.
  • 프런트 엔드 IP 주소, 포트 80 및 포트 443은 OpenShift Container Platform 클러스터에서 작동하는 모든 노드에 연결할 수 있습니다.
  • 로드 밸런서 백엔드는 포트 80, 443, 1936에서 Ingress 컨트롤러를 실행하는 OpenShift Container Platform 노드와 통신할 수 있습니다.

상태 점검 URL 사양의 사전 요구 사항

서비스를 사용할 수 없거나 사용할 수 없는지 결정하는 상태 점검 URL을 설정하여 대부분의 로드 밸런서를 구성할 수 있습니다. OpenShift Container Platform은 OpenShift API, 머신 구성 API 및 Ingress 컨트롤러 백엔드 서비스에 대한 이러한 상태 점검을 제공합니다.

다음 예제에서는 이전에 나열된 백엔드 서비스의 상태 점검 사양을 보여줍니다.

Kubernetes API 상태 점검 사양의 예

Path: HTTPS:6443/readyz
Healthy threshold: 2
Unhealthy threshold: 2
Timeout: 10
Interval: 10
Copy to Clipboard Toggle word wrap

Machine Config API 상태 점검 사양의 예

Path: HTTPS:22623/healthz
Healthy threshold: 2
Unhealthy threshold: 2
Timeout: 10
Interval: 10
Copy to Clipboard Toggle word wrap

Ingress 컨트롤러 상태 점검 사양의 예

Path: HTTP:1936/healthz/ready
Healthy threshold: 2
Unhealthy threshold: 2
Timeout: 5
Interval: 10
Copy to Clipboard Toggle word wrap

프로세스

  1. 포트 6443, 22623, 443 및 80의 로드 밸런서에서 클러스터에 액세스할 수 있도록 HAProxy Ingress 컨트롤러를 구성합니다. 필요에 따라 HAProxy 구성에 있는 여러 서브넷의 IP 주소 또는 단일 서브넷의 IP 주소를 지정할 수 있습니다.

    나열된 서브넷이 있는 HAProxy 구성 예

    # ...
listen my-cluster-api-6443
    bind 192.168.1.100:6443
    mode tcp
    balance roundrobin
  option httpchk
  http-check connect
  http-check send meth GET uri /readyz
  http-check expect status 200
    server my-cluster-master-2 192.168.1.101:6443 check inter 10s rise 2 fall 2
    server my-cluster-master-0 192.168.1.102:6443 check inter 10s rise 2 fall 2
    server my-cluster-master-1 192.168.1.103:6443 check inter 10s rise 2 fall 2

listen my-cluster-machine-config-api-22623
    bind 192.168.1.100:22623
    mode tcp
    balance roundrobin
  option httpchk
  http-check connect
  http-check send meth GET uri /healthz
  http-check expect status 200
    server my-cluster-master-2 192.168.1.101:22623 check inter 10s rise 2 fall 2
    server my-cluster-master-0 192.168.1.102:22623 check inter 10s rise 2 fall 2
    server my-cluster-master-1 192.168.1.103:22623 check inter 10s rise 2 fall 2

listen my-cluster-apps-443
    bind 192.168.1.100:443
    mode tcp
    balance roundrobin
  option httpchk
  http-check connect
  http-check send meth GET uri /healthz/ready
  http-check expect status 200
    server my-cluster-worker-0 192.168.1.111:443 check port 1936 inter 10s rise 2 fall 2
    server my-cluster-worker-1 192.168.1.112:443 check port 1936 inter 10s rise 2 fall 2
    server my-cluster-worker-2 192.168.1.113:443 check port 1936 inter 10s rise 2 fall 2

listen my-cluster-apps-80
   bind 192.168.1.100:80
   mode tcp
   balance roundrobin
  option httpchk
  http-check connect
  http-check send meth GET uri /healthz/ready
  http-check expect status 200
    server my-cluster-worker-0 192.168.1.111:80 check port 1936 inter 10s rise 2 fall 2
    server my-cluster-worker-1 192.168.1.112:80 check port 1936 inter 10s rise 2 fall 2
    server my-cluster-worker-2 192.168.1.113:80 check port 1936 inter 10s rise 2 fall 2
# ...
    Copy to Clipboard Toggle word wrap

    나열된 여러 서브넷이 있는 HAProxy 구성의 예

    # ...
listen api-server-6443
    bind *:6443
    mode tcp
      server master-00 192.168.83.89:6443 check inter 1s
      server master-01 192.168.84.90:6443 check inter 1s
      server master-02 192.168.85.99:6443 check inter 1s
      server bootstrap 192.168.80.89:6443 check inter 1s

listen machine-config-server-22623
    bind *:22623
    mode tcp
      server master-00 192.168.83.89:22623 check inter 1s
      server master-01 192.168.84.90:22623 check inter 1s
      server master-02 192.168.85.99:22623 check inter 1s
      server bootstrap 192.168.80.89:22623 check inter 1s

listen ingress-router-80
    bind *:80
    mode tcp
    balance source
      server worker-00 192.168.83.100:80 check inter 1s
      server worker-01 192.168.83.101:80 check inter 1s

listen ingress-router-443
    bind *:443
    mode tcp
    balance source
      server worker-00 192.168.83.100:443 check inter 1s
      server worker-01 192.168.83.101:443 check inter 1s

listen ironic-api-6385
    bind *:6385
    mode tcp
    balance source
      server master-00 192.168.83.89:6385 check inter 1s
      server master-01 192.168.84.90:6385 check inter 1s
      server master-02 192.168.85.99:6385 check inter 1s
      server bootstrap 192.168.80.89:6385 check inter 1s

listen inspector-api-5050
    bind *:5050
    mode tcp
    balance source
      server master-00 192.168.83.89:5050 check inter 1s
      server master-01 192.168.84.90:5050 check inter 1s
      server master-02 192.168.85.99:5050 check inter 1s
      server bootstrap 192.168.80.89:5050 check inter 1s
# ...
    Copy to Clipboard Toggle word wrap

  2. curl CLI 명령을 사용하여 사용자 관리 로드 밸런서 및 해당 리소스가 작동하는지 확인합니다.

    1. 다음 명령을 실행하고 응답을 관찰하여 Kubernetes API 서버 리소스에서 클러스터 머신 구성 API에 액세스할 수 있는지 확인합니다. 

      $ curl https://<loadbalancer_ip_address>:6443/version --insecure
      Copy to Clipboard Toggle word wrap

      구성이 올바르면 응답으로 JSON 오브젝트가 표시됩니다. 

      {
  "major": "1",
  "minor": "11+",
  "gitVersion": "v1.11.0+ad103ed",
  "gitCommit": "ad103ed",
  "gitTreeState": "clean",
  "buildDate": "2019-01-09T06:44:10Z",
  "goVersion": "go1.10.3",
  "compiler": "gc",
  "platform": "linux/amd64"
}
      Copy to Clipboard Toggle word wrap

    2. 다음 명령을 실행하고 출력을 관찰하여 클러스터 머신 구성 API에 머신 구성 서버 리소스에 액세스할 수 있는지 확인합니다. 

      $ curl -v https://<loadbalancer_ip_address>:22623/healthz --insecure
      Copy to Clipboard Toggle word wrap

      구성이 올바르면 명령의 출력에 다음 응답이 표시됩니다. 

      HTTP/1.1 200 OK
Content-Length: 0
      Copy to Clipboard Toggle word wrap

    3. 다음 명령을 실행하고 출력을 관찰하여 포트 80의 Ingress 컨트롤러 리소스에서 컨트롤러에 액세스할 수 있는지 확인합니다. 

      $ curl -I -L -H "Host: console-openshift-console.apps.<cluster_name>.<base_domain>" http://<load_balancer_front_end_IP_address>
      Copy to Clipboard Toggle word wrap

      구성이 올바르면 명령의 출력에 다음 응답이 표시됩니다. 

      HTTP/1.1 302 Found
content-length: 0
location: https://console-openshift-console.apps.ocp4.private.opequon.net/
cache-control: no-cache
      Copy to Clipboard Toggle word wrap

    4. 다음 명령을 실행하고 출력을 관찰하여 포트 443의 Ingress 컨트롤러 리소스에서 컨트롤러에 액세스할 수 있는지 확인합니다. 

      $ curl -I -L --insecure --resolve console-openshift-console.apps.<cluster_name>.<base_domain>:443:<Load Balancer Front End IP Address> https://console-openshift-console.apps.<cluster_name>.<base_domain>
      Copy to Clipboard Toggle word wrap

      구성이 올바르면 명령의 출력에 다음 응답이 표시됩니다. 

      HTTP/1.1 200 OK
referrer-policy: strict-origin-when-cross-origin
set-cookie: csrf-token=UlYWOyQ62LWjw2h003xtYSKlh1a0Py2hhctw0WmV2YEdhJjFyQwWcGBsja261dGLgaYO0nxzVErhiXt6QepA7g==; Path=/; Secure; SameSite=Lax
x-content-type-options: nosniff
x-dns-prefetch-control: off
x-frame-options: DENY
x-xss-protection: 1; mode=block
date: Wed, 04 Oct 2023 16:29:38 GMT
content-type: text/html; charset=utf-8
set-cookie: 1e2670d92730b515ce3a1bb65da45062=1bf5e9573c9a2760c964ed1659cc1673; path=/; HttpOnly; Secure; SameSite=None
cache-control: private
      Copy to Clipboard Toggle word wrap

  3. 사용자 관리 로드 밸런서의 프런트 엔드 IP 주소를 대상으로 하도록 클러스터의 DNS 레코드를 구성합니다. 로드 밸런서를 통해 클러스터 API 및 애플리케이션의 DNS 서버로 레코드를 업데이트해야 합니다.

    수정된 DNS 레코드 예

    <load_balancer_ip_address>  A  api.<cluster_name>.<base_domain>
A record pointing to Load Balancer Front End
    Copy to Clipboard Toggle word wrap 

    <load_balancer_ip_address>   A apps.<cluster_name>.<base_domain>
A record pointing to Load Balancer Front End
    Copy to Clipboard Toggle word wrap
    중요

    DNS 전파는 각 DNS 레코드를 사용할 수 있을 때까지 약간의 시간이 걸릴 수 있습니다. 각 레코드를 검증하기 전에 각 DNS 레코드가 전파되는지 확인합니다.

  4. OpenShift Container Platform 클러스터가 사용자 관리 로드 밸런서를 사용하려면 클러스터의 install-config.yaml 파일에 다음 구성을 지정해야 합니다. 

    # ...
platform:
    loadBalancer:
      type: UserManaged
    1 
    
    apiVIPs:
    - <api_ip>
    2 
    
    ingressVIPs:
    - <ingress_ip>
    3 
    
# ...
    Copy to Clipboard Toggle word wrap
    1
    type 매개변수에 대해 UserManaged 를 설정하여 클러스터의 사용자 관리 로드 밸런서를 지정합니다. 매개변수의 기본값은 기본 내부 로드 밸런서를 나타내는 OpenShiftManagedDefault 입니다. openshift-kni-infra 네임스페이스에 정의된 서비스의 경우 사용자 관리 로드 밸런서는 coredns 서비스를 클러스터의 Pod에 배포할 수 있지만 keepalived 및 haproxy 서비스를 무시합니다.
    2
    사용자 관리 로드 밸런서를 지정할 때 필수 매개변수입니다. Kubernetes API가 사용자 관리 로드 밸런서와 통신할 수 있도록 사용자 관리 로드 밸런서의 공용 IP 주소를 지정합니다.
    3
    사용자 관리 로드 밸런서를 지정할 때 필수 매개변수입니다. 사용자 관리 로드 밸런서에서 클러스터의 인그레스 트래픽을 관리할 수 있도록 사용자 관리 로드 밸런서의 공용 IP 주소를 지정합니다.

검증

  1. curl CLI 명령을 사용하여 사용자 관리 로드 밸런서 및 DNS 레코드 구성이 작동하는지 확인합니다.

    1. 다음 명령을 실행하고 출력을 관찰하여 클러스터 API에 액세스할 수 있는지 확인합니다. 

      $ curl https://api.<cluster_name>.<base_domain>:6443/version --insecure
      Copy to Clipboard Toggle word wrap

      구성이 올바르면 응답으로 JSON 오브젝트가 표시됩니다. 

      {
  "major": "1",
  "minor": "11+",
  "gitVersion": "v1.11.0+ad103ed",
  "gitCommit": "ad103ed",
  "gitTreeState": "clean",
  "buildDate": "2019-01-09T06:44:10Z",
  "goVersion": "go1.10.3",
  "compiler": "gc",
  "platform": "linux/amd64"
  }
      Copy to Clipboard Toggle word wrap

    2. 다음 명령을 실행하고 출력을 관찰하여 클러스터 머신 구성에 액세스할 수 있는지 확인합니다. 

      $ curl -v https://api.<cluster_name>.<base_domain>:22623/healthz --insecure
      Copy to Clipboard Toggle word wrap

      구성이 올바르면 명령의 출력에 다음 응답이 표시됩니다. 

      HTTP/1.1 200 OK
Content-Length: 0
      Copy to Clipboard Toggle word wrap

    3. 다음 명령을 실행하고 출력을 관찰하여 포트의 각 클러스터 애플리케이션에 액세스할 수 있는지 확인합니다. 

      $ curl http://console-openshift-console.apps.<cluster_name>.<base_domain> -I -L --insecure
      Copy to Clipboard Toggle word wrap

      구성이 올바르면 명령의 출력에 다음 응답이 표시됩니다. 

      HTTP/1.1 302 Found
content-length: 0
location: https://console-openshift-console.apps.<cluster-name>.<base domain>/
cache-control: no-cacheHTTP/1.1 200 OK
referrer-policy: strict-origin-when-cross-origin
set-cookie: csrf-token=39HoZgztDnzjJkq/JuLJMeoKNXlfiVv2YgZc09c3TBOBU4NI6kDXaJH1LdicNhN1UsQWzon4Dor9GWGfopaTEQ==; Path=/; Secure
x-content-type-options: nosniff
x-dns-prefetch-control: off
x-frame-options: DENY
x-xss-protection: 1; mode=block
date: Tue, 17 Nov 2020 08:42:10 GMT
content-type: text/html; charset=utf-8
set-cookie: 1e2670d92730b515ce3a1bb65da45062=9b714eb87e93cf34853e87a92d6894be; path=/; HttpOnly; Secure; SameSite=None
cache-control: private
      Copy to Clipboard Toggle word wrap

    4. 다음 명령을 실행하고 출력을 관찰하여 포트 443에서 각 클러스터 애플리케이션에 액세스할 수 있는지 확인합니다. 

      $ curl https://console-openshift-console.apps.<cluster_name>.<base_domain> -I -L --insecure
      Copy to Clipboard Toggle word wrap

      구성이 올바르면 명령의 출력에 다음 응답이 표시됩니다. 

      HTTP/1.1 200 OK
referrer-policy: strict-origin-when-cross-origin
set-cookie: csrf-token=UlYWOyQ62LWjw2h003xtYSKlh1a0Py2hhctw0WmV2YEdhJjFyQwWcGBsja261dGLgaYO0nxzVErhiXt6QepA7g==; Path=/; Secure; SameSite=Lax
x-content-type-options: nosniff
x-dns-prefetch-control: off
x-frame-options: DENY
x-xss-protection: 1; mode=block
date: Wed, 04 Oct 2023 16:29:38 GMT
content-type: text/html; charset=utf-8
set-cookie: 1e2670d92730b515ce3a1bb65da45062=1bf5e9573c9a2760c964ed1659cc1673; path=/; HttpOnly; Secure; SameSite=None
cache-control: private
      Copy to Clipboard Toggle word wrap

3.2. Bare Metal Operator 정보
링크 복사

BMO( Bare Metal Operator)를 사용하여 클러스터에서 베어 메탈 호스트를 프로비저닝, 관리 및 검사합니다.

BMO는 다음 리소스를 사용하여 다음 작업을 완료합니다.

  • BareMetalHost
  • HostFirmwareSettings
  • FirmwareSchema
  • HostFirmwareComponents

BMO는 각 베어 메탈 호스트를 BareMetalHost 사용자 정의 리소스 정의의 인스턴스에 매핑하여 클러스터의 물리적 호스트 인벤토리를 유지 관리합니다. 각 BareMetalHost 리소스에는 하드웨어, 소프트웨어 및 펌웨어 세부 정보가 있습니다. BMO는 클러스터의 베어 메탈 호스트를 지속적으로 검사하여 각 BareMetalHost 리소스에서 해당 호스트의 구성 요소를 정확하게 자세히 설명합니다.

BMO는 HostFirmwareSettings 리소스, FirmwareSchema 리소스 및 HostFirmwareComponents 리소스를 사용하여 펌웨어 사양을 자세히 설명하고 베어 메탈 호스트의 펌웨어를 업그레이드하거나 다운그레이드합니다.

BMO는 Ironic API 서비스를 사용하여 클러스터에서 베어 메탈 호스트와 상호 작용합니다. Ironic 서비스는 호스트의 BMC(Baseboard Management Controller)를 사용하여 시스템과 상호 작용합니다.

BMO를 사용하여 완료할 수 있는 몇 가지 일반적인 작업에는 다음이 포함됩니다.

  • 특정 이미지를 사용하여 클러스터에 베어 메탈 호스트 프로비저닝
  • 프로비저닝 전이나 프로비저닝 해제 후 호스트의 디스크 콘텐츠 포맷
  • 호스트 설정 또는 해제
  • 펌웨어 설정 변경
  • 호스트의 하드웨어 세부 정보 보기
  • 호스트의 펌웨어를 특정 버전으로 업그레이드 또는 다운그레이드

3.2.1. Bare Metal Operator 아키텍처
링크 복사

Bare Metal Operator(BMO)는 다음 리소스를 사용하여 클러스터에서 베어 메탈 호스트를 프로비저닝, 관리 및 검사합니다. 다음 다이어그램은 이러한 리소스의 아키텍처를 보여줍니다.

BMO 아키텍처 개요

BareMetalHost

BareMetalHost 리소스는 물리적 호스트와 해당 속성을 정의합니다. 베어 메탈 호스트를 클러스터에 프로비저닝하는 경우 해당 호스트에 대한 BareMetalHost 리소스를 정의해야 합니다. 호스트를 지속적으로 관리하려면 BareMetalHost 에서 정보를 검사하거나 이 정보를 업데이트할 수 있습니다.

BareMetalHost 리소스에는 다음과 같은 프로비저닝 정보가 있습니다.

  • 운영 체제 부팅 이미지 또는 사용자 정의 RAM 디스크와 같은 배포 사양
  • 프로비저닝 상태
  • BMC(Baseboard Management Controller) 주소
  • 원하는 전원 상태

BareMetalHost 리소스에는 다음과 같은 하드웨어 정보가 있습니다.

  • CPU 수
  • NIC의 MAC 주소
  • 호스트 스토리지 장치의 크기
  • 현재 전원 상태

HostFirmwareSettings

HostFirmwareSettings 리소스를 사용하여 호스트의 펌웨어 설정을 검색하고 관리할 수 있습니다. 호스트가 Available 상태로 이동하면 Ironic 서비스에서 호스트의 펌웨어 설정을 읽고 HostFirmwareSettings 리소스를 생성합니다. BareMetalHost 리소스와 HostFirmwareSettings 리소스 사이에 일대일 매핑이 있습니다.

HostFirmwareSettings 리소스를 사용하여 호스트의 펌웨어 사양을 검사하거나 호스트의 펌웨어 사양을 업데이트할 수 있습니다.

참고

HostFirmwareSettings 리소스의 spec 필드를 편집할 때 벤더 펌웨어와 관련된 스키마를 준수해야 합니다. 이 스키마는 읽기 전용 FirmwareSchema 리소스에서 정의됩니다.

FirmwareSchema

펌웨어 설정은 하드웨어 벤더 및 호스트 모델에 따라 다릅니다. FirmwareSchema 리소스는 각 호스트 모델의 각 펌웨어 설정에 대한 유형 및 제한이 포함된 읽기 전용 리소스입니다. 데이터는 Ironic 서비스를 사용하여 BMC에서 직접 가져옵니다. FirmwareSchema 리소스를 사용하면 HostFirmwareSettings 리소스의 spec 필드에 지정할 수 있는 유효한 값을 식별할 수 있습니다.

스키마가 동일한 경우 FirmwareSchema 리소스는 많은 BareMetalHost 리소스에 적용할 수 있습니다.

HostFirmwareComponents

Metal3 에서는 BIOS 및 BMC(Baseboard Management Controller) 펌웨어 버전을 설명하는 HostFirmwareComponents 리소스를 제공합니다. HostFirmwareComponents 리소스의 spec 필드를 편집하여 호스트의 펌웨어를 특정 버전으로 업그레이드하거나 다운그레이드할 수 있습니다. 이는 특정 펌웨어 버전에 대해 테스트된 검증된 패턴을 사용하여 배포할 때 유용합니다.

3.3. 사용자 지정 br-ex 브리지를 포함하는 매니페스트 오브젝트 생성
링크 복사

사용자 지정 br-ex 브리지가 포함된 매니페스트 오브젝트를 생성하는 다음 사용 사례를 고려하십시오.

  • OVS(Open vSwitch) 또는 OVN-Kubernetes br-ex 브리지 네트워크 변경과 같은 브릿지를 사후 설치하려고 합니다. configure-ovs.sh 쉘 스크립트는 브리지를 사후 설치하도록 지원하지 않습니다.
  • 호스트 또는 서버 IP 주소에 사용 가능한 인터페이스와 다른 인터페이스에 브리지를 배포하려고 합니다.
  • configure-ovs.sh 쉘 스크립트에서 사용할 수 없는 고급 구성을 브리지에 설정하려고 합니다. 이러한 구성에 스크립트를 사용하면 브리지가 여러 네트워크 인터페이스를 연결하고 인터페이스 간 데이터 전달을 용이하게 할 수 있습니다.

사전 요구 사항

  • 대체 방법을 사용하여 configure-ovs 를 사용하여 사용자 지정 br-ex 를 설정합니다.
  • Kubernetes NMState Operator가 설치되어 있어야 합니다.

프로세스

  • NodeNetworkConfigurationPolicy (NNCP) CR을 생성하고 사용자 지정 br-ex 브리지 네트워크 구성을 정의합니다. br-ex NNCP CR에는 네트워크의 OVN-Kubernetes masquerade IP 주소와 서브넷이 포함되어야 합니다. 예제 NNCP CR에는 ipv4.address.ip 및 ipv6.address.ip 매개변수에 기본값이 포함되어 있습니다. ipv4.address.ip,ipv6.address.ip 또는 두 매개변수 모두에서 masquerade IP 주소를 설정할 수 있습니다.

    중요

    설치 후 작업에서는 사용자 지정된 br-ex 브리지의 기본 IP 주소를 변경할 수 없습니다. 단일 스택 클러스터 네트워크를 듀얼 스택 클러스터 네트워크로 변환하려면 NNCP CR에서 보조 IPv6 주소를 추가하거나 변경할 수 있지만 기존 기본 IP 주소는 변경할 수 없습니다. 

    apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: worker-0-br-ex
spec:
  nodeSelector:
    kubernetes.io/hostname: worker-0
    desiredState:
    interfaces:
    - name: enp2s0
      type: ethernet
      state: up
      ipv4:
        enabled: false
      ipv6:
        enabled: false
    - name: br-ex
      type: ovs-bridge
      state: up
      ipv4:
        enabled: false
        dhcp: false
      ipv6:
        enabled: false
        dhcp: false
      bridge:
        options:
          mcast-snooping-enable: true
        port:
        - name: enp2s0
        - name: br-ex
    - name: br-ex
      type: ovs-interface
      state: up
      copy-mac-from: enp2s0
      ipv4:
        enabled: true
        dhcp: true
        auto-route-metric: 48
        address:
        - ip: "169.254.0.2"
          prefix-length: 17
      ipv6:
        enabled: true
        dhcp: true
        auto-route-metric: 48
        address:
        - ip: "fd69::2"
        prefix-length: 112
# ...
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

    metadata.name
    정책 이름입니다.
    interfaces.name
    인터페이스 이름입니다.
    interfaces.type
    이더넷 유형입니다.
    interfaces.state
    생성 후 인터페이스에 요청되는 상태입니다.
    ipv4.enabled
    이 예에서는 IPv4 및 IPv6을 비활성화합니다.
    port.name
    브리지가 연결된 노드 NIC입니다.
    address.ip
    는 기본 IPv4 및 IPv6 IP 주소를 표시합니다. 네트워크의 masquerade IPv4 및 IPv6 IP 주소를 설정해야 합니다.
    auto-route-metric
    매개변수를 48 으로 설정하여 br-ex 기본 경로가 항상 우선 순위가 가장 높은지(가장 낮은 메트릭)인지 확인합니다. 이 구성은 NetworkManager 서비스에서 자동으로 구성하는 다른 인터페이스와의 라우팅 충돌을 방지합니다.

다음 단계

  • 컴퓨팅 노드를 확장하여 사용자 지정 br-ex 브리지가 포함된 매니페스트 오브젝트를 클러스터에 있는 각 컴퓨팅 노드에 적용합니다. 자세한 내용은 추가 리소스 섹션의 "클러스터 확장"을 참조하십시오.

3.4. BareMetalHost 리소스 정보
링크 복사

Metal3 에는 물리적 호스트 및 해당 속성을 정의하는 BareMetalHost 리소스의 개념이 도입되었습니다. BareMetalHost 리소스에는 다음 두 섹션이 포함되어 있습니다.

  1. BareMetalHost 사양
  2. BareMetalHost 상태

3.4.1. BareMetalHost 사양
링크 복사

BareMetalHost 리소스의 spec 섹션에서는 원하는 호스트 상태를 정의합니다.

Expand
표 3.1. BareMetalHost spec
매개 변수설명

automatedCleaningMode

프로비저닝 및 프로비저닝 해제 중에 자동 정리를 활성화하거나 비활성화하는 인터페이스입니다. disabled 로 설정하면 자동화된 정리를 건너뜁니다. 메타데이터 로 설정하면 자동화된 정리가 활성화됩니다. 기본 설정은 metadata 입니다. 

bmc:
  address:
  credentialsName:
  disableCertificateVerification:
Copy to Clipboard Toggle word wrap

bmc 구성 설정에는 호스트의 BMC(Baseboard Management Controller)에 대한 연결 정보가 포함되어 있습니다. 필드는 다음과 같습니다.

  • address: 호스트의 BMC 컨트롤러와 통신하기 위한 URL입니다.
  • credentialsName: BMC의 사용자 이름과 암호가 포함된 보안에 대한 참조입니다.
  • disableCertificateVerification: true 로 설정된 경우 인증서 검증을 건너뛰는 부울입니다.

bootMACAddress

호스트 프로비저닝에 사용되는 NIC의 MAC 주소입니다.

bootMode

호스트의 부팅 모드입니다. 기본값은 UEFI 이지만 BIOS 부팅 또는 UEFISecureBoot 의 경우 legacy 로 설정할 수도 있습니다.

consumerRef

호스트를 사용하는 다른 리소스에 대한 참조입니다. 다른 리소스에서 현재 호스트를 사용하지 않는 경우 비어 있을 수 있습니다. 예를 들어 machine-api 에서 호스트를 사용할 때 Machine 리소스에서 호스트를 사용할 수 있습니다.

description

호스트를 식별하는 데 도움이 되는 사람이 제공하는 문자열입니다.

externallyProvisioned

호스트 프로비저닝 및 프로비저닝 해제가 외부에서 관리되는지 여부를 나타내는 부울입니다. 설정된 경우:

  • 전원 상태는 온라인 필드를 사용하여 계속 관리할 수 있습니다.
  • 하드웨어 인벤토리가 모니터링되지만 호스트에서 프로비저닝 또는 프로비저닝 해제 작업이 수행되지 않습니다.

펌웨어

베어 메탈 호스트의 BIOS 구성에 대한 정보가 포함되어 있습니다. 현재 펌웨어 는 iRMC, iDRAC, iLO4 및 iLO5 BMC에서만 지원됩니다. 하위 필드는 다음과 같습니다.

  • concurrentMultithreadingEnabled: 단일 물리적 프로세서 코어가 여러 개의 논리 프로세서로 표시되도록 허용합니다. 유효한 설정은 true 또는 false 입니다.
  • sriovEnabled: SR-IOV 지원을 사용하면 하이퍼바이저가 PCI-express 장치의 가상 인스턴스를 생성하여 성능이 증가할 수 있습니다. 유효한 설정은 true 또는 false 입니다.
  • virtualizationEnabled: 플랫폼 하드웨어의 가상화를 지원합니다. 유효한 설정은 true 또는 false 입니다. 
image:
  url:
  checksum:
  checksumType:
  format:
Copy to Clipboard Toggle word wrap

이미지 구성 설정에는 호스트에 배포할 이미지의 세부 정보가 있습니다. Ironic에는 이미지 필드가 필요합니다. 그러나 외부 프로비저닝된 구성 설정이 true 로 설정되고 외부 관리에 전원 제어가 필요하지 않은 경우 필드가 비어 있을 수 있습니다. 설정은 다음 필드를 지원합니다.

  • URL: 호스트에 배포할 이미지의 URL입니다.
  • 체크섬: image.url 에서 이미지의 체크섬이 포함된 파일의 실제 체크섬 또는 URL입니다.
  • checksumType: 체크섬 알고리즘을 지정할 수 있습니다. 현재 image.checksumType 은 md5,sha256 및 sha512 만 지원합니다. 기본 체크섬 유형은 md5 입니다.
  • Format: 이미지의 디스크 형식입니다. raw,qcow2,vdi,vmdk,live-iso 또는 left unset 중 하나일 수 있습니다. 원시 로 설정하면 Ironic 에이전트에서 해당 이미지의 원시 이미지 스트리밍이 활성화됩니다. live-iso 로 설정하면 iso 이미지가 디스크에 배포되지 않고 라이브 부팅이 가능하며 체크섬 필드를 무시합니다.

networkData

호스트가 네트워크를 설정하기 전에 호스트에 연결할 수 있도록 네트워크 구성 데이터 및 해당 네임스페이스가 포함된 보안에 대한 참조입니다.

온라인

호스트의 전원을 켜야 하는지(true) 또는 off(false)를 나타내는 부울 값입니다. 이 값을 변경하면 물리적 호스트의 전원 상태가 변경됩니다. 

raid:
  hardwareRAIDVolumes:
  softwareRAIDVolumes:
Copy to Clipboard Toggle word wrap

(선택 사항) 베어 메탈 호스트의 RAID 구성에 대한 정보가 포함됩니다. 지정하지 않으면 현재 구성이 유지됩니다.

참고

OpenShift Container Platform 4.16은 다음을 포함하여 BMC의 설치 드라이브에서 하드웨어 RAID를 지원합니다.

  • RAID 수준 0, 1, 5, 6, 10을 지원하는 Fujitsu iRMC
  • 펌웨어 버전 6.10.30.20 이상 및 RAID 수준 0, 1 및 5와 함께 Redfish API를 사용하는 Dell iDRAC

OpenShift Container Platform 4.16은 설치 드라이브에서 소프트웨어 RAID를 지원하지 않습니다.

다음 구성 설정을 참조하십시오.

  • hardwareRAIDVolumes: 하드웨어 RAID용 논리 드라이브 목록을 포함하며 하드웨어 RAID에서 원하는 볼륨 구성을 정의합니다. rootDeviceHints 를 지정하지 않으면 첫 번째 볼륨은 root 볼륨입니다. 하위 필드는 다음과 같습니다.

    • level: 논리 드라이브의 RAID 수준입니다. 다음 수준이 지원됩니다. 0,1,2,5,6,1+0,5+0,6+0.
    • name: 문자열로 된 볼륨의 이름입니다. 서버 내에서 고유해야 합니다. 지정하지 않으면 볼륨 이름이 자동으로 생성됩니다.
    • numberOfPhysicalDisks: 논리 drove에 사용할 정수로 물리적 드라이브의 수입니다. 기본값은 특정 RAID 수준에 필요한 최소 디스크 드라이브 수입니다.
    • physicalDisks: 물리적 디스크 드라이브의 이름 목록을 문자열로 나타냅니다. 이 필드는 선택적 필드입니다. 지정된 경우 컨트롤러 필드도 지정해야 합니다.
    • Controller: (선택 사항) 하드웨어 RAID 볼륨에서 사용할 문자열로 RAID 컨트롤러의 이름입니다.
    • rotational: true 로 설정하면 회전 디스크 드라이브만 선택됩니다. false 로 설정하면 솔리드 스테이트 및 NVMe 드라이브만 선택됩니다. 설정되지 않은 경우 기본 동작인 드라이브 유형을 선택합니다.
    • sizeGibibytes: GiB 단위로 생성할 논리 드라이브의 크기입니다. 지정되지 않았거나 0 으로 설정하면 논리 드라이브에 대해 물리적 드라이브의 최대 용량을 사용합니다.

  • SoftwareRAIDVolumes: OpenShift Container Platform 4.16은 설치 드라이브에서 소프트웨어 RAID를 지원하지 않습니다. 이 구성에는 소프트웨어 RAID용 논리 디스크 목록이 포함되어 있습니다. rootDeviceHints 를 지정하지 않으면 첫 번째 볼륨은 root 볼륨입니다. HardwareRAIDVolumes 를 설정하면 이 항목이 유효하지 않습니다. 소프트웨어 RAID는 항상 삭제됩니다. 생성된 소프트웨어 RAID 장치의 수는 1 또는 2 여야 합니다. 소프트웨어 RAID 장치가 하나뿐인 경우 RAID-1 이어야 합니다. 두 개의 RAID 장치가 있는 경우 첫 번째 장치는 RAID-1 이어야 하며 두 번째 장치의 RAID 수준은 0,1 또는 1+0 이어야 합니다. 첫 번째 RAID 장치는 소프트웨어 RAID 볼륨일 수 없는 배포 장치입니다. RAID-1 을 강제 적용하면 장치가 실패할 경우 노드가 부팅되지 않을 위험이 줄어듭니다. softwareRAIDVolume 필드는 소프트웨어 RAID에서 볼륨의 원하는 구성을 정의합니다. 하위 필드는 다음과 같습니다.

    • level: 논리 드라이브의 RAID 수준입니다. 지원되는 수준은0,1,1+0 입니다.
    • physicalDisks: 장치 힌트 목록입니다. 항목 수가 2 보다 크거나 같아야 합니다.
    • sizeGibibytes: GiB 단위로 생성할 논리 디스크 드라이브의 크기입니다. 지정되지 않았거나 0 으로 설정하면 논리 드라이브에 대해 물리적 드라이브의 최대 용량을 사용합니다.

hardwareRAIDVolume 을 빈 슬라이스로 설정하여 하드웨어 RAID 구성을 지울 수 있습니다. 예를 들면 다음과 같습니다. 

spec:
   raid:
     hardwareRAIDVolume: []
Copy to Clipboard Toggle word wrap

드라이버가 RAID를 지원하지 않음을 나타내는 오류 메시지가 표시되면 raid,hardwareRAIDVolumes 또는 softwareRAIDVolumes 를 nil로 설정합니다. 호스트에 RAID 컨트롤러가 있는지 확인해야 합니다. 

rootDeviceHints:
  deviceName:
  hctl:
  model:
  vendor:
  serialNumber:
  minSizeGigabytes:
  wwn:
  wwnWithExtension:
  wwnVendorExtension:
  rotational:
Copy to Clipboard Toggle word wrap

rootDeviceHints 매개변수를 사용하면 RHCOS 이미지를 특정 장치에 프로비저닝할 수 있습니다. 장치를 검색한 순서대로 검사하고 검색된 값을 팁 값과 비교합니다. 힌트 값과 일치하는 첫 번째 검색된 장치를 사용합니다. 구성은 여러 힌트를 결합할 수 있지만 장치를 선택하려면 모든 팁과 일치해야 합니다. 필드는 다음과 같습니다.

  • devicename: /dev/vda 와 같은 Linux 장치 이름을 포함하는 문자열입니다. 팁은 실제 값과 정확히 일치해야 합니다.
  • hctl: 0:0:0:0 과 같은 SCSI 버스 주소를 포함하는 문자열입니다. 팁은 실제 값과 정확히 일치해야 합니다.
  • model: 공급 업체별 장치 ID가 포함된 문자열입니다. 팁은 실제 값의 하위 문자열입니다.
  • vendor: 장치의 공급 업체 또는 제조업체 이름이 포함된 문자열입니다. 팁은 실제 값의 하위 문자열입니다.
  • serialnumber: 장치 일련 번호를 포함하는 문자열입니다. 팁은 실제 값과 정확히 일치해야 합니다.
  • minSizeGigabytes: 장치의 최소 크기를 기가바이트 단위로 나타내는 정수입니다.
  • WW N: 고유 스토리지 ID를 포함하는 문자열입니다. 팁은 실제 값과 정확히 일치해야 합니다.
  • wwnWithExtension: 공급 업체 확장이 추가된 고유 스토리지 식별자가 포함된 문자열입니다. 팁은 실제 값과 정확히 일치해야 합니다.
  • wwnVendorExtension: 고유한 공급 업체 스토리지 식별자를 포함하는 문자열입니다. 팁은 실제 값과 정확히 일치해야 합니다.
  • rotational: 장치가 회전 디스크(true)인지(false)인지 여부를 나타내는 부울입니다.

3.4.2. BareMetalHost 상태
링크 복사

BareMetalHost 상태는 호스트의 현재 상태를 나타내며 테스트된 인증 정보, 현재 하드웨어 세부 정보 및 기타 정보를 포함합니다.

Expand
표 3.2. BareMetalHost 상태
매개 변수설명

goodCredentials

시스템에서 검증할 수 있는 마지막 BMC(Baseboard Management Controller) 인증 정보를 보유한 시크릿 및 해당 네임스페이스에 대한 참조입니다.

errorMessage

프로비저닝 백엔드에서 보고한 마지막 오류의 세부 정보(있는 경우).

errorType

호스트가 오류 상태가 된 문제의 클래스를 나타냅니다. 오류 유형은 다음과 같습니다.

  • 프로비저닝된 등록 오류: 컨트롤러가 이미 프로비저닝된 호스트를 다시 등록할 수 없는 경우 발생합니다.
  • 등록 오류: 컨트롤러가 호스트의 베이스 보드 관리 컨트롤러에 연결할 수 없는 경우 발생합니다.
  • 검사 오류: 호스트에서 하드웨어 세부 정보를 가져오려고 할 때 발생합니다.
  • 준비 오류: 정리에 실패할 때 발생합니다.
  • 프로비저닝 오류: 컨트롤러가 호스트를 프로비저닝하거나 프로비저닝 해제하지 못할 때 발생합니다.
  • 전원 관리 오류: 컨트롤러가 호스트의 전원 상태를 수정할 수 없는 경우 발생합니다.
  • 분리 오류: 컨트롤러가 프로비저너에서 호스트를 분리할 수 없는 경우 발생합니다. 
hardware:
  cpu
    arch:
    model:
    clockMegahertz:
    flags:
    count:
Copy to Clipboard Toggle word wrap

hardware.cpu 필드 시스템의 CPU 세부 정보입니다. 필드는 다음과 같습니다.

  • Arch: CPU의 아키텍처입니다.
  • model: CPU 모델이 문자열로 되어 있습니다.
  • clockMegahertz: CPU의 속도입니다.
  • flags: CPU 플래그 목록입니다. 예를 들어 'mmx','sse', 'sse2','vmx' 등이 있습니다.
  • count: 시스템에서 사용 가능한 CPU 수입니다. 
hardware:
  firmware:
Copy to Clipboard Toggle word wrap

BIOS 펌웨어 정보를 포함합니다. 예를 들어 하드웨어 벤더 및 버전입니다. 

hardware:
  nics:
  - ip:
    name:
    mac:
    speedGbps:
    vlans:
    vlanId:
    pxe:
Copy to Clipboard Toggle word wrap

hardware.nics 필드에는 호스트에 대한 네트워크 인터페이스 목록이 포함되어 있습니다. 필드는 다음과 같습니다.

  • IP: 검색 에이전트가 실행될 때 할당된 NIC의 IP 주소입니다.
  • name: 네트워크 장치를 식별하는 문자열입니다. 예를 들면 nic-1 입니다.
  • Mac: NIC의 MAC 주소입니다.
  • speedGbps: Gbps 단위의 장치 속도입니다.
  • VLAN: 이 NIC에 사용 가능한 모든 VLAN이 있는 목록입니다.
  • vlanId: 태그가 지정되지 않은 VLAN ID입니다.
  • PXE: NIC가 PXE를 사용하여 부팅할 수 있는지 여부입니다. 
hardware:
  ramMebibytes:
Copy to Clipboard Toggle word wrap

호스트의 메모리 양(MB)입니다. 

hardware:
  storage:
  - name:
    rotational:
    sizeBytes:
    serialNumber:
Copy to Clipboard Toggle word wrap

hardware.storage 필드에는 호스트에서 사용할 수 있는 스토리지 장치 목록이 포함되어 있습니다. 필드는 다음과 같습니다.

  • name: 스토리지 장치를 식별하는 문자열입니다. 예를 들면 디스크 1(부팅) 입니다.
  • rotational: 디스크가 rotational인지 여부를 나타내며 true 또는 false 를 반환합니다.
  • sizeBytes: 저장 장치의 크기입니다.
  • serialnumber: 장치의 일련 번호입니다. 
hardware:
  systemVendor:
    manufacturer:
    productName:
    serialNumber:
Copy to Clipboard Toggle word wrap

호스트의 제조업체, productName, serialNumber 에 대한 정보를 포함합니다.

lastUpdated

호스트 상태가 마지막으로 업데이트된 시점의 타임스탬프입니다.

operationalStatus

서버 상태. 상태는 다음 중 하나입니다.

  • OK: 호스트의 모든 세부 정보가 알려지고, 올바르게 구성되고, 작동하고, 관리할 수 있음을 나타냅니다.
  • discovered: 일부 호스트의 세부 정보가 제대로 작동하지 않거나 누락된 경우입니다. 예를 들어 BMC 주소는 알려져 있지만 로그인 자격 증명은 그렇지 않습니다.
  • error: 시스템에 일종의 복구할 수 없는 오류가 있음을 나타냅니다. 자세한 내용은 상태 섹션의 errorMessage 필드를 참조하십시오.
  • 지연됨: 여러 호스트의 동시 프로비저닝을 제한하기 위해 프로비저닝이 지연됨을 나타냅니다.
  • 분리됨: 호스트가 관리되지 않음 으로 표시됩니다.

poweredOn

호스트의 전원이 켜졌는지 여부를 나타내는 부울입니다. 

provisioning:
  state:
  id:
  image:
  raid:
  firmware:
  rootDeviceHints:
Copy to Clipboard Toggle word wrap

provisioning 필드에는 호스트에 이미지 배포와 관련된 값이 포함되어 있습니다. 서브 필드는 다음과 같습니다.

  • 상태: 진행 중인 프로비저닝 작업의 현재 상태입니다. 국가에는 다음이 포함됩니다.

    • <empty string > : 현재 프로비저닝이 발생하지 않습니다.
    • Unmanaged: 호스트를 등록할 수 있는 정보가 충분하지 않습니다.
    • 등록: 에이전트는 호스트의 BMC 세부 정보를 확인하고 있습니다.
    • match profile: 에이전트는 호스트에서 검색된 하드웨어 세부 정보를 알려진 프로필과 비교합니다.
    • Available: 호스트를 프로비저닝할 수 있습니다. 이 상태를 이전에 ready 이라고 했습니다.
    • preparing: 기존 구성이 제거되고 새 구성이 호스트에 설정됩니다.
    • provisioning: 프로비저너가 호스트의 스토리지에 이미지를 작성하고 있습니다.
    • provisioned: 프로비저너가 호스트의 스토리지에 이미지를 작성했습니다.
    • 외부 프로비저닝: Metal3 은 호스트의 이미지를 관리하지 않습니다.
    • 프로비저닝 해제: 프로비저너가 호스트의 스토리지에서 이미지를 제거하고 있습니다.
    • inspect: 에이전트가 호스트의 하드웨어 세부 정보를 수집하고 있습니다.
    • Delete: 에이전트가 클러스터에서 를 삭제하고 있습니다.
  • ID: 기본 프로비저닝 툴에서 서비스의 고유 식별자입니다.
  • image: 호스트에 가장 최근에 프로비저닝된 이미지입니다.
  • RAID: 최근 설정된 하드웨어 또는 소프트웨어 RAID 볼륨 목록입니다.
  • 펌웨어: 베어 메탈 서버의 BIOS 구성입니다.
  • RootDeviceHints: 최근 프로비저닝 작업에 사용되는 루트 장치 선택 지침입니다.

triedCredentials

시크릿 및 해당 네임스페이스에 대한 참조로, 프로비저닝 백엔드로 전송된 BMC 자격 증명의 마지막 세트를 보유합니다.

3.5. BareMetalHost 리소스 가져오기
링크 복사

BareMetalHost 리소스에는 물리적 호스트의 속성이 포함되어 있습니다. 물리적 호스트에서 속성을 검토하려면 BareMetalHost 리소스를 가져와야 합니다.

프로세스

  1. BareMetalHost 리소스 목록을 가져옵니다. 

    $ oc get bmh -n openshift-machine-api -o yaml
    Copy to Clipboard Toggle word wrap
    참고

    baremetalhost 를 oc get 명령과 함께 긴 형태의 bmh 로 사용할 수 있습니다.

  2. 호스트 목록을 가져옵니다. 

    $ oc get bmh -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

  3. 특정 호스트에 대한 BareMetalHost 리소스를 가져옵니다. 

    $ oc get bmh <host_name> -n openshift-machine-api -o yaml
    Copy to Clipboard Toggle word wrap

    여기서 <host_name >은 호스트의 이름입니다.

    출력 예

    apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
metadata:
  creationTimestamp: "2022-06-16T10:48:33Z"
  finalizers:
  - baremetalhost.metal3.io
  generation: 2
  name: openshift-worker-0
  namespace: openshift-machine-api
  resourceVersion: "30099"
  uid: 1513ae9b-e092-409d-be1b-ad08edeb1271
spec:
  automatedCleaningMode: metadata
  bmc:
    address: redfish://10.46.61.19:443/redfish/v1/Systems/1
    credentialsName: openshift-worker-0-bmc-secret
    disableCertificateVerification: true
  bootMACAddress: 48:df:37:c7:f7:b0
  bootMode: UEFI
  consumerRef:
    apiVersion: machine.openshift.io/v1beta1
    kind: Machine
    name: ocp-edge-958fk-worker-0-nrfcg
    namespace: openshift-machine-api
  customDeploy:
    method: install_coreos
  online: true
  rootDeviceHints:
    deviceName: /dev/disk/by-id/scsi-<serial_number>
  userData:
    name: worker-user-data-managed
    namespace: openshift-machine-api
status:
  errorCount: 0
  errorMessage: ""
  goodCredentials:
    credentials:
      name: openshift-worker-0-bmc-secret
      namespace: openshift-machine-api
    credentialsVersion: "16120"
  hardware:
    cpu:
      arch: x86_64
      clockMegahertz: 2300
      count: 64
      flags:
      - 3dnowprefetch
      - abm
      - acpi
      - adx
      - aes
      model: Intel(R) Xeon(R) Gold 5218 CPU @ 2.30GHz
    firmware:
      bios:
        date: 10/26/2020
        vendor: HPE
        version: U30
    hostname: openshift-worker-0
    nics:
    - mac: 48:df:37:c7:f7:b3
      model: 0x8086 0x1572
      name: ens1f3
    ramMebibytes: 262144
    storage:
    - hctl: "0:0:0:0"
      model: VK000960GWTTB
      name: /dev/disk/by-id/scsi-<serial_number>
      sizeBytes: 960197124096
      type: SSD
      vendor: ATA
    systemVendor:
      manufacturer: HPE
      productName: ProLiant DL380 Gen10 (868703-B21)
      serialNumber: CZ200606M3
  lastUpdated: "2022-06-16T11:41:42Z"
  operationalStatus: OK
  poweredOn: true
  provisioning:
    ID: 217baa14-cfcf-4196-b764-744e184a3413
    bootMode: UEFI
    customDeploy:
      method: install_coreos
    image:
      url: ""
    raid:
      hardwareRAIDVolumes: null
      softwareRAIDVolumes: []
    rootDeviceHints:
      deviceName: /dev/disk/by-id/scsi-<serial_number>
    state: provisioned
  triedCredentials:
    credentials:
      name: openshift-worker-0-bmc-secret
      namespace: openshift-machine-api
    credentialsVersion: "16120"
    Copy to Clipboard Toggle word wrap

3.6. BareMetalHost 리소스 편집
링크 복사

베어 메탈에 OpenShift Container Platform 클러스터를 배포한 후 노드의 BareMetalHost 리소스를 편집해야 할 수 있습니다. 다음 예제를 고려하십시오.

  • 지원 설치 관리자를 사용하여 클러스터를 배포하고 BMC(Baseboard Management Controller) 호스트 이름 또는 IP 주소를 추가하거나 편집해야 합니다.
  • 프로비저닝을 해제하지 않고 한 클러스터에서 다른 클러스터로 노드를 이동하려고 합니다.

사전 요구 사항

  • 노드가 Provisioned,ExternallyProvisioned 또는 Available 상태인지 확인합니다.

프로세스

  1. 노드 목록을 가져옵니다. 

    $ oc get bmh -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

  2. 노드의 BareMetalHost 리소스를 편집하기 전에 다음 명령을 실행하여 Ironic에서 노드를 분리합니다. 

    $ oc annotate baremetalhost <node_name> -n openshift-machine-api 'baremetalhost.metal3.io/detached=true'
    1
    Copy to Clipboard Toggle word wrap
    1
    & lt;node_name >을 노드 이름으로 바꿉니다.

  3. 다음 명령을 실행하여 BareMetalHost 리소스를 편집합니다. 

    $ oc edit bmh <node_name> -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

  4. 다음 명령을 실행하여 Ironic에 노드를 다시 연결합니다. 

    $ oc annotate baremetalhost <node_name> -n openshift-machine-api 'baremetalhost.metal3.io/detached'-
    Copy to Clipboard Toggle word wrap

3.7. BareMetalHost 리소스를 삭제할 때 대기 시간 문제 해결
링크 복사

Bare Metal Operator(BMO)가 BareMetalHost 리소스를 삭제하면 Ironic에서 베어 메탈 호스트를 프로비저닝 해제합니다. 예를 들어 머신 세트를 축소할 때 이러한 상황이 발생할 수 있습니다. 프로비저닝 해제에는 다음 단계를 수행하는 "정리"라는 프로세스가 포함됩니다.

  • 베어 메탈 호스트 전원 끄기
  • 베어 메탈 호스트에서 서비스 RAM 디스크 부팅
  • 모든 디스크에서 파티션 메타데이터 제거
  • 베어 메탈 호스트의 전원을 다시 끄기

정리가 실패하면 BareMetalHost 리소스를 삭제하는 데 시간이 오래 걸리며 완료되지 않을 수 있습니다.

중요

BareMetalHost 리소스를 강제로 삭제하려면 종료자를 제거하지 마십시오. 프로비저닝 백엔드에는 호스트 레코드를 유지 관리하는 자체 데이터베이스가 있습니다. 종료자를 제거하여 강제로 삭제하려는 경우에도 실행 중인 작업이 계속 실행됩니다. 나중에 베어 메탈 호스트를 추가하려고 할 때 예기치 않은 문제에 직면할 수 있습니다.

프로세스

  1. 정리 프로세스가 복구될 수 있는 경우 완료될 때까지 기다립니다.
  2. 정리를 복구할 수 없는 경우 BareMetalHost 리소스를 수정하고 automatedCleaningMode 필드를 disabled 로 설정하여 정리 프로세스를 비활성화합니다.

자세한 내용은 " BareMetalHost 리소스 편집"을 참조하십시오.

3.8. 베어 메탈 노드에 부팅 불가능한 ISO 연결
링크 복사

DataImage 리소스를 사용하여 부팅 불가능한 일반 ISO 가상 미디어 이미지를 프로비저닝된 노드에 연결할 수 있습니다. 리소스를 적용하면 부팅 후 운영 체제에서 ISO 이미지에 액세스할 수 있게 됩니다. 이는 운영 체제를 프로비저닝한 후 노드를 처음 부팅하기 전에 노드를 구성하는 데 유용합니다.

사전 요구 사항

  • 이 기능을 지원하려면 노드에서 Redfish 또는 드라이버를 사용해야 합니다.
  • 노드가 Provisioned 또는 ExternallyProvisioned 상태여야 합니다.
  • 이름은 BareMetalHost 리소스에 정의된 노드의 이름과 동일해야 합니다.
  • ISO 이미지에 유효한 URL 이 있습니다.

프로세스

  1. DataImage 리소스를 생성합니다. 

    apiVersion: metal3.io/v1alpha1
kind: DataImage
metadata:
  name: <node_name>
    1 
    
spec:
  url: "http://dataimage.example.com/non-bootable.iso"
    2
    Copy to Clipboard Toggle word wrap
    1
    BareMetalHost 리소스에 정의된 노드 이름을 지정합니다.
    2
    ISO 이미지의 URL 및 경로를 지정합니다.

  2. 다음 명령을 실행하여 DataImage 리소스를 파일에 저장합니다. 

    $ vim <node_name>-dataimage.yaml
    Copy to Clipboard Toggle word wrap

  3. 다음 명령을 실행하여 DataImage 리소스를 적용합니다. 

    $ oc apply -f <node_name>-dataimage.yaml -n <node_namespace>
    1
    Copy to Clipboard Toggle word wrap
    1
    네임스페이스가 BareMetalHost 리소스의 네임스페이스와 일치하도록 <node_namespace>를 바꿉니다. 예를 들면 openshift-machine-api 입니다.

  4. 노드를 재부팅합니다.

    참고

    노드를 재부팅하려면 reboot.metal3.io 주석을 연결하거나 BareMetalHost 리소스에서 온라인 상태를 재설정합니다. 베어 메탈 노드를 강제로 재부팅하면 노드의 상태가 NotReady 로 변경됩니다. 예를 들면 5분 이상입니다.

  5. 다음 명령을 실행하여 DataImage 리소스를 확인합니다. 

    $ oc get dataimage <node_name> -n openshift-machine-api -o yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    apiVersion: v1
items:
- apiVersion: metal3.io/v1alpha1
  kind: DataImage
  metadata:
    annotations:
      kubectl.kubernetes.io/last-applied-configuration: |
        {"apiVersion":"metal3.io/v1alpha1","kind":"DataImage","metadata":{"annotations":{},"name":"bmh-node-1","namespace":"openshift-machine-api"},"spec":{"url":"http://dataimage.example.com/non-bootable.iso"}}
    creationTimestamp: "2024-06-10T12:00:00Z"
    finalizers:
    - dataimage.metal3.io
    generation: 1
    name: bmh-node-1
    namespace: openshift-machine-api
    ownerReferences:
    - apiVersion: metal3.io/v1alpha1
      blockOwnerDeletion: true
      controller: true
      kind: BareMetalHost
      name: bmh-node-1
      uid: 046cdf8e-0e97-485a-8866-e62d20e0f0b3
    resourceVersion: "21695581"
    uid: c5718f50-44b6-4a22-a6b7-71197e4b7b69
  spec:
    url: http://dataimage.example.com/non-bootable.iso
  status:
    attachedImage:
      url: http://dataimage.example.com/non-bootable.iso
    error:
      count: 0
      message: ""
    lastReconciled: "2024-06-10T12:05:00Z"
    Copy to Clipboard Toggle word wrap

3.9. HostFirmwareSettings 리소스 정보
링크 복사

HostFirmwareSettings 리소스를 사용하여 호스트의 BIOS 설정을 검색하고 관리할 수 있습니다. 호스트가 Available 상태로 이동하면 Ironic에서 호스트의 BIOS 설정을 읽고 HostFirmwareSettings 리소스를 생성합니다. 리소스에는 BMC(Baseboard Management Controller)에서 반환된 전체 BIOS 구성이 포함되어 있습니다. 반면 BareMetalHost 리소스의 펌웨어 필드는 세 가지 벤더 독립적인 필드를 반환하지만 HostFirmwareSettings 리소스는 일반적으로 호스트당 벤더별 필드의 많은 BIOS 설정을 포함합니다.

HostFirmwareSettings 리소스에는 다음 두 섹션이 포함되어 있습니다.

  1. HostFirmwareSettings 사양입니다.
  2. HostFirmwareSettings 상태입니다.

3.9.1. HostFirmwareSettings 사양
링크 복사

HostFirmwareSettings 리소스의 spec 섹션은 호스트 BIOS의 원하는 상태를 정의하며 기본적으로 비어 있습니다. Ironic은 spec.settings 섹션의 설정을 사용하여 호스트가 준비 상태에 있을 때 BMC(Baseboard Management Controller)를 업데이트합니다. FirmwareSchema 리소스를 사용하여 잘못된 이름/값 쌍을 호스트에 보내지 않도록 합니다. 자세한 내용은 " FirmwareSchema 리소스 수락"을 참조하십시오.

예제

spec:
  settings:
    ProcTurboMode: Disabled
1
Copy to Clipboard Toggle word wrap

1
위 예제에서 spec.settings 섹션에는 ProcTurboMode BIOS 설정을 Disabled 로 설정하는 이름/값 쌍이 포함되어 있습니다.
참고

상태 섹션에 나열된 정수 매개 변수는 문자열로 표시됩니다. 예를 들면 "1" 입니다. spec.settings 섹션에서 정수를 설정할 때 값은 따옴표 없이 정수로 설정해야 합니다. 예를 들면 1 입니다.

3.9.2. HostFirmwareSettings 상태
링크 복사

상태는 호스트 BIOS의 현재 상태를 나타냅니다.

Expand
표 3.3. HostFirmwareSettings
매개 변수설명
status:
  conditions:
  - lastTransitionTime:
    message:
    observedGeneration:
    reason:
    status:
    type:
Copy to Clipboard Toggle word wrap

conditions 필드에는 상태 변경 목록이 포함되어 있습니다. 서브 필드는 다음과 같습니다.

  • lastTransitionTime: 상태가 마지막으로 변경된 시간입니다.
  • Message: 상태 변경에 대한 설명입니다.
  • observedGeneration: 상태 의 현재 생성입니다. metadata.generation 및 이 필드가 동일하지 않으면 status.conditions 가 최신 상태가 될 수 있습니다.
  • 이유: 국가 변경의 이유
  • status: 상태 변경의 상태입니다. 상태는 True,False 또는 알 수 없음일 수 있습니다.
  • 유형: 상태 변경의 유형입니다. 유형은 Valid 및 ChangeDetected. 
status:
  schema:
    name:
    namespace:
    lastUpdated:
Copy to Clipboard Toggle word wrap

펌웨어 설정의 FirmwareSchema 입니다. 필드는 다음과 같습니다.

  • name: 스키마를 참조하는 이름 또는 고유 식별자입니다.
  • namespace: 스키마가 저장된 네임스페이스입니다.
  • lastUpdated: 리소스가 마지막으로 업데이트된 시간입니다. 
status:
  settings:
Copy to Clipboard Toggle word wrap

설정 필드에는 호스트의 현재 BIOS 설정의 이름/값 쌍 목록이 포함되어 있습니다.

3.10. HostFirmwareSettings 리소스 가져오기
링크 복사

HostFirmwareSettings 리소스에는 물리적 호스트의 벤더별 BIOS 속성이 포함되어 있습니다. BIOS 속성을 검토하려면 물리적 호스트에 대한 HostFirmwareSettings 리소스를 가져와야 합니다.

프로세스

  1. HostFirmwareSettings 리소스의 자세한 목록을 가져옵니다. 

    $ oc get hfs -n openshift-machine-api -o yaml
    Copy to Clipboard Toggle word wrap
    참고

    oc get 명령과 함께 hfs 의 긴 형식으로 hostfirmwaresettings 를 사용할 수 있습니다.

  2. HostFirmwareSettings 리소스 목록을 가져옵니다. 

    $ oc get hfs -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

  3. 특정 호스트에 대한 HostFirmwareSettings 리소스 가져오기 

    $ oc get hfs <host_name> -n openshift-machine-api -o yaml
    Copy to Clipboard Toggle word wrap

    여기서 <host_name >은 호스트의 이름입니다.

3.11. HostFirmwareSettings 리소스 편집
링크 복사

프로비저닝된 호스트의 HostFirmwareSettings 을 편집할 수 있습니다.

중요

읽기 전용 값을 제외하고 프로비저닝된 상태에 있는 경우에만 호스트를 편집할 수 있습니다. 외부 프로비저닝된 상태에서 호스트를 편집할 수 없습니다.

프로세스

  1. HostFirmwareSettings 리소스 목록을 가져옵니다. 

    $ oc get hfs -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

  2. 호스트의 HostFirmwareSettings 리소스를 편집합니다. 

    $ oc edit hfs <host_name> -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

    여기서 <host_name >은 프로비저닝된 호스트의 이름입니다. HostFirmwareSettings 리소스는 터미널의 기본 편집기에서 열립니다.

  3. spec.settings 섹션에 이름/값 쌍을 추가합니다.

    예제

    spec:
  settings:
    name: value
    1
    Copy to Clipboard Toggle word wrap

    1
    FirmwareSchema 리소스를 사용하여 호스트에 사용 가능한 설정을 식별합니다. 읽기 전용 값은 설정할 수 없습니다.
  4. 변경 사항을 저장하고 편집기를 종료합니다.

  5. 호스트의 시스템 이름을 가져옵니다. 

     $ oc get bmh <host_name> -n openshift-machine name
    Copy to Clipboard Toggle word wrap

    여기서 <host_name >은 호스트의 이름입니다. 시스템 이름은 CONSUMER 필드에 표시됩니다.

  6. 머신 세트에서 삭제하려면 머신에 주석을 답니다. 

    $ oc annotate machine <machine_name> machine.openshift.io/delete-machine=true -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

    여기서 <machine_name >은 삭제할 머신의 이름입니다.

  7. 노드 목록을 가져오고 작업자 노드 수를 계산합니다. 

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

  8. 머신 세트를 가져옵니다. 

    $ oc get machinesets -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

  9. 머신 세트를 스케일링합니다. 

    $ oc scale machineset <machineset_name> -n openshift-machine-api --replicas=<n-1>
    Copy to Clipboard Toggle word wrap

    여기서 <machineset_name >은 머신 세트의 이름이며 < n-1 >은 감소된 작업자 노드 수입니다.

  10. 호스트가 Available 상태가 되면 machineset을 확장하여 HostFirmwareSettings 리소스 변경 사항을 적용합니다. 

    $ oc scale machineset <machineset_name> -n openshift-machine-api --replicas=<n>
    Copy to Clipboard Toggle word wrap

    여기서 <machineset_name >은 머신 세트 이름이며 < n >은 작업자 노드 수입니다.

3.12. HostFirmware 설정 리소스가 유효한지 확인
링크 복사

사용자가 spec.settings 섹션을 편집하여 HFS( HostFirmwareSetting) 리소스를 변경하면 Bare Metal Operator(BMO)는 읽기 전용 리소스인 FimwareSchema 리소스에 대한 변경 사항을 검증합니다. 설정이 유효하지 않으면 BMO에서 status.Condition 설정의 Type 값을 False 로 설정하고 이벤트를 생성하여 HFS 리소스에 저장합니다. 다음 절차를 사용하여 리소스가 유효한지 확인합니다.

프로세스

  1. HostFirmwareSetting 리소스 목록을 가져옵니다. 

    $ oc get hfs -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

  2. 특정 호스트의 HostFirmwareSettings 리소스가 유효한지 확인합니다. 

    $ oc describe hfs <host_name> -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

    여기서 <host_name >은 호스트의 이름입니다.

    출력 예

    Events:
  Type    Reason            Age    From                                    Message
  ----    ------            ----   ----                                    -------
  Normal  ValidationFailed  2m49s  metal3-hostfirmwaresettings-controller  Invalid BIOS setting: Setting ProcTurboMode is invalid, unknown enumeration value - Foo
    Copy to Clipboard Toggle word wrap

    중요

    응답이 ValidationFailed 를 반환하는 경우 리소스 구성에 오류가 있으며 FirmwareSchema 리소스를 준수하도록 값을 업데이트해야 합니다.

3.13. FirmwareSchema 리소스 정보
링크 복사

BIOS 설정은 하드웨어 벤더 및 호스트 모델에 따라 다릅니다. FirmwareSchema 리소스는 각 호스트 모델의 각 BIOS 설정에 대한 유형 및 제한이 포함된 읽기 전용 리소스입니다. 데이터는 Ironic을 통해 BMC에서 직접 가져옵니다. FirmwareSchema 를 사용하면 HostFirmwareSettings 리소스의 spec 필드에 지정할 수 있는 유효한 값을 식별할 수 있습니다. FirmwareSchema 리소스에는 설정 및 제한에서 파생된 고유 식별자가 있습니다. 동일한 호스트 모델은 동일한 FirmwareSchema 식별자를 사용합니다. HostFirmwareSettings 의 여러 인스턴스가 동일한 FirmwareSchema 를 사용할 가능성이 큽니다.

Expand
표 3.4. FirmwareSchema specification
매개 변수설명
<BIOS_setting_name>
  attribute_type:
  allowable_values:
  lower_bound:
  upper_bound:
  min_length:
  max_length:
  read_only:
  unique:
Copy to Clipboard Toggle word wrap

사양 은 BIOS 설정 이름과 설정의 제한으로 구성된 간단한 맵입니다. 필드는 다음과 같습니다.

  • attribute_type: 설정 유형입니다. 지원되는 유형은 다음과 같습니다.

    • 열거
    • 정수
    • 문자열
    • 부울
  • allowable_values: attribute_type 이 Enumeration 인 경우 허용 가능한 값 목록입니다.
  • lower_bound: attribute_type 이 Integer 일 때 가장 낮은 허용 값입니다.
  • upper_bound: attribute_type 이 Integer 일 때 허용되는 가장 높은 값입니다.
  • min_length: attribute_type 이 문자열일 때 값을 가질 수 있는 가장 짧은 문자열 길이입니다.
  • max_length: attribute_type 이 문자열일 때 값을 가질 수 있는 가장 긴 문자열 길이입니다.
  • READ_ONLY: 설정이 읽기 전용이며 수정할 수 없습니다.
  • unique: 설정은 이 호스트에 따라 다릅니다.

3.14. FirmwareSchema 리소스 가져오기
링크 복사

각 벤더의 호스트 모델에는 서로 다른 BIOS 설정이 있습니다. HostFirmwareSettings 리소스의 spec 섹션을 편집할 때 설정한 이름/값 쌍은 해당 호스트의 펌웨어 스키마를 준수해야 합니다. 유효한 이름/값 쌍을 설정하려면 호스트의 FirmwareSchema 를 가져와서 검토합니다.

프로세스

  1. FirmwareSchema 리소스 인스턴스 목록을 가져오려면 다음을 실행합니다. 

    $ oc get firmwareschema -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

  2. 특정 FirmwareSchema 인스턴스를 가져오려면 다음을 실행합니다. 

    $ oc get firmwareschema <instance_name> -n openshift-machine-api -o yaml
    Copy to Clipboard Toggle word wrap

    여기서 <instance_name >은 HostFirmwareSettings 리소스에 명시된 스키마 인스턴스의 이름입니다(표 3 참조).

3.15. HostFirmwareComponents 리소스 정보
링크 복사

Metal3 에서는 BIOS 및 BMC(Baseboard Management Controller) 펌웨어 버전을 설명하는 HostFirmwareComponents 리소스를 제공합니다. HostFirmwareComponents 리소스에는 다음 두 섹션이 포함되어 있습니다.

  1. HostFirmwareComponents 사양
  2. HostFirmwareComponents 상태

3.15.1. HostFirmwareComponents 사양
링크 복사

HostFirmwareComponents 리소스의 spec 섹션에서는 호스트의 BIOS 및 BMC 버전의 원하는 상태를 정의합니다.

Expand
표 3.5. HostFirmwareComponents 사양
매개 변수설명
updates:
  component:
  url:
Copy to Clipboard Toggle word wrap

업데이트 구성 설정에는 업데이트할 구성 요소가 포함되어 있습니다. 필드는 다음과 같습니다.

  • 구성 요소의 이름입니다.The name of the component. 유효한 설정은 bios 또는 bmc 입니다.
  • URL: 구성 요소의 펌웨어 사양 및 버전의 URL입니다.

3.15.2. HostFirmwareComponents 상태
링크 복사

HostFirmwareComponents 리소스의 status 섹션은 호스트의 BIOS 및 BMC 버전의 현재 상태를 반환합니다.

Expand
표 3.6. HostFirmwareComponents 상태
매개 변수설명
components:
  component:
  initialVersion:
  currentVersion:
  lastVersionFlashed:
  updatedAt:
Copy to Clipboard Toggle word wrap

components 섹션에는 구성 요소의 상태가 포함되어 있습니다. 필드는 다음과 같습니다.

  • component: 펌웨어 구성 요소의 이름입니다. bios 또는 bmc 를 반환합니다.
  • initialVersion: 구성 요소의 초기 펌웨어 버전입니다. Ironic은 BareMetalHost 리소스를 생성할 때 이 정보를 검색합니다. 변경할 수 없습니다.
  • CurrentVersion - 구성 요소의 현재 펌웨어 버전입니다. 처음에는 Ironic이 베어 메탈 호스트의 펌웨어를 업데이트할 때까지 initialVersion 값과 일치합니다.
  • lastVersionFlashed: 베어 메탈 호스트에서 플래시된 구성 요소의 마지막 펌웨어 버전입니다. 이 필드는 Ironic이 펌웨어를 업데이트할 때까지 null 을 반환합니다.
  • updatedAt: Ironic에서 베어 메탈 호스트의 펌웨어를 업데이트한 타임스탬프입니다. 
updates:
  component:
  url:
Copy to Clipboard Toggle word wrap

업데이트 구성 설정에는 업데이트된 구성 요소가 포함되어 있습니다. 필드는 다음과 같습니다.

  • 구성 요소의 이름입니다.The name of the component.
  • URL: 구성 요소의 펌웨어 사양 및 버전의 URL입니다.

3.16. HostFirmwareComponents 리소스 가져오기
링크 복사

HostFirmwareComponents 리소스에는 물리적 호스트의 BIOS 및 BMC(Baseboard Management Controller)의 특정 펌웨어 버전이 포함되어 있습니다. 펌웨어 버전 및 상태를 검토하려면 물리적 호스트의 HostFirmwareComponents 리소스를 가져와야 합니다.

프로세스

  1. HostFirmwareComponents 리소스의 자세한 목록을 가져옵니다. 

    $ oc get hostfirmwarecomponents -n openshift-machine-api -o yaml
    Copy to Clipboard Toggle word wrap

  2. HostFirmwareComponents 리소스 목록을 가져옵니다. 

    $ oc get hostfirmwarecomponents -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

  3. 특정 호스트에 대한 HostFirmwareComponents 리소스를 가져옵니다. 

    $ oc get hostfirmwarecomponents <host_name> -n openshift-machine-api -o yaml
    Copy to Clipboard Toggle word wrap

    여기서 <host_name >은 호스트의 이름입니다.

    출력 예

    ---
apiVersion: metal3.io/v1alpha1
kind: HostFirmwareComponents
metadata:
  creationTimestamp: 2024-04-25T20:32:06Z"
  generation: 1
  name: ostest-master-2
  namespace: openshift-machine-api
  ownerReferences:
  - apiVersion: metal3.io/v1alpha1
    blockOwnerDeletion: true
    controller: true
    kind: BareMetalHost
    name: ostest-master-2
    uid: 16022566-7850-4dc8-9e7d-f216211d4195
  resourceVersion: "2437"
  uid: 2038d63f-afc0-4413-8ffe-2f8e098d1f6c
spec:
  updates: []
status:
  components:
  - component: bios
    currentVersion: 1.0.0
    initialVersion: 1.0.0
  - component: bmc
    currentVersion: "1.00"
    initialVersion: "1.00"
  conditions:
  - lastTransitionTime: "2024-04-25T20:32:06Z"
    message: ""
    observedGeneration: 1
    reason: OK
    status: "True"
    type: Valid
  - lastTransitionTime: "2024-04-25T20:32:06Z"
    message: ""
    observedGeneration: 1
    reason: OK
    status: "False"
    type: ChangeDetected
  lastUpdated: "2024-04-25T20:32:06Z"
  updates: []
    Copy to Clipboard Toggle word wrap

3.17. HostFirmwareComponents 리소스 편집
링크 복사

노드의 HostFirmwareComponents 리소스를 편집할 수 있습니다.

프로세스

  1. HostFirmwareComponents 리소스의 자세한 목록을 가져옵니다. 

    $ oc get hostfirmwarecomponents -n openshift-machine-api -o yaml
    Copy to Clipboard Toggle word wrap

  2. 호스트의 HostFirmwareComponents 리소스를 편집합니다. 

    $ oc edit <host_name> hostfirmwarecomponents -n openshift-machine-api
    1
    Copy to Clipboard Toggle word wrap
    1
    여기서 <host_name >은 호스트의 이름입니다. HostFirmwareComponents 리소스가 터미널의 기본 편집기에서 열립니다.

    출력 예

    ---
apiVersion: metal3.io/v1alpha1
kind: HostFirmwareComponents
metadata:
  creationTimestamp: 2024-04-25T20:32:06Z"
  generation: 1
  name: ostest-master-2
  namespace: openshift-machine-api
  ownerReferences:
  - apiVersion: metal3.io/v1alpha1
    blockOwnerDeletion: true
    controller: true
    kind: BareMetalHost
    name: ostest-master-2
    uid: 16022566-7850-4dc8-9e7d-f216211d4195
  resourceVersion: "2437"
  uid: 2038d63f-afc0-4413-8ffe-2f8e098d1f6c
spec:
  updates:
    - name: bios
    1 
    
      url: https://myurl.with.firmware.for.bios
    2 
    
    - name: bmc
    3 
    
      url: https://myurl.with.firmware.for.bmc
    4 
    
status:
  components:
  - component: bios
    currentVersion: 1.0.0
    initialVersion: 1.0.0
  - component: bmc
    currentVersion: "1.00"
    initialVersion: "1.00"
  conditions:
  - lastTransitionTime: "2024-04-25T20:32:06Z"
    message: ""
    observedGeneration: 1
    reason: OK
    status: "True"
    type: Valid
  - lastTransitionTime: "2024-04-25T20:32:06Z"
    message: ""
    observedGeneration: 1
    reason: OK
    status: "False"
    type: ChangeDetected
  lastUpdated: "2024-04-25T20:32:06Z"
    Copy to Clipboard Toggle word wrap

    1
    BIOS 버전을 설정하려면 name 속성을 bios 로 설정합니다.
    2
    BIOS 버전을 설정하려면 url 속성을 BIOS의 펌웨어 버전의 URL로 설정합니다.
    3
    BMC 버전을 설정하려면 name 속성을 bmc 로 설정합니다.
    4
    BMC 버전을 설정하려면 BMC의 펌웨어 확인 URL로 url 속성을 설정합니다.
  3. 변경 사항을 저장하고 편집기를 종료합니다.

  4. 호스트의 시스템 이름을 가져옵니다. 

    $ oc get bmh <host_name> -n openshift-machine name
    1
    Copy to Clipboard Toggle word wrap
    1
    여기서 <host_name >은 호스트의 이름입니다. 시스템 이름은 CONSUMER 필드에 표시됩니다.

  5. 머신 세트에서 삭제하려면 머신에 주석을 답니다. 

    $ oc annotate machine <machine_name> machine.openshift.io/delete-machine=true -n openshift-machine-api
    1
    Copy to Clipboard Toggle word wrap
    1
    여기서 <machine_name >은 삭제할 머신의 이름입니다.

  6. 노드 목록을 가져오고 작업자 노드 수를 계산합니다. 

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

  7. 머신 세트를 가져옵니다. 

    $ oc get machinesets -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

  8. 머신 세트를 스케일링합니다. 

    $ oc scale machineset <machineset_name> -n openshift-machine-api --replicas=<n-1>
    1
    Copy to Clipboard Toggle word wrap
    1
    여기서 <machineset_name >은 머신 세트의 이름이며 < n-1 >은 감소된 작업자 노드 수입니다.

  9. 호스트가 Available 상태가 되면 HostFirmwareComponents 리소스 변경 사항이 적용되도록 시스템 세트를 확장합니다. 

    $ oc scale machineset <machineset_name> -n openshift-machine-api --replicas=<n>
    1
    Copy to Clipboard Toggle word wrap
    1
    여기서 <machineset_name >은 머신 세트의 이름이며 < n >은 작업자 노드 수입니다.

4장. OpenShift 클러스터에서 다중 아키텍처 컴퓨팅 머신 구성
링크 복사

4.1. 다중 아키텍처 컴퓨팅 머신이 있는 클러스터 정보
링크 복사

다중 아키텍처 컴퓨팅 머신이 있는 OpenShift Container Platform 클러스터는 다양한 아키텍처가 있는 컴퓨팅 머신을 지원하는 클러스터입니다.

다중 아키텍처 컴퓨팅 머신 구성에는 몇 가지 추가 고려 사항이 포함됩니다.

  • 클러스터에 여러 아키텍처가 있는 노드가 있는 경우 노드에 배포하는 컨테이너 이미지의 아키텍처는 해당 노드의 아키텍처와 일치해야 합니다. Pod가 적절한 아키텍처가 있고 컨테이너 이미지 아키텍처와 일치하는지 확인해야 합니다. 노드에 Pod를 할당하는 방법에 대한 자세한 내용은 노드에 Pod 할당을 참조하십시오.
  • 설치 프로그램에서 제공하는 설치에서는 단일 클라우드 공급자가 제공하는 인프라를 사용하도록 제한됩니다. 아키텍처에 관계없이 외부 노드를 이러한 클러스터에 추가하는 것은 지원되지 않습니다.

  • 플랫폼 유형 없음 으로 설치된 클러스터는 Machine API로 컴퓨팅 머신 관리와 같은 일부 기능을 사용할 수 없습니다. 이 제한은 클러스터에 연결된 컴퓨팅 시스템이 일반적으로 기능을 지원하는 플랫폼에 설치된 경우에도 적용됩니다. 설치 후에는 이 매개변수를 변경할 수 없습니다.

    중요

    가상화 또는 클라우드 환경에서 OpenShift Container Platform 클러스터를 설치하기 전에 테스트되지 않은 플랫폼에 OpenShift Container Platform 배포 지침의 정보를 검토하십시오.

  • 다중 아키텍처 컴퓨팅 머신이 있는 클러스터에서는 Cluster Samples Operator가 지원되지 않습니다. 이 기능 없이 클러스터를 생성할 수 있습니다. 자세한 내용은 클러스터 기능을 참조하십시오.
  • 단일 아키텍처 클러스터를 다중 아키텍처 컴퓨팅 머신을 지원하는 클러스터로 마이그레이션하는 방법에 대한 자세한 내용은 다중 아키텍처 컴퓨팅 머신이 있는 클러스터로 마이그레이션 을 참조하십시오.

4.1.1. 다중 아키텍처 컴퓨팅 머신으로 클러스터 구성
링크 복사

다양한 설치 옵션 및 플랫폼이 있는 다중 아키텍처 컴퓨팅 머신으로 클러스터를 생성하려면 다음 표의 문서를 사용할 수 있습니다.

Expand
표 4.1. 다중 아키텍처 컴퓨팅 머신 설치 옵션이 있는 클러스터
문서 섹션플랫폼사용자 프로비저닝 설치설치 프로그램에서 제공하는 설치컨트롤 플레인컴퓨팅 노드

Azure에서 다중 아키텍처 컴퓨팅 머신이 있는 클러스터 생성

Microsoft Azure

✓

✓

aarch64 또는 x86_64

aarch64, x86_64

AWS에서 다중 아키텍처 컴퓨팅 시스템을 사용하여 클러스터 생성

AWS(Amazon Web Services)

✓

✓

aarch64 또는 x86_64

aarch64, x86_64

Google Cloud에서 다중 아키텍처 컴퓨팅 시스템을 사용하여 클러스터 생성

Google Cloud

 

✓

aarch64 또는 x86_64

aarch64, x86_64

베어 메탈, IBM Power 또는 IBM Z에서 다중 아키텍처 컴퓨팅 머신으로 클러스터 생성

베어 메탈

✓

 

aarch64 또는 x86_64

aarch64, x86_64

IBM Power

✓

 

x86_64 또는 ppc64le

x86_64, ppc64le

IBM Z

✓

 

x86_64 또는 s390x

x86_64, s390x

IBM Z® 및 IBM® LinuxONE에서 z/VM을 사용하여 다중 아키텍처 컴퓨팅 머신을 사용하여 클러스터 생성

IBM Z® 및 IBM® LinuxONE

✓

 

x86_64

x86_64, s390x

RHEL KVM을 사용하여 IBM Z® 및 IBM® LinuxONE에서 다중 아키텍처 컴퓨팅 머신으로 클러스터 생성

IBM Z® 및 IBM® LinuxONE

✓

 

x86_64

x86_64, s390x

IBM Power®에서 다중 아키텍처 컴퓨팅 머신이 있는 클러스터 생성

IBM Power®

✓

 

x86_64

x86_64, ppc64le

중요

현재 제로에서 자동 스케일링은 Google Cloud에서 지원되지 않습니다.

4.2. Azure에서 다중 아키텍처 컴퓨팅 머신으로 클러스터 생성
링크 복사

다중 아키텍처 컴퓨팅 머신이 있는 Azure 클러스터를 배포하려면 먼저 다중 아키텍처 설치 프로그램 바이너리를 사용하는 단일 아키텍처 Azure 설치 관리자 프로비저닝 클러스터를 생성해야 합니다. Azure 설치에 대한 자세한 내용은 사용자 지정을 사용하여 Azure에 클러스터 설치를 참조하십시오.

단일 아키텍처 컴퓨팅 머신이 있는 현재 클러스터를 다중 아키텍처 컴퓨팅 머신이 있는 클러스터로 마이그레이션할 수도 있습니다. 자세한 내용은 다중 아키텍처 컴퓨팅 머신이 있는 클러스터로 마이그레이션 을 참조하십시오.

다중 아키텍처 클러스터를 생성한 후 다양한 아키텍처가 있는 노드를 클러스터에 추가할 수 있습니다.

4.2.1. 클러스터 호환성 확인
링크 복사

다른 아키텍처의 컴퓨팅 노드를 클러스터에 추가하려면 먼저 클러스터가 다중 아키텍처 호환인지 확인해야 합니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.

프로세스

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

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

    $ oc adm release info -o jsonpath="{ .metadata.metadata}"
    Copy to Clipboard Toggle word wrap

검증

  • 다음 출력이 표시되면 클러스터에서 다중 아키텍처 페이로드를 사용하고 있습니다. 

    {
 "release.openshift.io/architecture": "multi",
 "url": "https://access.redhat.com/errata/<errata_version>"
}
    Copy to Clipboard Toggle word wrap

    그런 다음 클러스터에 다중 아키텍처 컴퓨팅 노드 추가를 시작할 수 있습니다.

  • 다음 출력이 표시되면 클러스터에서 다중 아키텍처 페이로드를 사용하지 않습니다. 

    {
 "url": "https://access.redhat.com/errata/<errata_version>"
}
    Copy to Clipboard Toggle word wrap
    중요

    클러스터가 다중 아키텍처 컴퓨팅 머신을 지원하도록 클러스터를 마이그레이션하려면 다중 아키텍처 컴퓨팅 머신이 있는 클러스터로 마이그레이션 절차를 따르십시오.

4.2.2. Azure 이미지 개요를 사용하여 64비트 ARM 부팅 이미지 생성
링크 복사

다음 절차에서는 64비트 ARM 부팅 이미지를 수동으로 생성하는 방법을 설명합니다.

사전 요구 사항

  • Azure CLI(az)를 설치했습니다.
  • 다중 아키텍처 설치 프로그램 바이너리를 사용하여 단일 아키텍처 Azure 설치 관리자 프로비저닝 클러스터를 생성했습니다.

프로세스

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

    $ az login
    Copy to Clipboard Toggle word wrap

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

    $ az storage account create -n ${STORAGE_ACCOUNT_NAME} -g ${RESOURCE_GROUP} -l westus --sku Standard_LRS
    1
    Copy to Clipboard Toggle word wrap
    1
    westus 오브젝트는 예제 영역입니다.

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

    $ az storage container create -n ${CONTAINER_NAME} --account-name ${STORAGE_ACCOUNT_NAME}
    Copy to Clipboard Toggle word wrap

  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')
      Copy to Clipboard Toggle word wrap

    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
      Copy to Clipboard Toggle word wrap

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

    $ end=`date -u -d "30 minutes" '+%Y-%m-%dT%H:%MZ'`
    Copy to Clipboard Toggle word wrap 
    $ sas=`az storage container generate-sas -n ${CONTAINER_NAME} --account-name ${STORAGE_ACCOUNT_NAME} --https-only --permissions dlrw --expiry $end -o tsv`
    Copy to Clipboard Toggle word wrap

  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}
    Copy to Clipboard Toggle word wrap

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

    $ az storage blob show -c ${CONTAINER_NAME} -n ${BLOB_NAME} --account-name ${STORAGE_ACCOUNT_NAME} | jq .properties.copy
    Copy to Clipboard Toggle word wrap

    출력 예

    {
 "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
}
    Copy to Clipboard Toggle word wrap

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

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

    $ az sig create --resource-group ${RESOURCE_GROUP} --gallery-name ${GALLERY_NAME}
    Copy to Clipboard Toggle word wrap

    이미지 모음을 사용하여 이미지 정의를 만듭니다. 다음 예제 명령에서 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
    Copy to Clipboard Toggle word wrap

  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)
    Copy to Clipboard Toggle word wrap

  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}
    Copy to Clipboard Toggle word wrap

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

    $ az sig image-version show -r $GALLERY_NAME -g $RESOURCE_GROUP -i rhcos-arm64 -e 1.0.0
    Copy to Clipboard Toggle word wrap

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

    resourceID예

    /resourceGroups/${RESOURCE_GROUP}/providers/Microsoft.Compute/galleries/${GALLERY_NAME}/images/rhcos-arm64/versions/1.0.0
    Copy to Clipboard Toggle word wrap

4.2.3. Azure 이미지 관리자를 사용하여 64비트 x86 부팅 이미지 생성
링크 복사

다음 절차에서는 64비트 x86 부팅 이미지를 수동으로 생성하는 방법을 설명합니다.

사전 요구 사항

  • Azure CLI(az)를 설치했습니다.
  • 다중 아키텍처 설치 프로그램 바이너리를 사용하여 단일 아키텍처 Azure 설치 관리자 프로비저닝 클러스터를 생성했습니다.

프로세스

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

    $ az login
    Copy to Clipboard Toggle word wrap

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

    $ az storage account create -n ${STORAGE_ACCOUNT_NAME} -g ${RESOURCE_GROUP} -l westus --sku Standard_LRS
    1
    Copy to Clipboard Toggle word wrap
    1
    westus 오브젝트는 예제 영역입니다.

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

    $ az storage container create -n ${CONTAINER_NAME} --account-name ${STORAGE_ACCOUNT_NAME}
    Copy to Clipboard Toggle word wrap

  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')
      Copy to Clipboard Toggle word wrap

    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
      Copy to Clipboard Toggle word wrap

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

    $ end=`date -u -d "30 minutes" '+%Y-%m-%dT%H:%MZ'`
    Copy to Clipboard Toggle word wrap 
    $ sas=`az storage container generate-sas -n ${CONTAINER_NAME} --account-name ${STORAGE_ACCOUNT_NAME} --https-only --permissions dlrw --expiry $end -o tsv`
    Copy to Clipboard Toggle word wrap

  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}
    Copy to Clipboard Toggle word wrap

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

    $ az storage blob show -c ${CONTAINER_NAME} -n ${BLOB_NAME} --account-name ${STORAGE_ACCOUNT_NAME} | jq .properties.copy
    Copy to Clipboard Toggle word wrap

    출력 예

    {
 "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
}
    Copy to Clipboard Toggle word wrap

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

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

    $ az sig create --resource-group ${RESOURCE_GROUP} --gallery-name ${GALLERY_NAME}
    Copy to Clipboard Toggle word wrap

  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
    Copy to Clipboard Toggle word wrap

    이 예제 명령에서 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)
    Copy to Clipboard Toggle word wrap

  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}
    Copy to Clipboard Toggle word wrap

    이 예에서 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
    Copy to Clipboard Toggle word wrap

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

    resourceID예

    /resourceGroups/${RESOURCE_GROUP}/providers/Microsoft.Compute/galleries/${GALLERY_NAME}/images/rhcos-x86_64/versions/1.0.0
    Copy to Clipboard Toggle word wrap

4.2.4. Azure 클러스터에 다중 아키텍처 컴퓨팅 머신 세트 추가
링크 복사

다중 아키텍처 클러스터를 생성한 후 다른 아키텍처로 노드를 추가할 수 있습니다.

다음과 같은 방법으로 다중 아키텍처 컴퓨팅 머신을 다중 아키텍처 클러스터에 추가할 수 있습니다.

  • 64비트 ARM 컨트롤 플레인 시스템을 사용하고 이미 64비트 ARM 컴퓨팅 시스템을 포함하는 클러스터에 64비트 x86 컴퓨팅 시스템을 추가합니다. 이 경우 64비트 x86은 보조 아키텍처로 간주됩니다.
  • 64비트 x86 컨트롤 플레인 시스템을 사용하고 이미 64비트 x86 컴퓨팅 시스템을 포함하는 클러스터에 64비트 ARM 컴퓨팅 머신을 추가합니다. 이 경우 64비트 ARM은 보조 아키텍처로 간주됩니다.

Azure에서 사용자 지정 컴퓨팅 머신 세트를 생성하려면 "Azure에서 컴퓨팅 머신 세트 생성"을 참조하십시오.

참고

클러스터에 보조 아키텍처 노드를 추가하기 전에 Multiarch Tuning Operator를 설치하고 ClusterPodPlacementConfig 사용자 정의 리소스를 배포하는 것이 좋습니다. 자세한 내용은 "Multiarch Tuning Operator를 사용하여 다중 아키텍처 클러스터에서 워크로드 관리"를 참조하십시오.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • 64비트 ARM 또는 64비트 x86 부팅 이미지를 생성하셨습니다.
  • 설치 프로그램을 사용하여 다중 아키텍처 설치 프로그램 바이너리를 사용하여 64비트 ARM 또는 64비트 x86 단일 아키텍처 Azure 클러스터를 생성했습니다.

프로세스

  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>"
    Copy to Clipboard Toggle word wrap

    1
    resourceID 매개변수를 arm64 또는 amd64 부팅 이미지로 설정합니다.
    2
    vmSize 매개변수를 설치에 사용되는 인스턴스 유형으로 설정합니다. 일부 인스턴스 유형은 Standard_D4ps_v5 또는 D8ps 입니다.

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

    $ oc create -f <file_name>
    1
    Copy to Clipboard Toggle word wrap
    1
    & lt;file_name >을 YAML 파일의 이름으로 컴퓨팅 머신 세트 구성으로 바꿉니다. 예: arm64-machine-set-0.yaml 또는 amd64-machine-set-0.yaml.

검증

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

    $ oc get machineset -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

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

    출력 예

    NAME                                                DESIRED  CURRENT  READY  AVAILABLE  AGE
<infrastructure_id>-machine-set-0                   2        2      2          2  10m
    Copy to Clipboard Toggle word wrap

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

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

4.3. AWS에서 다중 아키텍처 컴퓨팅 시스템을 사용하여 클러스터 생성
링크 복사

다중 아키텍처 컴퓨팅 머신이 있는 AWS 클러스터를 생성하려면 먼저 다중 아키텍처 설치 프로그램 바이너리를 사용하여 단일 아키텍처 AWS 설치 관리자 프로비저닝 클러스터를 생성해야 합니다. AWS 설치에 대한 자세한 내용은 사용자 지정을 사용하여 AWS에 클러스터 설치를 참조하십시오.

단일 아키텍처 컴퓨팅 머신이 있는 현재 클러스터를 다중 아키텍처 컴퓨팅 머신이 있는 클러스터로 마이그레이션할 수도 있습니다. 자세한 내용은 다중 아키텍처 컴퓨팅 머신이 있는 클러스터로 마이그레이션 을 참조하십시오.

다중 아키텍처 클러스터를 생성한 후 다양한 아키텍처가 있는 노드를 클러스터에 추가할 수 있습니다.

4.3.1. 클러스터 호환성 확인
링크 복사

다른 아키텍처의 컴퓨팅 노드를 클러스터에 추가하려면 먼저 클러스터가 다중 아키텍처 호환인지 확인해야 합니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.

프로세스

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

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

    $ oc adm release info -o jsonpath="{ .metadata.metadata}"
    Copy to Clipboard Toggle word wrap

검증

  • 다음 출력이 표시되면 클러스터에서 다중 아키텍처 페이로드를 사용하고 있습니다. 

    {
 "release.openshift.io/architecture": "multi",
 "url": "https://access.redhat.com/errata/<errata_version>"
}
    Copy to Clipboard Toggle word wrap

    그런 다음 클러스터에 다중 아키텍처 컴퓨팅 노드 추가를 시작할 수 있습니다.

  • 다음 출력이 표시되면 클러스터에서 다중 아키텍처 페이로드를 사용하지 않습니다. 

    {
 "url": "https://access.redhat.com/errata/<errata_version>"
}
    Copy to Clipboard Toggle word wrap
    중요

    클러스터가 다중 아키텍처 컴퓨팅 머신을 지원하도록 클러스터를 마이그레이션하려면 다중 아키텍처 컴퓨팅 머신이 있는 클러스터로 마이그레이션 절차를 따르십시오.

4.3.2. AWS 클러스터에 다중 아키텍처 컴퓨팅 머신 세트 추가
링크 복사

다중 아키텍처 클러스터를 생성한 후 다른 아키텍처로 노드를 추가할 수 있습니다.

다음과 같은 방법으로 다중 아키텍처 컴퓨팅 머신을 다중 아키텍처 클러스터에 추가할 수 있습니다.

  • 64비트 ARM 컨트롤 플레인 시스템을 사용하고 이미 64비트 ARM 컴퓨팅 시스템을 포함하는 클러스터에 64비트 x86 컴퓨팅 시스템을 추가합니다. 이 경우 64비트 x86은 보조 아키텍처로 간주됩니다.
  • 64비트 x86 컨트롤 플레인 시스템을 사용하고 이미 64비트 x86 컴퓨팅 시스템을 포함하는 클러스터에 64비트 ARM 컴퓨팅 머신을 추가합니다. 이 경우 64비트 ARM은 보조 아키텍처로 간주됩니다.
참고

클러스터에 보조 아키텍처 노드를 추가하기 전에 Multiarch Tuning Operator를 설치하고 ClusterPodPlacementConfig 사용자 정의 리소스를 배포하는 것이 좋습니다. 자세한 내용은 "Multiarch Tuning Operator를 사용하여 다중 아키텍처 클러스터에서 워크로드 관리"를 참조하십시오.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • 설치 프로그램을 사용하여 다중 아키텍처 설치 프로그램 바이너리를 사용하여 64비트 ARM 또는 64비트 x86 단일 아키텍처 AWS 클러스터를 생성했습니다.

프로세스

  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
    Copy to Clipboard Toggle word wrap

    1 2 3 9 13 14
    클러스터를 프로비저닝할 때 설정한 클러스터 ID를 기반으로 하는 인프라 ID를 지정합니다. OpenShift CLI (oc) 패키지가 설치되어 있으면 다음 명령을 실행하여 인프라 ID를 얻을 수 있습니다. 
    $ oc get -o jsonpath="{.status.infrastructureName}{'\n'}" infrastructure cluster
    Copy to Clipboard Toggle word wrap
    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'
    Copy to Clipboard Toggle word wrap
    10
    선택한 AMI의 CPU 아키텍처에 맞는 머신 유형을 지정합니다. 자세한 내용은 "AWS 64비트 ARM용 테스트 인스턴스 유형"을 참조하십시오.
    11
    영역을 지정합니다. 예를 들면 us-east-1a 입니다. 선택한 영역에 필요한 아키텍처가 있는 시스템이 있는지 확인합니다.
    12
    리전을 지정합니다. 예를 들면 us-east-1 입니다. 선택한 영역에 필요한 아키텍처가 있는 시스템이 있는지 확인합니다.

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

    $ oc create -f <file_name>
    1
    Copy to Clipboard Toggle word wrap
    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
    Copy to Clipboard Toggle word wrap

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

    출력 예

    NAME                                                DESIRED  CURRENT  READY  AVAILABLE  AGE
<infrastructure_id>-aws-machine-set-0                   2        2      2          2  10m
    Copy to Clipboard Toggle word wrap

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

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

다중 아키텍처 컴퓨팅 머신이 포함된 Google Cloud 클러스터를 생성하려면 먼저 다중 아키텍처 설치 프로그램 설치 프로그램 바이너리를 사용하여 단일 아키텍처 Google Cloud 설치 관리자 프로비저닝 클러스터를 생성해야 합니다. AWS 설치에 대한 자세한 내용은 사용자 지정을 사용하여 Google Cloud에 클러스터 설치를 참조하십시오.

단일 아키텍처 컴퓨팅 머신이 있는 현재 클러스터를 다중 아키텍처 컴퓨팅 머신이 있는 클러스터로 마이그레이션할 수도 있습니다. 자세한 내용은 다중 아키텍처 컴퓨팅 머신이 있는 클러스터로 마이그레이션 을 참조하십시오.

다중 아키텍처 클러스터를 생성한 후 다양한 아키텍처가 있는 노드를 클러스터에 추가할 수 있습니다.

참고

보안 부팅은 현재 Google Cloud용 64비트 ARM 머신에서 지원되지 않습니다.

4.4.1. 클러스터 호환성 확인
링크 복사

다른 아키텍처의 컴퓨팅 노드를 클러스터에 추가하려면 먼저 클러스터가 다중 아키텍처 호환인지 확인해야 합니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.

프로세스

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

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

    $ oc adm release info -o jsonpath="{ .metadata.metadata}"
    Copy to Clipboard Toggle word wrap

검증

  • 다음 출력이 표시되면 클러스터에서 다중 아키텍처 페이로드를 사용하고 있습니다. 

    {
 "release.openshift.io/architecture": "multi",
 "url": "https://access.redhat.com/errata/<errata_version>"
}
    Copy to Clipboard Toggle word wrap

    그런 다음 클러스터에 다중 아키텍처 컴퓨팅 노드 추가를 시작할 수 있습니다.

  • 다음 출력이 표시되면 클러스터에서 다중 아키텍처 페이로드를 사용하지 않습니다. 

    {
 "url": "https://access.redhat.com/errata/<errata_version>"
}
    Copy to Clipboard Toggle word wrap
    중요

    클러스터가 다중 아키텍처 컴퓨팅 머신을 지원하도록 클러스터를 마이그레이션하려면 다중 아키텍처 컴퓨팅 머신이 있는 클러스터로 마이그레이션 절차를 따르십시오.

4.4.2. Google Cloud 클러스터에 다중 아키텍처 컴퓨팅 머신 세트 추가
링크 복사

다중 아키텍처 클러스터를 생성한 후 다른 아키텍처로 노드를 추가할 수 있습니다.

다음과 같은 방법으로 다중 아키텍처 컴퓨팅 머신을 다중 아키텍처 클러스터에 추가할 수 있습니다.

  • 64비트 ARM 컨트롤 플레인 시스템을 사용하고 이미 64비트 ARM 컴퓨팅 시스템을 포함하는 클러스터에 64비트 x86 컴퓨팅 시스템을 추가합니다. 이 경우 64비트 x86은 보조 아키텍처로 간주됩니다.
  • 64비트 x86 컨트롤 플레인 시스템을 사용하고 이미 64비트 x86 컴퓨팅 시스템을 포함하는 클러스터에 64비트 ARM 컴퓨팅 머신을 추가합니다. 이 경우 64비트 ARM은 보조 아키텍처로 간주됩니다.
참고

클러스터에 보조 아키텍처 노드를 추가하기 전에 Multiarch Tuning Operator를 설치하고 ClusterPodPlacementConfig 사용자 정의 리소스를 배포하는 것이 좋습니다. 자세한 내용은 "Multiarch Tuning Operator를 사용하여 다중 아키텍처 클러스터에서 워크로드 관리"를 참조하십시오.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • 설치 프로그램을 사용하여 다중 아키텍처 설치 프로그램 바이너리를 사용하여 64비트 x86 또는 64비트 ARM 단일 아키텍처 Google Cloud 클러스터를 생성했습니다.

프로세스

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

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

    Google Cloud 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
    Copy to Clipboard Toggle word wrap

    1
    클러스터를 프로비저닝할 때 설정한 클러스터 ID를 기반으로 하는 인프라 ID를 지정합니다. 다음 명령을 실행하여 인프라 ID를 가져올 수 있습니다. 
    $ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster
    Copy to Clipboard Toggle word wrap
    2
    추가할 역할 노드 레이블을 지정합니다.
    3
    현재 컴퓨팅 머신 세트에 사용되는 이미지의 경로를 지정합니다. 이미지 경로에 프로젝트 및 이미지 이름이 필요합니다.

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

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

    출력 예

      "gcp": {
    "release": "415.92.202309142014-0",
    "project": "rhcos-cloud",
    "name": "rhcos-415-92-202309142014-0-gcp-aarch64"
  }
    Copy to Clipboard Toggle word wrap

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

    $ projects/<project>/global/images/<image_name>
    Copy to Clipboard Toggle word wrap
    4
    선택 사항: key:value 쌍 형식으로 사용자 지정 메타데이터를 지정합니다. 사용 사례의 예는 사용자 지정 메타데이터 설정에 대한 Google Cloud 설명서를 참조하십시오.
    5
    선택한 OS 이미지의 CPU 아키텍처에 맞는 머신 유형을 지정합니다. 자세한 내용은 "64비트 ARM 인프라에서 Google Cloud용 인스턴스 유형 테스트"을 참조하십시오.
    6
    클러스터에 사용하는 Google Cloud 프로젝트의 이름을 지정합니다.
    7
    리전을 지정합니다. 예를 들면 us-central1 입니다. 선택한 영역에 필요한 아키텍처가 있는 시스템이 있는지 확인합니다.

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

    $ oc create -f <file_name>
    1
    Copy to Clipboard Toggle word wrap
    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
    Copy to Clipboard Toggle word wrap

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

    출력 예

    NAME                                                DESIRED  CURRENT  READY  AVAILABLE  AGE
<infrastructure_id>-gcp-machine-set-0                   2        2      2          2  10m
    Copy to Clipboard Toggle word wrap

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

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

추가 리소스

베어 메탈(x86_64 또는 aarch64), IBM Power® (ppc64le), 또는 IBM Z® (s390x)에서 다중 아키텍처 컴퓨팅 머신이 있는 클러스터를 생성하려면 이러한 플랫폼 중 하나에 기존 단일 아키텍처 클러스터가 있어야 합니다. 플랫폼의 설치 절차를 따르십시오.

중요

베어 메탈 설치 관리자 프로비저닝 인프라 및 Bare Metal Operator는 초기 클러스터 설정 중에 보조 아키텍처 노드 추가를 지원하지 않습니다. 초기 클러스터 설정 후에만 보조 아키텍처 노드를 수동으로 추가할 수 있습니다.

클러스터에 컴퓨팅 노드를 추가하려면 먼저 다중 아키텍처 페이로드를 사용하는 클러스터로 클러스터를 업그레이드해야 합니다. 다중 아키텍처 페이로드로 마이그레이션하는 방법에 대한 자세한 내용은 다중 아키텍처 컴퓨팅 머신이 있는 클러스터로 마이그레이션 을 참조하십시오.

다음 절차에서는 ISO 이미지 또는 네트워크 PXE 부팅을 사용하여 RHCOS 컴퓨팅 머신을 생성하는 방법을 설명합니다. 이를 통해 클러스터에 노드를 추가하고 다중 아키텍처 컴퓨팅 머신이 있는 클러스터를 배포할 수 있습니다.

참고

보조 아키텍처 노드를 클러스터에 추가하기 전에 Multiarch Tuning Operator를 설치하고 ClusterPodPlacementConfig 오브젝트를 배포하는 것이 좋습니다. 자세한 내용은 Multiarch Tuning Operator를 사용하여 다중 아키텍처 클러스터에서 워크로드 관리를 참조하십시오.

4.5.1. 클러스터 호환성 확인
링크 복사

다른 아키텍처의 컴퓨팅 노드를 클러스터에 추가하려면 먼저 클러스터가 다중 아키텍처 호환인지 확인해야 합니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.

프로세스

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

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

    $ oc adm release info -o jsonpath="{ .metadata.metadata}"
    Copy to Clipboard Toggle word wrap

검증

  • 다음 출력이 표시되면 클러스터에서 다중 아키텍처 페이로드를 사용하고 있습니다. 

    {
 "release.openshift.io/architecture": "multi",
 "url": "https://access.redhat.com/errata/<errata_version>"
}
    Copy to Clipboard Toggle word wrap

    그런 다음 클러스터에 다중 아키텍처 컴퓨팅 노드 추가를 시작할 수 있습니다.

  • 다음 출력이 표시되면 클러스터에서 다중 아키텍처 페이로드를 사용하지 않습니다. 

    {
 "url": "https://access.redhat.com/errata/<errata_version>"
}
    Copy to Clipboard Toggle word wrap
    중요

    클러스터가 다중 아키텍처 컴퓨팅 머신을 지원하도록 클러스터를 마이그레이션하려면 다중 아키텍처 컴퓨팅 머신이 있는 클러스터로 마이그레이션 절차를 따르십시오.

4.5.2. ISO 이미지를 사용하여 RHCOS 머신 생성
링크 복사

ISO 이미지를 사용하여 머신을 생성함으로써 베어 메탈 클러스터에 대해 더 많은 Red Hat Enterprise Linux CoreOS (RHCOS) 컴퓨팅 머신을 생성할 수 있습니다.

사전 요구 사항

  • 클러스터의 컴퓨팅 머신에 대한 Ignition 구성 파일의 URL을 가져옵니다. 설치 중에 이 파일은 HTTP 서버에 업로드되어 있어야 합니다.
  • OpenShift CLI(oc)가 설치되어 있어야 합니다.

프로세스

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

    $ oc extract -n openshift-machine-api secret/worker-user-data-managed --keys=userData --to=- > worker.ign
    Copy to Clipboard Toggle word wrap
  2. 클러스터에서 내보낸 worker.ign Ignition 구성 파일을 HTTP 서버로 업로드합니다. 해당 파일의 URL을 기록해 둡니다.

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

    $ curl -k http://<HTTP_server>/worker.ign
    Copy to Clipboard Toggle word wrap

  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')
    Copy to Clipboard Toggle word wrap

  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>
    1
    2
    Copy to Clipboard Toggle word wrap
    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/worker.ign /dev/sda --ignition-hash=sha512-a5a2d43879223273c9b60af66b44202a1d1248fc01cf156c46d4a79f552b6bad47bc8cc78ddf0116e80c59d2ea9e32ba53bc807afbca581aa059311def2c3e3b
    Copy to Clipboard Toggle word wrap

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

    중요

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

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

4.5.3. PXE 또는 iPXE 부팅을 통해 RHCOS 머신 생성
링크 복사

PXE 또는 iPXE 부팅을 사용하여 베어 메탈 클러스터에 대해 추가 Red Hat Enterprise Linux CoreOS (RHCOS) 컴퓨팅 머신을 생성할 수 있습니다.

사전 요구 사항

  • 클러스터의 컴퓨팅 머신에 대한 Ignition 구성 파일의 URL을 가져옵니다. 설치 중에 이 파일은 HTTP 서버에 업로드되어 있어야 합니다.
  • 클러스터 설치 중에 HTTP 서버에 업로드 한 RHCOS ISO 이미지, 압축된 메탈 BIOS, kernel 및 initramfs 파일의 URL을 가져옵니다.
  • 설치 중에 OpenShift Container Platform 클러스터에 대한 머신을 생성하는 데 사용한 PXE 부팅 인프라에 액세스할 수 있습니다. RHCOS가 설치된 후 로컬 디스크에서 머신을 부팅해야합니다.
  • UEFI를 사용하는 경우 OpenShift Container Platform 설치 중에 수정 한 grub.conf 파일에 액세스할 수 있습니다.

프로세스

  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
      Copy to Clipboard Toggle word wrap
      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
      Copy to Clipboard Toggle word wrap
      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 
      
}
      Copy to Clipboard Toggle word wrap
      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 인프라를 사용하여 클러스터에 필요한 컴퓨팅 머신을 만듭니다.

4.5.4. 시스템의 인증서 서명 요청 승인
링크 복사

클러스터에 시스템을 추가하면 추가한 시스템별로 보류 중인 인증서 서명 요청(CSR)이 두 개씩 생성됩니다. 이러한 CSR이 승인되었는지 확인해야 하며, 필요한 경우 이를 직접 승인해야 합니다. 클라이언트 요청을 먼저 승인한 다음 서버 요청을 승인해야 합니다.

사전 요구 사항

  • 클러스터에 시스템을 추가했습니다.

프로세스

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

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME      STATUS    ROLES   AGE  VERSION
master-0  Ready     master  63m  v1.29.4
master-1  Ready     master  63m  v1.29.4
master-2  Ready     master  64m  v1.29.4
    Copy to Clipboard Toggle word wrap

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

    참고

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

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

    $ oc get csr
    Copy to Clipboard Toggle word wrap

    출력 예

    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
...
    Copy to Clipboard Toggle word wrap

    예에서는 두 시스템이 클러스터에 참여하고 있습니다. 목록에는 승인된 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
      Copy to Clipboard Toggle word wrap
      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
      Copy to Clipboard Toggle word wrap
      참고

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

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

    $ oc get csr
    Copy to Clipboard Toggle word wrap

    출력 예

    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
...
    Copy to Clipboard Toggle word wrap

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

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

      $ oc adm certificate approve <csr_name>
      1
      Copy to Clipboard Toggle word wrap
      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
      Copy to Clipboard Toggle word wrap

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

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME      STATUS    ROLES   AGE  VERSION
master-0  Ready     master  73m  v1.29.4
master-1  Ready     master  73m  v1.29.4
master-2  Ready     master  74m  v1.29.4
worker-0  Ready     worker  11m  v1.29.4
worker-1  Ready     worker  11m  v1.29.4
    Copy to Clipboard Toggle word wrap

    참고

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

추가 정보

IBM Z® 및 IBM® LinuxONE(s390x)에서 z/VM이 있는 다중 아키텍처 컴퓨팅 머신이 있는 클러스터를 생성하려면 기존 단일 아키텍처 x86_64 클러스터가 있어야 합니다. 그런 다음 s390x 컴퓨팅 머신을 OpenShift Container Platform 클러스터에 추가할 수 있습니다.

s390x 노드를 클러스터에 추가하려면 먼저 다중 아키텍처 페이로드를 사용하는 클러스터로 클러스터를 업그레이드해야 합니다. 다중 아키텍처 페이로드로 마이그레이션하는 방법에 대한 자세한 내용은 다중 아키텍처 컴퓨팅 머신이 있는 클러스터로 마이그레이션 을 참조하십시오.

다음 절차에서는 z/VM 인스턴스를 사용하여 RHCOS 컴퓨팅 머신을 생성하는 방법을 설명합니다. 이를 통해 클러스터에 s390x 노드를 추가하고 다중 아키텍처 컴퓨팅 머신이 있는 클러스터를 배포할 수 있습니다.

x86_64 에서 다중 아키텍처 컴퓨팅 머신이 있는 IBM Z® 또는 IBM® LinuxONE(s390x) 클러스터를 생성하려면 IBM Z® 및 IBM® LinuxONE에 클러스터 설치 지침을 따르십시오. 그런 다음 베어 메탈, IBM Power 또는 IBM Z에서 다중 아키텍처 컴퓨팅 머신을 사용하여 클러스터 생성에 설명된 대로 x86_64 컴퓨팅 머신을 추가할 수 있습니다.

참고

보조 아키텍처 노드를 클러스터에 추가하기 전에 Multiarch Tuning Operator를 설치하고 ClusterPodPlacementConfig 오브젝트를 배포하는 것이 좋습니다. 자세한 내용은 Multiarch Tuning Operator를 사용하여 다중 아키텍처 클러스터에서 워크로드 관리를 참조하십시오.

4.6.1. 클러스터 호환성 확인
링크 복사

다른 아키텍처의 컴퓨팅 노드를 클러스터에 추가하려면 먼저 클러스터가 다중 아키텍처 호환인지 확인해야 합니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.

프로세스

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

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

    $ oc adm release info -o jsonpath="{ .metadata.metadata}"
    Copy to Clipboard Toggle word wrap

검증

  • 다음 출력이 표시되면 클러스터에서 다중 아키텍처 페이로드를 사용하고 있습니다. 

    {
 "release.openshift.io/architecture": "multi",
 "url": "https://access.redhat.com/errata/<errata_version>"
}
    Copy to Clipboard Toggle word wrap

    그런 다음 클러스터에 다중 아키텍처 컴퓨팅 노드 추가를 시작할 수 있습니다.

  • 다음 출력이 표시되면 클러스터에서 다중 아키텍처 페이로드를 사용하지 않습니다. 

    {
 "url": "https://access.redhat.com/errata/<errata_version>"
}
    Copy to Clipboard Toggle word wrap
    중요

    클러스터가 다중 아키텍처 컴퓨팅 머신을 지원하도록 클러스터를 마이그레이션하려면 다중 아키텍처 컴퓨팅 머신이 있는 클러스터로 마이그레이션 절차를 따르십시오.

4.6.2. z/VM을 사용하여 IBM Z에서 RHCOS 머신 생성
링크 복사

IBM Z® with z/VM에서 실행되는 추가 RHCOS(Red Hat Enterprise Linux CoreOS) 컴퓨팅 머신을 기존 클러스터에 연결할 수 있습니다.

사전 요구 사항

  • 노드의 호스트 이름 및 역방향 조회를 수행할 수 있는 DNS(Domain Name Server)가 있습니다.
  • 생성한 머신에 액세스할 수 있는 프로비저닝 머신에서 HTTP 또는 HTTPS 서버가 실행되고 있습니다.

프로세스

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

    $ oc extract -n openshift-machine-api secret/worker-user-data-managed --keys=userData --to=- > worker.ign
    Copy to Clipboard Toggle word wrap
  2. 클러스터에서 내보낸 worker.ign Ignition 구성 파일을 HTTP 서버로 업로드합니다. 이 파일의 URL을 기록해 둡니다.

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

    $ curl -k http://<http_server>/worker.ign
    Copy to Clipboard Toggle word wrap

  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')
    Copy to Clipboard Toggle word wrap 
    $ 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')
    Copy to Clipboard Toggle word wrap 
    $ 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')
    Copy to Clipboard Toggle word wrap
  5. 다운로드한 RHEL 라이브 커널,initramfs 및 rootfs 파일을 추가하려는 RHCOS 게스트에서 액세스할 수 있는 HTTP 또는 HTTPS 서버로 이동합니다.

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

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

      1. 컴퓨터의 IP 주소
      2. 빈 문자열
      3. 게이트웨이
      4. 넷 마스크
      5. hostname.domainname 형식의 시스템 호스트 및 도메인 이름. 이 값을 생략하면 RHCOS는 역방향 DNS 조회를 통해 호스트 이름을 가져옵니다.
      6. 네트워크 인터페이스 이름. 이 값을 생략하면 RHCOS는 IP 구성을 사용 가능한 모든 인터페이스에 적용합니다.
      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
        Copy to Clipboard Toggle word wrap

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

    • 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
        Copy to Clipboard Toggle word wrap

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

  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
    Copy to Clipboard Toggle word wrap

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

4.6.3. 머신의 인증서 서명 요청 승인
링크 복사

클러스터에 시스템을 추가하면 추가한 시스템별로 보류 중인 인증서 서명 요청(CSR)이 두 개씩 생성됩니다. 이러한 CSR이 승인되었는지 확인해야 하며, 필요한 경우 이를 직접 승인해야 합니다. 클라이언트 요청을 먼저 승인한 다음 서버 요청을 승인해야 합니다.

사전 요구 사항

  • 클러스터에 시스템을 추가했습니다.

프로세스

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

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME      STATUS    ROLES   AGE  VERSION
master-0  Ready     master  63m  v1.29.4
master-1  Ready     master  63m  v1.29.4
master-2  Ready     master  64m  v1.29.4
    Copy to Clipboard Toggle word wrap

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

    참고

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

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

    $ oc get csr
    Copy to Clipboard Toggle word wrap

    출력 예

    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
...
    Copy to Clipboard Toggle word wrap

    예에서는 두 시스템이 클러스터에 참여하고 있습니다. 목록에는 승인된 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
      Copy to Clipboard Toggle word wrap
      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
      Copy to Clipboard Toggle word wrap
      참고

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

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

    $ oc get csr
    Copy to Clipboard Toggle word wrap

    출력 예

    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
...
    Copy to Clipboard Toggle word wrap

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

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

      $ oc adm certificate approve <csr_name>
      1
      Copy to Clipboard Toggle word wrap
      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
      Copy to Clipboard Toggle word wrap

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

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME      STATUS    ROLES   AGE  VERSION
master-0  Ready     master  73m  v1.29.4
master-1  Ready     master  73m  v1.29.4
master-2  Ready     master  74m  v1.29.4
worker-0  Ready     worker  11m  v1.29.4
worker-1  Ready     worker  11m  v1.29.4
    Copy to Clipboard Toggle word wrap

    참고

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

추가 정보

LPAR에서 IBM Z® 및 IBM® LinuxONE(s390x)에서 다중 아키텍처 컴퓨팅 머신이 있는 클러스터를 생성하려면 기존 단일 아키텍처 x86_64 클러스터가 있어야 합니다. 그런 다음 s390x 컴퓨팅 머신을 OpenShift Container Platform 클러스터에 추가할 수 있습니다.

s390x 노드를 클러스터에 추가하려면 먼저 다중 아키텍처 페이로드를 사용하는 클러스터로 클러스터를 업그레이드해야 합니다. 다중 아키텍처 페이로드로 마이그레이션하는 방법에 대한 자세한 내용은 다중 아키텍처 컴퓨팅 머신이 있는 클러스터로 마이그레이션 을 참조하십시오.

다음 절차에서는 LPAR 인스턴스를 사용하여 RHCOS 컴퓨팅 머신을 생성하는 방법을 설명합니다. 이를 통해 클러스터에 s390x 노드를 추가하고 다중 아키텍처 컴퓨팅 머신이 있는 클러스터를 배포할 수 있습니다.

참고

x86_64 에서 다중 아키텍처 컴퓨팅 머신이 있는 IBM Z® 또는 IBM® LinuxONE(s390x) 클러스터를 생성하려면 IBM Z® 및 IBM® LinuxONE에 클러스터 설치 지침을 따르십시오. 그런 다음 베어 메탈, IBM Power 또는 IBM Z에서 다중 아키텍처 컴퓨팅 머신을 사용하여 클러스터 생성에 설명된 대로 x86_64 컴퓨팅 머신을 추가할 수 있습니다.

4.7.1. 클러스터 호환성 확인
링크 복사

다른 아키텍처의 컴퓨팅 노드를 클러스터에 추가하려면 먼저 클러스터가 다중 아키텍처 호환인지 확인해야 합니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.

프로세스

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

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

    $ oc adm release info -o jsonpath="{ .metadata.metadata}"
    Copy to Clipboard Toggle word wrap

검증

  • 다음 출력이 표시되면 클러스터에서 다중 아키텍처 페이로드를 사용하고 있습니다. 

    {
 "release.openshift.io/architecture": "multi",
 "url": "https://access.redhat.com/errata/<errata_version>"
}
    Copy to Clipboard Toggle word wrap

    그런 다음 클러스터에 다중 아키텍처 컴퓨팅 노드 추가를 시작할 수 있습니다.

  • 다음 출력이 표시되면 클러스터에서 다중 아키텍처 페이로드를 사용하지 않습니다. 

    {
 "url": "https://access.redhat.com/errata/<errata_version>"
}
    Copy to Clipboard Toggle word wrap
    중요

    클러스터가 다중 아키텍처 컴퓨팅 머신을 지원하도록 클러스터를 마이그레이션하려면 다중 아키텍처 컴퓨팅 머신이 있는 클러스터로 마이그레이션 절차를 따르십시오.

4.7.2. LPAR에서 IBM Z에서 RHCOS 머신 생성
링크 복사

IBM Z®에서 실행되는 추가 RHCOS(Red Hat Enterprise Linux CoreOS) 컴퓨팅 머신을 생성하여 기존 클러스터에 연결할 수 있습니다.

사전 요구 사항

  • 노드의 호스트 이름 및 역방향 조회를 수행할 수 있는 DNS(Domain Name Server)가 있습니다.
  • 생성한 머신에 액세스할 수 있는 프로비저닝 머신에서 HTTP 또는 HTTPS 서버가 실행되고 있습니다.

프로세스

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

    $ oc extract -n openshift-machine-api secret/worker-user-data-managed --keys=userData --to=- > worker.ign
    Copy to Clipboard Toggle word wrap
  2. 클러스터에서 내보낸 worker.ign Ignition 구성 파일을 HTTP 서버로 업로드합니다. 이 파일의 URL을 기록해 둡니다.

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

    $ curl -k http://<http_server>/worker.ign
    Copy to Clipboard Toggle word wrap

  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')
    Copy to Clipboard Toggle word wrap 
    $ 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')
    Copy to Clipboard Toggle word wrap 
    $ 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')
    Copy to Clipboard Toggle word wrap
  5. 다운로드한 RHEL 라이브 커널,initramfs 및 rootfs 파일을 추가하려는 RHCOS 게스트에서 액세스할 수 있는 HTTP 또는 HTTPS 서버로 이동합니다.

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

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

      1. 컴퓨터의 IP 주소
      2. 빈 문자열
      3. 게이트웨이
      4. 넷 마스크
      5. hostname.domainname 형식의 시스템 호스트 및 도메인 이름. 이 값을 생략하면 RHCOS는 역방향 DNS 조회를 통해 호스트 이름을 가져옵니다.
      6. 네트워크 인터페이스 이름. 이 값을 생략하면 RHCOS는 IP 구성을 사용 가능한 모든 인터페이스에 적용합니다.
      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
        Copy to Clipboard Toggle word wrap

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

    • 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
        Copy to Clipboard Toggle word wrap

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

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

4.7.3. 시스템의 인증서 서명 요청 승인
링크 복사

클러스터에 시스템을 추가하면 추가한 시스템별로 보류 중인 인증서 서명 요청(CSR)이 두 개씩 생성됩니다. 이러한 CSR이 승인되었는지 확인해야 하며, 필요한 경우 이를 직접 승인해야 합니다. 클라이언트 요청을 먼저 승인한 다음 서버 요청을 승인해야 합니다.

사전 요구 사항

  • 클러스터에 시스템을 추가했습니다.

프로세스

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

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME      STATUS    ROLES   AGE  VERSION
master-0  Ready     master  63m  v1.29.4
master-1  Ready     master  63m  v1.29.4
master-2  Ready     master  64m  v1.29.4
    Copy to Clipboard Toggle word wrap

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

    참고

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

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

    $ oc get csr
    Copy to Clipboard Toggle word wrap

    출력 예

    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
...
    Copy to Clipboard Toggle word wrap

    예에서는 두 시스템이 클러스터에 참여하고 있습니다. 목록에는 승인된 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
      Copy to Clipboard Toggle word wrap
      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
      Copy to Clipboard Toggle word wrap
      참고

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

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

    $ oc get csr
    Copy to Clipboard Toggle word wrap

    출력 예

    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
...
    Copy to Clipboard Toggle word wrap

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

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

      $ oc adm certificate approve <csr_name>
      1
      Copy to Clipboard Toggle word wrap
      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
      Copy to Clipboard Toggle word wrap

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

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME      STATUS    ROLES   AGE  VERSION
master-0  Ready     master  73m  v1.29.4
master-1  Ready     master  73m  v1.29.4
master-2  Ready     master  74m  v1.29.4
worker-0  Ready     worker  11m  v1.29.4
worker-1  Ready     worker  11m  v1.29.4
    Copy to Clipboard Toggle word wrap

    참고

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

추가 정보

RHEL KVM을 사용하여 IBM Z® 및 IBM® LinuxONE(s390x)에서 다중 아키텍처 컴퓨팅 머신이 있는 클러스터를 생성하려면 기존 단일 아키텍처 x86_64 클러스터가 있어야 합니다. 그런 다음 s390x 컴퓨팅 머신을 OpenShift Container Platform 클러스터에 추가할 수 있습니다.

s390x 노드를 클러스터에 추가하려면 먼저 다중 아키텍처 페이로드를 사용하는 클러스터로 클러스터를 업그레이드해야 합니다. 다중 아키텍처 페이로드로 마이그레이션하는 방법에 대한 자세한 내용은 다중 아키텍처 컴퓨팅 머신이 있는 클러스터로 마이그레이션 을 참조하십시오.

다음 절차에서는 RHEL KVM 인스턴스를 사용하여 RHCOS 컴퓨팅 머신을 생성하는 방법을 설명합니다. 이를 통해 클러스터에 s390x 노드를 추가하고 다중 아키텍처 컴퓨팅 머신이 있는 클러스터를 배포할 수 있습니다.

x86_64 에서 다중 아키텍처 컴퓨팅 머신이 있는 IBM Z® 또는 IBM® LinuxONE(s390x) 클러스터를 생성하려면 IBM Z® 및 IBM® LinuxONE에 클러스터 설치 지침을 따르십시오. 그런 다음 베어 메탈, IBM Power 또는 IBM Z에서 다중 아키텍처 컴퓨팅 머신을 사용하여 클러스터 생성에 설명된 대로 x86_64 컴퓨팅 머신을 추가할 수 있습니다.

참고

보조 아키텍처 노드를 클러스터에 추가하기 전에 Multiarch Tuning Operator를 설치하고 ClusterPodPlacementConfig 오브젝트를 배포하는 것이 좋습니다. 자세한 내용은 Multiarch Tuning Operator를 사용하여 다중 아키텍처 클러스터에서 워크로드 관리를 참조하십시오.

4.8.1. 클러스터 호환성 확인
링크 복사

다른 아키텍처의 컴퓨팅 노드를 클러스터에 추가하려면 먼저 클러스터가 다중 아키텍처 호환인지 확인해야 합니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.

프로세스

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

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

    $ oc adm release info -o jsonpath="{ .metadata.metadata}"
    Copy to Clipboard Toggle word wrap

검증

  • 다음 출력이 표시되면 클러스터에서 다중 아키텍처 페이로드를 사용하고 있습니다. 

    {
 "release.openshift.io/architecture": "multi",
 "url": "https://access.redhat.com/errata/<errata_version>"
}
    Copy to Clipboard Toggle word wrap

    그런 다음 클러스터에 다중 아키텍처 컴퓨팅 노드 추가를 시작할 수 있습니다.

  • 다음 출력이 표시되면 클러스터에서 다중 아키텍처 페이로드를 사용하지 않습니다. 

    {
 "url": "https://access.redhat.com/errata/<errata_version>"
}
    Copy to Clipboard Toggle word wrap
    중요

    클러스터가 다중 아키텍처 컴퓨팅 머신을 지원하도록 클러스터를 마이그레이션하려면 다중 아키텍처 컴퓨팅 머신이 있는 클러스터로 마이그레이션 절차를 따르십시오.

4.8.2. virt-install을 사용하여 RHCOS 머신 생성
링크 복사

virt-install 을 사용하여 클러스터에 대해 더 많은 RHCOS(Red Hat Enterprise Linux CoreOS) 컴퓨팅 머신을 생성할 수 있습니다.

사전 요구 사항

  • 이 절차에서 RHEL KVM 호스트라고 하는 KVM을 사용하여 RHEL 8.7 이상에서 하나 이상의 LPAR이 실행됩니다.
  • RHEL KVM 호스트에 KVM/QEMU 하이퍼바이저가 설치되어 있어야 합니다.
  • 노드의 호스트 이름 및 역방향 조회를 수행할 수 있는 DNS(Domain Name Server)가 있습니다.
  • HTTP 또는 HTTPS 서버가 설정됩니다.

프로세스

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

    $ oc extract -n openshift-machine-api secret/worker-user-data-managed --keys=userData --to=- > worker.ign
    Copy to Clipboard Toggle word wrap
  2. 클러스터에서 내보낸 worker.ign Ignition 구성 파일을 HTTP 서버로 업로드합니다. 이 파일의 URL을 기록해 둡니다.

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

    $ curl -k http://<HTTP_server>/worker.ign
    Copy to Clipboard Toggle word wrap

  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')
    Copy to Clipboard Toggle word wrap 
    $ 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')
    Copy to Clipboard Toggle word wrap 
    $ 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')
    Copy to Clipboard Toggle word wrap
  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
    Copy to Clipboard Toggle word wrap
    1
    os-variant 의 경우 RHCOS 컴퓨팅 머신의 RHEL 버전을 지정합니다. rhel9.4 는 권장 버전입니다. 지원되는 RHEL 버전의 운영 체제를 쿼리하려면 다음 명령을 실행합니다. 
    $ osinfo-query os -f short-id
    Copy to Clipboard Toggle word wrap
    참고

    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. 계속해서 클러스터에 추가 컴퓨팅 머신을 만듭니다.

4.8.3. 시스템의 인증서 서명 요청 승인
링크 복사

클러스터에 시스템을 추가하면 추가한 시스템별로 보류 중인 인증서 서명 요청(CSR)이 두 개씩 생성됩니다. 이러한 CSR이 승인되었는지 확인해야 하며, 필요한 경우 이를 직접 승인해야 합니다. 클라이언트 요청을 먼저 승인한 다음 서버 요청을 승인해야 합니다.

사전 요구 사항

  • 클러스터에 시스템을 추가했습니다.

프로세스

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

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME      STATUS    ROLES   AGE  VERSION
master-0  Ready     master  63m  v1.29.4
master-1  Ready     master  63m  v1.29.4
master-2  Ready     master  64m  v1.29.4
    Copy to Clipboard Toggle word wrap

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

    참고

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

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

    $ oc get csr
    Copy to Clipboard Toggle word wrap

    출력 예

    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
...
    Copy to Clipboard Toggle word wrap

    예에서는 두 시스템이 클러스터에 참여하고 있습니다. 목록에는 승인된 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
      Copy to Clipboard Toggle word wrap
      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
      Copy to Clipboard Toggle word wrap
      참고

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

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

    $ oc get csr
    Copy to Clipboard Toggle word wrap

    출력 예

    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
...
    Copy to Clipboard Toggle word wrap

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

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

      $ oc adm certificate approve <csr_name>
      1
      Copy to Clipboard Toggle word wrap
      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
      Copy to Clipboard Toggle word wrap

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

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME      STATUS    ROLES   AGE  VERSION
master-0  Ready     master  73m  v1.29.4
master-1  Ready     master  73m  v1.29.4
master-2  Ready     master  74m  v1.29.4
worker-0  Ready     worker  11m  v1.29.4
worker-1  Ready     worker  11m  v1.29.4
    Copy to Clipboard Toggle word wrap

    참고

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

추가 정보

IBM Power®(ppc64le)에서 다중 아키텍처 컴퓨팅 머신이 있는 클러스터를 생성하려면 기존 단일 아키텍처(x86_64) 클러스터가 있어야 합니다. 그런 다음 OpenShift Container Platform 클러스터에 ppc64le 컴퓨팅 머신을 추가할 수 있습니다.

중요

클러스터에 ppc64le 노드를 추가하려면 먼저 다중 아키텍처 페이로드를 사용하는 클러스터로 클러스터를 업그레이드해야 합니다. 다중 아키텍처 페이로드로 마이그레이션하는 방법에 대한 자세한 내용은 다중 아키텍처 컴퓨팅 머신이 있는 클러스터로 마이그레이션 을 참조하십시오.

다음 절차에서는 ISO 이미지 또는 네트워크 PXE 부팅을 사용하여 RHCOS 컴퓨팅 머신을 생성하는 방법을 설명합니다. 이를 통해 클러스터에 ppc64le 노드를 추가하고 다중 아키텍처 컴퓨팅 머신이 있는 클러스터를 배포할 수 있습니다.

x86_64 에서 다중 아키텍처 컴퓨팅 머신이 있는 IBM Power®(ppc64le) 클러스터를 생성하려면 IBM Power®에 클러스터 설치 지침을 따르십시오. 그런 다음 베어 메탈, IBM Power 또는 IBM Z에서 다중 아키텍처 컴퓨팅 머신을 사용하여 클러스터 생성에 설명된 대로 x86_64 컴퓨팅 머신을 추가할 수 있습니다.

참고

보조 아키텍처 노드를 클러스터에 추가하기 전에 Multiarch Tuning Operator를 설치하고 ClusterPodPlacementConfig 오브젝트를 배포하는 것이 좋습니다. 자세한 내용은 Multiarch Tuning Operator를 사용하여 다중 아키텍처 클러스터에서 워크로드 관리를 참조하십시오.

4.9.1. 클러스터 호환성 확인
링크 복사

다른 아키텍처의 컴퓨팅 노드를 클러스터에 추가하려면 먼저 클러스터가 다중 아키텍처 호환인지 확인해야 합니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
참고

여러 아키텍처를 사용하는 경우 OpenShift Container Platform 노드의 호스트는 동일한 스토리지 계층을 공유해야 합니다. 동일한 스토리지 계층이 없는 경우 nfs-provisioner 와 같은 스토리지 공급자를 사용합니다.

참고

컴퓨팅과 컨트롤 플레인 사이의 네트워크 홉 수를 가능한 한 많이 제한해야 합니다.

프로세스

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

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

    $ oc adm release info -o jsonpath="{ .metadata.metadata}"
    Copy to Clipboard Toggle word wrap

검증

  • 다음 출력이 표시되면 클러스터에서 다중 아키텍처 페이로드를 사용하고 있습니다. 

    {
 "release.openshift.io/architecture": "multi",
 "url": "https://access.redhat.com/errata/<errata_version>"
}
    Copy to Clipboard Toggle word wrap

    그런 다음 클러스터에 다중 아키텍처 컴퓨팅 노드 추가를 시작할 수 있습니다.

  • 다음 출력이 표시되면 클러스터에서 다중 아키텍처 페이로드를 사용하지 않습니다. 

    {
 "url": "https://access.redhat.com/errata/<errata_version>"
}
    Copy to Clipboard Toggle word wrap
    중요

    클러스터가 다중 아키텍처 컴퓨팅 머신을 지원하도록 클러스터를 마이그레이션하려면 다중 아키텍처 컴퓨팅 머신이 있는 클러스터로 마이그레이션 절차를 따르십시오.

4.9.2. ISO 이미지를 사용하여 RHCOS 머신 생성
링크 복사

ISO 이미지를 사용하여 머신을 생성하여 클러스터에 대해 더 많은 RHCOS(Red Hat Enterprise Linux CoreOS) 컴퓨팅 머신을 생성할 수 있습니다.

사전 요구 사항

  • 클러스터의 컴퓨팅 머신에 대한 Ignition 구성 파일의 URL을 가져옵니다. 설치 중에 이 파일은 HTTP 서버에 업로드되어 있어야 합니다.
  • OpenShift CLI(oc)가 설치되어 있어야 합니다.

프로세스

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

    $ oc extract -n openshift-machine-api secret/worker-user-data-managed --keys=userData --to=- > worker.ign
    Copy to Clipboard Toggle word wrap
  2. 클러스터에서 내보낸 worker.ign Ignition 구성 파일을 HTTP 서버로 업로드합니다. 해당 파일의 URL을 기록해 둡니다.

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

    $ curl -k http://<HTTP_server>/worker.ign
    Copy to Clipboard Toggle word wrap

  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')
    Copy to Clipboard Toggle word wrap

  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>
    1
    2
    Copy to Clipboard Toggle word wrap
    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/worker.ign /dev/sda --ignition-hash=sha512-a5a2d43879223273c9b60af66b44202a1d1248fc01cf156c46d4a79f552b6bad47bc8cc78ddf0116e80c59d2ea9e32ba53bc807afbca581aa059311def2c3e3b
    Copy to Clipboard Toggle word wrap

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

    중요

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

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

4.9.3. PXE 또는 iPXE 부팅을 통해 RHCOS 머신 생성
링크 복사

PXE 또는 iPXE 부팅을 사용하여 베어 메탈 클러스터에 대해 추가 Red Hat Enterprise Linux CoreOS (RHCOS) 컴퓨팅 머신을 생성할 수 있습니다.

사전 요구 사항

  • 클러스터의 컴퓨팅 머신에 대한 Ignition 구성 파일의 URL을 가져옵니다. 설치 중에 이 파일은 HTTP 서버에 업로드되어 있어야 합니다.
  • 클러스터 설치 중에 HTTP 서버에 업로드 한 RHCOS ISO 이미지, 압축된 메탈 BIOS, kernel 및 initramfs 파일의 URL을 가져옵니다.
  • 설치 중에 OpenShift Container Platform 클러스터에 대한 머신을 생성하는 데 사용한 PXE 부팅 인프라에 액세스할 수 있습니다. RHCOS가 설치된 후 로컬 디스크에서 머신을 부팅해야합니다.
  • UEFI를 사용하는 경우 OpenShift Container Platform 설치 중에 수정 한 grub.conf 파일에 액세스할 수 있습니다.

프로세스

  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
      Copy to Clipboard Toggle word wrap
      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
      Copy to Clipboard Toggle word wrap
      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 
      
}
      Copy to Clipboard Toggle word wrap
      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 인프라를 사용하여 클러스터에 필요한 컴퓨팅 머신을 만듭니다.

4.9.4. 시스템의 인증서 서명 요청 승인
링크 복사

클러스터에 시스템을 추가하면 추가한 시스템별로 보류 중인 인증서 서명 요청(CSR)이 두 개씩 생성됩니다. 이러한 CSR이 승인되었는지 확인해야 하며, 필요한 경우 이를 직접 승인해야 합니다. 클라이언트 요청을 먼저 승인한 다음 서버 요청을 승인해야 합니다.

사전 요구 사항

  • 클러스터에 시스템을 추가했습니다.

프로세스

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

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME      STATUS    ROLES   AGE  VERSION
master-0  Ready     master  63m  v1.29.4
master-1  Ready     master  63m  v1.29.4
master-2  Ready     master  64m  v1.29.4
    Copy to Clipboard Toggle word wrap

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

    참고

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

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

    $ oc get csr
    Copy to Clipboard Toggle word wrap

    출력 예

    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
...
    Copy to Clipboard Toggle word wrap

    예에서는 두 시스템이 클러스터에 참여하고 있습니다. 목록에는 승인된 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
      Copy to Clipboard Toggle word wrap
      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
      Copy to Clipboard Toggle word wrap
      참고

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

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

    $ oc get csr
    Copy to Clipboard Toggle word wrap

    출력 예

    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
...
    Copy to Clipboard Toggle word wrap

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

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

      $ oc adm certificate approve <csr_name>
      1
      Copy to Clipboard Toggle word wrap
      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
      Copy to Clipboard Toggle word wrap

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

    $ oc get nodes -o wide
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME               STATUS   ROLES                  AGE   VERSION   INTERNAL-IP      EXTERNAL-IP   OS-IMAGE                                                       KERNEL-VERSION                  CONTAINER-RUNTIME
worker-0-ppc64le   Ready    worker                 42d   v1.29.5   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.29.5-3.rhaos4.15.gitb36169e.el9
worker-1-ppc64le   Ready    worker                 42d   v1.29.5   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.29.5-3.rhaos4.15.gitb36169e.el9
master-0-x86       Ready    control-plane,master   75d   v1.29.5   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.29.5-3.rhaos4.15.gitb36169e.el9
master-1-x86       Ready    control-plane,master   75d   v1.29.5   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.29.5-3.rhaos4.15.gitb36169e.el9
master-2-x86       Ready    control-plane,master   75d   v1.29.5   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.29.5-3.rhaos4.15.gitb36169e.el9
worker-0-x86       Ready    worker                 75d   v1.29.5   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.29.5-3.rhaos4.15.gitb36169e.el9
worker-1-x86       Ready    worker                 75d   v1.29.5   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.29.5-3.rhaos4.15.gitb36169e.el9
    Copy to Clipboard Toggle word wrap

    참고

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

추가 정보

4.10. 다중 아키텍처 컴퓨팅 머신으로 클러스터 관리
링크 복사

다른 아키텍처의 컴퓨팅 노드를 사용하여 클러스터에 워크로드를 배포하려면 클러스터를 주의하고 모니터링해야 합니다. 클러스터 노드에 Pod를 성공적으로 배치하기 위해 수행해야 할 추가 작업이 있을 수 있습니다.

Multiarch Tuning Operator를 사용하여 다중 아키텍처 컴퓨팅 머신이 있는 클러스터에서 워크로드의 아키텍처 인식 스케줄링을 활성화할 수 있습니다. Multiarch Tuning Operator는 생성 시 Pod에서 지원할 수 있는 아키텍처를 기반으로 Pod 사양에서 추가 스케줄러 서술자를 구현합니다. 자세한 내용은 Multiarch Tuning Operator를 사용하여 다중 아키텍처 클러스터에서 워크로드 관리를 참조하십시오.

노드 유사성, 스케줄링, 테인트 및 허용 오차에 대한 자세한 내용은 다음 문서를 참조하십시오.

4.10.1.1. 다중 아키텍처 노드 워크로드 배포 샘플
링크 복사

다른 아키텍처의 컴퓨팅 노드를 사용하여 클러스터에서 워크로드를 예약하기 전에 다음 사용 사례를 고려하십시오.

노드 유사성을 사용하여 노드에서 워크로드 예약

이미지에서 지원하는 노드 세트에서만 워크로드를 예약할 수 있습니다. Pod의 템플릿 사양에 spec.affinity.nodeAffinity 필드를 설정할 수 있습니다.

nodeAffinity 가 특정 아키텍처로 설정된 배포 예

apiVersion: apps/v1
kind: Deployment
metadata: # ...
spec:
   # ...
  template:
     # ...
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: kubernetes.io/arch
                operator: In
                values:
1 

                - amd64
                - arm64
Copy to Clipboard Toggle word wrap

1
지원되는 아키텍처를 지정합니다. 유효한 값에는 amd64,arm64 또는 두 값이 모두 포함됩니다.
특정 아키텍처에 대한 모든 노드 테인트

노드에 테인트를 적용하여 해당 아키텍처와 호환되지 않는 워크로드가 해당 노드에 예약되지 않도록 할 수 있습니다. 클러스터가 MachineSet 오브젝트를 사용하는 경우 .spec.template.spec.taints 필드에 매개변수를 추가하여 지원되지 않는 아키텍처가 있는 노드에서 워크로드가 예약되지 않도록 할 수 있습니다.

  • 노드를 테인트하려면 먼저 MachineSet 오브젝트를 축소하거나 사용 가능한 머신을 제거해야 합니다. 다음 명령 중 하나를 사용하여 머신 세트를 축소할 수 있습니다. 

    $ oc scale --replicas=0 machineset <machineset> -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

    또는 다음을 수행합니다. 

    $ oc edit machineset <machineset> -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

    머신 세트 스케일링에 대한 자세한 내용은 "컴퓨팅 머신 세트 수정"을 참조하십시오.

테인트가 설정된 MachineSet 의 예

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata: # ...
spec:
  # ...
  template:
    # ...
    spec:
      # ...
      taints:
      - effect: NoSchedule
        key: multi-arch.openshift.io/arch
        value: arm64
Copy to Clipboard Toggle word wrap

다음 명령을 실행하여 특정 노드에 테인트를 설정할 수도 있습니다. 

$ oc adm taint nodes <node-name> multi-arch.openshift.io/arch=arm64:NoSchedule
Copy to Clipboard Toggle word wrap
기본 허용 오차 생성

다음 명령을 실행하여 모든 워크로드가 동일한 기본 허용 오차를 갖도록 네임스페이스에 주석을 달 수 있습니다. 

$ oc annotate namespace my-namespace \
  'scheduler.alpha.kubernetes.io/defaultTolerations'='[{"operator": "Exists", "effect": "NoSchedule", "key": "multi-arch.openshift.io/arch"}]'
Copy to Clipboard Toggle word wrap
워크로드의 아키텍처 테인트 허용

테인트가 정의된 노드에서는 해당 노드에 워크로드가 예약되지 않습니다. 그러나 Pod 사양에서 허용 오차를 설정하여 예약할 수 있습니다.

허용 오차가 있는 배포 예

apiVersion: apps/v1
kind: Deployment
metadata: # ...
spec:
  # ...
  template:
    # ...
    spec:
      tolerations:
      - key: "multi-arch.openshift.io/arch"
        value: "arm64"
        operator: "Equal"
        effect: "NoSchedule"
Copy to Clipboard Toggle word wrap

이 예제 배포는 multi-arch.openshift.io/arch=arm64 테인트가 지정된 노드에서 허용할 수도 있습니다.

테인트 및 톨러레이션에서 노드 유사성 사용

스케줄러에서 Pod를 예약할 노드 세트를 계산하면 노드 유사성이 설정된 동안 허용 오차가 세트를 확장할 수 있습니다. 특정 아키텍처의 노드에 taint를 설정하는 경우 Pod를 예약하려면 다음 예제 허용 오차가 필요합니다.

노드 유사성 및 허용 오차가 설정된 배포의 예.

apiVersion: apps/v1
kind: Deployment
metadata: # ...
spec:
  # ...
  template:
    # ...
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: kubernetes.io/arch
                operator: In
                values:
                - amd64
                - arm64
      tolerations:
      - key: "multi-arch.openshift.io/arch"
        value: "arm64"
        operator: "Equal"
        effect: "NoSchedule"
Copy to Clipboard Toggle word wrap

추가 리소스

4.10.2. RHCOS(Red Hat Enterprise Linux CoreOS) 커널에서 64k 페이지 활성화
링크 복사

클러스터의 64비트 ARM 컴퓨팅 머신의 RHCOS(Red Hat Enterprise Linux CoreOS) 커널에서 64k 메모리 페이지를 활성화할 수 있습니다. 64k 페이지 크기 커널 사양은 대규모 GPU 또는 높은 메모리 워크로드에 사용할 수 있습니다. 이 작업은 머신 구성 풀을 사용하여 커널을 업데이트하는 MCO(Machine Config Operator)를 사용합니다. 64k 페이지 크기를 활성화하려면 커널에서 활성화하려면 ARM64에 대한 머신 구성 풀을 전용으로 설정해야 합니다.

중요

64k 페이지를 사용하는 것은 64비트 ARM 시스템에 설치된 64비트 ARM 아키텍처 컴퓨팅 노드 또는 클러스터 전용입니다. 64비트 x86 머신을 사용하여 머신 구성 풀에서 64k 페이지 커널을 구성하는 경우 머신 구성 풀 및 MCO의 성능이 저하됩니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • 지원되는 플랫폼 중 하나에 서로 다른 아키텍처의 컴퓨팅 노드가 있는 클러스터를 생성하셨습니다.

프로세스

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

    $ oc label node <node_name> <label>
    Copy to Clipboard Toggle word wrap

    명령 예

    $ oc label node worker-arm64-01 node-role.kubernetes.io/worker-64k-pages=
    Copy to Clipboard Toggle word wrap

  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
    Copy to Clipboard Toggle word wrap

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

    $ oc create -f <filename>.yaml
    Copy to Clipboard Toggle word wrap

    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
    Copy to Clipboard Toggle word wrap

    1
    사용자 지정 머신 구성 풀에서 machineconfiguration.openshift.io/role 레이블의 값을 지정합니다. 예제 MachineConfig는 worker-64k-pages 레이블을 사용하여 worker-64k-pages 풀에서 64k 페이지를 활성화합니다.
    2
    원하는 커널 유형을 지정합니다. 유효한 값은 64k-pages 및 default입니다.
    참고

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

검증

  • 새 worker-64k-pages 머신 구성 풀을 보려면 다음 명령을 실행합니다. 

    $ oc get mcp
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME     CONFIG                                                                UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
master   rendered-master-9d55ac9a91127c36314e1efe7d77fbf8                      True      False      False      3              3                   3                     0                      361d
worker   rendered-worker-e7b61751c4a5b7ff995d64b967c421ff                      True      False      False      7              7                   7                     0                      361d
worker-64k-pages  rendered-worker-64k-pages-e7b61751c4a5b7ff995d64b967c421ff   True      False      False      2              2                   2                     0                      35m
    Copy to Clipboard Toggle word wrap

다중 아키텍처 컴퓨팅 머신이 있는 OpenShift Container Platform 4.16 클러스터에서는 클러스터의 이미지 스트림에서 매니페스트 목록을 자동으로 가져오지 않습니다. 매니페스트 목록을 가져오려면 기본 importMode 옵션을 PreserveOriginal 옵션으로 수동으로 변경해야 합니다.

사전 요구 사항

  • OpenShift Container Platform CLI(oc)가 설치되어 있어야 합니다.

프로세스

  • 다음 예제 명령은 cli-artifacts:latest 이미지 스트림 태그가 매니페스트 목록으로 가져오기 위해 ImageStream cli-artifacts를 패치하는 방법을 보여줍니다. 

    $ oc patch is/cli-artifacts -n openshift -p '{"spec":{"tags":[{"name":"latest","importPolicy":{"importMode":"PreserveOriginal"}}]}}'
    Copy to Clipboard Toggle word wrap

검증

  • 이미지 스트림 태그를 검사하여 매니페스트 목록을 올바르게 가져온지 확인할 수 있습니다. 다음 명령은 특정 태그에 대한 개별 아키텍처 매니페스트를 나열합니다. 

    $ oc get istag cli-artifacts:latest -n openshift -oyaml
    Copy to Clipboard Toggle word wrap

    dockerImageManifests 오브젝트가 있는 경우 매니페스트 목록 가져오기에 성공했습니다.

    dockerImageManifests 오브젝트 출력 예

    dockerImageManifests:
  - architecture: amd64
    digest: sha256:16d4c96c52923a9968fbfa69425ec703aff711f1db822e4e9788bf5d2bee5d77
    manifestSize: 1252
    mediaType: application/vnd.docker.distribution.manifest.v2+json
    os: linux
  - architecture: arm64
    digest: sha256:6ec8ad0d897bcdf727531f7d0b716931728999492709d19d8b09f0d90d57f626
    manifestSize: 1252
    mediaType: application/vnd.docker.distribution.manifest.v2+json
    os: linux
  - architecture: ppc64le
    digest: sha256:65949e3a80349cdc42acd8c5b34cde6ebc3241eae8daaeea458498fedb359a6a
    manifestSize: 1252
    mediaType: application/vnd.docker.distribution.manifest.v2+json
    os: linux
  - architecture: s390x
    digest: sha256:75f4fa21224b5d5d511bea8f92dfa8e1c00231e5c81ab95e83c3013d245d1719
    manifestSize: 1252
    mediaType: application/vnd.docker.distribution.manifest.v2+json
    os: linux
    Copy to Clipboard Toggle word wrap

Multiarch Tuning Operator는 다중 아키텍처 클러스터 및 다중 아키텍처 환경으로 전환되는 단일 아키텍처 클러스터에서 워크로드 관리를 최적화합니다.

아키텍처 인식 워크로드 스케줄링을 통해 스케줄러는 Pod 이미지의 아키텍처와 일치하는 노드에 Pod를 배치할 수 있습니다.

기본적으로 스케줄러는 노드에 대한 새 Pod 배치를 결정할 때 Pod의 컨테이너 이미지의 아키텍처를 고려하지 않습니다.

아키텍처 인식 워크로드 스케줄링을 활성화하려면 ClusterPodPlacementConfig 오브젝트를 생성해야 합니다. ClusterPodPlacementConfig 오브젝트를 생성할 때 Multiarch Tuning Operator는 아키텍처 인식 워크로드 스케줄링을 지원하는 데 필요한 피연산자를 배포합니다. ClusterPodPlacementConfig 오브젝트에서 nodeAffinityScoring 플러그인을 사용하여 노드 아키텍처의 클러스터 수준 점수를 설정할 수도 있습니다. nodeAffinityScoring 플러그인을 활성화하면 스케줄러에서 먼저 호환되는 아키텍처로 노드를 필터링한 다음 Pod를 노드에 가장 높은 점수로 배치합니다.

Pod가 생성되면 피연산자는 다음 작업을 수행합니다.

  1. Pod 예약을 방지하는 multiarch.openshift.io/scheduling-gate 스케줄링 게이트를 추가합니다.
  2. kubernetes.io/arch 레이블에 지원되는 아키텍처 값을 포함하는 스케줄링 서술자를 계산합니다.
  3. Pod 사양에서 스케줄링 서술자를 nodeAffinity 요구 사항으로 통합합니다.
  4. Pod에서 스케줄링 게이트를 제거합니다.
중요

다음 피연산자 동작을 확인합니다.

  • nodeSelector 필드가 워크로드에 대해 kubernetes.io/arch 레이블로 이미 구성된 경우 피연산자는 해당 워크로드에 대한 nodeAffinity 필드를 업데이트하지 않습니다.
  • nodeSelector 필드가 워크로드에 대해 kubernetes.io/arch 레이블로 구성되지 않은 경우 피연산자는 해당 워크로드에 대한 nodeAffinity 필드를 업데이트합니다. 그러나 해당 nodeAffinity 필드에서 피연산자는 kubernetes.io/arch 레이블로 구성되지 않은 노드 선택기 용어만 업데이트합니다.
  • nodeName 필드가 이미 설정된 경우 Multiarch Tuning Operator에서 Pod를 처리하지 않습니다.
  • Pod가 DaemonSet에 속하는 경우 피연산자는 nodeAffinity 필드를 업데이트하지 않습니다.
  • nodeSelector 또는 nodeAffinity 및 preferredAffinity 필드가 kubernetes.io/arch 레이블에 대해 설정된 경우 피연산자에서 nodeAffinity 필드를 업데이트하지 않습니다.
  • nodeSelector 또는 nodeAffinity 필드만 kubernetes.io/arch 레이블에 설정되어 있고 nodeAffinityScoring 플러그인이 비활성화된 경우 피연산자에서 nodeAffinity 필드를 업데이트하지 않습니다.
  • nodeAffinity.preferredDuringSchedulingIgnoredDuringExecution 필드에 kubernetes.io/arch 레이블을 기반으로 노드를 점수하는 용어가 이미 포함된 경우 피연산자는 nodeAffinityScoring 플러그인의 구성을 무시합니다.

4.11.1. CLI를 사용하여 Multiarch Tuning Operator 설치
링크 복사

OpenShift CLI(oc)를 사용하여 Multiarch Tuning Operator를 설치할 수 있습니다.

사전 요구 사항

  • oc 를 설치했습니다.
  • cluster-admin 권한이 있는 사용자로 oc 에 로그인했습니다.

프로세스

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

    $ oc create ns openshift-multiarch-tuning-operator
    Copy to Clipboard Toggle word wrap

  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: {}
      Copy to Clipboard Toggle word wrap

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

      $ oc create -f <file_name>
      1
      Copy to Clipboard Toggle word wrap
      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.<version>
      Copy to Clipboard Toggle word wrap

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

      $ oc create -f <file_name>
      1
      Copy to Clipboard Toggle word wrap
      1
      & lt;file_name >을 Subscription 오브젝트 구성이 포함된 YAML 파일의 이름으로 바꿉니다.
참고

Subscription 오브젝트 및 OperatorGroup 오브젝트 구성에 대한 자세한 내용은 "CLI를 사용하여 OperatorHub에서 설치"를 참조하십시오.

검증

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

    $ oc get csv -n openshift-multiarch-tuning-operator
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                                   DISPLAY                     VERSION       REPLACES                            PHASE
multiarch-tuning-operator.<version>   Multiarch Tuning Operator   <version>     multiarch-tuning-operator.1.0.0      Succeeded
    Copy to Clipboard Toggle word wrap

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

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

    $ oc get operatorgroup -n openshift-multiarch-tuning-operator
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                                        AGE
openshift-multiarch-tuning-operator-q8zbb   133m
    Copy to Clipboard Toggle word wrap

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

    $ oc get subscription -n openshift-multiarch-tuning-operator
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                        PACKAGE                     SOURCE                  CHANNEL
multiarch-tuning-operator   multiarch-tuning-operator   redhat-operators        stable
    Copy to Clipboard Toggle word wrap

4.11.2. 웹 콘솔을 사용하여 Multiarch Tuning Operator 설치
링크 복사

OpenShift Container Platform 웹 콘솔을 사용하여 Multiarch Tuning Operator를 설치할 수 있습니다.

사전 요구 사항

  • cluster-admin 권한이 있는 클러스터에 액세스할 수 있습니다.
  • OpenShift Container Platform 웹 콘솔에 액세스할 수 있습니다.

프로세스

  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 가 나열되어 있는지 확인합니다.

4.11.3. Multiarch Tuning Operator Pod 라벨 및 아키텍처 지원 개요
링크 복사

Multiarch Tuning Operator를 설치한 후 클러스터의 워크로드에 대한 다중 아키텍처 지원을 확인할 수 있습니다. Pod 레이블을 사용하여 아키텍처 호환성을 기반으로 Pod를 식별하고 관리할 수 있습니다. 이러한 레이블은 아키텍처 지원에 대한 정보를 제공하기 위해 새로 생성된 Pod에 자동으로 설정됩니다.

다음 표는 Multiarch Tuning Operator가 Pod를 생성할 때 추가하는 라벨을 설명합니다.

Expand
표 4.2. Pod를 생성할 때 Multiarch Tuning Operator에서 추가하는 Pod 레이블
레이블설명

multiarch.openshift.io/multi-arch: ""

Pod는 여러 아키텍처를 지원합니다.

multiarch.openshift.io/single-arch: ""

Pod는 단일 아키텍처만 지원합니다.

multiarch.openshift.io/arm64: ""

Pod는 arm64 아키텍처를 지원합니다.

multiarch.openshift.io/amd64: ""

Pod는 amd64 아키텍처를 지원합니다.

multiarch.openshift.io/ppc64le: ""

Pod는 ppc64le 아키텍처를 지원합니다.

multiarch.openshift.io/s390x: ""

Pod는 s390x 아키텍처를 지원합니다.

multirach.openshift.io/node-affinity: set

Operator에서 아키텍처에 대한 노드 유사성 요구 사항을 설정합니다.

multirach.openshift.io/node-affinity: not-set

Operator에서 노드 유사성 요구 사항을 설정하지 않았습니다. 예를 들어 Pod에 아키텍처에 대한 노드 유사성이 이미 있는 경우 Multiarch Tuning Operator는 이 라벨을 Pod에 추가합니다.

multiarch.openshift.io/scheduling-gate: gated

Pod가 게이트됩니다.

multiarch.openshift.io/scheduling-gate: removed

Pod 게이트가 제거되었습니다.

multiarch.openshift.io/inspection-error: ""

노드 유사성 요구 사항을 빌드하는 동안 오류가 발생했습니다.

multiarch.openshift.io/preferred-node-affinity: set

Operator에서 Pod에 아키텍처 기본 설정을 설정합니다.

multiarch.openshift.io/preferred-node-affinity: not-set

사용자가 preferredDuringSchedulingIgnoredDuringExecution 노드 유사성에 이미 설정되었기 때문에 Operator에서 Pod에 아키텍처 기본 설정을 설정하지 않았습니다.

4.11.4. ClusterPodPlacementConfig 오브젝트 생성
링크 복사

Multiarch Tuning Operator를 설치한 후 ClusterPodPlacementConfig 오브젝트를 생성해야 합니다. 이 오브젝트를 생성할 때 Multiarch Tuning Operator는 아키텍처 인식 워크로드 스케줄링을 활성화하는 피연산자를 배포합니다.

참고

ClusterPodPlacementConfig 오브젝트의 하나의 인스턴스만 생성할 수 있습니다.

ClusterPodPlacementConfig 오브젝트 구성의 예

apiVersion: multiarch.openshift.io/v1beta1
kind: ClusterPodPlacementConfig
metadata:
  name: cluster
1 

spec:
  logVerbosityLevel: Normal
2 

  namespaceSelector:
3 

    matchExpressions:
      - key: multiarch.openshift.io/exclude-pod-placement
        operator: DoesNotExist
  plugins:
4 

    nodeAffinityScoring:
5 

      enabled: true
6 

      platforms:
7 

        - architecture: amd64
8 

          weight: 100
9 

        - architecture: arm64
          weight: 50
Copy to Clipboard Toggle word wrap

1
이 필드 값을 cluster 로 설정해야 합니다.
2
선택 사항: 필드 값을 Normal, Debug, Trace, 또는 TraceAll 로 설정할 수 있습니다. 이 값은 기본적으로 Normal 으로 설정됩니다.
3
선택 사항: Multiarch Tuning Operator의 Pod 배치 피연산자가 Pod의 nodeAffinity 를 처리해야 하는 네임스페이스를 선택하도록 namespaceSelector 를 구성할 수 있습니다. 모든 네임스페이스는 기본적으로 고려됩니다.
4
선택 사항: 아키텍처 인식 워크로드 스케줄링을 위한 플러그인 목록을 포함합니다.
5
선택 사항: 이 플러그인을 사용하여 Pod 배치에 대한 아키텍처 기본 설정을 설정할 수 있습니다. 활성화하면 스케줄러에서 먼저 Pod의 요구 사항을 충족하지 않는 노드를 필터링합니다. 그런 다음 nodeAffinityScoring.platforms 필드에 정의된 아키텍처 점수에 따라 나머지 노드의 우선 순위를 지정합니다.
6
선택 사항: nodeAffinityScoring 플러그인을 활성화하려면 이 필드를 true 로 설정합니다. 기본값은 false입니다.
7
선택 사항: 아키텍처 목록과 해당 점수를 정의합니다.
8
점수할 노드 아키텍처를 지정합니다. 스케줄러는 설정한 아키텍처 점수와 Pod 사양에 정의된 스케줄링 요구 사항을 기반으로 Pod 배치에 대해 노드에 우선순위를 지정합니다. 허용되는 값은 arm64,amd64,ppc64le 또는 s390x 입니다.
9
아키텍처에 점수를 할당합니다. 이 필드의 값은 1 (최저 우선 순위)에서 100 (최고 우선 순위) 범위로 구성해야 합니다. 스케줄러는 이 점수를 사용하여 Pod 배치에 대해 노드의 우선 순위를 지정하므로 점수가 더 높은 아키텍처를 사용하는 노드에 우선합니다.

이 예제에서 operator 필드 값은 DoesNotExist 로 설정됩니다. 따라서 키 필드 값(multiarch.openshift.io/exclude-pod-placement)이 네임스페이스에서 레이블로 설정된 경우 피연산자는 해당 네임스페이스에 있는 Pod의 nodeAffinity 를 처리하지 않습니다. 대신 피연산자는 라벨이 포함되지 않은 네임스페이스에서 Pod의 nodeAffinity 를 처리합니다.

피연산자가 특정 네임스페이스에서만 Pod의 nodeAffinity 를 처리하도록 하려면 다음과 같이 namespaceSelector 를 구성할 수 있습니다. 

namespaceSelector:
  matchExpressions:
    - key: multiarch.openshift.io/include-pod-placement
      operator: Exists
Copy to Clipboard Toggle word wrap

이 예제에서 operator 필드 값은 Exists 로 설정됩니다. 따라서 피연산자는 multiarch.openshift.io/include-pod-placement 레이블이 포함된 네임스페이스에서만 Pod의 nodeAffinity 를 처리합니다.

중요

이 Operator는 kube- 부터 네임스페이스의 Pod를 제외합니다. 또한 컨트롤 플레인 노드에서 예약할 것으로 예상되는 Pod를 제외합니다.

4.11.4.1. CLI를 사용하여 ClusterPodPlacementConfig 오브젝트 생성
링크 복사

아키텍처 인식 워크로드 스케줄링을 활성화하는 Pod 배치 피연산자를 배포하려면 OpenShift CLI(oc)를 사용하여 ClusterPodPlacementConfig 오브젝트를 생성할 수 있습니다.

사전 요구 사항

  • oc 를 설치했습니다.
  • cluster-admin 권한이 있는 사용자로 oc 에 로그인했습니다.
  • Multiarch Tuning Operator가 설치되어 있습니다.

프로세스

  1. ClusterPodPlacementConfig 오브젝트 YAML 파일을 생성합니다.

    ClusterPodPlacementConfig 오브젝트 구성의 예

    apiVersion: multiarch.openshift.io/v1beta1
kind: ClusterPodPlacementConfig
metadata:
  name: cluster
spec:
  logVerbosityLevel: Normal
  namespaceSelector:
    matchExpressions:
      - key: multiarch.openshift.io/exclude-pod-placement
        operator: DoesNotExist
  plugins:
    nodeAffinityScoring:
      enabled: true
      platforms:
        - architecture: amd64
          weight: 100
        - architecture: arm64
          weight: 50
    Copy to Clipboard Toggle word wrap

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

    $ oc create -f <file_name>
    1
    Copy to Clipboard Toggle word wrap
    1
    & lt;file_name& gt;을 ClusterPodPlacementConfig 오브젝트 YAML 파일의 이름으로 바꿉니다.

검증

  • ClusterPodPlacementConfig 오브젝트가 생성되었는지 확인하려면 다음 명령을 실행합니다. 

    $ oc get clusterpodplacementconfig
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME      AGE
cluster   29s
    Copy to Clipboard Toggle word wrap

4.11.4.2. 웹 콘솔을 사용하여 ClusterPodPlacementConfig 오브젝트 생성
링크 복사

아키텍처 인식 워크로드 스케줄링을 활성화하는 Pod 배치 피연산자를 배포하려면 OpenShift Container Platform 웹 콘솔을 사용하여 ClusterPodPlacementConfig 오브젝트를 생성할 수 있습니다.

사전 요구 사항

  • cluster-admin 권한이 있는 클러스터에 액세스할 수 있습니다.
  • OpenShift Container Platform 웹 콘솔에 액세스할 수 있습니다.
  • Multiarch Tuning Operator가 설치되어 있습니다.

프로세스

  1. OpenShift Container Platform 웹 콘솔에 로그인합니다.
  2. Operators → 설치된 Operator로 이동합니다.
  3. 설치된 Operator 페이지에서 Multiarch Tuning Operator 를 클릭합니다.
  4. Cluster Pod 배치 구성 탭을 클릭합니다.
  5. 양식 보기 또는 YAML 보기를 선택합니다.
  6. ClusterPodPlacementConfig 오브젝트 매개변수를 구성합니다.
  7. Create를 클릭합니다.

  8. 선택 사항: ClusterPodPlacementConfig 오브젝트를 편집하려면 다음 작업을 수행합니다.

    1. Cluster Pod 배치 구성 탭을 클릭합니다.
    2. 옵션 메뉴에서 Edit ClusterPodPlacementConfig 를 선택합니다.
    3. YAML 을 클릭하고 ClusterPodPlacementConfig 오브젝트 매개변수를 편집합니다.
    4. 저장을 클릭합니다.

검증

  • Cluster Pod 배치 구성 페이지에서 ClusterPodPlacementConfig 오브젝트가 Ready 상태인지 확인합니다.

4.11.5. CLI를 사용하여 ClusterPodPlacementConfig 오브젝트 삭제
링크 복사

ClusterPodPlacementConfig 오브젝트의 하나의 인스턴스만 생성할 수 있습니다. 이 오브젝트를 다시 만들려면 먼저 기존 인스턴스를 삭제해야 합니다.

OpenShift CLI(oc)를 사용하여 이 오브젝트를 삭제할 수 있습니다.

사전 요구 사항

  • oc 를 설치했습니다.
  • cluster-admin 권한이 있는 사용자로 oc 에 로그인했습니다.

프로세스

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

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

    $ oc delete clusterpodplacementconfig cluster
    Copy to Clipboard Toggle word wrap

검증

  • ClusterPodPlacementConfig 오브젝트가 삭제되었는지 확인하려면 다음 명령을 실행합니다. 

    $ oc get clusterpodplacementconfig
    Copy to Clipboard Toggle word wrap

    출력 예

    No resources found
    Copy to Clipboard Toggle word wrap

4.11.6. 웹 콘솔을 사용하여 ClusterPodPlacementConfig 오브젝트 삭제
링크 복사

ClusterPodPlacementConfig 오브젝트의 하나의 인스턴스만 생성할 수 있습니다. 이 오브젝트를 다시 만들려면 먼저 기존 인스턴스를 삭제해야 합니다.

OpenShift Container Platform 웹 콘솔을 사용하여 이 오브젝트를 삭제할 수 있습니다.

전제 조건

  • cluster-admin 권한이 있는 클러스터에 액세스할 수 있습니다.
  • OpenShift Container Platform 웹 콘솔에 액세스할 수 있습니다.
  • ClusterPodPlacementConfig 오브젝트가 생성되어 있습니다.

프로세스

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

검증

  • Cluster Pod 배치 구성 페이지에서 ClusterPodPlacementConfig 오브젝트가 삭제되었는지 확인합니다.

4.11.7. CLI를 사용하여 Multiarch Tuning Operator 설치 제거
링크 복사

OpenShift CLI(oc)를 사용하여 Multiarch Tuning Operator를 설치 제거할 수 있습니다.

사전 요구 사항

  • oc 를 설치했습니다.
  • cluster-admin 권한이 있는 사용자로 oc 에 로그인했습니다.

  • ClusterPodPlacementConfig 오브젝트를 삭제했습니다.

    중요

    Multiarch Tuning Operator를 설치 제거하려면 ClusterPodPlacementConfig 오브젝트를 삭제해야 합니다. ClusterPodPlacementConfig 오브젝트를 삭제하지 않고 Operator를 설치 제거하면 예기치 않은 동작이 발생할 수 있습니다.

프로세스

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

    $ oc get subscription.operators.coreos.com -n <namespace>
    1
    Copy to Clipboard Toggle word wrap
    1
    & lt;namespace >를 Multiarch Tuning Operator를 설치 제거할 네임스페이스의 이름으로 바꿉니다.

    출력 예

    NAME                                  PACKAGE                     SOURCE             CHANNEL
openshift-multiarch-tuning-operator   multiarch-tuning-operator   redhat-operators   stable
    Copy to Clipboard Toggle word wrap

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

    $ oc get subscription.operators.coreos.com <subscription_name> -n <namespace> -o yaml | grep currentCSV
    1
    Copy to Clipboard Toggle word wrap
    1
    <subscription_name>을 Subscription 오브젝트 이름으로 바꿉니다. 예: openshift-multiarch-tuning-operator. & lt;namespace >를 Multiarch Tuning Operator를 설치 제거할 네임스페이스의 이름으로 바꿉니다.

    출력 예

    currentCSV: multiarch-tuning-operator.<version>
    Copy to Clipboard Toggle word wrap

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

    $ oc delete subscription.operators.coreos.com <subscription_name> -n <namespace>
    1
    Copy to Clipboard Toggle word wrap
    1
    <subscription_name>을 Subscription 오브젝트 이름으로 바꿉니다. <namespace>를 Multiarch Tuning Operator를 설치 제거할 네임스페이스의 이름으로 바꿉니다.

    출력 예

    subscription.operators.coreos.com "openshift-multiarch-tuning-operator" deleted
    Copy to Clipboard Toggle word wrap

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

    $ oc delete clusterserviceversion <currentCSV_value> -n <namespace>
    1
    Copy to Clipboard Toggle word wrap
    1
    & lt;currentCSV& gt;를 Multiarch Tuning Operator의 currentCSV 값으로 바꿉니다. 예: multiarch-tuning-operator.<version>. & lt;namespace >를 Multiarch Tuning Operator를 설치 제거할 네임스페이스의 이름으로 바꿉니다.

    출력 예

    clusterserviceversion.operators.coreos.com "multiarch-tuning-operator.<version>" deleted
    Copy to Clipboard Toggle word wrap

검증

  • Multiarch Tuning Operator가 제거되었는지 확인하려면 다음 명령을 실행합니다. 

    $ oc get csv -n <namespace>
    1
    Copy to Clipboard Toggle word wrap
    1
    & lt;namespace >를 Multiarch Tuning Operator를 제거한 네임스페이스 이름으로 바꿉니다.

    출력 예

    No resources found in openshift-multiarch-tuning-operator namespace.
    Copy to Clipboard Toggle word wrap

4.11.8. 웹 콘솔을 사용하여 Multiarch Tuning Operator 설치 제거
링크 복사

OpenShift Container Platform 웹 콘솔을 사용하여 Multiarch Tuning Operator를 설치 제거할 수 있습니다.

사전 요구 사항

  • cluster-admin 권한이 있는 클러스터에 액세스할 수 있습니다.

  • ClusterPodPlacementConfig 오브젝트를 삭제했습니다.

    중요

    Multiarch Tuning Operator를 설치 제거하려면 ClusterPodPlacementConfig 오브젝트를 삭제해야 합니다. ClusterPodPlacementConfig 오브젝트를 삭제하지 않고 Operator를 설치 제거하면 예기치 않은 동작이 발생할 수 있습니다.

프로세스

  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 가 나열되어 있지 않은지 확인합니다.

4.12. Multiarch Tuning Operator 릴리스 노트
링크 복사

Multiarch Tuning Operator는 다중 아키텍처 클러스터 및 다중 아키텍처 환경으로 전환되는 단일 아키텍처 클러스터에서 워크로드 관리를 최적화합니다.

이 릴리스 노트에서는 Multiarch Tuning Operator의 개발을 추적합니다.

자세한 내용은 Multiarch Tuning Operator를 사용하여 다중 아키텍처 클러스터에서 워크로드 관리를 참조하십시오.

4.12.1. Multiarch Tuning Operator 1.1.1 릴리스 노트
링크 복사

출시 날짜: 2025년 5월 27일

4.12.1.1. 버그 수정
링크 복사

  • 이전에는 Pod 배치 피연산자가 풀 시크릿의 호스트 이름에 와일드카드 항목을 사용하여 레지스트리 인증을 지원하지 않았습니다. 이로 인해 Kubelet에서 이미지를 가져올 때 Kubelet과 일치하지 않는 동작이 발생했습니다. 피연산자가 정확히 일치하는 와일드카드 항목이 일치하기 때문입니다. 결과적으로 레지스트리에서 와일드카드 호스트 이름을 사용하는 경우 이미지 가져오기가 예기치 않게 실패할 수 있었습니다.

    이번 릴리스에서는 Pod 배치 피연산자가 와일드카드 호스트 이름을 포함하는 풀 시크릿을 지원하여 일관되고 안정적인 이미지 인증 및 가져오기를 보장합니다.

  • 이전 버전에서는 모든 재시도 후 이미지 검사에 실패하고 nodeAffinityScoring 플러그인이 활성화된 경우 Pod 배치 피연산자가 잘못된 nodeAffinityScoring 라벨을 적용했습니다.

    이번 릴리스에서는 이미지 검사에 실패하는 경우에도 피연산자가 nodeAffinityScoring 라벨을 올바르게 설정합니다. 이제 이러한 레이블을 필요한 선호도 프로세스와 독립적으로 적용하여 정확하고 일관된 스케줄링을 보장합니다.

4.12.2. Multiarch Tuning Operator 1.1.0 릴리스 노트
링크 복사

출시 날짜: 2025년 3월 18일

4.12.2.1. 새로운 기능 및 개선 사항
링크 복사
  • Multiarch Tuning Operator는 이제 HCP(Hosted Control Plane) 및 기타 HCP 환경을 포함한 관리형 제품에서 지원됩니다.
  • 이번 릴리스에서는 ClusterPodPlacementConfig 오브젝트의 새 plugins 필드를 사용하여 아키텍처 인식 워크로드 스케줄링을 구성할 수 있습니다. plugins.nodeAffinityScoring 필드를 사용하여 Pod 배치에 대한 아키텍처 기본 설정을 설정할 수 있습니다. nodeAffinityScoring 플러그인을 활성화하면 스케줄러에서 먼저 Pod 요구 사항을 충족하지 않는 노드를 필터링합니다. 그런 다음 스케줄러는 nodeAffinityScoring.platforms 필드에 정의된 아키텍처 점수에 따라 나머지 노드에 우선순위를 지정합니다.
4.12.2.2. 버그 수정
링크 복사
  • 이번 릴리스에서는 Multiarch Tuning Operator에서 데몬 세트에서 관리하는 Pod의 nodeAffinity 필드를 업데이트하지 않습니다. (OCPBUGS-45885)

4.12.3. Multiarch Tuning Operator 1.0.0 릴리스 노트
링크 복사

출시 날짜: 2024년 10월 31일

4.12.3.1. 새로운 기능 및 개선 사항
링크 복사
  • 이번 릴리스에서는 Multiarch Tuning Operator에서 사용자 정의 네트워크 시나리오 및 클러스터 전체 사용자 정의 레지스트리 구성을 지원합니다.
  • 이번 릴리스에서는 Multiarch Tuning Operator가 새로 생성된 Pod에 추가하는 Pod 레이블을 사용하여 아키텍처 호환성을 기반으로 Pod를 식별할 수 있습니다.
  • 이번 릴리스에서는 Cluster Monitoring Operator에 등록된 메트릭 및 경고를 사용하여 Multiarch Tuning Operator의 동작을 모니터링할 수 있습니다.

5장. 설치 후 클러스터 작업
링크 복사

OpenShift Container Platform을 한 후 요구 사항에 맞게 클러스터를 추가로 확장하고 사용자 정의할 수 있습니다.

5.1. 사용 가능한 클러스터 사용자 정의
링크 복사

OpenShift Container Platform 클러스터를 배포한 후 대부분의 클러스터 설정 및 사용자 정의가 완료됩니다. 다양한 설정 리소스를 사용할 수 있습니다.

참고

IBM Z®에 클러스터를 설치하는 경우 일부 기능 및 기능을 사용할 수 있는 것은 아닙니다.

설정 리소스를 수정하여 이미지 레지스트리, 네트워킹 설정, 이미지 빌드 동작 및 아이덴티티 제공자와 같은 클러스터의 주요 기능을 설정합니다.

이러한 리소스를 사용하여 기능 제어를 설정하려면 oc explain 명령을 사용합니다. (예: oc explain builds --api-version = config.openshift.io/v1)

5.1.1. 클러스터 설정 리소스
링크 복사

모든 클러스터 설정 리소스는 전체적으로 범위가 지정되고 (네임 스페이스가 아님) cluster라는 이름을 지정할 수 있습니다.

Expand
리소스 이름설명

apiserver.config.openshift.io

인증서 및 인증 기관과 같은 API 서버 구성을 제공합니다.

authentication.config.openshift.io

클러스터의 ID 공급자 및 인증 구성을 제어합니다.

build.config.openshift.io

클러스터의 모든 빌드에 대해 기본 및 강제 구성 을 제어합니다.

console.config.openshift.io

로그 아웃 동작을 포함하여 웹 콘솔 인터페이스의 동작을 구성합니다.

featuregate.config.openshift.io

기술 프리뷰 기능을 사용할 수 있도록 FeatureGates 를 활성화합니다.

image.config.openshift.io

특정 이미지 레지스트리를 처리하는 방법(허용, 허용하지 않음, 비보안, CA 세부 정보)을 설정합니다.

ingress.config.openshift.io

경로의 기본 도메인과 같은 라우팅 과 관련된 구성 세부 정보입니다.

oauth.config.openshift.io

내부 OAuth 서버 흐름과 관련된 ID 공급자 및 기타 동작을 설정합니다.

project.config.openshift.io

프로젝트 템플릿을 포함하여 프로젝트를 생성하는 방법을 구성합니다.

proxy.config.openshift.io

외부 네트워크 액세스를 필요로 하는 구성 요소에서 사용할 프록시를 정의합니다. 참고: 현재 모든 구성 요소가 이 값을 사용하는 것은 아닙니다.

scheduler.config.openshift.io

프로필 및 기본 노드 선택기와 같은 스케줄러 동작을 구성합니다.

5.1.2. Operator 설정 자원
링크 복사

이러한 설정 리소스는 cluster라는 클러스터 범위의 인스턴스로 특정 Operator가 소유한 특정 구성 요소의 동작을 제어합니다.

Expand
리소스 이름Description

consoles.operator.openshift.io

브랜딩 사용자 정의와 같은 콘솔 모양을 제어합니다

config.imageregistry.operator.openshift.io

공용 라우팅, 로그 수준, 프록시 설정, 리소스 제약 조건, 복제본 수 및 스토리지 유형과 같은 OpenShift 이미지 레지스트리 설정을 구성합니다.

config.samples.operator.openshift.io

Samples Operator 를 구성하여 클러스터에 설치된 이미지 스트림 및 템플릿 샘플을 제어합니다.

5.1.3. 추가 설정 리소스
링크 복사

이러한 설정 리소스는 특정 구성 요소의 단일 인스턴스를 나타냅니다. 경우에 따라 리소스의 여러 인스턴스를 작성하고 여러 인스턴스를 요청할 수 있습니다. 다른 경우 Operator는 특정 네임 스페이스에서 특정 리소스 인스턴스 이름 만 사용할 수 있습니다. 추가 리소스 인스턴스를 생성하는 방법과 시기에 대한 자세한 내용은 구성 요소 별 설명서를 참조하십시오.

Expand
리소스 이름인스턴스 이름네임 스페이스설명

alertmanager.monitoring.coreos.com

main

openshift-monitoring

Alertmanager 배포 매개변수를 제어합니다.

ingresscontroller.operator.openshift.io

default

openshift-ingress-operator

도메인, 복제본 수, 인증서 및 컨트롤러 배치와 같은 Ingress Operator 동작을 구성합니다.

5.1.4. 정보 리소스
링크 복사

이러한 리소스를 사용하여 클러스터에 대한 정보를 검색합니다. 일부 구성에서는 이러한 리소스를 직접 편집해야 할 수 있습니다.

Expand
리소스 이름인스턴스 이름설명

clusterversion.config.openshift.io

version

OpenShift Container Platform 4.16에서는 프로덕션 클러스터에 대한 ClusterVersion 리소스를 사용자 정의할 수 없습니다. 대신 클러스터 업데이트 프로세스를 수행합니다.

dns.config.openshift.io

cluster

클러스터의 DNS 설정을 변경할 수 없습니다. DNS Operator 상태를 확인할 수 있습니다.

infrastructure.config.openshift.io

cluster

클러스터가 클라우드 공급자와 상호 작용을 가능하게 하는 설정 세부 정보입니다.

network.config.openshift.io

cluster

설치 후 클러스터 네트워크를 변경할 수 없습니다. 네트워크를 사용자 지정하려면 프로세스에 따라 설치 중에 네트워크를 사용자 지정합니다.

5.2. 작업자 노드 추가
링크 복사

OpenShift Container Platform 클러스터를 배포한 후 작업자 노드를 추가하여 클러스터 리소스를 확장할 수 있습니다. 설치 방법 및 클러스터 환경에 따라 작업자 노드를 추가할 수 있는 방법은 다양합니다.

5.2.1. 설치 관리자 프로비저닝 인프라 클러스터에 작업자 노드 추가
링크 복사

설치 프로그램에서 프로비저닝한 인프라 클러스터의 경우 사용 가능한 베어 메탈 호스트 수와 일치하도록 MachineSet 오브젝트를 수동으로 또는 자동으로 스케일링할 수 있습니다.

베어 메탈 호스트를 추가하려면 모든 네트워크 사전 요구 사항을 구성하고, 관련 baremetalhost 오브젝트를 구성한 다음 작업자 노드를 클러스터에 프로비저닝해야 합니다. 수동으로 또는 웹 콘솔을 사용하여 베어 메탈 호스트를 추가할 수 있습니다.

5.2.2. 사용자 프로비저닝 인프라 클러스터에 작업자 노드 추가
링크 복사

사용자 프로비저닝 인프라 클러스터의 경우 RHEL 또는 RHCOS ISO 이미지를 사용하여 작업자 노드를 추가하고 클러스터 Ignition 구성 파일을 사용하여 클러스터에 연결할 수 있습니다. RHEL 작업자 노드의 경우 다음 예제에서는 Ansible 플레이북을 사용하여 클러스터에 작업자 노드를 추가합니다. RHCOS 작업자 노드의 경우 다음 예제에서는 ISO 이미지 및 네트워크 부팅을 사용하여 클러스터에 작업자 노드를 추가합니다.

지원 설치 프로그램에서 관리하는 클러스터의 경우 Red Hat OpenShift Cluster Manager 콘솔, 지원 설치 관리자 REST API를 사용하여 작업자 노드를 추가하거나 ISO 이미지 및 클러스터 Ignition 구성 파일을 사용하여 작업자 노드를 수동으로 추가할 수 있습니다.

Kubernetes용 다중 클러스터 엔진에서 관리하는 클러스터의 경우 전용 다중 클러스터 엔진 콘솔을 사용하여 작업자 노드를 추가할 수 있습니다.

5.3. 작업자 노드 조정
링크 복사

배포 중에 작업자 노드의 크기를 잘못 조정한 경우 하나 이상의 새 컴퓨팅 머신 세트를 생성하여 확장한 다음 제거하기 전에 원래 컴퓨팅 머신 세트를 축소하여 조정합니다.

5.3.1. 컴퓨팅 머신 세트와 머신 구성 풀의 차이점 이해
링크 복사

MachineSet 개체는 클라우드 또는 머신 공급자와 관련하여 OpenShift Container Platform 노드를 설명합니다.

MachineConfigPool 개체를 사용하면 MachineConfigController 구성 요소가 업그레이드 컨텍스트에서 시스템의 상태를 정의하고 제공할 수 있습니다.

MachineConfigPool 개체를 사용하여 시스템 구성 풀의 OpenShift Container Platform 노드에 대한 업그레이드 방법을 구성할 수 있습니다.

NodeSelector 개체는 MachineSet에 대한 참조로 대체할 수 있습니다.

5.3.2. 컴퓨팅 머신 세트 수동 스케일링
링크 복사

컴퓨팅 머신 세트에서 머신 인스턴스를 추가하거나 제거하려면 컴퓨팅 머신 세트를 수동으로 스케일링할 수 있습니다.

이는 완전히 자동화된 설치 프로그램에 의해 프로비저닝된 인프라 설치와 관련이 있습니다. 사용자 지정 사용자 프로비저닝 인프라 설치에는 컴퓨팅 머신 세트가 없습니다.

사전 요구 사항

  • OpenShift Container Platform 클러스터 및 oc 명령행을 설치합니다.
  • cluster-admin 권한이 있는 사용자로 oc에 로그인합니다.

프로세스

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

    $ oc get machinesets.machine.openshift.io -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

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

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

    $ oc get machines.machine.openshift.io -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

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

    $ oc annotate machines.machine.openshift.io/<machine_name> -n openshift-machine-api machine.openshift.io/delete-machine="true"
    Copy to Clipboard Toggle word wrap

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

    $ oc scale --replicas=2 machinesets.machine.openshift.io <machineset> -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

    또는 다음을 수행합니다. 

    $ oc edit machinesets.machine.openshift.io <machineset> -n openshift-machine-api
    Copy to Clipboard Toggle word wrap
    작은 정보

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

    apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  name: <machineset>
  namespace: openshift-machine-api
spec:
  replicas: 2
    Copy to Clipboard Toggle word wrap

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

    중요

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

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

검증

  • 다음 명령을 실행하여 의도한 시스템의 삭제를 확인합니다. 

    $ oc get machines.machine.openshift.io
    Copy to Clipboard Toggle word wrap

5.3.3. 컴퓨팅 머신 세트 삭제 정책
링크 복사

Random, Newest 및 Oldest의 세 가지 삭제 옵션이 지원됩니다. 기본값은 Random 입니다. 즉, 컴퓨팅 머신 세트를 축소할 때 임의의 머신이 선택되어 삭제됩니다. 특정 컴퓨팅 머신 세트를 수정하여 유스 케이스에 따라 삭제 정책을 설정할 수 있습니다. 

spec:
  deletePolicy: <delete_policy>
  replicas: <desired_replica_count>
Copy to Clipboard Toggle word wrap

삭제 정책에 관계없이 관심 머신에 machine.openshift.io/delete-machine=true 주석을 추가하여 특정 머신의 삭제 우선 순위를 지정할 수도 있습니다.

중요

기본적으로 OpenShift Container Platform 라우터 Pod는 작업자에게 배포됩니다. 라우터는 웹 콘솔을 포함한 일부 클러스터 리소스에 액세스해야 하므로 먼저 라우터 Pod를 재배치하지 않는 한 작업자 컴퓨팅 머신 세트를 0 으로 스케일링하지 마십시오.

참고

사용자 정의 컴퓨팅 머신 세트는 특정 노드에서 서비스가 실행되고 작업자 컴퓨팅 머신 세트가 축소될 때 컨트롤러에서 해당 서비스를 무시해야 하는 유스 케이스에 사용할 수 있습니다. 이로 인해 서비스 중단을 피할 수 있습니다.

5.3.4. 기본 클러스터 수준 노드 선택기 생성
링크 복사

Pod의 기본 클러스터 수준 노드 선택기와 노드의 라벨을 함께 사용하면 클러스터에 생성되는 모든 Pod를 특정 노드로 제한할 수 있습니다.

클러스터 수준 노드 선택기를 사용하여 해당 클러스터에서 Pod를 생성하면 OpenShift Container Platform에서 기본 노드 선택기를 Pod에 추가하고 라벨이 일치하는 노드에 Pod를 예약합니다.

Scheduler Operator CR(사용자 정의 리소스)을 편집하여 클러스터 수준 노드 선택기를 구성합니다. 노드, 컴퓨팅 머신 세트 또는 머신 구성에 라벨을 추가합니다. 컴퓨팅 시스템 세트에 레이블을 추가하면 노드 또는 머신이 중단되면 새 노드에 라벨이 지정됩니다. 노드 또는 머신이 중단된 경우 노드 또는 머신 구성에 추가된 라벨이 유지되지 않습니다.

참고

Pod에 키/값 쌍을 추가할 수 있습니다. 그러나 기본 키에는 다른 값을 추가할 수 없습니다.

프로세스

기본 클러스터 수준 노드 선택기를 추가하려면 다음을 수행합니다.

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

    $ oc edit scheduler cluster
    Copy to Clipboard Toggle word wrap

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

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

    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
        Copy to Clipboard Toggle word wrap
        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
        Copy to Clipboard Toggle word wrap
        작은 정보

        다음 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"
        Copy to Clipboard Toggle word wrap

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

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

        $ oc edit MachineSet abc612-msrtw-worker-us-east-1c -n openshift-machine-api
        Copy to Clipboard Toggle word wrap

        MachineSet 오브젝트의 예

        apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
  ...
spec:
  ...
  template:
    metadata:
  ...
    spec:
      metadata:
        labels:
          region: east
          type: user-node
  ...
        Copy to Clipboard Toggle word wrap

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

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

        $ oc scale --replicas=0 MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c -n openshift-machine-api
        Copy to Clipboard Toggle word wrap 
        $ oc scale --replicas=1 MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c -n openshift-machine-api
        Copy to Clipboard Toggle word wrap

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

        $ oc get nodes -l <key>=<value>
        Copy to Clipboard Toggle word wrap

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

        $ oc get nodes -l type=user-node
        Copy to Clipboard Toggle word wrap

        출력 예

        NAME                                       STATUS   ROLES    AGE   VERSION
ci-ln-l8nry52-f76d1-hl7m7-worker-c-vmqzp   Ready    worker   61s   v1.29.4
        Copy to Clipboard Toggle word wrap

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

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

        $ oc label nodes <name> <key>=<value>
        Copy to Clipboard Toggle word wrap

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

        $ oc label nodes ci-ln-l8nry52-f76d1-hl7m7-worker-b-tgq49 type=user-node region=east
        Copy to Clipboard Toggle word wrap
        작은 정보

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

        kind: Node
apiVersion: v1
metadata:
  name: <node_name>
  labels:
    type: "user-node"
    region: "east"
        Copy to Clipboard Toggle word wrap

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

        $ oc get nodes -l <key>=<value>,<key>=<value>
        Copy to Clipboard Toggle word wrap

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

        $ oc get nodes -l type=user-node,region=east
        Copy to Clipboard Toggle word wrap

        출력 예

        NAME                                       STATUS   ROLES    AGE   VERSION
ci-ln-l8nry52-f76d1-hl7m7-worker-b-tgq49   Ready    worker   17m   v1.29.4
        Copy to Clipboard Toggle word wrap

클러스터 관리자가 플랫폼 확인을 위해 대기 시간 테스트를 수행한 경우 대기 시간이 긴 경우 안정성을 보장하기 위해 클러스터의 작동을 조정해야 할 수 있습니다. 클러스터 관리자는 파일에 기록된 하나의 매개변수만 변경하면 됩니다. 이 매개변수는 감독 프로세스가 클러스터의 상태를 읽고 상태를 해석하는 방법에 영향을 미치는 네 가지 매개변수를 제어합니다. 하나의 매개변수만 변경하면 지원 가능한 방식으로 클러스터 튜닝이 제공됩니다.

Kubelet 프로세스는 클러스터 상태를 모니터링하기 위한 시작점을 제공합니다. Kubelet 은 OpenShift Container Platform 클러스터의 모든 노드에 대한 상태 값을 설정합니다. Kubernetes Controller Manager(kube 컨트롤러)는 기본적으로 10초마다 상태 값을 읽습니다. kube 컨트롤러에서 노드 상태 값을 읽을 수 없는 경우 구성된 기간이 지난 후 해당 노드와의 연결이 끊어집니다. 기본 동작은 다음과 같습니다.

  1. 컨트롤 플레인의 노드 컨트롤러는 노드 상태를 Unhealthy 로 업데이트하고 노드 Ready 조건 'Unknown'을 표시합니다.
  2. 스케줄러는 이에 대한 응답으로 해당 노드에 대한 Pod 예약을 중지합니다.
  3. Node Lifecycle Controller는 NoExecute 효과가 있는 node.kubernetes.io/unreachable 테인트를 노드에 추가하고 기본적으로 5분 후에 제거하도록 노드에 Pod를 예약합니다.

이 동작은 특히 네트워크 엣지에 노드가 있는 경우 네트워크에서 대기 시간이 쉬운 경우 문제가 발생할 수 있습니다. 경우에 따라 네트워크 대기 시간으로 인해 Kubernetes 컨트롤러 관리자에서 정상적인 노드에서 업데이트를 수신하지 못할 수 있습니다. Kubelet 은 노드가 정상이지만 노드에서 Pod를 제거합니다.

이 문제를 방지하려면 작업자 대기 시간 프로필을 사용하여 Kubelet 및 Kubernetes 컨트롤러 관리자가 작업을 수행하기 전에 상태 업데이트를 기다리는 빈도를 조정할 수 있습니다. 이러한 조정은 컨트롤 플레인과 작업자 노드 간의 네트워크 대기 시간이 최적이 아닌 경우 클러스터가 올바르게 실행되도록 하는 데 도움이 됩니다.

이러한 작업자 대기 시간 프로필에는 대기 시간을 높이기 위해 클러스터의 응답을 제어하기 위해 신중하게 조정된 값으로 사전 정의된 세 가지 매개변수 세트가 포함되어 있습니다. 실험적으로 최상의 값을 수동으로 찾을 필요가 없습니다.

클러스터를 설치하거나 클러스터 네트워크에서 대기 시간을 늘리면 언제든지 작업자 대기 시간 프로필을 구성할 수 있습니다.

5.4.1. 작업자 대기 시간 프로필 이해
링크 복사

작업자 대기 시간 프로필은 신중하게 조정된 매개변수의 네 가지 범주입니다. 이러한 값을 구현하는 4개의 매개변수는 node-status-update-frequency,node-monitor-grace-period,default-not-ready-toleration-seconds 및 default-unreachable-toleration-seconds 입니다. 이러한 매개변수는 수동 방법을 사용하여 최상의 값을 결정할 필요 없이 대기 시간 문제에 대한 클러스터의 대응을 제어할 수 있는 값을 사용할 수 있습니다.

중요

이러한 매개변수를 수동으로 설정하는 것은 지원되지 않습니다. 잘못된 매개변수 설정은 클러스터 안정성에 부정적인 영향을 미칩니다.

모든 작업자 대기 시간 프로필은 다음 매개변수를 구성합니다.

node-status-update-frequency
kubelet이 API 서버에 노드 상태를 게시하는 빈도를 지정합니다.
node-monitor-grace-period
노드를 비정상적으로 표시하고 node.kubernetes.io/not-ready 또는 node.kubernetes.io/unreachable 테인트를 노드에 추가하기 전에 Kubernetes 컨트롤러 관리자가 kubelet에서 업데이트를 기다리는 시간(초)을 지정합니다.
default-not-ready-toleration-seconds
해당 노드에서 Pod를 제거하기 전에 Kube API Server Operator가 기다리는 비정상적인 노드를 표시한 후 시간(초)을 지정합니다.
default-unreachable-toleration-seconds
해당 노드에서 Pod를 제거하기 전에 Kube API Server Operator가 대기할 수 없는 노드를 표시한 후 시간(초)을 지정합니다.

다음 Operator는 작업자 대기 시간 프로필에 대한 변경 사항을 모니터링하고 적절하게 응답합니다.

  • MCO(Machine Config Operator)는 작업자 노드에서 node-status-update-frequency 매개변수를 업데이트합니다.
  • Kubernetes 컨트롤러 관리자는 컨트롤 플레인 노드에서 node-monitor-grace-period 매개변수를 업데이트합니다.
  • Kubernetes API Server Operator는 컨트롤 플레인 노드에서 default-not-ready-toleration-seconds 및 default-unreachable-toleration-seconds 매개변수를 업데이트합니다.

기본 구성이 대부분의 경우 작동하지만 OpenShift Container Platform은 네트워크가 일반적인 것보다 대기 시간이 길어지는 상황에 대해 두 가지 다른 작업자 대기 시간 프로필을 제공합니다. 세 가지 작업자 대기 시간 프로필은 다음 섹션에 설명되어 있습니다.

기본 작업자 대기 시간 프로필

Default 프로필을 사용하면 각 Kubelet 에서 10초마다 상태를 업데이트합니다(node-status-update-frequency). Kube Controller Manager 는 5초마다 Kubelet 의 상태를 확인합니다.

Kubernetes 컨트롤러 관리자는 Kubelet 비정상을 고려하기 전에 Kubelet 의 상태 업데이트에 대해 40초(node-monitor-grace-period)를 기다립니다. Kubernetes 컨트롤러 관리자에서 사용할 수 없는 상태가 없는 경우 노드를 node.kubernetes.io/not-ready 또는 node.kubernetes.io/unreachable 테인트로 표시하고 해당 노드에서 Pod를 제거합니다.

NoExecute 테인트가 있는 노드에 Pod가 있는 경우 tolerationSeconds 에 따라 Pod가 실행됩니다. 노드에 taint가 없는 경우 300초(max-not-ready-toleration-seconds 및 Kube API Server의 default-unreachable-toleration-seconds 설정)가 제거됩니다.

Expand
프로필Component매개변수현재의

Default

kubelet

node-status-update-frequency

10s

kubelet Controller Manager

node-monitor-grace-period

40s

Kubernetes API Server Operator

default-not-ready-toleration-seconds

300s

Kubernetes API Server Operator

default-unreachable-toleration-seconds

300s

중간 규모의 작업자 대기 시간 프로파일

네트워크 대기 시간이 평상시보다 약간 높은 경우 MediumUpdateAverageReaction 프로필을 사용합니다.

MediumUpdateAverageReaction 프로필은 kubelet 업데이트 빈도를 20초로 줄이고 Kubernetes 컨트롤러 관리자가 해당 업데이트를 2분으로 기다리는 기간을 변경합니다. 해당 노드의 Pod 제거 기간은 60초로 단축됩니다. Pod에 tolerationSeconds 매개변수가 있는 경우 제거는 해당 매개변수에서 지정한 기간 동안 대기합니다.

Kubernetes 컨트롤러 관리자는 노드의 비정상적인 것으로 간주하기 위해 2분 정도 기다립니다. 다른 분 후에 제거 프로세스가 시작됩니다.

Expand
프로필Component매개변수현재의

MediumUpdateAverageReaction

kubelet

node-status-update-frequency

20s

kubelet Controller Manager

node-monitor-grace-period

2m

Kubernetes API Server Operator

default-not-ready-toleration-seconds

60s

Kubernetes API Server Operator

default-unreachable-toleration-seconds

60s

작업자 대기 시간이 짧은 프로필

네트워크 대기 시간이 매우 높은 경우 LowUpdateSlowReaction 프로필을 사용합니다.

LowUpdateSlowReaction 프로필은 kubelet 업데이트 빈도를 1분으로 줄이고 Kubernetes 컨트롤러 관리자가 해당 업데이트를 5분으로 기다리는 기간을 변경합니다. 해당 노드의 Pod 제거 기간은 60초로 단축됩니다. Pod에 tolerationSeconds 매개변수가 있는 경우 제거는 해당 매개변수에서 지정한 기간 동안 대기합니다.

Kubernetes 컨트롤러 관리자는 노드의 비정상적인 것으로 간주하기 위해 5분 정도 기다립니다. 다른 분 후에 제거 프로세스가 시작됩니다.

Expand
프로필Component매개변수현재의

LowUpdateSlowReaction

kubelet

node-status-update-frequency

1m

kubelet Controller Manager

node-monitor-grace-period

5m

Kubernetes API Server Operator

default-not-ready-toleration-seconds

60s

Kubernetes API Server Operator

default-unreachable-toleration-seconds

60s

참고

대기 시간 프로필은 사용자 정의 머신 구성 풀을 지원하지 않으며 기본 작업자 머신 구성 풀만 지원합니다.

5.4.2. 작업자 대기 시간 프로필 사용 및 변경
링크 복사

네트워크 대기 시간을 처리하기 위해 작업자 대기 시간 프로필을 변경하려면 node.config 오브젝트를 편집하여 프로필 이름을 추가합니다. 대기 시간이 증가하거나 감소하면 언제든지 프로필을 변경할 수 있습니다.

한 번에 하나의 작업자 대기 시간 프로필을 이동해야 합니다. 예를 들어 Default 프로필에서 LowUpdateSlowReaction 작업자 대기 시간 프로파일로 직접 이동할 수 없습니다. 기본 작업자 대기 시간 프로필에서 먼저 MediumUpdateAverageReaction 프로필로 이동한 다음 LowUpdateSlowReaction 으로 이동해야 합니다. 마찬가지로 Default 프로필로 돌아갈 때 먼저 low 프로필에서 medium 프로필로 이동한 다음 Default 로 이동해야 합니다.

참고

OpenShift Container Platform 클러스터를 설치할 때 작업자 대기 시간 프로필을 구성할 수도 있습니다.

프로세스

기본 작업자 대기 시간 프로필에서 이동하려면 다음을 수행합니다.

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

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

      $ oc edit nodes.config/cluster
      Copy to Clipboard Toggle word wrap

    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 
      

# ...
      Copy to Clipboard Toggle word wrap

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

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

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

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

      $ oc edit nodes.config/cluster
      Copy to Clipboard Toggle word wrap

    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 
      

# ...
      Copy to Clipboard Toggle word wrap

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

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

검증

  • 모든 노드가 Ready 조건으로 돌아가면 다음 명령을 사용하여 Kubernetes 컨트롤러 관리자를 확인하여 적용되었는지 확인할 수 있습니다. 

    $ oc get KubeControllerManager -o yaml | grep -i workerlatency -A 5 -B 5
    Copy to Clipboard Toggle word wrap

    출력 예

    # ...
    - lastTransitionTime: "2022-07-11T19:47:10Z"
      reason: ProfileUpdated
      status: "False"
      type: WorkerLatencyProfileProgressing
    - lastTransitionTime: "2022-07-11T19:47:10Z"
    1 
    
      message: all static pod revision(s) have updated latency profile
      reason: ProfileUpdated
      status: "True"
      type: WorkerLatencyProfileComplete
    - lastTransitionTime: "2022-07-11T19:20:11Z"
      reason: AsExpected
      status: "False"
      type: WorkerLatencyProfileDegraded
    - lastTransitionTime: "2022-07-11T19:20:36Z"
      status: "False"
# ...
    Copy to Clipboard Toggle word wrap

    1
    프로필이 적용되고 활성화되도록 지정합니다.

미디어 프로필을 기본값으로 변경하거나 기본값을 medium로 변경하려면 node.config 오브젝트를 편집하고 spec.workerLatencyProfile 매개변수를 적절한 값으로 설정합니다.

5.5. 컨트롤 플레인 시스템 관리
링크 복사

컨트롤 플레인 머신 세트는 컴퓨팅 머신에 제공하는 컴퓨팅 머신 세트와 유사한 컨트롤 플레인 시스템에 대한 관리 기능을 제공합니다. 클러스터의 컨트롤 플레인 머신 세트의 가용성 및 초기 상태는 클라우드 공급자와 설치한 OpenShift Container Platform 버전에 따라 다릅니다. 자세한 내용은 컨트롤 플레인 머신 세트 시작하기를 참조하십시오.

5.6. 프로덕션 환경의 인프라 머신 세트 생성
링크 복사

컴퓨팅 머신 세트를 생성하여 기본 라우터, 통합 컨테이너 이미지 레지스트리 및 클러스터 지표 및 모니터링과 같은 인프라 구성 요소만 호스팅하는 머신을 생성할 수 있습니다. 이러한 인프라 머신은 환경을 실행하는 데 필요한 총 서브스크립션 수에 포함되지 않습니다.

인프라 노드 및 인프라 노드에서 실행할 수 있는 구성 요소에 대한 자세한 내용은 인프라 머신 세트 생성 을 참조하십시오.

인프라 노드를 생성하려면 머신 세트를 사용하거나 노드에 레이블을 할당 하거나 머신 구성 풀을 사용할 수 있습니다.

이러한 절차와 함께 사용할 수 있는 샘플 머신 세트의 경우 다른 클라우드의 머신 세트 생성을 참조하십시오.

모든 인프라 구성 요소에 특정 노드 선택기를 적용하면 OpenShift Container Platform에서 해당 라벨이 있는 노드에 해당 워크로드를 예약합니다.

5.6.1. 컴퓨팅 머신 세트 생성
링크 복사

설치 프로그램에서 생성한 컴퓨팅 머신 세트 외에도 고유한 머신 세트를 생성하여 선택한 특정 워크로드의 머신 컴퓨팅 리소스를 동적으로 관리할 수 있습니다.

사전 요구 사항

  • OpenShift Container Platform 클러스터를 배포합니다.
  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 oc에 로그인합니다.

프로세스

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

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

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

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

      $ oc get machinesets -n openshift-machine-api
      Copy to Clipboard Toggle word wrap

      출력 예

      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
      Copy to Clipboard Toggle word wrap

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

      $ oc get machineset <machineset_name> \
  -n openshift-machine-api -o yaml
      Copy to Clipboard Toggle word wrap

      출력 예

      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 
      
        ...
      Copy to Clipboard Toggle word wrap

      1
      클러스터 인프라 ID입니다.
      2
      기본 노드 레이블입니다.
      참고

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

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

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

    $ oc create -f <file_name>.yaml
    Copy to Clipboard Toggle word wrap

검증

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

    $ oc get machineset -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                                DESIRED   CURRENT   READY   AVAILABLE   AGE
agl030519-vplxk-infra-us-east-1a    1         1         1       1           11m
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
    Copy to Clipboard Toggle word wrap

    새 컴퓨팅 머신 세트를 사용할 수 있으면 DESIRED 및 CURRENT 값이 일치합니다. 컴퓨팅 머신 세트를 사용할 수 없는 경우 몇 분 기다렸다가 명령을 다시 실행합니다.

5.6.2. 인프라 노드 생성
링크 복사

중요

설치 관리자 프로비저닝 인프라 환경 또는 머신 API에서 컨트롤 플레인 노드를 관리하는 클러스터의 인프라 머신 세트 생성을 참조하십시오.

클러스터의 요구 사항은 인프라(infra) 노드를 프로비저닝하도록 지정합니다. 설치 프로그램은 컨트롤 플레인 및 작업자 노드만 프로비저닝합니다. 작업자 노드는 레이블을 통해 인프라 노드로 지정할 수 있습니다. 그런 다음 테인트 및 허용 오차를 사용하여 적절한 워크로드를 인프라 노드로 이동할 수 있습니다. 자세한 내용은 "인프라 머신 세트에 리소스 전달"을 참조하십시오.

선택적으로 기본 클러스터 수준 노드 선택기를 생성할 수 있습니다. 기본 노드 선택기는 모든 네임스페이스에서 생성된 Pod에 적용되며 Pod의 기존 노드 선택기와 교차점을 생성하므로 Pod의 선택기가 추가로 제한됩니다.

중요

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

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

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

프로세스

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

    $ oc label node <node-name> node-role.kubernetes.io/infra=""
    Copy to Clipboard Toggle word wrap

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

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

  3. 선택 사항: 기본 클러스터 수준 노드 선택기를 생성합니다.

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

      $ oc edit scheduler cluster
      Copy to Clipboard Toggle word wrap

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

      apiVersion: config.openshift.io/v1
kind: Scheduler
metadata:
  name: cluster
spec:
  defaultNodeSelector: node-role.kubernetes.io/infra=""
      1 
      
# ...
      Copy to Clipboard Toggle word wrap
      1
      이 예제 노드 선택기는 기본적으로 인프라 노드에 Pod를 배포합니다.
    3. 파일을 저장하여 변경 사항을 적용합니다.

이제 인프라 리소스를 새 인프라 노드로 이동할 수 있습니다. 또한 원하지 않거나 속하지 않는 워크로드를 새 인프라 노드에서 제거합니다. "OpenShift Container Platform 인프라 구성 요소"의 인프라 노드에서 사용할 수 있도록 지원되는 워크로드 목록을 참조하십시오.

5.6.3. 인프라 머신의 머신 구성 풀 생성
링크 복사

전용 구성을 위한 인프라 머신이 필요한 경우 인프라 풀을 생성해야 합니다.

중요

사용자 지정 머신 구성 풀을 생성하면 동일한 파일 또는 장치를 참조하는 경우 기본 작업자 풀 구성이 재정의됩니다.

프로세스

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

    $ oc label node <node_name> <label>
    Copy to Clipboard Toggle word wrap 
    $ oc label node ci-ln-n8mqwr2-f76d1-xscn2-worker-c-6fmtx node-role.kubernetes.io/infra=
    Copy to Clipboard Toggle word wrap

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

    $ cat infra.mcp.yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    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
    Copy to Clipboard Toggle word wrap

    1
    작업자 역할 및 사용자 지정 역할을 추가합니다.
    2
    노드에 추가한 레이블을 nodeSelector로 추가합니다.
    참고

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

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

    $ oc create -f infra.mcp.yaml
    Copy to Clipboard Toggle word wrap

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

    $ oc get machineconfig
    Copy to Clipboard Toggle word wrap

    출력 예

    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
    Copy to Clipboard Toggle word wrap

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

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

    참고

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

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

      $ cat infra.mc.yaml
      Copy to Clipboard Toggle word wrap

      출력 예

      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
      Copy to Clipboard Toggle word wrap

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

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

      $ oc create -f infra.mc.yaml
      Copy to Clipboard Toggle word wrap

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

    $ oc get mcp
    Copy to Clipboard Toggle word wrap

    출력 예

    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
    Copy to Clipboard Toggle word wrap

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

5.7. 인프라 노드에 머신 세트 리소스 할당
링크 복사

인프라 머신 세트를 생성 한 후 worker 및 infra 역할이 새 인프라 노드에 적용됩니다. infra 역할이 적용된 노드는 worker 역할이 적용된 경우에도 환경을 실행하는 데 필요한 총 서브스크립션 수에 포함되지 않습니다.

그러나 인프라 노드에 작업자 역할이 할당되면 사용자 워크로드를 의도치 않게 인프라 노드에 할당할 수 있습니다. 이를 방지하려면 제어하려는 pod에 대한 허용 오차를 적용하고 인프라 노드에 테인트를 적용할 수 있습니다.

5.7.1. 테인트 및 허용 오차를 사용하여 인프라 노드 워크로드 바인딩
링크 복사

infra 및 worker 역할이 할당된 인프라 노드가 있는 경우 사용자 워크로드가 할당되지 않도록 노드를 구성해야 합니다.

중요

인프라 노드에 대해 생성된 이중 infra,worker 레이블을 유지하고 테인트 및 허용 오차를 사용하여 사용자 워크로드가 예약된 노드를 관리하는 것이 좋습니다. 노드에서 worker 레이블을 제거하는 경우 이를 관리할 사용자 지정 풀을 생성해야 합니다. master 또는 worker 이외의 레이블이 있는 노드는 사용자 지정 풀없이 MCO에서 인식되지 않습니다. worker 레이블을 유지 관리하면 사용자 정의 레이블을 선택하는 사용자 정의 풀이 없는 경우 기본 작업자 머신 구성 풀에서 노드를 관리할 수 있습니다. infra 레이블은 총 서브스크립션 수에 포함되지 않는 클러스터와 통신합니다.

사전 요구 사항

  • OpenShift Container Platform 클러스터에서 추가 MachineSet 개체를 구성합니다.

프로세스

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

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

      $ oc describe nodes <node_name>
      Copy to Clipboard Toggle word wrap

      샘플 출력

      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=reserved:NoSchedule
 ...
      Copy to Clipboard Toggle word wrap

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

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

      $ oc adm taint nodes <node_name> <key>=<value>:<effect>
      Copy to Clipboard Toggle word wrap

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

      $ oc adm taint nodes node1 node-role.kubernetes.io/infra=reserved:NoSchedule
      Copy to Clipboard Toggle word wrap
      작은 정보

      또는 Pod 사양을 편집하여 테인트를 추가할 수 있습니다. 

      apiVersion: v1
kind: Node
metadata:
  name: node1
# ...
spec:
  taints:
    - key: node-role.kubernetes.io/infra
      value: reserved
      effect: NoSchedule
# ...
      Copy to Clipboard Toggle word wrap

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

      인프라 노드에 NoSchedule 테인트를 추가하면 해당 노드의 데몬 세트에 의해 제어되는 모든 Pod가 잘못 예약 됨으로 표시됩니다. Red Hat 지식베이스 솔루션에 잘못 예약 DNS Pod에 허용 오차를 추가하여 Pod에 Pod를 삭제하거나 Pod에 허용 오차를 추가해야 합니다. Operator가 관리하는 데몬 세트 오브젝트에 허용 오차를 추가할 수 없습니다.

      참고

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

  2. 라우터, 레지스트리, 모니터링 워크로드와 같이 인프라 노드에서 예약할 Pod에 허용 오차를 추가합니다. 이전 예제를 참조하여 Pod 오브젝트 사양에 다음 허용 오차를 추가합니다. 

    apiVersion: v1
kind: Pod
metadata:
  annotations:

# ...
spec:
# ...
  tolerations:
    - key: node-role.kubernetes.io/infra
    1 
    
      value: reserved
    2 
    
      effect: NoSchedule
    3 
    
      operator: Equal
    4
    Copy to Clipboard Toggle word wrap
    1
    노드에 추가한 키를 지정합니다.
    2
    노드에 추가한 키-값 쌍 taint의 값을 지정합니다.
    3
    노드에 추가한 효과를 지정합니다.
    4
    노드에 node-role.kubernetes.io/infra 키가 있는 테인트를 요구하도록 Equal Operator를 지정합니다.

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

    참고

    OLM을 통해 설치된 Operator의 Pod를 인프라 노드로 이동하는 것은 항상 가능한 것은 아닙니다. Operator pod를 이동하는 기능은 각 Operator의 구성에 따라 다릅니다.

  3. 스케줄러를 사용하여 인프라 노드에 Pod를 예약합니다. 자세한 내용은 " scheduler를 사용하여 Pod 배치 제어"에 대한 설명서를 참조하십시오.
  4. 새 인프라 노드에서 원하지 않거나 속하지 않는 워크로드를 제거합니다. "OpenShift Container Platform 인프라 구성 요소"의 인프라 노드에서 사용할 수 있도록 지원되는 워크로드 목록을 참조하십시오.

5.8. 인프라 머신 세트로 리소스 이동
링크 복사

일부 인프라 리소스는 기본적으로 클러스터에 배포됩니다. 이를 생성한 인프라 머신 세트로 이동할 수 있습니다.

5.8.1. 라우터 이동
링크 복사

라우터 Pod를 다른 컴퓨팅 머신 세트에 배포할 수 있습니다. 기본적으로 Pod는 작업자 노드에 배포됩니다.

사전 요구 사항

  • OpenShift Container Platform 클러스터에서 추가 컴퓨팅 머신 세트를 구성합니다.

프로세스

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

    $ oc get ingresscontroller default -n openshift-ingress-operator -o yaml
    Copy to Clipboard Toggle word wrap

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

    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
    Copy to Clipboard Toggle word wrap

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

    $ oc edit ingresscontroller default -n openshift-ingress-operator
    Copy to Clipboard Toggle word wrap 
    apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  creationTimestamp: "2025-03-26T21:15:43Z"
  finalizers:
  - ingresscontroller.operator.openshift.io/finalizer-ingresscontroller
  generation: 1
  name: default
# ...
spec:
  nodePlacement:
    nodeSelector:
    1 
    
      matchLabels:
        node-role.kubernetes.io/infra: ""
    tolerations:
    - effect: NoSchedule
      key: node-role.kubernetes.io/infra
      value: reserved
# ...
    Copy to Clipboard Toggle word wrap
    1
    적절한 값이 설정된 nodeSelector 매개변수를 이동하려는 구성 요소에 추가합니다. 표시된 형식으로 nodeSelector 매개변수를 사용하거나 노드에 지정된 값에 따라 < key>: <value > 쌍을 사용할 수 있습니다. 인프라 노드에 테인트를 추가한 경우 일치하는 허용 오차도 추가합니다.

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

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

      $ oc get pod -n openshift-ingress -o wide
      Copy to Clipboard Toggle word wrap

      출력 예

      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>
      Copy to Clipboard Toggle word wrap

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

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

      $ oc get node <node_name>
      1
      Copy to Clipboard Toggle word wrap
      1
      pod 목록에서 얻은 <node_name>을 지정합니다.

      출력 예

      NAME                          STATUS  ROLES         AGE   VERSION
ip-10-0-217-226.ec2.internal  Ready   infra,worker  17h   v1.29.4
      Copy to Clipboard Toggle word wrap

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

5.8.2. 기본 레지스트리 이동
링크 복사

Pod를 다른 노드에 배포하도록 레지스트리 Operator를 구성합니다.

사전 요구 사항

  • OpenShift Container Platform 클러스터에서 추가 컴퓨팅 머신 세트를 구성합니다.

프로세스

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

    $ oc get configs.imageregistry.operator.openshift.io/cluster -o yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    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:
...
    Copy to Clipboard Toggle word wrap

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

    $ oc edit configs.imageregistry.operator.openshift.io/cluster
    Copy to Clipboard Toggle word wrap 
    apiVersion: imageregistry.operator.openshift.io/v1
kind: Config
metadata:
  name: cluster
# ...
spec:
  logLevel: Normal
  managementState: Managed
  nodeSelector:
    1 
    
    node-role.kubernetes.io/infra: ""
  tolerations:
  - effect: NoSchedule
    key: node-role.kubernetes.io/infra
    value: reserved
    Copy to Clipboard Toggle word wrap
    1
    적절한 값이 설정된 nodeSelector 매개변수를 이동하려는 구성 요소에 추가합니다. 표시된 형식으로 nodeSelector 매개변수를 사용하거나 노드에 지정된 값에 따라 < key>: <value > 쌍을 사용할 수 있습니다. infrasructure 노드에 테인트를 추가한 경우 일치하는 톨러레이션도 추가합니다.

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

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

      $ oc get pods -o wide -n openshift-image-registry
      Copy to Clipboard Toggle word wrap

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

      $ oc describe node <node_name>
      Copy to Clipboard Toggle word wrap

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

5.8.3. 모니터링 솔루션 이동
링크 복사

모니터링 스택에는 Prometheus, Thanos Querier 및 Alertmanager를 포함한 여러 구성 요소가 포함됩니다. Cluster Monitoring Operator는 이 스택을 관리합니다. 모니터링 스택을 인프라 노드에 재배포하려면 사용자 정의 구성 맵을 생성하고 적용할 수 있습니다.

사전 요구 사항

  • cluster-admin 클러스터 역할의 사용자로 클러스터에 액세스할 수 있습니다.
  • cluster-monitoring-config ConfigMap 오브젝트를 생성하셨습니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.

프로세스

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

    $ oc edit configmap cluster-monitoring-config -n openshift-monitoring
    Copy to Clipboard Toggle word wrap 
    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
    prometheusK8s:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - key: node-role.kubernetes.io/infra
        value: reserved
        effect: NoSchedule
    prometheusOperator:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - key: node-role.kubernetes.io/infra
        value: reserved
        effect: NoSchedule
    metricsServer:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - key: node-role.kubernetes.io/infra
        value: reserved
        effect: NoSchedule
    kubeStateMetrics:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - key: node-role.kubernetes.io/infra
        value: reserved
        effect: NoSchedule
    telemeterClient:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - key: node-role.kubernetes.io/infra
        value: reserved
        effect: NoSchedule
    openshiftStateMetrics:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - key: node-role.kubernetes.io/infra
        value: reserved
        effect: NoSchedule
    thanosQuerier:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - key: node-role.kubernetes.io/infra
        value: reserved
        effect: NoSchedule
    monitoringPlugin:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - key: node-role.kubernetes.io/infra
        value: reserved
        effect: NoSchedule
    Copy to Clipboard Toggle word wrap
    1
    적절한 값이 설정된 nodeSelector 매개변수를 이동하려는 구성 요소에 추가합니다. 표시된 형식으로 nodeSelector 매개변수를 사용하거나 노드에 지정된 값에 따라 < key>: <value > 쌍을 사용할 수 있습니다. 인프라 노드에 테인트를 추가한 경우 일치하는 허용 오차도 추가합니다.

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

    $ watch 'oc get pod -n openshift-monitoring -o wide'
    Copy to Clipboard Toggle word wrap

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

    $ oc delete pod -n openshift-monitoring <pod>
    Copy to Clipboard Toggle word wrap

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

5.8.4. 로깅 리소스 이동
링크 복사

로깅 리소스 이동에 대한 자세한 내용은 다음을 참조하십시오.

5.9. 클러스터에 자동 스케일링 적용
링크 복사

OpenShift Container Platform 클러스터에 자동 스케일링을 적용하려면클러스터 자동 스케일러를 배포한 다음 클러스터의 각 머신 유형에 대해 머신 자동 스케일러를 배포해야 합니다.

자세한 내용은 OpenShift Container Platform 클러스터에 자동 스케일링 적용에서 참조하십시오.

5.10. Linux cgroup 구성
링크 복사

OpenShift Container Platform 4.14부터 OpenShift Container Platform은 클러스터에서 Linux 제어 그룹 버전 2 (cgroup v2)를 사용합니다. OpenShift Container Platform 4.13 또는 이전 버전에서 cgroup v1을 사용하는 경우 OpenShift Container Platform 4.14 이상으로 마이그레이션하면 cgroup 설정이 버전 2로 자동으로 업데이트되지 않습니다. OpenShift Container Platform 4.14 이상을 새로 설치하면 기본적으로 cgroup v2가 사용됩니다. 그러나 설치 시 Linux 제어 그룹 버전 1 (cgroup v1)을 활성화할 수 있습니다.

cgroup v2는 Linux cgroup API의 현재 버전입니다. cgroup v2는 통합 계층 구조, 더 안전한 하위 트리 위임, pressure stayll Information 과 같은 새로운 기능, 향상된 리소스 관리 및 격리를 포함하여 cgroup v1에 비해 몇 가지 개선 사항을 제공합니다. 그러나 cgroup v2에는 cgroup v1과 다른 CPU, 메모리, I/O 관리 특성이 있습니다. 따라서 일부 워크로드는 cgroup v2를 실행하는 클러스터의 메모리 또는 CPU 사용량에 약간의 차이가 있을 수 있습니다.

필요에 따라 cgroup v1과 cgroup v2 간에 변경할 수 있습니다. OpenShift Container Platform에서 cgroup v1을 활성화하면 클러스터의 모든 cgroup v2 컨트롤러 및 계층이 비활성화됩니다.

중요

cgroup v1은 더 이상 사용되지 않는 기능입니다. 더 이상 사용되지 않는 기능은 여전히 OpenShift Container Platform에 포함되어 있으며 계속 지원됩니다. 그러나 이 기능은 향후 릴리스에서 제거될 예정이므로 새로운 배포에는 사용하지 않는 것이 좋습니다.

OpenShift Container Platform에서 더 이상 사용되지 않거나 삭제된 주요 기능의 최신 목록은 OpenShift Container Platform 릴리스 노트에서 더 이상 사용되지 않고 삭제된 기능 섹션을 참조하십시오.

사전 요구 사항

  • 버전 4.12 이상을 사용하는 실행 중인 OpenShift Container Platform 클러스터가 있어야 합니다.
  • 관리 권한이 있는 사용자로 클러스터에 로그인했습니다.

프로세스

  1. 노드에서 원하는 cgroup 버전을 설정합니다.

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

      $ oc edit nodes.config/cluster
      Copy to Clipboard Toggle word wrap

    2. spec.cgroupMode: "v1":을 추가합니다.

      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:
  cgroupMode: "v1"
      1 
      
...
      Copy to Clipboard Toggle word wrap

      1
      cgroup v1을 활성화합니다.

검증

  1. 머신 구성에서 새 머신 구성이 추가되었는지 확인합니다. 

    $ oc get mc
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                                               GENERATEDBYCONTROLLER                      IGNITIONVERSION   AGE
00-master                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
00-worker                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
01-master-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
01-master-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
01-worker-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
01-worker-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
97-master-generated-kubelet                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
99-worker-generated-kubelet                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
99-master-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
99-master-ssh                                                                                 3.2.0             40m
99-worker-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
99-worker-ssh                                                                                 3.2.0             40m
rendered-master-23d4317815a5f854bd3553d689cfe2e9   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             10s
    1 
    
rendered-master-23e785de7587df95a4b517e0647e5ab7   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
rendered-worker-5d596d9293ca3ea80c896a1191735bb1   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
rendered-worker-dcc7f1b92892d34db74d6832bcc9ccd4   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             10s
    Copy to Clipboard Toggle word wrap

    1
    예상대로 새 머신 구성이 생성됩니다.

  2. 새 kernelArguments 가 새 머신 구성에 추가되었는지 확인합니다. 

    $ oc describe mc <name>
    Copy to Clipboard Toggle word wrap

    cgroup v1의 출력 예

    apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: 05-worker-kernelarg-selinuxpermissive
spec:
  kernelArguments:
    systemd.unified_cgroup_hierarchy=0
    1 
    
    systemd.legacy_systemd_cgroup_controller=1
    2 
    
    psi=0
    Copy to Clipboard Toggle word wrap

    1
    cgroup v2를 비활성화합니다.
    2
    systemd에서 cgroup v1을 활성화합니다.

  3. 노드를 확인하여 노드의 스케줄링이 비활성화되어 있는지 확인합니다. 변경 사항이 적용 중임을 나타냅니다. 

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                                       STATUS                     ROLES    AGE   VERSION
ci-ln-fm1qnwt-72292-99kt6-master-0         Ready,SchedulingDisabled   master   58m   v1.29.4
ci-ln-fm1qnwt-72292-99kt6-master-1         Ready                      master   58m   v1.29.4
ci-ln-fm1qnwt-72292-99kt6-master-2         Ready                      master   58m   v1.29.4
ci-ln-fm1qnwt-72292-99kt6-worker-a-h5gt4   Ready,SchedulingDisabled   worker   48m   v1.29.4
ci-ln-fm1qnwt-72292-99kt6-worker-b-7vtmd   Ready                      worker   48m   v1.29.4
ci-ln-fm1qnwt-72292-99kt6-worker-c-rhzkv   Ready                      worker   48m   v1.29.4
    Copy to Clipboard Toggle word wrap

  4. 노드가 Ready 상태로 돌아간 후 해당 노드의 디버그 세션을 시작합니다. 

    $ oc debug node/<node_name>
    Copy to Clipboard Toggle word wrap

  5. 디버그 쉘 내에서 /host를 root 디렉터리로 설정합니다. 

    sh-4.4# chroot /host
    Copy to Clipboard Toggle word wrap

  6. sys/fs/cgroup/cgroup2fs 파일이 노드에 있는지 확인합니다. 이 파일은 cgroup v1에 의해 생성됩니다. 

    $ stat -c %T -f /sys/fs/cgroup
    Copy to Clipboard Toggle word wrap

    출력 예

    cgroup2fs
    Copy to Clipboard Toggle word wrap

5.11. FeatureGate를 사용하여 기술 프리뷰 기능 활성화
링크 복사

FeatureGate 사용자 정의 리소스 (CR)를 편집하여 클러스터의 모든 노드에 대해 현재 기술 프리뷰 기능의 일부를 켤 수 있습니다.

5.11.1. FeatureGate 이해
링크 복사

FeatureGate 사용자 정의 리소스 (CR)를 사용하여 클러스터에서 특정 기능 세트를 활성화할 수 있습니다. 기능 세트는 기본적으로 활성화되어 있지 않은 OpenShift Container Platform 기능 컬렉션입니다.

FeatureGate CR을 사용하여 다음 기능 세트를 활성화할 수 있습니다.

  • TechPreviewNoUpgrade. 이 기능 세트는 현재 기술 프리뷰 기능의 서브 세트입니다. 이 기능 세트를 사용하면 테스트 클러스터에서 이러한 기술 프리뷰 기능을 활성화할 수 있으며 프로덕션 클러스터에서 비활성화된 기능을 완전히 테스트할 수 있습니다.

    주의

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

    기능 세트를 통해 다음과 같은 기술 프리뷰 기능을 활성화할 수 있습니다.

    • 외부 클라우드 공급자. vSphere, AWS, Azure 및 GCP에서 클러스터의 외부 클라우드 공급자 지원을 활성화합니다. OpenStack 지원은 GA입니다. 이는 대부분의 사용자가 상호 작용할 필요가 없는 내부 기능입니다. (ExternalCloudProvider)
    • OpenShift 빌드의 공유 리소스 CSI 드라이버. CSI(Container Storage Interface)를 활성화합니다. (CSIDriverSharedResource)
    • 노드의 메모리를 스왑합니다. 노드별로 OpenShift Container Platform 워크로드에 대한 스왑 메모리 사용을 활성화합니다. (NodeSwap)
    • OpenStack 시스템 API 공급자. 이 게이트는 효과가 없으며 향후 릴리스에서 이 기능 세트에서 제거될 예정입니다. (MachineAPIProviderOpenStack)
    • Insights Operator. InsightsDataGather CRD를 활성화하여 사용자가 일부 Insights 데이터 수집 옵션을 구성할 수 있습니다. 기능 세트를 사용하면 사용자가 필요에 따라 Insights 데이터 수집을 실행할 수 있는 DataGather CRD를 사용할 수 있습니다. (InsightsConfigAPI)
    • 하위 활성 기본 스토리지 클래스. PVC가 생성될 때 기본 스토리지 클래스가 없는 경우 OpenShift Container Platform에서 기본 스토리지 클래스를 PVC에 소급 할당할 수 있습니다.(RetroactiveDefaultStorageClass)
    • 동적 리소스 할당 API. Pod와 컨테이너 간에 리소스를 요청하고 공유하는 데 새 API를 활성화합니다. 이는 대부분의 사용자가 상호 작용할 필요가 없는 내부 기능입니다. (DynamicResourceAllocation)
    • Pod 보안 승인 적용. Pod 보안 승인에 대한 restricted 적용 모드를 활성화합니다. 경고를 기록하는 대신 Pod 보안 표준을 위반하는 경우 Pod가 거부됩니다. (OpenShiftPodSecurityAdmission)
    • StatefulSet Pod 가용성 업그레이드 제한 사용자는 업데이트 중에 사용할 수 없는 최대 상태 저장 세트 Pod 수를 정의하여 애플리케이션 다운 타임을 줄일 수 있습니다. (MaxUnavailableStatefulSet)
    • MatchConditions 는 이 Webhook에 요청을 전송하려면 충족해야 하는 조건 목록입니다. 일치 조건은 규칙, namespaceSelector 및 objectSelector와 이미 일치하는 요청을 필터링합니다. 일치하는 Condition 의 빈 목록은 모든 요청과 일치합니다. (admissionWebhookMatchConditions)
    • gcpLabelsTags
    • vSphereStaticIPs
    • routeExternalCertificate
    • automatedEtcdBackup
    • gcpClusterHostedDNS
    • vSphereControlPlaneMachineset
    • dnsNameResolver
    • machineConfigNodes
    • metricsServer
    • installAlternateInfrastructureAWS
    • sdnLiveMigration
    • mixedCPUsAllocation
    • managedBootImages
    • onClusterBuild
    • signatureStores
    • DisableKubeletCloudCredentialProviders
    • BareMetalLoadBalancer
    • ClusterAPIInstallAWS
    • ClusterAPIInstallNutanix
    • ClusterAPIInstallOpenStack
    • ClusterAPIInstallVSphere
    • HardwareSpeed
    • KMSv1
    • NetworkDiagnosticsConfig
    • VSphereDriverConfiguration
    • ExternalOIDC
    • ChunkSizeMiB
    • ClusterAPIInstallGCP
    • ClusterAPIInstallPowerVS
    • EtcdBackendQuota
    • 예
    • ImagePolicy
    • InsightsConfig
    • InsightsOnDemandDataGather
    • MetricsCollectionProfiles
    • NewOLM
    • NodeDisruptionPolicy
    • PinnedImages
    • PlatformOperators
    • ServiceAccountTokenNodeBinding
    • ServiceAccountTokenNodeBindingValidation
    • ServiceAccountTokenPodNodeInfo
    • TranslateStreamCloseWebsocketRequests
    • upgradeStatus
    • VSphereMultiVCenters
    • VolumeGroupSnapshot

5.11.2. 웹 콘솔을 사용하여 기능 세트 활성화
링크 복사

OpenShift Container Platform 웹 콘솔을 사용하여 FeatureGate CR(사용자 정의 리소스)을 편집하여 클러스터의 모든 노드에 대해 기능 세트를 활성화할 수 있습니다.

프로세스

기능 세트를 활성화하려면 다음을 수행합니다.

  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
    Copy to Clipboard Toggle word wrap

    1
    FeatureGate CR의 이름은 cluster이어야 합니다.
    2
    활성화할 기능 세트를 추가합니다.
    • TechPreviewNoUpgrade를 사용하면 특정 기술 프리뷰 기능을 사용할 수 있습니다.

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

검증

노드가 ready 상태로 돌아간 후 노드에서 kubelet.conf 파일을 확인하여 기능 게이트가 활성화되어 있는지 확인할 수 있습니다.

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

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

    sh-4.2# chroot /host
    Copy to Clipboard Toggle word wrap

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

    sh-4.2# cat /etc/kubernetes/kubelet.conf
    Copy to Clipboard Toggle word wrap

    샘플 출력

    # ...
featureGates:
  InsightsOperatorPullingSCA: true,
  LegacyNodeRoleBehavior: false
# ...
    Copy to Clipboard Toggle word wrap

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

    참고

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

5.11.3. CLI를 사용하여 기능 세트 활성화
링크 복사

OpenShift CLI(oc)를 사용하여 FeatureGate CR(사용자 정의 리소스)을 편집하여 클러스터의 모든 노드에 대해 기능 세트를 활성화할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.

프로세스

기능 세트를 활성화하려면 다음을 수행합니다.

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

    $ oc edit featuregate cluster
    Copy to Clipboard Toggle word wrap
    주의

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

    FeatureGate 사용자 지정 리소스 샘플

    apiVersion: config.openshift.io/v1
kind: FeatureGate
metadata:
  name: cluster
    1 
    
# ...
spec:
  featureSet: TechPreviewNoUpgrade
    2
    Copy to Clipboard Toggle word wrap

    1
    FeatureGate CR의 이름은 cluster이어야 합니다.
    2
    활성화할 기능 세트를 추가합니다.
    • TechPreviewNoUpgrade를 사용하면 특정 기술 프리뷰 기능을 사용할 수 있습니다.

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

검증

노드가 ready 상태로 돌아간 후 노드에서 kubelet.conf 파일을 확인하여 기능 게이트가 활성화되어 있는지 확인할 수 있습니다.

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

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

    sh-4.2# chroot /host
    Copy to Clipboard Toggle word wrap

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

    sh-4.2# cat /etc/kubernetes/kubelet.conf
    Copy to Clipboard Toggle word wrap

    샘플 출력

    # ...
featureGates:
  InsightsOperatorPullingSCA: true,
  LegacyNodeRoleBehavior: false
# ...
    Copy to Clipboard Toggle word wrap

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

    참고

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

5.12. etcd 작업
링크 복사

etcd를 백업하거나 etcd 암호화를 활성화 또는 비활성화하거나 etcd 데이터 조각 모음을 실행합니다.

5.12.1. etcd 암호화 정보
링크 복사

기본적으로 etcd 데이터는 OpenShift Container Platform에서 암호화되지 않습니다. 클러스터에 etcd 암호화를 사용하여 추가 데이터 보안 계층을 제공할 수 있습니다. 예를 들어 etcd 백업이 잘못된 당사자에게 노출되는 경우 중요한 데이터의 손실을 방지할 수 있습니다.

etcd 암호화를 활성화하면 다음 OpenShift API 서버 및 쿠버네티스 API 서버 리소스가 암호화됩니다.

  • 보안
  • 구성 맵
  • 라우트
  • OAuth 액세스 토큰
  • OAuth 승인 토큰

etcd 암호화를 활성화하면 암호화 키가 생성됩니다. etcd 백업에서 복원하려면 이 키가 있어야 합니다.

참고

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

백업 중에 etcd 암호화가 활성화된 경우 static_kuberesources_<datetimestamp>.tar.gz 파일에 etcd 스냅샷의 암호화 키가 포함되어 있습니다. 보안상의 이유로 이 파일을 etcd 스냅샷과 별도로 저장합니다. 그러나 이 파일은 해당 etcd 스냅샷에서 이전 etcd 상태를 복원해야 합니다.

5.12.2. 지원되는 암호화 유형
링크 복사

OpenShift Container Platform에서 etcd 데이터를 암호화하는 데 지원되는 암호화 유형은 다음과 같습니다.

AES-CBC
PKCS#7 패딩과 32바이트 키를 사용하여 AES-CBC를 사용하여 암호화를 수행합니다. 암호화 키는 매주 순환됩니다.
AES-GCM
임의의 비ce 및 32바이트 키와 함께 AES-GCM을 사용하여 암호화를 수행합니다. 암호화 키는 매주 순환됩니다.

5.12.3. etcd 암호화 활성화
링크 복사

etcd 암호화를 활성화하여 클러스터에서 중요한 리소스를 암호화할 수 있습니다.

주의

초기 암호화 프로세스가 완료될 때까지 etcd 리소스를 백업하지 마십시오. 암호화 프로세스가 완료되지 않으면 백업이 부분적으로만 암호화될 수 있습니다.

etcd 암호화를 활성화한 후 다음과 같은 몇 가지 변경 사항이 발생할 수 있습니다.

  • etcd 암호화는 몇 가지 리소스의 메모리 사용에 영향을 미칠 수 있습니다.
  • 리더가 백업을 제공해야 하므로 백업 성능에 일시적인 영향을 줄 수 있습니다.
  • 디스크 I/O는 백업 상태를 수신하는 노드에 영향을 미칠 수 있습니다.

AES-GCM 또는 AES-CBC 암호화에서 etcd 데이터베이스를 암호화할 수 있습니다.

참고

하나의 암호화 유형에서 다른 암호화 유형으로 etcd 데이터베이스를 마이그레이션하려면 API 서버의 spec.encryption.type 필드를 수정할 수 있습니다. etcd 데이터를 새 암호화 유형으로 마이그레이션하는 것은 자동으로 수행됩니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.

프로세스

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

    $ oc edit apiserver
    Copy to Clipboard Toggle word wrap

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

    spec:
  encryption:
    type: aesgcm
    1
    Copy to Clipboard Toggle word wrap
    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"}'
      Copy to Clipboard Toggle word wrap

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

      EncryptionCompleted
All resources encrypted: routes.route.openshift.io
      Copy to Clipboard Toggle word wrap

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

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

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

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

      EncryptionCompleted
All resources encrypted: secrets, configmaps
      Copy to Clipboard Toggle word wrap

      출력에 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"}'
      Copy to Clipboard Toggle word wrap

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

      EncryptionCompleted
All resources encrypted: oauthaccesstokens.oauth.openshift.io, oauthauthorizetokens.oauth.openshift.io
      Copy to Clipboard Toggle word wrap

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

5.12.4. etcd 암호화 비활성화
링크 복사

클러스터에서 etcd 데이터의 암호화를 비활성화할 수 있습니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.

프로세스

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

    $ oc edit apiserver
    Copy to Clipboard Toggle word wrap

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

    spec:
  encryption:
    type: identity
    1
    Copy to Clipboard Toggle word wrap
    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"}'
      Copy to Clipboard Toggle word wrap

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

      DecryptionCompleted
Encryption mode set to identity and everything is decrypted
      Copy to Clipboard Toggle word wrap

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

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

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

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

      DecryptionCompleted
Encryption mode set to identity and everything is decrypted
      Copy to Clipboard Toggle word wrap

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

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

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

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

      DecryptionCompleted
Encryption mode set to identity and everything is decrypted
      Copy to Clipboard Toggle word wrap

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

5.12.5. etcd 데이터 백업
링크 복사

다음 단계에 따라 etcd 스냅샷을 작성하고 정적 pod의 리소스를 백업하여 etcd 데이터를 백업합니다. 이 백업을 저장하여 etcd를 복원해야하는 경우 나중에 사용할 수 있습니다.

중요

단일 컨트롤 플레인 호스트의 백업만 저장합니다. 클러스터의 각 컨트롤 플레인 호스트에서 백업을 수행하지 마십시오.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.

  • 클러스터 전체의 프록시가 활성화되어 있는지 확인해야 합니다.

    작은 정보

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

프로세스

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

    $ oc debug --as-root node/<node_name>
    Copy to Clipboard Toggle word wrap

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

    sh-4.4# chroot /host
    Copy to Clipboard Toggle word wrap

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

    $ export HTTP_PROXY=http://<your_proxy.example.com>:8080
    Copy to Clipboard Toggle word wrap 
    $ export HTTPS_PROXY=https://<your_proxy.example.com>:8080
    Copy to Clipboard Toggle word wrap 
    $ export NO_PROXY=<example.com>
    Copy to Clipboard Toggle word wrap

  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
    Copy to Clipboard Toggle word wrap

    스크립트 출력 예

    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
    Copy to Clipboard Toggle word wrap

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

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

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

      참고

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

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

5.12.6. etcd 데이터 조각 모음
링크 복사

대규모 및 밀도가 높은 클러스터의 경우 키 공간이 너무 커져서 공간 할당량을 초과하면 etcd 성능이 저하될 수 있습니다. etcd를 정기적으로 유지 관리하고 조각 모음하여 데이터 저장소의 공간을 확보합니다. Prometheus에 대해 etcd 지표를 모니터링하고 필요한 경우 조각 모음합니다. 그러지 않으면 etcd에서 키 읽기 및 삭제만 허용하는 유지 관리 모드로 클러스터를 만드는 클러스터 전체 알람을 발생시킬 수 있습니다.

다음 주요 메트릭을 모니터링합니다.

  • etcd_server_quota_backend_bytes (현재 할당량 제한)
  • etcd_mvcc_db_total_size_in_use_in_bytes 에서는 기록 압축 후 실제 데이터베이스 사용량을 나타냅니다.
  • etcd_mvcc_db_total_size_in_bytes: 조각 모음 대기 여유 공간을 포함하여 데이터베이스 크기를 표시합니다.

etcd 기록 압축과 같은 디스크 조각화를 초래하는 이벤트 후 디스크 공간을 회수하기 위해 etcd 데이터를 조각 모음합니다.

기록 압축은 5분마다 자동으로 수행되며 백엔드 데이터베이스에서 공백이 남습니다. 이 분할된 공간은 etcd에서 사용할 수 있지만 호스트 파일 시스템에서 사용할 수 없습니다. 호스트 파일 시스템에서 이 공간을 사용할 수 있도록 etcd 조각을 정리해야 합니다.

조각 모음이 자동으로 수행되지만 수동으로 트리거할 수도 있습니다.

참고

etcd Operator는 클러스터 정보를 사용하여 사용자에게 가장 효율적인 작업을 결정하기 때문에 자동 조각 모음은 대부분의 경우에 적합합니다.

5.12.6.1. 자동 조각 모음
링크 복사

etcd Operator는 디스크 조각 모음을 자동으로 수행합니다. 수동 조작이 필요하지 않습니다.

다음 로그 중 하나를 확인하여 조각 모음 프로세스가 성공했는지 확인합니다.

  • etcd 로그
  • cluster-etcd-operator Pod
  • Operator 상태 오류 로그
주의

자동 조각 모음으로 인해 Kubernetes 컨트롤러 관리자와 같은 다양한 OpenShift 핵심 구성 요소에서 리더 선택 실패가 발생하여 실패한 구성 요소를 다시 시작할 수 있습니다. 재시작은 무해하며 다음 실행 중인 인스턴스로 장애 조치를 트리거하거나 다시 시작한 후 구성 요소가 작업을 다시 시작합니다.

성공적으로 조각 모음을 위한 로그 출력 예

etcd member has been defragmented: <member_name>, memberID: <member_id>
Copy to Clipboard Toggle word wrap

실패한 조각 모음에 대한 로그 출력 예

failed defrag on member: <member_name>, memberID: <member_id>: <error_message>
Copy to Clipboard Toggle word wrap

5.12.6.2. 수동 조각 모음
링크 복사

Prometheus 경고는 수동 조각 모음을 사용해야 하는 시기를 나타냅니다. 경고는 다음 두 가지 경우에 표시됩니다.

  • etcd에서 사용 가능한 공간의 50% 이상을 10분 이상 사용하는 경우
  • etcd가 10분 이상 전체 데이터베이스 크기의 50% 미만을 적극적으로 사용하는 경우

PromQL 표현식의 조각 모음으로 해제될 etcd 데이터베이스 크기를 MB 단위로 확인하여 조각 모음이 필요한지 여부를 확인할 수도 있습니다. (etcd_mvcc_db_total_size_in_bytes - etcd_mvcc_db_total_size_in_bytes)/1024/1024

주의

etcd를 분리하는 것은 차단 작업입니다. 조각 모음이 완료될 때까지 etcd 멤버는 응답하지 않습니다. 따라서 각 pod의 조각 모음 작업 간에 클러스터가 정상 작동을 재개할 수 있도록 1분 이상 대기해야 합니다.

각 etcd 멤버의 etcd 데이터 조각 모음을 수행하려면 다음 절차를 따릅니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.

프로세스

  1. 리더가 최종 조각화 처리를 수행하므로 어떤 etcd 멤버가 리더인지 확인합니다.

    1. etcd pod 목록을 가져옵니다. 

      $ oc -n openshift-etcd get pods -l k8s-app=etcd -o wide
      Copy to Clipboard Toggle word wrap

      출력 예

      etcd-ip-10-0-159-225.example.redhat.com                3/3     Running     0          175m   10.0.159.225   ip-10-0-159-225.example.redhat.com   <none>           <none>
etcd-ip-10-0-191-37.example.redhat.com                 3/3     Running     0          173m   10.0.191.37    ip-10-0-191-37.example.redhat.com    <none>           <none>
etcd-ip-10-0-199-170.example.redhat.com                3/3     Running     0          176m   10.0.199.170   ip-10-0-199-170.example.redhat.com   <none>           <none>
      Copy to Clipboard Toggle word wrap

    2. Pod를 선택하고 다음 명령을 실행하여 어떤 etcd 멤버가 리더인지 확인합니다. 

      $ oc rsh -n openshift-etcd etcd-ip-10-0-159-225.example.redhat.com etcdctl endpoint status --cluster -w table
      Copy to Clipboard Toggle word wrap

      출력 예

      Defaulting container name to etcdctl.
Use 'oc describe pod/etcd-ip-10-0-159-225.example.redhat.com -n openshift-etcd' to see all of the containers in this pod.
+---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
|         ENDPOINT          |        ID        | VERSION | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS |
+---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
|  https://10.0.191.37:2379 | 251cd44483d811c3 |   3.5.9 |  104 MB |     false |      false |         7 |      91624 |              91624 |        |
| https://10.0.159.225:2379 | 264c7c58ecbdabee |   3.5.9 |  104 MB |     false |      false |         7 |      91624 |              91624 |        |
| https://10.0.199.170:2379 | 9ac311f93915cc79 |   3.5.9 |  104 MB |      true |      false |         7 |      91624 |              91624 |        |
+---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
      Copy to Clipboard Toggle word wrap

      이 출력의 IS LEADER 열에 따르면 https://10.0.199.170:2379 엔드 포인트가 리더입니다. 이전 단계의 출력과 이 앤드 포인트가 일치하면 리더의 Pod 이름은 etcd-ip-10-0199-170.example.redhat.com입니다.

  2. etcd 멤버를 분리합니다.

    1. 실행중인 etcd 컨테이너에 연결하고 리더가 아닌 pod 이름을 전달합니다. 

      $ oc rsh -n openshift-etcd etcd-ip-10-0-159-225.example.redhat.com
      Copy to Clipboard Toggle word wrap

    2. ETCDCTL_ENDPOINTS 환경 변수를 설정 해제합니다. 

      sh-4.4# unset ETCDCTL_ENDPOINTS
      Copy to Clipboard Toggle word wrap

    3. etcd 멤버를 분리합니다. 

      sh-4.4# etcdctl --command-timeout=30s --endpoints=https://localhost:2379 defrag
      Copy to Clipboard Toggle word wrap

      출력 예

      Finished defragmenting etcd member[https://localhost:2379]
      Copy to Clipboard Toggle word wrap

      시간 초과 오류가 발생하면 명령이 성공할 때까지 --command-timeout 의 값을 늘립니다.

    4. 데이터베이스 크기가 감소되었는지 확인합니다. 

      sh-4.4# etcdctl endpoint status -w table --cluster
      Copy to Clipboard Toggle word wrap

      출력 예

      +---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
|         ENDPOINT          |        ID        | VERSION | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS |
+---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
|  https://10.0.191.37:2379 | 251cd44483d811c3 |   3.5.9 |  104 MB |     false |      false |         7 |      91624 |              91624 |        |
| https://10.0.159.225:2379 | 264c7c58ecbdabee |   3.5.9 |   41 MB |     false |      false |         7 |      91624 |              91624 |        |
      1 
      
| https://10.0.199.170:2379 | 9ac311f93915cc79 |   3.5.9 |  104 MB |      true |      false |         7 |      91624 |              91624 |        |
+---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
      Copy to Clipboard Toggle word wrap

      이 예에서는 etcd 멤버의 데이터베이스 크기가 시작 크기인 104MB와 달리 현재 41MB임을 보여줍니다.

    5. 다음 단계를 반복하여 다른 etcd 멤버에 연결하고 조각 모음을 수행합니다. 항상 리더의 조각 모음을 마지막으로 수행합니다.

      etcd pod가 복구될 수 있도록 조각 모음 작업에서 1분 이상 기다립니다. etcd pod가 복구될 때까지 etcd 멤버는 응답하지 않습니다.

  3. 공간 할당량을 초과하여 NOSPACE 경고가 발생하는 경우 이를 지우십시오.

    1. NOSPACE 경고가 있는지 확인합니다. 

      sh-4.4# etcdctl alarm list
      Copy to Clipboard Toggle word wrap

      출력 예

      memberID:12345678912345678912 alarm:NOSPACE
      Copy to Clipboard Toggle word wrap

    2. 경고를 지웁니다. 

      sh-4.4# etcdctl alarm disarm
      Copy to Clipboard Toggle word wrap

5.12.7. 이전 클러스터 상태로 복원
링크 복사

저장된 etcd 백업을 사용하여 이전 클러스터 상태를 복원하거나 대부분의 컨트롤 플레인 호스트가 손실된 클러스터를 복원할 수 있습니다.

참고

클러스터에서 컨트롤 플레인 머신 세트를 사용하는 경우 etcd 복구 프로시저의 "Troubleshooting the control Plane machine set"에서 "Recovering a degraded etcd Operator"를 참조하십시오.

중요

클러스터를 복원할 때 동일한 z-stream 릴리스에서 가져온 etcd 백업을 사용해야 합니다. 예를 들어 OpenShift Container Platform 4.7.2 클러스터는 4.7.2에서 가져온 etcd 백업을 사용해야 합니다.

사전 요구 사항

  • 설치 중에 사용된 인증서 기반 kubeconfig 파일을 통해 cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있습니다.
  • 복구 호스트로 사용할 정상적인 컨트롤 플레인 호스트가 있어야 합니다.
  • 컨트롤 플레인 호스트에 대한 SSH 액세스.
  • 동일한 백업에서 가져온 etcd 스냅샷과 정적 pod 리소스가 모두 포함된 백업 디렉터리입니다. 디렉토리의 파일 이름은 snapshot_<datetimestamp>.db 및 static_kuberesources_<datetimestamp>.tar.gz 형식이어야합니다.
  • 노드에 액세스하거나 부팅할 수 있어야 합니다.
중요

복구되지 않은 컨트롤 플레인 노드의 경우 SSH 연결을 설정하거나 정적 Pod를 중지할 필요가 없습니다. 복구되지 않은 다른 컨트롤 플레인 시스템을 삭제하고 다시 생성할 수 있습니다.

프로세스

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

  2. 복구 호스트를 포함하여 각 컨트롤 플레인 노드에 SSH 연결을 설정합니다. 별도의 터미널을 사용하여 각 컨트롤 플레인 노드에 대한 SSH 연결을 설정합니다.

    복원 프로세스가 시작된 후에는 Kubernetes API 서버에 액세스할 수 없으므로 oc debug 방법을 사용하여 컨트롤 플레인 노드에 액세스할 수 없습니다. 따라서 별도의 터미널에서 각 컨트롤 플레인 호스트에 대한 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
      Copy to Clipboard Toggle word wrap

    3. 다음 명령을 실행하여 etcd pod가 중지되었는지 확인합니다. 

      $ sudo crictl ps | grep etcd | egrep -v "operator|etcd-guard"
      Copy to Clipboard Toggle word wrap

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

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

      $ sudo mv -v /etc/kubernetes/manifests/kube-apiserver-pod.yaml /tmp
      Copy to Clipboard Toggle word wrap

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

      $ sudo crictl ps | grep kube-apiserver | egrep -v "operator|guard"
      Copy to Clipboard Toggle word wrap

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

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

      $ sudo mv -v /etc/kubernetes/manifests/kube-controller-manager-pod.yaml /tmp
      Copy to Clipboard Toggle word wrap

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

      $ sudo crictl ps | grep kube-controller-manager | egrep -v "operator|guard"
      Copy to Clipboard Toggle word wrap

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

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

      $ sudo mv -v /etc/kubernetes/manifests/kube-scheduler-pod.yaml /tmp
      Copy to Clipboard Toggle word wrap

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

      $ sudo crictl ps | grep kube-scheduler | egrep -v "operator|guard"
      Copy to Clipboard Toggle word wrap

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

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

      $ sudo mv -v /var/lib/etcd/ /tmp
      Copy to Clipboard Toggle word wrap

    11. /etc/kubernetes/manifests/keepalived.yaml 파일이 있는 경우 다음 단계를 완료합니다. 이러한 단계는 API IP 주소가 복구 호스트에서 수신 대기 중인지 확인하는 데 필요합니다.

      1. 다음 명령을 실행하여 /etc/kubernetes/manifests/keepalived.yaml 파일을 kubelet 매니페스트 디렉터리에서 이동합니다. 

        $ sudo mv -v /etc/kubernetes/manifests/keepalived.yaml /home/core/
        Copy to Clipboard Toggle word wrap
        참고

        절차가 완료된 후 이 파일을 원래 위치로 복원해야 합니다.

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

        $ sudo crictl ps --name keepalived
        Copy to Clipboard Toggle word wrap

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

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

        $ ip -o address | egrep '<api_vip>|<ingress_vip>'
        Copy to Clipboard Toggle word wrap

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

        $ sudo ip address del <reported_vip> dev <reported_vip_device>
        Copy to Clipboard Toggle word wrap
    12. 복구 호스트가 아닌 다른 컨트롤 플레인 호스트에서 이 단계를 반복합니다.
  5. 복구 컨트롤 플레인 호스트에 액세스합니다.

  6. keepalived 데몬이 사용 중인 경우 복구 컨트롤 플레인 노드가 VIP를 소유하고 있는지 확인합니다. 그렇지 않으면 4.xi 단계를 반복합니다. 

    $ ip -o address | grep <api_vip>
    Copy to Clipboard Toggle word wrap

    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
    Copy to Clipboard Toggle word wrap

    스크립트 출력 예

    ...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
    Copy to Clipboard Toggle word wrap

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

    참고

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

  9. 노드가 Ready 상태인지 확인합니다. 노드를 확인하려면 bastion 호스트 또는 복구 호스트를 사용할 수 있습니다.

    • 복구 호스트를 사용하는 경우 다음 명령을 실행합니다. 

      $ export KUBECONFIG=/etc/kubernetes/static-pod-resources/kube-apiserver-certs/secrets/node-kubeconfigs/localhost-recovery.kubeconfig
      Copy to Clipboard Toggle word wrap 
      $ oc get nodes -w
      Copy to Clipboard Toggle word wrap

    • bastion 호스트를 사용하는 경우 다음 단계를 완료합니다.

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

        $ oc get nodes -w
        Copy to Clipboard Toggle word wrap

        샘플 출력

        NAME                STATUS  ROLES          AGE     VERSION
host-172-25-75-28   Ready   master         3d20h   v1.29.4
host-172-25-75-38   Ready   infra,worker   3d20h   v1.29.4
host-172-25-75-40   Ready   master         3d20h   v1.29.4
host-172-25-75-65   Ready   master         3d20h   v1.29.4
host-172-25-75-74   Ready   infra,worker   3d20h   v1.29.4
host-172-25-75-79   Ready   worker         3d20h   v1.29.4
host-172-25-75-86   Ready   worker         3d20h   v1.29.4
host-172-25-75-98   Ready   infra,worker   3d20h   v1.29.4
        Copy to Clipboard Toggle word wrap

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

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

        $  ssh -i <ssh-key-path> core@<master-hostname>
        Copy to Clipboard Toggle word wrap

        샘플 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
        Copy to Clipboard Toggle word wrap

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

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

      $ sudo systemctl restart kubelet.service
      Copy to Clipboard Toggle word wrap
    2. 다른 모든 컨트롤 플레인 호스트에서 이 단계를 반복합니다.

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

    참고

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

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

      $ oc get csr
      Copy to Clipboard Toggle word wrap

      출력 예

      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 
      
...
      Copy to Clipboard Toggle word wrap

      1 1 2
      kubelet 서비스 끝점에 대해 노드에서 요청한 보류 중인 kubelet 서비스 CSR입니다.
      3 4
      node-bootstrapper 노드 부트스트랩 인증 정보로 요청된 보류 중인 kubelet 클라이언트 CSR.

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

      $ oc describe csr <csr_name>
      1
      Copy to Clipboard Toggle word wrap
      1
      <csr_name>은 현재 CSR 목록에 있는 CSR의 이름입니다.

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

      $ oc adm certificate approve <csr_name>
      Copy to Clipboard Toggle word wrap

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

      $ oc adm certificate approve <csr_name>
      Copy to Clipboard Toggle word wrap

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

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

      $ sudo crictl ps | grep etcd | egrep -v "operator|etcd-guard"
      Copy to Clipboard Toggle word wrap

      출력 예

      3ad41b7908e32       36f86e2eeaaffe662df0d21041eb22b8198e0e58abeeae8c743c3e6e977e8009                                                         About a minute ago   Running             etcd                                          0                   7c05f8af362f0
      Copy to Clipboard Toggle word wrap

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

      $ oc -n openshift-etcd get pods -l k8s-app=etcd
      Copy to Clipboard Toggle word wrap

      출력 예

      NAME                                             READY   STATUS      RESTARTS   AGE
etcd-ip-10-0-143-125.ec2.internal                1/1     Running     1          2m47s
      Copy to Clipboard Toggle word wrap

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

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

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

      $ oc -n openshift-ovn-kubernetes delete pod -l app=ovnkube-control-plane
      Copy to Clipboard Toggle word wrap

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

      $ oc -n openshift-ovn-kubernetes get pod -l app=ovnkube-control-plane
      Copy to Clipboard Toggle word wrap

  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
      Copy to Clipboard Toggle word wrap

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

      $ sudo systemctl restart ovs-vswitchd ovsdb-server
      Copy to Clipboard Toggle word wrap

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

      $ oc -n openshift-ovn-kubernetes delete pod -l app=ovnkube-node --field-selector=spec.nodeName==<node>
      Copy to Clipboard Toggle word wrap

    4. 다음 명령을 실행하여 OVN Pod의 상태를 확인합니다. 

      $ oc get po -n openshift-ovn-kubernetes
      Copy to Clipboard Toggle word wrap

      1. OVN Pod가 종료 상태에 있는 경우 다음 명령을 실행하여 해당 OVN Pod를 실행 중인 노드를 삭제합니다. & lt;node >를 삭제 중인 노드의 이름으로 바꿉니다. 

        $ oc delete node <node>
        Copy to Clipboard Toggle word wrap

      2. 다음 명령을 실행하여 SSH를 사용하여 종료 상태의 OVN pod 노드에 로그인합니다. 

        $ ssh -i <ssh-key-path> core@<node>
        Copy to Clipboard Toggle word wrap

      3. 다음 명령을 실행하여 /var/lib/kubelet/pki 디렉토리에서 모든 PEM 파일을 이동합니다. 

        $ sudo mv /var/lib/kubelet/pki/* /tmp
        Copy to Clipboard Toggle word wrap

      4. 다음 명령을 실행하여 kubelet 서비스를 다시 시작합니다. 

        $ sudo systemctl restart kubelet.service
        Copy to Clipboard Toggle word wrap

      5. 다음 명령을 실행하여 복구 etcd 머신으로 돌아갑니다. 

        $ oc get csr
        Copy to Clipboard Toggle word wrap

        출력 예

        NAME        AGE    SIGNERNAME                         REQUESTOR                     CONDITION
csr-<uuid>   8m3s   kubernetes.io/kubelet-serving     system:node:<node_name>       Pending
        Copy to Clipboard Toggle word wrap

      6. 다음 명령을 실행하여 새 CSR을 모두 승인하고 csr-<uuid&gt;를 CSR 이름으로 교체하십시오. 

        oc adm certificate approve csr-<uuid>
        Copy to Clipboard Toggle word wrap

      7. 다음 명령을 실행하여 노드가 다시 있는지 확인합니다. 

        $ oc get nodes
        Copy to Clipboard Toggle word wrap

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

      $ oc -n openshift-ovn-kubernetes get pod -l app=ovnkube-node --field-selector=spec.nodeName==<node>
      Copy to Clipboard Toggle word wrap
      참고

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

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

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

      주의

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

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

      주의

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

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

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

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

        $ oc get machines -n openshift-machine-api -o wide
        Copy to Clipboard Toggle word wrap

        출력 예

        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
        Copy to Clipboard Toggle word wrap

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

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

        $ oc delete machine -n openshift-machine-api clustername-8qw5l-master-0
        1
        Copy to Clipboard Toggle word wrap
        1
        손실된 컨트롤 플레인 호스트의 컨트롤 플레인 시스템의 이름을 지정합니다.

        손실된 컨트롤 플레인 호스트의 시스템을 삭제한 후 새 시스템이 자동으로 프로비저닝됩니다.

      3. 다음을 실행하여 새 시스템이 생성되었는지 확인합니다. 

        $ oc get machines -n openshift-machine-api -o wide
        Copy to Clipboard Toggle word wrap

        출력 예

        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
        Copy to Clipboard Toggle word wrap

        1
        새 시스템 clustername-8qw5l-master-3 이 생성되고 단계가 Provisioning 에서 Running 으로 변경된 후 준비됩니다.

        새 시스템을 만드는 데 몇 분이 소요될 수 있습니다. etcd 클러스터 Operator는 머신 또는 노드가 정상 상태로 돌아올 때 자동으로 동기화됩니다.

      4. 복구 호스트가 아닌 모든 컨트롤 플레인 호스트에 대해 이 단계를 반복합니다.

  16. 다음 명령을 실행하여 쿼럼 가드를 끕니다. 

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": {"useUnsupportedUnsafeNonHANonProductionUnstableEtcd": true}}}'
    Copy to Clipboard Toggle word wrap

    이 명령을 사용하면 시크릿을 성공적으로 다시 생성하고 정적 Pod를 롤아웃할 수 있습니다.

  17. 아직 정의되지 않은 경우 복구 호스트 내의 별도의 터미널 창에서 다음 명령을 실행하여 복구 kubeconfig 파일을 내보냅니다. 

    $ export KUBECONFIG=/etc/kubernetes/static-pod-resources/kube-apiserver-certs/secrets/node-kubeconfigs/localhost-recovery.kubeconfig
    Copy to Clipboard Toggle word wrap

  18. etcd 를 강제로 재배포합니다.

    복구 kubeconfig 파일을 내보낸 동일한 터미널 창에서 다음 명령을 실행합니다. 

    $ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge
    1
    Copy to Clipboard Toggle word wrap
    1
    forceRedeploymentReason 값은 고유해야하므로 타임 스탬프가 추가됩니다.

    etcd 재배포가 시작됩니다.

    etcd 클러스터 Operator가 재배포를 수행하면 기존 노드가 초기 부트스트랩 확장과 유사한 새 Pod로 시작됩니다.

  19. 다음 명령을 실행하여 쿼럼 가드를 다시 켭니다. 

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": null}}'
    Copy to Clipboard Toggle word wrap

  20. 다음 명령을 실행하여 unsupportedConfigOverrides 섹션이 오브젝트에서 제거되었는지 확인할 수 있습니다. 

    $ oc get etcd/cluster -oyaml
    Copy to Clipboard Toggle word wrap

  21. 모든 노드가 최신 버전으로 업데이트되었는지 확인합니다.

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

    $ oc get etcd -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'
    Copy to Clipboard Toggle word wrap

    etcd 의 NodeInstallerProgressing 상태 조건을 검토하여 모든 노드가 최신 버전인지 확인합니다. 업데이트가 성공적으로 실행되면 출력에 AllNodesAtLatestRevision이 표시됩니다. 

    AllNodesAtLatestRevision
3 nodes are at revision 7
    1
    Copy to Clipboard Toggle word wrap
    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
      Copy to Clipboard Toggle word wrap

      모든 노드가 최신 버전으로 업데이트되었는지 확인합니다. 

      $ oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'
      Copy to Clipboard Toggle word wrap

      NodeInstallerProgressing 상태 조건을 확인하고 모든 노드가 최신 버전인지 확인합니다. 업데이트가 성공적으로 실행되면 출력에 AllNodesAtLatestRevision이 표시됩니다. 

      AllNodesAtLatestRevision
3 nodes are at revision 7
      1
      Copy to Clipboard Toggle word wrap
      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
      Copy to Clipboard Toggle word wrap

      다음 명령을 실행하여 모든 노드가 최신 버전으로 업데이트되었는지 확인합니다. 

      $ oc get kubecontrollermanager -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'
      Copy to Clipboard Toggle word wrap

      NodeInstallerProgressing 상태 조건을 확인하고 모든 노드가 최신 버전인지 확인합니다. 업데이트가 성공적으로 실행되면 출력에 AllNodesAtLatestRevision이 표시됩니다. 

      AllNodesAtLatestRevision
3 nodes are at revision 7
      1
      Copy to Clipboard Toggle word wrap
      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
      Copy to Clipboard Toggle word wrap

      다음 명령을 실행하여 모든 노드가 최신 버전으로 업데이트되었는지 확인합니다. 

      $ oc get kubescheduler -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'
      Copy to Clipboard Toggle word wrap

      NodeInstallerProgressing 상태 조건을 확인하고 모든 노드가 최신 버전인지 확인합니다. 업데이트가 성공적으로 실행되면 출력에 AllNodesAtLatestRevision이 표시됩니다. 

      AllNodesAtLatestRevision
3 nodes are at revision 7
      1
      Copy to Clipboard Toggle word wrap
      1
      이 예에서 최신 버전 번호는 7입니다.

      출력에 2 nodes are at revision 6; 1 nodes are at revision 7와 같은 여러 버전 번호가 표시되면 이는 업데이트가 아직 진행 중임을 의미합니다. 몇 분 기다린 후 다시 시도합니다.

  23. 다음 명령을 실행하여 플랫폼 Operator를 모니터링합니다. 

    $ oc adm wait-for-stable-cluster
    Copy to Clipboard Toggle word wrap

    이 프로세스는 최대 15분이 걸릴 수 있습니다.

  24. 복구 절차에 따라 모든 워크로드가 정상 작업으로 돌아가도록 모든 컨트롤 플레인 노드를 다시 시작합니다.

    참고

    이전 절차 단계를 완료하면 모든 서비스가 복원된 상태로 돌아올 때까지 몇 분 정도 기다려야 할 수 있습니다. 예를 들어, OAuth 서버 pod가 다시 시작될 때까지 oc login을 사용한 인증이 즉시 작동하지 않을 수 있습니다.

    즉각적인 인증을 위해 system:admin kubeconfig 파일을 사용하는 것이 좋습니다. 이 방법은 OAuth 토큰에 대해 SSL/TLS 클라이언트 인증서에 대한 인증을 기반으로 합니다. 다음 명령을 실행하여 이 파일로 인증할 수 있습니다. 

    $ export KUBECONFIG=<installation_directory>/auth/kubeconfig
    Copy to Clipboard Toggle word wrap

    다음 명령을 실행하여 인증된 사용자 이름을 표시합니다. 

    $ oc whoami
    Copy to Clipboard Toggle word wrap
  25. 롤링 방식으로 모든 작업자 노드를 재시작합니다.

5.12.8. 영구 스토리지 상태 복원을 위한 문제 및 해결 방법
링크 복사

OpenShift Container Platform 클러스터에서 모든 형식의 영구저장장치를 사용하는 경우 일반적으로 클러스터의 상태가 etcd 외부에 저장됩니다. etcd 백업에서 복원하면 OpenShift Container Platform의 워크로드 상태도 복원됩니다. 그러나 etcd 스냅샷이 오래된 경우 상태가 유효하지 않거나 오래되었을 수 있습니다.

중요

PV(영구 볼륨)의 내용은 etcd 스냅샷의 일부가 아닙니다. etcd 스냅샷에서 OpenShift Container Platform 클러스터를 복원할 때 중요하지 않은 워크로드가 중요한 데이터에 액세스할 수 있으며 그 반대의 경우로도 할 수 있습니다.

다음은 사용되지 않는 상태를 생성하는 몇 가지 예제 시나리오입니다.

  • MySQL 데이터베이스는 PV 오브젝트에서 지원하는 pod에서 실행됩니다. etcd 스냅샷에서 OpenShift Container Platform을 복원해도 스토리지 공급자의 볼륨을 다시 가져오지 않으며 pod를 반복적으로 시작하려고 하지만 실행 중인 MySQL pod는 생성되지 않습니다. 스토리지 공급자에서 볼륨을 복원한 다음 새 볼륨을 가리키도록 PV를 편집하여 이 Pod를 수동으로 복원해야 합니다.
  • Pod P1에서는 노드 X에 연결된 볼륨 A를 사용합니다. 다른 pod가 노드 Y에서 동일한 볼륨을 사용하는 동안 etcd 스냅샷을 가져오는 경우 etcd 복원이 수행되면 해당 볼륨이 여전히 Y 노드에 연결되어 있으므로 Pod P1이 제대로 시작되지 않을 수 있습니다. OpenShift Container Platform은 연결을 인식하지 못하고 자동으로 연결을 분리하지 않습니다. 이 경우 볼륨이 노드 X에 연결된 다음 Pod P1이 시작될 수 있도록 노드 Y에서 볼륨을 수동으로 분리해야 합니다.
  • etcd 스냅샷을 만든 후 클라우드 공급자 또는 스토리지 공급자 인증 정보가 업데이트되었습니다. 이로 인해 해당 인증 정보를 사용하는 CSI 드라이버 또는 Operator가 작동하지 않습니다. 해당 드라이버 또는 Operator에 필요한 인증 정보를 수동으로 업데이트해야 할 수 있습니다.

  • etcd 스냅샷을 만든 후 OpenShift Container Platform 노드에서 장치가 제거되거나 이름이 변경됩니다. Local Storage Operator는 /dev/disk/by-id 또는 /dev 디렉터리에서 관리하는 각 PV에 대한 심볼릭 링크를 생성합니다. 이 경우 로컬 PV가 더 이상 존재하지 않는 장치를 참조할 수 있습니다.

    이 문제를 해결하려면 관리자가 다음을 수행해야 합니다.

    1. 잘못된 장치가 있는 PV를 수동으로 제거합니다.
    2. 각 노드에서 심볼릭 링크를 제거합니다.
    3. LocalVolume 또는 LocalVolumeSet 오브젝트를 삭제합니다 (스토리지 → 영구 스토리지 구성 → 로컬 볼륨을 사용하는 영구 스토리지 → Local Storage Operator 리소스 삭제참조).

5.13. Pod 중단 예산
링크 복사

Pod 중단 예산을 이해하고 구성합니다.

5.13.1. Pod 중단 예산을 사용하여 실행 중인 pod 수를 지정하는 방법
링크 복사

Pod 중단 예산을 사용하면 유지보수를 위해 노드를 드레이닝하는 등 작업 중에 Pod에 대한 보안 제약 조건을 지정할 수 있습니다.

PodDisruptionBudget은 동시에 작동해야 하는 최소 복제본 수 또는 백분율을 지정하는 API 오브젝트입니다. 프로젝트에서 이러한 설정은 노드 유지 관리 (예: 클러스터 축소 또는 클러스터 업그레이드) 중에 유용할 수 있으며 (노드 장애 시가 아니라) 자발적으로 제거된 경우에만 적용됩니다.

PodDisruptionBudget 오브젝트의 구성은 다음과 같은 주요 부분으로 구성되어 있습니다.

  • 일련의 pod에 대한 라벨 쿼리 기능인 라벨 선택기입니다.

  • 동시에 사용할 수 있어야 하는 최소 pod 수를 지정하는 가용성 수준입니다.

    • minAvailable은 중단 중에도 항상 사용할 수 있어야하는 pod 수입니다.
    • maxUnavailable은 중단 중에 사용할 수없는 pod 수입니다.
참고

available 은 조건이 Ready=True 인 Pod 수를 나타냅니다. ready=True 는 요청을 제공할 수 있는 Pod를 나타내며 일치하는 모든 서비스의 로드 밸런싱 풀에 추가해야 합니다.

maxUnavailable 0 % 또는 0이나 minAvailable의 100 % 혹은 복제본 수와 동일한 값은 허용되지만 이로 인해 노드가 드레인되지 않도록 차단할 수 있습니다.

주의

maxUnavailable 의 기본 설정은 OpenShift Container Platform의 모든 머신 구성 풀에 대해 1 입니다. 이 값을 변경하지 않고 한 번에 하나의 컨트롤 플레인 노드를 업데이트하는 것이 좋습니다. 컨트롤 플레인 풀의 경우 이 값을 3 으로 변경하지 마십시오.

다음을 사용하여 모든 프로젝트에서 pod 중단 예산을 확인할 수 있습니다. 

$ oc get poddisruptionbudget --all-namespaces
Copy to Clipboard Toggle word wrap
참고

다음 예제에는 AWS의 OpenShift Container Platform과 관련된 몇 가지 값이 포함되어 있습니다.

출력 예

NAMESPACE                              NAME                                    MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
openshift-apiserver                    openshift-apiserver-pdb                 N/A             1                 1                     121m
openshift-cloud-controller-manager     aws-cloud-controller-manager            1               N/A               1                     125m
openshift-cloud-credential-operator    pod-identity-webhook                    1               N/A               1                     117m
openshift-cluster-csi-drivers          aws-ebs-csi-driver-controller-pdb       N/A             1                 1                     121m
openshift-cluster-storage-operator     csi-snapshot-controller-pdb             N/A             1                 1                     122m
openshift-cluster-storage-operator     csi-snapshot-webhook-pdb                N/A             1                 1                     122m
openshift-console                      console                                 N/A             1                 1                     116m
#...
Copy to Clipboard Toggle word wrap

PodDisruptionBudget은 시스템에서 최소 minAvailable pod가 실행중인 경우 정상으로 간주됩니다. 이 제한을 초과하는 모든 pod는 제거할 수 있습니다.

참고

Pod 우선 순위 및 선점 설정에 따라 우선 순위가 낮은 pod는 pod 중단 예산 요구 사항을 무시하고 제거될 수 있습니다.

5.13.2. Pod 중단 예산을 사용하여 실행해야 할 pod 수 지정
링크 복사

PodDisruptionBudget 오브젝트를 사용하여 동시에 가동되어야 하는 최소 복제본 수 또는 백분율을 지정할 수 있습니다.

프로세스

pod 중단 예산을 구성하려면 다음을 수행합니다.

  1. 다음과 같은 오브젝트 정의를 사용하여 YAML 파일을 만듭니다. 

    apiVersion: policy/v1
    1 
    
kind: PodDisruptionBudget
metadata:
  name: my-pdb
spec:
  minAvailable: 2
    2 
    
  selector:
    3 
    
    matchLabels:
      name: my-pod
    Copy to Clipboard Toggle word wrap
    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
    Copy to Clipboard Toggle word wrap
    1
    PodDisruptionBudget 은 policy/v1 API 그룹의 일부입니다.
    2
    동시에 사용할 수없는 최대 pod 수입니다. 정수 또는 백분율 (예: 20 %)을 지정하는 문자열을 사용할 수 있습니다.
    3
    리소스 집합에 대한 라벨 쿼리입니다. matchLabels 및 matchExpressions의 결과는 논리적으로 결합됩니다. 프로젝트의 모든 포드를 선택하려면 이 매개변수(예: selector {} )를 비워 둡니다.

  2. 다음 명령을 실행하여 오브젝트를 프로젝트에 추가합니다. 

    $ oc create -f </path/to/file> -n <project_name>
    Copy to Clipboard Toggle word wrap

5.13.3. 비정상 Pod의 제거 정책 지정
링크 복사

PDB(Pod 중단 예산)를 사용하여 동시에 사용할 수 있는 Pod 수를 지정하는 경우 비정상 Pod를 제거로 간주하는 방법에 대한 기준을 정의할 수도 있습니다.

다음 정책 중 하나를 선택할 수 있습니다.

IfHealthyBudget
아직 정상이 아닌 실행 중인 Pod는 보호된 애플리케이션이 중단되지 않는 경우에만 제거할 수 있습니다.
AlwaysAllow

아직 정상이 아닌 Pod 실행은 Pod 중단 예산의 기준이 충족되었는지 여부와 관계없이 제거할 수 있습니다. 이 정책은 CrashLoopBackOff 상태에 있거나 Ready 상태를 보고하지 못하는 Pod와 같은 오작동 애플리케이션을 제거하는 데 도움이 될 수 있습니다.

참고

노드 드레이닝 중 잘못된 애플리케이션 제거를 지원하기 위해 PodDisruptionBudget 오브젝트에서 unhealthyPodEvictionPolicy 필드를 AlwaysAllow 로 설정하는 것이 좋습니다. 기본 동작은 드레이닝을 진행하기 전에 애플리케이션 Pod가 정상 상태가 될 때까지 기다리는 것입니다.

프로세스

  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
    Copy to Clipboard Toggle word wrap

    1
    비정상 Pod 제거 정책으로 IfHealthyBudget 또는 AlwaysAllow 중 하나를 선택합니다. unhealthyPodEvictionPolicy 필드가 비어 있는 경우 기본값은 IfHealthyBudget 입니다.

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

    $ oc create -f pod-disruption-budget.yaml
    Copy to Clipboard Toggle word wrap

AlwaysAllow 비정상적인 Pod 제거 정책이 설정된 PDB를 사용하면 노드를 드레이닝하고 이 PDB에 의해 보호되는 오작동 애플리케이션에 대한 Pod를 제거할 수 있습니다.

6장. 설치 노드 작업 후
링크 복사

OpenShift Container Platform을 설치한 후 특정 노드 작업을 통해 요구 사항에 맞게 클러스터를 추가로 확장하고 사용자 지정할 수 있습니다.

6.1. OpenShift Container Platform 클러스터에 RHEL 컴퓨팅 머신 추가
링크 복사

RHEL 컴퓨팅 노드를 이해하고 사용합니다.

6.1.1. 클러스터에 RHEL 컴퓨팅 노드 추가 정보
링크 복사

OpenShift Container Platform 4.16에서는 x86_64 아키텍처에서 사용자 프로비저닝 또는 설치 관리자 프로비저닝 인프라 설치를 사용하는 경우 RHEL (Red Hat Enterprise Linux) 머신을 클러스터의 컴퓨팅 머신으로 사용하는 옵션이 있습니다. 클러스터의 컨트롤 플레인 시스템에 RHCOS(Red Hat Enterprise Linux CoreOS) 시스템을 사용해야 합니다.

클러스터에서 RHEL 컴퓨팅 머신을 사용하도록 선택하는 경우 모든 운영 체제의 라이프 사이클 관리 및 유지 관리를 담당합니다. 시스템 업데이트를 수행하고 패치를 적용하고 기타 모든 필수 작업을 완료해야 합니다.

설치 관리자가 프로비저닝한 인프라 클러스터의 경우 기본적으로 RHCOS(Red Hat Enterprise Linux CoreOS) 컴퓨팅 머신이 추가되므로 설치 관리자가 프로비저닝한 인프라 클러스터의 경우 RHEL 컴퓨팅 머신을 수동으로 추가해야 합니다.

중요
  • 클러스터의 시스템에서 OpenShift Container Platform을 제거하려면 운영 체제를 제거해야하므로 클러스터에 추가한 모든 RHEL 머신에 전용 하드웨어를 사용해야합니다.
  • OpenShift Container Platform 클러스터에 추가한 모든 RHEL 머신에서 스왑 메모리가 비활성화됩니다. 이 머신에서 스왑 메모리를 활성화할 수 없습니다.
  • 패키지 기반 RHEL의 설치는 더 이상 사용되지 않습니다. RHEL은 향후 릴리스에서 제거될 예정입니다. RHCOS 이미지 계층화는 이 기능을 대체하며 컴퓨팅 노드의 기본 운영 체제에 추가 패키지 설치를 지원합니다.

6.1.2. RHEL 컴퓨팅 노드의 시스템 요구 사항
링크 복사

OpenShift Container Platform 환경의 RHEL(Red Hat Enterprise Linux) 컴퓨팅 머신 호스트는 다음과 같은 최소 하드웨어 사양 및 시스템 수준 요구 사항을 충족해야 합니다.

  • Red Hat 계정에 유효한 OpenShift Container Platform 서브스크립션이 있어야합니다. 서브스크립션이 없는 경우 영업 담당자에게 자세한 내용을 문의하십시오.
  • 프로덕션 환경에서 예상 워크로드를 지원할 수 있는 컴퓨팅 머신을 제공해야합니다. 클러스터 관리자는 예상 워크로드를 계산하고 오버 헤드에 약 10%를 추가해야합니다. 프로덕션 환경의 경우 노드 호스트 장애가 최대 용량에 영향을 미치지 않도록 충분한 리소스를 할당해야 합니다.

  • 각 시스템은 다음 하드웨어 요구 사항을 충족해야합니다.

    • 물리적 또는 가상 시스템 또는 퍼블릭 또는 프라이빗 IaaS에서 실행되는 인스턴스.

    • 기본 운영 체제: 최소 설치 옵션으로 RHEL 8.8 이상 버전을 사용합니다.

      중요

      OpenShift Container Platform 클러스터에 RHEL 7 컴퓨팅 머신을 추가하는 것은 지원되지 않습니다.

      이전 OpenShift Container Platform 버전에서 이전에 지원되는 RHEL 7 컴퓨팅 머신이 있는 경우 RHEL 8로 업그레이드할 수 없습니다. 새 RHEL 8 호스트를 배포해야 하며 이전 RHEL 7 호스트를 제거해야 합니다. 자세한 내용은 "노드 삭제" 섹션을 참조하십시오.

      OpenShift Container Platform에서 더 이상 사용되지 않거나 삭제된 주요 기능의 최신 목록은 OpenShift Container Platform 릴리스 노트에서 더 이상 사용되지 않고 삭제된 기능 섹션을 참조하십시오.

    • FIPS 모드에서 OpenShift Container Platform을 배포하는 경우 부팅하기 전에 RHEL 시스템에서 FIPS를 활성화해야합니다. RHEL 8 설명서에서 FIPS 모드가 활성화된 RHEL 8 시스템 설치를 참조하십시오.

      중요

      클러스터의 FIPS 모드를 활성화하려면 FIPS 모드에서 작동하도록 구성된 RHEL(Red Hat Enterprise Linux) 컴퓨터에서 설치 프로그램을 실행해야 합니다. RHEL에서 FIPS 모드를 구성하는 방법에 대한 자세한 내용은 RHEL을 FIPS 모드로 전환 을 참조하십시오.

      FIPS 모드에서 부팅된 RHEL(Red Hat Enterprise Linux CoreOS) 또는 RHCOS(Red Hat Enterprise Linux CoreOS)를 실행하는 경우 OpenShift Container Platform 코어 구성 요소는 x86_64, ppc64le 및 s390x 아키텍처에서만 FIPS 140-2/140-3 Validation에 대해 NIST에 제출된 RHEL 암호화 라이브러리를 사용합니다.

    • NetworkManager 1.0 이상
    • vCPU 1개
    • 최소 8GB RAM
    • /var/를 포함하는 파일 시스템의 최소 15GB 하드 디스크 공간
    • /usr/local/bin/을 포함하는 파일 시스템의 최소 1GB 하드 디스크 공간
    • 임시 디렉토리를 포함하는 파일 시스템의 최소 1GB의 하드 디스크 공간 임시 시스템 디렉토리는 Python 표준 라이브러리의 tempfile 모듈에 정의된 규칙에 따라 결정됩니다.
  • 각 시스템은 시스템 제공 업체의 추가 요구 사항을 충족해야합니다. 예를 들어 VMware vSphere에 클러스터를 설치하는 경우 스토리지 지침에 따라 디스크를 구성하고 disk.enableUUID=TRUE 속성을 설정해야 합니다.
  • 각 시스템은 DNS 확인 가능한 호스트 이름을 사용하여 클러스터의 API 끝점에 액세스할 수 있어야 합니다. 모든 네트워크 보안 액세스 제어는 클러스터의 API 서비스 엔드 포인트에 대한 시스템 액세스를 허용해야합니다.

  • Microsoft Azure에 설치된 클러스터의 경우:

    • 시스템에 Standard_D8s_v3 가상 시스템의 하드웨어 요구 사항이 포함되어 있는지 확인합니다.
    • 가속 네트워킹을 활성화합니다. 가속화 네트워킹은 단일 루트 I/O 가상화(SR-IOV)를 사용하여 Microsoft Azure VM에 더 직접적인 전환 경로를 제공합니다.
6.1.2.1. 인증서 서명 요청 관리
링크 복사

사용자가 프로비저닝하는 인프라를 사용하는 경우 자동 시스템 관리 기능으로 인해 클러스터의 액세스가 제한되므로 설치한 후 클러스터 인증서 서명 요청(CSR)을 승인하는 메커니즘을 제공해야 합니다. kube-controller-manager는 kubelet 클라이언트 CSR만 승인합니다. machine-approver는 올바른 시스템에서 발행한 요청인지 확인할 수 없기 때문에 kubelet 자격 증명을 사용하여 요청하는 서비스 인증서의 유효성을 보장할 수 없습니다. kubelet 서비스 인증서 요청의 유효성을 확인하고 요청을 승인할 방법을 결정하여 구현해야 합니다.

6.1.3. Playbook 실행을 위한 머신 준비
링크 복사

RHEL(Red Hat Enterprise Linux)을 운영 체제로 사용하는 컴퓨팅 머신을 OpenShift Container Platform 4.16 클러스터에 추가하려면 먼저 클러스터에 새 노드를 추가하는 Ansible 플레이북을 실행하도록 RHEL 8 머신을 준비해야 합니다. 이 머신은 클러스터의 일부가 아니지만 클러스터에 액세스할 수 있어야합니다.

전제 조건

  • Playbook을 실행하는 머신에 OpenShift CLI (oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

프로세스

  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>
      Copy to Clipboard Toggle word wrap

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

      # subscription-manager refresh
      Copy to Clipboard Toggle word wrap

    3. 사용 가능한 서브스크립션을 나열하십시오. 

      # subscription-manager list --available --matches '*OpenShift*'
      Copy to Clipboard Toggle word wrap

    4. 이전 명령의 출력에서 OpenShift Container Platform 서브스크립션의 풀 ID를 찾아서 이를 연결합니다. 

      # subscription-manager attach --pool=<pool_id>
      Copy to Clipboard Toggle word wrap

  5. OpenShift Container Platform 4.16에 필요한 리포지토리를 활성화합니다. 

    # subscription-manager repos \
    --enable="rhel-8-for-x86_64-baseos-rpms" \
    --enable="rhel-8-for-x86_64-appstream-rpms" \
    --enable="rhocp-4.16-for-rhel-8-x86_64-rpms"
    Copy to Clipboard Toggle word wrap

  6. openshift-ansible을 포함한 필수 패키지를 설치합니다. 

    # yum install openshift-ansible openshift-clients jq
    Copy to Clipboard Toggle word wrap

    openshift-ansible 패키지는 설치 프로그램 유틸리티를 제공하고 Ansible, Playbook 및 관련 구성 파일과 같이 RHEL 컴퓨팅 노드를 클러스터에 추가하는데 필요한 다른 패키지를 가져옵니다. openshift-clients는 oc CLI를 제공하고 jq 패키지는 명령 행에서 JSON 출력 표시 방법을 개선할 수 있습니다.

6.1.4. RHEL 컴퓨팅 노드 준비
링크 복사

RHEL (Red Hat Enterprise Linux) 시스템을 OpenShift Container Platform 클러스터에 추가하기 전에 각 호스트를 RHSM (Red Hat Subscription Manager)에 등록하고 활성 OpenShift Container Platform 서브스크립션을 연결하고 필요한 저장소를 활성화해야합니다.

  1. 각 호스트에서 RHSM으로 동륵합니다. 

    # subscription-manager register --username=<user_name> --password=<password>
    Copy to Clipboard Toggle word wrap

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

    # subscription-manager refresh
    Copy to Clipboard Toggle word wrap

  3. 사용 가능한 서브스크립션을 나열하십시오. 

    # subscription-manager list --available --matches '*OpenShift*'
    Copy to Clipboard Toggle word wrap

  4. 이전 명령의 출력에서 OpenShift Container Platform 서브스크립션의 풀 ID를 찾아서 이를 연결합니다. 

    # subscription-manager attach --pool=<pool_id>
    Copy to Clipboard Toggle word wrap

  5. 모든 yum 저장소를 비활성화합니다.

    1. 활성화된 모든 RHSM 저장소를 비활성화합니다. 

      # subscription-manager repos --disable="*"
      Copy to Clipboard Toggle word wrap

    2. 나머지 yum 저장소를 나열하고 repo id 아래에 해당 이름을 적어 둡니다. 

      # yum repolist
      Copy to Clipboard Toggle word wrap

    3. yum-config-manager를 사용하여 나머지 yum 리포지토리를 비활성화합니다. 

      # yum-config-manager --disable <repo_id>
      Copy to Clipboard Toggle word wrap

      또는 모든 리포지토리를 비활성화합니다. 

      # yum-config-manager --disable \*
      Copy to Clipboard Toggle word wrap

      사용 가능한 리포지토리가 많으면 몇 분의 시간이 소요될 수 있습니다.

  6. OpenShift Container Platform 4.16에 필요한 리포지토리를 활성화합니다. 

    # subscription-manager repos \
    --enable="rhel-8-for-x86_64-baseos-rpms" \
    --enable="rhel-8-for-x86_64-appstream-rpms" \
    --enable="rhocp-4.16-for-rhel-8-x86_64-rpms" \
    --enable="fast-datapath-for-rhel-8-x86_64-rpms"
    Copy to Clipboard Toggle word wrap

  7. 호스트에서 firewalld를 중지하고 비활성화합니다. 

    # systemctl disable --now firewalld.service
    Copy to Clipboard Toggle word wrap
    참고

    나중에 firewalld를 활성화할 수 없습니다. 활성화하면 작업자의 OpenShift Container Platform 로그에 액세스할 수 없습니다.

6.1.5. 클러스터에 RHEL 컴퓨팅 머신 추가
링크 복사

Red Hat Enterprise Linux를 운영 체제로 사용하는 컴퓨팅 머신을 OpenShift Container Platform 4.16 클러스터에 추가할 수 있습니다.

사전 요구 사항

  • Playbook을 실행하는 머신에 필요한 패키지를 설치하고 필요한 구성이 수행되어 있습니다.
  • RHEL 호스트 설치가 준비되어 있습니다.

프로세스

Playbook을 실행할 준비가 되어 있는 머신에서 다음 단계를 수행합니다.

  1. 컴퓨팅 머신 호스트 및 필수 변수를 정의하는 /<path>/inventory/hosts라는 Ansible 인벤토리 파일을 만듭니다. 

    [all:vars]
ansible_user=root
    1 
    
#ansible_become=True
    2 
    

openshift_kubeconfig_path="~/.kube/config"
    3 
    

[new_workers]
    4 
    
mycluster-rhel8-0.example.com
mycluster-rhel8-1.example.com
    Copy to Clipboard Toggle word wrap
    1
    원격 컴퓨팅 머신에서 Ansible 태스크를 실행하는 사용자 이름을 지정합니다.
    2
    ansible_user의 root를 지정하지 않으면 ansible_become을 True로 설정하고 사용자 sudo 권한을 지정해야합니다.
    3
    클러스터 kubeconfig 파일의 경로와 파일 이름을 지정합니다.
    4
    클러스터에 추가할 각 RHEL 머신을 나열합니다. 각 호스트에 대해 정규화된 도메인 이름을 지정해야합니다. 이 이름은 클러스터가 시스템에 액세스하는 데 사용하는 호스트 이름이므로 올바른 공용 또는 개인 이름을 설정하여 시스템에 액세스합니다.

  2. Ansible Playbook 디렉토리로 이동합니다. 

    $ cd /usr/share/ansible/openshift-ansible
    Copy to Clipboard Toggle word wrap

  3. Playbook을 실행합니다. 

    $ ansible-playbook -i /<path>/inventory/hosts playbooks/scaleup.yml
    1
    Copy to Clipboard Toggle word wrap
    1
    <path>에 대해 생성한 Ansible 인벤토리 파일의 경로를 지정합니다.

6.1.6. Ansible 호스트 파일의 필수 매개 변수
링크 복사

RHEL (Red Hat Enterprise Linux) 컴퓨팅 머신을 클러스터에 추가하기 전에 Ansible 호스트 파일에서 다음 매개 변수를 정의해야합니다.

Expand
매개변수설명값

ansible_user

암호없이 SSH 기반 인증을 허용하는 SSH 사용자입니다. SSH 키 기반 인증을 사용하는 경우 SSH 에이전트를 사용하여 키를 관리해야합니다.

시스템의 사용자 이름입니다. 기본값은 root입니다.

ansible_become

ansible_user 값이 root가 아닌 경우 ansible_become을 True로 설정하고 ansible_user로 지정하는 사용자는 암호없이 sudo 액세스를 구성해야합니다.

True. 값이 True 가 아닌 경우 이 매개 변수를 지정하거나 정의하지 마십시오.

openshift_kubeconfig_path

클러스터의 kubeconfig 파일이 포함된 로컬 디렉토리의 경로와 파일 이름을 지정합니다.

구성 파일의 경로 및 이름

6.1.7. 선택 사항: 클러스터에서 RHCOS 컴퓨팅 머신 제거
링크 복사

RHEL (Red Hat Enterprise Linux) 컴퓨팅 머신을 클러스터에 추가 한 후 선택 옵션으로 RHCOS (Red Hat Enterprise Linux CoreOS) 컴퓨팅 머신을 제거하여 리소스를 확보할 수 있습니다.

전제 조건

  • RHEL 컴퓨팅 머신이 클러스터에 추가되어 있습니다.

프로세스

  1. 머신 목록을 표시하고 RHCOS 컴퓨팅 머신의 노드 이름을 기록합니다. 

    $ oc get nodes -o wide
    Copy to Clipboard Toggle word wrap

  2. 각 RHCOS 컴퓨팅 머신의 노드를 제거합니다.

    1. oc adm cordon 명령을 실행하여 노드를 스케줄 예약 해제로 표시합니다. 

      $ oc adm cordon <node_name>
      1
      Copy to Clipboard Toggle word wrap
      1
      RHCOS 컴퓨팅 머신의 노드 이름을 지정합니다.

    2. 노드에서 모든 pod를 드레인합니다. 

      $ oc adm drain <node_name> --force --delete-emptydir-data --ignore-daemonsets
      1
      Copy to Clipboard Toggle word wrap
      1
      분리 한 RHCOS 컴퓨팅 머신의 노드 이름을 지정합니다.

    3. 노드를 제거합니다. 

      $ oc delete nodes <node_name>
      1
      Copy to Clipboard Toggle word wrap
      1
      드레인한 RHCOS 컴퓨팅 머신의 노드 이름을 지정합니다.

  3. 컴퓨팅 머신 목록을 확인하고 RHEL 노드만 남아 있는지 확인합니다. 

    $ oc get nodes -o wide
    Copy to Clipboard Toggle word wrap
  4. 클러스터 컴퓨팅 머신의 로드 밸런서에서 RHCOS 머신을 제거합니다. 가상 머신을 삭제하거나 RHCOS 컴퓨팅 머신의 실제 하드웨어를 다시 이미지화 할 수 있습니다.

6.2. OpenShift Container Platform 클러스터에 RHCOS 컴퓨팅 머신 추가
링크 복사

베어 메탈의 OpenShift Container Platform 클러스터에 더 많은 Red Hat Enterprise Linux CoreOS (RHCOS) 컴퓨팅 머신을 추가할 수 있습니다.

베어메탈 인프라에 설치된 클러스터에 컴퓨팅 머신을 추가하기 전에 사용할 RHCOS 머신을 생성해야 합니다. ISO 이미지 또는 네트워크 PXE 부팅을 사용하여 시스템을 생성합니다.

6.2.1. 사전 요구 사항
링크 복사

  • 베어 메탈에 클러스터가 설치되어 있어야 합니다.
  • 클러스터를 만드는 데 사용한 설치 미디어 및 Red Hat Enterprise Linux CoreOS (RHCOS) 이미지가 있습니다. 이러한 파일이 없는 경우 설치 절차에 따라 파일을 가져와야 합니다.

6.2.2. ISO 이미지를 사용하여 RHCOS 머신 생성
링크 복사

ISO 이미지를 사용하여 머신을 생성함으로써 베어 메탈 클러스터에 대해 더 많은 Red Hat Enterprise Linux CoreOS (RHCOS) 컴퓨팅 머신을 생성할 수 있습니다.

사전 요구 사항

  • 클러스터의 컴퓨팅 머신에 대한 Ignition 구성 파일의 URL을 가져옵니다. 설치 중에 이 파일은 HTTP 서버에 업로드되어 있어야 합니다.
  • OpenShift CLI(oc)가 설치되어 있어야 합니다.

프로세스

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

    $ oc extract -n openshift-machine-api secret/worker-user-data-managed --keys=userData --to=- > worker.ign
    Copy to Clipboard Toggle word wrap
  2. 클러스터에서 내보낸 worker.ign Ignition 구성 파일을 HTTP 서버로 업로드합니다. 해당 파일의 URL을 기록해 둡니다.

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

    $ curl -k http://<HTTP_server>/worker.ign
    Copy to Clipboard Toggle word wrap

  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')
    Copy to Clipboard Toggle word wrap

  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>
    1
    2
    Copy to Clipboard Toggle word wrap
    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/worker.ign /dev/sda --ignition-hash=sha512-a5a2d43879223273c9b60af66b44202a1d1248fc01cf156c46d4a79f552b6bad47bc8cc78ddf0116e80c59d2ea9e32ba53bc807afbca581aa059311def2c3e3b
    Copy to Clipboard Toggle word wrap

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

    중요

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

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

6.2.3. PXE 또는 iPXE 부팅을 통해 RHCOS 머신 생성
링크 복사

PXE 또는 iPXE 부팅을 사용하여 베어 메탈 클러스터에 대해 추가 Red Hat Enterprise Linux CoreOS (RHCOS) 컴퓨팅 머신을 생성할 수 있습니다.

사전 요구 사항

  • 클러스터의 컴퓨팅 머신에 대한 Ignition 구성 파일의 URL을 가져옵니다. 설치 중에 이 파일은 HTTP 서버에 업로드되어 있어야 합니다.
  • 클러스터 설치 중에 HTTP 서버에 업로드 한 RHCOS ISO 이미지, 압축된 메탈 BIOS, kernel 및 initramfs 파일의 URL을 가져옵니다.
  • 설치 중에 OpenShift Container Platform 클러스터에 대한 머신을 생성하는 데 사용한 PXE 부팅 인프라에 액세스할 수 있습니다. RHCOS가 설치된 후 로컬 디스크에서 머신을 부팅해야합니다.
  • UEFI를 사용하는 경우 OpenShift Container Platform 설치 중에 수정 한 grub.conf 파일에 액세스할 수 있습니다.

프로세스

  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
      Copy to Clipboard Toggle word wrap
      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
      Copy to Clipboard Toggle word wrap
      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 
      
}
      Copy to Clipboard Toggle word wrap
      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 인프라를 사용하여 클러스터에 필요한 컴퓨팅 머신을 만듭니다.

6.2.4. 시스템의 인증서 서명 요청 승인
링크 복사

클러스터에 시스템을 추가하면 추가한 시스템별로 보류 중인 인증서 서명 요청(CSR)이 두 개씩 생성됩니다. 이러한 CSR이 승인되었는지 확인해야 하며, 필요한 경우 이를 직접 승인해야 합니다. 클라이언트 요청을 먼저 승인한 다음 서버 요청을 승인해야 합니다.

사전 요구 사항

  • 클러스터에 시스템을 추가했습니다.

프로세스

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

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME      STATUS    ROLES   AGE  VERSION
master-0  Ready     master  63m  v1.29.4
master-1  Ready     master  63m  v1.29.4
master-2  Ready     master  64m  v1.29.4
    Copy to Clipboard Toggle word wrap

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

    참고

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

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

    $ oc get csr
    Copy to Clipboard Toggle word wrap

    출력 예

    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
...
    Copy to Clipboard Toggle word wrap

    예에서는 두 시스템이 클러스터에 참여하고 있습니다. 목록에는 승인된 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
      Copy to Clipboard Toggle word wrap
      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
      Copy to Clipboard Toggle word wrap
      참고

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

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

    $ oc get csr
    Copy to Clipboard Toggle word wrap

    출력 예

    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
...
    Copy to Clipboard Toggle word wrap

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

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

      $ oc adm certificate approve <csr_name>
      1
      Copy to Clipboard Toggle word wrap
      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
      Copy to Clipboard Toggle word wrap

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

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME      STATUS    ROLES   AGE  VERSION
master-0  Ready     master  73m  v1.29.4
master-1  Ready     master  73m  v1.29.4
master-2  Ready     master  74m  v1.29.4
worker-0  Ready     worker  11m  v1.29.4
worker-1  Ready     worker  11m  v1.29.4
    Copy to Clipboard Toggle word wrap

    참고

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

추가 정보

OpenShift Container Platform은 부트스트랩 중에 처리되는 머신 구성을 사용하여 설치 중에 장치를 분할할 수 있습니다. 그러나 /var 파티셔닝을 사용하는 경우 설치 시 장치 이름을 결정해야 하며 변경할 수 없습니다. 장치 이름 지정 스키마가 다른 경우 다른 인스턴스 유형을 노드로 추가할 수 없습니다. 예를 들어 m4.large 인스턴스 dev/xvdb 의 기본 AWS 장치 이름으로 /var 파티션을 구성한 경우 AWS m5.large 인스턴스를 직접 추가할 수 없습니다. m5.large 인스턴스는 기본적으로 /dev/nvme1n1 장치를 사용합니다. 다른 이름 지정 스키마로 인해 장치가 파티션하지 못할 수 있습니다.

이 섹션의 절차에서는 설치 시 구성된 장치와 다른 장치 이름을 사용하는 인스턴스에 RHCOS(Red Hat Enterprise Linux CoreOS) 컴퓨팅 노드를 추가하는 방법을 보여줍니다. 사용자 지정 사용자 데이터 시크릿을 생성하고 새 컴퓨팅 머신 세트를 구성합니다. 다음 단계는 AWS 클러스터에 고유합니다. 이러한 원칙이 다른 클라우드 배포에도 적용됩니다. 그러나 장치 이름 지정 스키마는 다른 배포의 경우 다르며 상황에 따라 결정되어야 합니다.

프로세스

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

    $ oc project openshift-machine-api
    Copy to Clipboard Toggle word wrap

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

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

      $ oc get secret worker-user-data --template='{{index .data.userData | base64decode}}' | jq > userData.txt
      Copy to Clipboard Toggle word wrap

    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"
      }
    ]
  }
}
      Copy to Clipboard Toggle word wrap
      1
      AWS 블록 장치의 절대 경로를 지정합니다.
      2
      데이터 파티션의 크기를 Mebibytes로 지정합니다.
      3
      파티션의 시작을 메비바이트로 지정합니다. 데이터 파티션을 부트 디스크에 추가할 때 최소 25000MB(메비 바이트)를 사용하는 것이 좋습니다. 루트 파일 시스템은 지정된 오프셋까지 사용 가능한 모든 공간을 채우기 위해 자동으로 크기가 조정됩니다. 값이 지정되지 않거나 지정된 값이 권장 최소값보다 작으면 생성되는 루트 파일 시스템의 크기가 너무 작아지고 RHCOS를 나중에 다시 설치할 때 데이터 파티션의 첫 번째 부분을 덮어 쓸 수 있습니다.
      4
      /var 파티션의 절대 경로를 지정합니다.
      5
      파일 시스템 형식을 지정합니다.
      6
      Ignition이 실행 중인 동안 루트 파일 시스템이 마운트되는 위치와 관련하여 파일 시스템의 마운트 지점을 지정합니다. 이는 실제 루트에 마운트해야 하는 위치와 반드시 동일하지는 않지만 동일하게 설정하는 것이 좋습니다.
      7
      /dev/disk/by-partlabel/var 장치를 /var 파티션에 마운트하는 systemd 마운트 장치를 정의합니다.