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

1.2. 클러스터 업데이트 작동 방식

다음 섹션에서는 OCP(OpenShift Container Platform) 업데이트 프로세스의 각 주요 측면을 자세히 설명합니다. 업데이트가 작동하는 방법에 대한 일반적인 개요는 OpenShift 업데이트 소개를 참조하십시오.

1.2.1. Cluster Version Operator

CVO(Cluster Version Operator)는 OpenShift Container Platform 업데이트 프로세스를 오케스트레이션하고 용이하게 하는 주요 구성 요소입니다. 설치 및 표준 클러스터 작업 중에 CVO는 관리 클러스터 Operator의 매니페스트를 클러스터 내부 리소스와 지속적으로 비교하고 불일치를 조정하여 이러한 리소스의 실제 상태가 원하는 상태와 일치하는지 확인합니다.

1.2.1.1. ClusterVersion 오브젝트

CVO(Cluster Version Operator)에서 모니터링하는 리소스 중 하나는 ClusterVersion 리소스입니다.

관리자 및 OpenShift 구성 요소는 ClusterVersion 오브젝트를 통해 CVO와 통신하거나 상호 작용할 수 있습니다. 원하는 CVO 상태는 ClusterVersion 오브젝트를 통해 선언되며 현재 CVO 상태는 오브젝트 상태에 반영됩니다.

참고

ClusterVersion 오브젝트를 직접 수정하지 마십시오. 대신 oc CLI 또는 웹 콘솔과 같은 인터페이스를 사용하여 업데이트 대상을 선언합니다.

CVO는 ClusterVersion 리소스의 spec 속성에 선언된 대상 상태로 클러스터를 지속적으로 조정합니다. 원하는 릴리스가 실제 릴리스와 다른 경우 조정이 클러스터를 업데이트합니다.

가용성 데이터 업데이트

ClusterVersion 리소스에는 클러스터에서 사용할 수 있는 업데이트에 대한 정보도 포함되어 있습니다. 여기에는 클러스터에 적용되는 알려진 위험으로 인해 사용할 수 있지만 권장되지 않는 업데이트가 포함됩니다. 이러한 업데이트를 조건부 업데이트라고 합니다. CVO가 ClusterVersion 리소스의 사용 가능한 업데이트에 대한 이 정보를 유지 관리하는 방법에 대한 자세한 내용은 "업데이트 가용성 평가" 섹션을 참조하십시오.

  • 다음 명령을 사용하여 사용 가능한 모든 업데이트를 검사할 수 있습니다. 

    $ oc adm upgrade --include-not-recommended
    참고

    additional --include-not-recommended 매개변수에는 클러스터에 적용되는 알려진 문제에서 사용할 수 있는 업데이트가 포함되어 있습니다.

    출력 예

    Cluster version is 4.13.40

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

Recommended updates:

  VERSION     IMAGE
  4.14.27     quay.io/openshift-release-dev/ocp-release@sha256:4d30b359aa6600a89ed49ce6a9a5fdab54092bcb821a25480fdfbc47e66af9ec
  4.14.26     quay.io/openshift-release-dev/ocp-release@sha256:4fe7d4ccf4d967a309f83118f1a380a656a733d7fcee1dbaf4d51752a6372890
  4.14.25     quay.io/openshift-release-dev/ocp-release@sha256:a0ef946ef8ae75aef726af1d9bbaad278559ad8cab2c1ed1088928a0087990b6
  4.14.24     quay.io/openshift-release-dev/ocp-release@sha256:0a34eac4b834e67f1bca94493c237e307be2c0eae7b8956d4d8ef1c0c462c7b0
  4.14.23     quay.io/openshift-release-dev/ocp-release@sha256:f8465817382128ec7c0bc676174bad0fb43204c353e49c146ddd83a5b3d58d92
  4.13.42     quay.io/openshift-release-dev/ocp-release@sha256:dcf5c3ad7384f8bee3c275da8f886b0bc9aea7611d166d695d0cf0fff40a0b55
  4.13.41     quay.io/openshift-release-dev/ocp-release@sha256:dbb8aa0cf53dc5ac663514e259ad2768d8c82fd1fe7181a4cfb484e3ffdbd3ba

