OKD Container migration

Tech story/Container

OKD Container migration

kt cloud 테크블로그 2024. 11. 7. 14:00

[kt cloud Container개발팀 정성훈 님]

OKD Container migration

OKD 클러스터 간에 Kubernetes 리소스(네임스페이스 범위의 리소스), PV data, 내부 컨테이너 이미지를 crane이라는 오픈소스를 통해 마이그레이션하는 방법에 대한 소개글입니다.

OKD란?

Red Hat Openshift라는 상업용 소프트웨어 제품의 오픈 소스 버전이며, 다양한 Kubernetes 배포판 중의 한 종류로 보안 및 인증 기능을 제공하며 효율적인 운영을 위해 관리콘솔 및 모니터링 도구를 제공하고 있습니다.

Crane이란?

Crane은 Kubernetes 클러스터 간에 애플리케이션을 마이그레이션 하기 위한 도구입니다.
Persistent volume 및 Secret과 같은 상태를 마이그레이션하고, Kubernetes manifest를 재구성하고, pipeline을 생성하여 배포를 자동화할 수 있습니다.
자동화된 애플리케이션과 수동으로 배포된 애플리케이션을 모두 마이그레이션해야 하는 필요성을 해결하도록 지원 합니다.

용어

용어	정의
Source cluster (Remote cluster)	애플리케이션을 마이그레이션하는 클러스터. direct 이미지 마이그레이션을 위해 exposed된 보안 레지스트리 경로가 필요.
Destination cluster (Target cluster)	애플리케이션이 마이그레이션되는 클러스터.
Replication repository	Indirect 마이그레이션 중 이미지, 볼륨 및 쿠버네티스 오브젝트를 복사하거나 direct 볼륨 마이그레이션 또는 direct 이미지 마이그레이션 중 쿠버네티스 오브젝트를 복사하는 데 사용되는 오브젝트 스토리지. Replication repository는 모든 클러스터에서 액세스할 수 있어야 함.
Host cluster	마이그레이션 컨트롤러 파드와 웹 콘솔이 실행 중인 클러스터를 지칭하며 일반적으로 Destination 클러스터에 컨트롤러 구성. 별도의 컨트롤러용 Host 클러스터 구성하여 사용 가능. Host 클러스터는 direct 이미지 마이그레이션을 위해 exposed된 레지스트리 경로가 필요하지 않음.
Indirect migration	이미지, 볼륨 및 쿠버네티스 오브젝트를 Source 클러스터에서 Replication repository로 복사된 다음 Replication repository에서 Target 클러스터로 복사하는 방식.
Direct volume migration	Persistent 볼륨을 Source 클러스터에서 Target 클러스터로 direct 복사 방식.
Direct image migration	이미지를 Source 클러스터에서 Target 클러스터로 direct 복사 방식.
Stage migration	애플리케이션을 중지하지 않고 데이터가 target 클러스터로 복사. Stage 마이그레이션을 여러 번 실행하면 Cutover 마이그레이션 시간이 단축.
Cutover migration	애플리케이션이 Source 클러스터에서 중지되고 해당 리소스가 Target 클러스터로 마이그레이션. 선택사항으로 마이그레이션 중 Source 클러스터의 애플리케이션 중지 체크박스를 선택 취소할 수 있음.
Rollback migration	완료된 마이그레이션을 롤백.

마이그레이션 범위

마이그레이션 plan에 지정된 네임스페이스.
네임스페이스 범위 리소스
- 네임스페이스를 마이그레이션할 때 서비스나 파드와 같이 해당 네임스페이스와 연관된 모든 오브젝트와 리소스를 마이그레이션.
- 네임스페이스에 존재하지만 클러스터 레벨에는 없는 리소스가 클러스터 레벨에 존재하는 리소스에 종속되어 있는 경우, 두 리소스를 모두 마이그레이션.
  - 네임스페이스의 PVC에 연결된 PV(클러스터 레벨 자원)를 마이그레이션. (단, storageclass를 통해 생성된 PV/PVC)
  - 네임스페이스의 SA에 연결된 SCC(클러스터 레벨 자원)를 자동으로 찾아 SCC도 같이 마이그레이션

