GitLab에 Kubernetes 클러스터 연결

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

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

에이전트는 클러스터에서 실행되며, 이를 사용하여 다음과 같은 작업을 할 수 있습니다:

• 방화벽 또는 NAT 뒤에 있는 클러스터와 통신합니다.

• 클러스터의 API 엔드포인트에 실시간으로 액세스합니다.

• 클러스터에서 발생하는 이벤트에 대한 정보를 푸시합니다.

• 매우 짧은 지연 시간으로 최신 상태로 유지되는 Kubernetes 개체 캐시를 사용 설정합니다.

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

GitLab에 연결하려는 모든 클러스터에 별도의 에이전트를 배포해야 합니다. 에이전트는 강력한 멀티테넌시 지원을 위해 설계되었습니다. 유지 관리 및 운영을 간소화하려면 클러스터당 하나의 에이전트만 실행해야 합니다.

에이전트는 항상 GitLab 프로젝트에 등록됩니다. 에이전트를 등록하고 설치하면 클러스터에 대한 에이전트 연결을 다른 프로젝트, 그룹 및 사용자와 공유할 수 있습니다. 이 접근 방식은 GitLab 자체에서 에이전트 인스턴스를 관리하고 구성할 수 있으며 단일 설치를 여러 테넌트로 확장할 수 있음을 의미합니다.

수신 에이전트

티어 Ultimate
제공: 자체 관리형

수신 에이전트를 사용하면 GitLab 인스턴스에 대한 네트워크 연결을 설정할 수 없지만 GitLab에서 연결할 수 있는 Kubernetes 클러스터와 통합할 수 있습니다. 예를 들어 다음과 같은 경우에 발생할 수 있습니다:

1. GitLab이 사설 네트워크 또는 방화벽 뒤에서 실행되며 VPN을 통해서만 액세스할 수 있는 경우.

2. 클라우드 제공업체에서 호스팅하지만 인터넷에 노출되어 있거나 프라이빗 네트워크에서 연결할 수 있는 경우.

이 기능이 활성화되면 GitLab은 제공된 URL로 에이전트에 연결합니다. 에이전트와 수신 에이전트를 동시에 사용할 수 있습니다.

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

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

• For the Helm Chart.

• For GitLab Operator.

언제든지 지원되는 버전으로 업그레이드할 수 있습니다:

• 1.31 (GitLab 버전 18.7이 릴리스되거나 1.34가 지원되면 지원이 종료됨)

• 1.30 (GitLab 버전 18.2가 릴리스되거나 1.33이 지원되면 지원이 종료됨)

• 1.29 (GitLab 버전 17.10이 릴리스되거나 1.32가 지원되면 지원이 종료됨)

GitLab은 최초 릴리스 후 3개월 후에 새로운 마이너 Kubernetes 버전을 지원하는 것을 목표로 합니다. GitLab은 언제든지 프로덕션에 사용할 수 있는 최소 3개의 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 워크플로에서, 클러스터를 쿼리하고 업데이트하기 위해 Kubernetes API를 사용하도록 GitLab CI/CD를 구성합니다.

이 워크플로는 푸시 기반으로 간주되는데, 그 이유는 GitLab CI/CD에서 클러스터로 요청을 푸시하기 때문입니다.

다음과 같은 경우 이 워크플로를 사용하세요:

• 파이프라인 기반 프로세스가 있는 경우.

• 에이전트로 마이그레이션해야 하지만 GitOps 워크플로우가 사용 사례를 지원하지 않는 경우.

이 워크플로에는 보안 모델이 취약한 경우. 프로덕션 배포에는 CI/CD 워크플로우를 사용해서는 안 됩니다.

에이전트 연결 기술 세부 정보

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

• 각 에이전트는 활성 및 유휴 스트림을 포함하여 최대 500개의 논리적 gRPC 스트림을 유지할 수 있습니다.

• gRPC 스트림에 사용되는 TCP 연결 수는 gRPC 자체에 의해 결정됩니다.

• 각 연결의 최대 수명은 2시간이며, 1시간의 유예 기간이 있습니다.

  • KAS 앞의 프록시는 최대 연결 수명에 영향을 미칠 수 있습니다. http://GitLab.com 에서는 2시간입니다. 유예 기간은 최대 수명의 50%입니다.

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

쿠버네티스 통합 용어집

이 용어집에서는 GitLab Kubernetes 연동과 관련된 용어에 대한 정의를 제공합니다.