Config Management를 사용한 안전한 출시

이 문서에서는 클러스터 운영자와 플랫폼 관리자가 Config Management를 사용하여 여러 환경에서 안전하게 변경사항을 적용하는 방법을 설명합니다. Config Management를 사용하면 오류가 모든 환경에 동시에 영향을 주는 것을 방지할 수 있습니다.

Config Management에서는 Git 저장소에 저장된 파일을 사용하여 단일 클러스터, 멀티 테넌트 클러스터, 멀티 클러스터 Kubernetes 구성을 관리할 수 있습니다. Config Management는 구성 동기화, 정책 컨트롤러, 구성 커넥터 등 세 가지 기술을 결합합니다. 구성 동기화는 Git 저장소의 모든 파일의 업데이트를 감시하고 변경사항을 모든 관련 클러스터에 자동으로 적용합니다. 정책 컨트롤러는 클러스터의 객체에 대한 정책을 관리하고 적용합니다. 구성 커넥터는 Google Kubernetes Engine(GKE) 커스텀 리소스를 사용하여 클라우드 리소스를 관리합니다.

구성 동기화 구성은 다음을 포함한 몇 가지 사항을 나타낼 수 있습니다.

Config Management는 특히 GKE Enterprise를 기반으로 빌드하는 플랫폼을 실행하는 데 필요한 구성, 정책, 워크로드(예: 보안 에이전트, 모니터링 에이전트, 인증서 관리자)를 배포하는 데 적합합니다.

Config Management를 사용하여 사용자용 애플리케이션을 배포할 수 있지만 이 출시 수명 주기를 앞에서 언급한 관리 워크로드의 출시 수명 주기에 연결하지 않는 것이 좋습니다. 대신 애플리케이션 팀이 출시 일정을 관리할 수 있도록 지속적 배포 도구와 같은 애플리케이션 배포 전용 도구를 사용하세요.

Config Management는 여러 요소를 관리할 수 있는 강력한 제품이므로 중대한 영향을 미치는 오류를 방지하기 위해 가드레일이 필요합니다. 이 문서에서는 가드레일을 만드는 몇 가지 방법을 설명합니다. 첫 번째 섹션에서는 단계적 출시에 대해 다루고, 두 번째 섹션에서는 테스트 및 유효성 검사를 중점적으로 다룹니다. 세 번째 섹션에서는 정책 컨트롤러를 사용하여 가드레일을 만드는 방법을 설명합니다. 네 번째 섹션에서는 Config Management 배포를 모니터링하는 방법을 보여줍니다.

전체 Config Management 제품이 아닌 구성 동기화만 사용하는 경우에도 이 문서에 설명된 대부분의 방법을 사용할 수 있습니다. 전체 Config Management 제품을 사용하지는 않지만 정책 컨트롤러와 관련된 방법을 구현하려는 경우 게이트키퍼를 사용하면 됩니다. 이 규칙의 예외는 Google Cloud Console에서 Config Management 구성 업데이트와 같이 Google Cloud Console의 Config Management 페이지를 활용하는 방법입니다. 이 문서에서 설명하는 여러 가지 방법을 동시에 사용할 수도 있습니다. 다음 섹션의 표는 동시 사용을 위해 호환되는 방법을 나타냅니다.

Config Management를 사용한 단계적 출시 구현

GKE Enterprise 사용자가 일반적으로 사용하는 멀티 클러스터 환경에서는 모든 클러스터에 동시에 구성을 적용하지 않는 것이 좋습니다. 단계적 출시, 클러스터별 클러스터 또는 네임스페이스를 애플리케이션 간의 경계로 사용하는 경우에는 네임스페이스별 네임스페이스도 오류의 반경을 줄이기 때문에 훨씬 안전합니다.

다음은 Config Management를 사용하여 단계적 출시를 구현하는 몇 가지 방법입니다.

  • Git 커밋 또는 태그를 사용하여 클러스터에 원하는 변경사항을 수동으로 적용
  • Git 분기를 사용하여 변경사항이 병합될 때 자동으로 변경사항 적용. 서로 다른 클러스터 그룹에 서로 다른 분기를 사용할 수 있습니다.
  • ClusterSelector 및 NamespaceSelector 객체를 사용하여 클러스터 또는 네임스페이스의 하위 그룹에 변경사항을 선택적으로 적용

단계적 출시의 모든 방법은 장단점이 있습니다. 다음 표는 어떤 방법을 동시에 사용할 수 있는지를 보여줍니다.

