그룹 수준 쿠버네티스 클러스터(인증서 기반) (폐기됨)

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

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

프로젝트 수준과 인스턴스 수준의 쿠버네티스 클러스터와 유사하게, 그룹 수준의 쿠버네티스 클러스터를 사용하여 해당 그룹에 쿠버네티스 클러스터를 연결하여 동일한 클러스터를 여러 프로젝트에서 사용할 수 있습니다.

그룹 수준의 쿠버네티스 클러스터를 보려면:

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

클러스터 관리 프로젝트

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

RBAC 호환성

  • GitLab 11.4에서 소개되었습니다.
  • 프로젝트 네임스페이스 제한은 GitLab 11.5에서 소개되었습니다.

쿠버네티스 클러스터가 포함된 그룹의 각 프로젝트에 대해 GitLab은 프로젝트 네임스페이스에서 edit 권한을 갖는 제한된 서비스 계정을 생성합니다.

클러스터 우선 순위

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

다중 쿠버네티스 클러스터

하나 이상의 쿠버네티스 클러스터를 그룹에 연결하고 개발, 스테이징, 프로덕션 등과 같이 각기 다른 환경을 유지할 수 있습니다.

다른 클러스터를 추가할 때, 새로운 클러스터를 다른 클러스터와 구분하기 위해 환경 범위를 설정하세요.

GitLab에서 관리하는 클러스터

GitLab이 클러스터를 관리하도록 선택할 수 있습니다. GitLab이 클러스터를 관리하는 경우, 프로젝트의 리소스가 자동으로 생성됩니다. 자세한 내용은 접근 제어 섹션을 참조하세요.

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

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

클러스터 캐시 지우기

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

캐시를 지우려면:

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

기본 도메인

클러스터 수준의 도메인은 다중 쿠버네티스 클러스터당 다양한 도메인을 지원합니다. 도메인을 지정할 때, 자동으로 환경 변수(KUBE_INGRESS_BASE_DOMAIN)로 설정되며, Auto DevOps 단계에서 사용됩니다.

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

환경 범위

Tier: Premium, Ultimate Offering: GitLab.com, 자체 관리, GitLab Dedicated

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

클러스터의 환경 범위와 일치하는 환경을 평가하는 동안 클러스터 우선 순위가 적용됩니다. 프로젝트 수준의 클러스터가 우선이며, 가장 가까운 조상 그룹이 차례로 뒤를 이어 나옵니다.

예를 들어, 프로젝트에 다음과 같은 Kubernetes 클러스터가 있다고 가정해 봅시다:

클러스터 환경 범위 위치
Project * 프로젝트
Staging staging/* 프로젝트
Production production/* 프로젝트
Test test 그룹
Development * 그룹

그리고 다음과 같은 환경이 .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, 자체 관리, GitLab Dedicated

Kubernetes 클러스터에 배포된 CI 환경을 통합한 종합적인 보기를 위해서는 클러스터 환경 문서를 참조하십시오.

러너의 보안

러너를 안전하게 구성하는 중요한 정보에 대해서는 러너의 보안 문서를 참조하십시오.

자세한 정보

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