쿠버네티스 1.33, 6월 28일 지원 종료: 컨트롤러가 아니라 클러스터 자체입니다

지원 종료, 컨트롤러 얘기가 아니라 클러스터 자체입니다

최근 쿠버네티스 생태계에서 'EOL'이라는 단어가 자주 등장했습니다. Ingress-NGINX 컨트롤러 종료나 Gateway API 전환 같은 이야기죠. 그래서 "쿠버네티스 1.33 EOL"도 같은 종류로 넘겨버리기 쉬운데, 둘은 완전히 다릅니다.

앞의 것들은 라우팅 컴포넌트(애드온)의 수명주기 문제이고, 이번 1.33 EOL은 클러스터의 코어 마이너 버전 자체가 지원을 끝낸다는 뜻입니다. 컨트롤 플레인과 모든 노드가 올라타 있는 그 버전 말입니다. 그래서 영향 범위와 대응 방식이 다릅니다.

1.33 EOL이 정확히 무슨 뜻인가

쿠버네티스 1.33의 지원 종료일은 2026년 6월 28일입니다. 한 가지 더 알아둘 점은, 그 전인 2026년 4월 28일에 이미 유지보수(maintenance) 모드로 들어갔다는 것입니다. EOL을 "그날 갑자기 멈춘다"로 오해하기 쉬운데, 정확히는 그날 이후 공식 패치 릴리스가 더 이상 나오지 않는다는 의미입니다.

실무에서 이게 왜 문제냐면, EOL 이후 새 보안 취약점(CVE)이 나와도 1.33에는 패치가 제공되지 않기 때문입니다. 클러스터는 계속 돌아가지만, 알려진 결함을 메울 공식 경로가 사라지는 셈이죠. 쿠버네티스의 지원 정책은 마이너 버전당 약 14개월(표준 12개월 + 유예 2개월)이고, 패치는 보통 월 1회 케이던스로 나옵니다. 1.33은 그 시계가 6월 28일에 끝납니다.

어디로, 어떻게 올리나

2026년 6월 기준 최신 마이너는 1.36이고, 현재 유지보수되는 버전은 1.36, 1.35, 1.34 세 개입니다(쿠버네티스는 최근 3개 마이너만 릴리스 브랜치를 유지합니다). 권장 목적지는 최신인 1.36입니다.

여기서 가장 중요한 원칙. 마이너 버전은 건너뛸 수 없습니다. 1.33에서 1.36으로 직행할 수 없고, 1.33 → 1.34 → 1.35 → 1.36으로 한 단계씩 순차 업그레이드해야 합니다. 참고로 1.34는 지원 종료가 2026년 10월 27일로 임박해 있어, 잠깐 거쳐 가는 정거장일 뿐 최종 목적지로 삼기엔 적절치 않습니다.

운영자가 지금 점검할 것

업그레이드 자체보다 순서와 제약을 아는 것이 먼저입니다. 다음을 점검하세요.

1. 우리 클러스터 버전 확인: 지금 몇 버전인지, EOL까지 얼마나 남았는지부터 봅니다. 1.33이라면 6월 28일이 마감입니다.

2. 순차 업그레이드 계획: 1.33에서 1.36까지 한 번에 못 갑니다. 1.34, 1.35를 거쳐 단계별로 올리는 일정을 잡습니다.

3. 버전 스큐 확인: kubelet은 kube-apiserver보다 최대 3개 마이너까지만 구버전이 허용되고 신버전은 안 됩니다. kubectl은 apiserver 기준 위아래 1개 마이너까지입니다.

4. 제거된 API 점검: 여러 마이너를 거치는 동안 더 이상 지원되지 않거나 제거(deprecated·removed)된 API가 있으면 기존 워크로드 매니페스트가 깨질 수 있습니다. 업그레이드 전에 사용 중인 API 버전이 대상 버전에서도 유효한지 릴리스 노트로 확인하세요.

5. 업그레이드 순서·드레인·백업: 직접 운영(kubeadm) 환경이라면 컨트롤 플레인을 먼저 올린 뒤 워커 노드를 올립니다. kubelet 마이너 업그레이드 전에는 해당 노드를 drain(비우기)하고, 무중단을 위해 노드를 하나씩 처리합니다. 시작 전 etcd 등 클러스터 상태 백업과 롤백 계획을 세워두는 것이 안전합니다.

6. 매니지드 클라우드라면 연장 지원 정책 확인: EKS·AKS·GKE 같은 매니지드 서비스도 코어 버전 EOL을 피해 갈 수 없습니다. 연장 지원으로 넘어갈지, 언제까지 올려야 하는지, 비용은 어떻게 되는지를 확인해야 합니다.

참고로 패치 레벨(예: 1.36.x의 끝자리)은 출처와 시점에 따라 다르게 표기되니, 실제 업그레이드 전에는 공식 릴리스 페이지에서 최신 패치를 한 번 더 확인하는 편이 안전합니다.

이것만 기억하세요

자주 묻는 질문 (FAQ)