本番環境での Google Kubernetes Engine の準備

このソリューションは、安全性、信頼性、および費用対効果の高い方法でワークロードを Google Kubernetes Engine に展開するためのブループリントと方法を提供します。クラスタへの管理アクセスおよびネットワーク アクセスを構成するためのガイダンスを提供します。この記事では、Kubernetes リソースとクラスタ管理について実践的に理解し、Google Cloud ネットワーク機能に精通していることを前提としています。

プロジェクト、Virtual Private Cloud(VPC)ネットワーク、クラスタの構造化

次の図は、プロジェクト、VPC ネットワーク、リージョン、サブネット、ゾーン、クラスタに対して柔軟性があり、高可用性の構造の例を示しています。

プロジェクト、ネットワーク、クラスタ構造

プロジェクト

Google Cloud はプロジェクト エンティティ内にそのすべてのリソースを作成します。プロジェクトは課金の単位です。これにより、管理者は Identity and Access Management(IAM)のロールをユーザーに関連付けることができます。プロジェクト レベルでロールが適用されると、プロジェクト内にカプセル化されたすべてのリソースに、そのロールが適用されます。

さまざまなオペレーティング環境のカプセル化にはプロジェクトを使用する必要があります。たとえば、オペレーション チーム向けに production および staging プロジェクトを設定し、デベロッパー向けには test-dev プロジェクトを設定する場合などです。最もミッション クリティカルで機密性の高いデータとワークロードを保持するプロジェクトには、より詳細で厳格なポリシーを適用する一方、test-dev 環境のデベロッパーには、実験のための制限が緩やかで柔軟なポリシーを適用できます。

クラスタ

1 つのプロジェクトに複数のクラスタが存在する場合があります。複数のワークロードをデプロイする場合、それらのワークロードに単一の共有クラスタ、または個別のクラスタのいずれを使用するかを選択できます。決定する際に、GKE クラスタのサイズとスコープの選択に記載されているベスト プラクティスを検討してください。

ネットワークとサブネット

各プロジェクト内では、1 つ以上の VPC ネットワークを使用できます。VPC ネットワークは、物理ネットワークの仮想バージョンです。各 VPC ネットワークは、ネットワーク関連の他のリソース(サブネット、外部 IP アドレス、ファイアウォール ルール、ルート、VPN、Cloud Router など)が含まれるグローバル リソースです。VPC ネットワーク内では、リージョン リソースであるサブネットを使用して、GKE クラスタ間の各リージョン内外へのトラフィックを分離して制御できます。

各プロジェクトには、1 つのデフォルト ネットワークが付属しています。追加のネットワークを作成して、既存の IP アドレス管理(IPAM)規則にマップするように構成できます。そのネットワークにファイアウォール ルールを適用することで、GKE ノードに出入りするトラフィックをフィルタできます。デフォルトでは、GKE ノードへのすべてのインターネット トラフィックが拒否されます。

サブネット間の通信を制御するには、サブネット間でのトラフィックの受け渡しを許可するファイアウォール ルールを作成する必要があります。ファイアウォール ルールを有効にするには、クラスタまたはノードプールの作成時に --tags フラグを使用して、GKE ノードに適切なタグを付けます。必要に応じて、タグを使用してサブネット間のルートを作成することもできます。

マルチゾーン クラスタとリージョン クラスタ

デフォルトでは、クラスタは作成時に指定された単一のゾーン内にクラスタ マスターとノードを作成します。マルチゾーン クラスタまたはリージョン クラスタを作成することにより、クラスタの可用性と復元力を向上させることができます。マルチゾーン クラスタとリージョン クラスタは、リージョン内の複数のゾーンに Kubernetes リソースを分散させます。

マルチゾーン クラスタ:

  • 1 つのゾーンに単一のクラスタ マスターを作成します。
  • 複数のゾーンにノードを作成します。

リージョン クラスタ:

  • 3 つのゾーンに 3 つのクラスタ マスターを作成します。
  • デフォルトでは 3 つのゾーンにノードを作成しますが、必要に応じて、必要な数のゾーンにノードを作成できます。

リージョン クラスタとマルチゾーン クラスタの主な違いは、リージョン クラスタは 3 つのクラスタ マスターを作成する一方、マルチゾーン クラスタが作成するクラスタ マスターは 1 つだけであるという点です。いずれの場合も、複数のゾーンにまたがるノード間トラフィックに対しては料金が発生します。

クラスタの作成時に、マルチゾーン クラスタまたはリージョン クラスタを作成することを選択できます。マルチゾーン クラスタを作成するには、既存のクラスタに新しいノードを追加します。一方、既存のクラスタをリージョン クラスタに変更することはできません。リージョン クラスタを非リージョン クラスタに変更することもできません。

GKE マネージド クラスタ内のノードのサービス可用性は、Compute Engine サービスレベル契約(SLA)の適用を受けます。さらに、GKE の SLA により、ゾーンクラスタの場合は Kubernetes クラスタ マスターの月間稼働率 99.5% が、リージョン クラスタの場合は月間稼働率 99.95% が保証されます。

2020 年 6 月 6 日現在、GKE ではクラスタごとに 1 時間あたり $0.10 のクラスタ管理料金が発生します。詳細については、料金体系のページをご覧ください。

マルチゾーン クラスタとリージョン クラスタについて詳しくは、GKE のドキュメントをご覧ください。

マスター承認済みのネットワーク

クラスタで適用できる追加のセキュリティ対策として、マスター承認済みネットワークを有効にする方法があります。この機能により、指定した CIDR 範囲から API サーバーへのアクセスがロックされ、ネットワーク内のチームのみがクラスタを管理できるようになります。

この機能を有効にする場合は、次の点に注意してください。

  • 指定できる CIDR 範囲は 50 個までです。
  • CI / CD パイプラインを使用している場合は、CI / CD ツールが IP アドレスまたは CIDR 範囲を許可(ホワイトリストに登録)して、クラスタの API サーバーにアクセスできることを確認する必要があります。

また、この機能を Cloud Interconnect または Cloud VPN と組み合わせて、プライベート データセンター内からマスターノードのみへのアクセスを有効にすることも可能です。

限定公開クラスタ

デフォルトでは、GKE クラスタ内のすべてのノードにパブリック IP アドレスが割り振られます。すべてのワーカーノードにプライベート RFC 1918 の IP アドレスのみを付与する限定公開クラスタの作成をおすすめします。限定公開クラスタはネットワーク分離を適用するので、クラスタのリスクを軽減できます。限定公開クラスタを使用すると、デフォルトでは、ネットワーク内のクライアントのみがクラスタ内のサービスにアクセスできます。外部サービスがクラスタ内のサービスに到達できるように、HTTP(S) ロードバランサまたはネットワーク ロードバランサを使用できます。

