그룹 수준의 Kubernetes 클러스터(인증서 기반) (Deprecated)

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

경고: 이 기능은 GitLab 14.5에서 사용 중지되었습니다. 클러스터를 GitLab에 연결하려면 GitLab 에이전트를 사용하십시오.

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

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

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

클러스터 관리 프로젝트

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

RBAC 호환성

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

클러스터 우선 순위

프로젝트의 클러스터를 사용할 수 있고 비활성화되지 않은 경우, GitLab은 프로젝트를 포함하는 그룹의 클러스터보다 먼저 프로젝트의 클러스터를 사용합니다. 서브그룹의 경우, GitLab은 프로젝트의 가장 가까운 상위 그룹의 클러스터를 사용하는데, 클러스터가 비활성화되지 않았다면 제공됩니다.

여러 Kubernetes 클러스터

하나 이상의 Kubernetes 클러스터를 그룹에 연결하고 개발, 스테이징, 프로덕션과 같은 다양한 환경을 유지할 수 있습니다.

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

GitLab에서 관리되는 클러스터

GitLab이 클러스터를 관리하도록 선택할 수 있습니다. GitLab이 클러스터를 관리하면 프로젝트의 리소스가 자동으로 생성됩니다. 세부 정보는 액세스 제어 섹션에서 확인할 수 있습니다.

GitLab에서 관리되지 않는 클러스터의 경우, 프로젝트별 리소스가 자동으로 생성되지 않습니다. GitLab이 관리하지 않는 클러스터로 배포에 Auto DevOps를 사용하는 경우:

  • 프로젝트의 배포 서비스 계정이 KUBE_NAMESPACE로 배포할 권한이 있는지 확인해야 합니다.
  • KUBECONFIG이 KUBE_NAMESPACE에 대한 변경 사항을 정확하게 반영하고 있는지 확인해야 합니다 (이 작업은 자동으로 이루어지지 않습니다). KUBE_NAMESPACE을 직접 편집하는 것은 권장되지 않습니다.

클러스터 캐시 지우기

GitLab이 클러스터를 관리하도록 선택하는 경우, GitLab은 프로젝트를 위해 생성한 네임스페이스와 서비스 계정의 캐시 버전을 저장합니다. 이러한 리소스를 수동으로 수정하면 이 캐시는 클러스터와 동기화되지 않을 수 있으며 이는 배포 작업 실패의 원인이 될 수 있습니다.

캐시를 지우려면:

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

기본 도메인

클러스터 수준의 도메인은 다중 Kubernetes 클러스터 당 여러 도메인을 지원합니다. 도메인을 지정하면 이는 자동으로 환경 변수로 설정되며(KUBE_INGRESS_BASE_DOMAIN) Auto DevOps 단계 중에 사용됩니다.

도메인은 워크로드 DNS가 인그레스 IP 주소로 구성되어 있어야 합니다. 세부 정보를 참조하십시오.

환경 범위

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 작업에 사용됩니다.
  • 스테이징 클러스터는 deploy to staging 작업에 사용됩니다.
  • 프로덕션 클러스터는 deploy to production 작업에 사용됩니다.

클러스터 환경

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

Kubernetes 클러스터에 배포된 CI 환경의 통합 보기에 대한 설명은 클러스터 환경 문서를 참조하십시오.

러너의 보안

러너의 안전한 구성에 대한 중요한 정보는 프로젝트 수준의 클러스터에 대한 러너의 보안 문서를 참조하십시오.

추가 정보

GitLab 및 Kubernetes를 통합하는 방법에 대한 정보는 Kubernetes 클러스터를 참조하십시오.