[기술검증] 물리 서버는 그대로, Kubernetes는 새 버전으로: Cluster API In-place Upgrade

물리 서버 기반 Kubernetes 클러스터를 여러 개 장기 운영하려면 단순 설치 자동화를 넘어 생성·확장·업그레이드·삭제를 일관되게 관리하는 체계가 필요하다. kt cloud Cloud플랫폼팀은 이 문제를 Cluster API와 BYOH(Bring Your Own Host) Provider 조합으로 해결했다. BYOH는 이미 OS와 네트워크가 준비된 물리 서버에 Agent만 설치해 Cluster API 관리 대상으로 편입하는 방식으로, BMC·PXE·Ironic 계층 없이 기존 자산을 활용할 수 있다.

운영 과정에서 두 가지 과제가 드러났다. 첫째, BYOH Provider를 v1beta1에서 v1beta2 API로 전환할 때 CRD 스키마·Controller 로직·Webhook 변환 전반을 정비해야 했고, 기존 클러스터 중단 없이 하위 호환성을 유지해야 했다. 둘째, Cluster API 기본 방식인 Rolling Upgrade는 여분의 Host를 필요로 해 서버 수가 고정된 물리 환경에서 비용이 컸다.

이를 해결하기 위해 Rolling Upgrade를 제거하지 않고 In-place Upgrade를 선택지로 추가했다. In-place 방식은 기존 Host·Machine·Node 이름을 유지한 채 Kubernetes 구성요소만 현장에서 업그레이드한다. 버전 변경이 In-place 적용 범위에 해당하면 Controller와 BYOH Agent가 역할별 업그레이드 흐름을 실행하며, Condition·Event·Log로 진행 상태를 실시간 반영한다.

• Worker Node: 노드 구성요소 갱신 흐름 적용
• Control Plane: API Server·etcd 상태와 클러스터 정족수를 확인한 뒤 단계적으로 업그레이드
• 실패 시 중단·재시도·수동 개입 정책을 명시적으로 정의

검증 결과 추가 Host 없이 Control Plane과 Worker Node 모두 In-place 업그레이드가 가능함을 확인했으며, 이 구조는 GitOps 흐름과도 자연스럽게 연계된다.