GitLab과 Kubernetes 클러스터 연결하기
- Flux는 GitLab 15.10에서의 권장하는 GitOps 솔루션입니다.
클라우드 네이티브 솔루션을 배포, 관리 및 모니터링 하기 위해 Kubernetes 클러스터를 GitLab에 연결할 수 있습니다.
Kubernetes 클러스터를 GitLab에 연결하려면 먼저 클러스터에 에이전트를 설치해야 합니다.
에이전트는 클러스터에서 실행되며 다음과 같은 작업을 수행할 수 있습니다:
- 방화벽 또는 NAT 뒤에 있는 클러스터와 통신합니다.
- 클러스터의 API 엔드포인트에 실시간으로 액세스합니다.
- 클러스터에서 발생하는 이벤트에 관한 정보를 제공합니다.
- 매우 낮은 대기 시간으로 최신 상태를 유지하는 Kubernetes 객체의 캐시를 활성화합니다.
에이전트의 목적과 아키텍처에 대한 자세한 내용은 아키텍처 문서를 참조하십시오.
GitLab에 연결하려는 클러스터마다 별도의 에이전트를 배포해야 합니다. 에이전트는 강력한 멀티테넌시 지원이 되도록 설계되었습니다. 유지보수 및 운영을 간소화하기 위해 각 클러스터당 하나의 에이전트를 실행하는 것이 좋습니다.
에이전트는 항상 GitLab 프로젝트에 등록됩니다. 에이전트가 등록되고 설치된 후에는 클러스터와의 에이전트 연결을 다른 프로젝트, 그룹 및 사용자와 공유할 수 있습니다. 이 방식은 에이전트 인스턴스를 GitLab 자체에서 관리하고 구성할 수 있으며 단일 설치를 다중 테넌트로 확장할 수 있음을 의미합니다.
수용하는 에이전트
수용하는 에이전트를 사용하면 GitLab이 네트워크 연결을 설정할 수 없는 Kubernetes 클러스터와 통합할 수 있습니다. 예를 들어, 다음 상황에서 이런 일이 발생할 수 있습니다:
- GitLab이 사설 네트워크 또는 방화벽 뒤에서 실행되며 VPN을 통해서만 접근할 수 있는 경우.
- Kubernetes 클러스터가 클라우드 제공 업체에 의해 호스팅되지만 인터넷에 노출되거나 사설 네트워크에서 접근할 수 있는 경우.
이 기능이 활성화된 경우 GitLab은 제공된 URL로 에이전트에 연결합니다. 에이전트와 수용하는 에이전트를 동시에 사용할 수 있습니다.
GitLab 기능에 지원되는 Kubernetes 버전
GitLab은 다음 Kubernetes 버전을 지원합니다. Kubernetes 클러스터에서 GitLab을 실행하려는 경우 다른 버전의 Kubernetes가 필요할 수 있습니다.
언제든지 지원되는 버전으로 Kubernetes 버전을 업그레이드할 수 있습니다:
- 1.30 (GitLab 버전 18.2가 출시되거나 1.33이 지원되기 시작하면 지원이 종료됨)
- 1.29 (GitLab 버전 17.10이 출시되거나 1.32가 지원되기 시작하면 지원이 종료됨)
- 1.28 (GitLab 버전 17.5가 출시되거나 1.31이 지원되기 시작하면 지원이 종료됨)
GitLab은 새로운 Kubernetes 버전이 초기 출시 후 3개월 후에 새로운 마이너 버전을 지원하기 위해 노력합니다. GitLab은 언제나 적어도 세 가지 상용화 준비가 된 Kubernetes 마이너 버전을 지원합니다.
새로운 Kubernetes 버전이 출시되면 다음과 같은 일을 수행합니다:
- 우리의 초기 스모크 테스트 결과를 약 4주 내에 이 페이지에 업데이트합니다.
- 새로운 버전 지원의 지연이 예상된다면 약 8주 내에 이 페이지에 예상되는 GitLab 지원 버전을 업데이트합니다.
에이전트를 설치할 때, Kubernetes 버전과 호환되는 Helm 버전을 사용해야 합니다. 다른 버전의 Helm은 작동하지 않을 수 있습니다. 호환되는 버전의 목록은 Helm 버전 지원 정책을 참조하십시오.
폐기된 API에 대한 지원은 폐기된 API만을 지원하는 Kubernetes 버전에 대한 지원이 중단될 때 GitLab 코드베이스에서 제거될 수 있습니다.
여기에 나열된 버전 외에도 일부 GitLab 기능이 다른 버전에서 작동할 수 있습니다. 이 이야기는 Kubernetes 버전 지원을 추적합니다.
Kubernetes 배포 워크플로우
두 가지 주요 워크플로 중에서 선택할 수 있습니다. GitOps 워크플로를 권장합니다.
GitOps 워크플로우
GitLab은 GitOps에 대해 Flux를 권장합니다. 시작하려면 튜토리얼: GitOps용 Flux 설정을 참조하십시오.
GitLab CI/CD 워크플로우
CI/CD 워크플로에서는 GitLab CI/CD를 구성하여 Kubernetes API를 사용하여 클러스터를 쿼리하고 업데이트합니다.
이 워크플로는 GitLab CI/CD에서 클러스터로 요청을 푸시하기 때문에 ‘푸시 기반’으로 간주됩니다.
이 워크플로는 보안 모델이 약합니다. 프로덕션 배포에는 CI/CD 워크플로를 사용해서는 안 됩니다.
에이전트는 통신을 위해 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
| Kubernetes 관리 및 배포 자동화를 위한 GitLab의 클러스터 측 구성 요소 | GitLab |
Kubernetes용 GitLab 에이전트 서버(kas)
| Kubernetes 에이전트 통합에 대한 운영 및 논리를 처리하는 GitLab 측 구성 요소. GitLab과 Kubernetes 클러스터 간의 연결 및 통신을 관리합니다. | GitLab |
| 풀 기반 배포 | 변경 내용을 자동으로 클러스터에 적용하는 방법으로 Flux가 Git 저장소의 변경 사항을 확인하여 적용합니다. | GitLab, Kubernetes |
| 푸시 기반 배포 | 업데이트를 GitLab CI/CD 파이프라인에서 Kubernetes 클러스터로 전송하는 배포 방법 | GitLab |
| Flux | Pull 기반 배포에 대한 오픈 소스 GitOps 도구 | GitOps, Kubernetes |
| GitOps | 클라우드 및 Kubernetes 리소스의 관리 및 자동화에 Git을 사용하는 관행 | DevOps, Kubernetes |
| Kubernetes 네임스페이스 | Kubernetes 클러스터의 논리적 파티션으로 클러스터 리소스를 여러 사용자 또는 환경 사이에 분리합니다. | Kubernetes |
도움말