홍승현(@user49) Bro님이 이번 “Kubestronaut와 함께하는 커뮤니티 데이” 행사에 사전질문으로 주신 내용을 공유합니다.
- K8s 버전 업그레이드 전략(주기, know-how, 핵심 고려사항 등)이 궁금합니다.
전문가 Bro님들의 Insight 공유 부탁드립니다.
저도 궁금합니다
제 생각에는 업그레이드 전략은 케이스마다 다르지만,
일반적으로는 제어 플레인 → 노드 → 애드온 순서를 따르며,
최소 1버전 하위 호환성에서 문제가 없는지 반드시 확인해야 합니다~
스토리지가 클러스터 밖에 완전히 분리돼 있다면 비교적 수월하게
노드 드레인 → 업그레이드 → 언코드 순으로 Canary 롤링 방식을 적용할 수 있습니다~
보통 마이너 버전은 4개월 주기로 나오고 약 14개월 지원이 유지되므로,
현실적으로는 3~6개월 단위 혹은 EOL 전에 맞춰 업그레이드하는 패턴이 일반적입니다~
중요한 것은 사전 테스트 환경에서 CRD, 애드온, 네트워크 플러그인 등이 잘 작동하는지 확인하고
Canary 방식으로 일부부터 점진적으로 확대하는 것이라고 생각합니다~
3 Likes
버전업을 할때마다 다른 EKS 로 바꾸는 참신한 방법도 있다네요 ㄷㄷ
3 Likes
(EKS 사용시)
2 Likes
안녕하세요, 위에 송현님께서 답변해주신 내용에 저의 경험을 덧붙여보겠습니다.
다만 저는 오랜 기간 AWS 의 EC2 에서 직접 K8s 클러스터를 운영한 입장에서 말씀드리므로 EKS와 같은 Managed K8s 서비스에서는 상황이 다를 수 있습니다.
업그레이드 시점 결정
- K8s 버전의 EOL 여부: K8s 버전이 EOL에 가까워지면 보안 패치 및 버그 픽스가 제공되지 않으므로 업그레이드가 필요합니다.
- 새로운 기능 필요성: 새로운 K8s 버전에서 제공하는 기능이 필요할 때 업그레이드를 고려할 수 있습니다. ex) 1.30 에서 도입된 Topology Aware Routing
특별한 일이 없다면 EOL 이전 1~2개월 전에는 업그레이드를 계획합니다.
개인적으로는 k8s repo RSS를 구독해두면 새로운 릴리즈 소식을 빠르게 접할 수 있어 좋았습니다.
업그레이드 절차
- 버전 업그레이드는 k8s skew policy 에 따라 minor version을 하나씩 올려야 합니다. ( 버전 차이(skew) 정책 | Kubernetes )업그레이드 할 버전이 정해졌다면 다음 사항들을 점검해야 합니다.
- 현재 사용중인 K8s 버전의 EOL(End of Life) 여부
- 현재 운영중인 K8s API 에 의존하는 워크로드의 현재 버전이(예: ingress controller, external dns, cert manager 등) 업그레이드 하려는 K8s 버전을 지원하는지 여부
- 현재 운영중인 K8s Operator 들이 업그레이드 하려는 K8s 버전을 지원하는지 여부 (일부 Operator는 K8s API 변경에 민감하게 반응할 수 있어 빠짐없이 점검하는것이 좋습니다.)
- 이전 단계에서 확인된 K8s API 에 의존하는 워크로드 및 오퍼레이터를 가능한 최신버전으로 업그레이드 (보통 1개의 버전만 지원되는 서비스는 없으므로 가능한 지원되는 최신버전으로 업그레이드 하는것이 좋습니다. 각 서비스의 마이그레이션 가이드가 별도로 존재하는지 반드시 체크하여 따라 업그레이드 해야합니다.)
- 업그레이드 환경의 kubectl 버전을 업그레이드 하려는 K8s 버전과 호환되는 버전으로 맞춤 (kubectl 은 K8s skew policy 에 따라 최대 1버전 차이까지 호환됩니다.)
- etcd 스냅샷 백업 (마스터 노드 업그레이드 이전에 반드시 수행)
- 업그레이드 하려는 K8s 버전으로 제어 노드 업그레이드 (1개씩 순차적으로 업그레이드 권장)
- 업그레이드 하려는 K8s 버전으로 워커 노드 업그레이드 (노드그룹 단위로 롤링업그레이드 진행)
- 업그레이드 후 워크로드 및 오퍼레이터 정상 동작 여부 확인
만약 5번 단계를 진행하는 과정에서 문제가 발생하여 롤백이 필요한 경우 문제가 발생한 제어 노드를 이전 버전으로 다시 배포하고, 제어 노드 업그레이드 이전에 찍어둔 etcd 스냅샷을 복원하는 방법이 가장 확실합니다. (업그레이드 하며 etcd 데이터 일부가 마이그레이션 또는 손상될 수 있습니다.)
새로 배포된 제어 노드에 워커 노드가 정상적으로 조인하면 문제 없이 마이그레이션 된 것 입니다.
도움이 되었으면 좋겠습니다.
2 Likes
Managed k8s가 아닌, on-premise 형태의 k8s를 운영하는 환경에서의 업그레이드 전략도 공유드립니다.
business logic상에서 필요한 기능들을 k8s를 통해 구현하고 있는 입장에서 각자 환경에 맞는 안정적인 조합(kernel, os, cni, csi 등)이 갖춰져있고, 신규 k8s의 기능이 필요한 상황이 아니라면 3개월마다 나오는 k8s의 신규 버전을 계속해서 따라갈 필요는 없다고 생각합니다.
오히려 안정적인 버전을 유지하다가, 필요한 기능이 신규 k8s에 추가되었을 때 해당 버전의 k8s클러스터를 새로이 구축하고 migration을 하는 게 더 효율적일 수 있습니다.
일부 서버를 통해 신규 k8s 클러스터를 구축하고, 구 클러스터의 일부 서버들의 pod들을 이관하고 비워진 서버들을 다시 신규 k8s클러스터에 붙이는 방식으로 진행하면 두 배의 자원이 아닌, +@정도의 자원으로도 migration이 가능합니다.
3 Likes
@user49 많은 분들이 의견을 남겨주셨는데요, 추가적으로 궁금하신 점이 있다면 구체적으로 질문하셔도 좋을 것 같습니다 
사전 질문이 여기에 올라갔군요. 몰랐다가 멘션해주셔서 이메일 보고 알았습니다^^;
다들 소중한 의견 너무너무 감사합니다.
질문이 좀 구체적이지 않았는데요,
제가 업그레이드 전략을 고민할 땐 고려 요소가 참 많은데, 이걸 정기적으로 어떻게들 하고 계실까? 라는 생각에
혹시 전문가들의 노하우가 따로 있진 않을까 생각해서 질문을 제출했었습니다.
Cloud Managed는 크게 부담되진 않는데, Onprem 물리 서버에 구성된 K8s 업그레이드할 때 고려사항이 참 많더라구요. 특히 복원 시나리오를 생각할 때 Onprem 환경은 신규 VM과 클러스터를 바로 구성할 수 없다 보니 더 신중하게 고민하게 되는 것 같습니다.
예를 들면 아래와 같은 상황을 가정했을 때, 물음표가 꼬리에 꼬리를 무는 것 같습니다.
-
Onprem 기반 K8s, 목표 업그레이드 버전 : 1.27 → 1.32
-
클러스터에 수용된 모든 어플리케이션 서비스의 진입점(Ingress LB IP)이 하나여야 한다.
멀티클러스터로 묶는게 아니기 때문에 2개의 운영 클러스터를 동시에 둘순 없다.
어떤 배포 방식을 채택하든 한날한시에 모든 워크로드들은 다같이 이사해야 한다. -
클러스터 업그레이드 이후 개발자의 서비스 점검이 필요한데, 개발자가 10~20명이다.
작업 시간을 어렵게 확보했고, 가능한 Downtime은 일요일 새벽시간, 단 몇시간 뿐.
Q1. 수십개의 노드 버전을 롤링으로 하나하나 올려가면서 업그레이드했다.
근데 점검 과정에서 일부 서비스에 원인 모를 문제가 발생했다. 다운그레이드는 불가능한데, 이전 환경과 완전히 동일하게 돌아가려면 etcd snapshot restore만 하면 깔끔하게 원복이 될까? kubelet 등 필수 컴포넌트는?
etcd는 클러스터 상태 정보를 유실했을 때 유의미한데, 다운그레이드도 재현할 수 있을까?
무엇보다 확보한 Downtime을 넘어버릴 것 같은데… 근데 업그레이드하다가 롤백한 사례가 실무에서 빈번한가?
Q2. 아무래도 불안해서 가용 자원을 무리해서 확보하고 블루/그린으로 채택했다.
그린에서 모든 준비가 끝난 다음 앞단 L4에서 백엔드를 그린으로 절체하는 방식으로 서비스 무중단을 계획하고 싶다.
근데 양쪽 클러스터에서 워크로드를 띄워 놓으면, 블루/그린이 같이 바라보고 있는 하나의 DB와 S3에 중복 쓰기가 일어나는 거 아닌가? DB와 S3도 한 벌을 더 만들고 Live Sync를 해줘야만 진정한 블루/그린인가?
너무 일이 커지는데 어떻게 달리는 기차의 바퀴는 도대체 어떻게 교체하는 걸까?
위에 적은 고민 외에도 더 많은데… 막상 업그레이드 전략에 대해 검색해보면, 정보가 많이 없고 어떻게 보면 어렵지 않은 일인 것 처럼 여겨지는 것 같습니다. 그래서 이런 저런 고민을 하다가, 오히려 고려할 필요가 전혀 없는데 혼자만 심각하게 생각하는 것 같은 느낌도 들더라구요. 아무래도 제가 경험이 많이 없어서 그렇겠지만 나만 모르는 전문가들의 노하우가 있는 건 아닐까라는 생각이 들어 질문하게 되었습니다 ㅎㅎ
아무래도 제가 운영하는 환경을 글로써 모두 설명하긴 어렵기 때문에, 주신 답변들이 최선일 것 같아요.
소중한 의견 너무너무 감사드리고 잘 참고해서, 저만의 방법을 최적화해봐야겠습니다 !!