Kubernetes 컨트롤 플레인 업그레이드, 왜 자동화가 어려운가
Kubernetes 클러스터를 직접 운영하는 팀이라면 컨트롤 플레인 업그레이드가 얼마나 긴장되는 작업인지 잘 알 것이다. 노드마다 SSH로 접속해 업그레이드 명령을 순서대로 실행하고, 그 사이에 etcd quorum이 깨지지 않는지 실시간으로 모니터링해야 한다. 실수 한 번으로 클러스터 전체가 불능 상태에 빠질 수 있기 때문에, 많은 팀이 이 작업을 야간에 사람이 붙어서 진행한다.
문제는 이 과정이 반복될수록 "사람이 기억하는 절차"에 의존하게 된다는 점이다. CVE 패치 주기는 점점 빨라지고 있는데, 업그레이드할 때마다 문서를 다시 찾아보거나 이전 담당자에게 물어봐야 하는 상황은 명백한 운영 부채다.
Kairos와 불변 OS 기반 파이프라인 설계
이 사례에서 핵심 구성 요소는 Kairos라는 불변(Immutable) Linux 배포판이다. Kairos는 A/B 파티션 방식으로 OS 업그레이드를 수행한다. 현재 실행 중인 파티션을 건드리지 않고 비활성 파티션에 새 이미지를 기록한 뒤 재부팅한다. 롤백은 단순히 이전 파티션으로 다시 부팅하는 것으로 끝난다. cosign으로 서명된 이미지를 사용하기 때문에 공급망 보안도 함께 챙길 수 있다.
클러스터 구성은 다음과 같다.
- 3개의 컨트롤 플레인 노드, K3s HA 구성
- Cilium CNI 사용
- 전체 인프라는 OpenTofu로 코드화하여 프로비저닝
여기서 실무적으로 중요한 교훈이 하나 있다. 초기 파이프라인에 concurrency: 0 설정이 있었는데, 작성자는 이를 "한 번에 노드 한 개"로 오해했다. 실제 동작은 모든 노드를 동시에 재부팅하는 것이었다. 홈랩 환경이라 etcd quorum이 우연히 살아남았지만, 프로덕션이었다면 클러스터 전체가 다운됐을 상황이다.
# 잘못된 설정 예시 - 모든 노드 동시 업그레이드
spec:
concurrency: 0
# 올바른 설정 - 한 번에 한 노드씩
spec:
concurrency: 1
이처럼 자동화 파이프라인에서 기본값의 의미를 정확히 이해하지 못한 설정 하나가 치명적인 장애로 이어질 수 있다.
자가 치유 파이프라인의 실무적 의미
이 파이프라인이 완성된 후 컨트롤 플레인 업그레이드는 11분, 무인(zero human) 으로 완료된다. 단순히 속도의 문제가 아니다. 핵심은 다음 세 가지다.
첫째, 절차가 코드로 존재한다. 담당자가 바뀌거나 시간이 지나도 파이프라인 자체가 정답이다. 사람의 기억에 의존하지 않는다.
둘째, 롤백이 설계에 내장되어 있다. Kairos의 A/B 파티션 덕분에 업그레이드 실패 시 이전 상태로 되돌아가는 경로가 명확하다. 자동화된 복구 경로 없이 자동화된 업그레이드만 있는 것은 위험하다.
셋째, CNCF 프로젝트 조합으로 벤더 종속을 피했다. OpenTofu, K3s, Cilium, Kairos 모두 오픈소스 생태계 안에 있다. 특정 클라우드 벤더의 관리형 Kubernetes에 묶이지 않고 이 수준의 자동화를 달성할 수 있다는 점은, 온프레미스나 멀티클라우드 환경을 운영하는 팀에게 특히 참고할 만하다.
정리
concurrency같은 업그레이드 설정의 기본값은 반드시 공식 문서로 검증해야 한다. 잘못된 가정 하나가 etcd quorum 붕괴로 이어질 수 있다.- 불변 OS + A/B 파티션 방식은 업그레이드 자동화에서 롤백 안전망을 구조적으로 보장하는 강력한 패턴이다.
- 업그레이드 절차를 코드와 파이프라인으로 완전히 표현하는 것이 운영 성숙도의 핵심이며, 속도보다 재현 가능성과 복구 가능성이 우선이다.