네임스페이스 상속 개요

이 페이지에서는 구성 동기화가 계층적 저장소 구조를 기반으로 계층 구조의 클러스터에 있는 네임스페이스에 구성을 적용하는 방법을 설명합니다. 네임스페이스 및 네임스페이스 범위 객체 구성에 대해서도 알아볼 수 있습니다. 구조화되지 않은 저장소의 경우 비슷한 기능에 대해 계층 구조 컨트롤러를 사용할 수 있습니다.

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

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

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

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

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

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

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

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

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

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

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

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

이제 브라우저에서 namespaces/eng/ 디렉터리를 엽니다. eng 디렉터리에는 네임스페이스 구성이 없으므로 이 디렉터리는 추상 네임스페이스 디렉터리입니다. 여기에는 다음 구성이 포함됩니다.

  • eng-role.yaml
  • eng-rolebinding.yaml
  • network-policy-allow-gamestore-ingress.yaml
  • quota.yaml
  • selectors.yaml

각각의 하위 디렉터리 2개는 네임스페이스 구성을 포함하므로 네임스페이스 디렉터리입니다. 파일 이름은 중요하지 않지만 이 저장소는 규칙에 따라 모든 네임스페이스 구성에 이 파일 이름을 사용합니다. 이러한 각 네임스페이스는 eng 추상 네임스페이스 디렉터리의 eng-role.yaml, eng-rolebinding.yaml, network-policy-allow-gamestore-ingress.yaml 구성을 상속합니다. quota.yaml에 정의된 ResourceQuota 객체는 해당 NamespaceSelector와 일치하는 네임스페이스에만 적용됩니다.

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

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

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

  • config-management-system

구성 예시

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는 각 하위 항목의 네임스페이스에 적용됩니다. NamespaceSelector 주석으로 ResourceQuota를 만들 때 구성은 NamespaceSelector와 일치하는 네임스페이스에만 적용됩니다.

상속에서 네임스페이스 제외

네임스페이스 선택기를 사용하여 특정 네임스페이스를 트리의 리소스 상속으로부터 제외할 수 있습니다.

다음 예시에서는 루트 /namespaces 디렉터리에 올바르게 주석 처리된 ResourceQuota 객체가 quota-exempt: exempt 라벨이 지정된 객체를 제외한 모든 네임스페이스에서 상속되도록 합니다.

kind: NamespaceSelector
 apiVersion: configmanagement.gke.io/v1
 metadata:
   name: excludes-exempt-namespaces
 spec:
   selector:
     matchExpressions:
       - key: quota-exempt
         operator: NotIn
          values:
            - exempt

구성 동기화의 NamesspaceSelectors에 대해 자세히 알아보려면 구성 영향을 받는 네임스페이스 제한을 참조하세요.

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

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

namespaces/에 디렉터리 만들기

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

namespaces/에서 디렉터리 삭제

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

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

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

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

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

namespaces/에서 디렉터리 이동

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

계층 구조 컨트롤러와 통합

계층 구조 컨트롤러의 개념은 계층 구조 컨트롤러 문서에 설명된 대로 추상 네임스페이스에서 지원하는 네임스페이스 상속과 매우 유사한 개념입니다. 하지만 계층적 리소스 할당량셀프서비스 네임스페이스와 같은 일부 추가적인 기능을 지원합니다.

관련 네임스페이스 선택

공통의 상위를 통해 관련된 네임스페이스 집합에 정책을 적용해야 하는 경우가 있습니다. 계층 구조 컨트롤러는 트리 라벨이라는 개념을 사용하여 이를 지원하며, 계층 구조 컨트롤러가 사용 설정되어 있지 않아도 추상 네임 스페이스에서 지원됩니다.

트리 라벨은 Kubernetes 라벨로, 다음과 같은 형식입니다.

<namespace-name>.tree.hnc.x-k8s.io/depth: <depth>

예를 들어 이러한 라벨을 사용하면 네트워크 정책의 일부로 사용될 수 있는 네임스페이스 선택기를 작성하여 관련 네임스페이스의 하위 트리 내에서는 트래픽을 허용하되 해당 하위 트리 외부의 트래픽은 허용하지 않도록 할 수 있습니다.

저장소 예시의 다이어그램으로 돌아가서 이 개념을 설명할 수 있습니다.

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

예를 들어 gamestore 네임스페이스에는 다음과 같은 트리 라벨이 있습니다.

eng.tree.hnc.x-k8s.io/depth: "1"
gamestore.tree.hnc.x-k8s.io/depth: "0"

Git 저장소에 액세스하지 않고도 kubectl을 사용하여 클러스터에서 직접 이러한 관계를 검사할 수 있습니다.

# View all descendants of 'eng'
kubectl get namespaces -l 'eng.tree.hnc.x-k8s.io/depth'

# View any immediate children of 'eng'
kubectl get namespaces -l 'eng.tree.hnc.x-k8s.io/depth=1'

계층 구조 컨트롤러는 모든 트리 라벨을 모든 추상 네임스페이스에서 모든 하위 네임 스페이스로 전파합니다. 예를 들어 gamestore의 하위 네임스페이스를 만드는 경우 다음과 같습니다.

kubectl hns create gamestore-v1 -n gamestore

이 경우 gamestore-v1 네임스페이스에는 상위 요소의 모든 라벨이 포함되며 깊이가 적절히 조절된 자체 라벨도 포함됩니다.

eng.tree.hnc.x-k8s.io/depth: 2
gamestore-v1.tree.hnc.x-k8s.io/depth: 0
gamestore.tree.hnc.x-k8s.io/depth: 1

다음 단계