GitOps를 사용한 Kubernetes 클러스터
GitLab은 GitOps를 위해 Flux와 통합됩니다.
Flux를 시작하려면 GitOps 튜토리얼을 참조하세요.
GitOps를 사용하면 다음의 Git 리포지토리에서 컨테이너화된 클러스터와 애플리케이션을 관리할 수 있습니다:
- 시스템의 단일 진실 출처입니다.
- 시스템을 운영하는 단일 장소입니다.
GitLab, Kubernetes 및 GitOps를 결합하면 다음과 같은 결과를 얻을 수 있습니다:
- GitOps 운영자로서의 GitLab.
- 자동화 및 수렴 시스템으로서의 Kubernetes.
- 지속적 통합을 위한 GitLab CI/CD.
- 지속적 배포 및 클러스터 관찰성을 위한 에이전트.
- 자동 드리프트 수정 기능 내장.
- 투명한 다중 행위자 필드 관리를 위한 서버 측 적용으로 리소스 관리.
배포 순서
이 다이어그램은 GitOps 배포의 리포지토리 및 주요 행위를 보여줍니다:
GitOps 배포를 위해 Flux와 agentk를 모두 사용해야 합니다. Flux는 클러스터 상태를 소스와 동기화하며, agentk는 Flux 설정을 간소화하고, 클러스터와 GitLab 접근 관리를 제공하며, GitLab UI에서 클러스터 상태를 시각화합니다.
소스 제어를 위한 OCI
OCI 이미지를 Flux의 소스 컨트롤러로 사용해야 하며, Git 리포지토리는 사용하지 말아야 합니다. GitLab 컨테이너 레지스트리는 OCI 이미지를 지원합니다.
| OCI 레지스트리 | Git 리포지토리 |
|---|---|
| 대규모로 컨테이너 이미지를 제공하도록 설계됨. | 소스 코드를 버전 관리하고 저장하도록 설계됨. |
| 변경 불가능하며, 보안 검사 지원. | 변경 가능. |
| 기본 Git 브랜치는 동기화를 트리거하지 않고 클러스터 상태를 저장할 수 있습니다. | 기본 Git 브랜치는 클러스터 상태를 저장할 때 동기화를 트리거합니다. |
저장소 구조
구성을 간소화하기 위해 팀당 하나의 배포 저장소를 사용하십시오.
배포 저장소를 애플리케이션당 여러 OCI 이미지로 패키징할 수 있습니다.
추가적인 저장소 구조 권장 사항은 Flux 문서를 참조하세요.
즉각적인 Git 저장소 조정
- GitLab 16.1에 도입됨
notify_kas_on_git_push라는 플래그와 함께. 기본적으로 비활성화됨.- GitLab 16.2에서 GitLab.com 및 자체 관리에서 활성화됨.
- GitLab 16.3에서 기능 플래그가 제거됨.
일반적으로 Flux 소스 컨트롤러는 설정된 간격으로 Git 저장소를 조정합니다.
이는 git push와 클러스터 상태 조정 간의 지연을 초래할 수 있으며,
GitLab에서 불필요한 풀을 초래합니다.
Kubernetes에 대한 에이전트는 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이기도 합니다.
사용자 정의 엔드포인트를 구성하려면,
에이전트가 해결할 수 있는 URL로 flux.webhook_receiver_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 엔드포인트에 연결합니다.
클러스터 외부에서 에이전트를 실행하고 Flux 알림 컨트롤러에 대한 ‘인그레스’를 구성하지 않았다면 이를 사용할 수 있습니다.
경고:
신뢰할 수 있는 서비스 프록시 URL만 구성해야 합니다.
서비스 프록시 URL을 제공하면,
Kubernetes에 대한 에이전트는 API 서비스에 인증하기 위해 필요한
자격 증명을 포함하는 일반적인 Kubernetes API 요청을 보냅니다.
토큰 관리
특정 Flux 기능을 사용하려면 여러 개의 액세스 토큰이 필요할 수 있습니다. 추가로, 동일한 결과를 얻기 위해 여러 유형의 토큰을 사용할 수 있습니다.
이 섹션에서는 필요할 수 있는 토큰에 대한 가이드라인을 제공하고, 가능한 경우 토큰 유형 추천을 제공합니다.
Flux를 통한 GitLab 액세스
GitLab 컨테이너 레지스트리나 Git 리포지토리에 액세스하기 위해 Flux는 다음을 사용할 수 있습니다:
- 프로젝트 또는 그룹 배포 토큰.
- 프로젝트 또는 그룹 배포 키.
- 프로젝트 또는 그룹 액세스 토큰.
- 개인 액세스 토큰.
토큰은 쓰기 권한이 필요하지 않습니다.
http 액세스가 가능하면 프로젝트 배포 토큰을 사용해야 합니다.
git+ssh 액세스가 필요한 경우 배포 키를 사용해야 합니다.
배포 키와 배포 토큰을 비교하려면 배포 키를 참조하세요.
배포 토큰 생성, 회전 및 보고를 자동화하는 지원은 이슈 389393에서 제안되었습니다.
GitLab 알림을 위한 Flux
Flux를 Git 소스와 동기화하도록 구성하면, Flux는 GitLab 파이프라인에서 외부 작업 상태를 등록할 수 있습니다.
Flux에서 외부 작업 상태를 가져오려면 다음을 사용할 수 있습니다:
- 프로젝트 또는 그룹 배포 토큰.
- 프로젝트 또는 그룹 액세스 토큰.
- 개인 액세스 토큰.
토큰은 api 범위가 필요합니다. 유출된 토큰의 공격 표면을 최소화하기 위해 프로젝트 액세스 토큰을 사용하는 것이 좋습니다.
Flux를 GitLab 파이프라인에 작업으로 통합하는 것은 이슈 405007에서 제안되었습니다.
관련 주제
- 훈련 및 데모를 위한 GitOps 작업 예시
- 자가 주도형 강의실 워크숍 (AWS EKS 사용, 하지만 다른 Kubernetes 클러스터에도 사용할 수 있습니다)
- GitOps 워크플로에서 Kubernetes 비밀 관리
도움말