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

3.5. RHEL 컴퓨팅 시스템을 포함하는 클러스터 업데이트

OpenShift Container Platform 클러스터에서 마이너 버전 및 패치 업데이트를 수행할 수 있습니다. 클러스터에 RHEL(Red Hat Enterprise Linux) 시스템이 포함된 경우 추가 단계를 수행하여 해당 머신을 업데이트해야 합니다.

중요

OpenShift Container Platform 클러스터에서 RHEL 컴퓨팅 머신 사용은 더 이상 사용되지 않으며 향후 릴리스에서 제거됩니다.

3.5.1. 사전 요구 사항

  • admin 권한이 있는 사용자로 클러스터에 액세스합니다. RBAC를 사용하여 권한 정의 및 적용을 참조하십시오.
  • 업데이트가 실패할 경우 etcd 백업이 있어야 하며 클러스터를 이전 상태로 복원해야 합니다.
  • RHEL7 작업자는 RHEL8 또는 RHCOS 작업자로 교체됩니다. Red Hat은 RHEL 작업자의 RHEL7에서 RHEL8 업데이트를 지원하지 않습니다. 해당 호스트는 완전히 새로운 운영 체제 설치로 교체되어야 합니다.
  • 클러스터에서 수동으로 유지 관리되는 인증 정보를 사용하는 경우 새 릴리스의 클라우드 공급자 리소스를 업데이트합니다. 클러스터의 요구 사항인지 확인하는 방법을 포함하여 자세한 내용은 수동으로 유지 관리되는 인증 정보를 사용하여 클러스터 업데이트 준비를 참조하십시오.
  • Operator를 실행하거나 Pod 중단 예산으로 애플리케이션을 구성한 경우 업데이트 프로세스 중에 중단이 발생할 수 있습니다. PodDisruptionBudget 에서 minAvailable 이 1로 설정된 경우 제거 프로세스를 차단할 수 있는 보류 중인 머신 구성을 적용하기 위해 노드가 드레인됩니다. 여러 노드가 재부팅되면 모든 Pod가 하나의 노드에서만 실행될 수 있으며 PodDisruptionBudget 필드에는 노드가 드레이닝되지 않을 수 있습니다.

추가 리소스

3.5.2. 웹 콘솔을 사용하여 클러스터 업데이트

사용 가능한 업데이트가 있으면 웹 콘솔에서 클러스터를 업데이트할 수 있습니다.

사용 가능한 OpenShift Container Platform 권고 및 업데이트는 고객 포털의 에라타 섹션을 참조하십시오.

사전 요구 사항

  • cluster-admin 권한이 있는 사용자로 웹 콘솔에 액세스합니다.
  • OpenShift Container Platform 웹 콘솔에 액세스할 수 있습니다.
  • 모든 MachineHealthCheck 리소스를 일시 중지합니다.
  • OLM(Operator Lifecycle Manager)을 통해 이전에 설치된 모든 Operator를 대상 릴리스와 호환되는 버전으로 업데이트했습니다. Operator를 업데이트하면 클러스터 업데이트 중에 기본 OperatorHub 카탈로그가 현재 마이너 버전에서 다음 버전으로 전환될 때 유효한 업데이트 경로가 있습니다. 호환성을 확인하는 방법과 필요한 경우 설치된 Operator를 업데이트하는 방법에 대한 자세한 내용은 "추가 리소스" 섹션에서 "설치된 Operator 업그레이드"를 참조하십시오.
  • MCP(Machine config pool)가 실행 중이고 일시 중지되지 않습니다. 업데이트 프로세스 중에 일시 중지된 MCP와 연결된 노드를 건너뜁니다. 카나리아 롤아웃 업데이트 전략을 수행하는 경우 MCP를 일시 중지할 수 있습니다.
  • RHEL7 작업자는 RHEL8 또는 RHCOS 작업자로 교체됩니다. Red Hat은 RHEL 작업자의 RHEL7에서 RHEL8 업데이트를 지원하지 않습니다. 해당 호스트는 완전히 새로운 운영 체제 설치로 교체되어야 합니다.

