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

3장. 클러스터 업데이트 수행

3.1. CLI를 사용하여 클러스터 업데이트

OpenShift CLI(oc)를 사용하여 OpenShift Container Platform 클러스터에서 마이너 버전 및 패치 업데이트를 수행할 수 있습니다.

3.1.1. 사전 요구 사항

  • admin 권한이 있는 사용자로 클러스터에 액세스합니다. RBAC를 사용하여 권한 정의 및 적용을 참조하십시오.
  • 업데이트가 실패할 경우 etcd 백업이 있어야 하며 클러스터를 이전 상태로 복원해야 합니다.
  • Pod 실패로 인해 영구 볼륨을 복원해야 하는 경우 최신 CSI(Container Storage Interface) 볼륨 스냅샷 이 있어야 합니다.
  • RHEL7 작업자는 RHEL8 또는 RHCOS 작업자로 교체됩니다. Red Hat은 RHEL 작업자의 RHEL7에서 RHEL8 업데이트를 지원하지 않습니다. 해당 호스트는 완전히 새로운 운영 체제 설치로 교체되어야 합니다.
  • OLM(Operator Lifecycle Manager)을 통해 이전에 설치된 모든 Operator를 대상 릴리스와 호환되는 버전으로 업데이트했습니다. Operator를 업데이트하면 클러스터 업데이트 중에 기본 OperatorHub 카탈로그가 현재 마이너 버전에서 다음 버전으로 전환될 때 유효한 업데이트 경로가 있습니다. 호환성을 확인하고 필요한 경우 설치된 Operator를 업데이트하는 방법에 대한 자세한 내용은 설치된 Operator 업데이트를 참조하십시오.
  • 모든 MCP(Machine config pool)가 실행 중이고 일시 중지되지 않는지 확인합니다. 업데이트 프로세스 중에 일시 중지된 MCP와 연결된 노드를 건너뜁니다. 카나리아 롤아웃 업데이트 전략을 수행하는 경우 MCP를 일시 중지할 수 있습니다.
  • 클러스터에서 수동으로 유지 관리되는 인증 정보를 사용하는 경우 새 릴리스의 클라우드 공급자 리소스를 업데이트합니다. 클러스터의 요구 사항인지 확인하는 방법을 포함하여 자세한 내용은 수동으로 유지 관리되는 인증 정보를 사용하여 클러스터 업데이트 준비를 참조하십시오.
  • 클러스터가 다음 마이너 버전으로 업데이트할 수 있도록 모든 Upgradeable=False 조건을 처리해야 합니다. 업데이트할 수 없는 클러스터 Operator 가 하나 이상 있는 경우 클러스터 설정 페이지 상단에 경고가 표시됩니다. 현재 사용 중인 마이너 릴리스에 대해 사용 가능한 다음 패치 업데이트로 업데이트할 수 있습니다.
  • Kubernetes 1.27에서 제거된 API 목록을 검토하고 영향을 받는 구성 요소를 마이그레이션하여 새 API 버전을 사용하고 관리자 승인을 제공합니다. 자세한 내용은 OpenShift Container Platform 4.14로 업데이트 준비를 참조하십시오.
  • Operator를 실행하거나 Pod 중단 예산으로 애플리케이션을 구성한 경우 업데이트 프로세스 중에 중단이 발생할 수 있습니다. PodDisruptionBudget 에서 minAvailable 이 1로 설정된 경우 제거 프로세스를 차단할 수 있는 보류 중인 머신 구성을 적용하기 위해 노드가 드레인됩니다. 여러 노드가 재부팅되면 모든 Pod가 하나의 노드에서만 실행될 수 있으며 PodDisruptionBudget 필드에는 노드가 드레이닝되지 않을 수 있습니다.
