쿠버네티스 참고 자료

Tier: Free, Premium, Ultimate Offering: Self-Managed

이것은 GitLab 지원팀이 때때로 문제 해결 중에 사용하는 쿠버네티스에 관한 유용한 정보 디렉터리입니다. GitLab은 지원팀이 모은 지식을 누구나 활용할 수 있도록 이를 공개하고 있습니다.

caution
이 명령은 귀하의 쿠버네티스 컴포넌트를 변경하거나 손상시킬 수 있으므로 사용에 주의하십시오.

이 명령을 사용하는 방법에 대해 확신이 없고 유료 티어에 있는 경우, 지원팀에 문의하여 문제를 해결할 수 있습니다.

일반 쿠버네티스 명령어

  • GCP 프로젝트에 권한 부여하는 방법 (특히 여러 GCP 계정에 프로젝트가 있는 경우 유용): 

    gcloud auth login

  • 쿠버네티스 대시보드에 액세스하는 방법: 

    # 미니큐브의 경우:
minikube dashboard —url
# 로컬이 아닌 설치의 경우 Kubectl을 통해 액세스가 구성된 경우:
kubectl proxy

  • 쿠버네티스 노드로 SSH하고 루트 사용자로 컨테이너에 들어가는 방법 https://github.com/kubernetes/kubernetes/issues/30656:

    • GCP의 경우 노드 이름을 찾아 gcloud compute ssh node-name을 실행합니다.
    • docker ps를 사용하여 컨테이너 디렉터리을 확인합니다.
    • docker exec --user root -ti container-id bash를 사용하여 컨테이너에 들어갑니다.

  • 로컬 머신에서 pod으로 파일을 복사하는 방법: 

    kubectl cp file-name pod-name:./destination-path

  • CrashLoopBackoff 상태의 pod에 대한 조치 방법:

    • 쿠버네티스 대시보드를 통해 로그를 확인합니다.

    • Kubectl을 사용하여 로그를 확인합니다: 

      kubectl logs <webservice pod> -c dependencies

  • 실시간으로 모든 쿠버네티스 클러스터 이벤트를 추적하는 방법: 

    kubectl get events -w --all-namespaces

  • 이전에 종료된 pod 인스턴스의 로그를 가져오는 방법: 

    kubectl logs <pod-name> --previous

    로그는 컨테이너/pod 자체에 저장되지 않습니다. 모든 것이 stdout로 기록됩니다. 이것이 쿠버네티스의 원칙이며 자세한 내용은 12요소 앱을 읽어보세요.

  • 클러스터에 구성된 크론 작업 가져오는 방법 

    kubectl get cronjobs

    크론 기반 백업을 구성하면 새로운 일정이 여기에 표시됩니다. 일정에 대한 일부 세부 정보는 크론 작업을 사용한 자동화된 작업 실행에서 찾을 수 있습니다.

GitLab 고유의 쿠버네티스 정보

  • 쿠버네티스 헬름 차트를 테스트하는 데 사용할 수 있는 최소 구성입니다.

  • 별도의 pod의 로그를 실시간으로 가져오기. webservice pod의 예: 

    kubectl logs gitlab-webservice-54fbf6698b-hpckq -c webservice

  • 동일한 레이블을 공유하는 모든 pod을 따라가기. (이 경우 webservice): 

    # webservice pod의 모든 컨테이너
kubectl logs -f -l app=webservice --all-containers=true --max-log-requests=50
  
# 모든 webservice pod의 webservice 컨테이너만
kubectl logs -f -l app=webservice -c webservice --max-log-requests=50

(이하 생략)

macOS에서 minikube를 사용한 최소 GitLab 구성 설치

이 섹션은 minikube를 사용한 Kubernetes 개발 및 Helm을 기반으로 합니다. 자세한 내용은 해당 문서를 참조하십시오.

  • Homebrew를 통해 Kubectl을 설치합니다. 

    brew install kubernetes-cli

  • Homebrew를 통해 minikube를 설치합니다. 

    brew cask install minikube

  • minikube를 시작하고 구성합니다. minikube를 시작할 수 없는 경우 minikube delete && minikube start 명령을 실행해보고 다음 단계를 반복하십시오. 

    minikube start --cpus 3 --memory 8192 # GitLab이 작동하는 데 필요한 최소한의 양
minikube addons enable ingress

  • Homebrew를 통해 Helm을 설치하고 초기화합니다. 

    brew install helm

  • minikube 최소값 YAML 파일을 워크스테이션으로 복사합니다. 

    curl --output values.yaml "https://gitlab.com/gitlab-org/charts/gitlab/raw/master/examples/values-minikube-minimum.yaml"

  • minikube ip 명령의 출력에서 IP 주소를 찾아 이 IP 주소로 YAML 파일을 업데이트합니다.

  • GitLab Helm 차트를 설치합니다. 

    helm repo add gitlab https://charts.gitlab.io
helm install gitlab -f <path-to-yaml-file> gitlab/gitlab

    GitLab 설정을 수정하려면 위에서 언급한 구성을 기반으로하여 고유한 YAML 파일을 만들 수 있습니다.

  • helm status gitlab 및 minikube dashboard를 통해 설치 진행 상황을 모니터링합니다. 워크스테이션의 리소스 양에 따라 설치에는 20-30분이 소요될 수 있습니다.

  • 모든 파드가 Running 또는 Completed 상태를 나타내면 초기 로그인에서 설명한 대로 GitLab 비밀번호를 가져와 UI를 통해 GitLab에 로그인합니다. 이는 YAML 파일에 제공된 값인 domain 뒤에 https://gitlab.domain을 통해 액세스할 수 있습니다.

toolbox 파드에서 Rails 코드를 패치하는 방법

caution
이 작업은 정기적으로 수행해서는 안 되는 작업입니다. 자체 책임 하에 사용하십시오.

운영 GitLab 서비스 파드를 패치하는 것은 수정된 소스 코드가 포함된 새 이미지를 빌드해야 합니다. 이들은 직접 패치할 수 없습니다. toolbox / task-runner 파드에는 다른 정상적인 서비스 작업에 간섭하지 않고 Rails 기반 파드로 작동하는 데 필요한 모든 것이 포함되어 있습니다. 이를 사용하여 독립적인 작업을 실행하고 일시적으로 소스 코드를 수정하여 일부 작업을 수행할 수 있습니다.

note
toolbox 파드를 사용하여 변경 사항을 만든 경우, 해당 변경 사항은 파드를 다시 시작해도 유지되지 않습니다. 이러한 변경 사항은 컨테이너 작동 기간 동안에만 존재합니다.

toolbox 파드에서 소스 코드를 패치하는 방법:

  1. 적용할 원하는 .patch 파일을 가져옵니다:

    • Merge Request의 차이(diff)를 패치 파일로 다운로드하거나

    • curl을 사용하여 차이(diff)를 직접 가져옵니다. 아래의 <mr_iid>를 Merge Request의 IID로 대체하거나 URL을 수정하여 원시 스니펫을 가리키도록 합니다. 

      curl --output ~/<mr_iid>.patch "https://gitlab.com/gitlab-org/gitlab/-/merge_requests/<mr_iid>.patch"

  2. toolbox 파드의 로컬 파일을 패치합니다: 

     cd /srv/gitlab
 busybox patch -p1 -f < ~/<mr_iid>.patch