構成ファイルを作成する

このページでは、構成ファイルの作成方法について説明します。構成ファイルは、Config Sync が Git から読み取り、クラスタに自動的に適用するファイルです。

構成ファイルの詳細とリポジトリで構成ファイルを使用する方法については、Git リポジトリに構成ファイルを追加するをご覧ください。

始める前に

  • 構成ファイルは YAML または JSON のどちらかの形式で記述するため、これらの構文の基礎知識が必要です。このドキュメントのすべての例で、読みやすい YAML を使用しています。

  • 構成可能なオプションは Kubernetes オブジェクトのタイプによって異なります。あるタイプのオブジェクトの構成ファイルを記述する際、どうすれば手動で目的の構成が達成されるかを事前に確認することが有用です。

  • 階層リポジトリを使用する場合は、階層リポジトリの構造を理解する必要があります。構成ファイルをリポジトリ内のどこに配置するかによって、その構成ファイルがどのクラスタ、Namespace に適用されるかが決まります。これは特に namespaces/ ディレクトリに当てはまります。namespaces/ ディレクトリのサブディレクトリは、上位の抽象 Namespace のディレクトリから構成ファイルを継承できるからです。

構成ファイルを作成する

構成ファイルを作成するときは、その構成ファイルを配置するリポ内の最適な場所と、構成ファイルに含めるフィールドを決める必要があります。

リポジトリ内の場所

  • 非構造化リポジトリの場合は、構成ファイルを任意に整理し、リソースのサブフォルダを作成できます。

  • 階層型リポジトリの場合、リポジトリ内の構成ファイルの場所は、構成ファイルが適用されるクラスタを決定する要因の 1 つになります。

    • Namespace を除くクラスタ スコープ オブジェクトの構成ファイルは、リポジトリの cluster/ ディレクトリに保存されます。
    • Namespace オブジェクトと Namespace スコープ オブジェクトの構成ファイルは、リポジトリの namespaces/ ディレクトリに保存されます。
    • Config Sync コンポーネントの構成ファイルは、リポジトリの system/ ディレクトリに保存されます。
    • Config Management Operator の構成ファイルは、リポジトリに直接保存されず、同期されません。

構成ファイルの内容

構成ファイルは、kubectl と同様に加法的アプローチをとります。新しいオブジェクトを作成するときは、すべての必須フィールドを含める必要があります。ただし、既存のオブジェクトを更新する場合は、更新が必要なフィールドのみを指定します。

構成ファイルが適用されたとき、それは必ず有効な Kubernetes オブジェクトになる必要があります。

構成ファイルの例

Anthos Config Management のサンプル リポジトリでは、Config Sync の仕組みについて説明しています。次のタイプのリポジトリの例が含まれています。

以下の構成ファイルの例はすべてサンプル リポジトリから取得されます。サンプル リポジトリをブラウザで開いておくか、ローカル システムにサンプル リポジトリのクローンを作成することをおすすめします。

以下の例は、一例にすぎません。Config Sync を使用して、どのようなタイプの Kubernetes オブジェクトでも構成できます。

名前空間構成ファイル

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

apiVersion: v1
kind: Namespace
metadata:
  name: gamestore

Namespace 構成ファイルを作成するとき、その Namespace にラベルまたはアノテーションを付けることもできます。NamespaceSelector を使用する場合にはラベルが必要です。

次の例では、gamestore という Namespace がまだ存在しない場合や管理されていない場合、構成ファイルでこの Namespace が作成されます。Namespace にはラベル app: gamestore とアノテーション retail: true があります。手動でそのオブジェクトのメタデータが変更された場合は、直ちに Config Sync によって構成ファイルの値にリセットされます。

apiVersion: v1
kind: Namespace
metadata:
  name: gamestore
  labels:
    app: gamestore
  annotations:
    retail: "true"

Namespace の使用について詳しくは、Namespace オブジェクトと Namespace スコープ オブジェクトの構成をご覧ください。

ClusterRole 構成ファイル

この構成ファイルでは、namespace-reader という名前の ClusterRole が作成されます。この ClusterRole は、クラスタ内のすべての namespace オブジェクトを読み取る（get、watch、list）ことが可能です。ClusterRole 構成ファイルは通常、ClusterRoleBinding 構成ファイルと組み合わせて使用します。

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: namespace-reader
rules:
- apiGroups: [""]
  resources: ["namespaces"]
  verbs: ["get", "watch", "list"]