VPC ネットワークの外部にあるマスターノードへのアクセスを開通する場合は、マスター承認済みのネットワークで限定公開クラスタを使用します。マスター承認済みネットワークを有効にすると、クラスタ マスター エンドポイントは内部(プライベート)アドレスとパブリック アドレスの 2 つの IP アドレスを取得します。内部 IP アドレスは、同じリージョン内にある自身のネットワークへのすべての内部通信で使用されます。マスターのパブリック IP アドレスは、ネットワークの外部にあり、許可された CIDR 範囲または IP アドレスからのすべてのユーザーまたはプロセスで使用されます。プライベート ノードには外部 IP アドレスがないため、デフォルトでは、外部のインターネットにはアクセスはできません。これはまた、クラスタのコンテナ ランタイムには下り(外向き)接続が必要になるため、デフォルトでは、クラスタのコンテナ ランタイムは外部コンテナ レジストリからコンテナ イメージを pull できないことを示しています。Container Registry でコンテナ イメージをホストし、限定公開の Google アクセスを使用してこれらのイメージにアクセスすることを検討してください。または、Cloud NAT を使用するか、NAT ゲートウェイをデプロイすることで、プライベート ノードによる外向きのアクセスを可能にします。

また、VPC Service Controls を使用すると、データ漏洩のリスクを軽減できます。VPC Service Controls を使用すると、1 つ以上のプロジェクトでマネージド Google Cloud サービスを保護し、これらのサービスにアクセスするためのサービス境界を定義できます。これらのマネージド サービスに到達するためのアクセス権を GKE クラスタで実行するアプリケーションに付与するには、適切なアクセスレベルを設定します。また、VPC Service Controls を使用して GKE クラスタ作成コントロール プレーンを保護できます。

ID とアクセスの管理

プロジェクト レベルのアクセス

前のセクションで、プロジェクト レベルで IAM のロールをユーザーにバインドできることを説明しました。個々のユーザーにロールを付与するだけでなく、グループを使用して簡単にロールを適用することもできます。

次の IAM ポリシー レイアウトの図は、デベロッパーが今後リリースされる機能とバグ修正の開発とテストを行うために設定された dev プロジェクトと、本番環境のトラフィック用の prod プロジェクトのための、最小限の権限の原則を示しています。

ID とアクセスの管理。

次の表に示すように、組織内には、2 つのプロジェクト全体で IAM のロールを通じて許可された、さまざまなレベルの権限を持つ 4 つのユーザーのグループがあります。

チーム IAM の役割 プロジェクト 権限
デベロッパー container.developer dev プロジェクト内に、既存のクラスタ用の Kubernetes リソースを作成することはできますが、クラスタを作成または削除することはできません。
運用 container.admin prod プロジェクト内で実行されているクラスタおよび Kubernetes リソースへの完全な管理アクセス。
セキュリティ container.viewer
security.admin
prod ファイアウォール ルールと SSL 証明書の作成、変更、削除、ならびに実行中の Pod のログを含む各クラスタ内で作成されたリソースの表示。
ネットワーク network.admin prod ネットワーク リソース(ファイアウォール ルールと SSL 証明書を除く)の作成、変更、削除。

prod プロジェクトに対するアクセス権を持つ 3 チームに加えて、追加のサービス アカウントprod に対する container.developer のロールを付与すると、クラスタ内でリソースを作成、一覧表示、削除できるようになります。サービス アカウントを使用すると、自動化スクリプトやデプロイ フレームワークに、自動的に処理する機能を与えることができます。本番環境プロジェクトとクラスタへのデプロイは、自動化されたパイプラインで進められるはずです。

dev プロジェクトには、同じクラスタ内の同じアプリケーションを操作する複数のデベロッパーがいます。これは、クラスタ ユーザーが作成できる名前空間によって容易になります。各開発者は、独自の名前空間内にリソースを作成できるため、名前の競合が避けられます。また、同じ YAML 構成ファイルをデプロイに再利用できるので、開発の繰り返し時に可能な限り同じ構成が維持されます。名前空間を使用して、クラスタ内の CPU、メモリ、ストレージの割り当てを作成し、1 人の開発者がクラスタ内のリソースを使用しすぎないようにすることもできます。次のセクションでは、特定の名前空間内でオペレーションするようにユーザーを制限する方法について説明します。

ロールベースのアクセス制御(RBAC)

Kubernetes 1.6 以降を実行している GKE クラスタでは、個々のクラスタでユーザーに実行を許可する機能に関してさらに制限を加えることができます。IAM によって、ユーザーはクラスタとその中のすべてのリソースにアクセスできるようになりますが、Kubernetes ロールベースのアクセス制御(RBAC)により、Kubernetes API を使用して、ユーザーがクラスタ内で行えるアクションをさらに制限することが可能になります。

RBAC により、クラスタ管理者は、クラスタ内の個々の名前空間またはクラスタ全体に詳細なポリシーを適用します。Kubernetes kubectl ツールは、gcloud ツールからのアクティブな認証情報を使用するため、クラスタ管理者はロールを Google Cloud Identity(ユーザー、サービス アカウント、Google グループ)に RoleBinding の subjects としてマッピングできます。

GKE 向け Google グループ(ベータ版)を使用すると、Kubernetes RBAC で Google グループを使用できます。この機能を使用するには、Google Workspace の Google グループを構成し、この機能を有効にしたクラスタを作成する必要があります。また、RoleBinding を使用してグループとロールを関連付ける必要があります。詳細については、ロールベースのアクセス制御をご覧ください。

次の図の例では、user-auser-b という 2 人のユーザーには、app-a 名前空間上で config-reader ロールと pod-reader ロールが割り当てられています。

RBAC 認証。

別の例として、特定のユーザーにプロジェクト内のすべてのクラスタへのアクセス権を付与する Google Cloud プロジェクト レベルの IAM のロールがあります。さらに、特定のクラスタや名前空間内のリソースに対する粒度の細かいアクセス権を付与する RBAC によって、個々の名前空間およびクラスタレベルのロール バインディングが追加されます。

IAM RoleBindings。

Kubernetes にはデフォルトのロールがいくつか含まれていますが、クラスタ管理者は組織のニーズにより密接に対応する独自のロールを作成できます。次の例のロールの場合、delete 動詞が含まれていないため、ユーザーが行えるのは ConfigMaps の表示、編集、更新に限られ、削除はできません。

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: config-editor
rules:
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["get", "list", "watch", "create", "update", "patch"]

