GitLab과 Kubernetes 클러스터 연결
- GitLab 15.10에서는 GitOps 솔루션으로 Flux를 권장합니다.
클라우드 네이티브 솔루션을 배포, 관리 및 모니터링하려면 Kubernetes 클러스터를 GitLab에 연결해야 합니다.
Kubernetes 클러스터를 GitLab에 연결하려면 먼저 클러스터에 에이전트를 설치해야 합니다.
에이전트는 클러스터 내에서 실행되며 다음과 같이 사용할 수 있습니다:
- 방화벽 또는 NAT 뒤에 있는 클러스터와 통신합니다.
- 클러스터 내의 API 엔드포인트에 실시간으로 액세스합니다.
- 클러스터에서 발생하는 이벤트 정보를 푸시합니다.
- 매우 낮은 대기 시간으로 최신 상태를 유지하는 Kubernetes 오브젝트의 캐시를 활성화합니다.
에이전트의 목적 및 아키텍처에 대한 자세한 내용은 아키텍처 문서를 참조하세요.
워크플로우
기본적으로 두 가지 주요 워크플로우를 선택할 수 있습니다. GitOps 워크플로우가 권장됩니다.
GitOps 워크플로우
GitOps에는 Flux를 사용해야 합니다. 시작하려면 GitOps용 Flux 설정 튜토리얼을 참조하세요.
GitLab CI/CD 워크플로우
CI/CD 워크플로우에서는 다음과 같이 설정합니다:
- GitLab CI/CD를 구성하여 Kubernetes API를 사용하여 클러스터를 조회하고 업데이트합니다.
이 워크플로우는 GitLab이 GitLab CI/CD에서 클러스터로 요청을 보내는 push-based 방식입니다.
이 워크플로우는:
- 파이프라인 중심적인 프로세스가 필요할 때 사용합니다.
- 에이전트로 마이그레이션해야 하지만 GitOps 워크플로우로는 필요한 유즈 케이스를 지원할 수 없을 때 사용합니다.
이 워크플로우는 보안 모델이 약하며 프로덕션 배포에 권장되지 않습니다.
GitLab 기능에 대한 지원되는 Kubernetes 버전
GitLab은 다음 Kubernetes 버전을 지원합니다. Kubernetes 클러스터에서 GitLab을 실행하려면 적절한 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주 후 초기 smoke tests 결과가 있는 이 페이지가 업데이트될 것입니다.
- 신규 버전 지원을 지연할 것으로 예상되면 약 8주 후 GitLab 지원 버전이 표시됩니다.
에이전트를 설치할 때 사용하는 Helm 버전은 Kubernetes 버전과 호환되어야 합니다. 다른 버전의 Helm은 작동하지 않을 수 있습니다. 호환되는 버전 디렉터리은 Helm 버전 지원 정책에서 확인하세요.
지원이 중단된 API에 대한 지원은 해당되는 Kubernetes 버전의 지원이 중단될 때 GitLab 코드베이스에서 제거될 수 있습니다.
일부 GitLab 기능은 여기에 나열된 버전 이외의 버전에서 작동할 수 있습니다. 이 에픽은 Kubernetes 버전 지원을 추적합니다.
레거시 인증 기반 통합에서 에이전트로 마이그레이션
써티피케이션 기반 통합에서 Kubernetes를 위해 에이전트로 마이그레이션하는 방법을 읽어보세요.
에이전트 연결
에이전트는 통신을 위해 KAS에 양방향 채널을 엽니다. 이 채널은 에이전트와 KAS 간의 모든 통신에 사용됩니다.
- 각 에이전트는 활성 및 유휴 스트림을 포함하여 최대 500개의 논리 gRPC 스트림을 유지할 수 있습니다.
- gRPC 스트림에서 사용하는 TCP 연결 수는 gRPC 자체에서 결정됩니다.
- 각 연결은 2시간의 최대 수명을 가지며 1시간의 유예 기간이 있습니다.
- KAS 앞의 프록시는 연결의 최대 수명에 영향을 줄 수 있습니다. GitLab.com에서는 두 시간입니다. 유예 기간은 최대 수명의 50%입니다.
채널 라우팅에 대한 자세한 정보는 에이전트에서 KAS 요청 라우팅을 참조하세요.
Kubernetes 통합 용어집
이 용어집은 GitLab Kubernetes 통합과 관련된 용어에 대한 정의를 제공합니다.
용어 | 정의 | 범위 |
---|---|---|
GitLab Kubernetes 클러스터용 에이전트 | ‘에이전트k’와 ‘kas’라는 하위 컴포넌트 및 관련 기능을 포함한 전체 제공 | GitLab, Kubernetes, Flux |
‘에이전트k’ | Kubernetes 관리 및 배포 자동화를 위해 GitLab과 안전한 연결을 유지하는 클러스터 측 컴포넌트 | GitLab |
GitLab Kubernetes 클러스터용 에이전트 서버 (‘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 |