Kubernetes 클러스터는 배포 job의 대상이 될 수 있습니다. 다음 경우에:

• 클러스터가 GitLab과 통합된 경우 특별한 배포 변수가 job에서 사용 가능하며 별도의 구성이 필요하지 않습니다. kubectl 또는 helm과 같은 도구를 사용하여 job에서 클러스터와 즉시 상호 작용을 시작할 수 있습니다.
• GitLab 클러스터 통합을 사용하지 않는 경우에도 클러스터에 배포할 수 있습니다. 그러나 job에서 클러스터와 상호 작용하기 전에 CI/CD 변수를 사용하여 Kubernetes 도구를 직접 구성해야 합니다.

배포 변수#

배포 변수에는 gitlab-deploy-token이라는 유효한 배포 토큰이 필요하며, Kubernetes가 레지스트리에 액세스하기 위해 배포 job 스크립트에 다음 명령어가 필요합니다:

• 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 빌드 환경에서 배포 job에 대해 이러한 배포 변수를 노출합니다. 배포 job에는 대상 환경이 정의되어 있습니다.

커스텀 네임스페이스#

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

다음 몇 가지 방법으로 배포 네임스페이스를 사용자 정의할 수 있습니다:

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

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

자격 증명 보호#

기본적으로 배포 job을 생성할 수 있는 누구든지 환경의 배포 job에서 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 권한이 있어야 합니다. 지원은 환경의 첫 번째 파드에 있는 첫 번째 컨테이너로 제한됩니다.

트러블슈팅#

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

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

그러나 때로는 GitLab이 이를 생성하지 못할 수 있습니다. 그런 경우 job이 다음 메시지와 함께 실패할 수 있습니다:

This job failed because the necessary resources were not successfully created.

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

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

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