Kubernetes オブジェクトの構成

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

始める前に

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

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

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

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

構成ファイルを作成する

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

リポジトリ内の場所

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

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

コンフィグの内容

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

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

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

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

特に名前空間については、Anthos Config Management はアノテーションが付いていない名前空間内に新しいオブジェクトを作成する構成ファイルを適用し、作成されたオブジェクトに 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 オブジェクトでも構成できます。

Namespace 構成ファイル

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

apiVersion: v1
kind: Namespace
metadata:
  name: audit

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

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

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.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 はクラスタスコープであり、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-devshipping-prodshipping-stage の構成ファイルが含まれています。上記の NetworkPolicy の例をこの抽象名前空間に追加すると、その設定が継承され、各名前空間内のそれぞれのポッドが上り / 下りトラフィックから保護されます。

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

次のステップ