ロールを定義したら、バインディングによって、クラスタまたは名前空間にこれらのロールを適用できます。バインディングは、ロールをユーザー、グループ、またはサービス アカウントに関連付けます。次の例は、以前に作成したロール(config-editor)を、bob@example.org ユーザーと development 名前空間にバインドする方法を示しています。

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: config-editors
  namespace: development
subjects:
- kind: User
  name: bob@example.org
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: config-editor
  apiGroup: rbac.authorization.k8s.io

RBAC の詳細については、GKE のドキュメントをご覧ください。

イメージのアクセスと共有

Container Registry または Artifact Registry(ベータ版)のイメージは、Cloud Storage に保存されます。このセクションでは、イメージを共有する 2 つの方法について説明します。1 つはイメージを公開すること、もう 1 つはプロジェクト間でイメージを共有することです。

Container Registry 内のイメージを公開する

イメージを保持するオブジェクトとバケットを公開することによって、イメージを公開できます。詳細な手順については、Container Registry のアクセス制御のドキュメントを参照してください。

Container Registry 内のプロジェクト間でイメージを共有する

Kubernetes ノードにサービス アカウントを使用させることで、プロジェクト間でコンテナ イメージを共有できます。プロジェクトに関連付けられるデフォルトのサービス アカウントの形式は、次のとおりです。

project-id-compute@developer.gserviceaccount.com

この識別子を用意したら、Container Registry を使用するプロジェクトに対し、storage.viewer としてアクセス権を付与できます。デフォルトのサービス アカウントにはプロジェクト全体に対する編集権限があるため、権限を制限したカスタム サービス アカウントを使用します。

クラスタに別のサービス アカウントを使用するには、クラスタまたはノードプールの作成時に --service-account フラグを使用してサービス アカウントを指定します。たとえば、プロジェクト my-projectgke-sa サービス アカウントを使用するには、次のように指定します。

gcloud container clusters create west --service-account \
    gke-sa@my-project.google.com.iam.gserviceaccount.com

Container Registry から Artifact Registry へのコンテナ イメージの移行については、Container Registry からの移行をご覧ください。

適切なイメージ pull ポリシーを決定する

imagePullPolicy プロパティは、Pod の起動時にイメージを Kubelet で pull するかどうかを指定します。コンテナ イメージに指定する適切な imagePullPolicy 設定を検討する必要があります。たとえば、次のイメージ pull ポリシーを指定できます。

imagePullPolicy: IfNotPresent

この場合、ノードのキャッシュでイメージを使用できない場合にのみ、Kubelet でイメージのコピーを取得します。

指定できるイメージ pull ポリシーの詳細については、Kubernetes のドキュメントのコンテナ イメージをご覧ください。

ダイナミック アドミッション Webhook を使用してポリシーを適用する

ダイナミック アドミッション Webhook は、Kubernetes コントロール プレーンの一部です。API サーバーに対して行われた受信リクエストをインターセプトできます。アドミッション Webhook は、GKE クラスタに企業固有のカスタム ポリシーを適用できる強力なツールです。

Kubernetes は、変更用アドミッション Webhook と検証用アドミッション Webhook という 2 種類のアドミッション Webhook をサポートしています。

変更用アドミッション Webhook は、アドミッション リクエストをインターセプトし、リクエストを変更できます。リクエストはその後、API サーバーに渡されます。

検証用アドミッション Webhook は、リクエストを調べて、指定したルールに従って有効かどうかを判断します。クラスタに検証用 Webhook が構成されている場合、リクエストが API サーバーによって検証された後、Webhook が起動されます。検証用アドミッション Webhook は、Webhook で定義されているポリシーを遵守していることを保証するためにリクエストを拒否できます。

たとえば、変更用アドミッション Webhook を使用して、イメージ pull ポリシーを適用すると、Pod 作成リクエストを送信したデベロッパーによって指定された imagePullPolicy 設定に関係なく、ポリシーが Always に設定されることを保証できます。

イメージのデプロイに関するその他の考慮事項

Container Registry などの専用のコンテナ レジストリを使用して、組織用に選択されたイメージのセットを保持することをおすすめします。これにより、デプロイ パイプライン(最終的にはアプリケーション ワークロード)に脆弱性が生じるリスクを軽減できます。可能であれば、セキュリティ リスクをさらに軽減するため、脆弱性スキャンなどのコンテナ分析も有効にする必要があります。

公開イメージを使用する必要がある場合は、クラスタへのデプロイを許可する公開イメージのセットの検証を検討してください(詳細については、Binary Authorization をご覧ください)。また、Google Cloud マーケットプレイスからパッケージ化された Kubernetes アプリをデプロイすることも検討できます。Google Cloud マーケットプレイスにある Kubernetes アプリには、脆弱性スキャンやメンテナンスおよびサポートに関するパートナー契約など、Google によるテストと調査が実施されています。

また、適切なイメージのバージョニング方法(適切なタグ付け規則を使用)を使用し、適用する場合はタグの代わりにダイジェストの使用を検討してください。

Workload Identity を使用して Google Cloud サービス API を操作する

多くの場合、企業のアーキテクチャには、クラウド サービス(クラウド マネージド サービスおよびホスト型サービス)にまたがるアーキテクチャ コンポーネントが含まれています。GKE アプリケーションまたはサービスが、Cloud Storage や BigQuery などの Google Cloud マネージド サービスと通信する必要がある場合の一般的なパターンです。一例として、GKE でバッチジョブによって処理されたお客様の記録を、あとで分析するために BigQuery に保存する必要がある場合です。

Workload Identity は、サービス アカウントの認証情報を Kubernetes Secret として保存する必要がなくても、GKE サービスと Google Cloud の幅広いエコシステムとのやり取りを可能にする GKE 機能です。この機能を使用すると、IAM バインディングを使用して Kubernetes サービス アカウントを Google Cloud サービス アカウントにマッピングできます。その後、Kubernetes サービス アカウントを使用して Pod が走行すると、Pod は Google Cloud サービスにアクセスするために必要な ID を引き継げます。これは、サービスに必要なアクセスレベルが、Google Cloud サービス アカウントに付与されていることを前提としています。

Workload Identity の詳細については、GKE のドキュメントをご覧ください。

クラスタ セキュリティを管理する

セキュリティは、GKE クラスタのエンタープライズ デプロイメントで非常に重要な分野で、多面的な対策が求められます。このセクションでは、クラスタのセキュリティを強化するために使用できるいくつかの要素について説明します。

イメージの脆弱性スキャン

Container Registry では、push されたイメージをスキャンし、Ubuntu、Alpine、Debian、CentOS、RedHat に基づいて、イメージの既知のセキュリティの脆弱性を探します。この機能を利用して、Kubernetes クラスタで使用する予定のイメージをスキャンすることをおすすめします。