프로세스

  1. 웹 콘솔에서 Administration Cluster Settings을 클릭하고 Details 탭의 내용을 확인합니다.

  2. 프로덕션 클러스터의 경우 stable-4.17 과 같이 업데이트할 버전에 대해 Channel 이 올바른 채널로 설정되어 있는지 확인합니다.

    중요

    프로덕션 클러스터의 경우 stable-*, eus-* 또는 fast-* 채널에 가입해야 합니다.

    참고

    다음 마이너 버전으로 이동할 준비가 되면 해당 마이너 버전에 해당하는 채널을 선택합니다. 업데이트 채널이 더 빨리 선언될수록 클러스터가 대상 버전으로의 경로를 업데이트하는 것이 좋습니다. 클러스터는 사용 가능한 모든 업데이트를 평가하고 선택할 수 있는 최상의 업데이트 권장 사항을 제공하는 데 시간이 걸릴 수 있습니다. 업데이트 권장 사항은 당시 사용할 수 있는 업데이트 옵션을 기반으로 하므로 시간이 지남에 따라 변경될 수 있습니다.

    대상 마이너 버전에 대한 업데이트 경로가 표시되지 않는 경우 경로에서 다음 마이너 버전을 사용할 수 있을 때까지 현재 버전의 최신 패치 릴리스로 클러스터를 계속 업데이트합니다.

    • Update status 가 Updates available 이 아닌 경우 클러스터를 업데이트할 수 없습니다.
    • Select channel은 클러스터가 실행 중이거나 업데이트 중인 클러스터 버전을 나타냅니다.

  3. 업데이트할 버전을 선택하고 저장을 클릭합니다.

    입력 채널 Update Status가 Update to <product-version> in progress로 변경되고 Operator 및 노드의 진행률을 확인하여 클러스터 업데이트의 진행 상황을 검토할 수 있습니다.

    참고

    예를 들어 버전 4.10에서 4.11로 클러스터를 업데이트하는 경우 새 기능을 사용하는 워크로드를 배포하기 전에 노드가 업데이트되었는지 확인합니다. 아직 업데이트되지 않은 작업자 노드가 있는 풀은 클러스터 설정 페이지에 표시됩니다.

  4. 업데이트가 완료되고 Cluster Version Operator가 사용 가능한 업데이트를 새로 고침한 후 현재 채널에서 사용 가능한 추가 업데이트가 있는지 확인합니다.

    • 업데이트가 있는 경우 더 이상 업데이트할 수 없을 때까지 현재 채널에서 업데이트를 계속 수행합니다.
    • 사용 가능한 업데이트가 없는 경우 채널을 다음 마이너 버전의 stable-*, eus-* 또는 fast-* 채널로 변경하고 해당 채널에서 원하는 버전으로 업데이트합니다.

    필요한 버전에 도달할 때까지 여러 중간 업데이트를 수행해야 할 수도 있습니다.

    중요

    RHEL (Red Hat Enterprise Linux) 작업자 시스템이 포함된 클러스터를 업데이트하면 업데이트 프로세스 중에 해당 작업자를 일시적으로 사용할 수 없게 됩니다. 클러스터가 NotReady 상태가 되면 각 RHEL 머신에 대해 업데이트 플레이북을 실행하여 업데이트를 완료해야 합니다.

추가 리소스

3.5.3. 선택 사항: RHEL 시스템에서 Ansible 작업을 실행하기 위한 후크 추가

OpenShift Container Platform을 업데이트할 때 후크를 사용하여 RHEL 컴퓨팅 시스템에서 Ansible 작업을 실행할 수 있습니다.

3.5.3.1. 업데이트를 위한 Ansible 후크 정보

OpenShift Container Platform을 업데이트할 때 후크를 사용하여 특정 작업 중에 RHEL (Red Hat Enterprise Linux) 노드에서 사용자 정의 작업을 실행할 수 있습니다. 후크를 사용하면 특정 업데이트 작업 전후에 실행할 작업을 정의하는 파일을 지정할 수 있습니다. OpenShift Container Platform 클러스터에서 RHEL 컴퓨팅 노드를 업데이트할 때 후크를 사용하여 사용자 정의 인프라의 유효성을 검사하거나 변경할 수 있습니다.

후크가 실패하면 작업도 실패하므로 후크를 여러 번 실행하고 동일한 결과를 얻도록 설계해야합니다.

후크에는 다음과 같은 제한이 있습니다.-후크에는 정의되거나 버전이 지정된 인터페이스가 없습니다. 후크는 내부 openshift-ansible 변수를 사용할 수 있지만 이러한 변수는 향후 OpenShift Container Platform 릴리스에서 수정되거나 제거될 수 있습니다. -후크에는 오류 처리 기능이 없으므로 후크에 오류가 발생하면 업데이트 프로세스가 중단됩니다. 오류가 발생하면 문제를 해결한 다음 업데이트를 다시 시작해야 합니다.

3.5.3.2. 후크를 사용하도록 Ansible 인벤토리 파일 설정

all : vars 섹션 아래의 hosts 인벤토리 파일에서 작업자 시스템이라고도 하는 RHEL (Red Hat Enterprise Linux) 컴퓨팅 시스템을 업데이트할 때 사용할 후크를 정의합니다.

