Namespace と Namespace スコープ オブジェクトの構成

このページでは、Config Sync を使用して Namespace オブジェクトと Namespace スコープ オブジェクトを管理する方法について説明します。

名前空間を構成する

名前空間の構成は、非構造化リポジトリと階層型リポジトリで異なります。次の例は、この違いを示しています。

非構造化リポジトリ

名前空間オブジェクトと名前空間スコープ オブジェクトの構成ファイルは、リポジトリのディレクトリまたはサブディレクトリの任意の場所に配置できます。

登録された各クラスタに gamestore という Namespace を構成するには、次の手順に従います。

  1. 次の内容の namespace-gamestore.yaml ファイルを作成します。

    apiVersion: v1
    kind: Namespace
    metadata:
      name: gamestore
    

    必要な作業は、Namespace 構成ファイルを含む YAML ファイルを作成することだけです。

  2. namespace-gamestore.yaml 構成ファイルを含む commit を作成して、commit をリモート リポジトリに push します。

    git add multirepo/root/namespace-gamestore.yaml
    git commit -m "Created gamestore namespace config"
    git push REMOTE_NAME BRANCH_NAME
    

    以下を置き換えます。

    • REMOTE_NAME: リモート リポジトリの名前。
    • BRANCH_NAME: commit するブランチ。

    この例では、ファイルをルート ディレクトリに追加しますが、このファイルをリポジトリの任意のサブディレクトリに移動できます。

階層型リポジトリ

Namespace オブジェクトと Namespace スコープ オブジェクトの構成ファイルはすべて、階層型リポジトリnamespaces/ ディレクトリとその下位ディレクトリに配置されます。

次の手順で、登録された各クラスタに gamestore という Namespace を構成します。

  1. リポジトリのローカル クローンで、Namespace ディレクトリを作成します。1 つの Namespace ディレクトリには Namespace の構成が 1 つ含まれます。Namespace ディレクトリの名前は、Namespace の名前と一致する必要があります。この例では、ディレクトリの名前は namespaces/gamestore です。

    mkdir namespaces/gamestore
    
  2. Namespace ディレクトリに、次の内容のファイル gamestore.yaml を作成します。

    apiVersion: v1
    kind: Namespace
    metadata:
      name: gamestore
    

    metadata.name は名前空間ディレクトリの名前と一致する必要があります。

  3. gamestore.yaml 構成ファイルを含む commit を作成して、commit をリモート リポジトリに push します。

    git add namespaces/gamestore/gamestore.yaml
    git commit -m "Created gamestore namespace config"
    git push REMOTE_NAME BRANCH_NAME
    

    以下を置き換えます。

    • REMOTE_NAME: リモート リポジトリの名前。
    • BRANCH_NAME: commit するブランチ。

しばらくすると、登録された各クラスタに gamestore Namespace が作成されます。確認するには、Namespace を記述します。

kubectl describe namespace gamestore

構成ファイルを削除して、登録されたクラスタから gamestore Namespace を削除するには、ファイルを削除する新しい commit を作成し、リモート リポジトリに push します。階層リポジトリに抽象名前空間を構成する場合は、構成を削除しないでください。

抽象名前空間を構成する

このセクションは、階層型リポジトリにのみ適用されます。抽象 Namespaceは、非構造化リポジトリではサポートされていません。非構造化リポジトリを使用していて、同様の機能が必要な場合は、階層型名前空間を使用します。