Updates with known issues:

  Version: 4.14.22
  Image: quay.io/openshift-release-dev/ocp-release@sha256:7093fa606debe63820671cc92a1384e14d0b70058d4b4719d666571e1fc62190
  Reason: MultipleReasons
  Message: Exposure to AzureRegistryImageMigrationUserProvisioned is unknown due to an evaluation failure: client-side throttling: only 18.061µs has elapsed since the last match call completed for this cluster condition backend; this cached cluster condition request has been queued for later execution
  In Azure clusters with the user-provisioned registry storage, the in-cluster image registry component may struggle to complete the cluster update. https://issues.redhat.com/browse/IR-468

  Incoming HTTP requests to services exposed by Routes may fail while routers reload their configuration, especially when made with Apache HTTPClient versions before 5.0. The problem is more likely to occur in clusters with higher number of Routes and corresponding endpoints. https://issues.redhat.com/browse/NE-1689

  Version: 4.14.21
  Image: quay.io/openshift-release-dev/ocp-release@sha256:6e3fba19a1453e61f8846c6b0ad3abf41436a3550092cbfd364ad4ce194582b7
  Reason: MultipleReasons
  Message: Exposure to AzureRegistryImageMigrationUserProvisioned is unknown due to an evaluation failure: client-side throttling: only 33.991µs has elapsed since the last match call completed for this cluster condition backend; this cached cluster condition request has been queued for later execution
  In Azure clusters with the user-provisioned registry storage, the in-cluster image registry component may struggle to complete the cluster update. https://issues.redhat.com/browse/IR-468

  Incoming HTTP requests to services exposed by Routes may fail while routers reload their configuration, especially when made with Apache HTTPClient versions before 5.0. The problem is more likely to occur in clusters with higher number of Routes and corresponding endpoints. https://issues.redhat.com/browse/NE-1689

    oc adm upgrade 명령은 ClusterVersion 리소스에 사용 가능한 업데이트에 대한 정보를 쿼리하고 사용자가 읽을 수 있는 형식으로 제공합니다.

  • CVO에서 생성한 기본 가용성 데이터를 직접 검사하는 한 가지 방법은 다음 명령을 사용하여 ClusterVersion 리소스를 쿼리하는 것입니다. 

    $ oc get clusterversion version -o json | jq '.status.availableUpdates'

    출력 예

    [
  {
    "channels": [
      "candidate-4.11",
      "candidate-4.12",
      "fast-4.11",
      "fast-4.12"
    ],
    "image": "quay.io/openshift-release-dev/ocp-release@sha256:400267c7f4e61c6bfa0a59571467e8bd85c9188e442cbd820cc8263809be3775",
    "url": "https://access.redhat.com/errata/RHBA-2023:3213",
    "version": "4.11.41"
  },
  ...
]

  • 유사한 명령을 사용하여 조건부 업데이트를 확인할 수 있습니다. 

    $ oc get clusterversion version -o json | jq '.status.conditionalUpdates'

    출력 예

    [
  {
    "conditions": [
      {
        "lastTransitionTime": "2023-05-30T16:28:59Z",
        "message": "The 4.11.36 release only resolves an installation issue https://issues.redhat.com//browse/OCPBUGS-11663 , which does not affect already running clusters. 4.11.36 does not include fixes delivered in recent 4.11.z releases and therefore upgrading from these versions would cause fixed bugs to reappear. Red Hat does not recommend upgrading clusters to 4.11.36 version for this reason. https://access.redhat.com/solutions/7007136",
        "reason": "PatchesOlderRelease",
        "status": "False",
        "type": "Recommended"
      }
    ],
    "release": {
      "channels": [...],
      "image": "quay.io/openshift-release-dev/ocp-release@sha256:8c04176b771a62abd801fcda3e952633566c8b5ff177b93592e8e8d2d1f8471d",
      "url": "https://access.redhat.com/errata/RHBA-2023:1733",
      "version": "4.11.36"
    },
    "risks": [...]
  },
  ...
]