ClusterRoleBinding 構成ファイル

この構成ファイルでは、namespace-readers という ClusterRoleBinding が作成され、ユーザー cheryl@example.com に namespace-reader ClusterRole が付与されます。

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: namespace-readers
subjects:
- kind: User
  name: cheryl@example.com
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: namespace-reader
  apiGroup: rbac.authorization.k8s.io

ClusterRoleBinding はクラスタスコープであり、Namespace ディレクトリまたは抽象名前空間に配置することはできません。

PodSecurityPolicy 構成ファイル

次の例は psp という PodSecurityPolicy を作成します。これは、特権付きコンテナの実行は禁止し、コンテナをノード上の任意の有効なユーザーとして実行することは許可します。

apiVersion: extensions/v1beta1
kind: PodSecurityPolicy
metadata:
  name: psp
spec:
  privileged: false
  seLinux:
    rule: RunAsAny
  supplementalGroups:
    rule: RunAsAny
  runAsUser:
    rule: RunAsAny
  fsGroup:
    rule: RunAsAny
  volumes:
  - '*'

PodSecurityPolicy はクラスタスコープであり、Namespace ディレクトリまたは抽象名前空間に配置することはできません。

NetworkPolicy 構成ファイル

次の例は default-deny-all-traffic という NetworkPolicy を作成します。

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: default-deny-all-traffic
spec:
  podSelector: {}

NetworkPolicy は Namespace スコープであり、Namespace ディレクトリまたは抽象名前空間にのみ配置できます。

上記の NetworkPolicy を単一の Namespace に適用すると、その Namespace 内のすべての Pod が上り（内向き） / 下り（外向き）トラフィックから切り離されます。

下位の Namespace を持つ抽象名前空間に同じ NetworkPolicy を配置して複数の Namespace に適用すると、それぞれの Namespace にこの NetworkPolicy が継承されます。Namespace 継承サンプル リポジトリでは、namespaces ディレクトリに eng と rnd の 2 つの抽象名前空間があり、各抽象名前空間には実際の名前空間が 2 つ含まれています（それぞれ analytics と gamestore、incubator-1 と incubator-2）。上記の default-deny-all-traffic NetworkPolicy を抽象名前空間に追加すると、4 つの実際の名前空間は NetworkPolicy を継承するため、各 Pod は上り（内向き）と下り（外向き）トラフィックから保護されます。

Namespace の継承を使用して最小限の権限のセキュリティ原則を適用できます。たとえば、上記の NetworkPolicy の例が抽象名前空間の両方に適用され、次の NetworkPolicy が eng 抽象名前空間に追加された場合、上り（内向き）トラフィックは下位の Namespace 内で app:gamestore ラベルの付いた Pod にのみ許可されます。Namespace analytics、incubator-1、incubator-2 は、この NetworkPolicy の影響を受けません。

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-gamestore-ingress
spec:
  podSelector:
    matchLabels:
      app: gamestore
  ingress:
  - {}

ResourceQuota 構成ファイル

この例では、quota という ResourceQuota を作成します。これは、1 Pod、100 ミリ CPU、メモリ 100 メビバイト（Mi）というハードリミットを設定します。

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

特定のタイプの新しいオブジェクトを作成することが既存の ResourceQuota に違反する場合、その Kubernetes オブジェクトは ResourceQuota に違反しなくなるまで作成できません。

RepoSync 構成ファイル

この例では、ルート リポジトリ内に RepoSync オブジェクトを作成し、Namespace リポジトリから同期しています。RepoSync オブジェクトの構成の詳細については、複数のリポジトリからの同期の構成をご覧ください。

apiVersion: configsync.gke.io/v1beta1
kind: RepoSync
metadata:
  name: repo-sync
  namespace: gamestore
spec:
  sourceFormat: unstructured
  git:
    repo: https://github.com/GoogleCloudPlatform/anthos-config-management-samples
    branch: main
    dir: quickstart/multirepo/namespaces/gamestore
    auth: none

Config Sync は、Namespace リポジトリから同期するための Namespace Reconciler を作成します。

次のステップ