Red Hat Summit17.2. Telco 코어 CNF 클러스터 업그레이드
17.2.1. telco 코어 CNF 클러스터 업데이트
OpenShift Container Platform은 EUS 릴리스 간의 모든 짝수 릴리스 및 업데이트 경로에서 장기 지원 또는 EUS (Extended Update Support)를 제공합니다. 하나의 EUS 버전에서 다음 EUS 버전으로 업데이트할 수 있습니다. y-stream과 z-stream 버전 간에 업데이트할 수도 있습니다.
17.2.1.1. telco 코어 CNF 클러스터용 클러스터 업데이트
클러스터를 업데이트하는 것은 버그 및 잠재적인 보안 취약점이 패치되도록 하는 중요한 작업입니다. 종종 클라우드 네이티브 네트워크 기능(CNF)으로 업데이트하려면 클러스터 버전을 업데이트할 때 제공되는 플랫폼의 추가 기능이 필요합니다. 클러스터 플랫폼 버전이 지원되는지 확인하려면 클러스터를 주기적으로 업데이트해야 합니다.
EUS 릴리스를 최신 상태로 유지하고 중요한 z-stream 릴리스만 업그레이드하여 업데이트로 최신 상태를 유지하는 데 필요한 노력을 최소화할 수 있습니다.
클러스터의 업데이트 경로는 클러스터의 크기 및 토폴로지에 따라 다를 수 있습니다. 여기에 설명된 업데이트 절차는 telco scale 팀에서 인증된 최대 규모의 클러스터까지 3-노드 클러스터에서 대부분의 클러스터에 유효합니다. 여기에는 혼합 워크로드 클러스터에 대한 몇 가지 시나리오가 포함됩니다.
다음 업데이트 시나리오가 설명되어 있습니다.
- 컨트롤 플레인만 업데이트
- Y-stream 업데이트
- z-stream 업데이트
Control Plane은 이전에 EUS-to-EUS 업데이트라고도 합니다. 컨트롤 플레인은 OpenShift Container Platform의 짝수의 마이너 버전만 사용할 수 있습니다.
17.2.2. 업데이트 버전 간 클러스터 API 버전 확인
구성 요소가 업데이트되면 시간이 지남에 따라 API가 변경됩니다. 클라우드 네이티브 네트워크 기능(CNF) API가 업데이트된 클러스터 버전과 호환되는지 확인하는 것이 중요합니다.
17.2.2.1. OpenShift Container Platform API 호환성
새 y-stream 업데이트의 일부로 업데이트할 z-stream 릴리스를 고려할 때 이동 중인 z-stream 버전에 있는 모든 패치가 새로운 z-stream 버전에 있는지 확인해야 합니다. 업데이트하려는 버전에 필요한 모든 패치가 없는 경우 Kubernetes의 기본 제공 호환성이 손상됩니다.
예를 들어 클러스터 버전이 4.15.32인 경우 4.15.32에 적용되는 모든 패치가 있는 4.16 z-stream 릴리스로 업데이트해야 합니다.
17.2.2.1.1. Kubernetes 버전 skew 정보
각 클러스터 Operator는 특정 API 버전을 지원합니다. Kubernetes API는 시간이 지남에 따라 진화하며 최신 버전은 더 이상 사용되지 않거나 기존 API를 변경할 수 있습니다. 이를 "version skew"라고 합니다. 새 릴리스마다 API 변경 사항을 검토해야 합니다. API는 Operator의 여러 릴리스에서 호환될 수 있지만 호환성은 보장되지 않습니다. 버전 스큐에서 발생하는 문제를 완화하려면 잘 정의된 업데이트 전략을 따르십시오.
17.2.2.2. 클러스터 버전 업데이트 경로 확인
Red Hat OpenShift Container Platform Update Graph 툴을 사용하여 업데이트하려는 z-stream 릴리스에 경로가 유효한지 확인합니다. Red Hat Technical Account Manager 업데이트를 확인하여 Telco 구현에 업데이트 경로가 유효한지 확인합니다.
업데이트 중인 <4.y+1.z> 또는 <4.y+2.z> 버전은 업데이트 중인 <4.y.z> 릴리스와 동일한 패치 수준을 유지해야 합니다.
OpenShift 업데이트 프로세스에서는 특정 <4.y.z> 릴리스에 수정 사항이 있는 경우 업데이트하려는 <4.y+1.z> 릴리스에 해당 수정 사항이 있어야 합니다.
그림 17.1. 버그 수정 백포트 및 업데이트 그래프
OpenShift 개발에는 회귀를 방지하는 엄격한 백포트 정책이 있습니다. 예를 들어 4.15.z에서 수정되기 전에 4.16.z에서 버그를 수정해야 합니다. 즉, 업데이트 그래프는 마이너 버전이 더 큰 경우에도 업데이트 그래프에서 오래된 릴리스에 대한 업데이트를 허용하지 않습니다(예: 4.15.24에서 4.16.2로 업데이트).
17.2.2.3. 대상 릴리스 선택
Red Hat OpenShift Container Platform 업데이트 그래프 또는 cincinnati-data 리포지토리를 사용하여 업데이트할 릴리스를 결정합니다.
17.2.2.3.1. 사용 가능한 z-stream 업데이트 확인
새 z-stream 릴리스로 업데이트하려면 사용 가능한 버전을 알아야 합니다.
z-stream 업데이트를 수행할 때 채널을 변경할 필요가 없습니다.
프로세스
사용 가능한 z-stream 릴리스를 확인합니다. 다음 명령을 실행합니다.
$ oc adm upgrade출력 예
Cluster version is 4.14.34 Upstream is unset, so the cluster will use an appropriate default. Channel: stable-4.14 (available channels: candidate-4.14, candidate-4.15, eus-4.14, eus-4.16, fast-4.14, fast-4.15, stable-4.14, stable-4.15) Recommended updates: VERSION IMAGE 4.14.37 quay.io/openshift-release-dev/ocp-release@sha256:14e6ba3975e6c73b659fa55af25084b20ab38a543772ca70e184b903db73092b 4.14.36 quay.io/openshift-release-dev/ocp-release@sha256:4bc4925e8028158e3f313aa83e59e181c94d88b4aa82a3b00202d6f354e8dfed 4.14.35 quay.io/openshift-release-dev/ocp-release@sha256:883088e3e6efa7443b0ac28cd7682c2fdbda889b576edad626769bf956ac0858
17.2.2.3.2. 컨트롤 플레인의 채널 변경만 업데이트
채널을 컨트롤 플레인에만 필요한 버전으로 변경해야 합니다.
z-stream 업데이트를 수행할 때 채널을 변경할 필요가 없습니다.
프로세스
현재 구성된 업데이트 채널을 확인합니다.
$ oc get clusterversion -o=jsonpath='{.items[*].spec}' | jq출력 예
{ "channel": "stable-4.14", "clusterID": "01eb9a57-2bfb-4f50-9d37-dc04bd5bac75" }업데이트하려는 새 채널을 가리키도록 채널을 변경합니다.
$ oc adm upgrade channel eus-4.16업데이트된 채널을 확인합니다.
$ oc get clusterversion -o=jsonpath='{.items[*].spec}' | jq출력 예
{ "channel": "eus-4.16", "clusterID": "01eb9a57-2bfb-4f50-9d37-dc04bd5bac75" }
17.2.2.3.2.1. 초기 EUS의 채널을 EUS로 변경
OpenShift Container Platform의 새로운 릴리스의 업데이트 경로는 EUS 채널 또는 마이너 릴리스의 초기 GA 이후 45-90일까지 사용할 수 없습니다.
새 릴리스에 대한 업데이트 테스트를 시작하려면 fast 채널을 사용할 수 있습니다.
프로세스
채널을
fast-<y+1> 로 변경합니다. 예를 들어 다음 명령을 실행합니다.$ oc adm upgrade channel fast-4.16새 채널에서 업데이트 경로를 확인합니다. 다음 명령을 실행합니다.
$ oc adm upgradeCluster version is 4.15.33 Upgradeable=False Reason: AdminAckRequired Message: Kubernetes 1.28 and therefore OpenShift 4.16 remove several APIs which require admin consideration. Please see the knowledge article https://access.redhat.com/articles/6958394 for details and instructions. Upstream is unset, so the cluster will use an appropriate default. Channel: fast-4.16 (available channels: candidate-4.15, candidate-4.16, eus-4.15, eus-4.16, fast-4.15, fast-4.16, stable-4.15, stable-4.16) Recommended updates: VERSION IMAGE 4.16.14 quay.io/openshift-release-dev/ocp-release@sha256:6618dd3c0f5 4.16.13 quay.io/openshift-release-dev/ocp-release@sha256:7a72abc3 4.16.12 quay.io/openshift-release-dev/ocp-release@sha256:1c8359fc2 4.16.11 quay.io/openshift-release-dev/ocp-release@sha256:bc9006febfe 4.16.10 quay.io/openshift-release-dev/ocp-release@sha256:dece7b61b1 4.15.36 quay.io/openshift-release-dev/ocp-release@sha256:c31a56d19 4.15.35 quay.io/openshift-release-dev/ocp-release@sha256:f21253 4.15.34 quay.io/openshift-release-dev/ocp-release@sha256:2dd69c5업데이트 절차에 따라 버전 4.16 (<y+1> from version 4.15)으로 이동합니다.
참고fast 채널을 사용하는 경우에도 작업자 노드를 EUS 릴리스 간에 일시 정지할 수 있습니다.
-
필요한 <y+1> 릴리스에 도달하면 이번에는
fast-<y+2> 로 채널을 다시 변경합니다. - EUS 업데이트 절차에 따라 필요한 <y+2> 릴리스로 이동합니다.
17.2.2.3.3. y-stream 업데이트의 채널 변경
y-stream 업데이트에서는 채널을 다음 릴리스 채널로 변경합니다.
프로덕션 클러스터에 대해 stable 또는 EUS 릴리스 채널을 사용합니다.
프로세스
업데이트 채널을 변경합니다.
$ oc adm upgrade channel stable-4.15새 채널에서 업데이트 경로를 확인합니다. 다음 명령을 실행합니다.
$ oc adm upgrade출력 예
Cluster version is 4.14.34 Upgradeable=False Reason: AdminAckRequired Message: Kubernetes 1.27 and therefore OpenShift 4.15 remove several APIs which require admin consideration. Please see the knowledge article https://access.redhat.com/articles/6958394 for details and instructions. Upstream is unset, so the cluster will use an appropriate default. Channel: stable-4.15 (available channels: candidate-4.14, candidate-4.15, eus-4.14, eus-4.15, fast-4.14, fast-4.15, stable-4.14, stable-4.15) Recommended updates: VERSION IMAGE 4.15.33 quay.io/openshift-release-dev/ocp-release@sha256:7142dd4b560 4.15.32 quay.io/openshift-release-dev/ocp-release@sha256:cda8ea5b13dc9 4.15.31 quay.io/openshift-release-dev/ocp-release@sha256:07cf61e67d3eeee 4.15.30 quay.io/openshift-release-dev/ocp-release@sha256:6618dd3c0f5 4.15.29 quay.io/openshift-release-dev/ocp-release@sha256:7a72abc3 4.15.28 quay.io/openshift-release-dev/ocp-release@sha256:1c8359fc2 4.15.27 quay.io/openshift-release-dev/ocp-release@sha256:bc9006febfe 4.15.26 quay.io/openshift-release-dev/ocp-release@sha256:dece7b61b1 4.14.38 quay.io/openshift-release-dev/ocp-release@sha256:c93914c62d7 4.14.37 quay.io/openshift-release-dev/ocp-release@sha256:c31a56d19 4.14.36 quay.io/openshift-release-dev/ocp-release@sha256:f21253 4.14.35 quay.io/openshift-release-dev/ocp-release@sha256:2dd69c5
17.2.3. 업데이트를 위한 통신 코어 클러스터 플랫폼 준비
일반적으로 telco 클러스터는 베어 메탈 하드웨어에서 실행됩니다. 중요한 보안 수정을 수행하거나, 새로운 기능을 수행하거나, 새로운 OpenShift Container Platform 릴리스와의 호환성을 유지하도록 펌웨어를 업데이트해야 하는 경우가 많습니다.
17.2.3.1. 호스트 펌웨어가 업데이트와 호환되는지 확인
클러스터에서 실행하는 펌웨어 버전을 담당합니다. 호스트 펌웨어 업데이트는 OpenShift Container Platform 업데이트 프로세스의 일부가 아닙니다. OpenShift Container Platform 버전과 함께 펌웨어를 업데이트하지 않는 것이 좋습니다.
하드웨어 벤더는 실행 중인 특정 하드웨어에 대해 최신 인증된 펌웨어 버전을 적용하는 것이 가장 좋습니다. 통신용 사례의 경우 프로덕션 환경에서 적용하기 전에 항상 테스트 환경에서 펌웨어 업데이트를 확인합니다. 통신 CNF 워크로드의 높은 처리량은 최적의 호스트 펌웨어의 영향을 받지 않을 수 있습니다.
새 펌웨어 업데이트를 철저히 테스트하여 현재 OpenShift Container Platform 버전에서 예상대로 작동하는지 확인해야 합니다. 대상 OpenShift Container Platform 업데이트 버전을 사용하여 최신 펌웨어 버전을 테스트하는 것이 좋습니다.
17.2.3.2. 계층화된 제품이 업데이트와 호환되는지 확인
업데이트를 시작하기 전에 업데이트 중인 OpenShift Container Platform 버전에서 모든 계층 제품이 실행되는지 확인합니다. 여기에는 일반적으로 모든 Operator가 포함됩니다.
프로세스
클러스터에 현재 설치된 Operator를 확인합니다. 예를 들어 다음 명령을 실행합니다.
$ oc get csv -A출력 예
NAMESPACE NAME DISPLAY VERSION REPLACES PHASE gitlab-operator-kubernetes.v0.17.2 GitLab 0.17.2 gitlab-operator-kubernetes.v0.17.1 Succeeded openshift-operator-lifecycle-manager packageserver Package Server 0.19.0 SucceededOLM과 함께 설치하는 Operator가 업데이트 버전과 호환되는지 확인합니다.
OLM(Operator Lifecycle Manager)과 함께 설치된 Operator는 표준 클러스터 Operator 세트의 일부가 아닙니다.
Operator Update Information Checker 를 사용하여 각 y-stream 업데이트 후 Operator를 업데이트해야 하는지 또는 다음 EUS 릴리스로 완전히 업데이트할 때까지 기다릴 수 있는지 파악합니다.
작은 정보Operator Update Information Checker 를 사용하여 특정 릴리스의 Operator와 호환되는 OpenShift Container Platform 버전을 확인할 수도 있습니다.
OLM 외부에서 설치하는 Operator가 업데이트 버전과 호환되는지 확인합니다.
Red Hat에서 직접 지원하지 않는 OLM 설치된 모든 Operator의 경우 Operator 공급 업체에 문의하여 릴리스 호환성을 확인하십시오.
- 일부 Operator는 OpenShift Container Platform의 여러 릴리스와 호환됩니다. 클러스터 업데이트를 완료할 때까지 Operator를 업데이트하지 않아야 할 수 있습니다. 자세한 내용은 "작업자 노드 업그레이드"를 참조하십시오.
- 첫 번째 y-stream 컨트롤 플레인 업데이트를 수행한 후 Operator를 업데이트하는 방법에 대한 정보는 "모든 OLM Operator 업그레이드"를 참조하십시오.
17.2.3.3. 업데이트 전에 노드에 MachineConfigPool 라벨 적용
MachineConfigPool (mcp) 노드 레이블을 준비하여 약 8~10개의 노드 그룹에서 함께 노드를 그룹화합니다. mcp 그룹을 사용하면 나머지 클러스터와 독립적으로 노드 그룹을 재부팅할 수 있습니다.
업데이트 프로세스 중에 노드 세트를 일시 중지 및 일시 중지 해제하여 선택한 시점에 업데이트를 수행하고 재부팅할 수 있도록 mcp 노드 레이블을 사용합니다.
17.2.3.3.1. 클러스터 업데이트 차단
경우에 따라 업데이트 중에 문제가 발생할 수 있습니다. 종종 문제는 재설정해야 하는 하드웨어 장애 또는 노드와 관련이 있습니다. mcp 노드 레이블을 사용하여 중요한 순간에 업데이트를 일시 중지하여 노드를 단계별로 업데이트할 수 있으며, 진행하면서 일시 중지되지 않은 노드를 추적할 수 있습니다. 문제가 발생하면 일시 중지되지 않은 상태인 노드를 사용하여 모든 애플리케이션 Pod를 계속 실행할 수 있는 노드가 충분한지 확인합니다.
17.2.3.3.2. 작업자 노드를 MachineConfigPool 그룹으로 분할
작업자 노드를 mcp 그룹으로 나누는 방법은 클러스터에 있는 노드 수 또는 노드 역할에 할당하는 노드 수에 따라 달라질 수 있습니다. 기본적으로 클러스터의 2 역할은 컨트롤 플레인 및 작업자입니다.
telco 워크로드를 실행하는 클러스터에서는 작업자 노드를 CNF 컨트롤 플레인과 CNF 데이터 플레인 역할 간에 추가로 분할할 수 있습니다. 작업자 노드를 이 두 그룹 각각으로 분할하는 mcp 역할 레이블을 추가합니다.
대규모 클러스터는 CNF 컨트롤 플레인 역할에 작업자 노드를 100개 이상 보유할 수 있습니다. 클러스터에 노드 수에 관계없이 각 MachineConfigPool 그룹을 약 10개의 노드로 유지합니다. 이를 통해 한 번에 노드 수를 제어할 수 있습니다. 여러 MachineConfigPool 그룹을 사용하면 한 번에 여러 그룹을 일시 중지 해제하여 업데이트를 가속화하거나 2개 이상의 유지 관리 기간을 통해 업데이트를 분리할 수 있습니다.
- 작업자 노드가 15개인 클러스터 예
작업자 노드가 15개인 클러스터를 고려하십시오.
- 작업자 노드 10개가 CNF 컨트롤 플레인 노드입니다.
- 작업자 노드 5개는 CNF 데이터 플레인 노드입니다.
CNF 컨트롤 플레인 및 데이터 플레인 작업자 노드 역할을 각각 2
mcp그룹으로 나눕니다. 역할당 2개의mcp그룹을 사용하면 업데이트의 영향을 받지 않는 노드 세트가 한 개 있을 수 있습니다.- 작업자 노드가 6개인 클러스터 예
작업자 노드가 6개인 클러스터를 고려하십시오.
-
작업자 노드를 각각 2개의 노드의 3
mcp그룹으로 나눕니다.
mcp그룹 중 하나를 업그레이드합니다. 다른 4개 노드에서 업데이트를 완료하기 전에 업데이트된 노드가 CNF 호환성을 확인할 수 있도록 허용합니다.-
작업자 노드를 각각 2개의 노드의 3
mcp 그룹을 일시 중지 해제하는 프로세스 및 속도는 CNF 애플리케이션 및 구성에 따라 결정됩니다.
CNF Pod가 클러스터의 노드에 예약될 수 있는 경우 한 번에 여러 mcp 그룹을 일시 중지 해제하고 mcp CR(사용자 정의 리소스)에서 MaxUnavailable 을 50%로 설정할 수 있습니다. 이렇게 하면 mcp 그룹에 있는 노드의 절반까지 재시작하고 업데이트할 수 있습니다.
17.2.3.3.3. 구성된 클러스터 MachineConfigPool 역할 검토
클러스터에서 현재 구성된 MachineConfigPool 역할을 검토합니다.
프로세스
클러스터에서 현재 구성된
mcp그룹을 가져옵니다.$ oc get mcp출력 예
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE master rendered-master-bere83 True False False 3 3 3 0 25d worker rendered-worker-245c4f True False False 2 2 2 0 25dmcp역할 목록과 클러스터의 노드 목록을 비교합니다.$ oc get nodes출력 예
NAME STATUS ROLES AGE VERSION ctrl-plane-0 Ready control-plane,master 39d v1.27.15+6147456 ctrl-plane-1 Ready control-plane,master 39d v1.27.15+6147456 ctrl-plane-2 Ready control-plane,master 39d v1.27.15+6147456 worker-0 Ready worker 39d v1.27.15+6147456 worker-1 Ready worker 39d v1.27.15+6147456참고mcp그룹 변경을 적용하면 노드 역할이 업데이트됩니다.작업자 노드를
mcp그룹으로 분리하는 방법을 결정합니다.
17.2.3.3.4. 클러스터용 MachineConfigPool 그룹 생성
mcp 그룹을 생성하는 작업은 2단계 프로세스입니다.
-
클러스터의 노드에
mcp레이블을 추가합니다. -
라벨을 기반으로 노드를 구성하는 클러스터에
mcpCR을 적용
프로세스
mcp그룹에 배치될 수 있도록 노드에 레이블을 지정합니다. 다음 명령을 실행합니다.$ oc label node worker-0 node-role.kubernetes.io/mcp-1=$ oc label node worker-1 node-role.kubernetes.io/mcp-2=mcp-1및mcp-2레이블이 노드에 적용됩니다. 예를 들면 다음과 같습니다.출력 예
NAME STATUS ROLES AGE VERSION ctrl-plane-0 Ready control-plane,master 39d v1.27.15+6147456 ctrl-plane-1 Ready control-plane,master 39d v1.27.15+6147456 ctrl-plane-2 Ready control-plane,master 39d v1.27.15+6147456 worker-0 Ready mcp-1,worker 39d v1.27.15+6147456 worker-1 Ready mcp-2,worker 39d v1.27.15+6147456클러스터에서
mcpCR로 라벨을 적용하는 YAML CR(사용자 정의 리소스)을 생성합니다. 다음 YAML을mcps.yaml파일에 저장합니다.--- apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfigPool metadata: name: mcp-2 spec: machineConfigSelector: matchExpressions: - { key: machineconfiguration.openshift.io/role, operator: In, values: [worker,mcp-2] } nodeSelector: matchLabels: node-role.kubernetes.io/mcp-2: "" --- apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfigPool metadata: name: mcp-1 spec: machineConfigSelector: matchExpressions: - { key: machineconfiguration.openshift.io/role, operator: In, values: [worker,mcp-1] } nodeSelector: matchLabels: node-role.kubernetes.io/mcp-1: ""MachineConfigPool리소스를 생성합니다.$ oc apply -f mcps.yaml출력 예
machineconfigpool.machineconfiguration.openshift.io/mcp-2 created
검증
클러스터에 적용할 때 MachineConfigPool 리소스를 모니터링합니다. mcp 리소스를 적용하면 노드가 새 머신 구성 풀에 추가됩니다. 이 작업은 몇 분 정도 걸립니다.
노드가 mcp 그룹에 추가되는 동안 재부팅되지 않습니다. 원래 worker 및 master mcp 그룹은 변경되지 않습니다.
새
mcp리소스의 상태를 확인합니다.$ oc get mcp출력 예
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE master rendered-master-be3e83 True False False 3 3 3 0 25d mcp-1 rendered-mcp-1-2f4c4f False True True 1 0 0 0 10s mcp-2 rendered-mcp-2-2r4s1f False True True 1 0 0 0 10s worker rendered-worker-23fc4f False True True 0 0 0 2 25d결국 리소스가 완전히 적용됩니다.
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE master rendered-master-be3e83 True False False 3 3 3 0 25d mcp-1 rendered-mcp-1-2f4c4f True False False 1 1 1 0 7m33s mcp-2 rendered-mcp-2-2r4s1f True False False 1 1 1 0 51s worker rendered-worker-23fc4f True False False 0 0 0 0 25d
17.2.3.4. Telco 배포 환경 고려 사항
통신 환경에서 대부분의 클러스터는 연결이 끊긴 네트워크에 있습니다. 이러한 환경의 클러스터를 업데이트하려면 오프라인 이미지 리포지토리를 업데이트해야 합니다.
17.2.3.5. 업데이트를 위한 클러스터 플랫폼 준비
클러스터를 업데이트하기 전에 몇 가지 기본 검사 및 확인을 수행하여 클러스터가 업데이트 준비가 되었는지 확인합니다.
프로세스
다음 명령을 실행하여 클러스터에서 실패하거나 진행 중인 Pod가 없는지 확인합니다.
$ oc get pods -A | grep -E -vi 'complete|running'참고보류 중인 Pod가 있는 경우 이 명령을 두 번 이상 실행해야 할 수 있습니다.
클러스터의 모든 노드를 사용할 수 있는지 확인합니다.
$ oc get nodes출력 예
NAME STATUS ROLES AGE VERSION ctrl-plane-0 Ready control-plane,master 32d v1.27.15+6147456 ctrl-plane-1 Ready control-plane,master 32d v1.27.15+6147456 ctrl-plane-2 Ready control-plane,master 32d v1.27.15+6147456 worker-0 Ready mcp-1,worker 32d v1.27.15+6147456 worker-1 Ready mcp-2,worker 32d v1.27.15+6147456모든 베어 메탈 노드가 프로비저닝되고 준비되었는지 확인합니다.
$ oc get bmh -n openshift-machine-api출력 예
NAME STATE CONSUMER ONLINE ERROR AGE ctrl-plane-0 unmanaged cnf-58879-master-0 true 33d ctrl-plane-1 unmanaged cnf-58879-master-1 true 33d ctrl-plane-2 unmanaged cnf-58879-master-2 true 33d worker-0 unmanaged cnf-58879-worker-0-45879 true 33d worker-1 progressing cnf-58879-worker-0-dszsh false 1d1 - 1
worker-1노드를 프로비저닝하는 동안 오류가 발생했습니다.
검증
모든 클러스터 Operator가 준비되었는지 확인합니다.
$ oc get co출력 예
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE authentication 4.14.34 True False False 17h baremetal 4.14.34 True False False 32d ... service-ca 4.14.34 True False False 32d storage 4.14.34 True False False 32d
17.2.4. telco 코어 CNF 클러스터를 업데이트하기 전에 CNF Pod 구성
클라우드 네이티브 네트워크 기능(CNF) 을 개발할 때 Kubernetes의 Red Hat 모범 사례에 따라 클러스터가 업데이트 중에 Pod를 예약할 수 있도록 합니다.
Deployment 리소스를 사용하여 항상 그룹에 Pod를 배포합니다. 배포 리소스는 사용 가능한 모든 Pod에 워크로드를 분배하여 단일 장애 지점이 없도록 합니다. Deployment 리소스에서 관리하는 Pod가 삭제되면 새 Pod가 자동으로 수행됩니다.
17.2.4.1. CNF 워크로드가 Pod 중단 예산으로 중단 없이 실행되도록 합니다.
적용하는 PodDisruptionBudget 사용자 정의 리소스(CR)에서 Pod 중단 예산을 설정하여 CNF 워크로드가 중단되지 않도록 배포에서 최소 Pod 수를 구성할 수 있습니다. 이 값을 설정할 때 주의하십시오. 부적절하게 설정하면 업데이트가 실패할 수 있습니다.
예를 들어 배포에 Pod가 4개이고 Pod 중단 예산을 4로 설정하면 클러스터 스케줄러는 항상 4개의 Pod를 계속 실행하여 Pod를 축소할 수 없습니다.
대신 Pod 중단 예산을 2로 설정하면 Pod 4개 중 2개를 down으로 예약할 수 있습니다. 그런 다음 해당 Pod가 있는 작업자 노드를 재부팅할 수 있습니다.
Pod 중단 예산을 2로 설정하면 업데이트 중에 일정 기간 동안 2개의 Pod에서만 배포가 실행되지 않습니다. 클러스터 스케줄러는 2개의 이전 Pod를 교체하기 위해 2개의 새 Pod를 생성합니다. 그러나 새 Pod가 온라인 상태가 되고 이전 Pod는 삭제되는 데 시간이 짧습니다.
17.2.4.2. Pod가 동일한 클러스터 노드에서 실행되지 않도록 합니다.
Kubernetes의 고가용성을 위해서는 클러스터의 개별 노드에서 중복 프로세스를 실행해야 합니다. 이렇게 하면 하나의 노드를 사용할 수 없게 되는 경우에도 애플리케이션이 계속 실행됩니다. OpenShift Container Platform에서는 배포의 별도의 Pod에서 프로세스를 자동으로 복제할 수 있습니다. Pod 사양에서 유사성 방지를 구성하여 배포의 Pod 가 동일한 클러스터 노드에서 실행되지 않도록 합니다.
업데이트 중에 Pod 유사성 방지를 설정하면 클러스터의 노드에 Pod가 균등하게 배포됩니다. 따라서 업데이트 중에 노드 재부팅이 더 쉬워집니다. 예를 들어 노드에 단일 배포에서 Pod가 4개 있고 Pod 중단 예산이 한 번에 1개의 Pod만 삭제되도록 설정된 경우 해당 노드를 재부팅하는 데 4배가 걸립니다. Pod 유사성 방지를 설정하면 이러한 발생을 방지하기 위해 Pod가 클러스터에 분배됩니다.
17.2.4.3. 애플리케이션 활성 상태 프로브, 준비 상태, 시작 프로브
업데이트를 예약하기 전에 활성 상태, 준비 및 시작 프로브를 사용하여 라이브 애플리케이션 컨테이너의 상태를 확인할 수 있습니다. 이는 애플리케이션 컨테이너의 상태를 유지하는 데 의존하는 Pod와 함께 사용할 수 있는 매우 유용한 툴입니다.
- 활성 상태 점검
- 컨테이너가 실행 중인지 확인합니다. 컨테이너에 대한 활성 프로브가 실패하면 Pod는 재시작 정책을 기반으로 응답합니다.
- Readiness 프로브
- 컨테이너가 서비스 요청을 수락할 준비가 되었는지 확인합니다. 컨테이너에 대한 준비 상태 프로브가 실패하면 kubelet은 사용 가능한 서비스 끝점 목록에서 컨테이너를 제거합니다.
- Startup 프로브
-
시작 프로브는 컨테이너 내의 애플리케이션이 시작되었는지 여부를 나타냅니다. 기타 모든 프로브는 시작 프로브가 성공할 때까지 비활성화됩니다. 시작 프로브가 실패하면 kubelet에서 컨테이너를 종료하고 컨테이너에 Pod
restartPolicy설정이 적용됩니다.
17.2.5. telco 코어 CNF 클러스터를 업데이트하기 전에
클러스터 업데이트를 시작하기 전에 작업자 노드를 일시 중지하고 etcd 데이터베이스를 백업하고 계속하기 전에 최종 클러스터 상태 점검을 수행해야 합니다.
17.2.5.1. 업데이트 전에 작업자 노드 일시 중지
업데이트를 진행하기 전에 작업자 노드를 일시 중지해야 합니다. 다음 예에서는 mcp 그룹 mcp-1 및 mcp-2 가 있습니다. 이러한 MachineConfigPool 그룹 각각에 대해 spec.paused 필드를 true 로 패치합니다.
프로세스
다음 명령을 실행하여
mcpCR을 패치하여 노드를 일시 중지하고 해당 노드에서 Pod를 드레이닝합니다.$ oc patch mcp/mcp-1 --type merge --patch '{"spec":{"paused":true}}'$ oc patch mcp/mcp-2 --type merge --patch '{"spec":{"paused":true}}'일시 중지된
mcp그룹의 상태를 가져옵니다.$ oc get mcp -o json | jq -r '["MCP","Paused"], ["---","------"], (.items[] | [(.metadata.name), (.spec.paused)]) | @tsv' | grep -v worker출력 예
MCP Paused --- ------ master false mcp-1 true mcp-2 true
기본 컨트롤 플레인 및 작업자 mcp 그룹은 업데이트 중에 변경되지 않습니다.
17.2.5.2. 업데이트를 진행하기 전에 etcd 데이터베이스 백업
업데이트를 진행하기 전에 etcd 데이터베이스를 백업해야 합니다.
17.2.5.2.1. etcd 데이터 백업
다음 단계에 따라 etcd 스냅샷을 작성하고 정적 pod의 리소스를 백업하여 etcd 데이터를 백업합니다. 이 백업을 저장하여 etcd를 복원해야하는 경우 나중에 사용할 수 있습니다.
단일 컨트롤 플레인 호스트의 백업만 저장합니다. 클러스터의 각 컨트롤 플레인 호스트에서 백업을 수행하지 마십시오.
사전 요구 사항
-
cluster-admin역할의 사용자로 클러스터에 액세스할 수 있어야 합니다. 클러스터 전체의 프록시가 활성화되어 있는지 확인해야 합니다.
작은 정보oc get proxy cluster -o yaml의 출력을 확인하여 프록시가 사용 가능한지 여부를 확인할 수 있습니다.httpProxy,httpsProxy및noProxy필드에 값이 설정되어 있으면 프록시가 사용됩니다.
프로세스
컨트롤 플레인 노드의 root로 디버그 세션을 시작합니다.
$ oc debug --as-root node/<node_name>디버그 쉘에서 root 디렉토리를
/host로 변경합니다.sh-4.4# chroot /host클러스터 전체 프록시가 활성화된 경우 다음 명령을 실행하여
NO_PROXY,HTTP_PROXY및HTTPS_PROXY환경 변수를 내보냅니다.$ export HTTP_PROXY=http://<your_proxy.example.com>:8080$ export HTTPS_PROXY=https://<your_proxy.example.com>:8080$ export NO_PROXY=<example.com>디버그 쉘에서
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스크립트 출력 예
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이 예제에서는 컨트롤 플레인 호스트의
/home/core/assets/backup/디렉토리에 두 개의 파일이 생성됩니다.-
snapshot_<datetimestamp>.db:이 파일은 etcd 스냅샷입니다.cluster-backup.sh스크립트는 유효성을 확인합니다. static_kuberesources_<datetimestamp>.tar.gz: 이 파일에는 정적 pod 리소스가 포함되어 있습니다. etcd 암호화가 활성화되어 있는 경우 etcd 스냅 샷의 암호화 키도 포함됩니다.참고etcd 암호화가 활성화되어 있는 경우 보안상의 이유로 이 두 번째 파일을 etcd 스냅 샷과 별도로 저장하는 것이 좋습니다. 그러나 이 파일은 etcd 스냅 샷에서 복원하는데 필요합니다.
etcd 암호화는 키가 아닌 값만 암호화합니다. 즉, 리소스 유형, 네임 스페이스 및 개체 이름은 암호화되지 않습니다.
-
17.2.5.2.2. 단일 etcd 백업 생성
다음 단계에 따라 CR(사용자 정의 리소스)을 생성하고 적용하여 단일 etcd 백업을 생성합니다.
사전 요구 사항
-
cluster-admin역할의 사용자로 클러스터에 액세스할 수 있어야 합니다. -
OpenShift CLI(
oc)에 액세스할 수 있습니다.
프로세스
동적으로 프로비저닝된 스토리지를 사용할 수 있는 경우 다음 단계를 완료하여 단일 자동화된 etcd 백업을 생성합니다.
다음 예와 같은 콘텐츠를 사용하여
etcd-backup-pvc.yaml이라는 PVC(영구 볼륨 클레임)를 생성합니다.kind: PersistentVolumeClaim apiVersion: v1 metadata: name: etcd-backup-pvc namespace: openshift-etcd spec: accessModes: - ReadWriteOnce resources: requests: storage: 200Gi1 volumeMode: Filesystem- 1
- PVC에서 사용할 수 있는 스토리지 용량입니다. 요구 사항에 맞게 이 값을 조정합니다.
다음 명령을 실행하여 PVC를 적용합니다.
$ oc apply -f etcd-backup-pvc.yaml다음 명령을 실행하여 PVC 생성을 확인합니다.
$ oc get pvc출력 예
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE etcd-backup-pvc Bound 51s참고동적 PVC는 마운트될 때까지
Pending상태로 유지됩니다.다음 예와 같은 콘텐츠를 사용하여
etcd-single-backup.yaml이라는 CR 파일을 만듭니다.apiVersion: operator.openshift.io/v1alpha1 kind: EtcdBackup metadata: name: etcd-single-backup namespace: openshift-etcd spec: pvcName: etcd-backup-pvc1 - 1
- 백업을 저장할 PVC의 이름입니다. 환경에 따라 이 값을 조정합니다.
CR을 적용하여 단일 백업을 시작합니다.
$ oc apply -f etcd-single-backup.yaml
동적으로 프로비저닝된 스토리지를 사용할 수 없는 경우 다음 단계를 완료하여 단일 자동화된 etcd 백업을 생성합니다.
다음 콘텐츠를 사용하여
etcd-backup-local-storage.yaml이라는StorageClassCR 파일을 만듭니다.apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: etcd-backup-local-storage provisioner: kubernetes.io/no-provisioner volumeBindingMode: Immediate다음 명령을 실행하여
StorageClassCR을 적용합니다.$ oc apply -f etcd-backup-local-storage.yaml다음 예와 같은 콘텐츠를 사용하여
etcd-backup-pv-fs.yaml이라는 PV를 생성합니다.apiVersion: v1 kind: PersistentVolume metadata: name: etcd-backup-pv-fs spec: capacity: storage: 100Gi1 volumeMode: Filesystem accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain storageClassName: etcd-backup-local-storage local: path: /mnt nodeAffinity: required: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: In values: - <example_master_node>2 다음 명령을 실행하여 PV 생성을 확인합니다.
$ oc get pv출력 예
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE etcd-backup-pv-fs 100Gi RWO Retain Available etcd-backup-local-storage 10s다음 예와 같은 콘텐츠를 사용하여
etcd-backup-pvc.yaml이라는 PVC를 만듭니다.kind: PersistentVolumeClaim apiVersion: v1 metadata: name: etcd-backup-pvc namespace: openshift-etcd spec: accessModes: - ReadWriteOnce volumeMode: Filesystem resources: requests: storage: 10Gi1 - 1
- PVC에서 사용할 수 있는 스토리지 용량입니다. 요구 사항에 맞게 이 값을 조정합니다.
다음 명령을 실행하여 PVC를 적용합니다.
$ oc apply -f etcd-backup-pvc.yaml다음 예와 같은 콘텐츠를 사용하여
etcd-single-backup.yaml이라는 CR 파일을 만듭니다.apiVersion: operator.openshift.io/v1alpha1 kind: EtcdBackup metadata: name: etcd-single-backup namespace: openshift-etcd spec: pvcName: etcd-backup-pvc1 - 1
- 백업을 저장할 PVC(영구 볼륨 클레임)의 이름입니다. 환경에 따라 이 값을 조정합니다.
CR을 적용하여 단일 백업을 시작합니다.
$ oc apply -f etcd-single-backup.yaml
17.2.5.3. 클러스터 상태 확인
업데이트 중에 클러스터 상태를 자주 확인해야 합니다. 노드 상태, 클러스터 Operator 상태 및 실패한 Pod가 있는지 확인합니다.
프로세스
다음 명령을 실행하여 클러스터 Operator의 상태를 확인합니다.
$ oc get co출력 예
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE authentication 4.14.34 True False False 4d22h baremetal 4.14.34 True False False 4d22h cloud-controller-manager 4.14.34 True False False 4d23h cloud-credential 4.14.34 True False False 4d23h cluster-autoscaler 4.14.34 True False False 4d22h config-operator 4.14.34 True False False 4d22h console 4.14.34 True False False 4d22h ... service-ca 4.14.34 True False False 4d22h storage 4.14.34 True False False 4d22h클러스터 노드의 상태를 확인합니다.
$ oc get nodes출력 예
NAME STATUS ROLES AGE VERSION ctrl-plane-0 Ready control-plane,master 4d22h v1.27.15+6147456 ctrl-plane-1 Ready control-plane,master 4d22h v1.27.15+6147456 ctrl-plane-2 Ready control-plane,master 4d22h v1.27.15+6147456 worker-0 Ready mcp-1,worker 4d22h v1.27.15+6147456 worker-1 Ready mcp-2,worker 4d22h v1.27.15+6147456진행 중 또는 실패한 Pod가 없는지 확인합니다. 다음 명령을 실행할 때 반환된 Pod가 없어야 합니다.
$ oc get po -A | grep -E -iv 'running|complete'
17.2.6. 컨트롤 플레인 완료 클러스터 업데이트만
다음 단계에 따라 컨트롤 플레인만 클러스터 업데이트를 수행하고 업데이트를 모니터링하여 완료합니다.
Control Plane은 이전에 EUS-to-EUS 업데이트라고도 합니다. 컨트롤 플레인은 OpenShift Container Platform의 짝수의 마이너 버전만 사용할 수 있습니다.
17.2.6.1. 컨트롤 플레인만 또는 y-stream 업데이트 확인
4.11 이상에서 모든 버전으로 업데이트하는 경우 업데이트가 계속될 수 있음을 수동으로 승인해야 합니다.
업데이트를 확인하기 전에 업데이트 중인 버전에서 제거된 Kubernetes API를 사용하지 않는지 확인합니다. 예를 들어 OpenShift Container Platform 4.17에는 API 제거가 없습니다. 자세한 내용은 "Kubernetes API 제거"를 참조하십시오.
사전 요구 사항
- 클러스터에서 실행되는 모든 애플리케이션의 API가 OpenShift Container Platform의 다음 Y-stream 릴리스와 호환되는지 확인했습니다. 호환성에 대한 자세한 내용은 "업데이트 버전 간 클러스터 API 버전 확인"을 참조하십시오.
프로세스
다음 명령을 실행하여 클러스터 업데이트를 시작하도록 관리 승인을 완료합니다.
$ oc adm upgrade클러스터 업데이트가 성공적으로 완료되지 않으면 업데이트 실패에 대한 자세한 정보가
Reason및Message섹션에 제공됩니다.출력 예
Cluster version is 4.15.45 Upgradeable=False Reason: MultipleReasons Message: Cluster should not be upgraded between minor versions for multiple reasons: AdminAckRequired,ResourceDeletesInProgress * Kubernetes 1.29 and therefore OpenShift 4.16 remove several APIs which require admin consideration. Please see the knowledge article https://access.redhat.com/articles/7031404 for details and instructions. * Cluster minor level upgrades are not allowed while resource deletions are in progress; resources=PrometheusRule "openshift-kube-apiserver/kube-apiserver-recording-rules" ReleaseAccepted=False Reason: PreconditionChecks Message: Preconditions failed for payload loaded version="4.16.34" image="quay.io/openshift-release-dev/ocp-release@sha256:41bb08c560f6db5039ccdf242e590e8b23049b5eb31e1c4f6021d1d520b353b8": Precondition "ClusterVersionUpgradeable" failed because of "MultipleReasons": Cluster should not be upgraded between minor versions for multiple reasons: AdminAckRequired,ResourceDeletesInProgress * Kubernetes 1.29 and therefore OpenShift 4.16 remove several APIs which require admin consideration. Please see the knowledge article https://access.redhat.com/articles/7031404 for details and instructions. * Cluster minor level upgrades are not allowed while resource deletions are in progress; resources=PrometheusRule "openshift-kube-apiserver/kube-apiserver-recording-rules" Upstream is unset, so the cluster will use an appropriate default. Channel: eus-4.16 (available channels: candidate-4.15, candidate-4.16, eus-4.16, fast-4.15, fast-4.16, stable-4.15, stable-4.16) Recommended updates: VERSION IMAGE 4.16.34 quay.io/openshift-release-dev/ocp-release@sha256:41bb08c560f6db5039ccdf242e590e8b23049b5eb31e1c4f6021d1d520b353b8참고이 예에서 링크된 Red Hat 지식베이스 문서(OpenShift Container Platform 4.16으로 업그레이드 준비)는 릴리스 간 API 호환성을 확인하는 방법에 대해 자세히 설명합니다.
검증
다음 명령을 실행하여 업데이트를 확인합니다.
$ oc get configmap admin-acks -n openshift-config -o json | jq .data출력 예
{ "ack-4.14-kube-1.28-api-removals-in-4.15": "true", "ack-4.15-kube-1.29-api-removals-in-4.16": "true" }참고이 예에서 클러스터는 4.14에서 4.15로 업데이트되고 컨트롤 플레인 전용 업데이트의 4.15에서 4.16으로 업데이트됩니다.
17.2.6.2. 클러스터 업데이트 시작
하나의 y-stream 릴리스에서 다음 버전으로 업데이트할 때 중간 z-stream 릴리스도 호환되는지 확인해야 합니다.
oc adm upgrade 명령을 실행하여 실행 가능한 릴리스로 업데이트 중인지 확인할 수 있습니다. oc adm upgrade 명령은 호환되는 업데이트 릴리스를 나열합니다.
프로세스
업데이트를 시작합니다.
$ oc adm upgrade --to=4.15.33중요- Control Plane만 업데이트: 임시 <y+1> 릴리스 경로를 가리키십시오.
- Y-stream 업데이트 - Kubernetes 버전 skew 정책을 따르는 올바른 <y.z> 릴리스를 사용해야 합니다.
- Z-stream 업데이트 - 특정 릴리스로 이동하는 데 문제가 없는지 확인합니다.
출력 예
Requested update to 4.15.331 - 1
특정 업데이트에따라 요청된 업데이트 값이 변경됩니다.
17.2.6.3. 클러스터 업데이트 모니터링
업데이트 중에 클러스터 상태를 자주 확인해야 합니다. 노드 상태, 클러스터 Operator 상태 및 실패한 Pod가 있는지 확인합니다.
프로세스
클러스터 업데이트를 모니터링합니다. 예를 들어 버전 4.14에서 4.15로 클러스터 업데이트를 모니터링하려면 다음 명령을 실행합니다.
$ watch "oc get clusterversion; echo; oc get co | head -1; oc get co | grep 4.14; oc get co | grep 4.15; echo; oc get no; echo; oc get po -A | grep -E -iv 'running|complete'"출력 예
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.14.34 True True 4m6s Working towards 4.15.33: 111 of 873 done (12% complete), waiting on kube-apiserver NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE authentication 4.14.34 True False False 4d22h baremetal 4.14.34 True False False 4d23h cloud-controller-manager 4.14.34 True False False 4d23h cloud-credential 4.14.34 True False False 4d23h cluster-autoscaler 4.14.34 True False False 4d23h console 4.14.34 True False False 4d22h ... storage 4.14.34 True False False 4d23h config-operator 4.15.33 True False False 4d23h etcd 4.15.33 True False False 4d23h NAME STATUS ROLES AGE VERSION ctrl-plane-0 Ready control-plane,master 4d23h v1.27.15+6147456 ctrl-plane-1 Ready control-plane,master 4d23h v1.27.15+6147456 ctrl-plane-2 Ready control-plane,master 4d23h v1.27.15+6147456 worker-0 Ready mcp-1,worker 4d23h v1.27.15+6147456 worker-1 Ready mcp-2,worker 4d23h v1.27.15+6147456 NAMESPACE NAME READY STATUS RESTARTS AGE openshift-marketplace redhat-marketplace-rf86t 0/1 ContainerCreating 0 0s
검증
업데이트 중 watch 명령은 한 번에 하나 또는 여러 클러스터 Operator를 통해 주기 때문에 MESSAGE 열의 Operator 업데이트 상태를 제공합니다.
클러스터 Operator 업데이트 프로세스가 완료되면 각 컨트롤 플레인 노드가 한 번에 하나씩 재부팅됩니다.
업데이트 중에 상태 클러스터 Operator가 다시 업데이트되거나 성능이 저하된 상태인 메시지가 표시됩니다. 이는 노드를 재부팅하는 동안 컨트롤 플레인 노드가 오프라인 상태이기 때문입니다.
마지막 컨트롤 플레인 노드 재부팅이 완료되면 클러스터 버전이 업데이트됨으로 표시됩니다.
컨트롤 플레인 업데이트가 완료되면 다음과 같은 메시지가 표시됩니다. 이 예에서는 중간 y-stream 릴리스로 완료된 업데이트를 보여줍니다.
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS
version 4.15.33 True False 28m Cluster version is 4.15.33
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE
authentication 4.15.33 True False False 5d
baremetal 4.15.33 True False False 5d
cloud-controller-manager 4.15.33 True False False 5d1h
cloud-credential 4.15.33 True False False 5d1h
cluster-autoscaler 4.15.33 True False False 5d
config-operator 4.15.33 True False False 5d
console 4.15.33 True False False 5d
...
service-ca 4.15.33 True False False 5d
storage 4.15.33 True False False 5d
NAME STATUS ROLES AGE VERSION
ctrl-plane-0 Ready control-plane,master 5d v1.28.13+2ca1a23
ctrl-plane-1 Ready control-plane,master 5d v1.28.13+2ca1a23
ctrl-plane-2 Ready control-plane,master 5d v1.28.13+2ca1a23
worker-0 Ready mcp-1,worker 5d v1.28.13+2ca1a23
worker-1 Ready mcp-2,worker 5d v1.28.13+2ca1a2317.2.6.4. OLM Operator 업데이트
통신 환경에서 소프트웨어는 프로덕션 클러스터에 로드되기 전에 vletsd를 검사해야 합니다. 프로덕션 클러스터는 연결이 끊긴 네트워크에서도 구성됩니다. 즉, 인터넷에 항상 직접 연결되지는 않습니다. 클러스터는 연결이 끊긴 네트워크에 있기 때문에 OpenShift Operator는 설치 중에 수동으로 업데이트되도록 구성되므로 클러스터별로 새 버전을 관리할 수 있습니다. Operator를 최신 버전으로 이동하려면 다음 절차를 수행합니다.
프로세스
어떤 Operator를 업데이트해야 하는지 확인합니다.
$ oc get installplan -A | grep -E 'APPROVED|false'출력 예
NAMESPACE NAME CSV APPROVAL APPROVED metallb-system install-nwjnh metallb-operator.v4.16.0-202409202304 Manual false openshift-nmstate install-5r7wr kubernetes-nmstate-operator.4.16.0-202409251605 Manual false해당 Operator의
InstallPlan리소스를 패치합니다.$ oc patch installplan -n metallb-system install-nwjnh --type merge --patch \ '{"spec":{"approved":true}}'출력 예
installplan.operators.coreos.com/install-nwjnh patched다음 명령을 실행하여 네임스페이스를 모니터링합니다.
$ oc get all -n metallb-system출력 예
NAME READY STATUS RESTARTS AGE pod/metallb-operator-controller-manager-69b5f884c-8bp22 0/1 ContainerCreating 0 4s pod/metallb-operator-controller-manager-77895bdb46-bqjdx 1/1 Running 0 4m1s pod/metallb-operator-webhook-server-5d9b968896-vnbhk 0/1 ContainerCreating 0 4s pod/metallb-operator-webhook-server-d76f9c6c8-57r4w 1/1 Running 0 4m1s ... NAME DESIRED CURRENT READY AGE replicaset.apps/metallb-operator-controller-manager-69b5f884c 1 1 0 4s replicaset.apps/metallb-operator-controller-manager-77895bdb46 1 1 1 4m1s replicaset.apps/metallb-operator-controller-manager-99b76f88 0 0 0 4m40s replicaset.apps/metallb-operator-webhook-server-5d9b968896 1 1 0 4s replicaset.apps/metallb-operator-webhook-server-6f7dbfdb88 0 0 0 4m40s replicaset.apps/metallb-operator-webhook-server-d76f9c6c8 1 1 1 4m1s업데이트가 완료되면 필요한 Pod가
Running이어야 하며 필요한ReplicaSet리소스가 준비되어야 합니다.NAME READY STATUS RESTARTS AGE pod/metallb-operator-controller-manager-69b5f884c-8bp22 1/1 Running 0 25s pod/metallb-operator-webhook-server-5d9b968896-vnbhk 1/1 Running 0 25s ... NAME DESIRED CURRENT READY AGE replicaset.apps/metallb-operator-controller-manager-69b5f884c 1 1 1 25s replicaset.apps/metallb-operator-controller-manager-77895bdb46 0 0 0 4m22s replicaset.apps/metallb-operator-webhook-server-5d9b968896 1 1 1 25s replicaset.apps/metallb-operator-webhook-server-d76f9c6c8 0 0 0 4m22s
검증
Operator를 두 번 업데이트할 필요가 없는지 확인합니다.
$ oc get installplan -A | grep -E 'APPROVED|false'반환되는 출력이 없어야 합니다.
참고일부 Operator에는 최종 버전 전에 설치해야 하는 임시 z-stream 릴리스 버전이 있기 때문에 업데이트를 두 번 승인해야 하는 경우가 있습니다.
17.2.6.4.1. 두 번째 y-stream 업데이트 수행
첫 번째 y-stream 업데이트를 완료한 후에는 y-stream 컨트롤 플레인 버전을 새 EUS 버전으로 업데이트해야 합니다.
프로세스
선택한 <4.y.z> 릴리스가 여전히 다음으로 이동하기 좋은 채널로 나열되어 있는지 확인합니다.
$ oc adm upgrade출력 예
Cluster version is 4.15.33 Upgradeable=False Reason: AdminAckRequired Message: Kubernetes 1.29 and therefore OpenShift 4.16 remove several APIs which require admin consideration. Please see the knowledge article https://access.redhat.com/articles/7031404 for details and instructions. Upstream is unset, so the cluster will use an appropriate default. Channel: eus-4.16 (available channels: candidate-4.15, candidate-4.16, eus-4.16, fast-4.15, fast-4.16, stable-4.15, stable-4.16) Recommended updates: VERSION IMAGE 4.16.14 quay.io/openshift-release-dev/ocp-release@sha256:0521a0f1acd2d1b77f76259cb9bae9c743c60c37d9903806a3372c1414253658 4.16.13 quay.io/openshift-release-dev/ocp-release@sha256:6078cb4ae197b5b0c526910363b8aff540343bfac62ecb1ead9e068d541da27b 4.15.34 quay.io/openshift-release-dev/ocp-release@sha256:f2e0c593f6ed81250c11d0bac94dbaf63656223477b7e8693a652f933056af6e참고새 Y-stream 릴리스의 초기 GA 직후 업데이트되는 경우
oc adm upgrade명령을 실행할 때 사용 가능한 새로운 y-stream 릴리스가 표시되지 않을 수 있습니다.선택 사항: 권장되지 않는 잠재적인 업데이트 릴리스를 확인합니다. 다음 명령을 실행합니다.
$ oc adm upgrade --include-not-recommended출력 예
Cluster version is 4.15.33 Upgradeable=False Reason: AdminAckRequired Message: Kubernetes 1.29 and therefore OpenShift 4.16 remove several APIs which require admin consideration. Please see the knowledge article https://access.redhat.com/articles/7031404 for details and instructions. Upstream is unset, so the cluster will use an appropriate default.Channel: eus-4.16 (available channels: candidate-4.15, candidate-4.16, eus-4.16, fast-4.15, fast-4.16, stable-4.15, stable-4.16) Recommended updates: VERSION IMAGE 4.16.14 quay.io/openshift-release-dev/ocp-release@sha256:0521a0f1acd2d1b77f76259cb9bae9c743c60c37d9903806a3372c1414253658 4.16.13 quay.io/openshift-release-dev/ocp-release@sha256:6078cb4ae197b5b0c526910363b8aff540343bfac62ecb1ead9e068d541da27b 4.15.34 quay.io/openshift-release-dev/ocp-release@sha256:f2e0c593f6ed81250c11d0bac94dbaf63656223477b7e8693a652f933056af6e Supported but not recommended updates: Version: 4.16.15 Image: quay.io/openshift-release-dev/ocp-release@sha256:671bc35e Recommended: Unknown Reason: EvaluationFailed Message: Exposure to AzureRegistryImagePreservation is unknown due to an evaluation failure: invalid PromQL result length must be one, but is 0 In Azure clusters, the in-cluster image registry may fail to preserve images on update. https://issues.redhat.com/browse/IR-461참고이 예제에서는 Microsoft Azure에서 호스팅되는 클러스터에 영향을 줄 수 있는 잠재적인 오류를 보여줍니다. 베어 메탈 클러스터에 대한 위험이 표시되지 않습니다.
17.2.6.4.2. y-stream 릴리스 업데이트 확인
y-stream 릴리스 간에 이동할 때 patch 명령을 실행하여 업데이트를 명시적으로 승인해야 합니다. oc adm upgrade 명령의 출력에서 실행할 특정 명령을 표시하는 URL이 제공됩니다.
업데이트를 확인하기 전에 업데이트 중인 버전에서 제거된 Kubernetes API를 사용하지 않는지 확인합니다. 예를 들어 OpenShift Container Platform 4.17에는 API 제거가 없습니다. 자세한 내용은 "Kubernetes API 제거"를 참조하십시오.
사전 요구 사항
- 클러스터에서 실행되는 모든 애플리케이션의 API가 OpenShift Container Platform의 다음 Y-stream 릴리스와 호환되는지 확인했습니다. 호환성에 대한 자세한 내용은 "업데이트 버전 간 클러스터 API 버전 확인"을 참조하십시오.
프로세스
다음 명령을 실행하여 클러스터 업데이트를 시작하도록 관리 승인을 완료합니다.
$ oc adm upgrade클러스터 업데이트가 성공적으로 완료되지 않으면 업데이트 실패에 대한 자세한 정보가
Reason및Message섹션에 제공됩니다.출력 예
Cluster version is 4.15.45 Upgradeable=False Reason: MultipleReasons Message: Cluster should not be upgraded between minor versions for multiple reasons: AdminAckRequired,ResourceDeletesInProgress * Kubernetes 1.29 and therefore OpenShift 4.16 remove several APIs which require admin consideration. Please see the knowledge article https://access.redhat.com/articles/7031404 for details and instructions. * Cluster minor level upgrades are not allowed while resource deletions are in progress; resources=PrometheusRule "openshift-kube-apiserver/kube-apiserver-recording-rules" ReleaseAccepted=False Reason: PreconditionChecks Message: Preconditions failed for payload loaded version="4.16.34" image="quay.io/openshift-release-dev/ocp-release@sha256:41bb08c560f6db5039ccdf242e590e8b23049b5eb31e1c4f6021d1d520b353b8": Precondition "ClusterVersionUpgradeable" failed because of "MultipleReasons": Cluster should not be upgraded between minor versions for multiple reasons: AdminAckRequired,ResourceDeletesInProgress * Kubernetes 1.29 and therefore OpenShift 4.16 remove several APIs which require admin consideration. Please see the knowledge article https://access.redhat.com/articles/7031404 for details and instructions. * Cluster minor level upgrades are not allowed while resource deletions are in progress; resources=PrometheusRule "openshift-kube-apiserver/kube-apiserver-recording-rules" Upstream is unset, so the cluster will use an appropriate default. Channel: eus-4.16 (available channels: candidate-4.15, candidate-4.16, eus-4.16, fast-4.15, fast-4.16, stable-4.15, stable-4.16) Recommended updates: VERSION IMAGE 4.16.34 quay.io/openshift-release-dev/ocp-release@sha256:41bb08c560f6db5039ccdf242e590e8b23049b5eb31e1c4f6021d1d520b353b8참고이 예에서 링크된 Red Hat 지식베이스 문서(OpenShift Container Platform 4.16으로 업그레이드 준비)는 릴리스 간 API 호환성을 확인하는 방법에 대해 자세히 설명합니다.
검증
다음 명령을 실행하여 업데이트를 확인합니다.
$ oc get configmap admin-acks -n openshift-config -o json | jq .data출력 예
{ "ack-4.14-kube-1.28-api-removals-in-4.15": "true", "ack-4.15-kube-1.29-api-removals-in-4.16": "true" }참고이 예에서 클러스터는 4.14에서 4.15로 업데이트되고 컨트롤 플레인 전용 업데이트의 4.15에서 4.16으로 업데이트됩니다.
17.2.6.5. y-stream 컨트롤 플레인 업데이트 시작
이동 중인 전체 새 릴리스를 확인한 후 oc adm upgrade -to=x.y.z 명령을 실행할 수 있습니다.
프로세스
y-stream 컨트롤 플레인 업데이트를 시작합니다. 예를 들어 다음 명령을 실행합니다.
$ oc adm upgrade --to=4.16.14출력 예
Requested update to 4.16.14실행 중인 플랫폼과 관련하여 잠재적인 문제가 있는 z-stream 릴리스로 이동할 수 있습니다. 다음 예제에서는 Microsoft Azure의 클러스터 업데이트에 발생할 수 있는 문제를 보여줍니다.
$ oc adm upgrade --to=4.16.15출력 예
error: the update 4.16.15 is not one of the recommended updates, but is available as a conditional update. To accept the Recommended=Unknown risk and to proceed with update use --allow-not-recommended. Reason: EvaluationFailed Message: Exposure to AzureRegistryImagePreservation is unknown due to an evaluation failure: invalid PromQL result length must be one, but is 0 In Azure clusters, the in-cluster image registry may fail to preserve images on update. https://issues.redhat.com/browse/IR-461참고이 예제에서는 Microsoft Azure에서 호스팅되는 클러스터에 영향을 줄 수 있는 잠재적인 오류를 보여줍니다. 베어 메탈 클러스터에 대한 위험이 표시되지 않습니다.
$ oc adm upgrade --to=4.16.15 --allow-not-recommended출력 예
warning: with --allow-not-recommended you have accepted the risks with 4.14.11 and bypassed Recommended=Unknown EvaluationFailed: Exposure to AzureRegistryImagePreservation is unknown due to an evaluation failure: invalid PromQL result length must be one, but is 0 In Azure clusters, the in-cluster image registry may fail to preserve images on update. https://issues.redhat.com/browse/IR-461 Requested update to 4.16.15
17.2.6.6. 클러스터 업데이트의 두 번째 부분 모니터링
클러스터 업데이트의 두 번째 부분을 <y+1> 버전으로 모니터링합니다.
프로세스
<y+1> 업데이트의 두 번째 부분의 진행 상황을 모니터링합니다. 예를 들어 4.15에서 4.16으로의 업데이트를 모니터링하려면 다음 명령을 실행합니다.
$ watch "oc get clusterversion; echo; oc get co | head -1; oc get co | grep 4.15; oc get co | grep 4.16; echo; oc get no; echo; oc get po -A | grep -E -iv 'running|complete'"출력 예
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.15.33 True True 10m Working towards 4.16.14: 132 of 903 done (14% complete), waiting on kube-controller-manager, kube-scheduler NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE authentication 4.15.33 True False False 5d3h baremetal 4.15.33 True False False 5d4h cloud-controller-manager 4.15.33 True False False 5d4h cloud-credential 4.15.33 True False False 5d4h cluster-autoscaler 4.15.33 True False False 5d4h console 4.15.33 True False False 5d3h ... config-operator 4.16.14 True False False 5d4h etcd 4.16.14 True False False 5d4h kube-apiserver 4.16.14 True True False 5d4h NodeInstallerProgressing: 1 node is at revision 15; 2 nodes are at revision 17 NAME STATUS ROLES AGE VERSION ctrl-plane-0 Ready control-plane,master 5d4h v1.28.13+2ca1a23 ctrl-plane-1 Ready control-plane,master 5d4h v1.28.13+2ca1a23 ctrl-plane-2 Ready control-plane,master 5d4h v1.28.13+2ca1a23 worker-0 Ready mcp-1,worker 5d4h v1.27.15+6147456 worker-1 Ready mcp-2,worker 5d4h v1.27.15+6147456 NAMESPACE NAME READY STATUS RESTARTS AGE openshift-kube-apiserver kube-apiserver-ctrl-plane-0 0/5 Pending 0 <invalid>마지막 컨트롤 플레인 노드가 완료되면 클러스터 버전이 새 EUS 릴리스로 업데이트됩니다. 예를 들면 다음과 같습니다.
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.16.14 True False 123m Cluster version is 4.16.14 NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE authentication 4.16.14 True False False 5d6h baremetal 4.16.14 True False False 5d7h cloud-controller-manager 4.16.14 True False False 5d7h cloud-credential 4.16.14 True False False 5d7h cluster-autoscaler 4.16.14 True False False 5d7h config-operator 4.16.14 True False False 5d7h console 4.16.14 True False False 5d6h #... operator-lifecycle-manager-packageserver 4.16.14 True False False 5d7h service-ca 4.16.14 True False False 5d7h storage 4.16.14 True False False 5d7h NAME STATUS ROLES AGE VERSION ctrl-plane-0 Ready control-plane,master 5d7h v1.29.8+f10c92d ctrl-plane-1 Ready control-plane,master 5d7h v1.29.8+f10c92d ctrl-plane-2 Ready control-plane,master 5d7h v1.29.8+f10c92d worker-0 Ready mcp-1,worker 5d7h v1.27.15+6147456 worker-1 Ready mcp-2,worker 5d7h v1.27.15+6147456
17.2.6.7. 모든 OLM Operator 업데이트
다중 버전 업그레이드의 두 번째 단계에서는 모든 Operator를 승인하고 업그레이드하려는 다른 Operator에 대한 설치 계획을 추가로 추가해야 합니다.
" OLM Operator 업그레이드"에 설명된 것과 동일한 절차를 따릅니다. 필요에 따라 OLM이 아닌 Operator도 업데이트해야 합니다.
프로세스
클러스터 업데이트를 모니터링합니다. 예를 들어 버전 4.14에서 4.15로 클러스터 업데이트를 모니터링하려면 다음 명령을 실행합니다.
$ watch "oc get clusterversion; echo; oc get co | head -1; oc get co | grep 4.14; oc get co | grep 4.15; echo; oc get no; echo; oc get po -A | grep -E -iv 'running|complete'"어떤 Operator를 업데이트해야 하는지 확인합니다.
$ oc get installplan -A | grep -E 'APPROVED|false'해당 Operator의
InstallPlan리소스를 패치합니다.$ oc patch installplan -n metallb-system install-nwjnh --type merge --patch \ '{"spec":{"approved":true}}'다음 명령을 실행하여 네임스페이스를 모니터링합니다.
$ oc get all -n metallb-system업데이트가 완료되면 필요한 Pod가
Running이어야 하며 필요한ReplicaSet리소스가 준비되어야 합니다.
검증
업데이트 중 watch 명령은 한 번에 하나 또는 여러 클러스터 Operator를 통해 주기 때문에 MESSAGE 열의 Operator 업데이트 상태를 제공합니다.
클러스터 Operator 업데이트 프로세스가 완료되면 각 컨트롤 플레인 노드가 한 번에 하나씩 재부팅됩니다.
업데이트 중에 상태 클러스터 Operator가 다시 업데이트되거나 성능이 저하된 상태인 메시지가 표시됩니다. 이는 노드를 재부팅하는 동안 컨트롤 플레인 노드가 오프라인 상태이기 때문입니다.
17.2.6.8. 작업자 노드 업데이트
생성한 관련 mcp 그룹을 일시 중지 해제하여 컨트롤 플레인을 업데이트한 후 작업자 노드를 업그레이드합니다. mcp 그룹 일시 중지를 해제하면 해당 그룹의 작업자 노드에 대한 업그레이드 프로세스가 시작됩니다. 필요에 따라 클러스터의 각 작업자 노드가 재부팅되어 새 EUS, y-stream 또는 z-stream 버전으로 업그레이드합니다.
컨트롤 플레인의 경우 작업자 노드가 업데이트될 때 하나의 재부팅만 필요하며 <y+2>-release 버전을 건너뜁니다. 이는 대규모 베어 메탈 클러스터를 업그레이드하는 데 걸리는 시간을 줄이기 위해 추가된 기능입니다.
이것은 잠재적 인 포인트입니다. 작업자 노드가 <y-2>-release인 동안 새 EUS 릴리스로 업데이트되는 컨트롤 플레인을 사용하여 프로덕션에서 완전히 실행되도록 지원되는 클러스터 버전을 사용할 수 있습니다. 이를 통해 대규모 클러스터는 여러 유지 관리 창에서 단계에서 업그레이드할 수 있습니다.
mcp그룹에서 관리되는 노드 수를 확인할 수 있습니다. 다음 명령을 실행하여mcp그룹 목록을 가져옵니다.$ oc get mcp출력 예
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE master rendered-master-c9a52144456dbff9c9af9c5a37d1b614 True False False 3 3 3 0 36d mcp-1 rendered-mcp-1-07fe50b9ad51fae43ed212e84e1dcc8e False False False 1 0 0 0 47h mcp-2 rendered-mcp-2-07fe50b9ad51fae43ed212e84e1dcc8e False False False 1 0 0 0 47h worker rendered-worker-f1ab7b9a768e1b0ac9290a18817f60f0 True False False 0 0 0 0 36d참고한 번에 업그레이드할
mcp그룹 수를 결정합니다. 이는 한 번에 CNF Pod 수와 Pod 중단 예산 및 유사성 방지 설정을 구성하는 방법에 따라 달라집니다.클러스터의 노드 목록을 가져옵니다.
$ oc get nodes출력 예
NAME STATUS ROLES AGE VERSION ctrl-plane-0 Ready control-plane,master 5d8h v1.29.8+f10c92d ctrl-plane-1 Ready control-plane,master 5d8h v1.29.8+f10c92d ctrl-plane-2 Ready control-plane,master 5d8h v1.29.8+f10c92d worker-0 Ready mcp-1,worker 5d8h v1.27.15+6147456 worker-1 Ready mcp-2,worker 5d8h v1.27.15+6147456일시 중지된
MachineConfigPool그룹을 확인합니다.$ oc get mcp -o json | jq -r '["MCP","Paused"], ["---","------"], (.items[] | [(.metadata.name), (.spec.paused)]) | @tsv' | grep -v worker출력 예
MCP Paused --- ------ master false mcp-1 true mcp-2 true참고각
MachineConfigPool은 독립적으로 일시 중지 해제할 수 있습니다. 따라서 유지 관리 기간이 부족하면 다른 MCP를 즉시 일시 중지 해제할 필요가 없습니다. 클러스터는 여전히 <y-2>-release 버전에서 일부 작업자 노드에서 실행되도록 지원됩니다.업그레이드를 시작하는 데 필요한
mcp그룹 일시 중지를 해제합니다.$ oc patch mcp/mcp-1 --type merge --patch '{"spec":{"paused":false}}'출력 예
machineconfigpool.machineconfiguration.openshift.io/mcp-1 patched필요한
mcp그룹이 일시 중지되지 않았는지 확인합니다.$ oc get mcp -o json | jq -r '["MCP","Paused"], ["---","------"], (.items[] | [(.metadata.name), (.spec.paused)]) | @tsv' | grep -v worker출력 예
MCP Paused --- ------ master false mcp-1 false mcp-2 true각
mcp그룹이 업그레이드되면 일시 중지를 계속 해제하고 나머지 노드를 업그레이드합니다.$ oc get nodes출력 예
NAME STATUS ROLES AGE VERSION ctrl-plane-0 Ready control-plane,master 5d8h v1.29.8+f10c92d ctrl-plane-1 Ready control-plane,master 5d8h v1.29.8+f10c92d ctrl-plane-2 Ready control-plane,master 5d8h v1.29.8+f10c92d worker-0 Ready mcp-1,worker 5d8h v1.29.8+f10c92d worker-1 NotReady,SchedulingDisabled mcp-2,worker 5d8h v1.27.15+6147456
17.2.6.9. 새로 업데이트된 클러스터의 상태 확인
클러스터를 업데이트한 후 다음 명령을 실행하여 클러스터가 백업 및 실행 중인지 확인합니다.
프로세스
다음 명령을 실행하여 클러스터 버전을 확인합니다.
$ oc get clusterversion출력 예
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.16.14 True False 4h38m Cluster version is 4.16.14그러면 새 클러스터 버전이 반환되고
PROGRESSING열에False가 반환되어야 합니다.모든 노드가 준비되었는지 확인합니다.
$ oc get nodes출력 예
NAME STATUS ROLES AGE VERSION ctrl-plane-0 Ready control-plane,master 5d9h v1.29.8+f10c92d ctrl-plane-1 Ready control-plane,master 5d9h v1.29.8+f10c92d ctrl-plane-2 Ready control-plane,master 5d9h v1.29.8+f10c92d worker-0 Ready mcp-1,worker 5d9h v1.29.8+f10c92d worker-1 Ready mcp-2,worker 5d9h v1.29.8+f10c92d클러스터의 모든 노드는
Ready상태에 있어야 하며 동일한 버전을 실행해야 합니다.클러스터에 일시 중지된
mcp리소스가 없는지 확인합니다.$ oc get mcp -o json | jq -r '["MCP","Paused"], ["---","------"], (.items[] | [(.metadata.name), (.spec.paused)]) | @tsv' | grep -v worker출력 예
MCP Paused --- ------ master false mcp-1 false mcp-2 false모든 클러스터 Operator를 사용할 수 있는지 확인합니다.
$ oc get co출력 예
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE authentication 4.16.14 True False False 5d9h baremetal 4.16.14 True False False 5d9h cloud-controller-manager 4.16.14 True False False 5d10h cloud-credential 4.16.14 True False False 5d10h cluster-autoscaler 4.16.14 True False False 5d9h config-operator 4.16.14 True False False 5d9h console 4.16.14 True False False 5d9h control-plane-machine-set 4.16.14 True False False 5d9h csi-snapshot-controller 4.16.14 True False False 5d9h dns 4.16.14 True False False 5d9h etcd 4.16.14 True False False 5d9h image-registry 4.16.14 True False False 85m ingress 4.16.14 True False False 5d9h insights 4.16.14 True False False 5d9h kube-apiserver 4.16.14 True False False 5d9h kube-controller-manager 4.16.14 True False False 5d9h kube-scheduler 4.16.14 True False False 5d9h kube-storage-version-migrator 4.16.14 True False False 4h48m machine-api 4.16.14 True False False 5d9h machine-approver 4.16.14 True False False 5d9h machine-config 4.16.14 True False False 5d9h marketplace 4.16.14 True False False 5d9h monitoring 4.16.14 True False False 5d9h network 4.16.14 True False False 5d9h node-tuning 4.16.14 True False False 5d7h openshift-apiserver 4.16.14 True False False 5d9h openshift-controller-manager 4.16.14 True False False 5d9h openshift-samples 4.16.14 True False False 5h24m operator-lifecycle-manager 4.16.14 True False False 5d9h operator-lifecycle-manager-catalog 4.16.14 True False False 5d9h operator-lifecycle-manager-packageserver 4.16.14 True False False 5d9h service-ca 4.16.14 True False False 5d9h storage 4.16.14 True False False 5d9h모든 클러스터 Operator는
AVAILABLE열에서True를 보고해야 합니다.모든 Pod가 정상인지 확인합니다.
$ oc get po -A | grep -E -iv 'complete|running'Pod를 반환하지 않아야 합니다.
참고업데이트 후에도 몇 개의 Pod가 계속 이동하는 것을 볼 수 있습니다. 잠시 동안 모든 포드가 지워졌는지 확인하십시오.
17.2.7. y-stream 클러스터 업데이트 완료
다음 단계에 따라 y-stream 클러스터 업데이트를 수행하고 업데이트를 모니터링하여 완료합니다. y-stream 업데이트를 완료하는 것은 컨트롤 플레인만 업데이트하는 것보다 더 간단합니다.
17.2.7.1. 컨트롤 플레인만 또는 y-stream 업데이트 확인
4.11 이상에서 모든 버전으로 업데이트하는 경우 업데이트가 계속될 수 있음을 수동으로 승인해야 합니다.
업데이트를 확인하기 전에 업데이트 중인 버전에서 제거된 Kubernetes API를 사용하지 않는지 확인합니다. 예를 들어 OpenShift Container Platform 4.17에는 API 제거가 없습니다. 자세한 내용은 "Kubernetes API 제거"를 참조하십시오.
사전 요구 사항
- 클러스터에서 실행되는 모든 애플리케이션의 API가 OpenShift Container Platform의 다음 Y-stream 릴리스와 호환되는지 확인했습니다. 호환성에 대한 자세한 내용은 "업데이트 버전 간 클러스터 API 버전 확인"을 참조하십시오.
프로세스
다음 명령을 실행하여 클러스터 업데이트를 시작하도록 관리 승인을 완료합니다.
$ oc adm upgrade클러스터 업데이트가 성공적으로 완료되지 않으면 업데이트 실패에 대한 자세한 정보가
Reason및Message섹션에 제공됩니다.출력 예
Cluster version is 4.15.45 Upgradeable=False Reason: MultipleReasons Message: Cluster should not be upgraded between minor versions for multiple reasons: AdminAckRequired,ResourceDeletesInProgress * Kubernetes 1.29 and therefore OpenShift 4.16 remove several APIs which require admin consideration. Please see the knowledge article https://access.redhat.com/articles/7031404 for details and instructions. * Cluster minor level upgrades are not allowed while resource deletions are in progress; resources=PrometheusRule "openshift-kube-apiserver/kube-apiserver-recording-rules" ReleaseAccepted=False Reason: PreconditionChecks Message: Preconditions failed for payload loaded version="4.16.34" image="quay.io/openshift-release-dev/ocp-release@sha256:41bb08c560f6db5039ccdf242e590e8b23049b5eb31e1c4f6021d1d520b353b8": Precondition "ClusterVersionUpgradeable" failed because of "MultipleReasons": Cluster should not be upgraded between minor versions for multiple reasons: AdminAckRequired,ResourceDeletesInProgress * Kubernetes 1.29 and therefore OpenShift 4.16 remove several APIs which require admin consideration. Please see the knowledge article https://access.redhat.com/articles/7031404 for details and instructions. * Cluster minor level upgrades are not allowed while resource deletions are in progress; resources=PrometheusRule "openshift-kube-apiserver/kube-apiserver-recording-rules" Upstream is unset, so the cluster will use an appropriate default. Channel: eus-4.16 (available channels: candidate-4.15, candidate-4.16, eus-4.16, fast-4.15, fast-4.16, stable-4.15, stable-4.16) Recommended updates: VERSION IMAGE 4.16.34 quay.io/openshift-release-dev/ocp-release@sha256:41bb08c560f6db5039ccdf242e590e8b23049b5eb31e1c4f6021d1d520b353b8참고이 예에서 링크된 Red Hat 지식베이스 문서(OpenShift Container Platform 4.16으로 업그레이드 준비)는 릴리스 간 API 호환성을 확인하는 방법에 대해 자세히 설명합니다.
검증
다음 명령을 실행하여 업데이트를 확인합니다.
$ oc get configmap admin-acks -n openshift-config -o json | jq .data출력 예
{ "ack-4.14-kube-1.28-api-removals-in-4.15": "true", "ack-4.15-kube-1.29-api-removals-in-4.16": "true" }참고이 예에서 클러스터는 4.14에서 4.15로 업데이트되고 컨트롤 플레인 전용 업데이트의 4.15에서 4.16으로 업데이트됩니다.
17.2.7.2. 클러스터 업데이트 시작
하나의 y-stream 릴리스에서 다음 버전으로 업데이트할 때 중간 z-stream 릴리스도 호환되는지 확인해야 합니다.
oc adm upgrade 명령을 실행하여 실행 가능한 릴리스로 업데이트 중인지 확인할 수 있습니다. oc adm upgrade 명령은 호환되는 업데이트 릴리스를 나열합니다.
프로세스
업데이트를 시작합니다.
$ oc adm upgrade --to=4.15.33중요- Control Plane만 업데이트: 임시 <y+1> 릴리스 경로를 가리키십시오.
- Y-stream 업데이트 - Kubernetes 버전 skew 정책을 따르는 올바른 <y.z> 릴리스를 사용해야 합니다.
- Z-stream 업데이트 - 특정 릴리스로 이동하는 데 문제가 없는지 확인합니다.
출력 예
Requested update to 4.15.331 - 1
특정 업데이트에따라 요청된 업데이트 값이 변경됩니다.
17.2.7.3. 클러스터 업데이트 모니터링
업데이트 중에 클러스터 상태를 자주 확인해야 합니다. 노드 상태, 클러스터 Operator 상태 및 실패한 Pod가 있는지 확인합니다.
프로세스
클러스터 업데이트를 모니터링합니다. 예를 들어 버전 4.14에서 4.15로 클러스터 업데이트를 모니터링하려면 다음 명령을 실행합니다.
$ watch "oc get clusterversion; echo; oc get co | head -1; oc get co | grep 4.14; oc get co | grep 4.15; echo; oc get no; echo; oc get po -A | grep -E -iv 'running|complete'"출력 예
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.14.34 True True 4m6s Working towards 4.15.33: 111 of 873 done (12% complete), waiting on kube-apiserver NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE authentication 4.14.34 True False False 4d22h baremetal 4.14.34 True False False 4d23h cloud-controller-manager 4.14.34 True False False 4d23h cloud-credential 4.14.34 True False False 4d23h cluster-autoscaler 4.14.34 True False False 4d23h console 4.14.34 True False False 4d22h ... storage 4.14.34 True False False 4d23h config-operator 4.15.33 True False False 4d23h etcd 4.15.33 True False False 4d23h NAME STATUS ROLES AGE VERSION ctrl-plane-0 Ready control-plane,master 4d23h v1.27.15+6147456 ctrl-plane-1 Ready control-plane,master 4d23h v1.27.15+6147456 ctrl-plane-2 Ready control-plane,master 4d23h v1.27.15+6147456 worker-0 Ready mcp-1,worker 4d23h v1.27.15+6147456 worker-1 Ready mcp-2,worker 4d23h v1.27.15+6147456 NAMESPACE NAME READY STATUS RESTARTS AGE openshift-marketplace redhat-marketplace-rf86t 0/1 ContainerCreating 0 0s
검증
업데이트 중 watch 명령은 한 번에 하나 또는 여러 클러스터 Operator를 통해 주기 때문에 MESSAGE 열의 Operator 업데이트 상태를 제공합니다.
클러스터 Operator 업데이트 프로세스가 완료되면 각 컨트롤 플레인 노드가 한 번에 하나씩 재부팅됩니다.
업데이트 중에 상태 클러스터 Operator가 다시 업데이트되거나 성능이 저하된 상태인 메시지가 표시됩니다. 이는 노드를 재부팅하는 동안 컨트롤 플레인 노드가 오프라인 상태이기 때문입니다.
마지막 컨트롤 플레인 노드 재부팅이 완료되면 클러스터 버전이 업데이트됨으로 표시됩니다.
컨트롤 플레인 업데이트가 완료되면 다음과 같은 메시지가 표시됩니다. 이 예에서는 중간 y-stream 릴리스로 완료된 업데이트를 보여줍니다.
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS
version 4.15.33 True False 28m Cluster version is 4.15.33
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE
authentication 4.15.33 True False False 5d
baremetal 4.15.33 True False False 5d
cloud-controller-manager 4.15.33 True False False 5d1h
cloud-credential 4.15.33 True False False 5d1h
cluster-autoscaler 4.15.33 True False False 5d
config-operator 4.15.33 True False False 5d
console 4.15.33 True False False 5d
...
service-ca 4.15.33 True False False 5d
storage 4.15.33 True False False 5d
NAME STATUS ROLES AGE VERSION
ctrl-plane-0 Ready control-plane,master 5d v1.28.13+2ca1a23
ctrl-plane-1 Ready control-plane,master 5d v1.28.13+2ca1a23
ctrl-plane-2 Ready control-plane,master 5d v1.28.13+2ca1a23
worker-0 Ready mcp-1,worker 5d v1.28.13+2ca1a23
worker-1 Ready mcp-2,worker 5d v1.28.13+2ca1a2317.2.7.4. OLM Operator 업데이트
통신 환경에서 소프트웨어는 프로덕션 클러스터에 로드되기 전에 vletsd를 검사해야 합니다. 프로덕션 클러스터는 연결이 끊긴 네트워크에서도 구성됩니다. 즉, 인터넷에 항상 직접 연결되지는 않습니다. 클러스터는 연결이 끊긴 네트워크에 있기 때문에 OpenShift Operator는 설치 중에 수동으로 업데이트되도록 구성되므로 클러스터별로 새 버전을 관리할 수 있습니다. Operator를 최신 버전으로 이동하려면 다음 절차를 수행합니다.
프로세스
어떤 Operator를 업데이트해야 하는지 확인합니다.
$ oc get installplan -A | grep -E 'APPROVED|false'출력 예
NAMESPACE NAME CSV APPROVAL APPROVED metallb-system install-nwjnh metallb-operator.v4.16.0-202409202304 Manual false openshift-nmstate install-5r7wr kubernetes-nmstate-operator.4.16.0-202409251605 Manual false해당 Operator의
InstallPlan리소스를 패치합니다.$ oc patch installplan -n metallb-system install-nwjnh --type merge --patch \ '{"spec":{"approved":true}}'출력 예
installplan.operators.coreos.com/install-nwjnh patched다음 명령을 실행하여 네임스페이스를 모니터링합니다.
$ oc get all -n metallb-system출력 예
NAME READY STATUS RESTARTS AGE pod/metallb-operator-controller-manager-69b5f884c-8bp22 0/1 ContainerCreating 0 4s pod/metallb-operator-controller-manager-77895bdb46-bqjdx 1/1 Running 0 4m1s pod/metallb-operator-webhook-server-5d9b968896-vnbhk 0/1 ContainerCreating 0 4s pod/metallb-operator-webhook-server-d76f9c6c8-57r4w 1/1 Running 0 4m1s ... NAME DESIRED CURRENT READY AGE replicaset.apps/metallb-operator-controller-manager-69b5f884c 1 1 0 4s replicaset.apps/metallb-operator-controller-manager-77895bdb46 1 1 1 4m1s replicaset.apps/metallb-operator-controller-manager-99b76f88 0 0 0 4m40s replicaset.apps/metallb-operator-webhook-server-5d9b968896 1 1 0 4s replicaset.apps/metallb-operator-webhook-server-6f7dbfdb88 0 0 0 4m40s replicaset.apps/metallb-operator-webhook-server-d76f9c6c8 1 1 1 4m1s업데이트가 완료되면 필요한 Pod가
Running이어야 하며 필요한ReplicaSet리소스가 준비되어야 합니다.NAME READY STATUS RESTARTS AGE pod/metallb-operator-controller-manager-69b5f884c-8bp22 1/1 Running 0 25s pod/metallb-operator-webhook-server-5d9b968896-vnbhk 1/1 Running 0 25s ... NAME DESIRED CURRENT READY AGE replicaset.apps/metallb-operator-controller-manager-69b5f884c 1 1 1 25s replicaset.apps/metallb-operator-controller-manager-77895bdb46 0 0 0 4m22s replicaset.apps/metallb-operator-webhook-server-5d9b968896 1 1 1 25s replicaset.apps/metallb-operator-webhook-server-d76f9c6c8 0 0 0 4m22s
검증
Operator를 두 번 업데이트할 필요가 없는지 확인합니다.
$ oc get installplan -A | grep -E 'APPROVED|false'반환되는 출력이 없어야 합니다.
참고일부 Operator에는 최종 버전 전에 설치해야 하는 임시 z-stream 릴리스 버전이 있기 때문에 업데이트를 두 번 승인해야 하는 경우가 있습니다.
17.2.7.5. 작업자 노드 업데이트
생성한 관련 mcp 그룹을 일시 중지 해제하여 컨트롤 플레인을 업데이트한 후 작업자 노드를 업그레이드합니다. mcp 그룹 일시 중지를 해제하면 해당 그룹의 작업자 노드에 대한 업그레이드 프로세스가 시작됩니다. 필요에 따라 클러스터의 각 작업자 노드가 재부팅되어 새 EUS, y-stream 또는 z-stream 버전으로 업그레이드합니다.
컨트롤 플레인의 경우 작업자 노드가 업데이트될 때 하나의 재부팅만 필요하며 <y+2>-release 버전을 건너뜁니다. 이는 대규모 베어 메탈 클러스터를 업그레이드하는 데 걸리는 시간을 줄이기 위해 추가된 기능입니다.
이것은 잠재적 인 포인트입니다. 작업자 노드가 <y-2>-release인 동안 새 EUS 릴리스로 업데이트되는 컨트롤 플레인을 사용하여 프로덕션에서 완전히 실행되도록 지원되는 클러스터 버전을 사용할 수 있습니다. 이를 통해 대규모 클러스터는 여러 유지 관리 창에서 단계에서 업그레이드할 수 있습니다.
mcp그룹에서 관리되는 노드 수를 확인할 수 있습니다. 다음 명령을 실행하여mcp그룹 목록을 가져옵니다.$ oc get mcp출력 예
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE master rendered-master-c9a52144456dbff9c9af9c5a37d1b614 True False False 3 3 3 0 36d mcp-1 rendered-mcp-1-07fe50b9ad51fae43ed212e84e1dcc8e False False False 1 0 0 0 47h mcp-2 rendered-mcp-2-07fe50b9ad51fae43ed212e84e1dcc8e False False False 1 0 0 0 47h worker rendered-worker-f1ab7b9a768e1b0ac9290a18817f60f0 True False False 0 0 0 0 36d참고한 번에 업그레이드할
mcp그룹 수를 결정합니다. 이는 한 번에 CNF Pod 수와 Pod 중단 예산 및 유사성 방지 설정을 구성하는 방법에 따라 달라집니다.클러스터의 노드 목록을 가져옵니다.
$ oc get nodes출력 예
NAME STATUS ROLES AGE VERSION ctrl-plane-0 Ready control-plane,master 5d8h v1.29.8+f10c92d ctrl-plane-1 Ready control-plane,master 5d8h v1.29.8+f10c92d ctrl-plane-2 Ready control-plane,master 5d8h v1.29.8+f10c92d worker-0 Ready mcp-1,worker 5d8h v1.27.15+6147456 worker-1 Ready mcp-2,worker 5d8h v1.27.15+6147456일시 중지된
MachineConfigPool그룹을 확인합니다.$ oc get mcp -o json | jq -r '["MCP","Paused"], ["---","------"], (.items[] | [(.metadata.name), (.spec.paused)]) | @tsv' | grep -v worker출력 예
MCP Paused --- ------ master false mcp-1 true mcp-2 true참고각
MachineConfigPool은 독립적으로 일시 중지 해제할 수 있습니다. 따라서 유지 관리 기간이 부족하면 다른 MCP를 즉시 일시 중지 해제할 필요가 없습니다. 클러스터는 여전히 <y-2>-release 버전에서 일부 작업자 노드에서 실행되도록 지원됩니다.업그레이드를 시작하는 데 필요한
mcp그룹 일시 중지를 해제합니다.$ oc patch mcp/mcp-1 --type merge --patch '{"spec":{"paused":false}}'출력 예
machineconfigpool.machineconfiguration.openshift.io/mcp-1 patched필요한
mcp그룹이 일시 중지되지 않았는지 확인합니다.$ oc get mcp -o json | jq -r '["MCP","Paused"], ["---","------"], (.items[] | [(.metadata.name), (.spec.paused)]) | @tsv' | grep -v worker출력 예
MCP Paused --- ------ master false mcp-1 false mcp-2 true각
mcp그룹이 업그레이드되면 일시 중지를 계속 해제하고 나머지 노드를 업그레이드합니다.$ oc get nodes출력 예
NAME STATUS ROLES AGE VERSION ctrl-plane-0 Ready control-plane,master 5d8h v1.29.8+f10c92d ctrl-plane-1 Ready control-plane,master 5d8h v1.29.8+f10c92d ctrl-plane-2 Ready control-plane,master 5d8h v1.29.8+f10c92d worker-0 Ready mcp-1,worker 5d8h v1.29.8+f10c92d worker-1 NotReady,SchedulingDisabled mcp-2,worker 5d8h v1.27.15+6147456
17.2.7.6. 새로 업데이트된 클러스터의 상태 확인
클러스터를 업데이트한 후 다음 명령을 실행하여 클러스터가 백업 및 실행 중인지 확인합니다.
프로세스
다음 명령을 실행하여 클러스터 버전을 확인합니다.
$ oc get clusterversion출력 예
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.16.14 True False 4h38m Cluster version is 4.16.14그러면 새 클러스터 버전이 반환되고
PROGRESSING열에False가 반환되어야 합니다.모든 노드가 준비되었는지 확인합니다.
$ oc get nodes출력 예
NAME STATUS ROLES AGE VERSION ctrl-plane-0 Ready control-plane,master 5d9h v1.29.8+f10c92d ctrl-plane-1 Ready control-plane,master 5d9h v1.29.8+f10c92d ctrl-plane-2 Ready control-plane,master 5d9h v1.29.8+f10c92d worker-0 Ready mcp-1,worker 5d9h v1.29.8+f10c92d worker-1 Ready mcp-2,worker 5d9h v1.29.8+f10c92d클러스터의 모든 노드는
Ready상태에 있어야 하며 동일한 버전을 실행해야 합니다.클러스터에 일시 중지된
mcp리소스가 없는지 확인합니다.$ oc get mcp -o json | jq -r '["MCP","Paused"], ["---","------"], (.items[] | [(.metadata.name), (.spec.paused)]) | @tsv' | grep -v worker출력 예
MCP Paused --- ------ master false mcp-1 false mcp-2 false모든 클러스터 Operator를 사용할 수 있는지 확인합니다.
$ oc get co출력 예
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE authentication 4.16.14 True False False 5d9h baremetal 4.16.14 True False False 5d9h cloud-controller-manager 4.16.14 True False False 5d10h cloud-credential 4.16.14 True False False 5d10h cluster-autoscaler 4.16.14 True False False 5d9h config-operator 4.16.14 True False False 5d9h console 4.16.14 True False False 5d9h control-plane-machine-set 4.16.14 True False False 5d9h csi-snapshot-controller 4.16.14 True False False 5d9h dns 4.16.14 True False False 5d9h etcd 4.16.14 True False False 5d9h image-registry 4.16.14 True False False 85m ingress 4.16.14 True False False 5d9h insights 4.16.14 True False False 5d9h kube-apiserver 4.16.14 True False False 5d9h kube-controller-manager 4.16.14 True False False 5d9h kube-scheduler 4.16.14 True False False 5d9h kube-storage-version-migrator 4.16.14 True False False 4h48m machine-api 4.16.14 True False False 5d9h machine-approver 4.16.14 True False False 5d9h machine-config 4.16.14 True False False 5d9h marketplace 4.16.14 True False False 5d9h monitoring 4.16.14 True False False 5d9h network 4.16.14 True False False 5d9h node-tuning 4.16.14 True False False 5d7h openshift-apiserver 4.16.14 True False False 5d9h openshift-controller-manager 4.16.14 True False False 5d9h openshift-samples 4.16.14 True False False 5h24m operator-lifecycle-manager 4.16.14 True False False 5d9h operator-lifecycle-manager-catalog 4.16.14 True False False 5d9h operator-lifecycle-manager-packageserver 4.16.14 True False False 5d9h service-ca 4.16.14 True False False 5d9h storage 4.16.14 True False False 5d9h모든 클러스터 Operator는
AVAILABLE열에서True를 보고해야 합니다.모든 Pod가 정상인지 확인합니다.
$ oc get po -A | grep -E -iv 'complete|running'Pod를 반환하지 않아야 합니다.
참고업데이트 후에도 몇 개의 Pod가 계속 이동하는 것을 볼 수 있습니다. 잠시 동안 모든 포드가 지워졌는지 확인하십시오.
17.2.8. z-stream 클러스터 업데이트 완료
다음 단계에 따라 z-stream 클러스터 업데이트를 수행하고 업데이트를 모니터링하여 완료합니다. z-stream 업데이트를 완료하는 것은 컨트롤 플레인만 또는 y-stream 업데이트보다 간단합니다.
17.2.8.1. 클러스터 업데이트 시작
하나의 y-stream 릴리스에서 다음 버전으로 업데이트할 때 중간 z-stream 릴리스도 호환되는지 확인해야 합니다.
oc adm upgrade 명령을 실행하여 실행 가능한 릴리스로 업데이트 중인지 확인할 수 있습니다. oc adm upgrade 명령은 호환되는 업데이트 릴리스를 나열합니다.
프로세스
업데이트를 시작합니다.
$ oc adm upgrade --to=4.15.33중요- Control Plane만 업데이트: 임시 <y+1> 릴리스 경로를 가리키십시오.
- Y-stream 업데이트 - Kubernetes 버전 skew 정책을 따르는 올바른 <y.z> 릴리스를 사용해야 합니다.
- Z-stream 업데이트 - 특정 릴리스로 이동하는 데 문제가 없는지 확인합니다.
출력 예
Requested update to 4.15.331 - 1
특정 업데이트에따라 요청된 업데이트 값이 변경됩니다.
17.2.8.2. 작업자 노드 업데이트
생성한 관련 mcp 그룹을 일시 중지 해제하여 컨트롤 플레인을 업데이트한 후 작업자 노드를 업그레이드합니다. mcp 그룹 일시 중지를 해제하면 해당 그룹의 작업자 노드에 대한 업그레이드 프로세스가 시작됩니다. 필요에 따라 클러스터의 각 작업자 노드가 재부팅되어 새 EUS, y-stream 또는 z-stream 버전으로 업그레이드합니다.
컨트롤 플레인의 경우 작업자 노드가 업데이트될 때 하나의 재부팅만 필요하며 <y+2>-release 버전을 건너뜁니다. 이는 대규모 베어 메탈 클러스터를 업그레이드하는 데 걸리는 시간을 줄이기 위해 추가된 기능입니다.
이것은 잠재적 인 포인트입니다. 작업자 노드가 <y-2>-release인 동안 새 EUS 릴리스로 업데이트되는 컨트롤 플레인을 사용하여 프로덕션에서 완전히 실행되도록 지원되는 클러스터 버전을 사용할 수 있습니다. 이를 통해 대규모 클러스터는 여러 유지 관리 창에서 단계에서 업그레이드할 수 있습니다.
mcp그룹에서 관리되는 노드 수를 확인할 수 있습니다. 다음 명령을 실행하여mcp그룹 목록을 가져옵니다.$ oc get mcp출력 예
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE master rendered-master-c9a52144456dbff9c9af9c5a37d1b614 True False False 3 3 3 0 36d mcp-1 rendered-mcp-1-07fe50b9ad51fae43ed212e84e1dcc8e False False False 1 0 0 0 47h mcp-2 rendered-mcp-2-07fe50b9ad51fae43ed212e84e1dcc8e False False False 1 0 0 0 47h worker rendered-worker-f1ab7b9a768e1b0ac9290a18817f60f0 True False False 0 0 0 0 36d참고한 번에 업그레이드할
mcp그룹 수를 결정합니다. 이는 한 번에 CNF Pod 수와 Pod 중단 예산 및 유사성 방지 설정을 구성하는 방법에 따라 달라집니다.클러스터의 노드 목록을 가져옵니다.
$ oc get nodes출력 예
NAME STATUS ROLES AGE VERSION ctrl-plane-0 Ready control-plane,master 5d8h v1.29.8+f10c92d ctrl-plane-1 Ready control-plane,master 5d8h v1.29.8+f10c92d ctrl-plane-2 Ready control-plane,master 5d8h v1.29.8+f10c92d worker-0 Ready mcp-1,worker 5d8h v1.27.15+6147456 worker-1 Ready mcp-2,worker 5d8h v1.27.15+6147456일시 중지된
MachineConfigPool그룹을 확인합니다.$ oc get mcp -o json | jq -r '["MCP","Paused"], ["---","------"], (.items[] | [(.metadata.name), (.spec.paused)]) | @tsv' | grep -v worker출력 예
MCP Paused --- ------ master false mcp-1 true mcp-2 true참고각
MachineConfigPool은 독립적으로 일시 중지 해제할 수 있습니다. 따라서 유지 관리 기간이 부족하면 다른 MCP를 즉시 일시 중지 해제할 필요가 없습니다. 클러스터는 여전히 <y-2>-release 버전에서 일부 작업자 노드에서 실행되도록 지원됩니다.업그레이드를 시작하는 데 필요한
mcp그룹 일시 중지를 해제합니다.$ oc patch mcp/mcp-1 --type merge --patch '{"spec":{"paused":false}}'출력 예
machineconfigpool.machineconfiguration.openshift.io/mcp-1 patched필요한
mcp그룹이 일시 중지되지 않았는지 확인합니다.$ oc get mcp -o json | jq -r '["MCP","Paused"], ["---","------"], (.items[] | [(.metadata.name), (.spec.paused)]) | @tsv' | grep -v worker출력 예
MCP Paused --- ------ master false mcp-1 false mcp-2 true각
mcp그룹이 업그레이드되면 일시 중지를 계속 해제하고 나머지 노드를 업그레이드합니다.$ oc get nodes출력 예
NAME STATUS ROLES AGE VERSION ctrl-plane-0 Ready control-plane,master 5d8h v1.29.8+f10c92d ctrl-plane-1 Ready control-plane,master 5d8h v1.29.8+f10c92d ctrl-plane-2 Ready control-plane,master 5d8h v1.29.8+f10c92d worker-0 Ready mcp-1,worker 5d8h v1.29.8+f10c92d worker-1 NotReady,SchedulingDisabled mcp-2,worker 5d8h v1.27.15+6147456
17.2.8.3. 새로 업데이트된 클러스터의 상태 확인
클러스터를 업데이트한 후 다음 명령을 실행하여 클러스터가 백업 및 실행 중인지 확인합니다.
프로세스
다음 명령을 실행하여 클러스터 버전을 확인합니다.
$ oc get clusterversion출력 예
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.16.14 True False 4h38m Cluster version is 4.16.14그러면 새 클러스터 버전이 반환되고
PROGRESSING열에False가 반환되어야 합니다.모든 노드가 준비되었는지 확인합니다.
$ oc get nodes출력 예
NAME STATUS ROLES AGE VERSION ctrl-plane-0 Ready control-plane,master 5d9h v1.29.8+f10c92d ctrl-plane-1 Ready control-plane,master 5d9h v1.29.8+f10c92d ctrl-plane-2 Ready control-plane,master 5d9h v1.29.8+f10c92d worker-0 Ready mcp-1,worker 5d9h v1.29.8+f10c92d worker-1 Ready mcp-2,worker 5d9h v1.29.8+f10c92d클러스터의 모든 노드는
Ready상태에 있어야 하며 동일한 버전을 실행해야 합니다.클러스터에 일시 중지된
mcp리소스가 없는지 확인합니다.$ oc get mcp -o json | jq -r '["MCP","Paused"], ["---","------"], (.items[] | [(.metadata.name), (.spec.paused)]) | @tsv' | grep -v worker출력 예
MCP Paused --- ------ master false mcp-1 false mcp-2 false모든 클러스터 Operator를 사용할 수 있는지 확인합니다.
$ oc get co출력 예
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE authentication 4.16.14 True False False 5d9h baremetal 4.16.14 True False False 5d9h cloud-controller-manager 4.16.14 True False False 5d10h cloud-credential 4.16.14 True False False 5d10h cluster-autoscaler 4.16.14 True False False 5d9h config-operator 4.16.14 True False False 5d9h console 4.16.14 True False False 5d9h control-plane-machine-set 4.16.14 True False False 5d9h csi-snapshot-controller 4.16.14 True False False 5d9h dns 4.16.14 True False False 5d9h etcd 4.16.14 True False False 5d9h image-registry 4.16.14 True False False 85m ingress 4.16.14 True False False 5d9h insights 4.16.14 True False False 5d9h kube-apiserver 4.16.14 True False False 5d9h kube-controller-manager 4.16.14 True False False 5d9h kube-scheduler 4.16.14 True False False 5d9h kube-storage-version-migrator 4.16.14 True False False 4h48m machine-api 4.16.14 True False False 5d9h machine-approver 4.16.14 True False False 5d9h machine-config 4.16.14 True False False 5d9h marketplace 4.16.14 True False False 5d9h monitoring 4.16.14 True False False 5d9h network 4.16.14 True False False 5d9h node-tuning 4.16.14 True False False 5d7h openshift-apiserver 4.16.14 True False False 5d9h openshift-controller-manager 4.16.14 True False False 5d9h openshift-samples 4.16.14 True False False 5h24m operator-lifecycle-manager 4.16.14 True False False 5d9h operator-lifecycle-manager-catalog 4.16.14 True False False 5d9h operator-lifecycle-manager-packageserver 4.16.14 True False False 5d9h service-ca 4.16.14 True False False 5d9h storage 4.16.14 True False False 5d9h모든 클러스터 Operator는
AVAILABLE열에서True를 보고해야 합니다.모든 Pod가 정상인지 확인합니다.
$ oc get po -A | grep -E -iv 'complete|running'Pod를 반환하지 않아야 합니다.
참고업데이트 후에도 몇 개의 Pod가 계속 이동하는 것을 볼 수 있습니다. 잠시 동안 모든 포드가 지워졌는지 확인하십시오.
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}