* 주의 *
클러스터 레벨의 리소스는 리소스에 따라 수동으로 마이그레이션해야 할 수도 있음.

ex)
node label
수동 생성한 PV

사용자 지정 리소스(Custom Resource) 및 사용자 지정 리소스 정의(Custom Resource Definitions)
- 네임스페이스 수준에서 CR 및 CRD를 자동으로 마이그레이션.

Crane 구조

workflow

리소스 정보 (Custom Resources)

MigCluster(Target 클러스터 Config): 클러스터 정의.
MigStorage(Target 클러스터 Config): 스토리지 정의.
MigPlan(Target 클러스터 Config): 마이그레이션 계획.
BackupStorageLocation(Target 클러스터 Config): Velero 백업 오브젝트의 위치.
VolumeSnapshotLocation(Target 클러스터 Config): Velero 볼륨 스냅샷의 위치.
MigMigration(MTC 클러스터 action): 데이터를 스테이징하거나 마이그레이션할 때마다 생성되는 마이그레이션 수행 리소스. MigMigration CR은 각 CR들과 연결.
Backup(Source 클러스터 action): 마이그레이션 계획을 실행할 때 CR(MigMigration, Velero)은 Source 클러스터에 두 개의 백업 CR을 생성.
- 쿠버네티스 오브젝트에 대한 백업 CR.
- PV 데이터용 백업 CR.
Restore(Target 클러스터 action): 마이그레이션 계획을 실행할 때 CR(MigMigration, Velero)은 Target 클러스터에 두 개의 복원 CR을 생성.
- PV 데이터에 대한 CR 복원. (백업 CR)
- 쿠버네티스 오브젝트에 대한 CR 복원. (백업 CR 사용)

Crane 구성

OKD 4.7 구성

Migration Tool 구성 방법
quay.io 통신을 위한 방화벽 설정

진행 환경

KTCloud K2P Enterprise
Cluster version : OKD 4.7
OS : Fedora CoreOS 33
Crane Tool : 1.7

환경 구성 방법

openshift-marketplace 에서 필요 catalog 활성화

community-operators
migration-operator

1. Operator Hub 설정

oc edit operatorhub -n openshift-marketplace

apiVersion: config.openshift.io/v1
kind: OperatorHub
metadata:
  annotations:
    include.release.openshift.io/ibm-cloud-managed: "true"
    include.release.openshift.io/self-managed-high-availability: "true"
    include.release.openshift.io/single-node-developer: "true"
    release.openshift.io/create-only: "true"
  name: cluster
  ownerReferences:
  - apiVersion: config.openshift.io/v1
    kind: ClusterVersion
    name: version
spec:
  disableAllDefaultSources: true
  sources:           ## 하위 내용 추가
  - disabled: false
    name: community-operators
  - disabled: false
    name: migration-operators

2. Migration-operator catalog 추가

## manifest 생성
vi catalogsource.yml

apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: migration-operator
  namespace: openshift-marketplace
spec:
  sourceType: grpc
  image: quay.io/konveyor/mig-operator-index:latest

## 적용
oc apply -f catalogsource.yml

3. Catalog pod 생성 확인

oc get pod -n openshift-marketplace | egrep "community|migration"

OKD Console에서 설치 진행

1. console 접속 정보 확인

oc whoami --show-console
# OR
oc get route -n openshift-console | grep console

2. console 접속 → Operators → OperatorHub → crane 조회

3. Install 선택

4. 설치 옵션 선택 후, install 진행 (그림과 동일하게 선택)

5. 설치 완료 확인

6. Operators → Installed Operators 이동하여 Crane Operator 선택