전제 조건

  • RHEL 컴퓨팅 시스템 클러스터를 추가하는 데 사용되는 컴퓨터에 액세스할 수 있어여 합니다. RHEL 시스템을 정의하는 hosts Ansible 인벤토리 파일에 액세스할 수 있어야 합니다.

프로세스

  1. 후크를 설계한 후 Ansible 작업을 정의하는 YAML 파일을 만듭니다. 이 파일은 다음 예와 같이 Playbook이 아닌 일련의 작업으로 구성되어 있어야 합니다. 

    ---
# Trivial example forcing an operator to acknowledge the start of an upgrade
# file=/home/user/openshift-ansible/hooks/pre_compute.yml

- name: note the start of a compute machine update
  debug:
      msg: "Compute machine upgrade of {{ inventory_hostname }} is about to start"

- name: require the user agree to start an upgrade
  pause:
      prompt: "Press Enter to start the compute machine update"

  2. hosts Ansible 인벤토리 파일을 수정하여 후크 파일을 지정합니다. 후크 파일은 다음과 같이 [all : vars] 섹션에서 매개 변수 값으로 지정됩니다.

    인벤토리 파일에서 후크 정의의 예

    [all:vars]
openshift_node_pre_upgrade_hook=/home/user/openshift-ansible/hooks/pre_node.yml
openshift_node_post_upgrade_hook=/home/user/openshift-ansible/hooks/post_node.yml

    후크 경로의 모호성을 피하려면 정의에서 상대 경로 대신 절대 경로를 사용합니다.

3.5.3.3. RHEL 컴퓨팅 시스템에서 사용 가능한 후크

OpenShift Container Platform 클러스터에서 RHEL (Red Hat Enterprise Linux) 컴퓨팅 시스템을 업데이트 할 때 다음 후크를 사용할 수 있습니다.

후크 이름설명

openshift_node_pre_cordon_hook

  • 각 노드가 차단 (cordon)되기 이전에 실행됩니다.
  • 이 후크는 각 노드에 대해 연속적으로 실행됩니다.
  • 작업이 다른 호스트에서 실행되어야하는 경우 해당 작업은 delegate_to 또는 local_action을 사용해야 합니다.

openshift_node_pre_upgrade_hook

  • 각 노드가 차단(cordon)된 후 업데이트되기 전에 실행됩니다.
  • 이 후크는 각 노드에 대해 연속적으로 실행됩니다.
  • 작업이 다른 호스트에서 실행되어야하는 경우 해당 작업은 delegate_to 또는 local_action을 사용해야 합니다.

openshift_node_pre_uncordon_hook

  • 각 노드가 업데이트 된 후 차단 해제(uncordon)되기 전에 실행됩니다.
  • 이 후크는 각 노드에 대해 연속적으로 실행됩니다.
  • 작업이 다른 호스트에서 실행되어야하는 경우, 해당 작업은 delegate_to 또는 local_action을 사용해야 합니다.

openshift_node_post_upgrade_hook

  • 각 노드가 차단 해제 (uncordon) 후에 실행됩니다. 이는 마지막 노드 업데이트 작업입니다.
  • 이 후크는 각 노드에 대해 연속적으로 실행됩니다.
  • 작업이 다른 호스트에서 실행되어야하는 경우 해당 작업은 delegate_to 또는 local_action을 사용해야 합니다.

3.5.4. 클러스터에서 RHEL 컴퓨팅 시스템 업데이트

클러스터를 업데이트한 후 클러스터의 RHEL (Red Hat Enterprise Linux) 컴퓨팅 시스템을 업데이트해야합니다.

중요

RHEL (Red Hat Enterprise Linux) 버전 8.6 이상은 RHEL 컴퓨팅 머신에서 지원됩니다.

RHEL을 운영 체제로 사용하는 경우 컴퓨팅 머신을 다른 OpenShift Container Platform 마이너 버전으로 업데이트할 수도 있습니다. 마이너 버전 업데이트를 수행할 때 RHEL에서 RPM 패키지를 제외할 필요가 없습니다.

중요

RHEL 7 컴퓨팅 머신을 RHEL 8로 업데이트할 수 없습니다. 새 RHEL 8 호스트를 배포해야 하며 이전 RHEL 7 호스트를 제거해야 합니다.

사전 요구 사항

  • 클러스터가 업데이트되었습니다.

    중요

    RHEL 시스템에 업데이트 프로세스를 완료하기 위해 클러스터에서 생성한 자산이 필요하므로 RHEL 작업자 시스템을 업데이트하기 전에 클러스터를 업데이트해야 합니다.

  • RHEL 컴퓨팅 머신을 클러스터에 추가하는 데 사용한 로컬 시스템에 액세스할 수 있습니다. RHEL 시스템 및 upgrade Playbook을 정의하는 hosts Ansible 인벤토리 파일에 액세스할 수 있어야 합니다.
  • 마이너 버전을 업데이트하기 위해 RPM 리포지토리는 클러스터에서 실행 중인 동일한 버전의 OpenShift Container Platform을 사용하고 있습니다.

