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 도메인 전체에서 가장(impersonation) 기능을 사용하여 에이전트 연결을 공유할 수 있습니다.
• 매니페스트 저장 및 검색을 위해 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 컨테이너를 빌드하는 작업을 통해 일반 GitOps 도구가 지원하지 않는 보호된 환경, 배포 승인, 배포 동결 기간과 같은 잘 알려진 릴리스 관리 기능을 사용할 수 있습니다.

파이프라인 기반 배포#

파이프라인 기반 배포를 사용해야 하는 경우 다음 모범 사례를 따르십시오.

• 클러스터당 배포되는 에이전트 수를 줄이려면 그룹 및 프로젝트 전체에서 에이전트 연결을 공유하십시오. 가능하면 클러스터당 하나의 에이전트 배포만 사용하십시오.
• 가장(impersonation)을 사용하고, 일반 Kubernetes RBAC를 사용하여 클러스터 내 CI/CD 작업의 접근을 최소화하십시오.