쿠버네티스 클러스터를 사용한 GitOps

Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated
  • GitLab 15.3에서 GitLab 프리미엄에서 GitLab 무료로 이동되었습니다.
  • GitLab 15.7에서 id 어트리뷰트가 옵셔널하게 변경되었습니다.
  • Kubernetes 매니페스트 파일을 가져오기 위해 브랜치, 태그 또는 커밋 참조를 지정하는 기능이 GitLab 15.7에 도입되었습니다.
  • GitLab 16.1에서 GitOps를 위해 Flux를 우선순위로 변경했습니다.

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

GitOps를 사용하면 컨테이너화된 클러스터 및 응용 프로그램을 시스템의 진실의 단일 출처로 운영하는 단일 위치가 됩니다.

GitLab, Kubernetes 및 GitOps를 결합하여 다음을 구현할 수 있습니다. - GitLab은 GitOps 오퍼레이터로 사용합니다. - Kubernetes은 자동화 및 수렴 시스템으로 사용합니다. - GitLab CI/CD는 지속적 통합에 사용합니다. - 지속적 배포 및 클러스터 관측을 위한 에이전트를 사용합니다. - 내장된 자동 드리프트 복구 - 투명한 다중 액터 필드 관리를 위해 서버 측 적용를 사용하여 리소스 관리

배포 시퀀스

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

%%{init: { "fontFamily": "GitLab Sans" }}%% sequenceDiagram accTitle: 배포 시퀀스 accDescr: GitOps 배포의 리포지토리 및 주요 액터를 보여줍니다. participant D as 개발자 participant A as 응용 프로그램 코드 리포지토리 participant M as 배포 리포지토리 participant R as OCI 레지스트리 participant C as 에이전트 구성 리포지토리 participant K as GitLab 에이전트 participant F as Flux loop 정기적으로 K-->>C: 구성 가져오기 end D->>+A: 코드 변경 푸시 A->>M: 매니페스트 업데이트 M->>R: OCI artefact 빌드 M->>K: 알림 K->>F: 알림 및 동기화 모니터링 R-->>F: 변경 추적 및 적용 K->>M: 동기화 후 알림

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

소스 제어를 위한 OCI

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

OCI 레지스트리 Git 리포지토리
대규모 컨테이너 이미지 제공에 최적화되어 있습니다. 버전 및 소스 코드 저장에 최적화되어 있습니다.
불변하며, 보안 스캔을 지원합니다. 가변적입니다.
기본 Git 브랜치는 동기화를 트리거하지 않고 클러스터 상태를 저장할 수 있습니다. 기본 Git 브랜치는 클러스터 상태를 저장할 때 동기화를 트리거합니다.

리포지토리 구조

구성을 간소화하려면 팀 당 하나의 배달 리포지토리를 사용해야 합니다. 하나의 응용 프로그램 당 여러 개의 OCI 이미지로 배달 리포지토리를 패키징할 수 있습니다.

추가적인 리포지토리 구조 권장 사항은 Flux 문서를 참조하십시오.

즉시 Git 리포지토리 조정

  • GitLab 16.1에 notify_kas_on_git_push라는 플래그로 도입되었습니다. 기본적으로 비활성화됩니다.
  • GitLab 16.2에서 GitLab.com 및 self-managed에서 활성화되었습니다.
  • GitLab 16.3에서 피쳐 플래그가 제거되었습니다.

보통 Flux 소스 컨트롤러는 구성된 간격마다 Git 리포지토리를 조정합니다. 이는 git push와 클러스터 상태 조정 사이에 지연을 일으킬 수 있고, GitLab에서 불필요한 풀을 유발합니다.

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

즉시 Git 리포지토리 조정을 사용하려면 다음이 있어야 합니다. - Kubernetes 클러스터 - 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

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

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

적절한 서비스 프록시 URL을 구성하는 것이 중요합니다. ```

토큰 관리

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

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

Flux에서의 GitLab 액세스

컨테이너 레지스트리 또는 Git 저장소에 액세스하기 위해 Flux가 사용할 수 있는 것:

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

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

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

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

Flux에서 GitLab 알림

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

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

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

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

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

관련 주제