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

쿠버네티스 클러스터로 인증서와 함께 배포하기(사용 중지)

• GitLab 14.5에서 사용 중지되었습니다.

배포 변수

배포 변수는 유효한 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 클러스터 통합은 이러한 배포 변수를 CI/CD 빌드 환경에서 배포 작업에 노출시킵니다. 배포 작업은 대상 환경을 정의했습니다.

사용자 정의 네임스페이스

• GitLab 12.6에서 도입되었습니다.
• 프로젝트 전반적인 네임스페이스를 사용하는 옵션이 GitLab 13.5에서 추가되었습니다.

Kubernetes 통합은 배포 작업에 자동으로 생성된 네임스페이스를 포함한 KUBECONFIG를 제공합니다. 기본적으로 <prefix>-<environment> 형식의 프로젝트-환경별 특정 네임스페이스 사용을 기본으로 하며, 여기서 <prefix>은 <project_name>-<project_id> 형식입니다. 자세한 내용은 Deployment variables를 참조하세요.

네임스페이스를 사용자 정의하는 방법은 다음과 같습니다:

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

네임스페이스를 사용자 정의하면 기존의 환경은 해당 현재 네임스페이스에 연결된 채로 유지됩니다(이를 통해 클러스터 캐시를 지우기 전까지).

자격 증명 보호

기본적으로 배포 작업을 만들 수 있는 모든 사람은 환경의 배포 작업에서 사용 가능한 모든 CI/CD 변수에 액세스할 수 있습니다. 이는 클러스터의 연결된 서비스 계정에 사용 가능한 모든 비밀번호에 액세스할 수 있는 KUBECONFIG를 포함합니다. 프로덕션 자격 증명을 안전하게 유지하려면 protected environments와 함께 다음 중 하나를 고려하세요:

• GitLab에서 관리되는 클러스터 및 환경별 네임스페이스.
• 비보안 환경용으로 제한된 서비스 계정을 가지고 있는 환경별 클러스터. 동일한 클러스터를 여러 번 추가해서 여러 제한된 서비스 계정을 사용할 수 있습니다.

Kubernetes 클러스터용 Web 터미널

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이 이를 생성하지 못할 수 있습니다. 그러한 경우에는 다음 메시지로 작업이 실패할 수 있습니다:

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

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

오류의 원인은 다음과 같습니다:

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