X와 Y의 호환 여부 Git 커밋 또는 태그 Git 분기 클러스터 선택기 네임스페이스 선택기
Git 커밋 또는 태그 호환되지 않음 호환 가능 호환 가능
Git 분기 호환되지 않음 호환 가능 호환 가능
클러스터 선택기 호환 가능 호환 가능 호환 가능
네임스페이스 선택기 호환 가능 호환 가능 호환 가능

다음 결정 트리는 단계적 출시 방법 중 하나를 사용할 시기를 결정하는 데 도움이 됩니다.

출시 방법의 결정 트리

Git 커밋 또는 태그 사용

다른 단계적 출시 방법과 달리 Git 커밋 또는 태그 사용은 최대한의 제어를 제공하는 가장 안전한 방법입니다. 콘솔에서 Config Management 페이지를 사용하여 여러 클러스터를 동시에 업데이트할 수 있습니다. 이 방법은 클러스터에 변경사항을 하나씩 적용하고 적용 시기를 정확히 제어하려는 경우에 사용합니다.

이 방법에서는 각 클러스터를 Config Management 저장소의 특정 버전(커밋 또는 태그)에 '고정'합니다. 이것은 Git 커밋을 컨테이너 이미지 태그로 사용하는 것과 비슷합니다. RootSync 또는 RepoSync 커스텀 리소스의 spec.git.revision 필드에 커밋, 태그 또는 해시를 지정하여 이 메서드를 구현합니다.

kustomize 같은 도구로 RootSync 또는 RepoSync 커스텀 리소스를 관리하는 경우 변경사항을 적용하는 데 필요한 수동 작업량을 줄일 수 있습니다. 이러한 도구를 사용하면 한 위치에서 revision 매개변수를 변경한 다음 선택한 순서와 속도에 따라 새 RootSync 또는 RepoSync 커스텀 리소스를 클러스터에 선택적으로 적용하면 됩니다.

또한 구성 동기화가 아닌 Config Management를 사용하는 경우 Google Cloud Console의 Config Management 페이지에 액세스할 수 있습니다. 이 페이지에서는 동일한 Fleet에 속하는 여러 클러스터의 revision 매개변수를 동시에 업데이트할 수 있습니다. Config Management 구성을 업데이트하는 자동화 시스템이 있는 경우 콘솔을 사용하여 이 구성을 변경하지 않는 것이 좋습니다.

예를 들어 다음 RootSync 정의는 1.2.3 태그를 사용하도록 Config Management를 구성합니다.

apiVersion: configsync.gke.io/v1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-management-system
spec:
  sourceType: git
  sourceFormat: unstructured
  git:
    repo: git@example.com:anthos/config-management.git
    revision: 1.2.3
    auth: ssh

이 구성을 클러스터에 적용하면 Config Management는 example.com:anthos/config-management.git 저장소의 1.2.3 태그를 사용합니다.

클러스터를 업데이트하려면 spec.git.revision 필드를 클러스터의 새 값으로 변경합니다. 이렇게 하면 업데이트할 클러스터와 업데이트할 시기를 정의할 수 있습니다. 변경사항을 롤백해야 하는 경우 spec.git.revision 필드를 이전 값으로 다시 변경합니다.

다음 다이어그램은 이 방법의 출시 프로세스를 보여줍니다. 먼저 Config Management 저장소에 대한 변경사항을 커밋한 다음 모든 클러스터에서 RootSync 정의를 업데이트합니다.

Git 커밋 및 태그의 출시 프로세스.

다음과 같이 하는 것을 권장합니다.

  • 태그 대신 Git 커밋 ID를 사용합니다. Git의 작동 방식으로 인해 절대 변경되지 않을 것이라는 보장이 있습니다. 예를 들어 git push --force는 Config Management가 사용 중인 커밋을 변경할 수 없습니다. 이 접근법은 감사 목적과 로그에서 사용 중인 커밋을 추적하는 데 유용합니다. 또한 태그와 달리 ID를 커밋하기 위한 추가 단계가 없습니다.
  • Git 커밋 ID 대신 Git 태그를 사용하려는 경우와 GitLab을 사용하는 경우 태그를 보호하여 이동 또는 삭제를 방지합니다. 다른 주요 Git 솔루션에는 이 기능이 없습니다.
  • 동시에 여러 클러스터를 업데이트하려는 경우 Config Management 콘솔 페이지에서 수행할 수 있습니다. 한 번에 여러 클러스터를 업데이트하려면 동일한 Fleet의 일부여야 하며 동일한 프로젝트에 있어야 합니다.

Git 분기 사용

Git 저장소에 병합되는 즉시 클러스터에 변경사항을 적용하려면 커밋 또는 태그 대신 Git 분기를 사용하도록 Config Management를 구성합니다. 이 방법을 사용하면 Git 저장소에서 여러 개의 장기적 분기를 만들고 여러 클러스터에서 Config Management를 구성하여 서로 다른 분기에서 구성을 읽을 수 있습니다.