1.2.1.2. 업데이트 가용성 평가

CVO(Cluster Version Operator)는 업데이트 가능성에 대한 최신 데이터에 대해 OSUS(OpenShift Update Service)를 주기적으로 쿼리합니다. 이 데이터는 클러스터의 서브스크립션 채널을 기반으로 합니다. 그런 다음 CVO는 업데이트 권장 사항에 대한 정보를 ClusterVersion 리소스의 availableUpdates 또는 conditionalUpdates 필드에 저장합니다.

CVO는 조건부 업데이트에서 업데이트 위험을 주기적으로 확인합니다. 이러한 위험은 OSUS에서 제공하는 데이터를 통해 전달되며, 여기에는 해당 버전으로 업데이트된 클러스터에 영향을 미칠 수 있는 알려진 문제에 대한 각 버전에 대한 정보가 포함되어 있습니다. 대부분의 위험은 특정 클라우드 플랫폼에 배포된 특정 크기 또는 클러스터가 있는 클러스터와 같이 특정 특성이 있는 클러스터로 제한됩니다.

CVO는 각 조건부 업데이트의 조건부 위험 정보에 대해 클러스터 특성을 지속적으로 평가합니다. CVO가 클러스터가 기준과 일치하도록 발견하면 CVO는 이 정보를 ClusterVersion 리소스의 conditionalUpdates 필드에 저장합니다. CVO가 클러스터가 업데이트 위험과 일치하지 않거나 업데이트와 관련된 위험이 없는 경우 ClusterVersion 리소스의 availableUpdates 필드에 대상 버전을 저장합니다.

사용자 인터페이스(웹 콘솔 또는 OpenShift CLI(oc))는 이 정보를 관리자에게 제목으로 지정합니다. 업데이트 경로와 관련된 알려진 각 문제에는 위험 관련 추가 리소스에 대한 링크가 포함되어 관리자가 업데이트에 대해 정보에 입각한 결정을 내릴 수 있습니다.

추가 리소스

1.2.2. 이미지 릴리스

릴리스 이미지는 특정 OCP(OpenShift Container Platform) 버전에 대한 제공 메커니즘입니다. 릴리스 메타데이터, 릴리스 버전과 일치하는 CVO(Cluster Version Operator) 바이너리, 개별 OpenShift 클러스터 Operator를 배포하는 데 필요한 모든 매니페스트 및 이 OpenShift 버전을 구성하는 모든 컨테이너 이미지에 대한 SHA 다이제스트 버전 참조 목록이 포함되어 있습니다.

다음 명령을 실행하여 특정 릴리스 이미지의 콘텐츠를 검사할 수 있습니다. 

$ oc adm release extract <release image>

출력 예

$ oc adm release extract quay.io/openshift-release-dev/ocp-release:4.12.6-x86_64
Extracted release payload from digest sha256:800d1e39d145664975a3bb7cbc6e674fbf78e3c45b5dde9ff2c5a11a8690c87b created at 2023-03-01T12:46:29Z

$ ls
0000_03_authorization-openshift_01_rolebindingrestriction.crd.yaml
0000_03_config-operator_01_proxy.crd.yaml
0000_03_marketplace-operator_01_operatorhub.crd.yaml
0000_03_marketplace-operator_02_operatorhub.cr.yaml
0000_03_quota-openshift_01_clusterresourcequota.crd.yaml 1
...
0000_90_service-ca-operator_02_prometheusrolebinding.yaml 2
0000_90_service-ca-operator_03_servicemonitor.yaml
0000_99_machine-api-operator_00_tombstones.yaml
image-references 3
release-metadata

1
ClusterResourceQuota CRD의 매니페스트를 Runlevel 03에 적용
2
Runlevel 90에 적용할 service-ca-operator 의 PrometheusRoleBinding 리소스에 대한 매니페스트
3
필요한 모든 이미지에 대한 SHA 다이제스트 버전 참조 목록

