• GitOps 워크플로 단계
• GitOps 구성 참조
• GitOps 주석
• 자동 드리프트 해결
• 관련 주제
• 문제 해결
  • 여러 프로젝트를 가지고 충돌을 피하는 방법
  • 여러 에이전트 또는 프로젝트 사용

GitOps 에이전트를 쿠버네티스와 사용하기 (폐기된 기능)

- GitLab 13.7에 도입되었습니다.
- GitLab 14.0에 도입되었으며 resource_inclusions 및 resource_exclusions 속성이 제거되었으며 reconcile_timeout, dry_run_strategy, prune, prune_timeout, prune_propagation_policy, 그리고 inventory_policy 속성이 추가되었습니다.
- GitLab 15.3에서 GitLab Premium에서 GitLab Free로 이동되었습니다.
- GitLab 15.7에서 id 속성이 선택 사항으로 변경되었습니다.
- 브랜치, 태그 또는 커밋 참조를 지정하여 쿠버네티스 매니페스트 파일을 가져오는 것이 GitLab 15.7에 도입되었습니다.

이 다이어그램은 GitOps 배포에서 리포지터리와 주요 주체를 보여줍니다.

자세한 내용은 아키텍처 문서를 참조하세요.

GitOps 워크플로 단계

GitOps를 사용하여 Kubernetes 클러스터를 업데이트하려면 다음 단계를 완료하세요.

1. 작동하는 Kubernetes 클러스터가 있고 매니페스트가 GitLab 프로젝트에 있는지 확인합니다.
2. 동일한 프로젝트에서 GitLab 에이전트를 등록하고 설치하세요.
3. 에이전트 구성 파일을 구성하여 에이전트가 Kubernetes 매니페스트에 대한 프로젝트 변경 사항을 모니터링하도록 합니다. GitOps 구성 참조를 참고하세요.

Kubernetes 매니페스트를 업데이트할 때마다 에이전트가 클러스터를 업데이트합니다.

GitOps 구성 참조

다음 스니펫은 에이전트 구성 파일의 GitOps 섹션의 가능한 키와 값 예제를 보여줍니다(config.yaml).

gitops:
  manifest_projects:
  - id: gitlab-org/cluster-integration/gitlab-agent
    ref: # 브랜치, 태그 또는 커밋 중 하나를 지정할 수 있음
      branch: production
      # commit: <mysha>
      # tag: v1.0
    default_namespace: my-ns
    paths:
      # 이 디렉터리의 모든 YAML 파일을 읽습니다.
    - glob: '/team1/app1/*.yaml'
      # 'team2/apps' 및 모든 하위 디렉터리에서 모든 .yaml 파일을 읽습니다.
    - glob: '/team2/apps/**/*.yaml'
      # 'paths'가 지정되지 않거나 빈 디렉터리인 경우 아래 구성을 사용합니다.
    - glob: '/**/*.{yaml,yml,json}'
    reconcile_timeout: 3600s
    dry_run_strategy: none
    prune: true
    prune_timeout: 3600s
    prune_propagation_policy: foreground
    inventory_policy: must_match

GitOps 주석

Kubernetes용 GitLab 에이전트에는 다음을 사용할 수 있는 주석이 있습니다:

• 리소스 정렬: 특정 순서로 리소스를 적용하거나 삭제합니다.
• 적용 시간 돌연변이 사용: 하나의 리소스 구성에서 다른 리소스 구성으로 필드를 동적으로 대체합니다.

에이전트에는 기본 정렬이 있지만, 주석을 사용하여 순서를 미세 조정하고 적용 시간 값 주입을 할 수 있습니다.

GitOps 기능을 제공하기 위해 Kubernetes용 GitLab 에이전트는 Kubernetes SIG 프로젝트인 cli-utils 라이브러리를 사용합니다. 자세한 내용은 cli-utils 문서에서 제공하는 주석을 참조하십시오.

자동 드리프트 해결

드리프트는 인프라 리소스의 현재 구성이 원하는 구성과 다를 때 발생합니다. 일반적으로, 이는 사용된 인프라-as-code 메커니즘을 통해 직접 리소스를 편집하는 것으로 인해 발생합니다. 드리프트의 위험을 최소화하면 구성 일관성과 성공적인 운영을 보장할 수 있습니다.

GitLab에서는 Kubernetes용 에이전트가 git 리포지터리의 원하는 상태를 Kubernetes 클러스터의 실제 상태와 정기적으로 비교합니다. git 상태에서의 이탈은 매 체크마다 수정됩니다. 이러한 체크는 자동으로 5분마다 발생하며 구성할 수 없습니다.

에이전트는 서버 측 적용(server-side applies)을 사용합니다. 결과적으로 리소스의 모든 필드는 다른 매니저가 가질 수 있습니다. 드리프트는 git에서 관리되는 필드만 확인합니다. 이로써 클러스터 내부 컨트롤러를 사용하여 수평 파드 오토스케일러(Horizontal Pod Autoscalers)와 같은 리소스를 수정하는 것이 가능해집니다.

관련 주제

• 학습 및 데모용 GitOps 작업 예제
• 자율 주도형 교실 워크샵 (AWS EKS를 사용하지만 다른 Kubernetes 클러스터에도 사용할 수 있습니다)
• GitOps 워크플로우에서 Kubernetes 비밀 관리
• 애플리케이션 및 매니페스트 리포지터리 예제

문제 해결

여러 프로젝트를 가지고 충돌을 피하는 방법

에이전트는 프로젝트의 paths 섹션 하위에 설정된 각 glob 패턴을 독립적으로 감시하고, 클러스터에 동시에 업데이트를 수행합니다. 여러 경로에서 변경이 발견되면, 에이전트가 클러스터를 업데이트하려고 시도할 때 충돌이 발생할 수 있습니다.

이를 방지하기 위해 단일 위치에 논리 그룹의 매니페스트를 저장하고 겹치는 glob을 피하기 위해 이를 한 번만 참조하는 것을 고려하십시오.

예를 들어, 다음 두 가지 glob은 모두 루트 디렉터리의 *.yaml 파일과 일치하며 충돌을 일으킬 수 있습니다:

gitops:
  manifest_projects:
  - id: project1
    paths:
    - glob: '/**/*.yaml'
    - glob: '/*.yaml'

대신, 재귀적으로 모든 *.yaml 파일과 일치하는 단일 glob을 지정하십시오:

gitops:
  manifest_projects:
  - id: project1
    paths:
    - glob: '/**/*.yaml'

여러 에이전트 또는 프로젝트 사용

Kubernetes 매니페스트를 별도의 GitLab 프로젝트에 저장하는 경우 에이전트 구성 파일을 해당 프로젝트의 위치로 업데이트하십시오.