네임스페이스 상속 및 추상 네임스페이스

이 페이지에서는 구성 동기화 계층적 저장소에서 네임스페이스 상속 개념을 활용하는 방법을 설명합니다.

구성 구조를 사용하면 저장소 구조에 따라 네임스페이스가 있거나 있어야 하는 모든 클러스터의 네임스페이스 그룹에 구성을 자동으로 적용할 수 있습니다. 이러한 네임스페이스 그룹을 추상 네임스페이스라고 합니다.

네임스페이스 상속 및 추상 네임스페이스는 구조화되지 않은 저장소에서는 지원되지 않습니다. 구조화되지 않은 저장소를 사용 중이지만 비슷한 기능이 필요한 경우에는 계층 구조 컨트롤러를 사용하세요.

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

네임스페이스 상속은 계층적 저장소의 namespaces/ 디렉터리와 모든 하위 디렉터리에 적용됩니다. 저장소의 다른 디렉터리(예: cluster/)에 있는 구성은 상속되지 않습니다.

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

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

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

네임스페이스와 추상 네임스페이스 저장소의 구성 및 구조 유형이 올바른지 확인하기 위해 문제 발생 시 KNV1003: IllegalNamespaceSubdirectoryError 오류가 보고됩니다.

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

네임스페이스 상속 예시

namespaces/ 디렉터리의 구성 상속은 주로 저장소의 디렉터리 트리 내 위치에 기반합니다. 특정 클러스터의 지정된 네임스페이스에 적용되는 구성을 이해하려면 네임스페이스 상속 예시 저장소를 살펴볼 수 있습니다.

네임스페이스 상속 예시 저장소의 namespaces/ 디렉터리에는 다음과 같은 아키텍처가 있습니다.

├── namespaces # Namespace directory
│   ├── eng # Namespace directory
│   │   ├── analytics # Abstract namespace directory
│   │   └── gamestore # Abstract namespace directory
│   ├── rnd # Namespace directory
│   │   ├── incubator-1 # Abstract namespace directory
│   │   └── incubator-2 # Abstract namespace directory
|   |── network-policy-default-deny-all.yaml
|   |── viewers-rolebinding.yaml

이 예시 저장소의 작동 방식을 자세히 알아보려면 먼저 viewers-rolebinding.yaml을 살펴보세요.

namespace-inheritance/config/namespaces/viewers-rolebinding.yaml

GitHub에서 보기

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: viewers
subjects:
- kind: Group
  name: system:serviceaccounts:foo
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: view
  apiGroup: rbac.authorization.k8s.io

이 RoleBinding은 namespaces/ 디렉터리의 루트에 있으므로 system:serviceaccounts:foo 그룹의 모든 사용자에게 구성 동기화가 관리하는 모든 네임스페이스의 view ClusterRole을 부여합니다.

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

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

또한 eng 디렉터리에는 analytics 및 gamestore라는 두 개의 하위 디렉터리가 있습니다. 이러한 하위 디렉터리에는 각각 네임스페이스의 구성이 포함되므로 네임스페이스 디렉터리입니다. 이 예시에서는 네임스페이스 구성을 namespace.yaml이라고 하지만 원하는 대로 명명할 수 있습니다. analytics 및 gamestore의 각 네임스페이스는 eng 추상 네임스페이스 디렉터리의 eng-role.yaml, eng-rolebinding.yaml, network-policy-allow-gamestore-ingress.yaml 구성을 상속합니다.

quota.yaml에 정의된 ResourceQuota 객체는 NamespaceSelector를 사용하므로 이 ResourceQuota 객체는 analytics 및 gamestore 네임스페이스에서만 생성됩니다.

참고: ResourceQuotas는 단일 네임스페이스에만 적용됩니다. 반대로 HierarchicalResourceQuotas는 계층적 네임스페이스의 트리에서 리소스 사용을 제한할 수 있지만 추상 네임스페이스에서 지원되지 않습니다. 추상 네임스페이스에 계층적 할당량을 배치하면 해당 할당량의 독립적 복사본이 모든 하위 요소에 배치됩니다. 계층적 리소스 할당량을 사용하려면 계층 구조 컨트롤러에서 제공되는 계층적 네임스페이스를 사용합니다.

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

네임스페이스 상속 저장소에는 네임스페이스 상속 작동 방식의 추가 예시가 있는 README.md 파일도 있습니다.

제한된 네임스페이스

config-management-system은 제한된 네임스페이스입니다. 추상 네임스페이스 디렉터리로 사용할 수 없습니다. 버전 1.11.0 이상에서는 config-management-system 네임스페이스를 정의할 수 있습니다. 하지만 config-management-system 네임스페이스에 허용되는 리소스 유형은 RootSync뿐입니다.

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

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

다음 예시에서는 루트 /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

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

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

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

주의사항: 기본적으로 Git 저장소는 세분화된 액세스 권한 제어를 제공하지 않습니다. 저장소에 대한 커밋 권한이 있는 사용자 집합이 클러스터에서 Kubernetes 객체를 생성, 수정 또는 삭제할 수 있는 사용자 집합과 정확하게 일치하지 않으면 저장소에서 OWNERS 또는 CODEOWNERS 파일과 같은 액세스 제어 메커니즘을 사용하는 것이 좋습니다.

namespaces/에 디렉터리 만들기

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

namespaces/에서 디렉터리 삭제

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

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

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

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

참고: 네임스페이스 디렉터리 이름을 바꾸면 네임스페이스 구성에서 이름도 업데이트해야 합니다.

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

namespaces/에서 디렉터리 이동

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

계층 구조 컨트롤러와 통합

베타

이 제품에는 Google Cloud 서비스 약관의 GA 이전 제공 서비스 약관이 적용됩니다. GA 이전 제품은 지원이 제한될 수 있으며, GA 이전 제품의 변경사항이 다른 GA 이전 버전과 호환되지 않을 수 있습니다. 자세한 내용은 출시 단계 설명을 참조하세요.

중요: 계층 구조 컨트롤러 및 관련 기능에는 구성 동기화 버전 1.4.1 이상이 필요합니다.

계층 구조 컨트롤러를 사용하면 추상 네임스페이스와 유사한 계층적 네임스페이스를 사용할 수 있습니다. 계층 구조 컨트롤러는 계층적 리소스 할당량 및 셀프서비스 네임스페이스와 같은 추가 기능도 지원합니다.

관련 네임스페이스 선택

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

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

NAMESPACE_NAME.tree.hnc.x-k8s.io/depth: DEPTH

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

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

├── namespaces # Namespace directory
│   ├── eng # Namespace directory
│   │   ├── analytics # Abstract namespace directory
│   │   └── gamestore # Abstract namespace directory
│   ├── rnd # Namespace directory
│   │   ├── incubator-1 # Abstract namespace directory
│   │   └── incubator-2 # Abstract namespace directory
|   |── network-policy-default-deny-all.yaml
|   |── viewers-rolebinding.yaml

이 예시에서는 gamestore 추상 네임스페이스 디렉터리의 namespace.yaml에 다음과 같은 트리 라벨이 있다고 가정합니다.

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

다음 단계

• 네임스페이스 및 네임스페이스 범위 객체 관리 방법 알아보기
• Anthos Config Management 샘플 저장소에서 네임스페이스 상속 튜토리얼을 진행합니다.