1.2.3. 프로세스 워크플로 업데이트

다음 단계는 OCP(OpenShift Container Platform) 업데이트 프로세스의 자세한 워크플로를 나타냅니다.

  1. 대상 버전은 웹 콘솔 또는 CLI를 통해 관리할 수 있는 ClusterVersion 리소스의 spec.desiredUpdate.version 필드에 저장됩니다.
  2. CVO(Cluster Version Operator)는 ClusterVersion 리소스의 desiredUpdate 가 현재 클러스터 버전과 다른 것을 감지합니다. OpenShift Update Service의 그래프 데이터를 사용하여 CVO는 원하는 클러스터 버전을 릴리스 이미지의 가져오기 사양으로 확인합니다.
  3. CVO는 릴리스 이미지의 무결성 및 진위 여부를 검증합니다. Red Hat은 이미지 SHA 다이제스트를 고유하고 변경할 수 없는 릴리스 이미지 식별자로 사용하여 사전 정의된 위치에서 게시된 릴리스 이미지에 대해 암호화 방식으로 서명합니다. CVO는 기본 제공 공개 키 목록을 사용하여 선택한 릴리스 이미지와 일치하는 문의 존재 및 서명을 검증합니다.
  4. CVO는 openshift-cluster-version 네임스페이스에 version-$version-$hash 라는 작업을 생성합니다. 이 작업은 릴리스 이미지를 실행하는 컨테이너를 사용하므로 클러스터는 컨테이너 런타임을 통해 이미지를 다운로드합니다. 그런 다음 이 작업은 릴리스 이미지의 매니페스트 및 메타데이터를 CVO에 액세스할 수 있는 공유 볼륨으로 추출합니다.
  5. CVO는 추출된 매니페스트 및 메타데이터의 유효성을 검사합니다.
  6. CVO는 일부 사전 조건을 검사하여 클러스터에서 문제가 있는 상태가 탐지되지 않도록 합니다. 특정 조건은 업데이트가 진행되지 않도록 할 수 있습니다. 이러한 조건은 CVO 자체에 의해 결정되거나, Operator가 업데이트에 문제가 있다고 간주하는 클러스터에 대한 몇 가지 세부 정보를 감지하는 개별 클러스터 Operator에 의해 보고됩니다.
  7. CVO는 허용되는 릴리스를 status.desired 에 기록하고 새 업데이트에 대한 status.history 항목을 생성합니다.
  8. CVO는 릴리스 이미지에서 매니페스트를 조정하기 시작합니다. 클러스터 Operator는 Runlevels라는 별도의 단계에서 업데이트되며 CVO는 다음 단계로 진행하기 전에 Runlevel 완료 업데이트의 모든 Operator를 확인합니다.
  9. CVO 자체에 대한 매니페스트는 프로세스 초기에 적용됩니다. CVO 배포가 적용되면 현재 CVO Pod가 중지되고 새 버전을 사용하는 CVO Pod가 시작됩니다. 새 CVO는 나머지 매니페스트를 조정합니다.
  10. 업데이트는 전체 컨트롤 플레인이 새 버전으로 업데이트될 때까지 진행됩니다. 개별 클러스터 Operator는 클러스터 도메인에서 업데이트 작업을 수행할 수 있으며 이렇게 하는 동안 Progressing=True 조건을 통해 상태를 보고합니다.
  11. MCO(Machine Config Operator) 매니페스트는 프로세스 종료에 적용됩니다. 그런 다음 업데이트된 MCO는 모든 노드의 시스템 구성 및 운영 체제를 업데이트하기 시작합니다. 워크로드를 다시 수락하기 전에 각 노드를 드레이닝, 업데이트 및 재부팅할 수 있습니다.

일반적으로 모든 노드가 업데이트되기 전에 클러스터는 컨트롤 플레인 업데이트가 완료된 후 업데이트된 것으로 보고합니다. 업데이트 후 CVO는 릴리스 이미지에서 전달된 상태와 일치하도록 모든 클러스터 리소스를 유지 관리합니다.

