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

물리 서버(베어메탈) 고정 환경에서 Kubernetes 버전 업그레이드 시 추가 호스트 없이 기존 노드에서 In-place Upgrade를 구현한 KT Cloud의 기술 검증 사례다. Cluster API + BYOH(Bring Your Own Host) Provider를 채택해 선언형 멀티클러스터 라이프사이클 관리를 구현하고, v1beta1→v1beta2 API 마이그레이션과 컨버전 웹훅 구현을 함께 진행했다. 롤링 업그레이드는 스페어 호스트가 필요하다는 제약을 해결하면서 Control Plane은 etcd 상태 검증 포함 별도 순서 보장 로직을 적용했다.

핵심 포인트

물리 서버 고정 환경에서 롤링 업그레이드의 스페어 호스트 요구 문제를 In-place Upgrade로 해결
BYOH Provider: 기 프로비저닝된 리눅스 호스트에 에이전트 설치, PXE·Ironic 불필요
v1beta1→v1beta2 CRD 스키마·컨디션·컨트롤러·웹훅 전체 마이그레이션, 기존 리소스 컨버전 웹훅으로 하위 호환
Control Plane In-place Upgrade: API 서버 가용성 모니터링 + etcd 상태 검증 + 노드별 순차 처리
Conditions·Events·Logs 기반 업그레이드 단계별 상태 추적 및 실패 격리

상세 정리

도입 배경: kubeadm·Kubespray는 설치에 강하지만 멀티클러스터 라이프사이클 선언형 관리 불가
Cluster API 선택: CRD 기반 선언형 클러스터 상태 관리, GitOps 통합, YAML로 목표 상태 기술
BYOH vs Metal3: 기 프로비저닝된 서버 활용 시 BYOH 선택, Metal3는 PXE·전원 제어 인프라 필요
롤링 업그레이드 문제: 새 노드 생성 후 구 노드 삭제 방식, 물리 서버 고정 환경에서 스페어 호스트 없음
In-place Upgrade: 동일 Host/Machine/Node 정체성 유지한 채 Kubernetes 컴포넌트 직접 교체
v1beta2 마이그레이션: CRD 스키마·타입 구조체·컨디션 표현·컨트롤러 조정 로직·웹훅 변환기 전체 수정
컨버전 웹훅: v1beta1 리소스 대량 재생성 없이 v1beta2와 공존, 전환 전 CRD 백업 필수
Worker Node 흐름: BYOH 에이전트 통해 kubeadm 순차 실행, 컨트롤러 오케스트레이션
Control Plane 흐름: API 서버 가용성 상시 모니터링, 각 단계 전 etcd 클러스터 헬스 확인, 노드별 순차 처리(병렬화 금지)
실패 정책: 오류 시 중단·재시도·수동 개입 표시 중 선택, 자동 롤백 미지원
검증 항목: 롤링·In-place 비교, 실패 시나리오 주입·복구, 멀티노드, Control Plane·Worker 노드 순서 보장
Cluster API v1.12(2026-01-27): KubeadmControlPlane·MachineDeployments에 In-place update 훅 공식 도입