Kubernetes 클러스터에서 GitOps 사용하기

Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-managed, 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 15.3에서 GitLab Premium에서 GitLab Free로 이동되었습니다.
  • GitLab 15.7에서 id 속성이 선택 사항으로 변경되었습니다.(변경됨)
  • GitLab 15.7에서 브랜치, 태그 또는 커밋 참조를 지정하여 Kubernetes 매니페스트 파일을 가져오는 것이 도입되었습니다.
  • GitLab 16.1에서 GitOps를 위해 Flux가 우선시되도록 변경되었습니다.

GitLab은 GitOps에 Flux를 통합합니다. Flux를 시작하려면 GitOps 튜토리얼을 참조하십시오.

GitOps를 사용하면 다음과 같은 Git 리포지터리에서 컨테이너화된 클러스터 및 애플리케이션을 관리할 수 있습니다:

  • 시스템의 진실의 단일 진실 공급원입니다.
  • 시스템을 운영하는 유일한 곳입니다.

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

  • GitOps 연산자로서의 GitLab.
  • 자동화 및 수렴 시스템으로서의 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

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

OCI 레지스트리 Git 리포지터리
대규모에서 컨테이너 이미지를 제공하도록 설계되었습니다. 버전 및 소스 코드 저장에 사용됩니다.
변경 불가능하며 보안 스캔을 지원합니다. 가변적입니다.
기본 Git 브랜치는 동기화를 트리거하지 않고 클러스터 상태를 저장할 수 있습니다. 기본 Git 브랜치를 사용하여 클러스터 상태를 저장하면 동기화가 트리거됩니다.

리포지터리 구조

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

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

즉각적인 Git 리포지터리 조화

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

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

즉각적인 Git 리포지터리 조화를 사용하려면 다음이 실행되어야 합니다:

  • Kubernetes 클러스터에 에이전트.
  • Flux source-controller 및 notification-controller.

즉각적인 Git 리포지터리 조화는 푸시와 조화 간의 시간을 줄일 수 있지만, 모든 git push 이벤트가 수신되지는 않습니다. 그래도 여전히 GitRepository.spec.interval 를 적절한 기간으로 설정해야 합니다.

에이전트는 에이전트 구성 프로젝트 및 모든 공개 프로젝트에 액세스할 수 있습니다. 에이전트는 에이전트 구성 프로젝트를 제외하고는 즉시 비공개 프로젝트를 조화시킬 수 없습니다. 에이전트가 비공개 프로젝트에 액세스할 수 있게 하는 것은 이슈 389393에서 제안되었습니다.

사용자 정의 웹훅 엔드포인트

Kubernetes 에이전트가 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에 대한 특별한 처리가 있으며 이 형식으로 구성됩니다: /api/v1/namespaces/[^/]+/services/[^/]+/proxy. 예: 

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

이러한 경우, Kubernetes 에이전트는 사용 가능한 Kubernetes 구성 및 컨텍스트를 사용하여 API 엔드포인트에 연결합니다. 클러스터 외부에서 에이전트를 실행하고 Ingress를 구성하지 않았다면 이 기능을 사용할 수 있습니다.

caution
신뢰할 수 있는 서비스 프록시 URL만 구성해야 합니다. 서비스 프록시 URL을 제공하면 Kubernetes API 요청이 전송되며, 이 요청에는 API 서비스와 인증하는 데 필요한 자격 증명이 포함됩니다.

토큰 관리

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

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

GitLab에 대한 Flux 액세스

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

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

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

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

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

Flux에서 GitLab 알림

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

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

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

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

플럭스를 GitLab 파이프라인에 작업으로 통합하는 것은 이슈 405007에서 제안되었습니다.

관련 주제