名前空間の継承の概要

このページでは、Anthos Config Management が、リポジトリの構造に基づいて、階層内でクラスタ内の名前空間にコンフィグを適用する方法について説明します。

名前空間の継承の仕組み

Anthos Config Management の優れた一面として、該当する名前空間が存在する(または存在する必要がある)すべてのクラスタにおいて、コンフィグがリポ内のどこに配置されているかに基づいて名前空間のグループにコンフィグを自動的に適用できることが挙げられます。

Anthos Config Management では、リポジトリの namespaces/ ディレクトリとそのすべてのサブディレクトリに継承の概念が導入されています。リポジトリの他のディレクトリ(cluster/ など)のコンフィグは、継承の対象ではありません。

リポ では、namespaces/ ディレクトリに次の 2 種類のサブディレクトリを含めることができます。

  • 1 つの名前空間のコンフィグを含む名前空間ディレクトリ。コンフィグを含むファイルの名前は重要ではありませんが、コンフィグには kind: Namespace が含まれている必要があります。名前空間ディレクトリには、他の種類の Kubernetes オブジェクトのコンフィグも含めることができます。名前空間ディレクトリにサブディレクトリを含めることはできません。名前空間コンフィグは、クラスタ内の実際の名前空間を表します。

  • 複数の名前空間ディレクトリを含む抽象名前空間ディレクトリ。他の Kubernetes オブジェクトのコンフィグも含めることができますが、名前空間のコンフィグを直下に含めることはできません。Kubernetes クラスタ内のオブジェクトを表すのは抽象名前空間ディレクトリではなく、その下位の名前空間ディレクトリです。

名前空間の構成ファイルを名前空間ディレクトリに追加し忘れた場合、名前空間サブディレクトリにディレクトリを追加した場合、または名前空間の構成ファイルを抽象名前空間ディレクトリに追加した場合は、エラー KNV1003: IllegalNamespaceSubdirectoryError が発生します。

名前空間ディレクトリ内の構成ファイルはその名前空間にのみ適用され、抽象名前空間ディレクトリ内の構成ファイルは抽象名前空間の下位にある名前空間ディレクトリすべてに適用されます(NamespaceSelector が存在する場合は構成ファイルの NamespaceSelector に一致する下位の名前空間)。

namespaces/ ディレクトリ内の構成ファイルの継承は主に、その構成ファイルがリポのディレクトリ ツリーのどこに位置しているかに基づくため、リポの構造を見ることで、特定のクラスタ内の特定の名前空間にどの構成ファイルが適用されるかがわかります。

次の図は、サンプルリポnamespaces/ ディレクトリ内でコンフィグがどのように継承されるかを表しています。青い四角形は抽象名前空間ディレクトリを表し、オレンジ色の四角形は Kubernetes の実際の名前空間を表します。

サンプルリポでのコンフィグの継承を示す図

たとえば、viewers-rolebinding.yaml ファイルをブラウザで開きます。このファイルは namespaces ディレクトリ自体に存在するため、Anthos Config Management によって管理され、登録されたすべてのクラスタのすべての名前空間では、system:serviceaccounts:audit グループのすべてのユーザーには view ClusterRole が付与されます。

次に、namespaces/online/ ディレクトリをブラウザで開きます。online ディレクトリには、名前空間のコンフィグがないため、抽象名前空間ディレクトリです。shipping-app-backend ディレクトリをクリックします。これも抽象名前空間ディレクトリで、2 つの構成ファイル(pod-creator-rolebinding.yamlquota.yaml)を含んでいます。3 つのサブディレクトリにはそれぞれ名前空間の構成ファイルが含まれているため、名前空間ディレクトリです。ファイルの名前は重要ではありませんが、このリポでは慣例により、すべての 名前空間構成ファイルに対してこうしたファイル名を使用しています。これらの各名前空間には、shipping-app-backend 抽象名前空間ディレクトリにある pod-creator-rolebinding.yaml 構成ファイルと quota.yaml 構成ファイルが継承されます。

shipping-dev 名前空間ディレクトリには job-creators RoleBinding に対する別のコンフィグがありますが、他の 2 つの名前空間ディレクトリにこのコンフィグはないため、これらの名前空間にその RoleBinding は存在しません(誰かが手動で作成した場合を除く)。

namespaces/ で禁止の名前

次の名前は予約されており、リポの namespaces/ ディレクトリ内で名前空間または抽象名前空間ディレクトリとして使用することはできません。

  • config-management-system

コンフィグの例

Namespace の構成ファイル

次の構成ファイルは audit という名前空間を作成します。

apiVersion: v1
kind: Namespace
metadata:
  name: audit

名前空間コンフィグを作成するとき、名前空間にラベルを付けることもできます。これは NamespaceSelector と組み合わせると便利です。

次のコンフィグは、shipping-prod という Namespace がまだ存在しない場合、または configmanagement.gke.io/managed ラベルなしですでに存在する場合に名前空間を作成し、env: prod を割り当てます。また、audit というアノテーションが名前空間に対して確実に true に設定されるようにします。誰かが手動でそのアノテーションを変更または削除した場合は、Anthos Config Management によってすぐにコンフィグの値にリセットされます。

apiVersion: v1
kind: Namespace
metadata:
  name: shipping-prod
  labels:
    env: prod
  annotations:
    audit: "true"

ResourceQuota コンフィグ

次の例は quota という ResourceQuota を作成します。これは、1 Pod、0.1 CPU(100 ミリ CPU)、メモリ 100 MiB というハードリミットを設定します。

kind: ResourceQuota
apiVersion: v1
metadata:
  name: quota
spec:
  hard:
    pods: "1"
    cpu: "100m"
    memory: 100Mi

この構成ファイルを、特定の名前空間に適用されるディレクトリ(namespaces/[NAMESPACE_NAME])に置く場合、構成ファイルはその名前空間にのみ適用されます。この構成ファイルを、名前空間の下位ディレクトリを含む 抽象名前空間ディレクトリnamespaces/)に置く場合は、別の ResourceQuota が下位名前空間のそれぞれに適用されます。

Git 操作が名前空間に及ぼす影響

Git 操作によって namespaces/ ディレクトリ内に名前空間ディレクトリを作成または削除すると、当初期待したものとは異なる結果になる場合があります。このセクションでは、それらの相互作用について説明します。

namespaces/ にディレクトリを作成する

有効な namespaces/ 階層がリポに commit されると、Anthos Config Management は名前空間を作成してから、名前空間ディレクトリに含まれるコンフィグまたは継承されたコンフィグに対応する Kubernetes オブジェクトをそれらの名前空間に作成します。

namespaces/ のディレクトリを削除する

名前空間ディレクトリを削除することは破壊的な操作です。Anthos Config Management によって管理されているクラスタのうち、その名前空間が存在するすべてのクラスタから、名前空間とそのすべての内容が削除されます。

下位の名前空間ディレクトリを含む抽象名前空間ディレクトリを削除すると、それらの名前空間とその内容はすべて、Anthos Config Management によって管理されているすべてのクラスタから削除されます。

namespaces/ 内のディレクトリの名前を変更する

名前空間ディレクトリの名前を変更すると、いったん削除した後再び作成されるため、これも破壊的な操作です。

抽象名前空間ディレクトリの名前を変更しても、外部から見える影響はありません。

namespaces/ 内のディレクトリを移動する

namespaces/ 内で名前空間または抽象名前空間ディレクトリを移動しても、その 名前空間やその中のオブジェクトは削除されません。ただし、その階層が変更された結果、抽象名前空間ディレクトリからの構成ファイルの継承が開始または停止される場合は除きます。

次のステップ