이 섹션의 다중 페이지 출력 화면임. 여기를 클릭하여 프린트.
쿠버네티스 프로젝트는 가장 최신의 3개 마이너(minor) 릴리스(1.30, 1.29, 1.28)에 대해서 릴리스 브랜치를 관리한다. 쿠버네티스 1.19 및 이후 신규 버전은 약 1년간 패치 지원을 받을 수 있다. 쿠버네티스 1.18 및 이전 버전은 약 9개월간의 패치 지원을 받을 수 있다.
쿠버네티스 버전은 x.y.z 의 형태로 표현되는데, x 는 메이저(major) 버전, y 는 마이너(minor), z 는 패치(patch) 버전을 의미하며, 이는 시맨틱 버전의 용어를 따른 것이다.
자세한 정보는 버전 차이(skew) 정책 문서에서 확인하길 바란다.
차기 쿠버네티스 릴리스 1.31 일정은 스케줄에서 확인할 수 있다.
릴리스 노트는 사용자의 쿠버네티스 버전에 해당하는 변경로그(Changelog)를 통해서 확인할 수 있다. 1.30 의 변경로그는 깃허브에 있다.
대안으로, 릴리스 노트는 relnotes.k8s.io에서 온라인으로 검색 및 필터링이 가능하다. 1.30로 필터링된 릴리스 노트는 relnotes.k8s.io에서 확인한다.
이 문서는 다양한 쿠버네티스 구성 요소 간에 지원되는 최대 버전 차이를 설명한다. 특정 클러스터 배포 도구는 버전 차이에 대한 추가적인 제한을 설정할 수 있다.
쿠버네티스 버전은 x.y.z 로 표현되는데, 여기서 x 는 메이저 버전, y 는 마이너 버전, z 는 패치 버전을 의미하며, 이는 시맨틱 버전 용어에 따른 것이다. 자세한 내용은 쿠버네티스 릴리스 버전을 참조한다.
쿠버네티스 프로젝트는 최근 세 개의 마이너 릴리스 (1.30, 1.29, 1.28) 에 대한 릴리스 분기를 유지한다. 쿠버네티스 1.19 이상은 약 1년간의 패치 지원을 받는다. 쿠버네티스 1.18 이상은 약 9개월의 패치 지원을 받는다.
보안 수정사항을 포함한 해당 수정사항은 심각도와 타당성에 따라 세 개의 릴리스 브랜치로 백포트(backport) 될 수 있다. 패치 릴리스는 각 브랜치별로 정기적인 주기로 제공하며, 필요한 경우 추가 긴급 릴리스도 추가한다.
릴리스 관리자 그룹이 이러한 결정 권한을 가진다.
자세한 내용은 쿠버네티스 패치 릴리스 페이지를 참조한다.
고가용성(HA) 클러스터에서 최신 및 가장 오래된 kube-apiserver 인스턴스가 각각 한 단계 마이너 버전 내에 있어야 한다.
예:
kube-apiserver는 1.30 이다.kube-apiserver 인스턴스는 1.30 및 1.29 을 지원한다.kubelet은 kube-apiserver보다 최신일 수 없으며, 2단계의 낮은 마이너 버전까지 지원한다.
예:
kube-apiserver가 1.30 이다.kubelet은 1.30, 1.29 및 1.28 을 지원한다.kube-apiserver 인스턴스 사이에 버전 차이가 있으면 허용되는 kubelet 버전의 범위도 줄어든다.예:
kube-apiserver 인스턴스는 1.30 및 1.29 이다.kubelet은 1.29 및 1.28 을 지원한다(1.30 는 kube-apiserver의 1.29 인스턴스보다 최신 버전이기 때문에 지원하지 않는다).kube-controller-manager, kube-scheduler 그리고 cloud-controller-manager는 그들과 통신하는 kube-apiserver 인스턴스보다 최신 버전이면 안 된다. kube-apiserver 마이너 버전과 일치할 것으로 예상하지만, 최대 한 단계 낮은 마이너 버전까지는 허용한다(실시간 업그레이드를 지원하기 위해서).
예:
kube-apiserver은 1.30 이다.kube-controller-manager, kube-scheduler 그리고 cloud-controller-manager는 1.30 과 1.29 을 지원한다.kube-apiserver 인스턴스 간에 버전 차이가 존재하고 이러한 구성 요소가 클러스터의 모든 kube-apiserver 인스턴스와 통신할 수 있는 경우(예를 들어, 로드 밸런서를 통해서)에는 구성 요소의 허용하는 버전의 범위도 줄어든다.예:
kube-apiserver 인스턴스는 1.30 및 1.29 이다.kube-controller-manager, kube-scheduler 그리고 cloud-controller-manager는 모든 kube-apiserver 인스턴스로 라우팅하는 로드 밸런서와 통신한다.kube-controller-manager, kube-scheduler 그리고 cloud-controller-manager는 1.29 에서 지원한다(1.30 는 kube-apiserver 인스턴스의 1.29 버전보다 최신이기 때문에 지원하지 않는다).kubectl은 kube-apiserver의 한 단계 마이너 버전(이전 또는 최신) 내에서 지원한다.
예:
kube-apiserver은 1.30 이다.kubectl은 1.31, 1.30 및 1.29 을 지원한다.kube-apiserver 인스턴스 간에 버전 차이가 있으면 지원되는 kubectl 버전의 범위도 줄어든다.예:
kube-apiserver 인스턴스는 1.30 및 1.29 이다.kubectl은 1.30 및 1.29 에서 지원한다(다른 버전은 kube-apiserver 인스턴스 중에 한 단계 이상의 마이너 버전 차이가 난다).구성요소 간 지원되는 버전 차이는 구성요소를 업그레이드하는 순서에 영향을 준다. 이 섹션에서는 기존 클러스터를 버전 1.29 에서 버전 1.30 로 전환하기 위해 구성 요소를 업그레이드하는 순서를 설명한다.
선택적으로, 업그레이드를 준비할 때, 쿠버네티스 프로젝트는 업그레이드 중 가능한 많은 회귀 분석 및 버그 수정의 이점을 얻기 위해 다음을 수행할 것을 권장한다.
예를 들어, 만약 1.29 버전을 실행 중인 경우, 최신 패치 버전을 사용 중인지 확인한다. 그런 다음, 최신 패치 버전인 1.30로 업그레이드 한다.
사전 요구 사항:
kube-apiserver 인스턴스는 1.29 이어야 한다.kube-apiserver 인스턴스는 1.29 또는 1.30 이어야 한다(이것은 kube-apiserver 인스턴스 간의 가장 최신과 오래된 버전의 차이를 최대 1개의 마이너 버전의 차이로 보장한다).kube-controller-manager, kube-scheduler 그리고 cloud-controller-manager의 버전은 1.29 이어야 한다(이것은 기존 API서버 버전보다 최신 버전이 아니고 새로운 API서버 버전의 마이너 1개의 버전 내에 있음을 보장한다).kubelet 인스턴스는 버전 1.29 또는 1.28 이어야 한다(이것은 기존 API서버 버전보다 최신 버전이 아니며, 새로운 API서버 버전의 2개의 마이너 버전 내에 있음을 보장한다).kube-apiserver 인스턴스가 전송하는 데이터를 처리할 수 있다:
ValidatingWebhookConfiguration 그리고 MutatingWebhookConfiguration 오브젝트는 1.30 에 추가된 REST 리소스의 새 버전을 포함하도록 업데이트한다(또는 v1.15 이상에서 사용 가능한 matchPolicy: Equivalent option 설정을 사용).kube-apiserver를 1.30 으로 업그레이드
kube-apiserver의 마이너 버전을 건너뛰지 않도록 요구한다.사전 요구 사항:
kube-apiserver 인스턴스는 1.30 이여야 한다(HA 클러스터에서 kube-apiserver 인스턴스와 통신할 수 있는 구성 요소를 업그레이드 전에 모든 kube-apiserver 인스턴스는 업그레이드되어야 한다).kube-controller-manager, kube-scheduler 및 cloud-controller-manager 를
1.30 으로 업그레이드한다. kube-controller-manager, kube-scheduler 및 cloud-controller-manager 사이에는
업그레이드에 우선순위가 없다. 이 구성 요소들을
임의의 순서 또는 심지어 동시에
업그레이드해도 된다.
사전 요구 사항:
kubelet과 통신하는 kube-apiserver 인스턴스는 1.30 이어야 한다.필요에 따라서 kubelet 인스턴스를 1.30 으로 업그레이드할 수 있다(또는 1.29 아니면 1.28 으로 유지할 수 있음).
kubelet 마이너 버전 업그레이드를 수행하기 전에, 해당 노드의 파드를 드레인(drain)해야 한다.
인플레이스(In-place) 마이너 버전 kubelet 업그레이드는 지원되지 않는다.클러스터 안의 kubelet 인스턴스를 kube-apiserver의 버전보다 2단계 낮은 버전으로 실행하는 것을 권장하지 않는다:
kube-apiserver를 업그레이드한다면 한 단계 낮은 버전으로 업그레이드해야 한다.kubelet을 실행할 가능성을 높인다.kube-proxy는 반드시 kubelet과 동일한 마이너 버전이어야 한다.kube-proxy는 반드시 kube-apiserver 보다 최신 버전이면 안 된다.kube-proxy는 kube-apiserver 보다 2단계 낮은 마이너 버전 이내여야 한다.예:
kube-proxy 버전이 1.28 인 경우:
kubelet 버전도 반드시 1.28 와 동일한 마이너 버전이어야 한다.kube-apiserver 버전은 반드시 1.28 에서 1.30 사이 이어야 한다.