KinD를 사용한 Kubernetes 개발

본 안내서는 로컬 Kubernetes 개발 환경을 설정하기 위한 크로스 플랫폼 리소스로 프로덕션되었습니다. 본 안내서에서는 KinD를 사용할 것입니다. 이는 Docker를 사용하여 Kubernetes 클러스터를 생성하고 여러 버전 및 여러 노드를 배포할 수 있는 간단한 매커니즘을 제공합니다.

또한 nip.io를 사용할 것인데, 이를 사용하면 192.168.1.250.nip.io와 같은 형식으로 IP 주소를 호스트 이름에 매핑할 수 있습니다. 설치가 필요하지 않습니다.

note
아래의 SSL 활성화 설치 옵션의 경우, 리포지터리를 복제하고 변경 사항을 푸시하기 위해서는 SSH 대신 HTTPS를 통해 수행해야 합니다. 이에 대한 GitLab Shell의 서비스 노출을 NodePorts를 통해 업데이트할 계획입니다.

Apple 실리콘 (M1/M2)

kind는 macOS, M1 및 M2 등을 포함한 로컬 Kubernetes 개발 환경을 제공하기 위해 colima와 함께 사용할 수 있습니다.

의존성 설치

  • MacOS 13 (Ventura) 이상을 실행 중인지 확인하십시오.
  • colima를 설치하십시오.

  • Rosetta를 설치하십시오: 

    softwareupdate --install-rosetta

VM 구축

colima VM을 생성하십시오: 

colima start --cpu 4 --memory 16 --disk 40 --profile docker --arch aarch64 --vm-type=vz --vz-rosetta

준비가 되면, preparation을 참조하여 GitLab을 kind로 설치할 수 있습니다.

VM 관리

colima VM을 중지하려면: 

colima stop --profile docker

VM을 다시 시작하려면: 

colima start --profile docker

로컬 시스템을 제거하고 정리하려면: 

colima delete --profile docker

준비

필요한 정보

다음 설치 옵션에 필요한 호스트 IP를 알아야 합니다. 이 정보를 찾는 데에는 몇 가지 옵션이 있습니다:

  • Linux: hostname -i
  • MacOS: ipconfig getifaddr en0
note
대부분의 MacOS 시스템에서는 en0을 주요 인터페이스로 사용합니다. 다른 주요 인터페이스를 사용하는 시스템의 경우 en0 대신 해당 인터페이스 이름을 대체하십시오.

네임스페이스 사용

default 이외의 네임스페이스에 응용 프로그램을 설치하는 것이 가장 좋은 방법으로 간주됩니다. kubectl을 사용하여 helm install을 실행하기 전에 네임스페이스를 생성하십시오: 

kubectl create namespace YOUR_NAMESPACE 사용자_네임스페이스_이름

향후 kubectl 명령에 --namespace YOUR_NAMESPACE을 추가하여 네임스페이스를 사용하십시오. 또는 kubectx 프로젝트의 kubens를 사용하여 네임스페이스에 컨텍스트적으로 전환하고 추가 입력을 건너뛸 수 있습니다.

의존성 설치

asdf(자세한 정보)를 사용하여 다음 도구를 설치할 수 있습니다:

  • kubectl
  • helm
  • kind

kind는 로컬 Kubernetes 클러스터를 실행하기 위해 Docker를 사용하므로 Docker를 설치했는지 확인하십시오.

구성 예시 획득

GitLab 차트 리포지터리에는 다음 단계에서 참조된 모든 예시가 포함되어 있습니다. 최신 버전을 가져오려면 리포지터리를 복제하거나 기존 체크아웃을 업데이트하십시오: 

git clone https://gitlab.com/gitlab-org/charts/gitlab.git

GitLab Helm 차트 추가

시스템을 구성하여 GitLab Helm 차트에 액세스하도록 하려면 다음 명령을 따르십시오: 

helm repo add gitlab https://charts.gitlab.io/
helm repo update

배포 옵션

귀하의 요구에 따라 다음 중 하나의 배포 옵션을 선택하십시오.

note
네트워크 및 시스템 리소스에 따라 첫 번째 전체 배포 과정은 클라우드 네이티브 GitLab 이미지가 다운로드되는 데 약 10분 정도 소요될 수 있습니다. GitLab이 다음 명령을 통해 실행 중인지 확인하십시오:
kubectl --namespace YOUR_NAMESPACE get pods

webservice pod이 2/2 컨테이너로 READY 상태를 표시할 때 GitLab이 완전히 배포됩니다.

NGINX Ingress NodePort with SSL

이 방법에서는 SSL이 활성화된 NGINX 컨트롤러 서비스의 NodePort를 로컬 머신의 포트에 노출하기 위해 kind를 사용합니다. 

kind create cluster --config examples/kind/kind-ssl.yaml
helm upgrade --install gitlab gitlab/gitlab \
  --set global.hosts.domain=(your host IP).nip.io \
  -f examples/kind/values-base.yaml \
  -f examples/kind/values-ssl.yaml

그러면 https://gitlab.(your host IP).nip.io에서 GitLab에 액세스할 수 있습니다.

note
자체 서명된 인증서를 브라우저가 신뢰하도록 하려면 루트 CA를 다운로드하고 신뢰해야 합니다:
kubectl get secret gitlab-wildcard-tls-ca -ojsonpath='{.data.cfssl_ca}' | base64 --decode > gitlab.(your host IP).nip.io.ca.pem

이제 루트 CA를 다운로드했으므로 로컬 체인에 추가할 수 있습니다. (지침은 플랫폼에 따라 다양하며 온라인에서 쉽게 찾을 수 있습니다).

note
docker login으로 레지스트리에 로그인해야 하는 경우, 자체 서명된 인증서와 함께 레지스트리를 구성하기 위해 추가적인 단계를 수행해야 합니다. 자세한 지침은 다음에서 확인할 수 있습니다:

NGINX Ingress NodePort without SSL

이 방법에서는 SSL을 비활성화한 상태로 kind를 사용하여 NGINX 컨트롤러 서비스의 NodePort를 로컬 머신의 포트에 노출합니다. 

kind create cluster --config examples/kind/kind-no-ssl.yaml
helm upgrade --install gitlab gitlab/gitlab \
  --set global.hosts.domain=(your host IP).nip.io \
  -f examples/kind/values-base.yaml \
  -f examples/kind/values-no-ssl.yaml

http://gitlab.(your host IP).nip.io에서 GitLab에 액세스할 수 있습니다.

note
docker login으로 레지스트리에 로그인하려면, Docker에 보안되지 않은 레지스트리 신뢰 설정를 해야 합니다.

DNS 처리

본 안내서는 nip.io에 네트워크 액세스 권한이 있는 것으로 가정합니다. 이를 지원하지 않는 경우 KinD에 대해 동작할 미니큐브 설명서의 DNS 처리 섹션을 참고하십시오.

note
/etc/hosts를 수정할 때, $(minikube ip)의 출력이 아닌 호스트 컴퓨터의 IP 주소를 사용하십시오.

정리

로컬 시스템을 정리하려면 다음 명령을 실행하십시오: 

kind delete cluster
note
이름을 생성할 때 클러스터를 명명하거나 여러 클러스터를 실행 중인 경우 --name 플래그로 특정 클러스터를 삭제할 수 있습니다.