minikube를 사용한 Kubernetes 개발

이 안내서는 로컬 Kubernetes 개발 환경을 설정하기 위한 플랫폼 간 리소스로서 의도되었습니다. 이 안내서에서는 minikube를 사용할 것입니다. 이는 표준으로 받아들여지고 있기 때문입니다.

minikube로 시작하기

우리는 Kubernetes 프로젝트의 공식 문서에서 Running Kubernetes Locally with minikube의 내용을 추출하여 상세히 다룰 것입니다.

kubectl 설치

공식 문서에서는 여러 옵션을 제공하지만, 결과적으로 세 가지 중 하나를 할 수 있습니다:

  • Google Cloud 플랫폼의 Cloud SDK 페이지에서 Google Cloud SDK의 일부로 다운로드합니다. gcloud를 설치한 후, kubectl을 설치할 수 있습니다:

    sudo gcloud components install kubectl
    

    이미 이 방법으로 kubectl을 설치했다면, 업데이트를 확인하세요:

    sudo gcloud components update
    
  • cURL로 설치하거나 각 운영 체제에 적합한 패키지 관리 시스템을 사용하여 설치합니다:

minikube 설치

minikube 설치 가이드를 참조하세요. 여기서는 GitHub 릴리스에서 직접 설치할 것을 제안합니다.

VM 드라이버 선택

이 안내서의 플랫폼 간 호환성을 위해 VirtualBox를 사용할 것입니다. 그러나 VMware Fusion, HyperV, KVM 및 Xhyve용 드라이버도 있습니다.

minikube 시작/중지

GitLab 차트 개발을 위해 minikube 리소스 요청은 기본값보다 높게 설정되어야 합니다. 중요한 구성 항목은 minikube start --help 명령으로 찾을 수 있습니다. 테스트되는 부분 및 목록된 요구 사항에 따라 변경해야 할 사항이 아래에 제공되어 있습니다:

  • --cpus int: minikube VM에 할당된 CPU 수 (기본값 2). 절대적으로 필요한 최소 CPU는 3입니다. 전체 차트를 배포하려면 4가 필요합니다.
  • --memory int: minikube VM에 할당된 RAM 양 (기본값 2048). 절대적으로 필요한 최소값은 6144 (6 GB)입니다. 권장값은 10240 (10 GB)입니다.
  • --disk-size string: minikube VM에 할당된 디스크 크기 (형식: <숫자>[<단위>], 단위 = b, k, m 또는 g) (기본값 20g). GitLab의 저장소데이터베이스 요구 사항을 참조하세요.

    참고: 이는 ~/.minikube/machines/minikube/ 폴더 아래에 홈 디렉토리에 만들어집니다.

  • --kubernetes-version string: minikube VM이 사용할 Kubernetes 버전 (예: v1.2.3).
  • --registry-mirror stringSlice: Docker 데몬에 전달할 레지스트리 미러.

:: 여기서 두 번째 start 명령에서 이러한 값을 변경하려면 먼저 minikube delete로 기존 인스턴스를 삭제해야 하거나 수동으로 VirtualBox 관리자에서 속성을 변경해야 합니다.

모든 도구를 설치하고 구성한 후에는 다음으로 minikube 시작 및 중지를 수행할 수 있습니다.

minikube start --cpus 4 --memory 10240

이 명령은 다음과 유사한 내용을 출력해야 합니다:

로컬 Kubernetes v1.7.0 클러스터 시작 중...
VM 시작 중...
Minikube ISO 다운로드 중
 97.80 MB / 97.80 MB [==============================================] 100.00% 0s
VM IP 주소 가져오는 중...
파일을 클러스터로 이동 중...
인증서 설정 중...
클러스터 구성 요소 시작 중...
클러스터에 연결 중...
kubeconfig 설정 중...
Kubectl이 이제 클러스터를 사용하도록 구성되었습니다.
[helm.gitlab.io]$ minikube ip
192.168.99.100
[helm.gitlab.io]$ minikube stop
로컬 Kubernetes 클러스터 중지 중...
머신 중지됨.

minikube ip 명령을 실행한 결과를 확인하세요. 출력이 192.168.99.100이 아니라면 이 IP가 나준힌 후에 필요할 것입니다.

minikube 사용

minikube는 Kubernetes 설치와 마찬가지로 직접 사용되어 단일 노드 클러스터로 취급될 수 있습니다. minikube와 완전한 Kubernetes 클러스터(예: Google Container Engine (GKE)) 사이에 약간 다른 동작이 있습니다.

다른 점:

  • 지속적인 볼륨: hostPath만 지원됩니다.

사용 불가:

  • 로드 밸런서 (클라우드 제공 업체가 필요함).
  • 고급 스케줄링 정책 (다중 노드가 필요함).

주의: 지속적인 볼륨

minikube는 VM 내부의 디렉터리에 매핑되는 hostPath 유형의 지속적인 볼륨을 지원합니다. minikube는 tmpfs로 부팅되기 때문에 대부분의 디렉터리는 minikube stop을 통해 다시 부팅될 때 지속되지 않을 것입니다.

지속되는 디렉터리의 추가 세부 정보 및 목록은 minikube 시작 안내서에서 찾을 수 있습니다.

