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

Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-Managed, GitLab Dedicated
caution
이 기능은 GitLab 14.5에서 폐기되었습니다. 클러스터를 GitLab에 연결하려면 GitLab 에이전트를 사용하십시오.

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

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

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

클러스터 관리 프로젝트

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

RBAC 호환성

쿠버네티스 클러스터가 있는 그룹의 각 프로젝트에 대해 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가 Ingress IP 주소로 구성되어야 합니다. 더 많은 정보.

환경 범위

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

프로젝트에 여러 개의 쿠버네티스 클러스터를 추가하려면 각각에 환경 범위를 지정해야 합니다. 환경 범위는 환경로 클러스터를 연결하고 환경별 CI/CD 변수와 유사하게 작동합니다.

클러스터의 환경 범위를 사용하여 클러스터의 환경과 일치하는 환경을 평가할 때, 클러스터 우선순위가 적용됩니다. 프로젝트 수준의 클러스터가 우선되며, 다음으로 가장 가까운 상위 그룹, 해당 그룹의 부모 및 그 이후가 따릅니다.

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

클러스터 환경 범위 위치
프로젝트 * 프로젝트
스테이징 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

쿠버네티스 클러스터에 배포된 CI 환경의 통합된 보기에 대해서는 클러스터 환경의 문서를 참조하십시오.

실행자의 보안

실행자를 안전하게 구성하는 중요한 정보에 대한 자세한 내용은 실행자의 보안을 참조하십시오.

더 많은 정보

GitLab 및 Kubernetes 통합에 대한 자세한 내용은 다음을 참조하십시오. Kubernetes 클러스터.