イメージの脆弱性を表示するには、Google Cloud Console か、次の gcloud コマンドを実行します。

gcloud beta container images describe \
    hostname/project-id/image-id:tag  \
    --show-package-vulnerability

次のように置き換えます。

  • hostname: 次のホスト名のロケーションのいずれか。
    • gcr.io は現在、米国でイメージをホストしています。
    • us.gcr.io は米国でイメージをホストしますが、その場所は、gcr.io によってホストされるイメージからは独立したストレージ バケットです。
    • eu.gcr.io は、欧州連合でイメージをホストします。
    • asia.gcr.io は、アジアでイメージをホストします。
  • project-id: イメージを含むプロジェクトの ID。
  • image-id: 脆弱性を表示するイメージの ID。
  • tag: 情報を取得するイメージのタグ。

Container Registry リポジトリが変更されたときに、通知の追跡と受信を自動的に行うことができます。たとえば、新しいイメージが作成されたときや、画像が削除されたときに通知を受信できます。アプリケーション リスナーが登録されている Pub/Sub トピックに Container Registry イベントがパブリッシュされるようにパイプラインを構築できます。さらに、これらのイベントを使用してビルドまたは自動デプロイをトリガーできます。詳細については、Container Registry のドキュメントをご覧ください。

Binary Authorization

Kubernetes を使用して、クラスタへのイメージのデプロイが有効であると判断することと、判断するタイミングを決定する必要があります。このタスクには、Binary Authorization を使用できます。これは、イメージに必要となるクラスタにデプロイ可能な署名(証明書)に適用するワークフローを定義できるようにする、デプロイ時のコンストラクトです。

ワークフローはポリシーの観点から定義されます。CI / CD パイプラインでコードとコンテナ イメージを移動すると、Binary Authorization は Binary Authorization ポリシーの定義に従って、各ステージで証明書を記録します。これらの証明書は、定義されたマイルストーンをイメージが正常に通過していることを証明します。

Binary Authorization は GKE Deployment API と統合されており、イメージのデプロイが、必要なすべての証明書を持つイメージの対象になります。失敗したデプロイ試行は自動的にログに記録され、クラスタ管理者が確認して監査できます。

Cloud Build を使用して GKE で Binary Authorization を実装する方法のチュートリアルについては、Cloud Build と GKE を使用した Binary Authorization の実装をご覧ください。

GKE Sandbox での gVisor による安全なアクセス

コンテナによりセキュリティとカーネルの間に分離層ができますが、攻撃者がホストのオペレーティング システム(OS)へのアクセス権を取得するような侵害が発生する可能性が残されています。コンテナとホスト OS 間のセキュリティ分離でより高い復元性を実現するには、別の分離レイヤを作成します。その 1 つの方法が GKE Sandbox の使用です。

GKE Sandbox は、Google がリリースしたオープンソースのコンテナ ランタイムである gVisor を使用します。内部的には、gVisor によりコンテナと対話する仮想カーネルが作成されます。このカーネルは、コンテナによるホストカーネルへの接続を抽象化します。また、コンテナが行うことができるファイルとネットワークのオペレーションの制御も行います。

GKE Sandbox は追加の分離レイヤを作成するため、メモリと CPU のオーバーヘッドが増える可能性があります。GKE Sandbox を使用する前に、どのワークロードにこのような高度なセキュリティが必要となるかについて検討してください。通常、外部イメージに基づくサービスが良い候補になります。

次の gcloud コマンドは、GKE Sandbox を有効にしてノードプールを作成する方法を示しています。

gcloud container node-pools create node-pool-name \
    --cluster=cluster \
    --image-type=cos_containerd \
    --sandbox type=gvisor \
    --enable-autoupgrade

次のように置き換えます。

  • node-pool-name: 作成するモードプールの名前。
  • cluster: ノードプールを追加するクラスタ。

GKE Sandbox を使用して、どのアプリケーション Pod が走行するかを指定するには、次の例のように gVisor を Pod の仕様に組み込みます。

apiVersion: v1
kind: Pod
metadata:
  name: sample-saas-app
  labels:
    app: saas-v1
spec:
  runtimeClassName: gvisor
  containers:
    - name: sample-node-app-v1
      image: [image]

GKE Sandbox の詳細については、Google Cloud ブログの GKE Sandbox: Pod に深層防御を適用するをご覧ください。アプリケーションが GKE Sandbox に適しているかどうかについては、GKE のドキュメントをご覧ください。

監査ロギング

Kubernetes 監査ロギングでは、Kubernetes API サーバーに対するすべての API リクエストが記録されます。このロギングは、アクセスと構成の異常値や異常なパターンを検出するのに役立ちます。確認とアラートの対象としては、次のようなものがあります。

  • デプロイを削除する場合。
  • 特権アクセスのあるコンテナに接続、または exec を使用してアクセスする場合。
  • ClusterRole オブジェクトを変更するか、クラスタのロールのためにロール バインディングを作成する場合。
  • kube-system 名前空間にサービス アカウントを作成する場合。

GKE は Kubernetes 監査ロギングを Cloud Logging と統合します。これらのログには、Cloud プロジェクトで走行するリソースのログと同じ方法でアクセスできます。Kubernetes API サーバーに対して行われた API リクエストはログに記録され、API アクティビティ パターンを確認できます。

Kubernetes API サーバーでキャプチャされた各リクエスト(イベント)は、定義した 1 つ以上のポリシーによって処理されます。たとえば、ログに記録するイベントを判断する Kubernetes 監査ポリシーや、管理アクティビティ ログまたはデータログに記録するイベントを判断する Google Kubernetes Engine 監査ポリシーによって処理されます。管理アクティビティ ログはデフォルトで有効になっています。クラスタ内で読み取りまたは書き込みが行われたメタデータの詳細をログに記録する場合は、データアクセス ロギングも有効にします。ただし、データアクセス ロギングを有効にすると、追加料金が発生する場合があります。詳細については、料金のドキュメントをご覧ください。

PodSecurityPolicies

よくある攻撃ベクトルは、Kubernetes クラスタへのアクセス権を取得するために、権限を昇格した Pod をデプロイする方法です。PodSecurityPolicies は、Pod に許可する操作を記述した一連のルールを Pod 仕様に定義します。PodSecurityPolicy は、アドミッション コントローラ リソースとして Kubernetes に実装します。これを使用して、名前空間の使用方法、ボリューム タイプの使用方法、基盤となる OS 機能に対するアクセスを制限できます。

PodSecurityPolicy を有効にした GKE クラスタを作成するには、次のコマンドを使用します。cluster-name は、PodSecurityPolicy を追加するクラスタの名前に置き換えます。

gcloud beta container clusters create cluster-name \
    --enable-pod-security-policy

