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

このページでは、管理者クラスタとユーザー クラスタを 1 つの GKE On-Prem パッチ バージョンから次のパッチ バージョンにアップグレードする方法について説明します。利用可能なバージョンについては、バージョンをご覧ください。

関連情報:

• ダウンロード
• リリースノート
• 管理ワークステーションのアップグレード

概要

GKE On-Prem は、順次アップグレードをサポートしています。たとえば、次のようなバージョンだけが存在するとします。

• 1.0.10
• 1.0.X。X は .10 より後の数字です。
• 1.0.Y。Y は X より後の数字です。

この場合、1.0.Y が最新バージョンになります。バージョン 1.0.10 のクラスタを 1.0.Y にアップグレードするには、次の操作を行います。

1. クラスタを 1.0.10 から 1.0.X にアップグレードします。
2. 次に、クラスタを 1.0.X から 1.0.Y にアップグレードします。

始める前に

1. 管理ワークステーションに SSH 接続します。

   ssh -i ~/.ssh/vsphere_workstation ubuntu@[IP_ADDRESS]
   

2. gcloud を承認して Google Cloud にアクセスします。

   gcloud auth login

3. アクセス サービス アカウントを有効にします。

   gcloud auth activate-service-account --project [PROJECT_ID] \
   --key-file [ACCESS_KEY_FILE]
   

   ここで

   • [PROJECT_ID] はプロジェクト ID です。
   • [ACCESS_KEY_FILE] は、アクセス サービス アカウントの JSON キーファイルへのパス（/home/ubuntu/access.json など）です。

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

バージョン 1.0.2-gke.3 では、次の必須 OIDC フィールド（usercluster.oidc）が追加されました。これらのフィールドにより、Google Cloud Console からクラスタにログインできます。

• usercluster.oidc.kubectlredirecturl
• usercluster.oidc.clientsecret
• usercluster.oidc.usehttpproxy

Google Cloud Console からクラスタにログインせずに、OIDC を使用する必要がある場合は、これらのフィールドのプレースホルダの値を渡すことができます。

oidc:
  kubectlredirecturl: "redirect.invalid"
  clientsecret: "secret"
  usehttpproxy: "false"

クラスタのアップグレード シナリオを決める

クラスタをアップグレードする前に、アップグレードするバージョンの状況に応じて次のいずれかのシナリオに選択します。

シナリオ	必要なアクション	注
バージョンにセキュリティ アップデートがない。	最新の gkectl をダウンロードします。 最新のバンドルをダウンロードします。 このページの手順に従ってください。
バージョンにセキュリティ アップデートがある。	最新の管理ワークステーション OVA をダウンロードします。 管理ワークステーションをアップグレードします。 このページの手順に従ってください。	新しいバージョンにセキュリティ アップデートがある場合のみ、管理ワークステーションをアップグレードする必要があります。管理ワークステーションをアップグレードすると、最新の gkectl とバンドルが含まれます。

プラットフォームのバージョンを確認する

クラスタをアップグレードするには、クラスタのプラットフォーム バージョンを次のように指定します。

ドキュメントから

バージョンに関する記事をご覧ください。

バンドルから

次のコマンドを実行して、バンドルを一時ディレクトリに展開します。

tar -xvzf /var/lib/gke/bundles/gke-onprem-vsphere-[VERSION].tgz -C [TEMP_DIR]

展開された YAML ファイルを調べて、バンドルの内容の概要を確認します。

特に、gke-onprem-vsphere-[VERSION]-images.yaml を開きます。osimages フィールドを確認します。GKE プラットフォームのバージョンは、OS イメージ ファイルの名前で確認できます。たとえば、次の OS イメージでは、GKE プラットフォームのバージョンは 1.12.7-gke.19 です。

osImages:
  admin: "gs://gke-on-prem-os-ubuntu-release/gke-on-prem-osimage-1.12.7-gke.19-20190516-905ef43658.ova"

構成ファイルの変更

管理ワークステーション VM で構成ファイルを編集します。gkeplatformversion と bundlepath の値を設定します。例:

gkeplatformversion: 1.12.7-gke.19
bundlepath: /var/lib/gke/bundles/gke-onprem-vsphere-1.0.10.tgz

gkectl prepare の実行

次のコマンドを実行します。

gkectl prepare --config [CONFIG_FILE]

gkectl prepare コマンドによって、以下のタスクが実行されます。

• 必要に応じて、vSphere 環境に新しいノードの OS イメージをコピーし、その OS イメージをテンプレートとしてマークします。

• 新しいバンドルで指定された更新済みの Docker イメージを構成済みの場合は、それを非公開 Docker レジストリに push します。

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

ユーザー クラスタをアップグレードする場合、ユーザー クラスタのアップグレードの対象となるバージョンと同じか、それ以上のバージョンが管理クラスタに備わっている必要があります。管理クラスタのバージョンがそのバージョンを下回っている場合は、ユーザー クラスタをアップグレードする前に、管理クラスタをアップグレードしてください。

管理クラスタ

