정보 소스 정보

이 문서에서는 구성 동기화가 동기화할 수 있는 다양한 유형의 정보 소스를 설명합니다.

GitOps 워크플로의 핵심 개념은 구성 파일이 저장되는 중앙 저장소인 정보 소스입니다. 구성 파일은 일반적으로 Kubernetes 리소스를 정의하는 YAML 또는 JSON 파일입니다. 일반적으로 kubectl 명령줄 도구를 사용하여 Kubernetes 객체를 수동으로 적용할 수 있지만 구성 동기화는 Git 저장소와 같은 단일 정보 소스에서 이러한 리소스를 자동으로 적용할 수 있습니다. 그런 다음 구성 동기화는 지정된 정보 소스를 모니터링하고 변경사항을 클러스터에 자동으로 적용합니다.

구성 동기화는 Git 저장소, Open Container Initiative (OCI) 이미지, Helm 차트의 세 가지 유형의 소스에서 구성 파일을 동기화할 수 있습니다. 이 문서에서는 이러한 각 소스 유형과 구성 동기화가 소스 유형과 상호작용하는 방식을 설명합니다. 이 문서를 읽으면 워크플로와 환경에 가장 적합한 소스 옵션을 선택하는 데 도움이 됩니다.

Git 저장소

Git은 버전 관리 및 공동작업을 위해 널리 사용되는 기술입니다. Git을 사용하면 필요에 따라 요구사항에 맞는 방식으로 저장소를 구성하고 버전 관리 및 브랜칭의 이점을 누릴 수 있습니다. Git은 성숙하고 널리 채택된 기술이므로 다양한 제공업체와 도구를 선택할 수 있습니다.

Git 저장소를 정보 소스로 사용하여 구성 동기화를 구성하면 구성 동기화는 조정자 포드 내에서 git-sync 컨테이너를 사용하여 Git 저장소에서 구성을 가져옵니다. Git 저장소 내에서 구성을 가져올 위치를 더 세부적으로 제어하기 위해 저장소 URL, 브랜치, 버전 (커밋 또는 태그)을 구성할 수 있습니다.

RootSync 구성 예:

다음 예시에서는 Git 저장소에서 동기화되는 RootSync 매니페스트를 보여줍니다.

apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-management-system
spec:
  sourceType: git
  sourceFormat: unstructured
  git:
    repo: https://github.com/example/my-configs.git
    revision: main
    dir: cluster-configs
    auth: none # replace with your authentication method such as ssh or token
    period: 60s

이 구성은 Git 저장소에서 매니페스트를 동기화하도록 구성 동기화를 설정합니다. Config Sync는 https://github.com/example/my-configs.git 저장소의 main 브랜치에 있는 cluster-configs 디렉터리를 감시하고, 인증 없이 60초마다 업데이트를 확인합니다.

사용 사례 예: 중앙 집중식 관리

Git 저장소를 사용하여 머신의 모든 클러스터에 기준 정책을 적용하려는 플랫폼 관리자라고 가정해 보겠습니다. 이 시나리오에서는 standard-configs라는 중앙 Git 저장소에 표준 NetworkPolicies, RoleBindings, ResourceQuotas를 저장할 수 있습니다. 새 클러스터가 프로비저닝되면 구성 동기화가 standard-configs 저장소에서 동기화하도록 구성되어 모든 클러스터가 처음부터 조직 표준을 충족하도록 지원합니다.

OCI 이미지

OCI 이미지는 애플리케이션과 그 종속 항목을 패키징하기 위한 표준 형식입니다. 이 접근 방식은 컨테이너 이미지를 처리하는 방식과 유사하게 구성을 아티팩트로 취급합니다. 이 접근 방식은 불변성, 대규모에서의 빠른 성능과 같은 이점을 제공합니다. OCI를 사용하면 Artifact Registry와 같은 컨테이너 이미지 인프라 및 도구를 사용하여 이미지를 관리하고 GKE용 워크로드 아이덴티티 제휴를 사용하여 인증을 간소화할 수 있습니다.

OCI를 구성 소스로 사용하려면 일반적으로 구성 파일을 OCI 이미지로 빌드한 다음 Artifact Registry와 같은 레지스트리 플랫폼에 푸시하는 별도의 프로세스가 필요합니다. 이 방법은 Git 저장소에 파일로 저장된 구성보다 사람이 직접 읽기가 어려울 수 있습니다.

OCI 이미지를 정보 소스로 사용하여 구성 동기화를 구성하면 구성 동기화는 조정자 Pod 내에서 oci-sync 컨테이너를 사용하여 레지스트리에서 구성을 포함하는 OCI 이미지를 가져옵니다.

RootSync 구성 예:

다음 예시에서는 Artifact Registry에 저장된 OCI 이미지에서 동기화하는 RootSync 매니페스트를 보여줍니다.

apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-management-system
spec:
  sourceType: oci
  sourceFormat: unstructured
  oci:
    image: us-central1-docker.pkg.dev/my-project/my-repo/my-config-image:v1.0.0
    dir: .
    auth: k8sserviceaccount

이 구성은 OCI 이미지에서 동기화하도록 구성 동기화를 설정합니다. 구성 동기화는 인증을 위해 Kubernetes 서비스 계정을 사용하여 Artifact Registry에서 us-central1-docker.pkg.dev/my-project/my-repo/my-config-image:v1.0.0 이미지를 가져옵니다.

사용 사례 예시: CI/CD 파이프라인 통합

