構成ファイルを作成する
このページでは、構成ファイルの作成方法について説明します。構成ファイルは、Config Sync が Git から読み取り、クラスタに自動的に適用するファイルです。
構成ファイルの詳細とリポジトリで構成ファイルを使用する方法については、Git リポジトリに構成ファイルを追加するをご覧ください。
始める前に
構成ファイルは YAML または JSON のどちらかの形式で記述するため、これらの構文の基礎知識が必要です。このドキュメントのすべての例で、読みやすい YAML を使用しています。
構成可能なオプションは Kubernetes オブジェクトのタイプによって異なります。あるタイプのオブジェクトの構成ファイルを記述する際、どうすれば手動で目的の構成が達成されるかを事前に確認することが有用です。
階層リポジトリを使用する場合は、階層リポジトリの構造を理解する必要があります。構成ファイルをリポジトリ内のどこに配置するかによって、その構成ファイルがどのクラスタ、Namespace に適用されるかが決まります。これは特に
namespaces/
ディレクトリに当てはまります。namespaces/
ディレクトリのサブディレクトリは、上位の抽象 Namespace のディレクトリから構成ファイルを継承できるからです。
構成ファイルを作成する
構成ファイルを作成するときは、その構成ファイルを配置するリポ内の最適な場所と、構成ファイルに含めるフィールドを決める必要があります。
リポジトリ内の場所
非構造化リポジトリの場合は、構成ファイルを任意に整理し、リソースのサブフォルダを作成できます。
階層型リポジトリの場合、リポジトリ内の構成ファイルの場所は、構成ファイルが適用されるクラスタを決定する要因の 1 つになります。
- Namespace を除くクラスタ スコープ オブジェクトの構成ファイルは、リポジトリの
cluster/
ディレクトリに保存されます。 - Namespace オブジェクトと Namespace スコープ オブジェクトの構成ファイルは、リポジトリの
namespaces/
ディレクトリに保存されます。 - Config Sync コンポーネントの構成ファイルは、リポジトリの
system/
ディレクトリに保存されます。 - Config Management Operator の構成ファイルは、リポジトリに直接保存されず、同期されません。
- Namespace を除くクラスタ スコープ オブジェクトの構成ファイルは、リポジトリの
構成ファイルの内容
構成ファイルは、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 を作成します。
次のステップ
- クラスタスコープ オブジェクトの構成について詳しく学ぶ
- 名前空間スコープ オブジェクトの構成について詳しく学ぶ
- オブジェクトを管理対象または管理対象外にする方法を確認する。