구성 동기화 개요

구성 동기화는 클러스터 운영자 및 플랫폼 관리자가 일관된 구성과 정책을 배포할 수 있게 해주는 오픈소스 도구입니다. 이러한 구성과 정책을 개별 Kubernetes 클러스터, 하이브리드 및 멀티 클라우드 환경을 포괄할 수 있는 여러 클러스터, 클러스터 내의 여러 네임 스페이스에 배포할 수 있습니다. 이 프로세스는 규모에 맞춘 구성 및 정책 관리를 간소화하고 자동화합니다. 또한 구성 동기화를 사용하면 개발팀이 클러스터 내에서 네임스페이스를 독립적으로 관리할 수 있으며 관리자가 설정한 정책 가드레일의 적용을 받을 수 있습니다.

구성 동기화는 Kubernetes와 동일한 원칙을 사용하여 구성이라는 Kubernetes 선언적 구성 파일의 중앙 집합으로 등록된 클러스터의 상태를 지속적으로 조정합니다. 구성이 하나 이상의 Git 저장소에 저장되고 구성 동기화는 이를 구성된 Kubernetes 객체와 일관되게 유지합니다. 이 GitOps 접근 방식(코드로 구성이라고도 함)을 사용하면 감사, 거래, 리뷰 가능하고 버전 제어되는 프로세스를 사용하여 일반적인 구성을 관리하고 배포할 수 있습니다.

다음 다이어그램에서 플랫폼 관리자는 클러스터 및 클러스터 내의 네임스페이스에 구성을 적용하여 3개의 서로 다른 클러스터에 대해 일관적인 구성을 만듭니다.

클러스터에 여러 구성을 배포하는 플랫폼 관리자

구성 동기화 이점

다음 단락에서는 구성 동기화가 제공하는 몇 가지 이점을 설명합니다.

  • 'shadow ops'의 위험 감소: 검증되지 않은 변경사항을 라이브 클러스터로 푸시하면 문서화된 구성과 라이브 환경 간의 차이점을 파악하기 어려울 수 있습니다. 모든 클러스터 구성 변경사항이 구성 동기화를 통해 적용되도록 요구하고, Kubernetes API에 대한 직접 액세스를 잠그고, Git에서 신뢰할 수 있는 소스로 변경사항을 역추적할 수 있습니다.
  • GitOps 권장사항: 변경사항을 라이브 환경에 푸시하기 전 원하는 저장소 관리 도구를 사용하여 코드 검토를 요구할 수 있습니다. 구성 동기화를 사용하여 구성 변경을 초래한 커밋을 정확하게 감사합니다.
  • 구성 관련 서비스 중단으로 인한 다운타임 감소: 구성 동기화를 사용하면 '되돌린 후 조사' 전략을 사용하여 브레이킹 체인지를 롤백하고 문제가 있는 변경사항을 수정하고 새 커밋으로 적용하기 전에 라이브 클러스터를 정상 작동 상태로 되돌릴 수 있습니다.
  • 지속적 통합/지속적 배포 (CI/CD) 파이프라인 사용: CI/CD 워크플로를 사용하여 원하는 도구 및 형식을 사용하는 구성을 렌더링하고, 변경사항을 테스트 및 검증하며, 테스트를 통과하면 자동으로 이를 커밋할 수 있습니다. 그런 다음 구성 동기화는 변경사항을 적용하고 이후 구성 드리프트를 모니터링하고 수정합니다.

구성 동기화 이해

기본 요건

구성 동기화는 네임스페이스, 라벨, 주석을 해당 구현의 핵심 부분으로 사용합니다. 제품을 사용하기 전에 이러한 개념을 알고 있으면 유용합니다.

클러스터 구성

구성 동기화를 사용하면 정책 컨트롤러 제약조건과 같은 공통 구성 및 클러스터 수준 정책을 만들고 Git의 단일 정보 소스에서 등록되거나 연결된 클러스터에 일관되게 적용할 수 있습니다. 클러스터를 구성하려면 먼저 구성과 저장소를 만들어야 합니다.

구성

