OCP4 업그레이드 방안 공유~ (4.6 to 4.10)

최근 많은 사이트에서 OCP4.x의 최신 버전 업그레이드를 고려하고 있는 것으로 알고 있습니다.

이번 경험을 통해 업그레이드를 계획하고 진행하면서 고려했던 사항과 유의점을 공유하고, OCP 업그레이드를 앞으로 어떻게 안전하고 효율적으로 진행할 수 있을지 이야기해보고자 합니다.

작업 계획

먼저, 업그레이드 과정을 계획하고 일정을 수립하기 위해 다음 과정을 논의했습니다.

1. 업그레이드 목적 및 개요

최초로 업그레이드를 고려한 시점은 XXX 프로젝트의 DB 가용성 테스트에서 ‘haproxy maxconn 수 변경’이 필요하여 이를 지원하는 버전으로 업그레이드를 고려하였고, 이어서 OCP4.6의 Maintenance support 및 EOS 종료로 인해 최종적으로 업그레이드를 결정하게 되었습니다.

OCP Lifecycle:

OpenShift Container Platform Life Cycle - Red Hat Customer Portal

2. 업그레이드 계획 수립

2-1. 업그레이드 계획 시 고려사항

항목고려사항

OCP4 버전	업그레이드 경로 파악(Red Hat OpenShift Container Platform Update Graph)OCP는 Kubernetes를 기반으로 하기 때문에 k8s의 버전 차이 정책을 준수OCP 버전 업그레이드에 따른 k8s 버전 업그레이드가 동반되므로 업그레이드는 단계적으로 진행(k8s 마이너 버전 1개씩)이에 따라 레드햇 고객 포털에서는 OCP 버전 업그레이드 경로를 제공
클러스터 규모	업그레이드 대상 클러스터 수와 클러스터별 노드 규모 파악OCP 업그레이드는 노드 자체 업그레이드도 포함되므로 클러스터의 노드 수는 업그레이드 소요 시간에 큰 비중을 차지Bare metal 노드인 경우 시스템 체크 시간 때문에 업그레이드 시간이 더 오래 걸릴 수도 있음RHEL 노드인 경우, 별도 업그레이드 작업 필요
클러스터 백업	OCP4는 다운그레이드를 지원하지 않으므로 고객사에서 백업 지원 가능 여부 파악 필요OCP 백업: ETCD 백업OCP 외부 백업: VM 스냅샷, Bare metal 백업
클러스터 자원	업그레이드는 노드를 롤링으로 업그레이드하기 때문에 일시적으로 Pod가 한 노드로 몰릴 수 있는데 자원의 여유가 없다면(특히 메모리) 퇴거된 Pod가 다른 노드에서 기동되지 않을 수 있기 때문에 자원 확보 필요CPU메모리(두 배 이상 증설이 필요할 수도 있음)Mirror Registry 가용 용량
오퍼레이터 허브	사용되는 operator의 종류에 따라 업그레이드 영향도 분석 필요기존 버전 오퍼레이터 제거를 위해 오퍼레이터 > 연관되는 하위 Pod > 하위 자원(PV,SC 등)을 모두 파악 필요 Operator 업그레이드 방법 선택제거 후 재구축Operator 채널 변경을 통한 업그레이드
애플리케이션	OCP API를 호출하는 애플리케이션은 없는지 확인Node Selector 설정이 되어 있는지 확인

2-2. 업그레이드 사전 고객 환경 점검

1	diconnected 환경인지?	Disconnected 환경	Disconnected 환경
2	클러스터 개수	3개	4개
3	Current Channel(oc get clusterversion -o json|jq ".items[0].spec")	stable-4.6	stable-4.6
4	Architecture	X86_64	X86_64
5	Current OpenShift Version	4.6.22	4.6.22
6	Target OpenShift Version	4.10(4.10 EUS GA버전)	4.10(4.10 EUS GA버전)
7	Operator Hub 사용 및 설치현황	Cluster LoggingOpenshift Elasticsearch OperatorLocal Storage	Cluster LoggingOpenshift Elasticsearch OperatorLocal Storage3Scale
8	노드별 환경(VM / Baremetal)	BareMetal : Worker(Router)VM : Master, Infra, Logging	BareMetal : Worker(Router)VM : Master, Infra, Logging
9	Worker Node의 경우 Rhel OS 사용 유무	Master : CoreOSInfra : CoreOSLogging : CoreOSWorker : CoreOS	Master : CoreOSInfra : CoreOSLogging : CoreOSWorker : CoreOS
10	Rhel OS를 사용한다면,Rhel Version 정보 확인 필요	N/A	bastion rhel 8.3 * 2
11	타사 솔루션	JEUS WEB/WAS	WebtoB, JEUS, jennifer

2-3. 업그레이드 순서

사전에 파악된 고객 시스템 OpenShift 4의 현재 버전은 4.6.22이며 현재 최신 버전인 4.10.9 버전으로의 업그레이드는 다음과 같은 순서로 진행됩니다.

 

2-4. 주요 일정

