쿠버네티스 클러스터에서 GitOps 사용하기

Tier: Free, Premium, Ultimate Offering: GitLab.com, 자체관리, GitLab Dedicated
  • GitLab 13.7에서 소개됨.
  • GitLab 14.0에서 도입됨, resource_inclusions 및 resource_exclusions 속성이 제거되고, reconcile_timeout, dry_run_strategy, prune, prune_timeout, prune_propagation_policy, inventory_policy 속성이 추가됨.
  • GitLab Premium에서 GitLab Free로 이동, 15.3 버전에.
  • GitLab 15.7에서 id 속성이 선택 사항으로 변경됨.
  • GitLab 15.7에서 쿠버네티스 매니페스트 파일을 가져오기 위해 브랜치, 태그 또는 커밋 참조 지정이 도입됨.
  • GitLab 16.1에서 GitOps를 위해 Flux가 우선순위를 가지도록 변경됨.

GitLab은 GitOps를 위해 Flux를 통합합니다. Flux를 시작하려면 GitOps 튜토리얼을 참조하세요.

GitOps를 통해 컨테이너화된 클러스터 및 애플리케이션을 Git 리포지토리에서 관리할 수 있으며, 이를 통해 다음을 달성할 수 있습니다:

  • 시스템의 단일 정보 원천.
  • 시스템을 운영하는 단일 장소.

GitLab, Kubernetes 및 GitOps를 결합하면 다음을 얻을 수 있습니다:

  • GitLab은 GitOps 운영자로.
  • Kubernetes는 자동화 및 수렴 시스템으로.
  • GitLab CI/CD는 지속적 통합용.
  • 지속적 배포 및 클러스터 감시용 에이전트.
  • 내장된 자동 드리프트 복구.
  • 서버 측 적용을 통한 투명한 다중 액터 필드 관리를 통한 자원 관리.

배포 순서

다음 다이어그램은 GitOps 배포에 있는 레포지토리 및 주요 액터를 보여줍니다:

sequenceDiagram participant D as Developer participant A as Application code repository participant M as Deployment repository participant R as OCI registry participant C as Agent configuration repository participant K as GitLab agent participant F as Flux loop 정기적으로 K-->>C: 구성 가져오기 end D->>+A: 코드 변경 푸시 A->>M: 매니페스트 업데이트 M->>R: OCI 아티팩트 빌드 M->>K: 알림 K->>F: 알림 및 동기화 감시 R-->>F: 변경 내용 가져오고 적용 K->>M: 동기화 후 알림

GitOps 배포를 위해 Flux와 agentk를 모두 사용해야 합니다. Flux는 클러스터 상태를 소스와 동기화하고, agentk는 Flux 설정을 간단화하고 클러스터에서 GitLab 접근 제어를 제공하며, GitLab UI에서 클러스터 상태를 시각화합니다.

소스 제어를 위한 OCI

Flux에 소스 컨트롤러로 OCI 이미지를 사용해야 합니다. GitLab 컨테이너 레지스트리에서 OCI 이미지를 지원합니다.

OCI 레지스트리 Git 리포지토리
대규모 컨테이너 이미지 제공을 위해 설계됨. 버전 관리 및 소스 코드 저장을 위해 설계됨.
불변하며, 보안 스캔을 지원함. 가변적임.
기본 Git 브랜치는 클러스터 상태를 저장할 수 있으며 동기화가 트리거되지 않음. 기본 Git 브랜치는 클러스터 상태를 저장하면 동기화가 트리거됨.

레포지토리 구조

구성을 간소화하기 위해 팀 당 한 배달 레포지토리를 사용해야 합니다. 하나의 애플리케이션에 여러 OCI 이미지로 배달 레포지토리를 패키징할 수 있습니다.

추가적인 레포지토리 구조 권장 사항은 Flux 문서를 참조하세요.

즉시 Git 리포지토리 조정

보통 Flux 소스 컨트롤러는 구성된 간격에서 Git 리포지토리를 조정합니다. 이로 인해 git push와 클러스터 상태 조정 간의 지연이 발생할 수 있으며 GitLab에서 불필요한 풀이 발생합니다.

Kubernetes 에이전트는 자동으로 해당 에이전트가 연결된 GitLab 프로젝트를 참조하는 Flux GitRepository 객체를 감지하고, 인스턴스에 대한 Receiver를 구성합니다. Kubernetes 에이전트가 액세스할 수 있는 리포지토리에 대한 git push를 감지하면 Receiver가 트리거되어 Flux가 리포지토리의 변경사항으로 클러스터를 조정합니다.

