쿠버네티스 치트 시트

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

이것은 GitLab 지원팀이 가끔씩 문제 해결 중에 사용하는 Kubernetes에 관련된 유용한 정보 목록입니다. GitLab은 이를 공개함으로써 누구나 지원팀이 수집한 지식을 활용할 수 있도록 합니다.

경고: 이 명령어들은 귀하의 Kubernetes 구성요소를 변경하거나 손상시킬 수 있으므로, 자기 책임 하에 사용하십시오.

만약 유료 티어에 속해 있고, 이러한 명령어들을 어떻게 사용해야 할지 확신이 없다면, 지원팀에 문의하여 문제를 해결할 수 있도록 도움을 요청하세요.

일반적인 Kubernetes 명령어

  • GCP 프로젝트에 인증하는 방법 (특히 서로 다른 GCP 계정에 프로젝트가 있는 경우 유용): 

    gcloud auth login

  • Kubernetes 대시보드에 액세스하는 방법: 

    # minikube를 사용하는 경우:
minikube dashboard —url
# 로컬이 아닌 설치에서 Kubectl을 통해 액세스하는 경우:
kubectl proxy

  • Kubernetes 노드로 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를 처리하는 방법:

    • Kubernetes 대시보드를 통해 로그를 확인합니다.

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

      kubectl logs <webservice pod> -c dependencies

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

    kubectl get events -w --all-namespaces

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

    kubectl logs <pod-name> --previous

    로그는 컨테이너/팟 자체에 저장되지 않습니다. 모든 것은 stdout에 작성됩니다. 이것이 Kubernetes의 원칙이며, 자세한 내용은 12요소 앱을 읽어보세요.

  • 클러스터에서 구성된 cron job 가져오는 방법 

    kubectl get cronjobs

    cron 기반 백업을 구성하면 여기서 새로운 일정을 볼 수 있습니다. 일정에 관한 일부 세부 정보는 CronJob를 사용하여 자동화된 작업 실행에서 찾을 수 있습니다.

GitLab과 관련된 Kubernetes 정보

  • 별도의 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

  • 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 pod 안에 있습니다. 이 안에 들어가 명령어를 실행하거나 외부에서 실행할 수 있습니다. 

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

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

# GitLab 체크 실행하기. 특정 helm 차트를 통해 설치된 GitLab의 특정 구조 때문에 출력이 혼란스러울 수 있습니다.
gitlab-rake gitlab:check

# pod에 들어가지 않고 콘솔 열기
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 네임스페이스 내의 pod 로그 확인

  • 초기 관리자 비밀번호 가져오는 방법 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 파일에 리다이렉트 하기 (gitlab.rb 값의 유사한 부분)
helm get values <release name> > gitlab.yaml

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

    또한 Helm 차트를 사용한 GitLab 업데이트를 참조하세요.

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

    • gitlab.yaml 파일 수정.

    • 변경 사항 적용하려면 다음 명령어 실행: 

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

  • 릴리스에 대한 매니페스트 가져오는 방법. 모든 Kubernetes 리소스 및 종속 차트에 대한 정보를 포함하므로 유용할 수 있습니다: 

    helm get manifest <release name>

KubeSOS 보고서의 Fast-Stats

KubeSOS는 GitLab 클러스터 구성 및 GitLab 클라우드 네이티브 차트 배포에서 로그를 수집하는 도구입니다. 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 구성 설치

이 섹션은 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에 로그인합니다. 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