Kubernetes 클러스터에서 GitOps 사용하기
- 이동함 GitLab Premium에서 15.3 버전부터 GitLab Free로 이동되었습니다.
- GitLab 15.7에 id 속성을 선택 사항으로 변경하였습니다.
- GitLab 15.7 버전에서 브랜치, 태그 또는 커밋 참조를 지정하여 Kubernetes 매니페스트 파일을 가져오기 소개되었습니다.
- GitLab 16.1 버전에서 Flux를 GitOps로 우선순위를 매기도록 변경되었습니다.
GitLab은 GitOps에 Flux를 통합합니다. Flux 시작 방법은 GitOps 튜토리얼을 참조하세요.
GitOps를 통해 컨테이너화된 클러스터 및 애플리케이션을 다음과 같이 Git 리포지터리에서 관리할 수 있습니다:
- 시스템의 진실된 단일 원본입니다.
- 시스템을 운영하는 유일한 장소입니다.
GitLab, Kubernetes 및 GitOps를 결합함으로써 다음을 얻을 수 있습니다:
- GitLab이 GitOps 연산자로 작동합니다.
- Kubernetes가 자동화 및 수렴 시스템으로 작동합니다.
- GitLab CI/CD가 지속적 통합을 제공합니다.
- 클러스터 관찰을 위한 Continuous Deployment 및 에이전트를 제공합니다.
- 기본 자동 drift remediation을 제공합니다.
- 투명한 다중 액터 필드 관리를 위해 서버 측 적용로 리소스 관리를 제공합니다.
배포 순서
이 다이어그램은 GitOps 배포에서의 리포지터리와 주요 액터를 보여줍니다:
GitOps 배포에는 Flux와 agentk
를 모두 사용해야 합니다. Flux는 클러스터 상태를 소스와 동기화하는 반면, agentk
는 Flux 설정을 간소화하고, 클러스터에서 GitLab 액세스 관리를 제공하며, GitLab UI에서 클러스터 상태를 시각화합니다.
소스 제어를 위한 OCI
Flux를 위한 소스 컨트롤러로 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
객체를 자동으로 감지하고,
인스턴스에 대한 Receiver
를 구성합니다.
Kubernetes용 에이전트가 액세스할 수 있는 리포지터리에 git push
를 감지하면 Receiver
가 트리거되고 Flux는 리포지터리의 변경 내용으로 클러스터를 조정합니다.
즉시 Git 리포지터리 조정을 사용하려면 다음이 실행되어야 합니다:
- Kubernetes 클러스터에서 에이전트를 실행합니다.
- Flux
source-controller
및notification-controller
가 실행 중입니다.
즉시 Git 리포지터리 조정은 푸시와 조정 간의 시간을 단축시킬 수 있지만, 모든 git push
이벤트가 수신되는 것을 보장하지는 않습니다. 여전히 GitRepository.spec.interval
을 적절한 기간으로 설정해야 합니다.
사용자 지정 웹훅 엔드포인트
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를 구성하지 않은 경우에 사용할 수 있습니다.
토큰 관리
특정 Flux 기능을 사용하려면 여러 액세스 토큰이 필요할 수 있습니다. 또한 동일한 결과를 얻기 위해 여러 토큰 유형을 사용할 수 있습니다.
이 섹션에서는 필요한 토큰에 대한 지침을 제공하고 가능한 경우 토큰 유형을 권장합니다.
Flux를 통한 GitLab 액세스
GitLab 컨테이너 레지스트리 또는 Git 리포지터리에 액세스하기 위해 Flux가 사용할 수 있는 토큰:
- 프로젝트 또는 그룹 배포 토큰
- 프로젝트 또는 그룹 배포 키
- 프로젝트 또는 그룹 액세스 토큰
- 개인 액세스 토큰
이 토큰에는 쓰기 권한이 필요하지 않습니다.
만약 http
액세스가 가능하다면 프로젝트 배포 토큰을 사용해야 합니다.
git+ssh
액세스가 필요한 경우 배포 키를 사용해야 합니다.
배포 키와 배포 토큰을 비교하려면 Deploy keys를 참조하세요.
프로젝트 배포 토큰의 자동 생성, 회전 및 보고 지원이 issue 389393에서 제안되고 있습니다.
Flux에서 GitLab 알림
만약 Flux를 구성하여 Git 소스에서 동기화하면, Flux는 GitLab 파이프라인에서 외부 작업 상태를 등록할 수 있습니다.
Flux에서 외부 작업 상태를 받으려면 다음을 사용할 수 있습니다:
- 프로젝트 또는 그룹 배포 토큰.
- 프로젝트 또는 그룹 액세스 토큰.
- 개인 액세스 토큰.
토큰에는 api
스코프가 필요합니다. 유출된 토큰의 공격 표면을 최소화하기 위해 프로젝트 액세스 토큰을 사용해야 합니다.
Flux를 GitLab 파이프라인에 작업으로 통합하는 것은 이슈 405007에서 제안되었습니다.
관련 주제
- 학습 및 데모용 GitOps 작동 예제
- 자율학습 교실 워크샵 (AWS EKS를 사용하지만 다른 Kubernetes 클러스터에도 사용할 수 있음)
- GitOps 워크플로에 Kubernetes 시크릿 관리