次のコマンドを実行します。

gkectl upgrade admin \
--kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
--config [CONFIG_FILE]

ここで、[ADMIN_CLUSTER_KUBECONFIG] は管理クラスタの kubeconfig ファイル、[CONFIG_FILE] はアップグレードの実行に使用される GKE On-Prem 構成ファイルです。

ユーザー クラスタ

次のコマンドを実行します。

gkectl upgrade cluster \
--kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
--config [CONFIG_FILE] \
--cluster-name [CLUSTER_NAME]

ここで、[ADMIN_CLUSTER_KUBECONFIG] は管理クラスタの kubeconfig ファイル、[CLUSTER_NAME] はアップグレードするユーザー クラスタの名前、[CONFIG_FILE] はアップグレードの実行に使用される GKE On-Prem 構成ファイルです。

アップグレード中のダウンタイムについて

リソース	説明
管理クラスタ	管理クラスタが停止しても、ユーザー クラスタのコントロール プレーンとワークロードは、ダウンタイムの原因となった障害の影響を受けない限り引き続き実行されます。
ユーザー クラスタのコントロール プレーン	通常、ユーザー クラスタ コントロール プレーンには目立ったダウンタイムはありません。ただし、Kubernetes API サーバーへの長時間実行の接続が切断され、再確立する必要がある場合があります。この場合、API 呼び出し元は、接続が確立するまで再試行する必要があります。最悪のケースでは、アップグレード中に最大 1 分間のダウンタイムが発生することがあります。 注: アップグレード中にユーザー クラスタ ノードがユーザー コントロール プレーンに到達できない場合、新しいワークロードはクラスタにスケジュールされません。既存のワークロードが影響を受けることはありません。
ユーザー クラスタノード	アップグレードでユーザー クラスタ ノードの変更が必要な場合、GKE On-Prem はノードをローリング方式で再作成し、これらのノードで実行されている Pod を再スケジュールします。ワークロードへの影響を防ぐには、適切な PodDisruptionBudgets とアンチ アフィニティ ルールを構成します。

既知の問題

• 現時点では、クラスタをアップグレードすると、PodDisruptionBudgets（PDB）を使用するワークロードで中断やダウンタイムが発生することがあります。

トラブルシューティング

詳しくは、トラブルシューティングをご覧ください。

新しいノードが作成されたが、正常でない

現象

手動負荷分散モードを使用しているときに、新しいノードが自身をユーザー クラスタ コントロール プレーンに登録しません。

考えられる原因

ノードの Ingress 検証が有効になり、ノードの起動プロセスがブロックされている可能性があります。

解決策

検証を無効にするには、次のコマンドを実行します。

kubectl patch machinedeployment [MACHINE_DEPLOYMENT_NAME] -p '{"spec":{"template":{"spec":{"providerSpec":{"value":{"machineVariables":{"net_validation_ports": null}}}}}}}' --type=merge

gkectl を使用してクラスタの問題を診断する

クラスタの問題を特定し、クラスタの情報を Google と共有するために、gkectl diagnose コマンドを使用します。クラスタの問題を診断するをご覧ください。

デフォルトのロギング動作

gkectl と gkeadm では、デフォルトのロギング設定を使用するだけで十分です。

• デフォルトでは、ログエントリは次のように保存されます。

  • gkectl の場合、デフォルトのログファイルは /home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log で、このファイルは gkectl を実行するローカル ディレクトリの logs/gkectl-$(date).log ファイルにシンボリック リンクされます。
  • gkeadm の場合、デフォルトのログファイルは、gkeadm を実行するローカル ディレクトリの logs/gkeadm-$(date).log です。
• すべてのログエントリは、ターミナルに出力されていない場合（--alsologtostderr が false の場合）でもログファイルに保存されます。
• -v5 詳細レベル（デフォルト）は、サポートチームが必要とするログエントリすべてを対象としています。
• ログファイルには、実行されたコマンドと失敗メッセージも含まれます。

サポートが必要な場合は、サポートチームにログファイルを送信することをおすすめします。

ログファイルにデフォルト以外の場所を指定する

gkectl ログファイルにデフォルト以外の場所を指定するには、--log_file フラグを使用します。指定したログファイルは、ローカル ディレクトリにシンボリック リンクされません。

gkeadm ログファイルにデフォルト以外の場所を指定するには、--log_file フラグを使用します。

管理クラスタで Cluster API ログを見つける

管理コントロール プレーンの起動後に VM が起動しない場合は、管理クラスタの Cluster API コントローラのログを調べてデバッグを試すことができます。

1. kube-system Namespace で Cluster API コントローラ Pod の名前を確認します。ここで、[ADMIN_CLUSTER_KUBECONFIG] は管理クラスタの kubeconfig ファイルのパスです。

   kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system get pods | grep clusterapi-controllers

2. Pod のログを開きます。ここで、[POD_NAME] は Pod の名前です。必要に応じて、grep または同様のツールを使用してエラーを検索します。

   kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system logs [POD_NAME] vsphere-controller-manager