次の例は、特権 Pod を作成する機能を制限する PodSecurityPollicy を示しています。

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: default-pod-security-policy
spec:
  privileged: false
  hostPID: false
  seLinux:
    rule: RunAsAny
  runAsUser:
    rule: MustRunAsNonRoot

コンテナのセキュリティに関する考慮事項

Kubernetes サービスの基本的な構成要素はコンテナです。クラスタのセキュリティとポリシーを計画する際には、コンテナのセキュリティが重要な要素になります。次の点を考慮してください。

  • コンテナを構築する元となるイメージ。
  • コンテナに割り当てる特権。
  • コンテナがホスト OS や他のサービスとやり取りする方法。
  • コンテナで機密情報にアクセスしてログに記録する方法。
  • クラスタ内のコンテナのライフサイクルを管理する方法。

詳細とベスト プラクティスについては、コンテナの構築操作に関するドキュメントをご覧ください。

ネットワークの構成

Kubernetes は、クラスタ内の Pod セット全体だけでなく、クラスタ外で走行している以前のシステムに対する負荷分散とサービス ディスカバリを含むサービスの抽象化を提供します。以下のセクションでは、Kubernetes Pod と他の Kubernetes クラスタを含む他のシステム間の通信のベスト プラクティスについて説明します。

VPC ネイティブ クラスタとルートベース クラスタの比較

GKE クラスタが Pod から別の Pod にトラフィックをルーティングする方法に基づいて、クラスタを 2 つのタイプに分類できます。1 つ目は、トラフィックのルーティングにエイリアス IP 範囲を使用するクラスタです。これは VPC ネイティブ クラスタと呼ばれています。2 つ目は、Google Cloud ルートを使用するクラスタです。これは、ルートベース クラスタと呼ばれています。

VPC ネイティブ クラスタでは、Pod ネットワークにエイリアス IP 範囲を使用します。つまり、GKE クラスタ内の各ノードの静的ルートを構成して管理する代わりに、コントロール プレーンで Pod のルーティング構成が自動的に管理されます。エイリアス IP 範囲を使用すると、個別のネットワーク インターフェースを定義せずに、VM にホストされているコンテナまたはアプリケーションを表す複数の内部 IP アドレスを構成できます。Google Cloud では、プライマリ ネットワーク インターフェースのプライマリ範囲とエイリアス IP 範囲の VPC ネットワーク ルートが自動的にインストールされます。これにより、Pod 間のトラフィック ルーティングが大幅に簡素化されます。

また、VPC ネイティブ クラスタはルート割り当の対象ではありません。クラスタ ファブリックのエイリアス IP 範囲を活用することで、Cloud Storage や BigQuery などの Google サービスに直接アクセスできます。この方法以外では、NAT ゲートウェイでのみアクセスできます。

これは、GKE クラスタで、アプリケーションとサービスのオンプレミス エコシステムと安全に通信するための一般的なパターンです。エイリアス IP 範囲では、Cloud VPN または Cloud Interconnect を介してエイリアス IP アドレスを検出できるため、これが許可されます。これにより、オンプレミス インフラストラクチャと Google Cloud インフラストラクチャの間の安全な接続を実現できます。

ネットワーク トポロジに最適なクラスタタイプを決定する必要があります。主な要素は、ネットワーク内の IP アドレスの可用性、企業内のクラスタ(ノード)拡張プラン、エコシステム内の他のアプリケーションとの接続です。VPC ネイティブのクラスタでは、ネットワークでより多くの IP アドレスが必要になる傾向があるため、その点を考慮する必要があります。作成後には、VPC ネイティブ クラスタをルートベースのクラスタに、ルートベースのクラスタを VPC ネイティブ クラスタに移行できないため、実装する前に自身の選択に関する影響を理解することが重要です。

同一クラスタ内の通信

サービス ディスカバリ

Kubernetes では、一連のラベルに基づいて、クラスタ内で実行されているポッドをグループ化するサービスを定義できます。DNS を使用して、この Pod のグループをクラスタ内で検出できます。Kubernetes でのサービス ディスカバリの詳細については、アプリケーションとサービスの接続のドキュメントをご覧ください。

DNS

クラスタローカルの DNS サーバー kube-dns が各 GKE クラスタにデプロイされ、サービス名と正常な Pod の IP とのマッピングを処理します。デフォルトで、Kubernetes DNS サーバーはサービスのクラスタ IP アドレスを返します。この IP アドレスは、サービスの存続期間を通じて静的です。この IP にトラフィックを送信すると、ノード上の iptables は、サービスのセレクタに一致する準備完了状態のポッド全体でパケットを負荷分散します。これらの iptables は、各ノードで実行する kube-proxy サービスによって自動的にプログラムされます。

サービス ディスカバリと稼働状況のモニタリングが必要な場合に、DNS サービスで仮想 IP アドレスではなく、Pod の IP アドレスが返されるようにするには、ClusterIP フィールドを「None」に設定して、サービスをプロビジョニングし、サービスをヘッドレスにします。この場合、DNS サーバーが返すのは、サービスで定義されたラベルセレクタに一致する準備完了状態の Pod の A レコードにサービスの DNS 名をマップする A レコードのリストです。レスポンス内のレコードがローテーションし、さまざまなポッド間への負荷の分散を容易にします。一部のクライアント側 DNS リゾルバは DNS レスポンスをキャッシュに保存するため、A レコードのローテーションが無効になることがあります。ClusterIP を使用する利点は、Kubernetes のドキュメントに示されています。

ヘッドレス サービスの典型的な使用例の 1 つは、StatefulSets です。StatefulSets は、レプリカ間の安定したストレージとネットワークを必要とするステートフルなアプリケーションを実行する場合に適しています。このタイプのデプロイでは、安定したネットワーク ID を持つポッドをプロビジョニングします。つまり、クラスタ内でホスト名を解決できます。ポッドの IP は変更される可能性がありますが、そのホスト名 DNS エントリは最新の状態に維持されて、解決可能になります。

パケットフロー: ClusterIP

次の図は、標準 Kubernetes サービスの DNS レスポンスとパケットフローを示しています。ポッド IP アドレスはクラスタ外からルーティング可能ですが、サービスのクラスタ IP はクラスタ内でのみアクセス可能です。これらの仮想 IP アドレスは、各 Kubernetes ノードで宛先ネットワーク アドレス変換(DNAT)を行うことによって実装されます。各ノードで実行されている kube-proxy サービスが、クラスタ IP アドレスをクラスタ全体の正常な Pod IP アドレスにマップする転送ルールを、各ノードで最新の状態に維持します。ローカルノードで実行中のサービスの Pod がある場合は、その Pod が使用されます。ない場合はクラスタ内の Pod がランダムに選択されます。

