소프트웨어 정의에서부터 접근해보는 여러 가지

쿠버네티스를 운영하면서 사용하는 kubectl 버전은 운영하는 Kubernetes 클러스터 버전과 호환되어야 한다. 이 내용은 Kubernetes 공식 문서 내 버전 차이 정책(Version Skew Policy)에서 확인할 수 있으며, Amazon EKS 문서에도 명시적으로 언급되어 있다.

kubectl은 kube-apiserver의 한 단계 마이너 버전(이전 또는 최신) 내에서 지원한다.

예:

• kube-apiserver은 1.32 이다.
• kubectl은 1.33, 1.32 및 1.31 을 지원한다.

참고:

HA 클러스터의 kube-apiserver 인스턴스 간에 버전 차이가 있으면 지원되는 kubectl 버전의 범위도 줄어든다.

예:

• kube-apiserver 인스턴스는 1.32 및 1.31 이다.
• kubectl은 1.32 및 1.31 에서 지원한다(다른 버전은 kube-apiserver 인스턴스 중에 한 단계 이상의 마이너 버전 차이가 난다).

https://kubernetes.io/ko/releases/version-skew-policy/#kubectl

참고

Amazon EKS 클러스터 제어 영역과 마이너 버전이 하나 다른 kubectl 버전을 사용해야 합니다. 예를 들어, 1.30 kubectl 클라이언트는 Kubernetes 1.29, 1.30, 1.31 클러스터와 함께 작동합니다.

https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/install-kubectl.html#kubectl-install-update

그런데 Amazon EKS를 클러스터를 사용하다보면 kubectl 명령어를 실행할 때, `v1.29.0-eks-5e0fdde`와 같은 형식의 버전 문자열을 볼 수 있다 (참고: https://aws.amazon.com/ko/blogs/tech/how-to-upgrade-amazon-eks-worker-nodes-with-karpenter-drift/ ). Amazon EKS 사용자 가이드 - kubectl 및 eksctl 설정 문서에 따르면 이 바이너리는 업스트림 커뮤니티 버전과 동일하다고 언급되어 있다. 이와 같이 동일한 바이너리를 사용하더라도 버전 스트링을 커스터마이징하는 경우가 있는데, 클라우드를 제공하는 프로바이더 등에서 직접 바이너리를 빌드했음을 알려 신뢰성을 확보하거나, 또는 내부 버전 관리 목적을 위해 (예: 특정 환경용 빌드 구분 - `v1.32.0-internal`, 테스트 환경 구분 - `v1.32.0-test`, 개발 단계 구분 - `v1.29.0-dev`) 사용할 수 있겠다.

Kubernetes 소스를 직접 활용하여 버전 문자열을 커스터마이징해보자.

사전 요구사항 

• Go 개발 환경: 아래 과정을 사용하면 원하는 kubectl 버전에 맞추어 go를 직접 다운로드하여 바이너리를 빌드하는 과정을 거친다. 해당 Go가 잘 실행될 수 있도록 https://go.dev/wiki/MinimumRequirements 홈페이지에서 언급하는 go 최소 요구 사항을 확인하여 Go 개발 환경을 갖추도록 한다.
• Git: 이미 git 명령어가 실행되는 환경이라면 추가로 고려하지 않아도 된다. 그렇지 않다면 https://git-scm.com/ 등을 참고하여 git를 설치하도록 한다.
• Make 도구: 역사가 오래된 도구로 (링크: https://www.gnu.org/software/make/manual/make.html), 소스 코드 내 Makefile 파일을 읽어와 바이너리를 빌드하는 도구이다. "make" 명령어가 실행되지 않는다면 개발 환경 운영체제 및 배포판에 따라 설치하는 가이드를 검색하여 준비한다.

빌드 과정

1. 소스코드 준비

Kubernetes - GitHub 저장소에서 소스를 가져와 해당 디렉토리로 이동한다.

$ git clone https://github.com/kubernetes/kubernetes
$ cd kubernetes

2. 기존 버전 태그 확인

아래 명령어를 사용하여 최신 릴리스된 Kubernetes 버전부터 이전 버전까지 목록을 확인할 수 있다. 명령어가 종료되지 않고 : 마크가 앞에 나오는 것을 볼 수 있는데, 스페이스바를 누르면 계속 목록을 볼 수 있으며, q 문자를 누르면 빠져나온다.

$ git tag --sort=-taggerdate

3. 버전 선택 및 체크아웃

빌드하고자 하는 버전 태그를 로컬 환경 변수에 저장하고, 해당 버전에 대한 소스로 변경하기 위해 "git checkout" 커맨드를 사용한다. 여기서는 TAG라는 이름으로 환경 변수를 사용하여 값을 저장한 다음 $TAG 형태로 해당 값을 사용하여 해당 버전에 대한 소스를 체크아웃하였다.

$ TAG=v1.31.2  # 반드시 git tag 목록에 있는 버전을 사용
$ git checkout $TAG

4. 커스텀 태그 설정

Kubernetes 에서 제공하는 빌드 방식은 소스에 대한 Git 저장소에 기존 태그가 이미 저장되어 있어 해당 태그 이름을 우선적으로 활용하여 빌드하도록 구성이 되어 있다. 여기서는 해당 방식을 변경하기보다는, 기존 태그 목록을 제거한 후, 현재 체크아웃한 소스에 대해 커스텀 태그를 설정하는 방식을 적용해보자. 이 때, 임의의 문자열을 사용할 수는 없으며 "v{SEMVER}-{CUSTOM}" 형태를 사용한다. SEMVER는 https://semver.org/lang/ko/ 에서 설명하는 버전 번호에 해당하며, {CUSTOM} 부분에 위에서 설명한 목적에 따라 간단한 문자열을 추가해보는 식으로 설정한다.

# 기존 태그 제거
$ git tag | xargs git tag -d
 
# 원격 태그 가져오기 비활성화
$ git config --local fetch.tags false
 
# 새로운 커스텀 태그 생성
$ git tag $TAG-aewstest

5. 태그 적용 확인

아래 명령어를 사용하여 태그가 잘 적용되었는지 확인한다.

$ git describe --tags --match='v*'

6. kubectl 빌드

이제 make 명령어를 사용하여 빌드해보도록 하자. 아래 명령어를 실행한다.

$ make all WHAT=cmd/kubectl GOFLAGS=-v

7. 빌드 결과 확인

빌드된 바이너리는 _output 폴더에 생성된다. 빌드한 kubectl 바이너리를 한 번 실행해보자.

$ _output/bin/kubectl version

유의 사항

위에서 설명하였듯이, kubectl 버전은 클러스터 버전과 한 단계 차이까지를 허용한다. 테스트 환경에서 사용할 때에는 충분히 검증 후 사용하며, 프로덕션 환경에서는 공식 배포하는 kubectl 바이너리 사용을 권장한다.

• 도구 설치 - kubectl: https://kubernetes.io/ko/docs/tasks/tools/#kubectl

• Amazon EKS - kubectl 및 eksctl 설정: https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/install-kubectl.html

마치며

이와 같이 빌드한 kubectl은 원하는 버전 커스팀 문자열을 가질 수 있으며, 해당 문자열을 활용한다면 CI/CD에서 kubectl 버전을 확인하여 클러스터 관리에 도움을 주는 방향으로 활용하는 것도 가능하겠다. 실제 운영 환경에서는 공식 배포판을 사용하는 것이 안전하며, 커스텀 빌드는 테스트나 개발 환경에서 사용하는 것을 권장한다.