쿠버네티스 치트 시트

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

이것은 GitLab 지원 팀이 문제를 해결하는 동안 때때로 사용하는 쿠버네티스에 대한 유용한 정보 목록입니다. GitLab은 이 정보를 공개하여 누구나 지원 팀이 수집한 지식을 활용할 수 있도록 하고 있습니다.

경고:
이 명령어는 쿠버네티스 구성 요소를 변경하거나 손상을 줄 수 있으므로 사용자는 자신의 책임 하에 사용해야 합니다.

유료 계정에 가입되어 있고 이러한 명령어 사용 방법을 잘 모르는 경우, 지원팀에 연락하는 것이 가장 좋습니다 그들이 여러분이 겪고 있는 문제를 도와줄 것입니다.

일반 쿠버네티스 명령어

  • 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로 컨테이너에 들어갑니다.

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

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

  • CrashLoopBackoff 상태의 포드에서 할 일:

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

    • Kubectl을 통해 로그를 확인합니다:

      kubectl logs <webservice pod> -c dependencies

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

    kubectl get events -w --all-namespaces

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

    kubectl logs <pod-name> --previous

    컨테이너/포드 자체에는 로그가 저장되지 않습니다. 모든 내용은 stdout에 기록됩니다.
    이것은 쿠버네티스의 원칙으로, 자세한 내용은 Twelve-factor app을 참조하세요.

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

    kubectl get cronjobs

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

GitLab 전용 쿠버네티스 정보

  • 별도의 포드의 로그를 테일링하는 방법. webservice 포드에 대한 예:

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

  • 레이블을 공유하는 모든 포드의 로그를 테일 및 팔로우하는 방법(이 경우, webservice):

    # 웹 서비스 포드의 모든 컨테이너
kubectl logs -f -l app=webservice --all-containers=true --max-log-requests=50

# 모든 웹 서비스 포드 중에서 웹 서비스 컨테이너만
kubectl logs -f -l app=webservice -c webservice --max-log-requests=50

  • 모든 컨테이너에서 로그를 동시에 스트리밍할 수 있는 방법, 이는 Linux 패키지 설치에서의 gitlab-ctl tail 명령과 유사합니다:

    kubectl logs -f -l release=gitlab --all-containers=true --max-log-requests=100

  • gitlab 네임스페이스 내의 모든 이벤트를 확인하는 방법(네임스페이스 이름은 Helm 차트를 배포할 때 다른 이름을 지정했다면 다를 수 있습니다):

    kubectl get events -w --namespace=gitlab

  • 유용한 GitLab 도구(콘솔, Rake 작업 등)는 toolbox 포드에 있습니다. 이를 들어가서 내부에서 명령어를 실행하거나 외부에서 실행할 수 있습니다.

    # 포드 찾기
kubectl --namespace gitlab get pods -lapp=toolbox

# Rails 콘솔 열기
kubectl --namespace gitlab exec -it -c toolbox <toolbox-pod-name> -- gitlab-rails console

# GitLab 체크 실행. 출력은 헬름 차트를 통해 설치된 GitLab의 특정 구조로 인해 혼란스럽고 잘못될 수 있습니다.
gitlab-rake gitlab:check

# 포드에 들어가지 않고 콘솔 열기
kubectl exec -it <toolbox-pod-name> -- gitlab-rails console

# DB 마이그레이션 상태 확인
kubectl exec -it <toolbox-pod-name> -- gitlab-rake db:migrate:status

  • Infrastructure > Kubernetes clusters 통합 문제 해결:

    • kubectl get events -w --all-namespaces의 출력을 확인합니다.
    • gitlab-managed-apps 네임스페이스 내의 포드 로그를 확인합니다.

  • 초기 관리자 비밀번호를 가져오는 방법 https://docs.gitlab.com/charts/installation/deployment.html#initial-login:

    # 비밀번호가 포함된 비밀의 이름 찾기
kubectl get secrets | grep initial-root
# 디코드하기
kubectl get secret <secret-name> -ojsonpath={.data.password} | base64 --decode ; echo

  • GitLab PostgreSQL 데이터베이스에 연결하는 방법.

    kubectl exec -it <toolbox-pod-name> -- gitlab-rails dbconsole --include-password --database main

  • Helm 설치 상태에 대한 정보를 얻는 방법:

    helm status <release name>

  • Helm 차트를 사용하여 설치한 GitLab을 업데이트하는 방법:

    helm repo update

# 현재 값을 가져와 yaml 파일로 리디렉션(analogue of gitlab.rb values)
helm get values <release name> > gitlab.yaml

# 업그레이드 실행
helm upgrade <release name> <chart path> -f gitlab.yaml

    GitLab을 Helm 차트를 사용하여 업데이트하는 방법에 대한 내용은 여기를 참조하세요.

  • GitLab 구성 변경 사항을 적용하는 방법:

    • gitlab.yaml 파일을 수정합니다.

    • 다음 명령어를 실행하여 변경 사항을 적용합니다:

      helm upgrade <release name> <chart path> -f gitlab.yaml

  • 릴리스의 매니페스트를 가져오는 방법. 이는 모든 쿠버네티스 리소스 및 종속 차트에 대한 정보를 포함하고 있어 유용할 수 있습니다:

    helm get manifest <release name>

KubeSOS 보고서용 Fast-Stats

KubeSOS는 GitLab 클러스터 구성 및 GitLab Cloud Native 차트 배포에서 로그를 수집하는 도구입니다. fast-stats는 최소한의 메모리 사용으로 GitLab 로그에서 성능 통계를 신속하게 생성하고 비교할 수 있는 도구입니다.

  • fast-stats 실행:

    cut -d  ' ' -f2- <file-name> | grep ^{ | fast-stats

  • 오류 목록:

    cut -d  ' ' -f2- <file-name> | grep ^{ | fast-stats errors

  • fast-stats top 실행:

    cut -d  ' ' -f2- <file-name> | grep ^{ | fast-stats top

  • 출력되는 행의 수를 변경하세요. 기본적으로 10행이 출력됩니다.

    cut -d  ' ' -f2- <file-name> | grep ^{ | fast-stats -l <number of rows>

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

이 섹션은 Kubernetes용 minikube 개발과 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 주소를 찾아 YAML 파일을 이 IP 주소로 업데이트합니다.

  • 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에 로그인합니다. https://gitlab.domain을 통해 접근할 수 있으며, 여기서 domain은 YAML 파일에 제공된 값입니다.

toolbox 팟에서 Rails 코드 패칭

경고:
이 작업은 정기적으로 수행해야 하는 것이 아닙니다. 사용 시 주의하시기 바랍니다.

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

주의:
toolbox 팟을 사용하여 변경한 내용은 팟이 재시작되면 유지되지 않습니다. 이는 컨테이너 운영 기간 동안만 존재합니다.

toolbox 팟의 소스 코드를 패칭하려면:

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

    • 병합 요청의 차이를 패치 파일로 직접 다운로드합니다.

    • 또는, curl을 사용하여 차이를 직접 가져옵니다. 아래 <mr_iid>를 병합 요청의 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