그룹 수준 쿠버네티스 클러스터(인증서 기반) (폐기됨)
프로젝트 수준과 동일하게, 프로젝트 수준 및 인스턴스 수준의 쿠버네티스 클러스터와 유사하게, 그룹 수준 쿠버네티스 클러스터를 사용하여 쿠버네티스 클러스터를 그룹에 연결하여 하나의 클러스터를 여러 프로젝트에서 공유하여 사용할 수 있습니다.
그룹 수준 쿠버네티스 클러스터를 보려면:
- 왼쪽 사이드바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
- 운영 > 쿠버네티스를 선택합니다.
클러스터 관리 프로젝트
클러스터 관리 프로젝트를
클러스터에 연결하여 Ingress 컨트롤러와 같이 cluster-admin
권한이 필요한
공유 리소스를 설치할 수 있습니다.
RBAC 호환성
쿠버네티스 클러스터가 있는 그룹의 각 프로젝트에 대해 GitLab은 프로젝트 네임스페이스에서 edit
권한을 갖는
제한된 서비스 계정을 생성합니다.
클러스터 우선 순위
프로젝트의 클러스터가 사용 가능하고 비활성화되지 않은 경우, GitLab은 프로젝트가 속한 그룹의 클러스터를 사용하기 전에 그룹에 속한 클러스터를 사용합니다. 하위 그룹의 경우, GitLab은 프로젝트가 속한 가장 가까운 상위 그룹의 클러스터를 사용하며 클러스터가 비활성화되지 않은 경우에만 사용합니다.
다중 쿠버네티스 클러스터
하나의 그룹에 여러 쿠버네티스 클러스터를 연결하고 서로 다른 환경(예: 개발, 스테이징, 프로덕션)을 유지할 수 있습니다.
다른 클러스터를 추가할 때, 환경 범위를 설정하여 새로운 클러스터를 다른 클러스터와 구별할 수 있습니다.
GitLab 관리 클러스터
GitLab이 클러스터를 관리하도록 선택할 수 있습니다. GitLab이 클러스터를 관리하면 프로젝트의 리소스가 자동으로 생성됩니다. 자세한 내용은 접근 제어 섹션을 참조하십시오.
GitLab에서 관리하지 않는 클러스터에는 프로젝트별 리소스가 자동으로 생성되지 않습니다. GitLab이 관리하지 않는 클러스터에 배포에 Auto DevOps를 사용하는 경우, 다음을 확인해야 합니다:
- 프로젝트의 배포 서비스 계정이
KUBE_NAMESPACE
로 배포할 권한이 있어야 합니다. -
KUBECONFIG
은KUBE_NAMESPACE
에 대한 변경 사항을 정확하게 반영해야 합니다 (이것은 자동으로 되지 않습니다). 직접KUBE_NAMESPACE
를 편집하는 것은 권장되지 않습니다.
클러스터 캐시 지우기
GitLab이 클러스터를 관리하도록 선택하는 경우, GitLab은 프로젝트를 위해 만든 네임스페이스와 서비스 계정의 캐시된 버전을 저장합니다. 이 캐시는 클러스터에서 이러한 리소스를 매뉴얼으로 수정하면 동기화가 해제될 수 있으며, 이로 인해 배포 작업이 실패할 수 있습니다.
캐시를 지우려면:
- 왼쪽 사이드바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
- 운영 > 쿠버네티스를 선택합니다.
- 클러스터를 선택합니다.
- 고급 설정을 확장합니다.
- 클러스터 캐시 지우기를 선택합니다.
기본 도메인
클러스터 수준의 도메인은 여러 도메인을 지원할 수 있습니다
다중 쿠버네티스 클러스터 단일 도메인을 지정할 때,
이는 환경 변수 (KUBE_INGRESS_BASE_DOMAIN
)로 자동 설정되며
Auto DevOps 단계 중에 자동으로 설정됩니다.
도메인은 별도의 DNS가 Ingress IP 주소로 구성되어야 합니다. 더 많은 정보.
환경 범위
프로젝트에 여러 개의 쿠버네티스 클러스터를 추가하려면 각각에 환경 범위를 지정해야 합니다. 환경 범위는 환경로 클러스터를 연결하고 환경별 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
작업에 사용됩니다.
클러스터 환경
쿠버네티스 클러스터에 배포된 CI 환경의 통합된 보기에 대해서는 클러스터 환경의 문서를 참조하십시오.
실행자의 보안
실행자를 안전하게 구성하는 중요한 정보에 대한 자세한 내용은 실행자의 보안을 참조하십시오.
더 많은 정보
GitLab 및 Kubernetes 통합에 대한 자세한 내용은 다음을 참조하십시오. Kubernetes 클러스터.