7. MigrationController 클릭

8. Create 클릭

9. 생성 확인

Cluster-admin 권한 설정

migration-controller ServiceAccount에 cluster-admin 권한 부여
권한이 없을 경우, cluster의 namespaces들에 대해 제어 권한이 없어 마이그레이션 불가.

1. SA 확인

oc get sa -n openshift-migration | grep migration-controller

2. Cluster Role Binding 추가

vi clusterrolebinding-migration.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: migration-cluster-admin
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: migration-controller
  namespace: openshift-migration

3. 적용

oc apply -f clusterrolebinding-migration.yaml

4. 확인

oc get clusterrolebindings | grep migration

Crane Console 접속

1.console 접속 주소 확인 (접속 정보는 okd console 접속 정보와 동일)

oc get route -n openshift-migration | grep ui

2. 접속 시 화면

OKD 4.10 구성

Migration Tool 구성 방법
quay.io 통신을 위한 방화벽 설정.

진행 환경

KTCloud K2P Enterprise
Cluster version : OKD 4.10
OS : Fedora CoreOS 35
Crane Tool : 1.7

환경 구성 방법

openshift-marketplace 에서 필요 catalog 활성화

community-operators
migration-operator

1. Operator Hub 설정

oc edit operatorhub -n openshift-marketplace

2. Migration-operator catalog 추가

## manifest 생성
vi catalogsource.yml

## 적용
oc apply -f catalogsource.yml

3. Catalog pod 생성 확인

oc get pod -n openshift-marketplace | egrep "community|migration"

OKD Console에서 설치 진행

1. console 접속 정보 확인

oc whoami --show-console
# OR
oc get route -n openshift-console | grep console

2. console 접속 → Operators → OperatorHub → crane 조회

3. Install 선택

4. 설치 옵션 선택 후, install 진행 (그림과 동일하게 선택)

5. 설치 완료 확인

6. Operators → Installed Operators 이동하여 Crane Operator 선택

7. MigrationController 클릭

8. Create 클릭

9. 생성 확인

OKD Console에서 설치 진행

1. console 접속 정보 확인

oc whoami --show-console
# OR
oc get route -n openshift-console | grep console

2. console 접속 → Operators → OperatorHub → crane 조회

3. Install 선택

4.설치 옵션 선택 후, install 진행 (그림과 동일하게 선택)

5.설치 완료 확인

6. Operators → Installed Operators 이동하여 Crane Operator 선택

7. MigrationController 클릭

8. Create 클릭

9. 생성 확인

Cluster-admin 권한 설정

migration-controller ServiceAccount에 cluster-admin 권한 부여
권한이 없을 경우, cluster의 namespaces들에 대해 제어 권한이 없어 마이그레이션 불가.

1.SA 확인

oc get sa -n openshift-migration | grep migration-controller

2.Cluster Role Binding 추가

vi clusterrolebinding-migration.yaml

3.적용

oc apply -f clusterrolebinding-migration.yaml

4.확인

oc get clusterrolebindings | grep migration

CoreDNS 설정

source 클러스터의 master API와 통신 가능하도록 coredns 설정

1.DNS Operator 관리 상태 변경

oc patch dns.operator.openshift.io default --type merge --patch '{"spec":{"managementState":"Unmanaged"}}'

2. coredns configmap 변경

oc edit cm -n openshift-dns dns-default

data:
  Corefile: |
    .:5353 {
      bufsize 512
      errors
...생략...
      cache 900 {
        denial 9984 30
      }
      reload
      loadbalance       ##추가
      hosts {
        xxx.xxx.xxx.xxx api-int.xxx-xxx-xxx-xxx.nip.io     ## master api IP and URL
        fallthrough
      }
    }

Crane Console 접속

1.console 접속 주소 확인 (접속 정보는 okd console 접속 정보와 동일)

oc get route -n openshift-migration | grep ui

2.접속 시 화면