예를 들어 단순한 패턴에는 다음과 같은 두 개의 분기가 있습니다.

  • 비프로덕션 클러스터의 staging 분기
  • 프로덕션 클러스터의 master 분기

비프로덕션 클러스터의 경우 spec.git.branch 필드를 staging으로 설정하여 RootSync 또는 RepoSync 객체를 만듭니다. 프로덕션 클러스터의 경우 spec.git.branch 매개변수를 master로 설정하여 RootSync 또는 RepoSync 객체를 만듭니다.

예를 들어 다음 RootSync 정의는 master 브랜치를 사용하도록 Config Management를 구성합니다.

apiVersion: configsync.gke.io/v1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-management-system
spec:
  git:
    repo: git@example.com:anthos/config-management.git
    branch: master
    auth: ssh

다음 다이어그램은 이 방법의 출시 프로세스를 보여줍니다.

Git 분기의 출시 프로세스

3개 이상의 분기를 사용하거나 환경 이외의 다른 대상에 매핑된 분기를 사용하여 이 패턴을 특정 요구사항에 맞게 조정할 수 있습니다. 변경사항을 롤백해야 하는 경우 git revert 명령어를 사용하여 동일한 분기에서 새 커밋을 만들어 이전 커밋에서 변경된 사항을 되돌립니다.

다음과 같이 하는 것을 권장합니다.

  • 여러 클러스터를 처리할 때는 프로덕션 클러스터와 비프로덕션 클러스터를 구분하는 데 도움이 되도록 두 개 이상의 Git 분기를 사용합니다.
  • 대부분의 Git 솔루션에서는 보호된 분기 기능을 사용하여 해당 분기의 삭제 또는 검토되지 않은 변경사항을 방지할 수 있습니다. 자세한 내용은 GitHub, GitLab, Bitbucket 문서를 참조하세요.

ClusterSelector 및 NamespaceSelector 객체 사용

Git 분기는 결국 모두 동일한 정책을 적용하려는 여러 클러스터에 걸쳐 변경사항을 단계적으로 출시하는 좋은 방법입니다. 그러나 클러스터 또는 네임스페이스의 하위 집합에만 변경사항을 출시하려면 ClusterSelector 및 NamespaceSelector 객체를 사용합니다. 이러한 객체의 목표는 비슷하며, 즉 특정 라벨이 있는 클러스터 또는 네임스페이스에만 객체를 적용할 수 있습니다.

예를 들면 다음과 같습니다.

  • ClusterSelector 객체를 사용하면 다양한 규정 준수 체제에 대해 해당 객체가 위치한 국가에 따라 클러스터에 다른 정책을 적용할 수 있습니다.
  • NamespaceSelector 객체를 사용하면 내부 팀과 외부 계약자가 사용하는 네임스페이스에 다른 정책을 적용할 수 있습니다.

ClusterSelector 및 NamespaceSelector 객체를 사용하면 다음과 같은 고급 테스트 및 출시 방법을 구현할 수도 있습니다.

  • 정책의 카나리아 릴리스: 소규모의 클러스터 및 네임스페이스의 하위 집합에 새 정책을 배포하여 장시간의 정책 효과를 연구합니다.
  • A/B 테스트: 동일한 정책의 여러 버전을 다른 클러스터에 배포하여 정책 버전의 영향을 조사한 다음 어디에나 배포할 최적의 버전을 선택합니다.

예를 들어 여러 프로덕션 클러스터가 있는 조직을 가정해 보겠습니다. 플랫폼팀에서 이미 Config Management, Cluster, ClusterSelector 객체를 사용하여 프로덕션 클러스터의 두 범주인 canary-prod 및 prod를 만들었습니다(ClusterSelector 사용 참조).

플랫폼팀은 각 네임스페이스가 속한 팀을 파악하기 위해 네임스페이스에 팀 라벨의 존재를 시행하도록 정책 컨트롤러를 사용하여 정책을 출시하려고 합니다. 이미 테스트 실행 모드에서 이 정책의 버전을 출시했으며 이제 소수의 클러스터에 이 정책을 적용하고자 합니다. 그들은 ClusterSelector 객체를 사용하여 서로 다른 클러스터에 적용되는 두 개의 서로 다른 K8sRequiredLabels 리소스를 만듭니다.

  • K8sRequiredLabels 리소스는 prod 유형의 클러스터에 적용되며, enforcementAction 매개변수를 dryrun으로 설정합니다.

    apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: ns-must-have-team
  annotations:
    configmanagement.gke.io/cluster-selector: prod
