![[기술검증] 물리 서버는 그대로, Kubernetes는 새 버전으로: Cluster API In-place Upgrade](https://img1.daumcdn.net/thumb/R800x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdna%2FbQUeUX%2FdJMcaixohDj%2FAAAAAAAAAAAAAAAAAAAAABE8WRGRV2HGT0sQ_Z0ZyGdLNuwFNjastOLZ3bYohGWc%2Fimg.png%3Fcredential%3DyqXZFxpELC7KVnFOS48ylbz2pIh7yKj8%26expires%3D1785509999%26allow_ip%3D%26allow_referer%3D%26signature%3DnGfIJyO%252FDsajqPD8Volunq8ics4%253D)
데브옵스
[기술검증] 물리 서버는 그대로, Kubernetes는 새 버전으로: Cluster API In-place Upgrade
두줄요약
물리 서버 환경에서 Cluster API와 BYOH Provider로 In-place Upgrade를 구현하고 검증했습니다. Rolling 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를 함께 운용하는 전략 검토