쿠버네티스 클러스터에 클러스터 인증서로 배포(Deprecated)
Offering: GitLab.com, Self-Managed
- Deprecated in GitLab 14.5.
쿠버네티스 클러스터는 배포 작업의 대상이 될 수 있습니다. 만약,
- 클러스터가 GitLab과 통합된 경우, 특별한
배포 변수가 작업에 사용할 수 있고
구성이 필요하지 않습니다.
kubectl
이나helm
과 같은 도구를 사용하여 즉시 작업에서 클러스터와 상호 작용을 시작할 수 있습니다. - GitLab 클러스터 통합을 사용하지 않는다면, 클러스터에 배포할 수 있습니다. 그러나 작업에서 클러스터와 상호 작용하기 전에 직접 Kubernetes 도구를 구성해야 합니다. 프로젝트를 위한 CI/CD 변수 을 사용하여 준비를 해야 합니다.
배포 변수
배포 변수는 유효한 배포 토큰인
gitlab-deploy-token
및
레지스트리 접근을 위한 다음 명령어가 배포 작업 스크립트에 필요합니다.
-
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 -
쿠버네티스 클러스터 통합은 배포 변수를 GitLab CI/CD 빌드 환경에서 배포 작업에 노출시킵니다. 배포 작업은 대상 환경을 정의했습니다.
배포 변수 | 설명 |
---|---|
KUBE_URL
| API URL과 동일합니다. |
KUBE_TOKEN
|
환경 서비스 계정의 Kubernetes 토큰입니다. GitLab 11.5 이전에는 KUBE_TOKEN 이 클러스터 통합의 주요 서비스 계정의 Kubernetes 토큰이었습니다.
|
KUBE_NAMESPACE
| 프로젝트의 배포 서비스 계정에 관련된 네임스페이스입니다. 형식은 <프로젝트 이름>-<프로젝트 ID>-<환경> 입니다. GitLab에서 관리하는 클러스터의 경우, GitLab은 클러스터에 자동으로 해당하는 네임스페이스를 만들 것입니다. 만약 클러스터가 GitLab 12.2 이전에 생성되었다면, 기본 KUBE_NAMESPACE 은 <프로젝트 이름>-<프로젝트 ID> 로 설정됩니다.
|
KUBE_CA_PEM_FILE
| PEM 데이터가 포함 된 파일의 경로입니다. 사용자 정의 CA 번들이 지정된 경우에만 존재합니다. |
KUBE_CA_PEM
| (deprecated) Raw PEM 데이터입니다. 사용자 정의 CA 번들이 지정된 경우에만 존재합니다. |
KUBECONFIG
| 이 배포를 위한 kubeconfig 가 들어 있는 파일의 경로입니다. 사용자가 지정한 경우 CA 번들이 포함됩니다. 이 구성은 KUBE_TOKEN 에서 정의한 동일한 토큰이 내장되어 있으므로 이 변수만 사용할 가능성이 높습니다. 또한 이 변수 이름은 kubectl 에서 자동으로 선택되므로 kubectl 을 사용하는 경우 명시적으로 참조할 필요가 없습니다.
|
KUBE_INGRESS_BASE_DOMAIN
| GitLab 11.8부터 이 변수는 클러스터 당 도메인을 설정하는 데 사용할 수 있습니다. 자세한 정보는 클러스터 도메인을 참조하십시오. |
사용자 정의 네임스페이스
쿠버네티스 통합은 배포 작업에 자동으로 생성된 네임스페이스와 함께 KUBECONFIG
를 제공합니다.
기본적으로 <접두어>-<환경>
형식의 프로젝트-환경별 네임스페이스를 사용합니다.
더 많은 정보는 배포 변수를 참조하십시오.
네임스페이스를 사용자 정의하는 몇 가지 방법이 있습니다.
- 환경당 네임스페이스 사이에서 선택할 수 있습니다. 환경별 네임스페이스는 기존 환경 간의 리소스 섞임을 방지하므로 기본 설정이고 권장되는 설정입니다.
- 프로젝트 수준 클러스터를 사용하는 경우 네임스페이스 접두사를 추가적으로 사용자 정의할 수 있습니다.
환경 별 네임스페이스를 사용하는 경우, 배포 네임스페이스는
<접두어>-<환경>
이지만 다른 경우에는<접두어>
만 됩니다. -
관리되지 않는 클러스터의 경우, 자동으로 생성된 네임스페이스가
KUBECONFIG
에 설정되지만 사용자가 존재 여부를 보장해야 합니다. 이 값을.gitlab-ci.yml
에서environment:kubernetes:namespace
를 사용하여 완전히 사용자 정의할 수 있습니다.
네임스페이스를 사용자 정의할 때 기존 환경은 클러스터 캐시를 지워야만 현재 네임스페이스에 연결된 상태로 남아 있습니다.
자격 증명 보호
기본적으로 배포 작업을 생성할 수 있는 사용자는 해당 환경의 배포 작업에 있는 모든 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이 이를 생성할 수 없을 수 있습니다. 이러한 경우에는 작업에서 다음과 같은 메시지와 함께 실패할 수 있습니다:
This job failed because the necessary resources were not successfully created.
네임스페이스 및 서비스 계정을 생성하는 동안이 오류의 원인을 찾으려면 로그를 확인하세요.
오류의 원인은 다음과 같습니다:
- GitLab이 필요로 하는
cluster-admin
권한이 토큰에 없습니다. -
KUBECONFIG
또는KUBE_TOKEN
배포 변수가 누락되었습니다. 작업에 전달하려면 해당 변수들은 일치하는environment:name
이 있어야 합니다. 작업에environment:name
이 설정되지 않으면 Kubernetes 자격 증명이 전달되지 않습니다.
참고: GitLab 12.0이나 이전 버전에서 업그레이드된 프로젝트 수준 클러스터는 이 오류를 일으키는 방식으로 구성될 수 있습니다. 네임스페이스와 서비스 계정을 직접 관리하려면 GitLab 관리 클러스터 옵션을 해제해야 합니다.