프로젝트 수준 및 인스턴스 수준 Kubernetes 클러스터와 마찬가지로 그룹 수준 Kubernetes 클러스터를 사용하면 Kubernetes 클러스터를 그룹에 연결하여 여러 프로젝트 간에 동일한 클러스터를 사용할 수 있습니다.

그룹 수준 Kubernetes 클러스터를 보려면:

1. 상단 표시줄에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
2. 왼쪽 사이드바에서 운영 > Kubernetes를 선택합니다.

클러스터 관리 프로젝트#

클러스터 관리 프로젝트를 클러스터에 연결하여 Ingress 컨트롤러와 같이 설치를 위해 cluster-admin 권한이 필요한 공유 리소스를 관리합니다.

RBAC 호환성#

그룹 아래에 Kubernetes 클러스터가 있는 각 프로젝트에 대해 GitLab은 프로젝트 네임스페이스에서 edit 권한을 가진 제한된 서비스 계정을 만듭니다.

클러스터 우선 순위#

프로젝트의 클러스터를 사용할 수 있고 비활성화되지 않은 경우, GitLab은 프로젝트가 포함된 그룹에 속한 클러스터를 사용하기 전에 프로젝트의 클러스터를 사용합니다. 하위 그룹의 경우 GitLab은 클러스터가 비활성화되지 않은 경우 프로젝트에 가장 가까운 조상 그룹의 클러스터를 사용합니다.

여러 Kubernetes 클러스터#

그룹에 둘 이상의 Kubernetes 클러스터를 연결하고 개발, 스테이징 및 프로덕션과 같이 다른 환경에 대해 서로 다른 클러스터를 유지 관리할 수 있습니다.

다른 클러스터를 추가할 때, 환경 범위를 설정하여 새 클러스터를 다른 클러스터와 구분합니다.

GitLab 관리 클러스터#

GitLab이 클러스터를 관리하도록 선택할 수 있습니다. GitLab이 클러스터를 관리하면 프로젝트에 대한 리소스가 자동으로 만들어집니다. 자세한 내용은 GitLab이 만드는 리소스에 대한 액세스 제어 섹션을 참조하세요.

GitLab에서 관리하지 않는 클러스터의 경우 프로젝트별 리소스가 자동으로 만들어지지 않습니다. GitLab에서 관리하지 않는 클러스터에서 배포를 위한 Auto DevOps를 사용하는 경우 다음을 확인해야 합니다:

• 프로젝트의 배포 서비스 계정에 KUBE_NAMESPACE에 배포할 권한이 있는지.
• KUBECONFIG가 KUBE_NAMESPACE 변경 사항을 올바르게 반영하는지 (이는 자동이 아닙니다). KUBE_NAMESPACE를 직접 편집하는 것은 권장되지 않습니다.

클러스터 캐시 지우기#

GitLab이 클러스터를 관리하도록 선택하면 GitLab은 프로젝트를 위해 만드는 네임스페이스 및 서비스 계정의 캐시된 버전을 저장합니다. 클러스터에서 이러한 리소스를 수동으로 수정하면 이 캐시가 클러스터와 동기화되지 않아 배포 job이 실패할 수 있습니다.

캐시를 지우려면:

1. 상단 표시줄에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
2. 왼쪽 사이드바에서 운영 > Kubernetes를 선택합니다.
3. 클러스터를 선택합니다.
4. 고급 설정을 펼칩니다.
5. 클러스터 캐시 지우기를 선택합니다.

기본 도메인#

클러스터 수준에서의 도메인은 여러 Kubernetes 클러스터당 여러 도메인을 지원합니다. 도메인을 지정하면, Auto DevOps Stage 중에 환경 변수(KUBE_INGRESS_BASE_DOMAIN)로 자동 설정됩니다.

도메인은 Ingress IP 주소에 와일드카드 DNS가 구성되어 있어야 합니다. 자세한 내용.

환경 범위#

프로젝트에 둘 이상의 Kubernetes 클러스터를 추가할 때 환경 범위로 구분해야 합니다. 환경 범위는 환경별 CI/CD 변수가 작동하는 방식과 유사하게 클러스터를 환경과 연결합니다.

클러스터의 환경 범위와 일치하는 환경을 평가할 때 클러스터 우선 순위가 적용됩니다. 프로젝트 수준의 클러스터가 우선되고, 다음으로 가장 가까운 조상 그룹, 그런 다음 해당 그룹의 부모 순으로 우선됩니다.

예를 들어, 프로젝트에 다음과 같은 Kubernetes 클러스터가 있는 경우:

그리고 .gitlab-ci.yml 파일에 다음과 같은 환경이 설정된 경우:

stages:
  - test
  - deploy

test:
  stage: test
  script: sh test

deploy to staging:
  stage: deploy
  script: make deploy
  environment:
    name: staging/$CI_COMMIT_REF_NAME
    url: https://staging.example.com/

deploy to production:
  stage: deploy
  script: make deploy
  environment:
    name: production/$CI_COMMIT_REF_NAME
    url: https://example.com/

결과는 다음과 같습니다:

• test job에 Project 클러스터가 사용됩니다.
• deploy to staging job에 Staging 클러스터가 사용됩니다.
• deploy to production job에 Production 클러스터가 사용됩니다.

클러스터 환경#

Kubernetes 클러스터에 배포되는 CI 환경의 통합된 보기를 위해 클러스터 환경 문서를 참조하세요.

러너 보안#

러너를 안전하게 구성하는 방법에 대한 중요한 정보는 프로젝트 수준 클러스터에 대한 러너 보안 문서를 참조하세요.

추가 정보#

GitLab과 Kubernetes 통합에 대한 정보는 Kubernetes 클러스터를 참조하세요.