デフォルトで、Google Kubernetes Engine クラスタとノードプールは Google によって自動的にアップグレードされます。このページでは、GKE クラスタまたはそのノードのアップグレードとダウングレードを手動で要求する方法について説明します。詳細については、自動および手動クラスタ アップグレードの動作をご覧ください。メンテナンスの時間枠と除外対象を構成することで、自動アップグレードのタイミングを管理することもできます。
新しいバージョンの GKE は定期的に発表されています。利用可能なバージョンについては、バージョニングをご覧ください。クラスタの詳細については、クラスタのアーキテクチャをご覧ください。クラスタのアップグレードに関するガイドについては、クラスタのアップグレードに関するベスト プラクティスをご覧ください。
始める前に
作業を始める前に、次のことを確認してください。
- Google Kubernetes Engine API が有効になっていることを確認します。 Google Kubernetes Engine API の有効化
- Cloud SDK がインストール済みであることを確認します。
次のいずれかの方法で gcloud
のデフォルトの設定を指定します。
gcloud init
。デフォルトの設定全般を確認する場合に使用します。gcloud config
。プロジェクト ID、ゾーン、リージョンを個別に設定する場合に使用します。
gcloud init の使用
エラー One of [--zone, --region] must be supplied: Please specify
location
を受信した場合は、このセクションの内容を実施します。
-
gcloud init
を実行して、次の操作を行います。gcloud init
リモート サーバーで SSH を使用している場合は、
--console-only
フラグを指定して、コマンドがブラウザを起動しないようにします。gcloud init --console-only
- 手順に従って
gcloud
を承認し、Google Cloud アカウントを使用します。 - 新しい構成を作成するか、既存の構成を選択します。
- Google Cloud プロジェクトを選択します。
- デフォルトの Compute Engine ゾーンを選択します。
gcloud config の使用
- デフォルトのプロジェクト ID を設定します。
gcloud config set project PROJECT_ID
- ゾーンクラスタを使用する場合は、デフォルトのコンピューティング ゾーンを設定します。
gcloud config set compute/zone COMPUTE_ZONE
- リージョン クラスタを使用する場合は、デフォルトのコンピューティング リージョンを設定します。
gcloud config set compute/region COMPUTE_REGION
gcloud
を最新バージョンに更新します。gcloud components update
データを永続ディスクに保存する
ノードプールをアップグレードする前に、保持するデータが、永続ディスクを使用する永続ボリュームを使用したポッドに保存されていることを確認する必要があります。永続ディスクは、アップグレード時にデータを消去せずにマウント解除され、そのデータはポッド間で「引き渡され」ます。
永続ディスクには次の制限があります。
- ポッドを実行しているノードが Compute Engine VM であること
- これらの VM が永続ディスクと同じ Compute Engine プロジェクトおよびゾーンに存在すること
既存のノード インスタンスに永続ディスクを追加する方法については、Compute Engine ドキュメントのゾーン永続ディスクの追加またはサイズ変更をご覧ください。
クラスタのアップグレードについて
クラスタのコントロール プレーンとノードは個別にアップグレードされます。
制限事項
アルファ クラスタはアップグレードできません。
サポート対象のバージョン
新しいバージョンがリリースされたときや、古いバージョンが廃止されたときに、リリースノートで通知されます。次のコマンドを使用すると、サポート対象のクラスタとノードのバージョンをいつでも確認できます。
gcloud container get-server-config
既知の問題
Anthos Service Mesh または OSS Istio をクラスタにインストールしている場合、Istio コンポーネントの PodDisruptionBudget 設定方法によっては、再試行してもユーザーノードによるコントロール プレーン バージョンへのアップグレードが失敗する可能性があります。このエラーを回避するには、アップグレードをする前に、istio-system
名前空間のコンポーネントで水平ポッド自動スケーリングの minReplicas
設定を 1 から 2 に増やすことをおすすめします。これにより、ASM コントロール プレーンのインスタンスが常に実行されます。
Anthos Service Mesh 1.5 以降または OSS Istio 1.5 以降を使用している場合:
kubectl patch hpa -n istio-system istio-ingressgateway -p '{"spec":{"minReplicas": 2}}' --type=merge
kubectl patch hpa -n istio-system istiod -p '{"spec":{"minReplicas": 2}}' --type=merge
Anthos Service Mesh 1.4.x または OSS Istio 1.4.x を使用している場合:
kubectl patch hpa -n istio-system istio-galley -p '{"spec":{"minReplicas": 2}}' --type=merge
kubectl patch hpa -n istio-system istio-ingressgateway -p '{"spec":{"minReplicas": 2}}' --type=merge
kubectl patch hpa -n istio-system istio-nodeagent -p '{"spec":{"minReplicas": 2}}' --type=merge
kubectl patch hpa -n istio-system istio-pilot -p '{"spec":{"minReplicas": 2}}' --type=merge
kubectl patch hpa -n istio-system istio-sidecar-injector -p '{"spec":{"minReplicas": 2}}' --type=merge
自動アップグレードで問題が発生する可能性がありますが、自動アップグレード プロセスではノードのアップグレードを強制的に行います。ただし、アップグレードは istio-system
Namespace のノードが PodDisruptionBudget に違反するたびに 1 時間余分にかかります。
ダウングレードの制限事項
クラスタをダウングレードすることはおすすめしません。ノードは、クラスタ バージョンより古いパッチ バージョンにダウングレードできます。クラスタをマイナー バージョン間でダウングレードすることはできません。たとえば、クラスタで GKE 1.11.5 を実行している場合、まだ利用可能であれば 1.11.4 にダウングレードできますが、1.10.9 にはダウングレードできません。次のようなエラーが生成されます。
ERROR: (gcloud.container.clusters.upgrade) ResponseError: code=400,
message=Master cannot be upgraded to "1.10.9-gke.9": specified version is not
newer than the current version.
クラスタのアップグレード
クラスタとノードは自動的にアップグレードされます。クラスタの自動アップグレードとそのノードが受け取る内容をより細かく管理するには、リリース チャンネルに登録します。
クラスタの GKE バージョンの管理について詳しくは、アップグレードをご覧ください。
手動アップグレードは、新しいバージョンの提供後であればいつでも開始できます。
コントロール プレーンの手動アップグレード
クラスタのアップグレードを開始すると、コントロール プレーンに再びアクセスできるまで、数分間はクラスタの構成を変更できません。コントロール プレーンのアップグレード中のダウンタイムを防ぐ必要がある場合は、リージョン クラスタの使用を検討してください。
クラスタを手動でアップグレードするには、Cloud Console を使用するか、gcloud
コマンドライン ツールを使用します。クラスタをアップグレードした後、そのノードをアップグレードできます。デフォルトでは、Google Cloud Console で作成したノードでは自動アップグレードが有効になります。このため、アップグレードは自動的に行われます。
gcloud
クラスタ コントロール プレーンのバージョンをアップグレードするには、まず次のコマンドを実行して利用可能なバージョンを確認します。
gcloud container get-server-config
デフォルトのクラス タバージョンにアップグレードするには、次のコマンドを実行します。
gcloud container clusters upgrade CLUSTER_NAME --master
デフォルト以外の特定のバージョンにアップグレードするには、次のコマンドを実行します。
gcloud container clusters upgrade CLUSTER_NAME \
--master --cluster-version VERSION
詳しくは、gcloud container clusters upgrade
のドキュメントをご覧ください。
Console
クラスタ コントロール プレーンを手動で更新するには、次の手順に従います。
Google Cloud Console で Google Kubernetes Engine のメニューに移動します。
目的のクラスタ名をクリックします。
[クラスタの基本] で、[バージョン] の横にある edit [アップグレード可能] をクリックします。
目的のバージョンを選択し、[変更を保存] をクリックします。
クラスタのダウングレード
クラスタを以前のパッチ バージョンにダウングレードするには、次のコマンドを使用してクラスタ コントロール プレーン バージョンを変更します。
gcloud container clusters upgrade CLUSTER_NAME \
--master --cluster-version VERSION
クラスタの自動アップグレードの無効化
クラスタの自動アップグレードは無効にできません。推奨ではありませんが、ノードの自動アップグレードは無効にできます。
ノードのアップグレード
デフォルトでは、クラスタのノードで自動アップグレードが有効になっています。無効にすることはおすすめしません。
ノードプールをアップグレードするときに、サージ アップグレードの設定を構成して、GKE が一度にアップグレードするノードの数と、アップグレードがワークロードに与える影響の大きさを制御できます。デフォルトでは、GKE は一度に 1 ノードずつアップグレードします。
ノードがアップグレードされている間、GKE は新しいポッドのスケジュールを停止し、実行中のポッドを他のノードにスケジュールします。これは、ノードプールで機能を有効または無効にする場合など、ノードの再作成を行う他のイベントも同様です。
アップグレードは、すべてのノードが再作成され、クラスタが目的の状態になったときにはじめて完了します。新しくアップグレードされたノードがコントロール プレーンに登録されると、GKE ではノードがスケジューリング可能であるとマークされます。
新しいノード インスタンスでは、目的の Kubernetes バージョンと次のものが実行されます。
- ノードイメージ
- Docker デーモン(該当する場合)
kubelet
kube-proxy
ノードの手動アップグレード
手動でアップグレードできるノードプールのバージョンは、コントロール プレーンと同じバージョンか、引き続き使用可能でコントロール プレーンと互換性のある以前のバージョンです。Kubernetes バージョンとバージョン スキューのサポート ポリシーにより、コントロール プレーンは、コントロール プレーンの 2 つ前までのマイナー バージョンのノードと互換性が保証されています。たとえば、Kubernetes 1.13 コントロール プレーンは Kubernetes 1.11 ノードと互換性があります。
コントロール プレーンと互換性のあるバージョンを手動でアップグレードするには、Google Cloud Console または gcloud
コマンドライン ツールを使用します。
gcloud
次のコマンドは、ノードをコントロール プレーンで実行されているバージョンにアップグレードします。
gcloud container clusters upgrade CLUSTER_NAME \
--node-pool=NODE_POOL_NAME
CLUSTER_NAME は、アップグレードするクラスタの名前に置き換えます。
ノードで GKE の別のバージョンを指定するには、オプションの --cluster-version
フラグを使用します。
gcloud container clusters upgrade CLUSTER_NAME \
--node-pool=NODE_POOL_NAME \
--cluster-version VERSION
VERSION
は、ノードのアップグレード先の Kubernetes バージョンに置き換えます。たとえば、--cluster-version=1.7.2
や cluster-version=latest
です。
バージョンの指定の詳細については、バージョニングをご覧ください。
詳細については、gcloud container clusters upgrade
のドキュメントをご覧ください。
Console
Cloud Console を使用してノードプールをアップグレードするには、次の手順を行います。
Cloud Console で Google Kubernetes Engine のメニューに移動します。
編集するクラスタの横にある more_vert [アクション] をクリックし、edit [編集] をクリックします。
[クラスタの詳細] ページで [ノード] タブをクリックします。
[ノードプール] セクションで、アップグレードするノードプールの名前をクリックします。
edit [編集] をクリックします。
[ノードのバージョン] の [変更] をクリックします。
[ノードのバージョン] プルダウン リストから目的のバージョンを選択し、[変更] をクリックします。
ノードのダウングレード
ノードプールをダウングレードすることはできません。その代わりに、目的のバージョンで新しいノードプールを作成して、ワークロードを移行します。自動アップグレードが有効になっているノードは、コントロール プレーンのバージョンに合わせてアップグレードされます。
ノードのアップグレード ステータスの確認
アップグレードのステータスは、gcloud beta container operations
で確認できます。
クラスタ内の実行中のオペレーションと完了したオペレーションの全リストを表示するには、次のコマンドを実行します。
gcloud beta container operations list
各オペレーションには、開始時刻と終了時刻、ターゲット クラスタ、ステータスとともに、オペレーション ID とオペレーション タイプが割り当てられています。このリストの表示例を次に示します。
NAME TYPE ZONE TARGET STATUS_MESSAGE STATUS START_TIME END_TIME
operation-1505407677851-8039e369 CREATE_CLUSTER us-west1-a my-cluster DONE 20xx-xx-xxT16:47:57.851933021Z 20xx-xx-xxT16:50:52.898305883Z
operation-1505500805136-e7c64af4 UPGRADE_CLUSTER us-west1-a my-cluster DONE 20xx-xx-xxT18:40:05.136739989Z 20xx-xx-xxT18:41:09.321483832Z
operation-1505500913918-5802c989 DELETE_CLUSTER us-west1-a my-cluster DONE 20xx-xx-xxT18:41:53.918825764Z 20xx-xx-xxT18:43:48.639506814Z
特定のオペレーションに関する詳細情報を取得するには、次のコマンドでオペレーション ID を指定します。
gcloud beta container operations describe OPERATION_ID
例:
gcloud beta container operations describe operation-1507325726639-981f0ed6
endTime: '20xx-xx-xxT21:40:05.324124385Z'
name: operation-1507325726639-981f0ed6
operationType: UPGRADE_CLUSTER
selfLink: https://container.googleapis.com/v1/projects/.../kubernetes-engine/docs/zones/us-central1-a/operations/operation-1507325726639-981f0ed6
startTime: '20xx-xx-xxT21:35:26.639453776Z'
status: DONE
targetLink: https://container.googleapis.com/v1/projects/.../kubernetes-engine/docs/zones/us-central1-a/clusters/...
zone: us-central1-a
ノードのアップグレードをキャンセルする
アップグレードはいつでもキャンセルできます。アップグレードをキャンセルすると、次のようになります。
- アップグレードを開始したノードのアップグレードは完了します。
- アップグレードを開始していないノードはアップグレードされません。
- アップグレードがすでに完了したノードは影響を受けず、ロールバックされません。
アップグレードのオペレーション ID を取得するには、次のコマンドを使用します。
gcloud container operations list
アップグレードをキャンセルするには、次のコマンドを実行します。
gcloud beta container operations cancel OPERATION_ID
詳しくは、gcloud container operations cancel
のドキュメントをご覧ください。
ノードのアップグレードをロールバックする
アップグレードに失敗したノードプールまたはアップグレードがキャンセルされたノードプールを以前のバージョンの Kubernetes にロールバックできます。正常にアップグレードされたノードプールをロールバックすることはできません。アップグレードを開始していないノードは影響を受けません。
アップグレードをロールバックするには、次のコマンドを実行します。
gcloud container node-pools rollback NODE_POOL_NAME \
--cluster CLUSTER_NAME
以下を置き換えます。
NODE_POOL_NAME
: ロールバックするノードプールの名前。CLUSTER_NAME
: ノードプールのロールバック元となるクラスタの名前。
詳しくは、gcloud container node-pools rollback
のドキュメントをご覧ください。
サージ アップグレード パラメータの変更
サージ アップグレードを使用すると、GKE が一度にアップグレードするノード数とアップグレードでワークロードが中断される回数を変更できます。
max-surge-upgrade
フラグと max-unavailable-upgrade
フラグは、ノードプールごとに定義されています。適切なパラメータの選択について詳しくは、最適なサージ構成の決定をご覧ください。
これらの設定は、クラスタやノードプールを作成または更新するときに変更できます。
下記のコマンドでは、次の変数を使用しています。
CLUSTER_NAME
: ノードプールのクラスタの名前。COMPUTE_ZONE
: クラスタのゾーン。NODE_POOL_NAME
: ノードプールの名前。NUMBER_NODES
: 各クラスタのゾーンにあるノードプール内のノード数。SURGE_NODES
: ノードプールのアップグレードのたびに作成される余分な(サージ)ノードの数。UNAVAILABLE_NODES
: ノードプールの各アップグレードで同時に使用不可になるノードの数。
特定のパラメータでクラスタを作成する
サージ アップグレードに固有の設定でクラスタを作成するには、max-surge-upgrade
フラグと max-unavailable-upgrade
フラグを使用します。
gcloud container clusters create CLUSTER_NAME \ --max-surge-upgrade=SURGE_NODES --max-unavailable-upgrade=UNAVAILABLE_NODES
サージ アップグレードが無効なクラスタを作成する
サージ アップグレードなしでクラスタを作成するには、max-surge-upgrade
フラグの値を 0
に設定します。
gcloud container clusters create CLUSTER_NAME \ --max-surge-upgrade=0 --max-unavailable-upgrade=1
特定のサージ パラメータでノードプールを作成する
サージ アップグレードに固有の設定で既存のクラスタにノードプールを作成するには、max-surge-upgrade
フラグと max-unavailable-upgrade
フラグを使用します。
gcloud container node-pools create NODE_POOL_NAME \ --num-nodes=NUMBER_NODES --cluster=CLUSTER_NAME \ --max-surge-upgrade=SURGE_NODES --max-unavailable-upgrade=UNAVAILABLE_NODES
既存のノードプールのサージ アップグレードをオンまたはオフにする
既存のノードプールのアップグレード設定を更新するには、max-surge-upgrade
フラグと max-unavailable-upgrade
フラグを使用します。max-surge-upgrade
を 0
よりも大きい値に設定すると、GKE によってサージノードが作成されます。max-surge-upgrade
を 0
に設定すると、サージノードは作成されません。
gcloud beta container node-pools update NODE_POOL_NAME \ --cluster=CLUSTER_NAME \ --max-surge-upgrade=SURGE_NODES --max-unavailable-upgrade=UNAVAILABLE_NODES
ノードプールでサージ アップグレードが有効になっていることを確認する
ノードプールでサージ アップグレードが有効になっていることを確認するには、gcloud
を使用してクラスタのパラメータを表示します。
gcloud container node-pools describe NODE_POOL_NAME \ --cluster=CLUSTER_NAME
次のステップ
- クラスタ アーキテクチャについて学習する。
- リリース チャンネルについて学習する。