Spec:
  enforcementAction: dryrun
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Namespace"]
  parameters:
    labels:
      - key: "team"

  • K8sRequiredLabels 리소스는 enforcementAction 매개변수 없이 canary-prod 유형의 클러스터에 적용됩니다. 즉, 정책이 실제로 적용됩니다.

    apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: ns-must-have-team
  annotations:
    configmanagement.gke.io/cluster-selector: canary-prod
spec:
  match:
    kinds:
      - apiGroups: [""]
    kinds: ["Namespace"]
  parameters:
    labels:
      - key: "team"

configmanagement.gke.io/cluster-selector 주석을 사용하면 팀은 canary-prod 유형의 클러스터에서만 정책을 적용하여 의도치 않은 부작용이 전체 프로덕션 Fleet로 확산되지 않도록 할 수 있습니다. 정책 컨트롤러의 테스트 실행 기능에 대한 자세한 내용은 제약조건 만들기를 참조하세요.

다음과 같이 하는 것을 권장합니다.

  • 클러스터 또는 네임스페이스의 하위 집합에 구성 변경사항을 무기한으로 적용해야 하는 경우에는 ClusterSelector 및 NamespaceSelector 객체를 사용합니다.
  • 선택기를 사용하여 변경사항을 출시하는 경우 매우 신중해야 합니다. Git 커밋을 사용하는 경우 클러스터별로 출시하므로 한 번에 하나의 클러스터에만 오류가 발생합니다. 하지만 Git 분기를 사용하면 오류가 해당 분기를 사용하는 모든 클러스터에 영향을 줄 수 있습니다. 선택기를 사용하면 오류가 한 번에 모든 클러스터에 영향을 미칠 수 있습니다.

검토, 테스트, 유효성 검사 구현

Config Management의 장점 중 하나는 Kubernetes 리소스, 클라우드 리소스, 정책 등 모든 요소를 선언적으로 관리한다는 것입니다. 즉 소스 제어 관리 시스템의 파일은 리소스(Config Management의 경우 Git 파일)를 나타냅니다. 이 특성을 통해 애플리케이션의 소스 코드에 이미 사용 중인 개발 워크플로(검토 및 자동 테스트)를 구현할 수 있습니다.

검토 구현

Config Management는 Git를 기반으로 하므로 선호하는 Git 솔루션을 사용하여 Config Management 저장소를 호스팅할 수 있습니다. Git 솔루션에는 Config Management 저장소의 변경사항을 검토하는 데 사용할 수 있는 코드 검토 기능이 있을 수 있습니다.

Config Management 저장소의 변경사항을 검토하는 권장사항은 다음과 같이 일반 코드 검토와 동일합니다.

Config Management 코드베이스의 민감도를 감안하여 가능한 경우 Git 솔루션에 다음 구성을 만드는 것이 좋습니다.

이러한 다양한 기능을 사용하여 Config Management 코드베이스의 각 변경 요청에 대한 승인을 적용할 수 있습니다. 예를 들어 최소한 플랫폼팀 구성원(클러스터 전체를 운영하는 사람)과 보안팀의 구성원(보안 정책 정의 및 구현을 책임지는 사람)에게 각 변경사항에 대해 승인을 받을 수 있습니다.

다음과 같이 하는 것을 권장합니다.

  • Config Management 저장소에 동료 검토를 적용하고 클러스터에서 사용되는 Git 분기를 보호합니다.

자동 테스트 구현

코드베이스 작업 시 일반적인 권장사항은 지속적 통합을 구현하는 것입니다. 즉, 변경 요청이 생성되거나 업데이트될 때 실행되도록 자동화된 테스트를 구성합니다. 자동화된 테스트는 사람이 변경 요청을 검토하기 전에 많은 오류를 포착할 수 있습니다. 이는 개발자를 위해 피드백 루프를 강화합니다. Config Management 저장소에 대해 동일한 도구를 사용하여 동일한 아이디어를 구현할 수 있습니다.

예를 들어 새 변경사항에 대해 nomos vet 명령어를 자동으로 실행하는 것이 좋습니다. 이 명령어는 Config Management 저장소의 구문이 유효한지 확인합니다. 구성 유효성 검사 튜토리얼에 따라 Cloud Build를 사용하여 이 테스트를 구현할 수 있습니다. Cloud Build를 다음 옵션과 통합할 수 있습니다.

구성 유효성 검사 튜토리얼에서 볼 수 있듯이 컨테이너 이미지를 사용하여 테스트를 수행합니다. 따라서 Cloud Build 뿐만 아니라 컨테이너를 실행하는 모든 지속적 통합 솔루션에서 테스트를 구현할 수 있습니다. 특히 정책 컨트롤러 테스트가 포함된 이 예시에 따라 GitLab CI로 구현할 수 있습니다.