구성은 YAML 또는 JSON으로 작성된 Kubernetes 구성 선언입니다. 구성 동기화는 구성을 읽고 하나 이상의 클러스터에 적용하여 클러스터에서 Kubernetes 객체 또는 리소스를 생성 또는 구성하거나 구성 동기화 자체에 필요한 정보를 제공합니다. 구성에는 kubectl edit 또는 kubectl apply을 사용하여 Kubernetes 클러스터에 적용할 수 있는 구성 세부정보가 포함될 수 있습니다. 단일 파일에 구성을 여러 개 선언할 수도 있습니다. 구성 동기화는 .yaml, .yml, .json의 세 가지 파일 유형을 읽습니다. 다른 서픽스가 있는 파일은 무시됩니다.

구성을 작성한 후 구성이 작성되는 대상 Kubernetes 객체를 이해해야 합니다.

자세한 내용은 Git 저장소에 구성 추가구성 만들기를 참조하세요.

저장소

저장소(또는 repo)는 구성 동기화 자체 구성을 포함하여 구성이 저장되는 Git 저장소입니다. 구성 동기화를 구성할 때는 구성 동기화가 변경사항을 모니터링하는 저장소, 브랜치, 하위 디렉터리를 구성해야 합니다.

구성 동기화를 사용하면 여러 저장소의 구성을 동일한 클러스터 집합에 동기화할 수 있습니다. 구성 동기화에서는 Git 참조(Git URL, 저장소 브랜치, 커밋 또는 태그, 디렉터리)를 사용하여 각 저장소를 참조할 수 있습니다. 이 구성은 여러 팀에 대한 구성 배포 수명 주기를 분리합니다. 또한 저장소를 배치할 위치와 구조화 방법을 선택할 때 자율성을 높여줍니다.

루트 저장소 및 네임스페이스 저장소의 두 가지 저장소 유형을 만들 수 있습니다.

  • 루트 저장소: 루트 저장소를 사용하면 클러스터 범위네임스페이스 범위 구성을 동기화할 수 있습니다. 루트 저장소는 관리자 수준 사용자 인증 정보를 사용하여 애플리케이션 네임스페이스에 정책을 적용하고 구성에 선언한 상태와 다른 로컬 변경사항을 재정의합니다. 루트 저장소는 일반적으로 중앙 관리자가 관리합니다.

    루트 저장소에는 두 가지 구조를 사용할 수 있습니다.

    • 구조화되지 않은 형식: 구조화되지 않은 소스 형식을 사용하면 가장 편리한 방식으로 저장소의 구성을 조직화할 수 있습니다. 이 형식은 Kustomize, kpt 또는 helm과 같은 도구를 사용하여 구성을 정리하거나 생성할 때 특히 유용합니다. 구조화되지 않은 형식은 대부분의 사용자에게 권장되며 Google Cloud Console을 통해 구성 동기화를 구성할 때 기본값입니다. 자세한 내용은 구조화되지 않은 저장소 사용을 참조하세요.
    • 계층적 구조: 계층적 또는 구조화된 소스 형식은 구성을 시스템 구성, 클러스터 메타데이터, 클러스터 수준 구성, 네임스페이스 구성에 대한 고유 카테고리로 구분하므로 구성을 쉽게 조직화할 수 있습니다. 또한 디렉터리 구조를 기반으로 여러 네임스페이스에서 계층적 구성 상속이 지원됩니다. 자세한 내용은 네임스페이스 구성 섹션을 참조하세요. 매니페스트에서 sourceFormat을 지정하지 않으면 계층적 구조는 구성 동기화의 기본 저장소 형식입니다. 자세한 내용은 계층적 저장소 개요를 참조하세요.

    루트 저장소를 구성하는 방법은 구성 동기화 설치를 참조하세요.

  • 네임스페이스 저장소: 네임스페이스 저장소는 선택사항이며 클러스터 전체에서 특정 네임스페이스와 동기화된 네임스페이스 범위 구성을 포함할 수 있습니다. 네임스페이스 저장소의 설정 및 제어를 관리자가 아닌 사용자에게 위임할 수 있습니다. 네임스페이스 저장소는 구조화되지 않은 저장소 형식을 사용해야 합니다.

