Kubernetes 클러스터를 GitLab에 연결하기
Offering: GitLab Self-Managed
Kubernetes 클러스터를 GitLab에 연결하여 클라우드 네이티브 솔루션을 배포, 관리 및 모니터링할 수 있습니다. Kubernetes 클러스터를 GitLab에 연결하려면 먼저 클러스터에 에이전트를 설치해야 합니다.
히스토리
- GitLab 15.10에서 Flux가 GitOps 솔루션으로 권장됨.
Kubernetes 클러스터를 GitLab에 연결하여 클라우드 네이티브 솔루션을 배포, 관리 및 모니터링할 수 있습니다.
Kubernetes 클러스터를 GitLab에 연결하려면 먼저 클러스터에 에이전트를 설치해야 합니다.
에이전트는 클러스터에서 실행되며 다음과 같은 용도로 사용할 수 있습니다:
- 방화벽 또는 NAT 뒤에 있는 클러스터와 통신.
- 실시간으로 클러스터의 API 엔드포인트에 접근.
- 클러스터에서 발생하는 이벤트에 대한 정보 푸시.
- 매우 낮은 지연시간으로 최신 상태를 유지하는 Kubernetes 객체 캐시 활성화.
에이전트의 목적과 아키텍처에 대한 자세한 내용은 아키텍처 문서를 참조하세요.
GitLab에 연결하려는 모든 클러스터에 별도의 에이전트를 배포해야 합니다. 에이전트는 강력한 멀티 테넌시 지원을 갖추고 설계되었습니다. 유지 관리 및 운영을 단순화하기 위해 클러스터당 하나의 에이전트만 실행하는 것이 좋습니다.
에이전트는 항상 GitLab 프로젝트에 등록됩니다. 에이전트가 등록 및 설치되면 클러스터에 대한 에이전트 연결을 다른 프로젝트, 그룹 및 사용자와 공유할 수 있습니다. 이 방법을 사용하면 GitLab 자체에서 에이전트 인스턴스를 관리 및 구성할 수 있으며, 단일 설치를 여러 테넌트로 확장할 수 있습니다.
GitLab 기능에 대한 지원 Kubernetes 버전#
GitLab은 다음 Kubernetes 버전을 지원합니다. Kubernetes 클러스터에서 GitLab을 실행하려면 다른 버전의 Kubernetes가 필요할 수 있습니다:
언제든지 지원되는 버전으로 Kubernetes 버전을 업그레이드할 수 있습니다:
- 1.35 (GitLab 버전 19.10이 릴리스되거나 1.38이 지원될 때 지원 종료)
- 1.34 (GitLab 버전 19.7이 릴리스되거나 1.37이 지원될 때 지원 종료)
- 1.33 (GitLab 버전 19.2가 릴리스되거나 1.36이 지원될 때 지원 종료)
GitLab은 초기 릴리스 후 3개월 후에 새로운 마이너 Kubernetes 버전을 지원하는 것을 목표로 합니다. GitLab은 항상 최소 세 개의 프로덕션 준비 Kubernetes 마이너 버전을 지원합니다.
새로운 버전의 Kubernetes가 릴리스될 때:
- 이 페이지는 약 4주 이내에 초기 스모크 테스트 결과로 업데이트됩니다.
- 새 버전 지원 릴리스가 지연되는 경우 이 페이지는 약 8주 이내에 예상 GitLab 지원 버전으로 업데이트됩니다.
에이전트를 설치할 때 Kubernetes 버전과 호환되는 Helm 버전을 사용하세요. 다른 버전의 Helm은 작동하지 않을 수 있습니다. 호환되는 버전 목록은 Helm 버전 지원 정책을 참조하세요.
GitLab이 더 이상 더 이상 사용되지 않는 API만 지원하는 Kubernetes 버전을 지원하지 않을 때 더 이상 사용되지 않는 API에 대한 지원이 GitLab 코드베이스에서 제거될 수 있습니다.
일부 GitLab 기능은 여기에 나열되지 않은 버전에서도 작동할 수 있습니다. 이 에픽에서 Kubernetes 버전 지원을 추적합니다.
Kubernetes 배포 워크플로#
두 가지 기본 워크플로 중에서 선택할 수 있습니다. GitOps 워크플로를 권장합니다.
GitOps 워크플로#
GitLab은 GitOps용 Flux를 사용하는 것을 권장합니다. 시작하려면 튜토리얼: GitOps용 Flux 설정을 참조하세요.
GitLab CI/CD 워크플로#
CI/CD 워크플로에서 GitLab CI/CD를 구성하여 Kubernetes API를 사용하여 클러스터를 쿼리하고 업데이트합니다.
이 워크플로는 GitLab CI/CD에서 클러스터로 요청을 푸시하기 때문에 푸시 기반으로 간주됩니다.
이 워크플로를 사용하세요:
- 파이프라인 기반 프로세스가 있는 경우.
- 에이전트로 마이그레이션해야 하지만 GitOps 워크플로가 사용 사례를 지원하지 않는 경우.
이 워크플로는 더 약한 보안 모델을 가지고 있습니다. 프로덕션 배포에는 CI/CD 워크플로를 사용하지 않는 것이 좋습니다.
에이전트 연결 기술 세부 정보#
에이전트는 통신을 위해 KAS에 양방향 채널을 엽니다. 이 채널은 에이전트와 KAS 간의 모든 통신에 사용됩니다:
- 각 에이전트는 활성 및 유휴 스트림을 포함하여 최대 500개의 논리적 gRPC 스트림을 유지할 수 있습니다.
- gRPC 스트림에 사용되는 TCP 연결 수는 gRPC 자체에 의해 결정됩니다.
- 각 연결의 최대 수명은 2시간이며 1시간의 유예 기간이 있습니다.
- KAS 앞의 프록시가 연결의 최대 수명에 영향을 줄 수 있습니다. GitLab.com에서는 2시간입니다. 유예 기간은 최대 수명의 50%입니다.
채널 라우팅에 대한 자세한 내용은 에이전트에서 KAS 요청 라우팅을 참조하세요.
리셉티브 에이전트(Receptive agents)#
히스토리
- GitLab 17.4에서 도입.
리셉티브 에이전트를 사용하면 GitLab을 GitLab 인스턴스에 네트워크 연결을 설정할 수 없지만 GitLab이 연결할 수 있는 Kubernetes 클러스터와 통합할 수 있습니다. 예를 들어 다음의 경우에 발생할 수 있습니다:
- GitLab이 사설 네트워크 또는 방화벽 뒤에서 실행되며 VPN을 통해서만 접근 가능합니다.
- Kubernetes 클러스터는 클라우드 공급자가 호스팅하지만 인터넷에 노출되어 있거나 사설 네트워크에서 접근 가능합니다.
이 기능이 활성화되면 GitLab은 제공된 URL로 에이전트에 연결합니다. 에이전트와 리셉티브 에이전트를 동시에 사용할 수 있습니다.
Kubernetes 통합 용어집#
이 용어집은 GitLab Kubernetes 통합과 관련된 용어 정의를 제공합니다.
| 용어 | 정의 | 범위 |
|---|---|---|
| GitLab agent for Kubernetes | agentk 및 kas라는 기본 컴포넌트와 관련 기능을 포함한 전체 제품군. |
GitLab, Kubernetes, Flux |
agentk |
Kubernetes 관리 및 배포 자동화를 위해 GitLab에 대한 안전한 연결을 유지하는 클러스터 측 컴포넌트. | GitLab |
GitLab agent server for Kubernetes (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 |