중요
  • 업데이트가 완료되지 않으면 CVO(Cluster Version Operator)에서 업데이트를 조정하는 동안 차단 구성 요소의 상태를 보고합니다. 클러스터를 이전 버전으로 롤백하는 것은 지원되지 않습니다. 업데이트가 완료되지 않으면 Red Hat 지원에 문의하십시오.
  • unsupportedConfigOverrides 섹션을 사용하여 Operator 설정을 수정하는 것은 지원되지 않으며 클러스터 업데이트를 차단할 수 있습니다. 클러스터를 업데이트하려면 이 설정을 제거해야 합니다.

추가 리소스

3.1.2. MachineHealthCheck 리소스 일시 중지

업데이트 프로세스 중에 클러스터의 노드를 일시적으로 사용할 수 없게 될 수 있습니다. 작업자 노드의 경우 시스템 상태 점검에서 이러한 노드를 비정상으로 식별하고 재부팅할 수 있습니다. 이러한 노드를 재부팅하지 않으려면 클러스터를 업데이트하기 전에 모든 MachineHealthCheck 리소스를 일시 중지합니다.

사전 요구 사항

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

프로세스

  1. 일시 중지하려는 사용 가능한 MachineHealthCheck 리소스를 모두 나열하려면 다음 명령을 실행합니다. 

    $ oc get machinehealthcheck -n openshift-machine-api

  2. 머신 상태 점검을 일시 중지하려면 cluster.x-k8s.io/paused="" 주석을 MachineHealthCheck 리소스에 추가합니다. 다음 명령을 실행합니다. 

    $ oc -n openshift-machine-api annotate mhc <mhc-name> cluster.x-k8s.io/paused=""

    주석이 지정된 MachineHealthCheck 리소스는 다음 YAML 파일과 유사합니다. 

    apiVersion: machine.openshift.io/v1beta1
kind: MachineHealthCheck
metadata:
  name: example
  namespace: openshift-machine-api
  annotations:
    cluster.x-k8s.io/paused: ""
spec:
  selector:
    matchLabels:
      role: worker
  unhealthyConditions:
  - type:    "Ready"
    status:  "Unknown"
    timeout: "300s"
  - type:    "Ready"
    status:  "False"
    timeout: "300s"
  maxUnhealthy: "40%"
status:
  currentHealthy: 5
  expectedMachines: 5
    중요

    클러스터를 업데이트한 후 머신 상태 점검을 다시 시작합니다. 검사를 다시 시작하려면 다음 명령을 실행하여 MachineHealthCheck 리소스에서 일시 중지 주석을 제거합니다. 

    $ oc -n openshift-machine-api annotate mhc <mhc-name> cluster.x-k8s.io/paused-

3.1.3. 단일 노드 OpenShift Container Platform 업데이트 정보

콘솔 또는 CLI를 사용하여 단일 노드 OpenShift Container Platform 클러스터를 업데이트하거나 업그레이드할 수 있습니다.

그러나 다음과 같은 제한 사항에 유의하십시오.

  • 상태 점검을 수행할 다른 노드가 없기 때문에 MachineHealthCheck 리소스를 일시 중지하기 위한 사전 요구 사항은 필요하지 않습니다.
  • etcd 백업을 사용하여 단일 노드 OpenShift Container Platform 클러스터 복원은 공식적으로 지원되지 않습니다. 그러나 업데이트가 실패하는 경우 etcd 백업을 수행하는 것이 좋습니다. 컨트롤 플레인이 정상이면 백업을 사용하여 클러스터를 이전 상태로 복원할 수 있습니다.

  • 단일 노드 OpenShift Container Platform 클러스터를 업데이트하려면 다운타임이 필요하며 자동 재부팅을 포함할 수 있습니다. 다운타임의 양은 다음 시나리오에 설명된 대로 업데이트 페이로드에 따라 다릅니다.

    • 업데이트 페이로드에 재부팅이 필요한 운영 체제 업데이트가 포함된 경우 다운타임이 중요하며 클러스터 관리 및 사용자 워크로드에 영향을 미칩니다.
    • 재부팅할 필요가 없는 머신 구성 변경 사항이 업데이트되면 다운타임이 줄어들고 클러스터 관리 및 사용자 워크로드에 미치는 영향이 줄어듭니다. 이 경우 워크로드를 다시 예약할 다른 노드가 없기 때문에 단일 노드 OpenShift Container Platform으로 노드 드레이닝 단계를 건너뜁니다.
    • 업데이트 페이로드에 운영 체제 업데이트 또는 머신 구성이 변경되지 않으면 짧은 API 중단이 발생하고 신속하게 해결됩니다.