クラスタ IP サービス。

ClusterIP の実装方法の詳細については、Kubernetes のドキュメントをご覧ください。GKE のネットワーキングの詳細については、YouTube の Next 2017 の講演をご覧ください。

ヘッドレス サービス

以下は、ヘッドレス サービスの DNS レスポンスとトラフィック パターンの例です。Pod IP アドレスは、デフォルトの Google Cloud サブネット ルートテーブルによってルーティング可能であり、アプリケーションから直接アクセスされます。

ヘッドレス サービスの DNS レスポンスとトラフィック パターンの例。

ネットワーク ポリシー

GKE のネットワーク ポリシーの適用を使用すると、クラスタの Pod とサービス間の通信を制御できます。GKE でネットワーク ポリシーを定義するには、Kubernetes ネットワーク ポリシー API を使用して Pod レベルのファイアウォール ルールを作成します。これらのファイアウォール ルールは、クラスタ内でどの Pod とサービスが互いにアクセスできるかを決定します。

ネットワーク ポリシーは、クラスタで実行されているワークロードのセキュリティを強化する、一種の深層防御です。たとえば、アプリケーション内の不正使用されたフロントエンド サービスが数レベル下の課金サービスや会計サービスと直接通信できないようにするネットワーク ポリシーを作成できます。

ネットワーク ポリシーを使用して、異なるテナントに属するワークロードを分離することもできます。たとえば、テナント単位の名前空間モデルを定義して、セキュアなマルチテナンシーを提供できます。このようなモデルでは、ネットワーク ポリシー ルールにより、特定の名前空間内の Pod やサービスが異なる名前空間内の他の Pod やサービスにアクセスできないようにできます。

ネットワーク ポリシーの詳細については、GKE のドキュメントをご覧ください。

Google Cloud の内部から GKE クラスタに接続する

クラスタの外部(ただし Google Cloud ネットワークのプライベート IP アドレス空間内)からサービスに接続するには、内部負荷分散を使用します。Kubernetes 内でサービスを作成するときに type: Load Balancercloud.google.com/load-balancer-type: Internal アノテーションを指定すると、Google プロジェクト内に内部ネットワーク ロードバランサが作成され、TCP と UDP のトラフィックを Pod 間で分散するように構成されます。

クラスタ内から外部サービスへの接続

多くの場合、Kubernetes 内で実行しているアプリケーションを、クラスタの外部にあるサービス、データベース、アプリケーションと接続する必要があります。下記の 3 つのオプションがあります。

スタブドメイン

Kubernetes 1.6 以上では、特定のドメインの DNS クエリを外部 DNS サーバーに転送するようにクラスタ内部 DNS サービス(kube-dns)を構成できます。これは、Kubernetes Pod が使用する必要があるドメインについて、クエリを実行する優先 DNS サーバーがある場合に便利です。

外部ネームサービス

外部ネームサービスを使用すると、DNS レコードをクラスタ内のサービス名にマップできます。この場合、クラスタ内サービスの DNS ルックアップでは、選択した CNAME レコードが返されます。既存の DNS サービスにマップするレコードが少ない場合は、これを使用するとよいでしょう。

セレクタのないサービス

セレクタなしでサービスを作成し、エンドポイントをそれに手動で追加して、サービス検出に正しい値を設定できます。これにより、クラスタ内サービスに対して同じサービス検出メカニズムを使用して、DNS によるサービス検出がないシステムにも確実に到達できるようにします。このアプローチは最も柔軟性がありますが、長期的に最も構成とメンテナンスを必要とします。

DNS の詳細については、Kubernetes DNS の Pod と Service のドキュメント ページをご覧ください。

インターネット トラフィックを受信するように Kubernetes でサービスを構成する

Kubernetes サービスは、NodePort、ClusterIP、および LoadBalancer を使用して公開できます。

ただし、外部向けサービスが多数ある場合は、Kubernetes Ingress リソースの使用を検討してください。Ingress はクラスタ向けのエントリ ポイントを提供し、受信リクエストをクラスタ内の 1 つ以上のバックエンド サービスにルーティングするルーティング ルールの定義を可能にします。GKE では、GKE Ingress コントローラによって Ingress リソースが Google Cloud HTTP(S) ロードバランサとして実装され、Ingress リソースとその関連サービスの情報に従って構成されます。

Kubernetes Ingress リソースは、アプリケーションが HTTP(S) 経由でトラフィックを提供する場合にのみ使用できます。バックエンド サービスが TCP または UDP プロトコルを使用している場合は、代わりにネットワーク ロードバランサを使用する必要があります。これは、データベースをサービスとして公開する必要がある場合などに、必要になることがあります。

バックエンドの構成

BackendConfig は、Kubernetes Ingress コントローラで使用される追加の指示を与える構成を提供できるカスタム リソース定義です。Ingress オブジェクトを GKE クラスタにデプロイすると、Kubernetes Ingress コントローラによって、Ingress マニフェストで指定したバックエンド サービスに、受信リクエストをルーティングする HTTP(S) ロードバランサが構成されます。

ロードバランサの構成は、次のような仕様で補完できます。

  • Cloud CDN でキャッシュを有効にする。
  • Google Cloud Armor で IP アドレスまたは CIDR 許可リスト(ホワイトリスト)を追加する。
  • Identity-Aware Proxy(IAP)でアプリケーション レベルのアクセス制御を行う。
  • クラスタ内の Ingress オブジェクトによって管理されるサービスのサービス タイムアウトとコネクション ドレインのタイムアウトを構成する。

GKE で BackendConfig カスタム リソースを構成する方法の詳細については、GKE のドキュメントをご覧ください。

サービス メッシュの使用

サービス メッシュを使用すると、Kubernetes クラスタで走行しているマイクロサービスの接続、保護、管理を統一された方法で行うことができます。たとえば、GKE アドオンとして追加できる Istio サービス メッシュを使用すると、サービス間認証と通信の管理、アクセス ポリシーの適用、GKE クラスタの監査と管理に使用できるリッチなテレメトリー データポイント収集を行うことができます。

サービス メッシュの主な特徴は、次のとおりです。

  • トラフィック管理。サービス メッシュでは、トラフィックをサービス間、または同じサービスの異なるバージョン間で、ルーティングする方法や、分割する方法を決定する、詳細なルールを定義できます。これにより、カナリア デプロイと Blue/Green デプロイのロールアウトが容易になります。

  • 組み込みのオブザーバビリティ。メッシュは、サービスをインストルメント化するためにコードを記述する必要がなくても、ネットワーク トラフィック(レイヤ 4 とレイヤ 7)の指標を統一された方法で記録します。

  • セキュリティ。メッシュにより、サービス間の相互 TLS(mTLS)が有効になります。転送中のデータのための安全なチャネルが提供されるだけでなく、メッシュ内のサービスの認証と認可も管理できます。