この例は、gamestore Namespace によって継承された追加の構成ファイルを含む抽象 Namespace に gamestore Namespace ディレクトリを移動して、Namespace の構成を拡張しています。

  1. リポジトリのローカル クローンで、eng という名前の抽象 Namespace ディレクトリを作成します。

    mkdir namespaces/eng
    

    抽象 Namespace ディレクトリには Namespace の構成は含まれませんが、その下位の Namespace ディレクトリには含まれます。

  2. eng 抽象 Namespace ディレクトリで、eng-viewer という名前のロールの構成を作成します。これにより、最終的にロールを継承する Namespace のすべてのリソースで getlist が付与されます。

    # namespaces/eng/eng-role.yaml
    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      name: eng-viewer
    rules:
    - apiGroups: [""]
      resources: ["*"]
      verbs: ["get", "list"]
    
  3. eng-viewer Role をグループ eng@example.com にバインドする eng-admin という名前の RoleBinding の構成を作成します。

    # namespaces/eng/eng-rolebinding.yaml
    kind: RoleBinding
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: eng-admin
    subjects:
    - kind: Group
      name: eng@example.com
      apiGroup: rbac.authorization.k8s.io
    roleRef:
      kind: Role
      name: eng-viewer
      apiGroup: rbac.authorization.k8s.io
    
  4. gamestore Namespace ディレクトリを namespaces/ ディレクトリから namespaces/eng/ ディレクトリに移動します。

    mv namespaces/gamestore/namespaces/eng/
    
  5. すべての変更を commit して、リモートのリポジトリに push します。

Config Management Operator が変更を認識し、登録されているすべてのクラスタの gamestore Namespace に新しい Role と RoleBinding を適用します。

構成ファイルを削除し、登録されているクラスタから gamestore Namespace を削除するには、eng 抽象名前空間全体を削除する新しい commit を作成し、リモート リポジトリに push します。

構成ファイルを適用するクラスタを制限する

通常、Config Sync は登録済みの各クラスタに構成を適用します。構成ファイルが階層型リポジトリのサブディレクトリ namespaces/ 内にある場合、Config Sync はまず各クラスタ内に Namespace を作成し、継承したすべての構成ファイルをその Namespace に適用します。各クラスタのラベルに基づいて特定のコンフィグが影響を与えるクラスタを制限するには、ClusterSelector を使用します。詳細については、クラスタのサブセットの構成をご覧ください。

構成ファイルを適用する Namespace を制限する

構成が影響を与える名前空間を制限するには、NamespaceSelector を使用します。NamespaceSelector は、Kubernetes の labelSelector を使用する特別なタイプの構成です。非構造化リポジトリまたは階層型リポジトリの Namespace スコープ オブジェクトの構成ファイルと組み合わせて NamespaceSelector を宣言すると、その構成ファイルを継承できる Namespace を制限できます。NamespaceSelector は ClusterSelector と類似していますが、同一ではありません。NamespaceSelector は、構成ファイルが適用される Namespace のプールを絞り込みます。

NamespaceSelector を宣言するには、metadata.namespace アノテーションまたは NamespaceSelector アノテーションのどちらかを追加します。両方のアノテーションを宣言することはできません。Namespace スコープのリソースで metadata.namespace または NamespaceSelector アノテーションが宣言されていない場合、Config Sync はクラスタの「デフォルト」の Namespace を使用します。

非構造化リポジトリの NamespaceSelector

非構造化リポジトリは、リポジトリ内の名前空間スコープ オブジェクトのすべての名前空間を宣言する必要はありません。オブジェクトは、非構造化リポジトリ内に一致する Namespace オブジェクトがなくても metadata.namespace を定義できます。Namespace がすでにクラスタに存在する場合、Config Sync はその Namespace 内にオブジェクトを作成します。Namespace がまだクラスタに存在しない場合、Config Sync は Namespace を暗黙的に作成します。

非構造化リポジトリでは、NamespaceSelector アノテーションを宣言するオブジェクトは、NamespaceSelector の条件を満たすすべての名前空間に適用されます。以前に階層型リポジトリで使用されていたオブジェクトを使用して非構造化リポジトリを作成する前に、NamespaceSelectors は追加リソースに適用されないことを確認してください。

非構造化リポジトリから Namespace スコープ オブジェクトを削除すると、Config Sync によってオブジェクトが削除されますが、その削除されたオブジェクトに対して暗黙的に作成された Namespace は削除されません。これは、Config Sync が暗黙的に作成された Namespace を安全に削除できるタイミングを推測できないためです。このため、暗黙的に作成された Namespace は必ずクラスタに残ります。

