기존 클러스터를 클러스터 인증서를 통해 연결 (사용 중지됨)
- 사용 중지됨 GitLab 14.5부터.
기존의 Kubernetes 클러스터가 있는 경우, 해당 클러스터를 프로젝트, 그룹 또는 인스턴스에 추가하여 GitLab의 통합 기능을 활용할 수 있습니다.
전제 조건
기존 클러스터를 GitLab에 추가하려면 아래 전제 조건을 확인하십시오.
모든 클러스터
GitLab에 어떤 클러스터를 추가하기 위해서는 다음이 필요합니다:
- GitLab.com 계정 또는 GitLab 12.5 이상 버전을 실행 중인 자체 관리 설치용 계정 중 하나.
- 그룹 수준 및 프로젝트 수준 클러스터를 위한 관리자 역할.
- 인스턴스 수준 클러스터의 경우 Admin 영역에 대한 액세스 권한.
- Kubernetes 클러스터.
-
kubectl을 사용하여 클러스터에 대한 클러스터 관리 액세스.
클러스터를 EKS, GKE, 온프레미스 및 기타 공급업체에 호스팅할 수 있습니다. 온프레미스 및 다른 공급업체에 호스팅하려면 EKS 또는 GKE 방법을 사용하여 가이드를 따르고 클러스터 설정을 수동으로 입력하십시오.
경고:
GitLab은 arm64 클러스터를 지원하지 않습니다. 자세한 내용은 이슈 Helm Tiller fails to install on arm64 cluster에서 확인하십시오.
EKS 클러스터
기존의 EKS 클러스터를 추가하려면 다음이 필요합니다:
- 작동 노드가 올바르게 구성된 Amazon EKS 클러스터.
- EKS 클러스터에 액세스하기 위해
kubectl이 설치 및 구성되어 있어야 합니다. - 클러스터에 대한 관리자 권한이 있는 계정의 토큰을 확인하십시오.
GKE 클러스터
기존의 GKE 클러스터를 추가하려면 다음이 필요합니다:
- 클러스터 역할 바인딩을 생성하기 위한
container.clusterRoleBindings.create권한이 필요합니다. Google Cloud 문서를 참고하여 액세스 권한을 부여하십시오.
기존 클러스터 추가 방법
프로젝트, 그룹 또는 인스턴스에 Kubernetes 클러스터를 추가하려면 다음을 수행하십시오:
- 다음 위치로 이동하십시오:
- 프로젝트의 운영 > Kubernetes 클러스터 페이지, 프로젝트 수준 클러스터의 경우.
- 그룹의 Kubernetes 페이지, 그룹 수준 클러스터의 경우.
- 인스턴스의 Kubernetes 페이지, 인스턴스 수준 클러스터의 경우.
- Kubernetes 클러스터 페이지에서 작업 드롭다운 목록에서 인증서로 연결 옵션을 선택하십시오.
-
클러스터 연결 페이지에서 다음 세부 정보를 입력하십시오:
- Kubernetes 클러스터 이름 (필수) - 클러스터에 지정하려는 이름.
- 환경 범위 (필수) - 이 클러스터에 연결된 환경.
-
API URL (필수) - GitLab이 Kubernetes API에 액세스하는 데 사용하는 URL입니다. Kubernetes은 여러 API를 노출하는데, 우리는 모든 API에 공통인 “base” URL을 원합니다. 예를 들어
https://kubernetes.example.com/api/v1이 아닌https://kubernetes.example.com입니다.다음 명령어를 실행하여 API URL을 가져오십시오:
kubectl cluster-info | grep -E 'Kubernetes master|Kubernetes control plane' | awk '/http/ {print $NF}' -
CA 인증서 (필수) - 클러스터에 인증하기 위해 유효한 Kubernetes 인증서가 필요합니다. 우리는 기본적으로 생성된 인증서를 사용합니다.
-
kubectl get secrets명령을 사용하여 시크릿을 나열하고default-token-xxxxx와 유사한 이름의 시크릿 중 하나를 복사하십시오. -
다음 명령어를 실행하여 인증서를 가져오십시오:
kubectl get secret <secret name> -o jsonpath="{['data']['ca\.crt']}" | base64 --decode명령이 전체 인증서 체인을 반환하는 경우, 체인 파일에는 다음 구조가 있습니다:
-----BEGIN MY CERTIFICATE----- -----END MY CERTIFICATE----- -----BEGIN INTERMEDIATE CERTIFICATE----- -----END INTERMEDIATE CERTIFICATE----- -----BEGIN INTERMEDIATE CERTIFICATE----- -----END INTERMEDIATE CERTIFICATE----- -----BEGIN ROOT CERTIFICATE----- -----END ROOT CERTIFICATE-----
-
-
토큰 - GitLab은 Kubernetes에 서비스 토큰을 사용하여 인증하며, 이 토큰은 특정
namespace에 대한 범위가 지정됩니다. 사용된 토큰은cluster-admin권한이있는 서비스 계정에 속해야합니다. 이 서비스 계정을 만들려면:-
gitlab-admin-service-account.yaml이라는 파일을 만들고 다음 내용을 포함시킵니다:apiVersion: v1 kind: ServiceAccount metadata: name: gitlab namespace: kube-system --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: gitlab-admin roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-admin subjects: - kind: ServiceAccount name: gitlab namespace: kube-system -
서비스 계정 및 클러스터 역할 바인딩을 클러스터에 적용하십시오:
kubectl apply -f gitlab-admin-service-account.yaml클러스터 수준 역할을 만들기 위해서
container.clusterRoleBindings.create권한이 필요합니다. 이 권한이 없는 경우 Basic Authentication을 활성화한 다음 관리자로서kubectl apply명령을 실행할 수도 있습니다:kubectl apply -f gitlab-admin-service-account.yaml --username=admin --password=<password>참고: Basic Authentication을 활성화하고 비밀 번호 자격 증명을 얻을 수 있습니다. Google Cloud 콘솔에서 작업하십시오.
출력:
serviceaccount "gitlab" created clusterrolebinding "gitlab-admin" created -
gitlab서비스 계정의 토큰을 검색하십시오:kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | grep gitlab | awk '{print $1}')출력에서
<authentication_token>값을 복사하십시오:Name: gitlab-token-b5zv4 Namespace: kube-system Labels: <none> Annotations: kubernetes.io/service-account.name=gitlab kubernetes.io/service-account.uid=bcfe66ac-39be-11e8-97e8-026dce96b6e8 Type: kubernetes.io/service-account-token Data ==== ca.crt: 1025 bytes namespace: 11 bytes token: <authentication_token>
-
- GitLab 관리 클러스터 - 이 옵션을 선택한 경우, GitLab이 이 클러스터를 위해 네임스페이스와 서비스 계정을 관리합니다. 자세한 내용은 관리 클러스터 섹션을 참조하십시오.
-
프로젝트 네임스페이스 (선택 사항) - 이 옵션을 작성할 필요는 없습니다. 비워 두면 GitLab이 대신 만듭니다. 또한:
- 각 프로젝트에는 고유한 네임스페이스가 있어야 합니다.
- 프로젝트 네임스페이스는 secret의 네임스페이스와 일치하지 않을 수 있으며, 보다 넓은 권한을 부여한 secret(예:
default의 secret)를 사용하는 경우에 해당합니다. - 프로젝트 네임스페이스가 secret의 네임스페이스일 필요는 없습니다.
- 만약 프로젝트에 특별히 제한된 권한으로 시크릿을 만들었거나 다른 누군가가 만들었다면, 시크릿의 네임스페이스와 프로젝트 네임스페이스가 동일할 수 있습니다.
- Kubernetes 클러스터 추가 버튼을 선택하십시오.
약 10분 후에 클러스터가 준비됩니다.
롤 기반 액세스 제어 (RBAC) 비활성화 (옵션)
GitLab 통합을 통해 클러스터를 연결할 때 RBAC(Roll-Based Access Control)가 활성화되었는지 여부를 지정할 수 있습니다. 이는 GitLab이 클러스터와 상호 작용하는 방식에 영향을 미칩니다. 만약 생성 시 RBAC 활성화된 클러스터 확인란을 선택하지 않았다면, GitLab은 클러스터와 상호 작용할 때 RBAC가 비활성화되었다고 가정합니다. 그렇다면, 통합이 올바르게 작동하려면 클러스터에서 RBAC를 비활성화해야 합니다.
경고: RBAC를 비활성화하는 것은 클러스터에서 실행 중인 모든 어플리케이션이나 클러스터에 인증할 수 있는 사용자가 완전한 API 액세스 권한을 갖게 됨을 의미합니다. 이는 보안 문제이며 원하는 바가 아닐 수 있습니다.
RBAC를 효과적으로 비활성화하기 위해 전역 권한을 부여하여 완전한 액세스 권한을 부여할 수 있습니다:
kubectl create clusterrolebinding permissive-binding \
--clusterrole=cluster-admin \
--user=admin \
--user=kubelet \
--group=system:serviceaccounts
문제 해결
클러스터의 인증에 문제가 있습니다. CA 인증서 및 토큰이 유효한지 확인해주세요
Kubernetes 클러스터를 연결하는 동안 이 오류를 만난다면, 서비스 토큰을 올바르게 붙여넣었는지 확인해야 합니다. 일부 셸에서는 서비스 토큰에 줄 바꿈을 추가하여 유효하지 않게 만들 수 있습니다. 토큰을 편집기에 붙여넣고 추가적인 공백을 제거하여 줄 바꿈이 없는지 확인해주세요.
인증서가 유효하지 않은 경우에도 이 오류가 발생할 수 있습니다. 클러스터의 API에 대한 올바른 도메인을 포함하는 subject alternative names를 확인하려면 다음 명령을 실행해주세요:
echo | openssl s_client -showcerts -connect kubernetes.example.com:443 -servername kubernetes.example.com 2>/dev/null |
openssl x509 -inform pem -noout -text
-connect 인자는 호스트:포트 조합을 기대합니다. 예를 들어, https://kubernetes.example.com은 kubernetes.example.com:443가 됩니다. -servername 인자는 URI가 없는 도메인을 기대합니다. 예를 들어, kubernetes.example.com입니다.
도움말