네임스페이스 상속 개요

이 페이지에서는 Anthos Config Management가 저장소 구조에 따라 계층 구조로 클러스터의 네임스페이스에 구성을 적용하는 방법을 설명합니다.

네임스페이스 상속 작동 방식

Anthos Config Management의 가장 강력한 기능 중 하나는 저장소 내 구성 위치를 토대로 네임스페이스가 있는(또는 있어야 하는) 모든 클러스터에서 구성을 자동으로 네임스페이스 그룹에 적용하는 것입니다.

Anthos Config Management는 저장소 및 모든 하위 디렉터리의 namespaces/ 디렉터리에 상속 개념을 도입합니다. 저장소의 다른 디렉터리(예: cluster/)에 있는 구성은 상속되지 않습니다.

저장소에서 namespaces/ 디렉터리에는 다음 두 가지 유형의 하위 디렉터리가 포함될 수 있습니다.

  • 네임스페이스 디렉터리에는 네임스페이스 구성이 포함됩니다. 구성이 포함된 파일의 이름은 중요하지 않지만 구성에는 kind: Namespace가 있어야 합니다. 또한 네임스페이스 디렉터리에는 다른 종류의 Kubernetes 객체 구성도 포함될 수 있습니다. 네임스페이스 디렉토리에는 하위 디렉토리가 포함될 수 없습니다. 네임스페이스 구성은 클러스터의 실제 네임스페이스를 나타냅니다.

  • 추상 네임스페이스 디렉터리에는 네임스페이스 디렉터리가 포함됩니다. 또한 다른 Kubernetes 객체 구성도 포함될 수 있지만 네임스페이스 구성이 직접 포함될 수는 없습니다. 추상 네임스페이스 디렉터리는 Kubernetes 클러스터의 객체를 나타내지 않지만 하위 네임스페이스 디렉터리는 이러한 객체를 나타냅니다.

네임스페이스 디렉터리에 네임스페이스 구성을 추가하는 것을 잊거나, 네임스페이스 하위 디렉터리에 디렉터리를 추가하거나, 추상 네임스페이스 디렉터리에 네임스페이스 구성을 추가하면 KNV1003: IllegalNamespaceSubdirectoryError 오류가 발생합니다.

네임스페이스 디렉터리에 있는 구성은 해당 네임스페이스에만 적용되지만 추상 네임스페이스 디렉터리에 있는 구성은 해당 추상 네임스페이스의 모든 하위 네임스페이스 디렉터리(또는 구성의 NamespaceSelector와 일치하는 하위 네임스페이스(있는 경우))에 적용되기 때문입니다.

namespaces/ 디렉터리에 있는 구성의 상속은 주로 저장소의 디렉터리 트리 내 위치를 기반하고 있으므로 저장소를 탐색하면 지정된 클러스터의 지정된 네임스페이스에 적용되는 구성을 파악할 수 있습니다.

다음 다이어그램은 저장소 예시 namespaces/ 디렉터리에 어떻게 구성이 상속되는지 보여줍니다. 파란색 직사각형은 추상 네임스페이스 디렉터리를 나타내고, 주황색 직사각형은 Kubernetes의 실제 네임스페이스를 나타냅니다.

저장소 예시의 구성 상속을 보여주는 다이어그램

예를 들어 브라우저에서 viewers-rolebinding.yaml 파일을 엽니다. 이 파일은 namespaces 디렉터리 자체에 있으므로 모든 등록된 클러스터의 Anthos Config Management에서 관리되는 모든 네임스페이스에 있는 view ClusterRole을 system:serviceaccounts:audit 그룹 내 모든 사용자에게 부여합니다.

이제 브라우저에서 namespaces/online/ 디렉터리를 엽니다. online 디렉터리에는 네임스페이스 구성이 없으므로 이 디렉터리는 추상 네임스페이스 디렉터리입니다. shipping-app-backend 디렉터리를 클릭합니다. 이 디렉터리도 추상 네임스페이스 디렉터리이며 구성 두 개(pod-creator-rolebinding.yamlquota.yaml)를 포함합니다. 각각의 하위 디렉터리 세 개는 네임스페이스 구성을 포함하므로 네임스페이스 디렉터리입니다. 파일 이름은 중요하지 않지만 이 저장소는 규칙에 따라 모든 네임스페이스 구성에 이 파일 이름을 사용합니다. 이러한 각 네임스페이스는 shipping-app-backend 추상 네임스페이스 디렉터리의 pod-creator-rolebinding.yaml 구성과 quota.yaml 구성을 상속합니다.