다음 다이어그램은 팀이 단일 루트 저장소(관리자가 관리) 및 여러 네임스페이스 저장소(애플리케이션 운영자가 관리)에 클러스터를 동기화할 수 있는 방법을 간략하게 보여줍니다.

여러 구성 및 자체 네임스페이스 구성을 제어하는 앱 연산자를 관리하는 중앙 관리자

앞선 다이어그램에서 중앙 관리자는 조직의 중앙 집중식 인프라를 관리하고 클러스터 및 조직의 모든 네임스페이스에 정책을 적용합니다. 실시간 배포 관리를 담당하는 애플리케이션 연산자는 작업 중인 네임스페이스의 애플리케이션에 구성을 적용합니다.

다중 클러스터 구성

구성 동기화는 하이브리드 및 멀티 클라우드 환경을 포함하는 멀티 클러스터에 일관된 구성과 정책을 배포하는 데 도움이 됩니다.

구성 동기화는 다음 옵션을 제공하여 여러 클러스터를 구성하는 데 도움이 됩니다.

클러스터를 등록하는 것을 강하게 권장합니다. 클러스터를 등록하면 Google Cloud Console을 통해 모든 클러스터의 현재 상태를 관찰하고 등록된 클러스터에서 중앙 집중식 구성 동기화와 구성 동기화 관리를 수행할 수 있습니다. 자세한 내용은 클러스터 등록, 구성 동기화 구성, 구성 동기화 버전 업그레이드를 참조하세요.

네임스페이스 구성

구성 동기화에서 네임스페이스를 구성하면 다음과 같은 기능이 제공됩니다.

  • 등록 및 연결된 클러스터 전반에서 RBAC 역할과 같은 네임스페이스 범위 정책을 사용하여 Kubernetes 네임스페이스를 일관되게 프로비저닝할 수 있습니다. 네임스페이스 범위 정책을 사용하면 클러스터 내에서 멀티테넌시를 더 쉽게 구현하고 관리할 수 있습니다.
  • 구성을 복제하지 않고 여러 관련 네임스페이스에 정책을 적용하고 지정된 네임스페이스 또는 네임스페이스 집합의 구성을 재정의하거나 확장하여 여러 테넌트에 일관된 정책을 쉽게 적용할 수 있습니다.

이러한 기능은 구조화되지 않음 저장소와 계층 구조 저장소 형식에서 서로 다르게 작동합니다.

구조화되지 않은 저장소를 사용하면 계층 구조 컨트롤러를 사용하여 클러스터에 정의한 네임스페이스 계층 구조로 정책을 전파할 수 있습니다. 자세한 내용은 계층 구조 컨트롤러 개요를 참조하세요.

계층 구조 저장소를 사용하면 추상 네임스페이스라고 하는 네임스페이스 그룹을 사용하여 전파해야 하는 네임스페이스 정책을 제어할 수 있습니다. 추상 네임스페이스에는 저장소의 디렉터리 트리에서 계층적으로 네임스페이스를 구성해야 합니다. 자세한 내용은 네임스페이스 및 네임스페이스 범위 객체 구성네임스페이스 상속 개요를 참조하세요.

구조화되지 않은 형식과 계층 구조 형식은 둘 다 라벨 선택기를 사용한 비계층적 네임스페이스 집합의 타겟팅도 지원합니다.

nomos 명령어

구성 동기화는 API를 제공합니다. nomos(Windows의 nomos.exe) 명령어는 API를 사용하고, 설치 상태를 확인하고, 구성을 검증합니다.

자세한 내용은 nomos 명령줄 도구 사용을 참조하세요.

구성 동기화 RBAC / 권한

다음 섹션에는 구성 동기화 및 해당 구성요소가 클러스터 수준에서 올바르게 액세스할 수 있도록 하는 권한이 나와 있습니다. 나열된 권한은 기본적으로 사용 설정되며 구성 동기화가 작동하는 동안 사용 중지해서는 안 됩니다.

