활발히 발전하는 소프트웨어는 주기적으로 규격을 변경해야 할 필요가 발생하고 이에따라 신규규격을 지원하고 이전 버전은 서서히 지원중단(deprecated)하는 방식을 사용한다. kubernetes도 마찮가지로 AP I마다 버전을 부여하고 kubernetes 버전에따라 자원별 지원 버전을 옮겨가면서 필요한 변화를 적용시키는 전략을 사용한다.
본 블로그에서는 kubernetes의 버전의 변경을 살펴보고 이를 변경하는 방법을 이야기해 보겠다.
쿠버네티스 버전은 x.y.z로 표현되고(x는 메이저, y는 마이너, z는 패치), 3개월에 한번씩 새로운 버전을 발표하고 이때 minor버전을 증가시키는 형태로 운영한다. 특별히 중요한 변화가 있을경우 메이저 버전을 변경시키는 경우가 있고 현재까지는 v0에서 v1으로 정식 릴리즈로 공개했을 때가 유일하다. 현재 최신버전은 v1.22이다. 지원정책은 v1.18 버전까지는 9개월의 패치 지원을 v1.19이상은 1년간의 패치지원을 한다. (현재 v1.18버전의 패치지원은 공식적으로 끝났다.)
패치 지원이 있는 버전의 경우 버전별 마이너 릴리즈에 대한 브랜치를 유지하면서 중요한 변화가 있을때 경우에따라 필요한 브랜치로 백포트하고 패치 릴리즈를 공표한다.
minor버전 하나 차이인 경우(ex. v1.22를 신규도입하는 경우 v.21과의 호환성)는 대부분의 경우를 지원한다.
kubernetes는 많은 구성 요소와 기여자(contributer)가 있는 대규모 시스템으로 기능셋은 시간에 지남에 따라 자연스럽게 발전하고 때로는 제거되야 한다. 이 대상으로는 API, flag 또는 기능전체가 될수 있으며, 기존 사용자들이 대응할 수 있도록 시스템적으로 적용시기를 공유하고 있다.
Kubernetes는 API 기반 시스템이므로 API의 변화를 수용하면서 진화하도록 설계되었고 API그룹이라는 단위로 독립적 버전을 부여하고 사용한다. API버전은 다음과 같은 3가지를 갖는다.
다양한 정책으로 버전을 옮기면서 기존 API를 변경시켜나가는데 자세한 내용은 아래 참고의 링크를 확인하기 바란다.
https://github.com/kubernetes/community/blob/master/contributors/design-proposals/release/versioning.md