즉시 Git 리포지토리 조정을 사용하려면 다음이 실행 중인 쿠버네티스 클러스터가 있어야 합니다:

  • Kubernetes 에이전트.
  • Flux source-controller 및 notification-controller.

즉시 Git 리포지토리 조정은 푸시와 조정 간 시간을 줄일 수 있지만, 모든 git push 이벤트가 수신되지는 않음을 보장하지 않습니다. 여전히 GitRepository.spec.interval을 적절한 기간으로 설정해야 합니다.

에이전트는 에이전트 구성 프로젝트 및 모든 공개 프로젝트에만 액세스할 수 있습니다. 에이전트는 에이전트 구성 프로젝트를 제외하고는 빠른 재조정을 할 수 없습니다. 에이전트가 비공개 프로젝트에 액세스할 수 있도록 하는 것은 issue 389393에서 제안되었습니다.

커스텀 웹훅 엔드포인트

쿠버네티스 에이전트가 Receiver 웹훅을 호출할 때, 에이전트는 기본적으로 http://webhook-receiver.flux-system.svc.cluster.local로 기본 설정되어 있으며, 이는 Flux 부트스트랩 설치에서 기본 URL로 설정됩니다. 커스텀 엔드포인트를 구성하려면 flux.webhook_receiver_url을 에이전트가 해석할 수 있는 URL로 설정하십시오. 예를 들면: 

flux:
  webhook_receiver_url: http://webhook-receiver.another-flux-namespace.svc.cluster.local

이 형식으로 서비스 프록시 URL이 구성되어 있는 경우에는 특별한 처리가 있습니다. 

flux:
  webhook_receiver_url: /api/v1/namespaces/flux-system/services/http:webhook-receiver:80/proxy

이러한 경우에 쿠버네티스 에이전트는 사용 가능한 쿠버네티스 구성과 컨텍스트를 사용하여 API 엔드포인트에 연결합니다. 클러스터 외부에서 에이전트를 실행하고 Flux 알림 컨트롤러에 대한 Ingress를 구성하지 않은 경우에 사용할 수 있습니다.

경고: 신뢰할 수 있는 서비스 프록시 URL만 구성해야 합니다. 서비스 프록시 URL을 제공하는 경우, 쿠버네티스 에이전트는 API 서비스와 인증하는 데 필요한 자격 증명을 포함하는 일반적인 쿠버네티스 API 요청을 보냅니다.

토큰 관리

특정 Flux 기능을 사용하려면 여러 액세스 토큰이 필요할 수 있습니다. 또한, 동일한 결과를 얻기 위해 여러 토큰 유형을 사용할 수 있습니다.

이 섹션에서는 필요한 토큰에 대한 지침을 제공하며 가능한 경우 토큰 유형 권장 사항을 제공합니다.

GitLab으로부터의 Flux 액세스

GitLab 컨테이너 레지스트리 또는 Git 리포지토리에 액세스하기 위해, Flux는 다음을 사용할 수 있습니다:

  • 프로젝트 또는 그룹 배포 토큰.
  • 프로젝트 또는 그룹 배포 키.
  • 프로젝트 또는 그룹 액세스 토큰.
  • 개인 액세스 토큰.

토큰에는 쓰기 액세스가 필요하지 않습니다.

만약 http 액세스가 가능하다면 프로젝트 배포 토큰을 사용해야 합니다. git+ssh 액세스가 필요하다면 배포 키를 사용해야 합니다. 배포 키와 배포 토큰을 비교하려면 Deploy keys를 참조하십시오.

배포 토큰 생성, 회전 및 보고 자동화 지원은 이슈 389393에서 제안됩니다.

Flux에서 GitLab으로의 알림

Flux를 구성하여 Git 소스에서 동기화하도록 한 경우, Flux는 GitLab 파이프라인에 외부 작업 상태를 등록할 수 있습니다.

Flux에서 외부 작업 상태를 가져오려면 다음을 사용할 수 있습니다:

  • 프로젝트 또는 그룹 배포 토큰.
  • 프로젝트 또는 그룹 액세스 토큰.
  • 개인 액세스 토큰.

토큰에는 api 스코프가 필요합니다. 누출된 토큰의 공격 표면을 최소화하기 위해 프로젝트 액세스 토큰을 사용해야 합니다.

Flux를 GitLab 파이프라인에 작업으로 통합하는 기능은 이슈 405007에서 제안됩니다.

관련 주제