kubeconfig로 여러 쿠버네티스 클러스터 오가기와 사설 레지스트리 사용

이 글은 2022년 11월 기준 기록입니다.

 

기존 Docker 환경에서 제공하는 클러스터가 아닌, 실제 쿠버네티스 클러스터에 설정 파일을 이용해 접속해 봅니다.

Docker Desktop은 이미 클러스터 하나를 쥐여 준다

도커에 내장된 쿠버네티스 확장을 사용하면, 도커가 내부적으로 컨테이너를 활용해 docker-desktop이라는 이름의 쿠버네티스 클러스터를 구성하여 사용하게 됩니다. 지금까지 별다른 설정 없이 kubectl이 동작했다면 이 클러스터를 보고 있었던 것입니다.

접속을 위한 설정 파일의 위치는 다음과 같습니다.

C:\Users\사용자계정\.kube\config

config는 고치지 말고 KUBECONFIG로 늘린다

붙어야 할 클러스터가 늘어나면 이 파일을 어떻게 다룰지가 문제가 됩니다. 기본 config 파일 내용을 직접 고쳐도 상관은 없으나, 안정적인 관리를 위해서는 KUBECONFIG 환경 변수를 설정하는 편이 낫습니다. 원본을 건드리지 않고 파일을 추가하는 방식이기 때문입니다.

 

윈도우의 경우 KUBECONFIG 변수에 각 config 파일의 경로를 세미콜론(;)으로 구분해서 입력합니다.

context 이름이 클러스터를 고르는 스위치다

등록한 config들은 하나로 합쳐져 보이고, 그 안에서 대상을 고르는 단위가 context입니다.

# 등록된 모든 config 파일의 내용을 종합하여 표시
$ kubectl config view

# 각 config의 내용은 context의 name으로 구분됨
# 원하는 context 사용하기
$ kubectl config use-context CONTEXT_NAME

# 이후 사용하는 모든 명령은 선택된 context에 해당하는 클러스터에서 작동
# helm도 대상 클러스터를 기준으로 작동

 

한 번 context를 고르면 이후의 모든 명령이 그 클러스터에서 작동하고, helm 역시 같은 대상 클러스터를 기준으로 동작합니다. 명령마다 대상을 지정할 필요가 없는 대신, 지금 어느 context에 서 있는지는 늘 의식해야 합니다.

이미지 저장소를 쓸 수 없을 때는 호스트에 직접 올린다

사용하는 쿠버네티스 클러스터에 연결된 이미지 저장소를 임의로 사용할 수 없을 때가 있습니다. 그럴 때는 특정 호스트에 이미지를 올리고 그것을 사용하는 방법을 씁니다.

 

레지스트리용 이미지는 이름 자체에 대상 주소를 붙여서 빌드합니다.

# 기존 이미지 생성
$ docker build -t IMAGE_NAME:VERSION .

# 레지스트리용 이미지 생성
$ docker build -t IP_ADDRESS:32000/IMAGE_NAME:VERSION .

 

그리고 push합니다.

$ docker push IP_ADDRESS:32000/IMAGE_NAME:VERSION

도커가 신뢰하지 않는 저장소는 daemon 설정에 등록해야 한다

이 상태에서는 도커가 저장소에 대해 신뢰할 수 없어서 업로드가 실패하게 됩니다. 도커 daemon 설정에 다음 내용을 추가합니다.

"insecure-registries" : ["IP_ADDRESS:32000"] 

 

설정 후 Docker를 재시작합니다.

클러스터 안에서는 localhost로 참조한다

전송이 완료되면, 해당 클러스터에서 작동하는 image 소스 이름을 다음 형태로 작성하여 사용합니다.

localhost:32000/IMAGE_NAME:VERSION 

 

올릴 때는 IP 주소로 지정했지만 클러스터 안에서 참조할 때는 localhost가 된다는 점이 헷갈리기 쉬운 지점입니다.