피드백 루프를 더 강화하기 위해 해당 사용자에게 nomos vet 명령어를 Git 커밋 전 후크로 실행하도록 요청할 수 있습니다. 한 가지 주의해야 할 점은 일부 사용자가 Config Management에서 관리하는 Kubernetes 클러스터에 액세스하지 못할 수 있으며 워크스테이션에서 전체 유효성 검사를 실행하지 못할 수 있다는 점입니다. nomos vet --clusters "" 명령어를 실행하여 의미 체계 및 구문 검사로 유효성 검사를 제한합니다.

필요하거나 유용하다고 생각되는 다른 테스트를 구현할 수 있습니다. 정책 컨트롤러를 사용하면 정책 컨트롤러 정책에 대한 변경사항 테스트에 설명된 대로, 정책에 따라 제안된 변경사항에 대해 자동 테스트를 구현할 수 있습니다.

다음과 같이 하는 것을 권장합니다.

  • 지속적 통합 파이프라인에서 테스트를 구현하세요. 제안된 모든 변경사항에 대해 최소한 nomos vet 명령어는 실행하도록 합니다.

정책 컨트롤러 사용

정책 컨트롤러는 Kubernetes 동적 승인 컨트롤러입니다. 정책 컨트롤러를 설치하고 구성할 때 Kubernetes는 사전 정의된 규칙(이른바 정책)을 준수하지 않는 변경사항을 거부할 수 있습니다.

다음은 정책 컨트롤러의 두 가지 사용 사례 예시입니다.

  • Kubernetes 객체에 특정 라벨의 존재 시행
  • 권한이 있는 pod 생성 방지

가장 일반적으로 사용되는 정책을 구현하기 위해 정책 템플릿 라이브러리를 사용할 수 있지만, Rego라는 강력한 언어로 직접 작성할 수 있습니다. 예를 들어 정책 컨트롤러를 사용하면 사용자가 인그레스에서 구성할 수 있는 호스트 이름을 제한할 수 있습니다(자세한 내용은 이 가이드 참조).

구성 동기화와 마찬가지로 정책 컨트롤러는 Config Management 제품의 일부입니다. 정책 컨트롤러와 구성 동기화는 다음과 같이 사용 사례가 상이하지만 보완적입니다.

  • 구성 동기화는 잠재적으로 여러 클러스터에서 Kubernetes 객체를 동시에 만들 수 있는 GitOps 스타일 도구입니다. 소개에서 언급한 대로 구성 동기화는 정책을 관리하는데 특히 유용합니다.
  • 정책 컨트롤러를 사용하면 Kubernetes에서 만들 수 있는 객체의 정책을 정의할 수 있습니다. 이러한 정책은 Kubernetes 객체 자체인 커스텀 리소스에 정의됩니다.

앞의 기능은 두 애플리케이션 간의 양방향 관계를 만듭니다. 구성 동기화를 사용하여 정책 컨트롤러에서 시행하는 정책을 생성할 수 있으며, 이러한 정책을 사용하여 다음 다이어그램과 같이 구성 동기화(또는 다른 프로세스)로 만들 수 있는 객체를 정확하게 제어할 수 있습니다.

구성 동기화 및 정책 컨트롤러

Git 저장소, 구성 동기화, 정책 컨트롤러, Kubernetes, 지속적 배포(CD) 시스템, 사용자가 모두 다음과 같은 방식으로 서로 상호작용합니다.

  • 사용자는 Config Management Git 저장소와 상호작용하여 Kubernetes 객체를 생성, 업데이트, 삭제합니다.
  • 구성 동기화는 Config Management Git 저장소에서 해당 구성을 읽습니다.
  • 구성 동기화는 Kubernetes API 서버와 상호작용하여 정책 컨트롤러의 정책이 포함된 객체를 만듭니다.
  • CD 시스템은 Kubernetes API 서버와 상호작용하여 객체를 만듭니다. 정책 컨트롤러의 제약조건을 만들 수 있습니다. 하지만 이 사용 사례에는 Config Management를 사용하는 것이 좋습니다. 제약조건을 관리하고 테스트할 수 있는 중앙 집중식 공간을 제공하기 때문입니다.
  • Kubernetes API 서버는 정책 컨트롤러의 응답을 기반으로 구성 동기화 및 CD 시스템에서 객체 생성을 수락하거나 거부합니다.
  • 정책 컨트롤러는 Kubernetes API 서버에서 읽어오는 정책을 기반으로 응답을 제공합니다.

다음 다이어그램은 이러한 상호작용을 보여줍니다.

