本番環境での 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 環境のデベロッパーには、実験のための制限が緩やかで柔軟なポリシーを適用できます。

クラスタ

プロジェクトに、複数のクラスタを含めることがあります。複数のワークロードをデプロイする場合、それらのワークロードに単一の共有クラスタ、または個別のクラスタのいずれを使用するかを選択できます。決定する際の参考として、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 を使用すると、マネージド Google Cloud サービスへのアクセスに対するサービス境界を定義することにより、1 つ以上のプロジェクトでサービスを保護できます。適切なアクセスレベルを設定することで、GKE クラスタで実行されるアプリケーションに、これらのマネージド サービスへのアクセス権を付与できます。VPC Service Controls を使用して、GKE クラスタ作成コントロール プレーンを保護することもできます。

ID とアクセスの管理

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

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

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

Identity and Access Management

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

チーム IAM の役割 プロジェクト 権限
開発 container.developer dev プロジェクト内に、既存のクラスタ用の Kubernetes リソースを作成することはできますが、クラスタを作成または削除することはできません。
運用 container.admin prod プロジェクト内で実行されているクラスタおよび Kubernetes リソースへの完全な管理アクセス。
セキュリティ container.viewer
security.admin
prod ファイアウォール ルールと SSL 証明書の作成、変更、削除、ならびに実行中のポッドのログを含む各クラスタ内で作成されたリソースの表示。
ネットワーク 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 グループを使用できます。この機能を使用するには、G Suite Google グループを構成して、有効にしたその機能でクラスタを作成し、RoleBinding を使用して Google グループをバインドするロールに関連付ける必要があります。詳細については、ロールベースのアクセス制御をご覧ください。

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

RBAC 認証

もう 1 つの例としては、特定のユーザーにプロジェクト内のすべてのクラスタへのアクセス権を付与する 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

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

クラスタに別のサービス アカウントを使用するには、クラスタまたはノードプールの作成時に --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 は、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 リポジトリに変更が加えられた場合、通知の追跡と受信の自動化は、組織にとってメリットになります。たとえば、新しいイメージが作成されたときや、イメージが削除されたときに通知を受けられます。Container Registry イベントがパブリッシュされる Pub/Sub トピックに、アプリケーション リスナーをサブスクライブするパイプラインをビルドできます。その後、これらのイベントを使用して、ビルドまたは自動デプロイをトリガーできます。詳細については、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 範囲とエイリアス IP 範囲の VPC ネットワーク ルートを自動的にインストールします。これにより、Pod 間のトラフィックのルーティングが大幅に簡素化されます。

また、VPC ネイティブ クラスタにはルートの割り当ては適用されません。クラスタ ファブリックでエイリアス IP 範囲を利用すると、Cloud Storage や BigQuery などの Google サービスに直接アクセスできます。この接続を利用しない場合は、NAT ゲートウェイでのみ接続可能です。

企業にとって、GKE クラスタをアプリケーションやサービスのオンプレミスのエコシステムと安全に通信させることは、一般的なパターンです。Cloud VPN または Cloud Interconnect 経由でエイリアス IP アドレスを検出できるため、エイリアス 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 サーバーが返すのは、サービスで定義されたラベルセレクタに一致する準備完了状態のポッドの 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 アドレスにマップする転送ルールを、各ノードで最新の状態に維持します。ローカルノードで実行中のサービスのポッドがある場合はそのポッドが使用され、ない場合はクラスタ内のランダムポッドが選択されます。

クラスタ IP サービス

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

ヘッドレス サービス

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

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

ネットワーク ポリシー

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

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

ネットワーク ポリシーを使用して、異なるテナントに属するワークロードを分離することもできます。たとえば、テナント単位の名前空間モデルを定義して、セキュアなマルチテナンシーを提供できます。このようなモデルでは、ネットワーク ポリシー ルールにより、特定の名前空間内の 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 ポッドが使用する必要があるドメインについて、クエリを実行する優先 DNS サーバーがある場合に便利です。

外部ネームサービス

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

セレクタのないサービス

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

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

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

Kubernetes Services は、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 クラスタで走行しているサービスの全体的なアジリティ、堅牢性、疎結合が改善されます。

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

ファイアウォール

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 最新バージョンに更新する必要があります。これにより、ロールアウトされた新機能を活用して、クラスタ ノードの基盤となるオペレーティング システムにパッチを適用し、最新の状態に保ちます。

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

  • マスターノードとワーカーノード用の Kubernetes クラスタのメジャーとマイナーの 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 自動スケーリング機能は、コンテナ用の最適な 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 のその他の機能を試す。チュートリアルをご覧ください。