위 업그레이드 작업을 순차적으로 진행하기 위해 고객 환경에서 업그레이드 영향도를 파악할 시간이 필요했습니다. 따라서 초도 클러스터는 보다 충분한 여유시간을 할당하여 영향도를 파악하고, 나머지 클러스터를 이어서 진행합니다.

 

단계 별 소요시간

1	단계	업그레이드 이미지 및 환경 파악 준비	D ~ D+3	3일
2	첫번째 대상 업그레이드 수행	D+4 ~ D+5	5일
3	업그레이드후 영향도 확인	D+9 ~ D+13	5일	조정가능
4	두번째 대상 업그레이드 수행 및 영향도 확인	D+14 ~ D+16	3일
5	세번째 대상 업그레이드 수행 및 영향도 확인	D+17 ~ D+19	3일
6	네번째 대상 업그레이드 수행 및 영향도 확인	D+20 ~ D+22	3일
1	단계	업그레이드 이미지 및 환경 파악 준비	D ~D+3	3일
2	첫번째 대상 업그레이드 수행	D+4 ~ D+5	5일
3	업그레이드후 영향도 확인	D+9 ~ D+13	5일	조정가능
4	두번째 대상 업그레이드 수행 및 영향도 확인	D+14 ~ D+16	3일
5	세번째 대상 업그레이드 수행 및 영향도 확인	D+17 ~ D+19	3일

3. 작업 계획서 작성

작업 수행

1. 업그레이드 이미지 준비

1-1. OCP4.x 이미지 및 CLI tool 준비

• CLI tool은 4.10.9의 oc 하나만 준비
• 모든 이미지는 ocp4/openshift4라는 이름의 repository로 준비 (하나의 repo안에 4.6~4.10의 모든 이미지 미러링)

1-2. 오퍼레이터 이미지 준비

• 4.10 기준의 ElasticSearch, Logging, LocalVolume 오퍼레이터 미러링
• 3scale 2.11 오퍼레이터 미러링 (OCP4.10에서는 3scale 2.11이상 버전만 지원)

2. 클러스터 상태 백업

2-1. OCP4 ETCD 백업

• 업그레이드 롤백이 공식적으로 불가능하므로, 사실상 의미 없음
• 단, 최후의 수단으로 ETCD를 이용한 업그레이드 롤백(비공식)을 고려하고자 버전 별 ETCD 백업 수행

2-2. VM 스냅샷 백업

• RHV VM으로 구성된 Master Node 백업
• 원복 시 Master Node 복구 후, Worker노드 재구성으로 복구 계획

3. 업그레이드 작업 수행

3-1. 오퍼레이터 업그레이드

• 구성된 오퍼레이터 제거(elasticsearch, cluster-logging, local-storage) 및 4.10.9 업그레이드 이후 재설치
• 신규 카탈로그 배포 및 채널 변경을 통한 오퍼레이터 업그레이드

3-2. OCP 업그레이드

• 3scale 업그레이드(2.10 → 2.11) → 4.6.56 → 4.7.45 → LocalVolume 업그레이드 → 4.8.35 → 4.9.28 → 4.10.9 → Logging 업그레이드 순서로 진행

 

업그레이드 작업 시 주의점

1. 업그레이드 채널 확인

