그룹 수준 Kubernetes 클러스터 (인증서 기반) (더 이상 지원되지 않음)

Tier: Free, Premium, Ultimate

Offering: GitLab.com, Self-managed, GitLab Dedicated

caution

이 기능은 더 이상 지원되지 않음 GitLab 14.5에서. 클러스터를 GitLab에 연결하려면, GitLab 에이전트를 사용하세요.

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

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

  1. 왼쪽 사이드바에서 Search or go to를 선택하고 그룹을 찾으세요.
  2. Operate > Kubernetes를 선택하세요.

클러스터 관리 프로젝트

클러스터 관리 프로젝트를 클러스터에 첨부하여 설치를 위해 cluster-admin 권한이 필요한 공유 리소스를 관리하세요. 예를 들면 Ingress 컨트롤러가 있습니다.

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. 왼쪽 사이드바에서 Search or go to를 선택하고 그룹을 찾으세요.
  2. Operate > 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 작업에 사용됩니다.
  • 스테이징 클러스터는 deploy to staging 작업에 사용됩니다.
  • 프로덕션 클러스터는 deploy to production 작업에 사용됩니다.

클러스터 환경

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

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

러너 보안

러너를 안전하게 구성하는 데 대한 중요한 정보는 러너 보안 문서를 참조하세요.

추가 정보

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