クラスタのライフサイクル

このページでは、Google Kubernetes Engine（GKE）クラスタのライフサイクルの概要について説明します。これには、どのタスクを自分で実施できて、どれが Google Cloud によって管理されるかも含まれます。また、実際の作業を開始するための詳細なガイドへのリンクも示します。

このページを読む前に、次のことと Kubernetes の基本コンセプトを理解しておく必要があります。

クラスタの作成

クイックスタートで説明しているように、GKE での Kubernetes クラスタの作成は簡単であり、特に Google Cloud コンソールを使用して、用意されているデフォルトのオプションをすべて使用する場合は非常に単純です。実際のクラスタの作成は、これよりも少し複雑になることがあります。特に、組織と技術のニーズに合うようにクラスタ オプションを選択するときです。クラスタを作成する前に、組織内のネットワーキングやセキュリティなどの担当者と相談しながら決定を下すことをおすすめします。クラスタ オプションの中には、その構成後に変更するにはクラスタの再作成が必要になるものがあるからです。

クラスタを作成するには、Google Cloud コンソール、gcloud CLI、または GKE 用 Terraform プロバイダを使用します。

クラスタに関する作業

クラスタ管理者の作業の多くは、稼働中のクラスタに関する作業です。タスクの例としては、クラスタの状態のモニタリングとトラブルシューティングがあり、大規模な組織（特に GKE のエンタープライズ ティアを使用する組織）では、複数のクラスタをまとめてフリートの一部として管理することが含まれる場合があります。セキュリティ スペシャリストやネットワーキング スペシャリストは、より専門的なタスク、たとえばセキュリティ ポリシーの適用やネットワーキング インフラストラクチャの構成などを担当することが考えられます。GKE を使用するデベロッパーは、おそらくクラスタの作成や管理を行う必要はありませんが、ワークロードをクラスタにデプロイすることや、自分のワークロードに関する問題のトラブルシューティングを行うことが必要になる可能性があります。

次のようなツールが使用されます。

  • クラスタの作成、管理、状態の表示を行うための Google Cloud ツール。Google Cloud コンソール、gcloud CLI などがあります。
  • Kubernetes コマンドライン ツール kubectl。クラスタ内部のタスク、たとえばワークロードのデプロイや Kubernetes ロールベース アクセス制御（RBAC）ポリシーの適用などに使用します。
  • Terraform。クラスタとワークロードを宣言型でプロビジョニングします。

GKE はマネージド サービスであるため、基盤となるインフラストラクチャ、たとえばクラスタノードを実行する仮想マシンについて、または Kubernetes コントロール プレーン コンポーネントの状態についてユーザーが気に掛ける必要はなく、これらは GKE によって管理されます。

クラスタに関する作業と、これに使用するツールとワークフローについて詳しくは、クラスタ管理の概要をご覧ください。クラスタ アーキテクチャと GKE コントロール プレーンの詳細については、GKE クラスタ アーキテクチャをご覧ください。

クラスタのアップグレード

クラスタのアップグレードでは、クラスタのコントロール プレーンとノードで実行されている GKE システム ソフトウェアのバージョンが更新されます。デフォルトでは、GKE によってクラスタが自動的にアップグレードされるため、セキュリティ アップデート、既知の問題の修正、新機能がクラスタに確実に適用されるとともに、サポートされているバージョンの Kubernetes が実行されることが確実になります。

アップグレード プロセスをより細かく制御できるように、GKE にはリリース チャンネルが用意されています。リリース チャンネルを使用すると、機能の可用性と安定性のバランスを選択して、それに基づいてクラスタのバージョンを選択できます。メンテナンスの時間枠と除外を使用すると、アップグレードやその他のクラスタ メンテナンスをいつ行うかを選択できます。

デフォルトでは、すべてのクラスタが Regular リリース チャンネルに登録されます。ワークロードの停止を最小限に抑えながらリリース チャンネルを最大限に活用する方法については、クラスタのアップグレードに関するベスト プラクティスをご覧ください。

クラスタのアップグレードを自分で開始することもできます。詳細については、クラスタまたはノードプールの手動アップグレードをご覧ください。

クラスタの更新

クラスタの作成に関する前のセクションで説明したように、クラスタの作成後も、その構成に対してさまざまな変更を行うことができます。クラスタに対して可能な更新には、次のようなものがあります。

  • Standard クラスタのサイズを変更します（Autopilot クラスタのサイズ変更は、ワークロードのニーズに基づいて自動的に行われます）。
  • クラスタをフリートに追加します。
  • クラスタのリリース チャンネルを変更します。
  • Standard クラスタのゾーンを更新します。
  • クラスタのメンテナンス ポリシーを更新します。
  • ネットワーキング オプションのサブセットを更新します。
  • クラスタ機能（バックアップ、ロギング、モニタリングなど）を有効または無効にします。

クラスタ作成後に何を変更でき、何を変更できないかについて、詳しくはクラスタ構成の概要をご覧ください。

クラスタのサイズ変更

Autopilot クラスタのサイズは、Pod の仕様に基づいて自動的に調整されるため、クラスタのサイズ変更をユーザーが意識する必要はありません。たとえば、Pod のレプリカの数や、リクエストするリソースを変更すると、それに応じてクラスタのサイズが増減します。

Standard モードを使用する場合は、手動でクラスタのサイズを変更してノードの数を増減できます。たとえば、クラスタによるリソース消費を停止したいがそのクラスタを削除したくない場合に、スケールダウンしてノード数をゼロにします。サイズ変更の詳細については、クラスタのサイズ変更をご覧ください。クラスタの自動スケーリングを使用することもでき、その場合は GKE によってクラスタのノードプールのサイズがワークロードの需要に基づいて自動的に変更されます。また、ノード自動プロビジョニングを使用すると、GKE によってノードプールが自動的に作成および削除されます。

クラスタをさらに効率的に最適化するために、垂直 Pod 自動スケーリング（VPA）も使用できます。オートスケーラーから提示される、CPU およびメモリのリクエストと制限の推奨値を使用することも、これらの値を自動的に更新することもできます。

クラスタの削除

必要に応じて、クラスタを削除できます。詳細については、クラスタの削除をご覧ください。

フリートへのクラスタの追加

複数のクラスタを使用している組織では、これらのクラスタを 1 つのフリート（Kubernetes クラスタの論理的なグループ化）に追加すると、マルチクラスタ管理を単純化できます。フリートを作成すると、組織は個々のクラスタの管理からクラスタ グループ全体の管理にレベルアップでき、フリート対応の機能（マルチクラスタ Ingress、Config Sync、Policy Controller など）を使用できます。

GKE クラスタをフリートに追加するには、Google Cloud コンソールまたは gcloud CLI を使用します。宣言型で行うには、Terraform または Config Connector を使用します。

フリートの仕組みについては、フリートの管理をご覧ください。フリートの作成については、フリートを作成してマルチクラスタ管理を簡素化するをご覧ください。

次のステップ