OKD 마이그레이션

crane을 활용하여 OKD Cluster 마이그레이션 방법.

사전 준비

Source 클러스터(OKD 4.7)와 Destination 클러스터(OKD 4.10) 필요.

용어	설명	비고
Source 클러스터	애플리케이션을 마이그레이션하는 클러스터
Destination 클러스터	애플리케이션이 마이그레이션되는 클러스터	target 클러스터

source 클러스터의 control plan의 api 주소로 접근 가능하도록 inbound 방화벽 정책 허용 필요.
마이그레이션 애플리케이션은 Opensearch로 진행. (K2P 옵션상품)

사용 방법

마이그레이션 컨트롤러 설정

Destination 클러스터가 마이그레이션 컨트롤러 역할.
마이그레이션 컨트롤러는 마이그레이션에 필요한 설정을 함.

1. Clusters 설정

crane UI console 주소 확인 및 접속 (접속 정보는 OKD console 접속 정보와 동일)

oc get route -n openshift-migration | grep ui

마이그레이션 하려는 source 클러스터 추가

Clusters → Add cluster 클릭

source 클러스터 정보 기입

Clouster nate : 이름 지정
URL : Source 클러스터의 Master API 서버 정보 기입.

## Master API 서버 정보 확인
oc cluster-info

Service account token : Destination 클러스터가 Source 클러스터와 통신을 위한 서비스 계정 토큰 등록

## token 정보 확인
oc sa get-token -n openshift-migration migration-controller

Exposed route host to image registry : 클러스터 내부 registry 외부 접근을 위한 도메인 정보 기입

## 클러스터 내부 registry 외부 접속 정보 확인
oc get route -n openshift-image-registry

Add cluster 확인 후 연결 확인

2. Replication repositories 설정

Source 클러스터에서 Target 클러스터로 데이터 복사를 위한 repositories 설정

Replication repositories → Add replication repository 클릭

Storage proviser type → S3 선택

추가 정보 기입

- Replication repository name : 이름 지정.
- S3 bucket name : 사용할 bucket 이름 기입.
- S3 endpoint : Object storage endpoint 정보 기입
- S3 provider access key : S3 access key 정보 기입
- S3 provider secret access key : S3 secret access key 정보 기입
Add repository 클릭 → 생성 확인

3. Migration plans 설정

Source 클러스터에서 Target 클러스터로 마이그레이션을 위한 plan 설정.

Migration plans → Add migrations plan

General 정보 기입

- Plan name : 설정할 plan name 기입
- Migration type : data 마이그레이션 방법 선택
  - 전체 마이그레이션 - 네임스페이스, 영구볼륨(PV) 및 Kubernetes 리소스를 한 클러스터에서 다른 클러스터로 마이그레이션 함.
  - 상태 망이그레이션 - 동일한 클러스터 또는 다른 클러스터의 네임스페이스 간에만 PV를 마이그레이션 함.
  - 저장소 클래스 변환 - 동일한 클러스터 및 네임스페이스 내에서 PV를 다른 저장소 클래스로 변환.
- Source cluster : 마이그레이션 하는 대상 클러스터 지정.
- Target cluster : 마이그레이션 되는 대상 클러스터 지정.
- Repository : [Replication repositories 설정] 에서 구성한 Object Srorage 지정.
Namespaces 선택

Persistent volumes 선택

PV migration type : 영구 볼륨에 대한 마이그레이션 유형 설정
- Move : source 클러스터에서 원격 볼륨(예: NFS)을 언마운트하고, 원격 볼륨을 target 클러스터에 PV 리소스를 생성한 다음, target 클러스터에 원격 볼륨을 마운트. target 클러스터에서 실행되는 애플리케이션은 소스 클러스터가 사용하던 것과 동일한 원격 볼륨을 사용.
- Filesystem copy : source 클러스터의 PV에 있는 데이터를 복제 저장소로 복사한 다음, target 클러스터에서 비슷한 특성을 가진 새로 생성된 PV에 데이터를 복원.

