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

Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-Managed, GitLab Dedicated

GitLab은 GitOps에 Flux를 통합합니다. Flux 시작 방법은 GitOps 튜토리얼을 참조하세요.

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

  • 시스템의 진실된 단일 원본입니다.
  • 시스템을 운영하는 유일한 장소입니다.

GitLab, Kubernetes 및 GitOps를 결합함으로써 다음을 얻을 수 있습니다:

  • GitLab이 GitOps 연산자로 작동합니다.
  • Kubernetes가 자동화 및 수렴 시스템으로 작동합니다.
  • GitLab CI/CD가 지속적 통합을 제공합니다.
  • 클러스터 관찰을 위한 Continuous Deployment 및 에이전트를 제공합니다.
  • 기본 자동 drift remediation을 제공합니다.
  • 투명한 다중 액터 필드 관리를 위해 서버 측 적용로 리소스 관리를 제공합니다.

배포 순서

이 다이어그램은 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 Regularly 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에서 제안되고 있습니다.

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

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에 대한 특수 처리가 있습니다. 이 예시는 다음과 같습니다: 

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

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

caution
신뢰할 수 있는 서비스 프록시 URL만 구성해야 합니다. 서비스 프록시 URL을 제공하면 Kubernetes용 에이전트는 API 서비스의 인증에 필요한 자격 증명을 포함하는 일반적인 Kubernetes API 요청을 보냅니다.

토큰 관리

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

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

Flux를 통한 GitLab 액세스

GitLab 컨테이너 레지스트리 또는 Git 리포지터리에 액세스하기 위해 Flux가 사용할 수 있는 토큰:

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

이 토큰에는 쓰기 권한이 필요하지 않습니다.

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

프로젝트 배포 토큰의 자동 생성, 회전 및 보고 지원이 issue 389393에서 제안되고 있습니다.

Flux에서 GitLab 알림

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

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

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

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

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

관련 주제