Kubernetes 클러스터에 클러스터 인증서로 배포 (사용 중지됨)
- 사용 중닷됨 GitLab 14.5에서.
경고: 이 기능은 GitLab 14.5에서 사용이 중단되었습니다. 클러스터를 GitLab에 연결하려면 GitLab 에이전트를 사용하세요. 에이전트를 사용하여 배포하려면 CI/CD workflow를 사용하세요.
Kubernetes 클러스터는 배포 작업의 대상이 될 수 있습니다. 만약
- 클러스터가 GitLab과 통합되어 있다면, 특별한
배포 변수가 작업에 제공되며
구성이 필요하지 않습니다.
kubectl또는helm과 같은 도구를 사용하여 즉시 작업에서 클러스터와 상호 작용할 수 있습니다. - GitLab 클러스터 통합을 사용하지 않는다면, 여전히 클러스터에 배포할 수 있습니다. 그러나 작업에서 클러스터와 상호 작용할 수 있도록 CI/CD 변수를 구성해야 합니다.
배포 변수
배포 변수는 유효한 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 빌드 환경에서 배포 작업으로 노출합니다. 배포 작업에는 대상 환경이 정의되어 있습니다.
| 배포 변수 | 설명 |
|————————|——|
| KUBE_URL | API URL과 동일합니다. |
| KUBE_TOKEN | 환경 서비스 계정의 Kubernetes 토큰입니다. |
| KUBE_NAMESPACE | 프로젝트 배포 서비스 계정과 관련된 네임스페이스입니다. <project_name>-<project_id>-<environment> 형식입니다.
GitLab 관리 클러스터의 경우, GitLab에서 클러스터에 자동으로 일치하는 네임스페이스가 생성됩니다.
클러스터가 GitLab 12.2보다 이전에 생성되었으면, 기본 KUBE_NAMESPACE은 <project_name>-<project_id>로 설정됩니다. |
| KUBE_CA_PEM_FILE | PEM 데이터를 포함하는 파일의 경로입니다. 사용자 지정 CA 번들이 지정된 경우에만 나타납니다. |
| KUBE_CA_PEM | (사용 중닷됨) Raw PEM 데이터입니다. 사용자 지정 CA 번들이 지정된 경우에만 나타납니다. |
| KUBECONFIG | 이 배포에 대한 kubeconfig가 있는 파일의 경로입니다. 사용자 지정 CA 번들이 지정된 경우에는 내장됩니다.
이 구성은 KUBE_TOKEN에 정의된 동일한 토큰도 내장되므로 이 변수만 필요할 수 있습니다. 이 변수 이름은 kubectl에서 자동으로
선택되므로 kubectl을 사용하는 경우 명시적으로 참조할 필요가 없습니다. |
| KUBE_INGRESS_BASE_DOMAIN | 이 변수는 클러스터당 도메인을 설정하는 데 사용할 수 있습니다. 자세한 내용은 클러스터 도메인을 참조하십시오. |
사용자 정의 네임스페이스
Kubernetes 통합은 배포 작업에 자동 생성된 네임스페이스와 KUBECONFIG를 제공합니다.
기본적으로 프로젝트-환경별 특정 네임스페이스인 <prefix>-<environment> 형식을 사용합니다.
여기서 <prefix>는 <project_name>-<project_id> 형식입니다. 자세한 내용은 Deployment variables을 참조하십시오.
네임스페이스를 사용자 정의할 수 있는 몇 가지 방법이 있습니다:
- 환경별 네임스페이스 당 네임스페이스 또는 프로젝트 당 네임스페이스 중 하나를 선택할 수 있습니다. 환경별 네임스페이스를 사용하는 것이 기본 설정이며 권장됩니다. 이렇게 하면 프로덕션 환경과 비프로덕션 환경 간의 리소스 혼합을 방지합니다.
- 프로젝트 수준 클러스터를 사용하는 경우, 네임스페이스 접두사를 추가로 사용자 정의할 수 있습니다.
환경별 네임스페이스를 사용할 때, 배포 네임스페이스는
<prefix>-<environment>이지만 그렇지 않은 경우 단순히<prefix>입니다. -
관리되지 않는 클러스터의 경우, 자동 생성된 네임스페이스가
KUBECONFIG에 설정되지만 사용자는 해당 존재를 보장해야 합니다..gitlab-ci.yml에서environment:kubernetes:namespace를 사용하여 이 값을 완전히 사용자 정의할 수 있습니다.
네임스페이스를 사용자 정의하면 기존 환경은 현재 네임스페이스에 연결된 상태입니다. 클러스터 캐시를 지우기 전까지 기존 환경은 현재 네임스페이스에 연결된 상태로 유지됩니다.
자격 증명 보호
기본적으로 배포 작업을 생성할 수 있는 모든 사용자는
환경의 배포 작업에서 사용 가능한 모든 CI/CD 변수에 액세스할 수 있습니다. 이에는
연결된 서비스 계정에 사용 가능한 모든 비밀번호에 액세스할 수 있는 KUBECONFIG도 포함됩니다.
프로덕션 자격 증명을 안전하게 유지하려면
보호된 환경을 사용하고 다음 중 하나를 사용할 수 있습니다:
- GitLab에서 관리하는 클러스터 및 환경별 네임스페이스.
- 보호된 환경당 환경별 클러스터. 동일한 클러스터가 다수의 제한된 서비스 계정으로 여러 번 추가될 수 있습니다.
Kubernetes 클러스터용 웹 터미널
Kubernetes 통합은 환경에 웹 터미널 지원을 추가합니다.
이는 Docker 및 Kubernetes에서 찾을 수 있는 exec 기능을 기반으로 하므로 기존 컨테이너에서 새 쉘 세션을 제공합니다.
이 통합을 사용하려면 상기한 배포 변수를 사용하여 Kubernetes에 배포해야 하며, 배포, 레플리카 세트 및 팟이 다음과 같이 주석이 달려 있어야 합니다:
app.gitlab.com/env: $CI_ENVIRONMENT_SLUGapp.gitlab.com/app: $CI_PROJECT_PATH_SLUG
$CI_ENVIRONMENT_SLUG 및 $CI_PROJECT_PATH_SLUG은
CI/CD 변수의 값입니다.
프로젝트 소유자이거나 maintainer 권한이 있어야 합니다. 지원은 환경의 첫 번째 팟의 첫 번째 컨테이너에 한정됩니다.
문제 해결
배포 작업이 시작되기 전에 GitLab은 배포 작업을 위해 다음을 특별히 생성합니다:
- 네임스페이스
- 서비스 계정
그러나 때때로 GitLab이 이를 생성하지 못할 수 있습니다. 이러한 경우에는 작업이 다음과 같은 메시지와 함께 실패할 수 있습니다:
이 작업이 실패했습니다. 필요한 리소스가 성공적으로 생성되지 않았기 때문입니다.
네임스페이스 및 서비스 계정을 생성하는 중에이 오류의 원인을 찾으려면 로그를 확인하세요.
실패의 이유는 다음과 같습니다:
- GitLab이 필요로 하는
cluster-admin권한이 제공한 토큰에 없는 경우. -
KUBECONFIG또는KUBE_TOKEN배포 변수가 누락된 경우. 작업에 전달되기 위해서는environment:name과 일치해야 합니다. 작업에environment:name이 설정되어 있지 않은 경우 Kubernetes 자격 증명이 전달되지 않습니다.
참고: GitLab 12.0 이전의 프로젝트 수준 클러스터가 설정되어 있다면 이러한 오류를 발생시킬 수 있습니다. 네임스페이스 및 서비스 계정을 직접 관리하려는 경우 GitLab 관리 클러스터 옵션을 해제했는지 확인하세요.
도움말