OVN-Kubernetes CNI에서 Calico로 마이그레이션
처음부터 새 OpenShift 클러스터를 만들 수 없는 상황이라면, 이 튜토리얼처럼 컨테이너 네트워크 인터페이스(CNI)를 OVN-Kubernetes에서 Calico로 라이브 마이그레이션할 수 있어요. 이 마이그레이션을 통해 모던 클라우드 네이티브 환경에 꼭 필요한 고급 네트워킹과 보안 기능을 사용하게 돼요. 클러스터를 계속 운영하면서 네트워킹 공급자만 바꾸는 절차이니, 단계 순서를 지켜가며 천천히 따라오면 돼요.
출처: 문서
본문
왜 Calico를 사용해야 할까요
Calico는 OVN-Kubernetes에 비해, 특히 고급 네트워킹과 보안 기능 면에서 상당한 이점을 제공해요.
- eBPF 네트워킹: Calico의 eBPF(Extended Berkeley Packet Filter) 지원은 커널 안에서 매우 효율적이고 프로그래밍 가능한 네트워크 데이터 경로 조작을 가능하게 해요. 처리가 커널 안에서 직접 일어나 컨텍스트 스위칭과 오버헤드가 줄어들기 때문에, 네트워크 정책 적용, 로드 밸런싱, 서비스 메시 통합 같은 영역에서 성능이 크게 좋아져요.
- 가상 머신 지원: Calico는 KubeVirt 같은 기술로 관리되는 가상 머신 워크로드와 매끄럽게 통합돼요. OpenShift 클러스터 안의 컨테이너와 VM 모두에 일관된 네트워킹과 보안 정책을 적용할 수 있고, 이 통합 접근은 하이브리드 환경의 네트워크 관리와 정책 적용을 단순하게 만들어 줘요.
- 고급 네트워크 정책: Calico의 네트워크 정책 엔진은 매우 유연하고 확장 가능해서, 파드 간, 파드-외부 간, 호스트-파드 간 통신을 세밀하게 제어할 수 있어요.
- 확장성과 성능: 크고 높은 처리량을 다루는 환경에서는 Calico의 아키텍처, 특히 eBPF나 자체 데이터 플레인을 활용할 때 더 나은 확장성과 성능을 보여줘요.
- VMware 마이그레이션 준비 완료: Calico는 tier-0 라우팅, VM 테넌트 격리, 마이크로세그멘테이션 같은 기능을 제공해 VMware에서 Kubernetes로 넘어가는 여정을 도와줘요.
- 네트워크 옵저버빌리티: 클러스터 네트워크 트래픽을 이해하는 것은 보안에 필수적이에요. Calico Whisker는 네트워크 로그를 살펴보고 다룰 수 있는 간단한 GUI를 제공해서, 이상 징후를 찾아내고 환경을 진짜로 지켜주는 정교한 보안 정책을 만들기가 한결 쉬워져요.
사전 요구 사항
SECONDARY: 자신의 환경으로 본격 들어가기 전에 crc를 활용하는 것도 고려해 보세요. 실험용 개발 OpenShift 환경을 편하게 띄울 수 있어요.
Red Hat CodeReady Containers(CRC)는 개발과 테스트를 위해 노트북이나 데스크톱에서 최소 구성의 OpenShift 4 클러스터를 제공해요. CRC는 VM 안의 플랫폼 형태로 제공돼요.
- OpenShift 클러스터가 건강한 상태인지, 모든 노드와 컨트롤 플레인 구성 요소가 정상 동작하는지 확인해요. (OpenShift 4.16~4.18에서 테스트됐어요.)
- etcd 데이터와 중요 클러스터 구성에 대한 튼튼한 백업 전략을 마련해요.
- Calico 에이전트와 새 CNI로 인한 리소스 사용 증가를 감당할 수 있도록 노드에 충분한 리소스(CPU, 메모리)가 있는지 확인해요.
이 튜토리얼은 매끄러운 전환을 목표로 하지만, 예상 못한 문제가 생길 수도 있어요. 50노드를 넘는 환경이라면 slack 그룹으로 문의하기를 권해요.
SECONDARY: 마이그레이션 과정에서 기반이 되는 네트워크 패브릭이 교체되면서 네트워크 중단이 발생한다는 점을 알아 두세요. 다운타임을 계획하고 이해관계자에게 미리 알려야 해요.
Machine Config Pool 업데이트 중지
OpenShift의 Machine Config Operator(MCO)는 노드의 운영체제 구성을 관리해요. CNI 마이그레이션 중에는 네트워크 구성 변경이 크게 일어나요. 이 중요한 시기에 MCO가 충돌 가능성이 있는 구성 업데이트를 적용하지 않도록 Machine Config Pool(MCP)을 일시 정지해요.
oc patch MachineConfigPool master --type='merge' --patch '{ "spec": { "paused": true } }'
oc patch MachineConfigPool worker --type='merge' --patch '{ "spec":{ "paused": true } }'
이렇게 하면 CNI 마이그레이션이 진행되는 동안 master와 worker 노드에 의도하지 않은 구성 변경이 배포되지 않아요. 네트워크 구성 업데이트와 OS 구성 업데이트가 동시에 일어나서 생길 수 있는 불안정이나 충돌을 미리 막는 거예요.
클러스터 마이그레이션 준비
먼저 현재 진행 중인 다른 마이그레이션이 있는지 확인해요.
oc get Network.operator.openshift.io cluster -o jsonpath='{.spec.migration}'
진행 중인 마이그레이션이 없다면 마이그레이션 상태를 초기화해요.
oc patch Network.operator.openshift.io cluster --type='merge' --patch '{ "spec": { "migration": null } }'
다음으로, Calico로의 마이그레이션을 활성화해요.
oc patch Network.operator.openshift.io cluster --type='merge' --patch '{ "spec": { "migration": { "networkType": "Calico" } } }'
이 핵심 명령은 OpenShift 네트워크 오퍼레이터에게 Calico로의 CNI 마이그레이션을 시작하라고 신호를 보내는 거예요. spec.migration.networkType을 Calico로 설정하면, 즉시 적용할 수 없는 네트워크 변경을 위해 클러스터 네트워크 마이그레이션이 활성화되고 구성돼요.
Calico 설치
OpenShift용 Calico 매니페스트를 내려받아요.
mkdir calico
wget -qO- https://github.com/projectcalico/calico/releases/download/v3.33.0/ocp.tgz | tar xvz --strip-components=1 -C calico
cd calico
oc create -f를 사용해 이름에 -cr-이 들어간 것들을 제외한 모든 매니페스트를 설치해요. Linux라면 다음 명령을 시도해 보세요.
for file in $(ls *.yaml | grep -Ev 'cr-(.*?)\.yaml'); do
echo "Applying $file"
oc create -f "$file"
done
Tigera-operator가 성공적으로 롤아웃될 때까지 기다려요.
oc rollout status -w --timeout=2m -n tigera-operator deployment/tigera-operator
SECONDARY: eBPF 강화: Calico의 eBPF 데이터 플레인으로 성능과 기능을 끌어올릴 계획이라면
deployKubeProxy를true로 설정할 필요가 없어요. Calico eBPF 데이터 플레인이 kube-proxy 기능을 완전히 대체하기 때문이에요.
kube-proxy를 활성화하거나 eBPF를 사용해요.
oc patch networks.operator.openshift.io cluster --type merge -p '{"spec":{"deployKubeProxy": true}}'
Tigera Operator에게 Calico를 설치하라고 알려주는 installation 매니페스트를 만들어요.
oc create -f *cr*.yaml
Calico 구성 요소가 준비될 때까지 기다려요.
oc wait --for=condition=Available tigerastatus --all
spec.networkType을 Calico로 설정하면 OpenShift 네트워크 관리 시스템에 Calico가 이제 활성 CNI라고 알려주는 거예요. 이렇게 하면 노드 네트워킹을 Calico가 사용하도록 구성하는 등 마이그레이션의 마지막 단계가 촉발돼요.
oc patch Network.config.openshift.io cluster --type='merge' --patch '{ "spec": { "networkType": "Calico" } }'
Multus 재시작
OpenShift Container Platform은 Multus CNI 플러그인을 사용해 CNI 플러그인을 체이닝할 수 있게 해요. 클러스터 설치 시 기본 파드 네트워크를 구성하는데, Multus는 메타 CNI로 동작해 파드가 여러 네트워크 인터페이스를 가질 수 있게 해줘요.
다음 명령으로 Multus를 재시작해요.
oc -n openshift-multus rollout restart daemonset/multus
Multus가 돌아오기를 기다려요.
oc -n openshift-multus -w --timeout=2m rollout status daemonset/multus
이 시점에서 마이그레이션을 마무리하면, 네트워크 오퍼레이터가 모든 변경을 적용해요.
oc patch Network.operator.openshift.io cluster --type='merge' --patch '{ "spec": { "migration": null } }'
정리
마이그레이션이 끝나면 OVN-Kubernetes CNI를 완전히 제거할 수 있어요. 아래 명령들은 클러스터에서 남아 있는 OVN-Kubernetes 부분들을 걷어내요. 이렇게 하면 깔끔하게 전환되고, 새 Calico CNI와의 잠재적 충돌도 막을 수 있어요.
OVN-Kubernetes 전용 구성을 제거해요.
oc patch Network.operator.openshift.io cluster --type='merge' --patch '{ "spec": { "defaultNetwork": { "openshiftSDNConfig":null } } }'
SDN-Kubernetes 전용 구성을 제거해요.
oc patch Network.operator.openshift.io cluster --type='merge' --patch '{ "spec": { "defaultNetwork": { "ovnKubernetesConfig":null } } }'
네임스페이스를 삭제해서 OpenShift OVN을 제거해요.
oc delete namespace openshift-ovn-kubernetes
이 단계에서는 서비스 중단이 어느 정도 있을 것으로 예상해야 해요. 그 기간과 영향은 OpenShift 환경의 규모와 복잡도에 따라 달라져요. 기반이 되는 OVN 네트워크 인터페이스가 제거되고 워크로드가 새로 만들어진 Calico 인터페이스로 넘어가는 동안, 일부 노드가 잠시 응답하지 않는 걸 볼 수도 있어요. 이 전환은 모든 파드와 서비스의 네트워크 연결을 다시 세우는 과정이라 시간이 걸릴 수 있어요.
노드를 원래 상태로 되돌리기
MachineConfigPool이 일시 정지되어 있어서 OpenShift 4에서 Machine Config Operator가 업데이트를 밀어 보낼 수 없었죠.
Machine Config Pool 업데이트를 다시 활성화해요.
oc patch MachineConfigPool master --type='merge' --patch '{ "spec": { "paused": false } }'
oc patch MachineConfigPool worker --type='merge' --patch '{ "spec":{ "paused": false } }'
다음 단계
추천 - 네트워킹
- 기본 BGP 네트워킹(캡슐화 없는 풀 메시 노드 간 피어링)을 사용 중이라면, BGP 피어링 구성 문서로 이동해 파드 간 트래픽이 흐르도록 만들어요.
- 네트워킹 옵션이 확실하지 않거나 캡슐화(오버레이 네트워킹)를 도입하고 싶다면 최적 네트워킹 옵션 결정을 참고해요.
추천 - 보안
- 네트워크 옵저빌리티 활성화
- Calico 구성 요소 간 통신 보안
- 호스트에 Calico를 설치해 호스트 보안 확보
- Calico 네트워크 정책으로 파드 보안 확보
- Calico를 Istio 서비스 메시와 함께 사용한다면 여기서 시작해요: 애플리케이션 계층 정책 활성화
더 알아보기 (Learn more)
이 마이그레이션의 핵심은 Machine Config Pool을 먼저 일시 정지해 OS 구성 변경과 네트워크 변경이 엇갈리지 않게 하는 거예요. migration 필드로 네트워크 오퍼레이터에게 전환을 알리고, 마지막에 Network.config의 networkType을 Calico로 바꿔 마무리한다는 흐름을 기억해 두면 좋아요. 완료 후에는 반드시 MCP를 원래대로 되돌려야 해요.