프로세스

  1. 호스트에서 firewalld를 중지하고 비활성화합니다. 

    # systemctl disable --now firewalld.service
    참고

    기본적으로 "최소" 설치 옵션이 있는 기본 OS RHEL에서는 firewalld 서비스를 활성화합니다. 호스트에서 firewalld 서비스를 활성화하면 작업자의 OpenShift Container Platform 로그에 액세스할 수 없습니다. 작업자의 OpenShift Container Platform 로그에 계속 액세스하려면 나중에 firewalld를 활성화하지 마십시오.

  2. OpenShift Container Platform 4.17에 필요한 리포지토리를 활성화합니다.

    1. Ansible Playbook을 실행하는 컴퓨터에서 필요한 리포지토리를 업데이트합니다. 

      # subscription-manager repos --disable=rhocp-4.16-for-rhel-8-x86_64-rpms \
                             --enable=rhocp-4.17-for-rhel-8-x86_64-rpms
      중요

      OpenShift Container Platform 4.11부터 Ansible 플레이북은 RHEL 8에만 제공됩니다. RHEL 7 시스템이 OpenShift Container Platform 4.10 Ansible 플레이북의 호스트로 사용된 경우 Ansible 호스트를 RHEL 8로 업데이트하거나 RHEL 8 시스템에서 새 Ansible 호스트를 생성하고 이전 Ansible 호스트의 인벤토리를 통해 복사해야 합니다.

    2. Ansible 플레이북을 실행하는 시스템에서 Ansible 패키지를 업데이트합니다. 

      # yum swap ansible ansible-core

    3. Ansible Playbook을 실행하는 시스템에서 openshift-ansible을 포함하여 필요한 패키지를 업데이트합니다. 

      # yum update openshift-ansible openshift-clients

    4. 각 RHEL 컴퓨팅 노드에 필요한 리포지토리를 업데이트합니다. 

      # subscription-manager repos --disable=rhocp-4.16-for-rhel-8-x86_64-rpms \
                             --enable=rhocp-4.17-for-rhel-8-x86_64-rpms

  3. RHEL 작업자 시스템을 업데이트합니다.

    1. 다음 예와 같이 /<path>/inventory/hosts 에서 Ansible 인벤토리 파일을 검토하고 RHEL 8 시스템이 [workers] 섹션에 나열되도록 콘텐츠를 업데이트합니다. 

      [all:vars]
ansible_user=root
#ansible_become=True

openshift_kubeconfig_path="~/.kube/config"

[workers]
mycluster-rhel8-0.example.com
mycluster-rhel8-1.example.com
mycluster-rhel8-2.example.com
mycluster-rhel8-3.example.com

    2. openshift-ansible 디렉토리로 변경합니다. 

      $ cd /usr/share/ansible/openshift-ansible

    3. upgrade Playbook을 실행합니다. 

      $ ansible-playbook -i /<path>/inventory/hosts playbooks/upgrade.yml 1
      1
      <path>에 대해 생성한 Ansible 인벤토리 파일의 경로를 지정합니다.
      참고

      upgrade 플레이북은 OpenShift Container Platform 패키지만 업데이트합니다. 운영 체제 패키지를 업데이트하지 않습니다.

  4. 모든 작업자를 업데이트한 후 모든 클러스터 노드가 새 버전으로 업데이트되었는지 확인합니다. 

    # oc get node

    출력 예

    NAME                        STATUS                        ROLES    AGE    VERSION
mycluster-control-plane-0   Ready                         master   145m   v1.30.3
mycluster-control-plane-1   Ready                         master   145m   v1.30.3
mycluster-control-plane-2   Ready                         master   145m   v1.30.3
mycluster-rhel8-0           Ready                         worker   98m    v1.30.3
mycluster-rhel8-1           Ready                         worker   98m    v1.30.3
mycluster-rhel8-2           Ready                         worker   98m    v1.30.3
mycluster-rhel8-3           Ready                         worker   98m    v1.30.3

  5. 선택 사항: upgrade 플레이북에서 업데이트하지 않은 운영 체제 패키지를 업데이트합니다. 4.17에 없는 패키지를 업데이트하려면 다음 명령을 사용합니다. 

    # yum update
    참고

    4.17을 설치할 때 사용한 것과 동일한 RPM 리포지토리를 사용하는 경우 RPM 패키지를 제외할 필요가 없습니다.

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.