애드온 활성화

minikube는 기본 구성 이외의 일부 기능을 처리합니다. 이 프로젝트의 개발을 위해 Ingress에 액세스할 필요가 있습니다:

minikube addons enable ingress

대시보드 연결

다음 명령을 사용하여 대시보드의 URL을 찾을 수 있습니다:

minikube dashboard --url

차트 배포

이 차트를 minikube에 배포할 때 일부 차트 리소스를 줄이거나 비활성화해야 합니다. nginx-ingress 차트를 사용하여 포트 22, 80, 443을 제공하는 것은 불가능합니다. 이를 비활성화하고 Ingress 클래스를 설정하는 것이 최선입니다. nginx-ingress.enabled=false,global.ingress.class="nginx"로 설정하세요.

certmanager 차트는 minikube와 함께 사용할 수 없습니다. certmanager.install=false,global.ingress.configureCertmanager=false로 설정하여 비활성화해야 합니다. 결과적으로, 자체 서명된 인증서가 생성됩니다. gitlab-runner 차트에서 자체 서명된 인증서를 허용합니다. 릴리스 이름이 gitlab이라면, 인증서 이름은 gitlab-wildcard-tls-chain이 될 것입니다.

gitlab-shell 차트는 minikube에서 사용할 수 있지만, 이미 minikube에서 사용 중인 포트 22 이외의 다른 포트로 매핑해야 합니다. gitlab.gitlab-shell.service.type=NodePortgitlab.gitlab-shell.service.nodePort=<고번호 포트>를 구성할 수 있으며, 이를 통해 지정된 포트를 통해 저장소를 복제할 수 있습니다. 이 포트가 UI의 복제 링크에 반영되도록 하려면 global.shell.port=<고번호 포트>를 구성하세요.

다음 섹션에서는 로컬 Git 복제로부터 이러한 차트를 설치하는 방법을 보여드릴 것입니다. 원하는 브랜치 또는 태그를 체크아웃했는지 확인하고 해당 체크아웃의 기본 폴더에 있는지 확인하세요.

GitLab 차트 레포지토리 복제

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

권장 설정으로 GitLab 배포

추천되는 4 CPU 및 10 GB RAM을 사용하는 경우 values-minikube.yaml를 기본으로 사용하세요.

helm dependency update
helm upgrade --install gitlab . \
  --timeout 600s \
  -f https://gitlab.com/gitlab-org/charts/gitlab/raw/master/examples/values-minikube.yaml

최소한의 설정으로 GitLab 배포

절대 최소한 리소스를 사용하는 경우 3 CPU 및 6GB RAM을 사용해야 하며, 모든 레플리카를 줄이고 불필요한 서비스를 비활성화해야 합니다. 합리적인 기본으로 values-minikube-minimum.yaml을 참조하세요.

helm dependency update
helm upgrade --install gitlab . \
  --timeout 600s \
  -f https://gitlab.com/gitlab-org/charts/gitlab/raw/master/examples/values-minikube-minimum.yaml

만약 minikube ip의 출력이 192.168.99.100이 아니라면, 예제 구성 파일에서 IP 엔드포인트를 재정의하는 데에 아래 인자를 추가하세요:

  --set global.hosts.domain=$(minikube ip).nip.io \
  --set global.hosts.externalIP=$(minikube ip)

DNS 처리

제공된 예제 구성에서는 192.168.99.100.nip.io로 도메인을 구성하여 호스트 파일 또는 다른 도메인 이름 해결 서비스의 변경 오버헤드를 줄이려고 합니다. 그러나 이는 nip.io의 네트워크 접근성에 의존합니다.

이를 사용할 수 없는 경우, 호스트 파일을 수정하거나 다른 DNS 해결 수단을 제공해야 할 수 있습니다.

예를 들어 /etc/hosts 파일에 다음을 추가할 수 있습니다:

192.168.99.100 gitlab.some.domain registry.some.domain minio.some.domain

자체 서명된 CA 통합

차트가 배포된 후, 자체 서명된 인증서를 사용하는 경우 생성된 CA 인증서를 가져오는 방법에 대한 알림을 받게 될 것입니다. 이 인증서는 시스템 스토어에 추가할 수 있어서 브라우저, Docker 데몬 및 git 명령에서 모두 배포된 인증서를 신뢰할 수 있도록 할 수 있습니다. 방법은 운영 체제에 따라 다릅니다.

BounCA에는 대부분의 운영 체제를 다루는 좋은 자습서가 있습니다.

로그인

지정된 도메인을 방문하여 GitLab 인스턴스에 액세스할 수 있습니다. 이 예에서는 https://gitlab.192.168.99.100.nip.io를 사용합니다. 초기 루트 암호에 대한 비밀을 수동으로 만들었다면 해당 암호를 사용하여 루트 사용자로 로그인할 수 있습니다. 그렇지 않은 경우 GitLab은 루트 사용자를 위해 무작위 암호를 자동으로 생성했습니다. 이는 다음 명령을 사용하여 추출할 수 있습니다 (위의 명령을 사용했다면, <name>을 사용한 이름으로 바꿉니다).

kubectl get secret <name>-gitlab-initial-root-password -ojsonpath='{.data.password}' | base64 --decode ; echo