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

핵심 내용

• 물리 서버 기반 Kubernetes 운영에서 Cluster API와 BYOH Provider를 선택한 배경 정리
• Rolling Upgrade와 공존하는 In-place Upgrade를 Control Plane과 Worker Node에 적용한 구현·검증 과정 소개
• API v1beta2 대응, 기존 v1beta1 호환성 확보, 상태 추적을 위한 Condition·Event·Log 관찰 구조 점검

선택 이유

• 여러 클러스터의 생성·확장·업그레이드·삭제를 선언형으로 일관 관리할 필요
• 이미 준비된 Host를 그대로 활용해야 하는 Bare Metal 환경의 제약
• 여분 Host 없이 버전만 갱신하려는 운영 요구와 맞는 업그레이드 전략

장단점

• Rolling Upgrade는 검증과 복구가 쉬운 대신 고정 자원 환경에서 비용 부담 증가
• In-place Upgrade는 추가 Host 없이 가능하지만 제어 로직과 실패 대응 책임 증가
• 두 전략 공존으로 변경 유형과 인프라 특성에 맞는 선택 가능

적용해볼 점

• Provider 호환성 정비를 기능 개발보다 먼저 검토
• 역할별 안전 정책과 관찰 가능성 확보를 업그레이드 설계의 핵심으로 반영
• 운영 환경에 맞춰 Rolling과 In-place를 함께 운용하는 전략 검토