중요

업데이트된 패키지의 버그와 같은 조건이 있으므로 재부팅 후 단일 노드가 재시작되지 않을 수 있습니다. 이 경우 업데이트가 자동으로 롤백되지 않습니다.

추가 리소스

3.1.4. CLI를 사용하여 클러스터 업데이트

OpenShift CLI(oc)를 사용하여 클러스터 업데이트를 검토하고 요청할 수 있습니다.

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

전제 조건

  • 업데이트된 버전과 일치하는 OpenShift CLI (oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 클러스터에 로그인합니다.
  • 모든 MachineHealthCheck 리소스를 일시 중지합니다.

프로세스

  1. 사용 가능한 업데이트를 확인하고 적용하려는 업데이트의 버전 번호를 기록해 둡니다. 

    $ oc adm upgrade

    출력 예

    Cluster version is 4.13.10
Upstream is unset, so the cluster will use an appropriate default.
Channel: stable-4.13 (available channels: candidate-4.13, candidate-4.14, fast-4.13, stable-4.13)
Recommended updates:
  VERSION     IMAGE
  4.13.14     quay.io/openshift-release-dev/ocp-release@sha256:406fcc160c097f61080412afcfa7fd65284ac8741ac7ad5b480e304aba73674b
  4.13.13     quay.io/openshift-release-dev/ocp-release@sha256:d62495768e335c79a215ba56771ff5ae97e3cbb2bf49ed8fb3f6cefabcdc0f17
  4.13.12     quay.io/openshift-release-dev/ocp-release@sha256:73946971c03b43a0dc6f7b0946b26a177c2f3c9d37105441315b4e3359373a55
  4.13.11     quay.io/openshift-release-dev/ocp-release@sha256:e1c2377fdae1d063aaddc753b99acf25972b6997ab9a0b7e80cfef627b9ef3dd

    참고
    • 사용 가능한 업데이트가 없는 경우 지원되지만 권장되지 않는 업데이트는 계속 사용할 수 있습니다. 자세한 내용은 조건부 업데이트 경로를 따라 업데이트를 참조하십시오.
    • 컨트롤 플레인만 채널 업데이트를 수행하는 방법에 대한 자세한 내용 및 자세한 내용은 추가 리소스 섹션에 나열된 컨트롤 플레인만 업데이트 준비 페이지를 참조하십시오.

  2. 조직 요구 사항에 따라 적절한 업데이트 채널을 설정합니다. 예를 들어 채널을 stable-4.13 또는 fast-4.13 으로 설정할 수 있습니다. 채널에 대한 자세한 내용은 추가 리소스 섹션에 나열된 업데이트 채널 및 릴리스 이해 를 참조하십시오. 

    $ oc adm upgrade channel <channel>

    예를 들어 채널을 stable-4.14 로 설정하려면 다음을 수행합니다. 

    $ oc adm upgrade channel stable-4.14
    중요

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

    참고

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

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

  3. 업데이트를 적용합니다.

    • 최신 버전으로 업데이트하려면 다음을 수행합니다. 

      $ oc adm upgrade --to-latest=true 1

    • 특정 버전으로 업데이트하려면 다음을 수행합니다. 

      $ oc adm upgrade --to=<version> 1
      1 1
      <version >은 oc adm upgrade 명령의 출력에서 얻은 업데이트 버전입니다.
      중요

      oc adm upgrade --help 를 사용하는 경우 --force 에 대한 나열된 옵션이 있습니다. --force 옵션을 사용하면 릴리스 확인 및 사전 조건 검사를 포함하여 클러스터 측 가드를 우회하므로 이는 바람직 하지 않습니다. --force 를 사용하면 성공적인 업데이트가 보장되지 않습니다. 가드를 우회하면 클러스터가 위험하게 됩니다.

  4. 클러스터 버전 Operator의 상태를 확인합니다. 

    $ oc adm upgrade

  5. 업데이트가 완료되면 클러스터 버전이 새 버전으로 업데이트되었는지 확인합니다. 

    $ oc adm upgrade

    출력 예

    Cluster version is <version>

Upstream is unset, so the cluster will use an appropriate default.
Channel: stable-<version> (available channels: candidate-<version>, eus-<version>, fast-<version>, stable-<version>)

No updates available. You may force an update to a specific release image, but doing so might not be supported and might result in downtime or data loss.

  6. 클러스터를 버전 X.y에서 X.(y+1)로 업데이트하는 경우 새 기능을 사용하는 워크로드를 배포하기 전에 노드가 업데이트되었는지 확인하는 것이 좋습니다. 

    $ oc get nodes

    출력 예

    NAME                           STATUS   ROLES    AGE   VERSION
ip-10-0-168-251.ec2.internal   Ready    master   82m   v1.27.3
ip-10-0-170-223.ec2.internal   Ready    master   82m   v1.27.3
ip-10-0-179-95.ec2.internal    Ready    worker   70m   v1.27.3
ip-10-0-182-134.ec2.internal   Ready    worker   70m   v1.27.3
ip-10-0-211-16.ec2.internal    Ready    master   82m   v1.27.3
ip-10-0-250-100.ec2.internal   Ready    worker   69m   v1.27.3

추가 리소스

3.1.5. 조건부 업데이트 경로를 따라 업데이트

웹 콘솔 또는 OpenShift CLI(oc)를 사용하여 권장 조건부 업데이트 경로를 따라 업데이트할 수 있습니다. 클러스터에 조건부 업데이트가 권장되지 않는 경우 OpenShift CLI (oc) 4.10 이상을 사용하여 조건부 업데이트 경로를 따라 업데이트할 수 있습니다.

프로세스

  1. 위험이 적용될 수 있으므로 권장되지 않는 경우 업데이트 설명을 보려면 다음 명령을 실행합니다. 

    $ oc adm upgrade --include-not-recommended

  2. 클러스터 관리자가 알려진 위험을 평가하고 현재 클러스터에 대해 허용 가능한 것으로 결정하는 경우 관리자는 안전 가드를 포기하고 다음 명령을 실행하여 업데이트를 진행할 수 있습니다. 

    $ oc adm upgrade --allow-not-recommended --to <version> <.>

    < . > <version>은 지원되지만 이전 명령의 출력에서 얻은 업데이트 버전은 권장되지 않습니다.

추가 리소스

3.1.6. CLI를 사용하여 업데이트 서버 변경

업데이트 서버 변경은 선택 사항입니다. 로컬에 설치되어 구성된 OSUS(OpenShift Update Service)가 있는 경우 업데이트 중에 로컬 서버를 사용하도록 서버의 URL을 upstream으로 설정해야 합니다. upstream의 기본값은 https://api.openshift.com/api/upgrades_info/v1/graph입니다.

프로세스

  • 클러스터 버전에서 upstream 매개변수 값을 변경합니다. 

    $ oc patch clusterversion/version --patch '{"spec":{"upstream":"<update-server-url>"}}' --type=merge

    <update-server-url> 변수는 업데이트 서버의 URL을 지정합니다.

    출력 예

    clusterversion.config.openshift.io/version patched

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.