GitLab과 Kubernetes 클러스터 연결하기

  • GitLab 15.10에서 권장되는 GitOps 솔루션인 Flux입니다.

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

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

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

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

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

GitLab에 연결할 모든 클러스터에 별도의 에이전트를 배포해야 합니다.

에이전트는 강력한 다중 테넌시 지원으로 설계되었습니다. 관리 및 운영을 단순화하기 위해 클러스터당 한 개의 에이전트만 실행하는 것이 좋습니다.

에이전트는 항상 GitLab 프로젝트에 등록됩니다.

에이전트가 등록되고 설치된 후, 클러스터에 대한 에이전트 연결은 다른 프로젝트, 그룹 및 사용자와 공유할 수 있습니다.

이 접근 방식은 GitLab에서 에이전트 인스턴스를 관리 및 구성할 수 있음을 의미하며,

단일 설치를 여러 테넌트로 확장할 수 있습니다.

수신 에이전트

Tier: Ultimate Offering: Self-managed

수신 에이전트를 통해 GitLab은 GitLab 인스턴스로 네트워크 연결을 설정할 수 없는 Kubernetes 클러스터와 통합할 수 있습니다. 그러나 GitLab에 의해 연결될 수 있습니다. 예를 들어, 다음과 같은 경우에 발생할 수 있습니다:

  1. GitLab이 사설 네트워크 또는 방화벽 뒤에서 실행되며, VPN을 통해서만 접근할 수 있는 경우입니다.
  2. 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에 대한 지원은 더 이상 지원하지 않는 Kubernetes 버전에 대한 지원을 중단할 때 GitLab 코드베이스에서 제거될 수 있습니다.

일부 GitLab 기능은 여기에 나열되지 않은 버전에서도 작동할 수 있습니다. 이 에픽은 Kubernetes 버전에 대한 지원을 추적합니다.

Kubernetes 배포 워크플로우

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

GitOps 워크플로우

GitLab은 Flux for GitOps를 사용하는 것을 권장합니다. 시작하려면 튜토리얼: 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 자체에 의해 결정됩니다.
  • 각 연결은 최대 두 시간의 수명을 가지며, 한 시간의 유예 기간이 있습니다.
    • KAS 앞의 프록시는 연결의 최대 수명에 영향을 미칠 수 있습니다. GitLab.com에서는 두 시간입니다. 유예 기간은 최대 수명의 50%입니다.

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

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
Pull-based deployment Flux가 Git 저장소에서 변경 사항을 확인하고 이러한 변경 사항을 클러스터에 자동으로 적용하는 배포 방법. GitLab, Kubernetes
Push-based deployment GitLab CI/CD 파이프라인에서 Kubernetes 클러스터로 업데이트가 전송되는 배포 방법. GitLab
Flux 풀 기반 배포를 위한 에이전트와 통합되는 오픈 소스 GitOps 도구. GitOps, Kubernetes
GitOps 클라우드 및 Kubernetes 리소스의 관리 및 자동화에 있어 버전 관리를 위해 Git을 사용하는 일련의 관행. DevOps, Kubernetes
Kubernetes namespace 여러 사용자 또는 환경 간에 클러스터 리소스를 나누는 Kubernetes 클러스터의 논리적 분할. Kubernetes

관련 주제