まとめると、Istio などのサービス メッシュを使用すると、システムレベルのタスクをメッシュ インフラストラクチャに委任できます。これにより、Kubernetes クラスタで走行しているサービスの全体的なアジリティ、堅牢性、疎結合が改善されます。

詳細については、Google Kubernetes Engine 上の Istio をご覧ください。

ファイアウォール

GKE ノードは Compute Engine にインスタンスとしてプロビジョニングされます。そのため、他のインスタンスと同じステートフルなファイアウォール メカニズムに従います。これらのファイアウォール ルールはタグを使用して、ネットワーク内でインスタンスに適用されます。各ノードプールは、ルールで使用できる独自のタグセットを受け取ります。デフォルトでは、ノードプールに属する各インスタンスは、このノードプールが属する特定の Kubernetes Engine クラスタを識別するタグを受け取ります。このタグは、Kubernetes Engine が自動的に作成するファイアウォール ルールで使用されます。クラスタまたはノードプールの作成時に、gcloud command-line tool ツールで --tags フラグを使用して、独自のカスタムタグを追加できます。

たとえば、内部ロードバランサがすべてのノードのポート 8080 にアクセスできるようにするには、次のコマンドを使用します。

gcloud compute firewall-rules create allow-8080-fwr \
    --target-tags allow-8080 \
    --allow tcp:8080 \
    --network gke \
    --source-range 130.211.0.0/22
gcloud container clusters create my-cluster --tags allow-8080

次の例では、あるクラスタにタグを付けてインターネット トラフィックがポート 30000 上のノードにアクセスできるようにする一方、他のクラスタには VPN からポート 40000 へのトラフィックを許可するタグを付けています。これは、VPN などの特権ネットワークを使用してのみ、会社のデータセンターにアクセスできるようにするか、プロジェクト内の別のクラスタからアクセスできるようにする必要のあるサービスを NodePort によって公開する場合に便利です。

2 つのクラスタに異なるタグを付ける。

オンプレミスのデータセンターへの接続

オンプレミスのデータセンターへの接続には、いくつかの Cloud Interconnect オプションを使用できます。これらのオプションは相互に排他的ではないため、ワークロードと要件に基づいて組み合わせることができます。

  1. データ集約型でなくレイテンシの影響も小さいワークロード用のインターネット。Google は世界各地のサービス プロバイダに接続する 100 を超える PoP(接続拠点)を提供しています。
  2. 専用の帯域幅を必要とし、レイテンシによる影響を受けやすく、Google Cloud プロダクトのフルパッケージを含むすべての Google サービスにアクセスする必要があるダイレクト ピアリング。ダイレクト ピアリングは BGP ルートの交換によって行われるレイヤ 3 接続であるため、登録済みの ASN が必要です。
  3. キャリア ピアリングは、サービス プロバイダを通じて行われることを除けば、ダイレクト ピアリングと同じです。登録済みの ASN がない場合や、優先サービス プロバイダとの関係がすでに存在する場合に適したオプションです。
  4. Cloud VPN は、IPsec 暗号化が必要な場合、またはプライベート ネットワークをプライベート Compute Engine ネットワークに拡張する場合に、レイヤ 3 相互接続とインターネット オプション(1、2、3)で構成します。

クラスタの操作性の管理

このセクションでは、GKE クラスタの管理や運用を行う際に考慮すべき重要な要素について説明します。

リソースの割り当て

Kubernetes リソースの割り当ては、クラスタ内の各 Namespace で許容されるリソース使用量の合計を制限する制約を提供します。ビジネス機能または開発ステージを分離する Kubernetes Namespace を持つクラスタがある場合、割り当てを使用して、CPU 使用率、メモリ、名前空間内に作成できる Pod とサービスの数など、リソースの広い配列を制限できます。GKE クラスタのコントロール プレーンの安定性を確保するため、5 ノード以下の GKE クラスタ内の各 Namespace に、オーバーライドできないデフォルトのリソース割り当てが自動的に適用されます。

リソースの上限

Kubernetes の LimitRange オブジェクトを使用すると、コンテナと Pod を作成できる最小リソースまたは最大リソースの境界にきめ細かい制約を適用できます。次の例は、LimitRange の使用方法を示しています。

apiVersion: v1
kind: LimitRange
metadata:
  name: sample-limits
spec:
  limits:
    - max:
        cpu: "400m"
        memory: "1Gi"
      defaultRequest:
        cpu: "200m"
        memory: "500Mi"
      type: Container

Pod 停止予算

Pod 停止予算(PDB)を使用すると、チームによる Pod やデプロイの自発的な削除や、偶発的な削除を防ぐことができます。PDB は、ノードの停止や再起動が原因の意図しない中断を防ぐことはできません。通常、オペレーターはアプリケーションのために走行する Pod の最低数を定義するアプリケーション用の PDB を作成します。

複数のアプリケーションが動作している企業ではミスが起こり、デベロッパーまたは管理者が、Pod やデプロイを削除する、つまり、Kubernetes リソースを削除するスクリプトを誤って実行する可能性があります。しかし、PDB を定義することで、Kubernetes アプリケーションに最小限の必要なリソースセットを常時維持できるようになります。

GKE クラスタに構成する PDB は、GKE のアップグレード中に適用されます。つまり、アップグレード中もアプリケーションの可用性を制御できます。次の例は、PDB の構成方法を示しています。

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: nginx-pdb
  spec:
    minAvailable: 4
    selector:
      matchLabels:
        app: nginx

Kubernetes のアップグレードの管理

GKE 上の Kubernetes クラスタは、要件を満たす Kubernetes の最新バージョンにしておく必要があります。これにより、ロールアウトされる新機能を利用できます。また、クラスタノードの基盤となるオペレーティング システムにパッチが適用され、最新の状態が維持されます。

アップグレードが必要な場合は、次のタイプを検討できます。

  • マスターノードとワーカーノード用の GKE クラスタのメジャーとマイナーの Kubernetes バージョン アップグレード。
  • クラスタを構成する仮想マシン(ノード)の OS のパッチとアップグレード。

Kubernetes のバージョンのアップグレード

GKE マスターノードをアップグレードする方法は 2 つあります。1 つ目は、GKE クラスタ マスターのアップグレードを自動的に行うように Google Cloud を構成する方法です。2 つ目は、新しいバージョンが利用可能になったときに手動アップグレードを開始する方法です。

