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

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

名前空間を構成する

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

非構造化リポジトリ

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. リポジトリのローカル クローンで、名前空間ディレクトリを作成します。1 つの Namespace ディレクトリには Namespace の構成ファイルが 1 つ含まれます。Namespace ディレクトリの名前は、Namespace の名前と一致する必要があります。この例では、ディレクトリの名前は namespaces/gamestore です。

    mkdir namespaces/gamestore

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

    apiVersion: v1
kind: Namespace
metadata:
  name: gamestore

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

  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 を構成する場合は、構成を削除しないでください。

Namespace スコープ オブジェクトを構成する

非構造化リポジトリでは、Namespace 構成ファイルがなくても、任意のディレクトリまたはサブディレクトリに Namespace スコープ オブジェクトを格納できます。Namespace 構成ファイルがない場合、Config Sync は暗黙的な Namespace オブジェクトを自動的に作成し、すべての構成ファイルをこの Namespace に適用します。

この動作は、namespaceStrategy フィールドを使用して変更できます。namespaceStrategy が explicit に設定されている場合、Config Sync は暗黙的な Namespace オブジェクトを自動的に作成しません。詳細については、Namespace 戦略をご覧ください。

階層型リポジトリでは、namespaces/NAMESPACE サブディレクトリに Namespace 構成ファイルを明示的に指定する必要があります。ここで、NAMESPACE は Namespace の名前と一致する必要があります。また、Namespace スコープの他のすべての構成ファイルを同じサブディレクトリに保存する必要があります。Namespace 構成ファイルがない場合、Config Sync は、Namespace 構成ファイルがないことを示す KNV1044 エラーを返します。

抽象 Namespace を構成する

抽象 Namespace は非構造化リポジトリでサポートされていないため、このセクションは階層型リポジトリにのみ適用されます。

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

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

    mkdir namespaces/eng

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

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

    # 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 Sync が変更を認識し、登録されているすべてのクラスタの gamestore Namespace に新しい Role と RoleBinding を適用します。

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

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

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

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

構成ファイルが影響を与える 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 スコープ オブジェクトのすべての Namespace を宣言する必要はありません。オブジェクトは、非構造化リポジトリ内に一致する Namespace オブジェクトがなくても metadata.namespace を定義できます。Namespace がすでにクラスタに存在する場合、Config Sync はその Namespace 内にオブジェクトを作成します。Namespace がまだクラスタに存在しない場合、Config Sync は Namespace を暗黙的に作成します。

以前に階層型リポジトリで使用されていたオブジェクトを使用して非構造化リポジトリを作成する前に、NamespaceSelectors は追加リソースに適用されないことを確認してください。

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

NamespaceSelector モード

非構造化リポジトリでは、NamespaceSelector アノテーションを宣言するオブジェクトは、NamespaceSelector の条件を満たすすべての Namespace に適用されます。1.17.0 より前のバージョンの Config Sync では、NamespaceSelector アノテーションは信頼できる情報源で静的に宣言された一致する Namespace にのみ適用されます。バージョン 1.17.0 以降では、NamespaceSelector オブジェクトは spec.mode を dynamic に設定することで動的モードをサポートします。動的モードでは、選択は静的に宣言された Namespace と、クラスタに動的に存在する Namespace の両方に拡張されます。動的に選択された Namespace はクラスタにすでに存在するため、Config Sync によって管理されません。デフォルトのモードは static です。

階層型リポジトリの NamespaceSelector

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

NamespaceSelector の場所

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

階層型リポジトリでは、NamespaceSelector は任意の抽象 Namespace ディレクトリに配置できますが、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

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

NamespaceSelector の例

ラベルセレクタで NamespaceSelector を使用して、Namespace を含めるか、除外できます。Kubernetes は、等式ベースとセットベースのセレクタをサポートしています。両方のタイプのセレクタを組み合わせて、選択する Namespace をさらに絞り込むことができます。

等式ベースのラベルセレクタ

次の構成は、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 オブジェクトを参照します。

セットベースのラベルセレクタ

Namespace セレクタを使用し、セットベースのラベルセレクタを用いて特定の Namespace をツリー内のリソースの継承から除外できます。

この例では、アノテーション configmanagement.gke.io/namespace-selector: excludes-exempt-namespaces を設定して ResourceQuota に NamespaceSelector アノテーションを付けると、quota-exempt: exempt というラベルが付いた Namespace を除くすべての Namespace に ResourceQuota が作成されます。

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

チームスコープとフリートの Namespace の統合

Google Cloud で作成されたフリート Namespace には、自動的にラベル fleet.gke.io/fleet-scope: your-scope が付きます。すべての Namespace に、Kubernetes kubernetes.io/metadata.name: your-namespace ラベルも付いています。これらのデフォルトのラベルを使用して、フリート Namespace を選択するために 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

次のステップ