1.2.4. 업데이트 중에 매니페스트가 적용되는 방법 이해

릴리스 이미지에 제공된 일부 매니페스트는 둘 사이의 종속 항목으로 인해 특정 순서로 적용해야 합니다. 예를 들어 일치하는 사용자 지정 리소스보다 먼저 CustomResourceDefinition 리소스를 생성해야 합니다. 또한 클러스터 중단을 최소화하기 위해 개별 클러스터 Operator를 업데이트해야 하는 논리적 순서가 있습니다. CVO(Cluster Version Operator)는 Runlevels라는 개념을 통해 이 논리 순서를 구현합니다.

이러한 종속 항목은 릴리스 이미지에 있는 매니페스트의 파일 이름으로 인코딩됩니다. 

0000_<runlevel>_<component>_<manifest-name>.yaml

예를 들면 다음과 같습니다. 

0000_03_config-operator_01_proxy.crd.yaml

CVO는 내부적으로 매니페스트에 대한 종속성 그래프를 빌드하며 CVO는 다음 규칙을 따릅니다.

  • 업데이트 중에 더 낮은 Runlevel의 매니페스트가 더 높은 Runlevel의 매니페스트보다 먼저 적용됩니다.
  • 하나의 Runlevel 내에서 다른 구성 요소에 대한 매니페스트를 병렬로 적용할 수 있습니다.
  • 하나의 Runlevel 내에서 단일 구성 요소에 대한 매니페스트가 사전순으로 적용됩니다.

CVO는 생성된 종속성 그래프 다음에 매니페스트를 적용합니다.

참고

일부 리소스 유형의 경우 CVO는 매니페스트가 적용된 후 리소스를 모니터링하고 리소스가 stable 상태에 도달한 후에만 성공적으로 업데이트되도록 간주합니다. 이 상태를 달성하는 데는 약간의 시간이 걸릴 수 있습니다. 이는 ClusterOperator 리소스에 특히 해당되며 CVO는 클러스터 Operator가 자체적으로 업데이트되고 ClusterOperator 상태를 업데이트할 때까지 대기합니다.

CVO는 Runlevel의 모든 클러스터 Operator가 다음 Runlevel으로 진행하기 전에 다음 조건을 충족할 때까지 기다립니다.

  • 클러스터 Operator에는 Available=True 조건이 있습니다.
  • 클러스터 Operator에는 Degraded=False 조건이 있습니다.
  • 클러스터 Operator는 ClusterOperator 리소스에서 원하는 버전을 달성했다고 선언합니다.

일부 작업은 완료하는 데 상당한 시간이 걸릴 수 있습니다. CVO는 후속 Runlevels가 안전하게 진행할 수 있도록 작업이 완료될 때까지 기다립니다. 처음에는 새 릴리스의 매니페스트를 조정하는 데 총 60~120분이 걸릴 것으로 예상됩니다. 업데이트 기간에 영향을 미치는 요인에 대한 자세한 내용은 OpenShift Container Platform 업데이트 기간 이해 를 참조하십시오.

Runlevels 순서 및 각 수준 내의 구성 요소의 매니페스트를 표시하는 다이어그램

이전 예제 다이어그램에서 CVO는 Runlevel 20에서 모든 작업이 완료될 때까지 대기 중입니다. CVO는 Runlevel의 Operator에 모든 매니페스트를 적용했지만 kube-apiserver-operator ClusterOperator 는 새 버전이 배포된 후 일부 작업을 수행합니다. kube-apiserver-operator ClusterOperator 는 Progressing=True 조건을 통해 이 진행 상황을 선언하고 새 버전을 status.versions 에서 reconciled로 선언하지 않습니다. CVO는 ClusterOperator가 허용 가능한 상태를 보고할 때까지 기다린 다음 Runlevel 25에서 매니페스트를 조정하기 시작합니다.

추가 리소스

1.2.5. Machine Config Operator가 노드를 업데이트하는 방법 이해