Git 저장소, 구성 동기화, 정책 컨트롤러, Kubernetes, 지속적 배포 시스템, 사용자 간의 상호작용

정책 컨트롤러는 검토자 및 자동 테스트를 이스케이프 처리하는 정책 위반을 방지하므로 Kubernetes 클러스터의 마지막 방어선으로 간주할 수 있습니다. 또한 Config Management의 검토자 수가 증가할수록 정책 컨트롤러도 유용해집니다. 하지만 사회적 태만 현상으로 인해 검토자가 많을수록 조직에서 정의한 규칙을 일관되게 적용할 가능성이 낮아집니다.

정책 컨트롤러 정책에 대한 변경사항 테스트

정책 컨트롤러를 사용하는 경우 지속적 통합 파이프라인에 몇 단계를 추가하여(자동 테스트 구현 참조) 정책을 기준으로 제안된 변경사항을 자동으로 테스트할 수 있습니다. 테스트를 자동화하면 변경사항을 제안하는 사람에게 더 빠르고 더 눈에 띄는 피드백을 제공할 수 있습니다. 지속적 통합 파이프라인의 정책을 기준으로 변경사항을 테스트하지 않는 경우 출시 모니터링에 설명된 시스템을 사용하여 Config Management 동기화 오류에 대한 알림을 받아야 합니다. 정책을 기준으로 변경사항을 테스트하면 변경을 제안하는 사람이 어떤 위반이든 확실하게 조기에 알아낼 수 있습니다.

CI 파이프라인에서 정책 컨트롤러 사용 튜토리얼에 따라 Cloud Build에서 이 테스트를 구현할 수 있습니다. 앞서 자동화된 테스트 구현에서 설명했듯이 Cloud Build를 GitHub 및 Bitbucket과 통합할 수 있습니다. GitLab CI로 이 테스트를 구현할 수도 있습니다. 구현 예시는 이 저장소를 참조하세요.

다음과 같이 하는 것을 권장합니다.

  • 정책 컨트롤러를 사용하는 경우 지속적 통합 파이프라인의 정책과 비교하여 제안된 변경사항의 유효성을 검사하세요.

출시 모니터링

이 문서에서 다루는 모든 가드레일을 구현하더라도 오류가 발생할 수 있습니다. 다음은 일반적인 두 가지 오류 유형입니다.

  • 구성 동기화 자체에는 문제를 일으키지 않지만 워크로드가 제대로 작동하지 못하는 오류(예: 워크로드의 구성요소가 통신하는 것을 방해하는 지나치게 제한적인 NetworkPolicy)
  • 잘못된 Kubernetes 매니페스트 또는 허용 컨트롤러에서 거부된 객체 등 구성 동기화가 클러스터에 변경사항을 적용할 수 없는 오류 앞서 설명한 방법은 이러한 오류를 대부분 발견할 것입니다.

앞의 첫 번째 글머리 기호에 설명된 오류를 감지하려면 각 워크로드의 상태를 파악해야 하므로 Config Management 수준에서는 거의 불가능합니다. 따라서 애플리케이션이 오작동하면 이를 알리는 기존 모니터링 시스템에서 이러한 오류를 감지하는 것이 가장 좋습니다.

가드레일을 모두 구현한 경우에 드물지만 두 번째 글머리 기호에 설명된 오류를 감지하려면 특정 설정이 필요합니다. 기본적으로 Config Management는 오류를 로그에 작성합니다(기본적으로 Cloud Logging에서 확인할 수 있음). Config Management 콘솔 페이지에도 오류가 표시됩니다. 로그나 콘솔은 보통 오류를 감지하기에 충분하지 않습니다. 항상 모니터링하지 않기 때문입니다. 오류 감지를 자동화하는 가장 간단한 방법은 클러스터에 오류가 있는지 알려주는 nomos status 명령어를 실행하는 것입니다.

또한 오류 자동 알림을 사용하여 고급 솔루션을 설정할 수도 있습니다. Config Management는 Prometheus 형식의 측정항목을 노출합니다. 자세한 내용은 Config Management 모니터링을 참조하세요.

모니터링 시스템에 Config Management 측정항목이 있으면 gkeconfig_monitor_errors 측정항목이 0보다 클 때 알리는 알림을 만듭니다. 자세한 내용은 Cloud Monitoring의 알림 정책 관리 또는 Prometheus의 알림 규칙을 참조하세요.

Config Management를 사용한 안전한 출시에 대한 메커니즘 요약

다음 표에는 이 문서의 앞부분에서 설명한 다양한 메커니즘이 요약되어 있습니다. 이러한 메커니즘 중 어느 것도 배타적이지 않습니다. 일부 또는 전부를 다른 목적으로 사용할 수 있습니다.