階層型リポジトリの NamespaceSelector

階層型リポジトリでは、NamespaceSelector アノテーションを宣言するオブジェクトは、namespaces/ ディレクトリのディレクトリ構造に関係なく、抽象 Namespace の特定の構成ファイルを継承する Namespace に適用されます。ClusterSelector は、構成のターゲットがクラスタ スコープ オブジェクトまたは Namespace スコープ オブジェクトのいずれであるかにかかわらず、構成ファイルが適用されるクラスタのプールを絞り込みます。

NamespaceSelector の場所

非構造化リポジトリでは、任意のディレクトリまたはサブディレクトリに NamespaceSelector を配置できます。

階層リポジトリでは、任意の NamespaceSelector を 抽象名前空間ディレクトリに配置できますが、namespace ディレクトリには配置できません。

次のリポジトリ アーキテクチャの例は、階層リポジトリを使用している場合の NamespaceSelector の有効な場所と無効な場所を示しています。

namespace-inheritance
...
├── namespaces
│   ├── eng
│   │   ├── gamestore
│   │   │   ├── namespace.yaml
│   │   │   └── ns_selector.yaml  # invalid
│   │   └── ns_selector.yaml  # valid
│   ├── ns_selector.yaml  # valid
│   ├── rnd
│   │   ├── incubator-1
│   │   │   ├── namespace.yaml
│   │   │   └── ns_selector.yaml  # invalid
│   │   └── ns_selector.yaml  # valid

namespacesengrnd ディレクトリは抽象 Namespace を表すため、セレクタを配置できます。ただし、gamestoreincubator-1 ディレクトリは実際の Namespace を表しているため、NamespaceSelector を配置できません。

NamespaceSelector の例

次の構成は、gamestore-selector という名前の NamespaceSelector を作成します。別の構成ファイルでこの NamespaceSelector が参照されている場合、その構成ファイルは app: gamestore ラベルを持つ Namespace のオブジェクトにのみ適用されます。

kind: NamespaceSelector
apiVersion: configmanagement.gke.io/v1
metadata:
  name: gamestore-selector
spec:
  selector:
    matchLabels:
      app: gamestore

構成ファイルで NamespaceSelector を参照するには、configmanagement.gke.io/namespace-selector アノテーションを NamespaceSelector の名前に設定します。

NamespaceSelector は、別のコンフィグで参照しなければ効果はありません。 gamestore-selector NamespaceSelector が次の ResourceQuota quota と同じ階層にある場合、ResourceQuota は app: gamestore ラベルを持つ Namespace のみに作成されます。

kind: ResourceQuota
apiVersion: v1
metadata:
  name: quota
  annotations:
    configmanagement.gke.io/namespace-selector: gamestore-selector
spec:
  hard:
    pods: "1"
    cpu: "200m"
    memory: "200Mi"

まとめると、NamespaceSelector の使用は次の 3 段階からなります。

  1. 名前空間にラベルを追加します。
  2. NamespaceSelector 構成ファイルを作成します。
  3. 別の構成ファイルで NamespaceSelector オブジェクトを参照します。

特定のオブジェクト タイプについて継承を無効にする

HierarchyConfig Kubernetes オブジェクトは、非構造化リポジトリではサポートされていません。次の例は、階層型リポジトリにのみ適用されます。

hierarchyMode フィールドを none に設定すると、任意の構成の継承を選択的に無効にできます。HierarchyConfig はリポジトリの system/ ディレクトリに保存されています。次の例では、RoleBinding の継承を無効にします。

# system/hierarchy-config.yaml
kind: HierarchyConfig
apiVersion: configmanagement.gke.io/v1
metadata:
  name: rbac
spec:
  resources:
  # Configure Role to only be allowed in leaf namespaces.
  - group: rbac.authorization.k8s.io
    kinds: [ "RoleBinding" ]
    hierarchyMode: none

次のステップ