Kubernetes オブジェクトの構成

このトピックでは、Anthos Config Management が Git から読み取り、クラスタに自動的に適用するファイルであるコンフィグの作成方法を示します。

始める前に

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

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

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

  • Anthos Config Management がどのように機能するのかを説明するために、標準的なサンプルリポが用意されています。このトピックの例はサンプルリポに基づいているため、サンプルリポをブラウザで開いておくか、ローカル システムにサンプルリポのクローンを作成することをおすすめします。

構成ファイルを作成する

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

リポジトリ内の場所

リポ内のコンフィグの場所は、そのコンフィグがどのクラスタに適用されるかを決定する要因の 1 つです。

  • 名前空間を除くクラスタ スコープ オブジェクトの構成ファイルは、リポジトリの cluster/ ディレクトリに保存されます。
  • 名前空間オブジェクトと名前空間スコープ オブジェクトの構成ファイルは、リポジトリの namespaces/ ディレクトリに保存されます。
  • Anthos Config Management のコンポーネントのコンフィグは、リポジトリの system/ ディレクトリに格納されています。
  • Config Management Operator のコンフィグは、リポジトリに直接保存されておらず、同期されません。

構成ファイルの内容

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

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

既存の Kubernetes オブジェクトの構成

Anthos Config Management をインストールする前からすでにクラスタに存在していた名前空間など、既存の Kubernetes オブジェクトのコンフィグを作成できます。ただし、オブジェクトにアノテーション configmanagement.gke.io/managed: enabled が付いていない限り、この構成ファイルは無視されます。既存のオブジェクトについては、このアノテーションを手動で適用する必要があります。

特に名前空間については、Config Sync はアノテーションが付いていない名前空間内に新しいオブジェクトを作成する構成ファイルを適用し、作成されたオブジェクトに configmanagement.gke.io/managed: enabled アノテーションを追加します。ただし、Anthos Config Management は、アノテーションが付けられていないクラスタ スコープ オブジェクトをクラスタから変更または削除することを拒否します。これは、運用中のコンフィグの操作の図で示されています。

CustomResourceDefinitions を構成する

Anthos Config Management では、他のリソースを同期する場合と同じ方法で CustomResourceDefinitions(CRD)を同期できます。CRD を同期するときに注意する点は、次のとおりです。

  • 名前空間付きのカスタム リソースを宣言する場合でも、CRD は cluster/ ディレクトリに配置する必要があります。

  • CRD とそれに対応する CustomResource の更新は、予測可能な順序では行われません。同じ commit で CRD とそれに対応する CustomResource を変更した場合、カスタム リソースが更新される前に CRD が更新されることはありません。これにより、CustomResource と CRD の両方がクラスタに存在するようになるまで、syncer ログで短い期間に一時的なエラーが報告されることがあります。

  • リポジトリの CustomResource が CRD に依存している場合、Anthos Config Management で CRD を削除できません。CRD を削除するには、その CustomResource も削除する必要があります。リポジトリへの同じ commit で両方を削除することをおすすめします。

  • CRD がすでにクラスタに存在していることを保証できれば、CRD と同期せずに CustomResource を同期できます。

構成ファイルの例

以下のコンフィグの例はすべてサンプルリポに基づいており、これらを出発点として独自のコンフィグを記述できます。このリストは網羅的なものではありません。Anthos Config Management ではどのようなタイプの Kubernetes オブジェクトでも構成できます。

名前空間コンフィグ

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

apiVersion: v1
kind: Namespace
metadata:
  name: audit

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

次の例では、shipping-prod という名前空間がまだ存在しない場合や管理されていない場合、構成ファイルでこの名前空間が作成されます。名前空間にはラベル env: prod とアノテーション audit: true があります。オブジェクトのメタデータが手動で変更された場合、Anthos Config Management によって、メタデータはすぐにコンフィグ内の値にリセットされます。

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

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

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@foo-corp.comnamespace-reader ClusterRole が付与されます。

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

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

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 はクラスタスコープであり、名前空間ディレクトリまたは抽象名前空間に配置することはできません。

NetworkPolicy コンフィグ

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

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

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

上記の NetworkPolicy を単一の名前空間に適用すると、その名前空間内のすべてのポッドが上り / 下りトラフィックから切り離されます。

下位の名前空間を持つ抽象名前空間に同じ NetworkPolicy を配置して複数の名前空間に適用すると、それぞれの名前空間にこの NetworkPolicy が継承されます。サンプル リポジトリでは、shipping-app-backend は抽象名前空間であり、shipping-devshipping-prodshipping-stage の構成ファイルが含まれています。上記の NetworkPolicy の例をこの抽象名前空間に追加すると、その設定が継承され、各 Namespace 内のそれぞれの Pod が上り / 下りトラフィックから保護されます。

名前空間の継承を使用して最小限の権限のセキュリティ原則を適用できます。たとえば、上記の NetworkPolicy の例が shipping-app-backend に適用され、次の NetworkPolicy が shipping-dev 名前空間に追加される場合、上りトラフィックは、その名前空間内の app:nginx ラベルが付けられた Pod にのみ許可されます。名前空間 shipping-prodshipping-staging は、この NetworkPolicy の影響を受けません。

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-nginx-ingress
spec:
  podSelector:
    matchLabels:
      app: nginx
  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 に違反しなくなるまで作成できません。

次のステップ