• Update Path가 열려있는 것을 확인하고 해당 버전으로 순차 업그레이드를 진행해야 함(참고: https://access.redhat.com/labs/ocpupgradegraph/update_channel)
• 4.6 -> 4.10의 경우, Update Path가 “no update path available”임에도 불구하고 업그레이드 진행 

→ 추후 EUS 및 Stable 채널이 오픈되면, 한 번 더 업그레이드(패치) 진행 필요

2. 버전 별 지원 오퍼레이터 확인

• OCP4.6의 OLM에서 설치한 LocalVolume의 경우, 4.7.45 → 4.8.x로 업그레이드 시 업그레이드 불가.

→ 4.7.45에서 OCP4.10 OLM의 오퍼레이터로 업그레이드 후 OCP 업그레이드 진행

3. 오퍼레이터 삭제 시 깔끔하게 삭제

• 오퍼레이터 마다 삭제 방법이 다름
• 보통, 오퍼레이터의 Instance 삭제 → Operator 삭제 → 연관된 PV삭제 순
• 일부 지워지지 않는 CR 및 CRD는 ETCD의 key로 객체를 검색하여 찌꺼기 객체 확인

1--- logging operator의 경우 --- 2sh-4.4# etcdctl get --keys-only --from-key / | grep clusterlogging 3혹은 4sh-4.4# etcdctl get --keys-only --from-key / | grep openshift-logging 

4. OCP4.8 → 4.9 업그레이드 시 별도 승인 명령어 수행

1--- Deprecated API 사용 여부 확인 --- 2# oc get apirequestcount 3# oc get apirequestcounts -o jsonpath='{range .items[?(@.status.removedInRelease!="")]}{.status.removedInRelease}{"\t"}{.metadata.name}{"\n"}{end}' 4 5--- 해당 API를 사용중인 주체 확인 --- 6# oc get apirequestcounts ingresses.v1beta1.networking.k8s.io \ 7 -o jsonpath='{range .status.currentHour..byUser[*]}{..byVerb[*].verb}{","}{.username}{","}{.userAgent}{"\n"}{end}' \ 8 | sort -k 2 -t, -u | column -t -s, -NVERBS,USERNAME,USERAGENT 9 10 11--- 해당 API 호출에 대해 조치나 특이사항이 없으면 다음 버전으로 업그레이드 가능하도록 승인 --- 12# oc -n openshift-config patch cm admin-acks --patch '{"data":{"ack-4.8-kube-1.22-api-removals-in-4.9":"true"}}' --type=merge 

5. unsupportedConfigOverrides 옵션 삭제

• kubecontroller나 ingresscontroller 등 공식적으로 지원되지 않는 옵션을 임시로 적용한 경우, 업그레이드 불가

→ unsupportedConfigOverrides: Null 혹은 옵션 제거 확인 후 업그레이드 진행 (unsupportedConfigOverrides: {}일 경우도 업그레이드 불가)

6. 업그레이드 이미지 준비 시 버전 별 Repositories 구분 권장

• 설치 미러 이미지 준비 시, 위 경우처럼 ocp4/openshift4에 모두 몰아넣을 경우 업그레이드 완료 후 나머지 설치 이미지(4.10 아래 버전)를 제거할 때 매우 유의해야 함.
• podman garbage-collection 시 tags레벨의 prune을 진행해야 함. 이 경우, 다른 repository의 원치 않은 이미지가 prune될 수 있음. (-m 옵션)

1podman exec -it mirror-registry registry garbage-collect /etc/docker/registry/config.yml -m

• 실제로 Logging Operator에 tags가 복수 적용된 dummy 데이터가 존재했고, 해당 tags가 사라진 것으로 인식해 사용중인 이미지를 지워버림

→ Repositories 레벨로 prune 진행 시 해당 repository의 mapping blobs만 지우기 때문에 다음처럼 준비 권장

• ocp4/openshift4.6.56
• ocp4/openshift4.7.45
• ocp4/openshift4.8.35 …
• 나중에 prune작업 시 해당 repository를 제거하고, ‘-m’옵션을 사용하지 않고 prune을 진행

1podman exec -it mirror-registry registry garbage-collect /etc/docker/registry/config.yml

7. Private Registry의 인증서 내 SAN 정보 유무 확인

• OCP 4.6.x 버전 초기에 구성된 클러스터는 대부분 Private Registry 내에 SAN정보 대신 GODEBUG=x509를 export하여 workaround로 사용 중인 경우가 많음
• 업그레이드 시 인증 오류 발생

-> 업그레이드 이전에 SAN을 추가한 Private Registry로 변경하고 작업 진행

 

시도해보고 싶은 업그레이드 방식

EUS to EUS 업그레이드 방식을 보면, 업그레이드를 한 번에 건너 뛰는 것이 아니라 Worker의 mcp를 중지시키고 Master를 순차 업그레이드한 후, Worker mcp를 재동작시키는 방식으로 업그레이드를 진행합니다.

(참고:

Preparing to perform an EUS-to-EUS update | Updating clusters | OpenShift Container Platform 4.10 )

1--- 업그레이드 전 Worker의 MCP 동작 중지 --- 2# oc patch mcp/worker --type merge --patch '{"spec":{"paused":true}}' 3 4--- 업그레이드 완료 후 Worker의 MCP 재동작 --- 5# oc patch mcp/worker --type merge --patch '{"spec":{"paused":false}}' 

노드를 구성하는 rpm-ostree나 ETCD 등의 정보는 Worker노드에 포함되어있지 않기에 가능한 방법이죠.

그렇다면, 4.6에서 Worker mcp를 pause시키고 Master의 업그레이드를 순차적으로 4.10까지 진행한 후, Worker mcp를 다시 풀어주면 한 번에 4.10으로도 갈 수 있지 않을까요?

물론, 위 가이드는 EUS to EUS버전에 해당하는 이야기이고 여기서도 Worker의 두 단계 이상 점프하는 업그레이드에 대해서 언급은 없습니다.

다만, Master는 순차 업그레이드가 되는 것이니 문제가 없고, Worker도 rpm-ostree를 결정하는 osImageURL이 변경되는 것 외에 특별한 작업이 없다면, 이렇게 작업하는데 큰 이슈가 없을 것 같다는 생각입니다.

 

이번 업그레이드 작업을 진행하면서 가장 큰 걸림돌은 역시 업그레이드 시간이었습니다. 21대의 Baremetal Worker가 존재하는 클러스터는 한 번만 roll-out이 일어나도 3시간이 걸립니다. 이 작업을 5번이나 해야했죠. (물론, 임시 mcp 및 Role을 할당해 병렬처리하여 속도를 높였습니다.)

Worker의 Roll-out이 한 번만 일어나게 할 수 있다면, 연속적인 업그레이드 작업은 매우 짧은 시간에 완료할 수 있을 것으로 보입니다.