GitLab과 Kubernetes 클러스터 연결

13.4버전에서 도입.
grpcs를 지원하기 시작한 버전은 13.6.
에이전트 서버는 이니셔티브 프로그램을 통해 13.10 버전에서 wss://kas.gitlab.com 아래 GitLab.com에 도입되었습니다.
13.11에서 GitLab Agent가 GitLab.com에서 사용 가능해졌습니다.
14.5에서 GitLab Premium에서 GitLab Free로 이동했습니다.
“GitLab Kubernetes Agent”가 14.6에서 “GitLab agent for Kubernetes”로 이름이 변경되었습니다.
GitLab 15.10에서 Flux가 GitOps 솔루션으로 권장됩니다.

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

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

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

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

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

워크플로우

주로 두 가지 주요 워크플로우를 선택할 수 있습니다. GitOps 워크플로우가 권장됩니다.

GitOps 워크플로우

GitOps를 위해 Flux를 사용해야 합니다. 시작하려면 GitOps를 위한 Flux 설정 튜토리얼을 참조하십시오.

GitLab CI/CD 워크플로우

CI/CD 워크플로우에서:

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

이 워크플로우는 GitLab이 클러스터로부터 요청을 밀어넣는 푸시 기반 워크플로우로 간주됩니다.

이 워크플로우는 다음과 같은 경우에 사용하십시오:

파이프라인 중심적인 프로세스가 있는 경우.
GitOps 워크플로우가 필요한 사용 사례를 지원할 수 없는 경우 에이전트로 마이그레이션해야 하는 경우.

이 워크플로우는 보안 모델이 약하며 별도의 프로덕션 배포에 권장되지 않습니다.

GitLab 기능 지원하는 Kubernetes 버전

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

Helm 차트용
GitLab Operator용

지원되는 Kubernetes 버전으로 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은 언제나 적어도 3개의 프로덕션용 Kubernetes 마이너 버전을 지원합니다.

새로운 Kubernetes 버전이 출시되면 약 4주 내에 초기 스모크 테스트 결과로 이 페이지를 업데이트할 것입니다.

에이전트를 설치할 때 Kubernetes 버전과 호환되는 Helm 버전을 사용해야 합니다. 다른 버전의 Helm은 작동하지 않을 수 있습니다. 호환되는 버전 목록은 Helm 버전 지원 정책을 참조하십시오.

Deprecated API 지원은 GitLab 코드베이스에서 지원하는 Kubernetes 버전이 Deprecated API만 지원하는 버전일 때 제거될 수 있습니다.

여기에 나열되지 않은 버전에서도 일부 GitLab 기능이 작동할 수 있습니다. Kubernetes 버전 지원을 추적하는 이 차세대 에픽을 참조하십시오.

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

인즅러하여 kubernetes 에이전트로 마이그레이션하는 방법에 대해 읽어보세요.

에이전트 연결

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

각 에이전트는 액티브 및 아이들 스트림을 포함하여 최대 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과의 안전한 연결을 유지합니다.	GitLab
Kubernetes용 GitLab 에이전트 서버 (`kas`)	Kubernetes 에이전트 통합에 대한 GitLab 측 구성 요소로서 GitLab과 Kubernetes 클러스터 간의 연결과 통신을 관리합니다.	GitLab
풀 기반 배포	Flux가 Git 리포지토리의 변경 사항을 확인하고 이를 클러스터에 자동으로 적용하는 배포 방법	GitLab, Kubernetes
푸시 기반 배포	GitLab CI/CD 파이프라인에서 Kubernetes 클러스터로 업데이트를 보내는 배포 방법	GitLab
Flux	풀 기반 배포에 대한 에이전트와 통합되는 오픈소스 GitOps 도구	GitOps, Kubernetes
GitOps	클라우드 및 Kubernetes 리소스의 관리와 자동화에 Git을 사용하는 관행의 집합	DevOps, Kubernetes
Kubernetes 네임스페이스	Kubernetes 클러스터의 논리적 분할로 클러스터 리소스를 여러 사용자 또는 환경으로 분할합니다.	Kubernetes