OCI 이미지 생성을 조직의 CI/CD 파이프라인에 통합한다고 가정해 보세요. 구성 파일의 변경사항이 병합되면 nomos vet 명령어와 같은 유효성 검사 테스트를 실행하고, YAML 파일을 OCI 이미지로 빌드하고, 이미지를 Artifact Registry에 푸시하도록 파이프라인을 설정할 수 있습니다. 그러면 구성 동기화가 새 버전의 이미지를 자동으로 감지하여 클러스터에 적용하므로 모든 구성 변경사항이 검증되고 버전이 지정된 롤아웃이 보장됩니다.

Helm 차트

Helm은 Kubernetes의 인기 있는 패키지 관리자로, 차트라는 패키징 형식을 사용합니다. 구성 동기화는 Helm 차트에 정의된 리소스를 가져오고, 렌더링하고, 동기화할 수 있습니다.

Helm은 Kubernetes 애플리케이션을 패키징하고 재사용하는 일관된 방법을 제공합니다. 템플릿이나 사전 빌드된 Helm 차트를 사용하여 일관되고 재사용 가능한 구성을 만들 수 있습니다.

Helm에 익숙하지 않은 경우 템플릿 및 출시 프로세스로 인해 구성 관리 파이프라인이 더 복잡해질 수 있습니다.

Helm 차트를 정보 소스로 사용하여 구성 동기화를 구성하면 구성 동기화는 조정자 Pod 내에서 helm-sync 컨테이너를 사용하여 Helm 저장소 (예: Artifact Registry) 또는 Git 저장소에서 차트를 가져온 다음 차트를 렌더링하여 Kubernetes 매니페스트를 생성합니다. 또는 Kustomize와 함께 구성 동기화를 사용하여 Helm 차트를 렌더링할 수 있습니다. 이 접근 방식에 대한 자세한 내용은 Kustomize 및 Helm에 구성 동기화 사용을 참고하세요.

RootSync 구성 예:

다음 예시에서는 Artifact Registry에 저장된 Helm 차트에서 동기화하는 RootSync 매니페스트를 보여줍니다.

apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-management-system
spec:
  sourceType: helm
  helm:
    repo: oci://us-central1-docker.pkg.dev/my-project/my-helm-repo
    chart: my-chart
    version: 1.2.0
    auth: gcpserviceaccount
    gcpServiceAccountEmail: my-service-account@my-project.iam.gserviceaccount.com
    releaseName: my-chart-release
    namespace: my-app-namespace # Namespace where the chart resources will be deployed

이 구성은 OCI 저장소에서 Helm 차트를 동기화하도록 구성 동기화를 설정합니다. 구성 동기화는 oci://us-central1-docker.pkg.dev/my-project/my-helm-repo 저장소에서 my-chart 차트의 버전 1.2.0를 가져오고 my-service-account@my-project.iam.gserviceaccount.com 서비스 계정으로 인증합니다. 차트의 리소스를 my-chart-release 출시 이름 아래의 my-app-namespace 네임스페이스에 배포합니다.

사용 사례 예: 서드 파티 애플리케이션 배포

클러스터에 Prometheus를 배포하려는 애플리케이션 팀에 속해 있다고 가정해 보겠습니다. Prometheus를 배포하는 사전 빌드된 Helm 차트에서 가져오도록 구성 동기화를 구성할 수 있습니다. Helm 명령어를 수동으로 실행하는 대신 구성 동기화의 RootSync 또는 RepoSync 객체 내에서 차트 소스, 버전, 맞춤 values를 정의합니다. 그런 다음 구성 동기화는 배포를 지정된 차트 버전 및 구성과 동기화된 상태로 유지합니다.

소스 유형 선택

가장 적합한 소스 유형은 팀의 기존 도구, 워크플로, 선호도에 따라 다릅니다. 이 표를 사용하여 각 소스 유형의 주요 특징을 파악하고 충분한 정보를 바탕으로 결정을 내릴 수 있습니다.

기능 Git 저장소 OCI 이미지 Helm 차트
적합한 환경 범용 구성 관리, 유연성, 사람이 읽을 수 있음 변경 불가능한 버전 관리 구성, 컨테이너 인프라 활용 복잡한 애플리케이션 패키징 및 배포
변경 가능 여부 변경 가능 변경 불가 변경 가능 (차트 버전은 변경할 수 없지만 값은 변경할 수 있음)
롤백 커밋 되돌리기 또는 브랜치 변경 이전 이미지 태그 배포 이전 차트 버전으로 롤백
도구 표준 Git 클라이언트, CI/CD 파이프라인 Docker 또는 Podman, 컨테이너 레지스트리 Helm CLI, Helm 저장소
성능 대규모 저장소의 경우 속도가 느릴 수 있음 특히 대규모에서 더 빠름 차트 저장소에서 가져올 때 빠름
인증 유연함 (SSH, 토큰), 설정이 더 복잡할 수 있음 GKE용 워크로드 아이덴티티 제휴로 간소화 (예: Artifact Registry 사용) GKE용 워크로드 아이덴티티 제휴로 간소화 (예: Artifact Registry 사용)

동일한 클러스터에서 서로 다른 용도로 서로 다른 소스 유형을 사용할 수도 있습니다. 예를 들어 클러스터에는 다음이 있을 수 있습니다.

  • 플랫폼팀에서 관리하는 기본 클러스터 전체 리소스 및 정책이 포함된 Git 저장소에서 동기화하는 RootSync
  • 애플리케이션 팀에서 관리하는 Redis 인스턴스를 배포하기 위해 Helm 차트에서 동기화하는 특정 네임스페이스의 RepoSync
  • 별도의 CI/CD 프로세스에서 빌드된 애플리케이션별 구성 세트가 포함된 OCI 이미지에서 동기화되는 다른 네임스페이스의 또 다른 RepoSync

다음 단계