그룹 수준 Kubernetes 클러스터 (인증서 기반) (사용 중지)

Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated
caution
이 기능은 GitLab 14.5에서 사용되지 않게 되었습니다. GitLab에 클러스터를 연결하려면 GitLab 에이전트를 사용하세요.

프로젝트 수준 및 인스턴스 수준 Kubernetes 클러스터와 유사하게, 그룹 수준 Kubernetes 클러스터를 사용하면 Kubernetes 클러스터를 그룹에 연결하여 동일한 클러스터를 여러 프로젝트에서 사용할 수 있습니다.

그룹 수준 Kubernetes 클러스터를 확인하려면:

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

클러스터 관리 프로젝트

클러스터 관리 프로젝트를 클러스터에 첨부하여 설치에 클러스터 관리자 권한이 필요한 공유 리소스를 관리할 수 있습니다.

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은 프로젝트를 위해 생성한 네임스페이스와 서비스 계정의 캐시 버전을 보관합니다. 이러한 리소스를 클러스터에서 매뉴얼으로 수정하는 경우, 이 캐시가 클러스터와 동기화되지 않을 수 있으며 이는 배포 작업 실패의 원인이 될 수 있습니다.

캐시를 지우려면:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 그룹을 찾으세요.
  2. 운영 > Kubernetes를 선택하세요.
  3. 클러스터를 선택하세요.
  4. 고급 설정을 확장하세요.
  5. 클러스터 캐시 지우기를 선택하세요.

기본 도메인

클러스터 수준의 도메인을 지정하면 다중 Kubernetes 클러스터당 여러 도메인을 지원할 수 있습니다. 도메인을 지정하면 Auto DevOps 단계 중 자동으로 환경 변수(KUBE_INGRESS_BASE_DOMAIN)로 설정됩니다. 도메인은 Ingress IP 주소에 대한 와일드카드 DNS가 구성되어야 합니다. 추가 정보.

환경 범위

Tier: Premium, Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated

프로젝트에 하나 이상의 Kubernetes 클러스터를 추가하는 경우, 환경 범위로 클러스터를 구분해야 합니다. 환경 범위는 환경별 CI/CD 변수와 유사하게 클러스터를 환경와 관련시킵니다.

클러스터의 환경 범위를 평가하는 동안 클러스터 우선 순위가 적용됩니다. 프로젝트 수준의 클러스터가 우선되며, 가장 가까운 조상 그룹, 해당 그룹의 부모 그룹 등이 그 뒤를 따릅니다.

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

클러스터 환경 범위 위치
프로젝트 * 프로젝트
스테이징 staging/* 프로젝트
제품 production/* 프로젝트
테스트 test 그룹
개발 * 그룹

그리고 다음과 같이 .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 작업에 사용됩니다.
  • 스테이징 클러스터는 staging 작업에 사용됩니다.
  • 제품 클러스터는 production 작업에 사용됩니다.

클러스터 환경

Tier: Premium, Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated

Kubernetes 클러스터에 배포된 CI 환경을 종합적으로 확인하려면 클러스터 환경 문서를 참조하세요.

러너들의 보안

러너를 안전하게 구성하는 중요한 정보에 대해서는 러너들의 보안 문서를 프로젝트 레벨 클러스터의 보안 설정에 대해 참조하세요.

추가 정보

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