shipping-dev 네임스페이스 디렉터리에는 job-creators RoleBinding의 추가 구성이 있지만 다른 두 네임스페이스 디렉터리에는 이 구성이 없으므로(다른 사용자가 수동으로 작성하지 않는 한) RoleBinding이 없습니다.

namespaces/에서 허용되지 않는 이름

다음 이름은 예약되어 있으며 저장소의 namespaces/ 디렉터리 내에 있는 네임스페이스 또는 추상 네임스페이스 디렉터리로 사용될 수 없습니다.

  • config-management-system

구성 예

네임스페이스 구성

이 구성은 audit이라는 네임스페이스를 만듭니다.

apiVersion: v1
kind: Namespace
metadata:
  name: audit

네임스페이스 구성을 만들 때 네임스페이스에 라벨을 추가할 수도 있으며 이를 NamespaceSelector와 함께 사용하면 유용할 수 있습니다.

다음 구성은 네임스페이스가 없거나 configmanagement.gke.io/managed 라벨 없이 있으면 shipping-prod라는 네임스페이스를 만들고 env: prod를 할당합니다. 또한 audit 주석이 네임스페이스에 true로 설정되도록 합니다. 사용자가 수동으로 이 주석을 수정 또는 삭제하면 Anthos Config Management는 신속하게 주석을 구성 값으로 재설정합니다.

apiVersion: v1
kind: Namespace
metadata:
  name: shipping-prod
  labels:
    env: prod
  annotations:
    audit: "true"

ResourceQuota 구성

다음 예시에서는 Pod 1개, 0.1 CPU(100밀리 CPU), 100MiB 메모리에 대한 엄격한 제한을 설정하는 quota라는 ResourceQuota를 만듭니다.

kind: ResourceQuota
apiVersion: v1
metadata:
  name: quota
spec:
  hard:
    pods: "1"
    cpu: "100m"
    memory: 100Mi

이 구성을 특정 네임스페이스(namespaces/[NAMESPACE_NAME])에 적용되는 디렉터리에 배치하면 구성은 이 네임스페이스에만 적용됩니다. 이 구성을 네임스페이스 하위 항목이 포함된 추상 네임스페이스 디렉터리(namespaces/)에 배치하면 별도의 ResourceQuota는 각 하위 항목의 네임스페이스에 적용됩니다.

Git 작업이 네임스페이스에 미치는 영향

namespaces/ 디렉터리 내에서 네임스페이스 디렉터리를 만들거나 삭제하는 Git 작업은 처음 예상과는 다른 영향을 미칠 수 있습니다. 이 섹션에서는 이러한 상호작용을 설명합니다.

namespaces/에 디렉터리 만들기

유효한 namespaces/ 계층 구조가 저장소에 커밋되면 Anthos Config Management는 네임스페이스를 만든 후 네임스페이스 디렉터리에 있거나 상속되는 각 구성의 관련 네임스페이스에 Kubernetes 객체를 만듭니다.

namespaces/에서 디렉터리 삭제

네임스페이스 디렉터리 삭제는 파괴적인 작업입니다. 네임스페이스가 있는 Anthos Config Management에서 관리되는 모든 클러스터의 관련 콘텐츠와 함께 네임스페이스가 삭제됩니다.

하위 네임스페이스 디렉터리가 있는 추상 네임스페이스 디렉터리를 삭제하면 Anthos Config Management가 관리하는 모든 클러스터에서 이 네임스페이스와 해당 콘텐츠가 모두 삭제됩니다.

namespaces/에서 디렉터리 이름 바꾸기

네임스페이스 디렉터리 이름 바꾸기는 삭제만들기이므로 역시 파괴적인 작업입니다.

추상 네임스페이스 디렉터리 이름을 바꿔도 외부에서 보이는 영향이 없습니다.

namespaces/에서 디렉터리 이동

namespaces/ 내에서 네임스페이스 또는 추상 네임스페이스 디렉터리를 이동해도 네임스페이스나 그 안에 있는 객체는 삭제되지 않습니다. 단, 계층 구조 변경으로 인해 네임스페이스가 추상 네임스페이스 디렉터리에서 구성 상속을 시작 또는 중지하는 경우는 예외입니다.

다음 단계