메커니즘 장점 단점 사용 사례
Git 커밋 ID 및 태그 특정 Git 커밋 ID 또는 태그를 사용하여 적용될 클러스터 변경사항을 정밀하게 제어합니다. 클러스터 간의 장기적인 차이에 Git 커밋 ID나 태그를 사용하지 마세요. 클러스터 선택기를 사용하는 것이 좋습니다. 모든 클러스터는 12345 Git 커밋을 적용하도록 구성됩니다. 테스트할 새 커밋 abcdef를 사용하여 변경합니다. 이 새 커밋을 사용하여 변경사항의 유효성을 검사하도록 단일 클러스터 구성을 변경합니다.
Git 분기 동일한 변경사항을 여러 환경에 적용하려면 여러 Git 분기를 사용합니다. 클러스터 간의 장기적 차이에 여러 개의 Git 분기를 사용하지 마세요. 분기가 크게 갈리며 다시 병합하기가 어렵습니다. 먼저 스테이징 분기에서 변경사항을 병합합니다. 그러면 스테이징 클러스터가 수령합니다.
그런 다음 마스터 분기의 변경사항을 병합하면 프로덕션 클러스터가 수령합니다.
클러스터 선택기 및 네임스페이스 선택기 클러스터와 네임스페이스의 장기적 차이에 선택기를 사용합니다. 여러 환경에 걸친 단계적 출시에는 선택기를 사용하지 마세요. 스테이징에서 먼저 수정사항을 테스트한 다음 프로덕션에 배포하려면 별도의 Git 분기를 사용합니다. 애플리케이션팀에 개발 클러스터에 대한 전체 액세스 권한이 필요하지만 프로덕션 클러스터에 대한 읽기 전용 액세스 권한이 있을 경우에는 ClusterSelector 객체를 사용하여 관련 클러스터에 올바른 RBAC 정책을 적용합니다.
동료 검토 동료 검토를 사용하여 관련 팀에서 변경사항을 승인하는지 확인합니다. 사람이 직접 검토하는 경우 모든 오류를 발견할 수 없으며, 특히 구문 오류 등을 발견하기 어렵습니다. 조직에서 보안팀이 여러 시스템에 영향을 미치는 구성 변경사항을 검토해야 하는 경우 보안팀 구성원에게 변경사항을 검토해달라고 요청합니다.
지속적 통합 파이프라인의 자동 테스트 자동 테스트를 사용하여 제안된 변경사항의 오류를 포착합니다. 자동 테스트는 검토자를 완전히 대체할 수 없습니다. 둘 다 사용합니다. 제안된 모든 변경사항에서 nomos vet 명령어를 실행하여 저장소가 유효한 Config Management 구성인지 확인합니다.
정책 컨트롤러 조직 전체 정책을 시행하고 Kubernetes API 서버 수준에서 직접 가드레일을 구현합니다. 정책 컨트롤러는 정책을 만들거나, 업데이트 또는 삭제하는 데 사용할 수 없습니다(Config Management의 역할임). 정책 컨트롤러는 정책 시행만 할 수 있습니다. 애플리케이션팀에서 직접 관리하는 네임스페이스에서도 보안팀은 사용자가 권한 있는 컨테이너를 만들지 못하도록 Config Management를 사용하여 정책 컨트롤러 제약조건을 만듭니다.
정책 컨트롤러 제약조건 변경사항을 테스트합니다. Config Management가 변경사항을 적용할 때 정책 컨트롤러가 변경사항을 거부하지 않는지 확인합니다. 지속적 통합 파이프라인의 정책 컨트롤러 제약 조건 변경사항 테스트를 클러스터에서 정책 컨트롤러를 사용 설정하는 것으로 대체할 수 없습니다. 모든 네임스페이스에는 소유자를 식별하는 'team' 라벨이 있어야 합니다. 사용자가 새 네임스페이스를 만들려고 하고 제안된 변경사항에 이 라벨을 추가하는 것을 잊은 경우 지속적 통합 파이프라인이 사용자가 변경사항을 검토하기 전에 오류를 포착합니다.
동기화 오류 모니터링 Config Management는 실제로 변경사항을 클러스터에 적용해야 합니다. 동기화 오류는 Config Management가 잘못된 저장소를 적용하려고 하거나 Kubernetes API 서버가 일부 객체를 거부하는 경우에만 발생합니다. 정책 컨트롤러 정책의 모든 제약조건을 코드화하지 않으면 제약조건을 위반하는 리소스가 감지되지 않습니다. 사용자가 모든 테스트와 검토를 우회하고 잘못된 변경사항을 Config Management 저장소에 커밋합니다. 이 변경사항은 클러스터에 적용할 수 없습니다. 동기화 오류를 모니터링하는 경우 오류가 발생하면 알림을 받게 됩니다.