アップグレードが利用可能になると、GKE クラスタに表示されるコンソールで通知を確認できます。リリース コンテンツを確認し、アップグレードするバージョンで走行しているサンドボックス化されたクラスタでアプリケーションをテストしてから、バージョンのアップグレードをトリガーすることをおすすめします。

ゾーンクラスタのマスターノードでは、アップグレードの進行中に、コントロール プレーンは使用できません。つまり、API サーバーとやり取りして、クラスタ内のリソースを追加または削除することはできません。ゾーンクラスタ内でのマスターノードのアップグレードによるダウンタイムが許容できない場合は、代わりにリージョン GKE クラスタをデプロイすることで、マスターノードを高可用性にすることが可能です。この方法により、ゾーン全体に分散する複数のマスターノード持つことができます。一方のマスターノードがアップグレードされると、API サーバーへのコントロール プレーン リクエストはどれも、もう一方のマスターノードにルーティングされます。

マスターノードの場合と同様に、GKE ワーカーノードをクラスタのマスターノードと同じバージョンにアップグレードするには 2 つの方法があります。

  • GKE に、ワーカーノードのアップグレードを管理させます。これを行うには、GKE クラスタ内のノードプールのノードの自動アップグレードを有効にします。
  • GKE ワーカーノードは手動でアップグレードできます。アップグレードが利用可能な場合、GKE コンソールにアラートが表示されます。このアラートが表示されたら、GKE ワーカーノードにアップグレードを適用できます。

いずれの場合も、アップグレードが適用されると、GKE はワーカーノードにローリング アップデートを適用します。新しい置換ノードが受信リクエストへの応答に使用可能になると、ローリング アップグレードはノードを系統的にドレインして停止させ、1 回に 1 つのノードをアップグレードします。

ノードの自動修復

GKE ノードの自動修復機能では、GKE ノードのヘルスチェックを管理します。いずれかのノードで異常が見つかった場合、GKE でノードの修復プロセスが開始されます。

マネージド ノードの修復プロセスでは、ノードのドレインと再作成が行われます。GKE クラスタ内の複数のノードを同時に修復する必要がある場合、Google Cloud は並行して修復可能なノード数を内部的に決定します。

Google Cloud Console でクラスタを作成する場合、自動修復機能は自動的に有効になります。gcloud command-line tool ツールを使用して作成した GKE クラスタの場合は、クラスタの作成コマンドに --enable-autorepair フラグを含めることで、明示的に自動修復を有効にできます。

GKE クラスタに複数のノードプールがある場合は、自動修復機能を使用すると、ノードの自動修復を有効にするノードプールをきめ細かく制御できます。

GKE クラスタの自動スケーリング

企業は多くの場合、Kubernetes クラスタで走行しているアプリケーション上で、変化する受信読み込みを経験します。これらのビジネス主導の変化に対応するために、GKE クラスタで自動的に対応を行い、指標に基づいてスケールアップとスケールダウンを行うことができます。

次のセクションで説明するように、自動スケーリングには、複数の特徴があります。

クラスタ オートスケーラー

GKE クラスタ オートスケーラーは、ワークロードの需要に応じて、クラスタのノードを自動的に追加または削除します。クラスタ オートスケーラーは、個々のノードプールに対して有効になっています。GKE は、各ノードプールで容量不足のためにスケジューリング待ちになっている Pod があるかどうか確認します。このような Pod がある場合、クラスタ オートスケーラーはノードプールにノードを追加します。

要因の組み合わせは、GKE によるスケールダウンがどのように決定されるかに影響します。ノードで走行している Pod によるノードの使用率が 50% 未満で、走行中の Pod が容量のある他のノードでスケジュールされる場合、使用率の低いノードはドレインされ、終了します。

クラスタ オートスケーラーでスケーリングできる最小と最大ノードのノード数を指定することにより、ノードプールの境界を設定できます。

水平 Pod 自動スケーリング(HPA)

Kubernetes では、水平 Pod 自動オートスケーラー(HPA)を作成できます。これにより、Kubernetes の Deployment または ReplicaSet のスケーリング方法と、どの指標に基づきスケーリングを決定するかを構成できます。デフォルトでは、HPA コントローラは CPU 使用率に関する自動スケーリングの決定を基準としています。ただし、HPA コントローラは、HTTP リクエストの数など、カスタム指標に基づいて Pod をスケーリングする方法を計算できます。HPA がカスタム指標に応答するためには、通常、追加のモニタリング インストルメンテーションが必要です。

詳細については、KubernetesGKE のドキュメントをご覧ください。

垂直 Pod 自動スケーリング(VPA)

GKE クラスタの垂直 Pod 自動スケーリング(VPA)機能は、コンテナ用の最適な CPU とメモリ要求を特定するタスクから解放されます。必要であれば、VPA はクラスタ内のコンテナに対するリソースの割り当てを調整します。VPA は、ノードごとにコンテナレベルで最適化することにより、クラスタに対するリソースの利用を最適化します。また、VPA を使用することで、リソースの維持に必要だった管理の時間から解放されます。

VPA は、次のセクションで説明するノード自動プロビジョニング機能と連携して動作します。

Kubernetes の制限により、Pod のリソース リクエストを変更するには Pod の再起動が必要です。したがって、この変更を行うため、VPA は Pod を強制排除します。詳細については、GKEKubernetes のドキュメントをご覧ください。

ノードの自動プロビジョニング

ノード自動プロビジョニングを使用すると、GKE クラスタ オートスケーラーは、追加のノードプールが必要であると判断したときに、自動的に追加のノードプールをプロビジョニングできます。クラスタ オートスケーラーは、ノードプールにノードがなくなったときに、自動プロビジョニングされたノードプールを削除できます。

ノードの自動プロビジョニングの決定は、いくつかの要因に基づいて GKE クラスタ オートスケーラーによって行われます。この要因には、Pod によって要求されたリソースの量、指定した Pod アフィニティ、GKE クラスタで定義された node taints と tolerations が含まれます。

ノードの自動プロビジョニングは、GKE クラスタでさまざまなワークロードが実行される場合に役立ちます。たとえば、GKE クラスタに GPU を利用するワークロードがある場合、GPU 対応ノードでプロビジョニングされた専用のノードプールでこのワークロードを実行できます。ノードプールのスケーリング境界を定義するには、ノードプールの最小サイズと最大サイズを指定します。

ノード自動プロビジョニングの詳細と有効にする場合については、ノードの自動プロビジョニングの使用をご覧ください。

次のステップ

  • コンテナの構築操作のベスト プラクティスについて学習する。
  • このチュートリアルで、Istio を使用して Cloud Run on GKE でエンドユーザーの認証を行う方法について学習する。
  • Google Cloud のその他の機能を試す。チュートリアルをご覧ください。