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

このトピックでは、Anthos Config Management を使用して 名前空間オブジェクトと名前空間スコープ オブジェクトを管理する方法を説明します。クラスタとクラスタ スコープ オブジェクトの構成もご覧ください。

名前空間の構成

名前空間オブジェクトと名前空間スコープ オブジェクトの構成はすべて、リポジトリnamespaces/ ディレクトリとその下位ディレクトリに配置します。

次の手順で、登録された各クラスタに audit という名前空間を構成します。

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

    mkdir namespaces/audit
    
  2. Namespace ディレクトリに、次の内容のファイル audit.yaml を作成します。metadata.name は、名前空間の名前(および名前空間ディレクトリの名前)と一致する必要があります。

    apiVersion: v1
    kind: Namespace
    metadata:
      name: audit
    
  3. audit.yaml 構成を含む commit を作成して、commit をリモート リポジトリに push します。

    git add namespaces/audit/audit.yaml
    git commit -m "Created audit namespace config"
    git push [NAME-OF-REMOTE] [BRANCH-NAME]
    
  4. しばらくすると、登録された各クラスタに audit 名前空間が作成されます。確認するには、名前空間を記述します。

    kubectl describe namespace audit
    
  5. 構成を削除し、登録されたクラスタから audit 名前空間を削除するには、ファイルを削除する新しい commit を作成し、リモート リポジトリに push します。

抽象 Namespace の構成

この例は、audit 名前空間によって継承された追加の構成を含む抽象名前空間に audit 名前空間ディレクトリを移動して、あ名前空間の構成を拡張しています。

  1. リポジトリのローカル クローンで、regulatory という名前の抽象 Namespace ディレクトリを作成します。抽象名前空間ディレクトリには名前空間の構成は含まれませんが、その下位の名前空間ディレクトリには含まれます。

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

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

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

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

Config Management Operator は変更を認識し、すべての登録されているクラスタの audit 名前空間に新しいロールと RoleBinding を適用します。

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

構成が影響を与えるクラスタの制限

通常、Anthos Config Management は登録済みの各クラスタにコンフィグを適用します。コンフィグが namespaces/ サブディレクトリ内にある場合、Anthos Config Management は、まず各クラスタ内に名前空間を作成し、次に継承されたすべてのコンフィグをその名前空間に適用します。

各クラスタのラベルに基づいて特定の構成が影響を与えるクラスタを制限するには、クラスタのサブセットへの構成の適用をご覧ください。

構成が影響を与える名前空間の制限

NamespaceSelector は、Kubernetes の labelSelector を使用する特別なタイプの構成です。NamespaceSelector を namespaces/ の構成と組み合わせて使用すると、その構成を継承できる名前空間を制限できます。

次の構成は、sre-supported という名前の NamespaceSelector を作成します。別の構成でこの NamespaceSelector が参照されている場合、その構成は env: prod ラベルを持つ名前空間のオブジェクトにのみ適用されます。

kind: NamespaceSelector
apiVersion: configmanagement.gke.io/v1
metadata:
  name: sre-supported
spec:
  selector:
    matchLabels:
      env: prod

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

NamespaceSelector は、別の構成で参照しなければ効果はありません。sre-supported NamespaceSelector が次の RoleBinding sre-admin と同じ階層にある場合、RoleBinding は env: prod ラベルを持つ名前空間のみに作成されます。

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: sre-admin
  annotations:
    configmanagement.gke.io/namespace-selector: sre-supported
subjects:
- kind: Group
  name: sre@foo-corp.com
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: admin
  apiGroup: rbac.authorization.k8s.io

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

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

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

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

次のステップ