Copy options

Persistent volumes 선택

- Target storage class : Filesystem copy를 선택한 경우, target 저장소 클래스를 변경 가능.
- Verify copy : Filesystem copy를 선택한 경우, 각 source 파일에 대한 체크섬을 생성하고 복원 후 체크섬을 확인 하도록 선택 가능. 마이스레이션 성능 크게 저하.
Migration options

- Images - Direct image migration : Direct image 마이그레이션은 복제 저장소를 사용하지 않고, image를 source 클러스터에서 target 클러스터로 직접 복사.
  복제 저장소를 사용하는 image 마이그레이션보다 훨씬 빠름.
  source/target 클러스터 모두의 이미지 레지스트리에 대한 외부 노출된 route 경로를 지정해야 함.
- Persistent volumes - Direct PV migration : Direct PV 마이그레이션을 사용하면 복제 저장소를 거치지 않고도 파일 시스템 복사 가능.
  기본(복제 저장소) PV 마이그레이션보다 훨씬 빠르지만 Filesystem copy 유형에만 사용할 수 있으며, Move나 Snapshot copy에는 사용할 수 없음.
  source 클러스터가 포트 443을 통해 target 클러스터와 통신할 수 있어야 함.
Hooks

- Hook은 마이그레이션 프로세스의 다양한 단계에서 실행할 수 있는 명령. 컨테이너 이미지 또는 Ansible 플레이북에 정의되며 source 또는 target 클러스터에서 실행할 수 있음.
- 해당 가이드에서는 다루지 않음.
Next 클릭 시, 경고와 함께 plan 설정 완료

- node label과 같이 node 영역에 대한 설정은 수동으로 추가 필요.
생성된 plan 정보

- Logs : Migration controller에 대한 Log 조회.
- Edit : 작성한 Migration plan 수정.
- Delete : 설정한 Migration plan 삭제.
- Stage : Application을 중지하지 않고 Source 클러스터에서 Target 클러스터로 데이터 복사.
- Cutover : Source 클러스터의 트랜잭션을 중지하고 Resouce를 Target 클러스터로 이동. (마이그레이션 중 Source 클러스터의 트랜잭션 중지 확인란의 선택을 취소할 수 있음.)
- Rollback : Migration된 Resouces와 Volume이 원래 상태 및 위치 복구.
  - Source 클러스터 : Deployments, DeploymentConfigs, StatefulSets, StatefulSets, ReplicaSets, DaemonSets, CronJobs 및 Jobs 에서 원래 Replicas 복원.
  - Target 클러스터 : Migration 된 Resource 를 삭제.
  - Source 및 Target 클러스터 : Migration 중에 생성된 Velero 백업 및 복원 삭제 PV, PVC, Pod, ImageStream 및 네임스페이스에서 Migration 주석 및 레이블 제거

Migration 진행

1. 진행 전 필수 요건 확인

Ready 상태의 Source 클러스터
Ready 상태의 Target 클러스터
Replication repository
유효한 Migration plan 설정

Node 영역에 대한 설정은 마이그레이션 불가하기 때문에 tartget 클러스터에도 동일하게 설정 필요함.

Node Labels.
SCC manifest 직접 edit하여 추가한 정보.
StorageClass를 사용하지 않고 수동 생성한 PV.
기타 namespace object에 종속되지 않는 설정들에 대한 부분은 마이그레이션 전 동일하게 설정 필요

2. 진행

Migration plan 설정
- Mig 대상 서비스 - cert-manager, opensearch, opentelemetry-operator
- PV migration type - filesystem copy
- Persistent volume - Direct PV migration
- Migration Policy - Cutover (Source 클러스터 서비스 중지 비활성화로 진행)
Cutover Policy 실행 시, 마이그레이션에 대한 대략적인 정보 표시