MCO(Machine Config Operator)는 각 컨트롤 플레인 노드 및 컴퓨팅 노드에 새 머신 구성을 적용합니다. 머신 구성 업데이트 중에 컨트롤 플레인 노드와 컴퓨팅 노드는 머신 풀이 병렬로 업데이트되는 자체 머신 구성 풀로 구성됩니다. 기본 값이 1 인 .spec.maxUnavailable 매개변수는 머신 구성 풀의 노드 수를 동시에 수행할 수 있는 업데이트 프로세스를 결정합니다.

주의

maxUnavailable 의 기본 설정은 OpenShift Container Platform의 모든 머신 구성 풀에 대해 1 입니다. 이 값을 변경하지 않고 한 번에 하나의 컨트롤 플레인 노드를 업데이트하는 것이 좋습니다. 컨트롤 플레인 풀의 경우 이 값을 3 으로 변경하지 마십시오.

머신 구성 업데이트 프로세스가 시작되면 MCO는 풀에서 현재 사용할 수 없는 노드의 양을 확인합니다. .spec.maxUnavailable 의 값보다 적은 노드가 있는 경우 MCO는 풀에서 사용 가능한 노드에서 다음 작업 시퀀스를 시작합니다.

  1. 노드를 차단하고 드레이닝

    참고

    노드가 차단되면 워크로드를 예약할 수 없습니다.

  2. 노드의 시스템 구성 및 운영 체제(OS) 업데이트
  3. 노드 재부팅
  4. 노드 차단 해제

이 프로세스를 수행하는 노드는 차단 해제되고 워크로드를 다시 예약할 수 없을 때까지 사용할 수 없습니다. MCO는 사용할 수 없는 노드 수가 .spec.maxUnavailable 과 동일할 때까지 노드 업데이트를 시작합니다.

노드가 업데이트를 완료하고 사용 가능하게 되면 머신 구성 풀에서 사용할 수 없는 노드 수가 다시 한 번 .spec.maxUnavailable 보다 적습니다. 업데이트해야 하는 노드가 남아 있는 경우 MCO는 .spec.maxUnavailable 제한에 다시 도달할 때까지 노드에서 업데이트 프로세스를 시작합니다. 이 프로세스는 각 컨트롤 플레인 노드와 컴퓨팅 노드가 업데이트될 때까지 반복됩니다.

다음 예제 워크플로우에서는 5개의 노드가 있는 머신 구성 풀에서 이 프로세스가 발생하는 방법을 설명합니다. 여기서 .spec.maxUnavailable 은 3이고 모든 노드를 처음 사용할 수 있습니다.

  1. MCO는 1, 2, 3 노드를 차단하고 드레이닝하기 시작합니다.
  2. 노드 2 드레이닝, 재부팅 및 다시 사용할 수 있게 됩니다. MCO는 노드 4를 차단하고 드레이닝을 시작합니다.
  3. 노드 1이 드레이닝, 재부팅 및 다시 사용할 수 있게 됩니다. MCO 노드 5를 차단하고 드레이닝을 시작합니다.
  4. 노드 3은 드레이닝을 완료, 재부팅, 다시 사용할 수 있게 됩니다.
  5. 노드 5 드레이닝, 재부팅 및 다시 사용할 수 있게 됩니다.
  6. 노드 4 드레이닝, 재부팅 및 다시 사용할 수 있게 됩니다.

각 노드의 업데이트 프로세스는 다른 노드와 독립적이므로 위 예제의 일부 노드는 MCO에 의해 차단된 순서대로 업데이트를 완료합니다.

다음 명령을 실행하여 머신 구성 업데이트의 상태를 확인할 수 있습니다. 

$ oc get mcp

출력 예

NAME         CONFIG                                                 UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
master       rendered-master-acd1358917e9f98cbdb599aea622d78b       True      False      False      3              3                   3                     0                      22h
worker       rendered-worker-1d871ac76e1951d32b2fe92369879826       False     True       False      2              1                   1                     0                      22h

추가 리소스

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.