• 배포 변수
• 사용자 정의 네임스페이스
  • 자격 증명 보호
• Kubernetes 클러스터의 웹 터미널
• 문제 해결

Kubernetes 클러스터에 클러스터 인증서로 배포하기 (deprecated)

• GitLab 14.5에서 사용 중단됨.

Kubernetes 클러스터는 배포 작업의 대상이 될 수 있습니다.

• 클러스터가 GitLab과 통합되어 있다면, 특별한
  배포 변수가 작업에 제공되며
  설정이 필요하지 않습니다. kubectl이나 helm과 같은 도구를 사용하여
  작업에서 클러스터와 즉시 상호작용을 시작할 수 있습니다.

• GitLab 클러스터 통합을 사용하지 않는 경우에도
  여전히 클러스터에 배포할 수 있습니다. 그러나
  클러스터에서 작업과 상호작용하기 전에
  CI/CD 변수를 사용하여
  Kubernetes 도구를 직접 설정해야 합니다.

배포 변수

배포 변수는 유효한 Deploy Token인
gitlab-deploy-token을 요구하며,
Kubernetes가 레지스트리에 접근하기 위해 배포 작업 스크립트에 다음 명령어가 필요합니다:

• Kubernetes 1.18+를 사용하는 경우:

  kubectl create secret docker-registry gitlab-registry --docker-server="$CI_REGISTRY" --docker-username="$CI_DEPLOY_USER" --docker-password="$CI_DEPLOY_PASSWORD" --docker-email="$GITLAB_USER_EMAIL" -o yaml --dry-run=client | kubectl apply -f -  
  

• Kubernetes <1.18을 사용하는 경우:

  kubectl create secret docker-registry gitlab-registry --docker-server="$CI_REGISTRY" --docker-username="$CI_DEPLOY_USER" --docker-password="$CI_DEPLOY_PASSWORD" --docker-email="$GITLAB_USER_EMAIL" -o yaml --dry-run | kubectl apply -f -  
  

Kubernetes 클러스터 통합은 이러한
배포 변수를
GitLab CI/CD 빌드 환경의 배포 작업에 노출합니다. 배포 작업에는
정의된 대상 환경이 있습니다.

사용자 정의 네임스페이스

Kubernetes 통합은 배포 작업에 자동 생성된 네임스페이스가 있는 KUBECONFIG 를 제공합니다. 이는 <prefix>-<environment> 형식의 프로젝트-환경 특화 네임스페이스를 사용하는 것이 기본값이며, 여기서 <prefix>는 <project_name>-<project_id> 형식입니다. 자세한 내용은 배포 변수를 참조하세요.

배포 네임스페이스는 여러 방법으로 사용자 정의할 수 있습니다:

• 환경별 네임스페이스와 프로젝트별 네임스페이스 중 하나를 선택할 수 있습니다. 환경별 네임스페이스가 기본값이며 권장 설정으로, 이는 프로덕션 환경과 비프로덕션 환경 간의 리소스 혼합을 방지합니다.
• 프로젝트 수준의 클러스터를 사용하는 경우, 네임스페이스 접두사를 추가로 사용자 정의할 수 있습니다. 환경별 네임스페이스를 사용하는 경우, 배포 네임스페이스는 <prefix>-<environment>이지만, 그렇지 않으면 단순히 <prefix>입니다.
• 비관리 클러스터의 경우 자동 생성된 네임스페이스는 KUBECONFIG에 설정되지만, 사용자가 그 존재를 보장할 책임이 있습니다. 이 값을 완전히 사용자 정의할 수 있으며, environment:kubernetes:namespace 를 .gitlab-ci.yml에서 사용할 수 있습니다.

네임스페이스를 사용자 정의하면 기존 환경은 클러스터 캐시를 지우기 전까지 현재 네임스페이스에 연결된 상태를 유지합니다.

자격 증명 보호

기본적으로 배포 작업을 생성할 수 있는 사람은 환경의 배포 작업 내 모든 CI/CD 변수를 접근할 수 있습니다. 여기에는 KUBECONFIG가 포함되어 있으며, 이는 클러스터의 관련 서비스 계정에 접근할 수 있는 모든 비밀에 대한 접근을 제공합니다.

프로덕션 자격 증명을 안전하게 유지하려면 보호된 환경과 다음 중 하나를 결합하여 사용하는 것을 고려하세요:

• GitLab 관리 클러스터와 환경별 네임스페이스.
• 보호된 환경별 환경 범위 클러스터. 동일한 클러스터를 여러 번 추가하고 여러 제한된 서비스 계정을 사용할 수 있습니다.

Kubernetes 클러스터의 웹 터미널

Kubernetes 통합은 환경에서 웹 터미널 지원을 추가합니다. 이는 Docker 및 Kubernetes에서 발견되는 exec 기능을 기반으로 하며, 기존 컨테이너에서 새 셸 세션을 제공합니다. 이 통합을 사용하려면, 위의 배포 변수를 사용하여 Kubernetes에 배포해야 하며, 모든 배포, 복제 세트 및 파드에 다음을 주석으로 추가해야 합니다:

• app.gitlab.com/env: $CI_ENVIRONMENT_SLUG
• app.gitlab.com/app: $CI_PROJECT_PATH_SLUG

$CI_ENVIRONMENT_SLUG 및 $CI_PROJECT_PATH_SLUG는 CI/CD 변수의 값입니다.

터미널을 사용하려면 프로젝트 소유자이거나 maintainer 권한이 있어야 합니다.

지원은 환경의 첫 번째 파드에 있는 첫 번째 컨테이너로 제한됩니다.

문제 해결

배포 작업이 시작되기 전에 GitLab은 배포 작업을 위해 다음을 생성합니다:

• 네임스페이스.
• 서비스 계정.

그러나 때때로 GitLab은 이를 생성할 수 없습니다. 이러한 경우 작업은 다음과 같은 메시지와 함께 실패할 수 있습니다:

이 작업은 필요한 리소스가 성공적으로 생성되지 않았기 때문에 실패했습니다.

네임스페이스 및 서비스 계정을 생성할 때 이 오류의 원인을 찾으려면 로그를 확인하세요.

실패 이유는 다음과 같습니다:

• GitLab에 제공한 토큰이 GitLab에 필요한 cluster-admin 권한이 없습니다.
• KUBECONFIG 또는 KUBE_TOKEN 배포 변수가 누락되었습니다. 작업에 전달되려면, 이들은 일치하는 environment:name이 있어야 합니다. 작업에 environment:name이 설정되어 있지 않으면 Kubernetes 자격 증명이 전달되지 않습니다.

노트: GitLab 12.0 이하에서 업그레이드된 프로젝트 수준의 클러스터는 이 오류를 발생시키는 방식으로 구성될 수 있습니다. 네임스페이스 및 서비스 계정을 직접 관리하고 싶다면 GitLab 관리 클러스터 옵션을 지우십시오.