Kubernetes용 에이전트와 Flux를 함께 사용하면 GitOps로 Kubernetes에 배포할 때 가장 나은 경험을 얻을 수 있습니다. GitLab은 배포에 GitOps(풀 기반 배포라고도 함)를 사용할 것을 권장합니다. 다만 회사 사정으로 GitOps로 전환하지 못하거나, 특정한(대개 비프로덕션) 이유로 파이프라인 기반 방식을 써야 할 수 있습니다. 이 페이지에서는 엔터프라이즈 환경에서 GitOps를 사용하는 모범 사례와 파이프라인 기반 배포에 대한 고려 사항을 설명합니다.

GitOps의 장점에 대한 설명은 OpenGitOps 이니셔티브를 참고합니다.

GitOps#

• Kubernetes 클러스터를 GitLab에 연결하기에서는 Flux CLI로 Flux를 설치하는 방법을 설명하지만, Flux 배포를 확장하고 자동화하려면 다음 중 하나를 사용합니다.
  • Flux Operator를 사용합니다.
  • Terraform 또는 OpenTofu로 설치합니다.
• 멀티테넌시 잠금으로 Flux를 구성합니다.
• 확장을 위해 Flux는 수직 확장과 수평 샤딩을 지원합니다.
• Flux 관련 지침은 Flux 문서의 Flux 가이드를 참고합니다.
• 유지 관리를 단순화하려면 클러스터당 GitLab Kubernetes 에이전트를 하나만 설치해 실행합니다. 가장 기능을 사용해 GitLab 도메인 전체에서 에이전트 연결을 공유할 수 있습니다.
• 매니페스트를 저장하고 가져올 때 Flux OCIRepository 사용을 고려합니다. GitLab 파이프라인으로 OCI 이미지를 빌드해 컨테이너 레지스트리에 푸시할 수 있습니다.
• 피드백 루프를 단축하려면 관련 GitLab 파이프라인에서 GitOps 조정을 즉시 트리거합니다.
• 생성된 OCI 이미지에는 서명을 하고, Flux가 서명을 검증한 이미지만 배포합니다.
• Flux가 매니페스트에 접근할 때 사용하는 키는 정기적으로 교체합니다. 에이전트 등록 토큰도 정기적으로 교체합니다.

OCI 컨테이너#

Git 리포지터리 대신 OCI 컨테이너를 사용하더라도 매니페스트의 정본은 여전히 Git 리포지터리입니다. OCI 컨테이너는 Git 리포지터리와 클러스터 사이의 캐시 레이어로 볼 수 있습니다.

OCI 컨테이너를 사용하면 다음과 같은 이점이 있습니다.

• OCI는 확장성을 염두에 두고 설계되었습니다. GitLab Git 리포지터리도 잘 확장되지만, 이러한 용도를 위해 설계되지는 않았습니다.
• 하나의 Git 리포지터리가 여러 OCI 컨테이너의 소스가 될 수 있고, 각 컨테이너는 소수의 매니페스트만 패키징합니다. 이렇게 하면 매니페스트 집합이 필요할 때 Git 리포지터리 전체를 내려받지 않아도 됩니다.
• OCI 리포지터리는 널리 쓰이는 버전 관리 체계를 따를 수 있고, Flux는 그 체계에 맞춰 자동 업데이트하도록 구성할 수 있습니다. 예를 들어 시맨틱 버전 관리를 사용하면 Flux가 마이너 및 패치 변경 사항은 모두 자동으로 배포하고, 메이저 버전은 수동 업데이트가 필요합니다.
• OCI 이미지는 서명할 수 있고, 그 서명을 Flux가 검증할 수 있습니다.
• OCI 리포지터리는 이미지를 빌드한 뒤에도 컨테이너 레지스트리에서 스캔할 수 있습니다.
• OCI 컨테이너를 빌드하는 job 덕분에 일반 GitOps 도구가 지원하지 않는 보호된 환경, 배포 승인, 배포 동결 기간 같은 익숙한 릴리스 관리 기능을 사용할 수 있습니다.

파이프라인 기반 배포#

파이프라인 기반 배포를 사용해야 한다면 다음 모범 사례를 따릅니다.

• 클러스터당 배포되는 에이전트 수를 줄이려면 그룹과 프로젝트 전체에서 에이전트 연결을 공유합니다. 가능하면 클러스터당 에이전트 배포를 하나만 사용합니다.
• 가장 기능을 사용하고, 일반 Kubernetes RBAC로 클러스터 내 CI/CD job의 접근 범위를 최소화합니다.