출시 전략 예시

이 섹션에서는 이 문서의 나머지에서 소개하는 개념을 사용하여 조직의 모든 클러스터에 대한 엔드 투 엔드 출시 전략을 만드는 데 도움을 줍니다. 이 전략에서는 Fleet 예시 1 - 접근법 1에서처럼 개발, 스테이징, 프로덕션을 위한 별도의 Fleet가 있다고 가정합니다.

이 시나리오에서는 특정 Git 커밋을 사용하여 Config Management Git 저장소와 동기화하도록 각 클러스터를 구성합니다. 특정 Fleet에 변경사항을 배포하는 프로세스는 4단계입니다.

  1. Fleet에서 단일('카나리아') 클러스터를 업데이트하여 새 커밋을 먼저 사용합니다.
  2. 테스트를 실행하고 출시를 모니터링하여 모든 것이 예상대로 작동하는지 확인합니다.
  3. Fleet에서 나머지 클러스터를 업데이트합니다.
  4. 모든 것이 예상대로 작동하는지 다시 확인합니다.

모든 클러스터에 변경사항을 배포하려면 각 Fleet에 대해 이 프로세스를 반복합니다. 분기에서 Git 커밋을 사용하여 이 메서드를 기술적으로 적용할 수 있습니다. 하지만 검토 프로세스 초기에 문제를 식별하려면 다음 프로세스를 채택하는 것이 좋습니다.

  1. 다른 사용자가 Config Management Git 저장소에서 변경 요청을 열면 개발 클러스터에 변경사항을 배포하세요.
  2. 변경 요청이 수락되어 기본 분기에서 병합되는 경우 앞서 설명한 대로 모든 Fleet에 전체 배포를 실행합니다.

일부 변경사항은 특정 Fleet만 대상으로 할 수 있지만 모든 변경사항을 최종적으로 모든 Fleet에 배포하는 것이 좋습니다. 이 전략은 어떤 Fleet를 어떤 커밋과 동기화할지 추적할 필요가 없습니다. 이전 Fleet에서는 적절한 테스트가 불가능하므로 프로덕션 Fleet만 대상으로 하는 변경사항에 특히 주의하세요. 예를 들어 카나리아 클러스터 배포와 나머지 클러스터 배포 사이에 문제가 발생할 때까지 더 오래 기다린다는 의미입니다.

요약하면 전체 엔드 투 엔드 배포 절차는 다음과 같습니다.

  1. 다른 사람이 변경 요청을 엽니다.
  2. 자동화된 테스트 및 유효성 검사가 실행되고 수동 검토가 완료됩니다.
  3. 작업을 수동으로 트리거하여 개발 Fleet의 카나리아 클러스터에 변경사항을 배포합니다. 이 클러스터에서 자동화된 엔드 투 엔드 테스트가 실행됩니다.
  4. 모든 것이 정상이면 기본 분기에서 변경 요청을 병합합니다.
  5. 병합은 자동화된 작업을 트리거하여 개발 Fleet의 카나리아 클러스터에 새로운 기본 분기 팁 커밋을 배포합니다. 이 클러스터에서 자동화된 엔드 투 엔드 테스트가 실행됩니다(대략 동시에 생성되고 병합된 두 변경 요청 간의 잠재적인 비호환성을 감지하기 위해).
  6. 다음 작업은 차례로 실행됩니다(사용자가 직접 트리거하거나 사용자가 회귀 보고서를 허용하도록 사전 정의된 시간 후에 트리거함).
    1. 개발 Fleet의 모든 클러스터에 배포합니다.
    2. 개발 Fleet 클러스터에서 테스트 및 유효성 검사를 실행합니다.
    3. 스테이징 Fleet의 카나리아 클러스터에 배포합니다.
    4. 스테이징 Fleet의 카나리아 클러스터에서 테스트 및 유효성 검사를 실행합니다.
    5. 스테이징 Fleet의 모든 클러스터에 배포합니다.
    6. 스테이징 Fleet의 클러스터에서 테스트 및 유효성 검사를 실행합니다.
    7. 프로덕션 Fleet의 카나리아 클러스터에 배포합니다.
    8. 프로덕션 Fleet의 카나리아 클러스터에서 테스트 및 유효성 검사를 실행합니다.
    9. 프로덕션 Fleet의 모든 클러스터에 배포합니다.
    10. 프로덕션 Fleet의 클러스터에서 테스트 및 유효성 검사를 실행합니다.

전체 출시 절차.

다음 단계