Kubernetes 클러스터를 GitLab과 연결하기

클라우드 네이티브 솔루션을 배포, 관리 및 모니터링하려면 Kubernetes 클러스터를 GitLab과 연결할 수 있습니다.

GitLab에 Kubernetes 클러스터를 연결하려면 먼저 클러스터에 에이전트를 설치해야 합니다.

에이전트는 클러스터에서 실행되며 다음과 같이 사용할 수 있습니다:

  • 방화벽 뒤나 NAT 뒤에 있는 클러스터와 통신
  • 클러스터의 API 엔드포인트에 실시간으로 액세스
  • 클러스터에서 발생하는 이벤트에 대한 정보 전송
  • 매우 낮은 대기 시간으로 최신 상태를 유지하는 Kubernetes 오브젝트의 캐시 활성화

에이전트의 목적 및 아키텍처에 대한 자세한 내용은 아키텍처 문서를 참조하세요.

Workflows

두 가지 기본 Workflow 중 하나를 선택할 수 있습니다. GitOps Workflow가 권장됩니다.

GitOps Workflow

GitOps에는 Flux를 사용해야 합니다. 시작하려면 튜토리얼: GitOps를 위한 Flux 설정을 참조하세요.

GitLab CI/CD Workflow

CI/CD Workflow에서:

  • GitLab CI/CD를 구성하여 Kubernetes API를 사용하여 클러스터를 조회하고 업데이트

이 Workflow는 GitLab이 GitLab CI/CD에서 클러스터로 요청을 푸시하므로 푸시 기반 Workflow로 간주됩니다.

이 Workflow는 대규모 파이프라인 지향적 프로세스가 필요할 때, 그리고 GitOps Workflow가 필요한 사용 사례를 지원할 수 없을 때 사용합니다.

이 Workflow는 보안 모델이 약하며 프로덕션 배포에는 권장되지 않습니다.

GitLab 기능에 대한 지원되는 Kubernetes 버전

GitLab은 다음 Kubernetes 버전을 지원합니다. Kubernetes 클러스터에서 GitLab을 실행하려면 다른 버전을 필요로 할 수 있습니다:

어느 때든 Kubernetes 버전을 지원되는 버전으로 업그레이드할 수 있습니다:

  • 1.29 (GitLab 버전 17.10이 릴리스되거나 1.32가 지원되기 시작했을 때 지원 종료)
  • 1.28 (GitLab 버전 17.5이 릴리스되거나 1.31이 지원되기 시작했을 때 지원 종료)
  • 1.27 (GitLab 버전 17.2이 릴리스되거나 1.30이 지원되기 시작했을 때 지원 종료)

GitLab은 새로운 Kubernetes 마이너 버전을 초기 릴리스 후 3개월 후에 지원하기 위해 노력합니다. GitLab은 언제나 적어도 세 가지의 프로덕션에 준비된 Kubernetes 마이너 버전을 지원합니다.

새로운 Kubernetes 버전이 릴리스되면 다음과 같이 진행됩니다:

  • 대략 4주 안에 초기 Smoke 테스트 결과로 이 페이지가 업데이트됩니다.
  • 새로운 버전 지원의 지연이 예상될 경우, 대략 8주 안에 기대되는 GitLab 지원 버전으로 이 페이지가 업데이트됩니다.

에이전트를 설치할 때, Kubernetes 버전과 호환되는 Helm 버전을 사용해야 합니다. 기타 버전의 Helm은 작동하지 않을 수 있습니다. 호환되는 버전 디렉터리은 Helm 버전 지원 정책을 참조하세요.

폐기된 API 지원은 폐기된 API만 지원하는 Kubernetes 버전에 대한 GitLab 코드베이스에서 제거될 수 있습니다.

여기에 나열되지 않은 버전에서도 일부 GitLab 기능이 작동할 수 있습니다. 이 이슈에서 Kubernetes 버전 지원을 추적합니다.

레거시 인증 기반 통합에서 에이전트로 마이그레이션

인증 기반 통합에서 에이전트로의 마이그레이션에 대해 읽어보세요.

에이전트 연결

에이전트는 KAS에 양방향 채널을 엽니다. 이 채널은 에이전트와 KAS 사이의 모든 통신에 사용됩니다:

  • 각 에이전트는 Active 및 Idle 스트림을 포함한 최대 500개의 논리적 gRPC 스트림을 유지할 수 있습니다.
  • gRPC 스트림에 의해 사용되는 TCP 연결 수는 gRPC 자체에 의해 결정됩니다.
  • 각 연결은 최대 2시간의 최대 수명을 가지며 1시간의 유예 기간이 있습니다.
    • KAS 앞에 프록시가 있을 경우 연결의 최대 수명에 영향을 줄 수 있습니다. GitLab.com에서는 2시간입니다. 유예 기간은 최대 수명의 50%입니다.

채널 라우팅에 대한 자세한 정보는 에이전트를 통한 KAS 요청 라우팅을 참조하세요.

Kubernetes 통합용 용어집

이 용어집은 GitLab Kubernetes 통합과 관련된 용어에 대한 정의를 제공합니다.

용어 정의 범위
Kubernetes용 GitLab 에이전트 관련 기능 및 하부 컴포넌트인 agentk 및 kas를 포함한 전반적인 제공 GitLab, Kubernetes, Flux
agentk GitLab에서 Kubernetes 관리 및 배포 자동화를 위한 클러스터 측 컴포넌트 GitLab
Kubernetes용 GitLab 에이전트 서버 (kas) Kubernetes 클러스터와 GitLab 간의 연결 및 통신을 관리하는 GitLab 측 컴포넌트 GitLab
풀 기반 배포 Flux가 Git 리포지터리의 변경을 확인하고 이러한 변경을 자동으로 클러스터에 적용하는 배포 방법 GitLab, Kubernetes
푸시 기반 배포 업데이트가 GitLab CI/CD 파이프라인에서 Kubernetes 클러스터로 보내지는 배포 방법 GitLab
Flux 풀 기반 배포를 위한 에이전트와 통합되는 오픈 소스 GitOps 도구 GitOps, Kubernetes
GitOps 클라우드 및 Kubernetes 리소스의 관리 및 자동화에 Git을 사용하는 관행 DevOps, Kubernetes
Kubernetes 네임스페이스 Kubernetes 클러스터의 논리적 파티션으로 여러 사용자 또는 환경 사이에 클러스터 리소스를 분할 Kubernetes

관련 주제