구성요소 네임스페이스 서비스 계정 권한 설명
reconciler-manager config-management-system reconciler-manager cluster-admin 루트 조정자를 프로비저닝하고 루트 조정자에 대한 ClusterRoleBinding을 만들려면 reconciler-manager는 cluster-admin이어야 합니다.
root reconcilers config-management-system 루트 조정자 이름 cluster-admin 클러스터 범위 및 커스텀 리소스를 적용하려면 루트 조정자가 cluster-admin이어야 합니다.
namespace reconcilers config-management-system 네임스페이스 조정자 이름 configsync.gke.io:ns-reconciler 네임스페이스 조정자에는 RepoSync 및 ResourceGroup 객체 및 해당 상태를 가져오거나 업데이트할 수 있는 권한이 필요합니다.
resource-group-controller-manager config-management-system resource-group-sa resource-group-manager-role resource-group-leader-election-role resource-group-controller-manager에는 객체 상태를 확인하고 리더 선택을 사용 설정하는 역할이 필요합니다.
admission-webhook config-management-system admission-webhook cluster-admin 클러스터의 객체에 대한 요청을 거부하려면 허용 웹훅이 cluster-admin이어야 합니다.
importer config-management-system importer cluster-admin RBAC 권한을 설정하려면 사용자에 권한이 있어야 하므로 RBAC 권한을 설정하려면 가져오기 도구가 cluster-admin이어야 합니다.

네임스페이스 조정자용 RBAC

다음 API 정의는 네임스페이스 조정자에 대한 액세스 제어 권한을 보여줍니다.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: configsync.gke.io:ns-reconciler
  labels:
    configmanagement.gke.io/system: "true"
    configmanagement.gke.io/arch: "csmr"
rules:
- apiGroups: ["configsync.gke.io"]
  resources: ["reposyncs"]
  verbs: ["get"]
- apiGroups: ["configsync.gke.io"]
  resources: ["reposyncs/status"]
  verbs: ["get","list","update"]
- apiGroups: ["kpt.dev"]
  resources: ["resourcegroups"]
  verbs: ["*"]
- apiGroups: ["kpt.dev"]
  resources: ["resourcegroups/status"]
  verbs: ["*"]
- apiGroups:
  - policy
  resources:
  - podsecuritypolicies
  resourceNames:
  - acm-psp
  verbs:
  - use

리소스 그룹 컨트롤러용 RBAC

다음 API 정의는 리소스 그룹 컨트롤러에 대한 액세스 제어 권한을 보여줍니다.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  creationTimestamp: null
  labels:
    configmanagement.gke.io/arch: "csmr"
    configmanagement.gke.io/system: "true"
  name: resource-group-manager-role
rules:
# This permission is needed to get the status for managed resources
- apiGroups:
  - '*'
  resources:
  - '*'
  verbs:
  - get
  - list
  - watch
# This permission is needed to watch/unwatch types as they are registered or removed.
- apiGroups:
  - apiextensions.k8s.io
  resources:
  - customresourcedefinitions
  verbs:
  - get
  - list
  - watch
# This permission is needed so that the ResourceGroup controller can reconcile a ResourceGroup CR
- apiGroups:
  - kpt.dev
  resources:
  - resourcegroups
  verbs:
  - create
  - delete
  - get
  - list
  - patch
  - update
  - watch
# This permission is needed so that the ResourceGroup controller can update the status of a ResourceGroup CR
- apiGroups:
  - kpt.dev
  resources:
  - resourcegroups/status
  verbs:
  - get
  - patch
  - update
# This permission is needed so that the ResourceGroup controller can work on a cluster with PSP enabled
- apiGroups:
  - policy
  resourceNames:
  - acm-psp
  resources:
  - podsecuritypolicies
  verbs:
  - use
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  labels:
    configmanagement.gke.io/arch: "csmr"
    configmanagement.gke.io/system: "true"
  name: resource-group-leader-election-role
  namespace: resource-group-system
rules:  // The following permissions are needed so that the leader election can work
- apiGroups:
  - ""
  resources:
  - configmaps
  verbs:
  - get
  - list
  - watch
  - create
  - update
  - patch
  - delete
- apiGroups:
  - ""
  resources:
  - configmaps/status
  verbs:
  - get
  - update
  - patch
- apiGroups:
  - ""
  resources:
  - events
  verbs:
  - create
- apiGroups:
  - coordination.k8s.io
  resources:
  - leases
  verbs:
  - '*'

다음 단계