제가 매주 뉴스레터와 블로그로 공유하는 아티클은 크게 3가지 유형으로 나눠집니다. (아마 눈치채셨을지도 모르겠습니다.)
- 직접 따라해볼 수 있는 DevOps/MLOps 실습 가이드
- 최신 DevOps/MLOps 기술 소식
- DevOps/MLOps 관련 흥미로운 이야기
그 중에서도 실습 가이드는 로컬에서도 쉽게 따라하며 경험할 수 있어서 많은 분들이 긍정적인 피드백을 주고 계신데요.
DevOps와 MLOps 관련 툴을 다루다보니 로컬 Kubernetes 환경이 거의 필수가 되었고, 그래서 minikube를 사용하곤 했는데요.
하지만 이번엔 다른 툴을 여러분들께 소개해드리려고 합니다.
바로, Kind(Kubernetes in Docker)입니다.
직관적인 이름처럼, Docker를 사용해서 Kubernetes 클러스터를 구축해주는 툴인데요.
minikube와 비교하며 더 자세히 알아보겠습니다.
Kind와 minikube 비교하기
1. 클러스터 내 Service 접근 (Kind⬆️)
minikube로 실습할 때 minikube service 명령어를 사용해야만 클러스터에 배포한 Service에 웹 브라우저로 접근할 수 있습니다. 테스트나 실습을 하다보면 꽤 불편한 점이죠.
하지만 Kind에서는 이런 터널링 작업이 필요하지 않습니다. 특히 Windows나 macOS에서 Docker Desktop 사용하는 경우, Kind 클러스터 구축 설정에서 포트 매핑(Port Mapping) 설정만 추가하면 끝이라서 minikube보다 훨씬 편합니다.
2. 클러스터 설정 관리 (Kind⬆️)
minikube는 CLI 환경에서 명령어로 클러스터 구축 설정을 해야 합니다. 노드의 개수, 리소스, 클러스터 이름 등을 터미널 명령어로 지정하는 방식이죠.
반면에 Kind는 전체 클러스터 설정을 YAML 파일로 저장해서 관리할 수 있습니다. 나중에 어떤 클러스터 설정을 했었는지 따로 찾아볼 필요없이 설정 YAML 파일만 있으면 된다는 것인데요. 이 특징은 IaC(Infrastructure as Code)와도 이어집니다.
3. 기존 클러스터 상태 관리 (minikube⬆️)
minikube는 클러스터를 자유롭게 중지하고 재시작할 수 있습니다. 그래서 긴 호흡으로 Kubernetes를 테스트하거나 실습하는 경우라면 중간에 클러스터를 멈췄다가 나중에 다시 이어서 사용할 수 있어 유리합니다.
하지만 Kind는 클러스터를 생성하고 제거하는 기능만 지원합니다. Kind 클러스터를 제거한다는 것은 구축한 클러스터에 배포한 리소스와 저장되는 데이터까지 모두 삭제된다는 뜻입니다.
Kind 클러스터로 실습이나 테스트를 한다면 꼭 유의해야 할 점인데요. 반면 이런 특징 덕분에 CI 파이프라인 내에서 Kubernetes 환경이 필요할 때 Kind를 활용하기도 합니다.
정리하자면, Kind는 빠르게 Kubernetes 환경를 구축해서 테스트하도록 도와주는 툴이라고 할 수 있습니다.
그렇다면 이제 실습에 필요한 준비물부터 빠르게 짚고 실습하러 가보시죠.
실습 전 준비물
가장 먼저 필요한 것은 물론 Docker입니다. Docker Desktop이나 Docker Engine 어느 것이든 괜찮습니다.
다음은 kubectl입니다. 아마 저와 같이 그동안 minikube를 써보셨다면 이미 설치가 되어있을 텐데요. 혹시 아직 설치하지 않으셨다면 여기를 참고해주세요.
마지막으로 Kind 툴을 설치해야 합니다.
Kind 공식 설치 페이지에서 여러분의 운영체제에 맞는 방식으로 설치하시면 됩니다.
참고로 제가 실습하는 환경은 WSL2(Windows Subsystem for Linux 2)인데요. 그래서 공식 설치 페이지의 On Linux에 나와있는 것처럼 아래 명령어로 Kind를 설치하겠습니다.
curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.31.0/kind-linux-amd64
chmod +x ./kind
sudo mv ./kind /usr/local/bin/kind위 명령어들을 차례대로 실행 완료했다면 아래 명령어로 Kind가 잘 설치되었는지 확인해봅니다.
kind --version
설치된 Kind의 버전이 표시되는 걸 보니 설치 성공이네요!
Kind 클러스터 설정부터 구축까지
이제 본격적으로 가보겠습니다. kind create cluster 명령어를 실행해도 기본 로컬 Kubernetes 환경이 바로 구축되지만, 우리는 DevOps 관점에서 더 체계적으로 관리하기 위해 클러스터 설정을 파일로 먼저 정의할 겁니다.
원하는 경로에 kind-config.yaml 파일을 아래와 같이 생성합니다. 구축할 클러스터의 이름은 test-cluster이고, Control Plane 노드와 Worker 노드를 하나씩 해서 총 2개 노드로 클러스터를 구성하겠습니다.
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
name: test-cluster
nodes:
- role: control-plane
- role: worker방금 생성한 YAML 파일이 있는 경로에서 아래 명령어를 실행하면 Kind로 Kubernetes 클러스터를 생성할 수 있습니다.
kind create cluster --config kind-config.yaml아마 Kind를 처음 쓴다면 Kubernetes 노드 이미지를 받아오느라 시간이 좀 걸릴 수 있습니다. 조금만 기다려보면…
이렇게 Kind 클러스터가 구축되었다는 로그가 뜰 겁니다.
클러스터가 구축되고 kubectl context 설정까지 완료되었다고 하네요!
Kind는 각 노드를 Docker 컨테이너로 생성해준다고 했었죠? 전체 Docker 컨테이너 목록을 보여주는 docker ps -a 명령어로 확인해봅시다.
그럼 현재 실행되고 있는 test-cluster-control-plane과 test-cluster-worker 컨테이너를 찾을 수 있습니다. 이 두 컨테이너가 Kind로 배포된 Kubernetes 노드인 것이죠.
우리가 사용하는 kubectl의 context 설정이 완료되었다고 하니 kubectl config current-context 명령어를 실행해봅시다.
그러면 kind-test-cluster라는 이름이 표시되는데요. Kind로 구축한 클러스터와 잘 연동되었다는 뜻입니다.
Kind에서 Ingress를 직접 써보자
Kind 클러스터 구축이 완료되었습니다. 로컬 환경에서 Kubernetes 실습을 할 수 있는 준비가 모두 끝났습니다!
근데 이렇게 끝내긴 아쉽네요. 아까 Kind는 포트 매핑만 하면 로컬 웹 브라우저에서 Kind 클러스터 내 Service로 접근할 수 있다고 했는데, 기억 나시나요?
minikube보다 더 쉽게 Service에 접근 가능한 Kind의 특징을 직접 경험해보겠습니다.
만약 Linux에서 Docker Engine만 사용하고 있다면...
아래에서 설명드릴
extraPortMappings설정을 하지 않아도 무방합니다. 단, 해당 설정을 건너뛸 경우 Worker Node의 IP를 통해 접근해야 한다는 점 기억해주세요. 이 외에 모든 실습 환경에서는extraPortMappings설정을 해야 합니다.
먼저 아까 생성했던 kind-config.yaml 파일을 아래와 같이 수정합니다. - role: worker 아래에 extraPortMappings 필드를 추가함으로써 로컬 웹 브라우저에서 해당 노드에 localhost와 30000 포트로 접근할 수 있게 되는 설정입니다.
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
name: test-cluster
nodes:
- role: control-plane
- role: worker
extraPortMappings:
- containerPort: 30080 # Kind로 생성된 노드의 포트번호
hostPort: 30000 # 로컬에서 해당 노드로 접근할 수 있는 포트번호업데이트한 설정으로 클러스터를 다시 구축하기 위해, 아까 생성한 클러스터를 아래 명령어로 제거합니다.
kind delete cluster --name test-clusterKind는 클러스터를 생성하거나 제거하는 것만 가능합니다.
Kind와 minikube를 비교하는 섹션에서도 언급했던 내용인데요. 실습이 끝난 클러스터를
kind delete명령어로 제거할 경우, 동일한 YAML 설정으로 클러스터를 다시 생성해도 새로운 클러스터가 생성될 뿐이지 이전 상태가 유지되지 않습니다. 이 점 유의하세요.
그리고 아까 수정한 Config 파일로 Kind 클러스터를 다시 구축해볼게요.
kind create cluster --config kind-config.yaml이제 NodePort 타입의 Service를 배포하고 로컬 웹 브라우저에서 바로 접속해보겠습니다.
실습용 매니페스트 YAML 파일은 아래와 같습니다. 원하는 파일명으로 저장해주세요.
kind: Pod
apiVersion: v1
metadata:
name: test-app
labels:
app: nodeport-test
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: test-svc
spec:
type: NodePort
selector:
app: nodeport-test
ports:
- name: http
nodePort: 30080 # kind-config.yaml에서 설정한 노드의 포트번호
port: 80그리고 kubectl apply -f {실습용 YAML 파일명}명령어로 위 Pod와 Service를 배포합니다.
kubectl get svc 명령어로 NodePort 타입의 Service가 잘 배포되었는지도 확인하고요.
배포가 완료되었다면 터미널에서 curl 명령어로 배포한 Service로 접근할 수 있는지 테스트해보겠습니다. kind-config.yaml 파일에 extraPortMappings 필드를 추가함으로써 해당 노드에 접근할 수 있다고 했었죠?
우리가 방금 NodePort 타입의 Service를 배포했기 때문에 localhost:30000로 접근하면 함께 배포한 Pod의 Nginx 앱이 정상적으로 응답하네요.
로컬 웹 브라우저에서도 동일한 URL로 접속해보겠습니다.
역시나 Nginx 웹서버의 응답을 받을 수 있습니다!
이렇게 Kind는 클러스터의 설정으로 로컬 웹 브라우저에서 쉽게 Service로 접근할 수 있다는 걸 직접 확인했습니다. 확실히 로컬에서 테스트하고 실습하기 더 편하겠네요.
실습 마무리
이번 아티클에서는 Kind가 무엇이고 minikube와 어떤 차이점이 있는지 알아봤습니다. 게다가 Kind를 직접 설치해서 클러스터를 구축하고, NodePort 타입의 Service 배포까지 진행했는데요.
minikube와 달리 Kind는 클러스터의 상태를 저장하고 다시 재개하는 기능을 지원하고 있지 않습니다. 저는 실습을 마무리하기 위해 아래 명령어로 Kind 클러스터를 제거하겠습니다.
kind delete cluster --name test-cluster여러분은 이제 minikube와 Kind를 모두 경험해보셨습니다. 각 툴의 장단점도 자연스럽게 익히셨을 것이고요.
이제 앞으로 공유드릴 실습 가이드에서 여러분은 원하시는 로컬 Kubernetes 구축 툴을 사용해서 실습을 진행하실 수 있을 겁니다.
각자 장단점이 뚜렷하고, 여러분의 상황과 조건에 따라 적합한 툴이 다를 테니까요.
그럼 저는 다음 아티클에서 더 흥미롭고 유익한 주제로 찾아오겠습니다.
감사합니다. 오늘도 행복한 하루 되세요😸