Kubernetes オブジェクトの構成

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

始める前に

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

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

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

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

構成ファイルを作成する

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

リポジトリ内の場所

リポジトリ内の構成ファイルの場所は、その構成ファイルがどのクラスタに適用されるかを決定する要因の 1 つです。

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

構成ファイルの内容

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

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

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

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

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

CustomResourceDefinitions を構成する

Config Sync では、他のリソースの同期と同じ方法で CustomResourceDefinitions（CRD）を同期できます。CRD を同期するときに注意する点は、次のとおりです。

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

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

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

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

構成ファイルの例

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

Namespace コンフィグ

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

apiVersion: v1
kind: Namespace
metadata:
  name: audit

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

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

apiVersion: v1
kind: Namespace
metadata:
  name: shipping-prod
  labels:
    env: prod
  annotations:
    audit: "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@foo-corp.com に namespace-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 はクラスタスコープであり、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 が継承されます。サンプル リポジトリでは、shipping-app-backend は抽象名前空間であり、shipping-dev、shipping-prod、shipping-stage の構成ファイルが含まれています。上記の NetworkPolicy の例をこの抽象名前空間に追加すると、その設定が継承され、各名前空間内のそれぞれの Pod が上り（内向き） / 下り（外向き）トラフィックから保護されます。

Namespace の継承を使用して最小限の権限のセキュリティ原則を適用できます。たとえば、上記の NetworkPolicy の例が shipping-app-backend に適用され、次の NetworkPolicy が shipping-dev Namespace に追加される場合、上りトラフィックは、その Namespace 内の app:nginx ラベルが付けられた Pod にのみ許可されます。Namespace shipping-prod と shipping-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 に違反しなくなるまで作成できません。

次のステップ