バージョン 1.3このバージョンは、Anthos バージョンサポートポリシーに記載のとおり、サポートを終了しています。Anthos clusters on VMware (GKE on-prem) に影響するセキュリティの脆弱性、露出、問題に対する最新のパッチとアップデートを適用するには、サポート対象のバージョンにアップグレードしてください。最新バージョンはこちらで確認できます。

利用可能なバージョン

GKE On-Prem のアップグレード

このページでは、GKE On-Prem をアップグレードする方法について説明します。

GKE On-Prem をアップグレードするには、管理ワークステーションをアップグレードします。次に、クラスタをアップグレードします。

始める前に

必ずローカルワークステーションまたはノートパソコンからこの手順を行ってください。既存の管理ワークステーションからこの手順を行わないでください。
クラスタの現在のバージョンを確認します。
アップグレードに関連するリリースノートと既知の問題を確認してください。
バージョンを確認します。

また、次の点も留意してお読みください。

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

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

順次的なアップグレード

GKE On-Prem は順次的なアップグレードをサポートしています。つまり、アップグレードするクラスタは、直前のパッチバージョンである必要があります。

パッチバージョンが直前のものより古い場合は、クラスタを直接最新のバージョンにアップグレードすることはできません。クラスタに古いパッチバージョンが複数ある場合は、パッチバージョンごとに順次クラスタをアップグレードする必要があります。

例

1.1.0 バージョンへのアップグレードを希望していて、管理ワークステーションとユーザークラスタが古い 1.0.1 バージョンを運用中の場合:

1.0.1（最も古いバージョン）
1.0.2
1.1.0（最新バージョン）

次に、次の手順を実行して、1.0.2 バージョン、1.1.0 バージョンに順次アップグレードします。

管理ワークステーションを 1.0.1 から 1.0.2 にアップグレードします。
クラスタを 1.0.1 から 1.0.2 にアップグレードします。
管理ワークステーションを 1.0.2 から 1.1. にアップグレードします。
クラスタを 1.0.2 から 1.1.0 にアップグレードします。

GKE On-Prem 構成ファイルと kubeconfig ファイルをバックアップする

管理ワークステーションをアップグレードすると、Terraform は管理ワークステーション VM を削除し、アップグレードされた管理ワークステーションに置き換えます。

管理ワークステーションのアップグレードを実行する前に、GKE On-Prem の構成ファイルとクラスタの kubeconfig ファイルをバックアップする必要があります。gkectl create cluster コマンドは、管理クラスタ（[ADMIN_CLUSTER_KUBECONFIG]）とユーザークラスタ（[USER_CLUSTER_KUBECONFIG]）の kubeconfig ファイルを作成します。基本的なインストールの例をご覧ください。管理ワークステーションをアップグレードしたら、同じファイルをアップグレードされた管理ワークステーションにコピーします。

管理ワークステーションのアップグレード

Terraform を使用して管理ワークステーションをアップグレードします。

アップグレードされた管理ワークステーションには、管理ワークステーションの Open Virtualization Appliance（OVA）ファイルと同じバージョンの次のエンティティが含まれています。

gkectl
フルバンドル

OVA をダウンロードする

ダウンロードから、アップグレードバージョンである管理ワークステーション OVA ファイルをダウンロードします。

最新の OVA をダウンロードするには、次のコマンドを実行します。

gsutil cp gs://gke-on-prem-release/admin-appliance/1.3.2-gke.1/gke-on-prem-admin-appliance-vsphere-1.3.2-gke.1.{ova,ova.1.sig} ~/

OVA を vSphere にインポートし、VM テンプレートとしてマークする

以降のセクションでは、以下を行います。

vCenter Server と vSphere 環境の要素を宣言する変数を作成する。
管理ワークステーションの OVA を vSphere にインポートし、VM テンプレートとしてマークする。

`govc` の変数を作成する

管理ワークステーション OVA を vSphere にインポートする前に、vCenter Server と vSphere 環境の要素を宣言する変数を govc に指定する必要があります。

export GOVC_URL=https://[VCENTER_SERVER_ADDRESS]/sdk
export GOVC_USERNAME=[VCENTER_SERVER_USERNAME]
export GOVC_PASSWORD=[VCENTER_SERVER_PASSWORD]
export GOVC_DATASTORE=[VSPHERE_DATASTORE]
export GOVC_DATACENTER=[VSPHERE_DATACENTER]
export GOVC_INSECURE=true

次のように、vSphere のデフォルトのリソースプールを使用することも、独自のリソースプールを作成することもできます。

# If you want to use a resource pool you've configured yourself, export this variable:
export GOVC_RESOURCE_POOL=[VSPHERE_CLUSTER]/Resources/[VSPHERE_RESOURCE_POOL]

# If you want to use vSphere's default resource pool, export this variable instead:
export GOVC_RESOURCE_POOL=[VSPHERE_CLUSTER]/Resources

ここで

[VCENTER_SERVER_ADDRESS] は、vCenter Server の IP アドレスまたはホスト名です。
[VCENTER_SERVER_USERNAME] は、vCenter Server で管理者のロールまたは同等の権限を持つアカウントのユーザー名です。
[VCENTER_SERVER_PASSWORD] は、vCenter Server アカウントのパスワードです。
[VSPHERE_DATASTORE] は、vSphere 環境で構成したデータストアの名前です。
[VSPHERE_DATACENTER] は、vSphere 環境で構成したデータセンターの名前です。
[VSPHERE_CLUSTER] は、vSphere 環境で構成したクラスタの名前です。
[VSPHERE_RESOURCE_POOL] は、vSphere 環境で構成したリソースプールの名前です。

OVA を vSphere（標準スイッチ）にインポートする

vSphere 標準スイッチを使用している場合、次のコマンドを使用して OVA を vSphere にインポートします。

govc import.ova -options - ~/gke-on-prem-admin-appliance-vsphere-1.3.2-gke.1.ova <<EOF
{
  "DiskProvisioning": "thin",
  "MarkAsTemplate": true
}
EOF

OVA を vSphere（分散スイッチ）にインポートする

vSphere 分散スイッチを使用している場合、このコマンドを実行して OVA を vSphere にインポートします。ここで、[YOUR_DISTRIBUTED_PORT_GROUP_NAME] は分散ポートグループの名前です。

govc import.ova -options - ~/gke-on-prem-admin-appliance-vsphere-1.3.2-gke.1.ova <<EOF
{
  "DiskProvisioning": "thin",
  "MarkAsTemplate": true,
  "NetworkMapping": [
      {
          "Name": "VM Network",
          "Network": "[YOUR_DISTRIBUTED_PORT_GROUP_NAME]"
      }
  ]
}
EOF

新しい管理ワークステーション VM 用に Terraform のテンプレート変数を設定する

管理ワークステーションの TFVARS ファイルで、vm_template をアップグレード先のバージョンに設定します。vm_template の値は次のようになります。ここで [VERSION] は、OVA のバージョンです。

gke-on-prem-admin-appliance-vsphere-[VERSION]

Terraform を使用して管理ワークステーションをアップグレードする

管理ワークステーションをアップグレードするには、次のコマンドを実行します。次のコマンドは、現在の管理ワークステーション VM を削除し、アップグレードされた VM に置き換えます。

terraform init && terraform apply -auto-approve -input=false

管理ワークステーションに接続する

次のコマンドを実行して、管理ワークステーションに SSH 接続します。

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

バックアップした構成ファイルと kubeconfig ファイルをコピーする

前の手順で、GKE On-Prem 構成ファイルとクラスタの kubeconfig ファイルをバックアップしました。これらのファイルをアップグレードした管理ワークステーションにコピーして戻します。

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

管理ワークステーションをアップグレードして接続したら、次の手順を行います。

十分な IP アドレスが使用可能であることを確認する

アップグレードを行う前に、クラスタに使用可能な IP アドレスが十分にあることを確認します。

DHCP

アップグレード中、GKE On-Prem は管理クラスタ内に 1 つの一時ノードを作成し、関連する各ユーザークラスタ内に 1 つの一時ノードを作成します。DHCP サーバーが、これらの一時ノードに十分な IP アドレスを提供できることを確認してください。詳細については、管理クラスタとユーザークラスタに必要な IP アドレスをご覧ください。

静的 IP

アップグレード中、GKE On-Prem は管理クラスタ内に 1 つの一時ノードを作成し、関連する各ユーザークラスタ内に 1 つの一時ノードを作成します。管理クラスタと各ユーザークラスタに対して、十分な IP アドレスが予約されていることを確認します。クラスタノードより少なくとも 1 つ以上多い IP アドレスを、クラスタごとに予約しておく必要があります。詳細については、静的 IP アドレスの構成をご覧ください。

管理クラスタのノード数を指定します。

kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] get nodes

ここで、[ADMIN_CLUSTER_KUBECONFIG] は管理クラスタの kubeconfig ファイルのパスです。

次に、管理クラスタ用に予約されたアドレスを表示します。

kubectl get cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -o yaml

出力の reservedAddresses フィールドに、管理クラスタノード用に予約されている IP アドレスの数が表示されます。たとえば、次の出力は、管理クラスタノード用に 5 つの IP アドレスが予約されていることを示しています。

...
reservedAddresses:
- gateway: 21.0.135.254
  hostname: admin-node-1
  ip: 21.0.133.41
  netmask: 21
- gateway: 21.0.135.254
  hostname: admin-node-2
  ip: 21.0.133.50
  netmask: 21
- gateway: 21.0.135.254
  hostname: admin-node-3
  ip: 21.0.133.56
  netmask: 21
- gateway: 21.0.135.254
  hostname: admin-node-4
  ip: 21.0.133.47
  netmask: 21
- gateway: 21.0.135.254
  hostname: admin-node-5
  ip: 21.0.133.44
  netmask: 21

予約された IP アドレスの数は、管理クラスタ内のノードの数より少なくとも 1 つ以上多い数である必要があります。そうでない場合は、クラスタオブジェクトを編集して追加のアドレスを予約できます。

クラスタオブジェクトを開いて編集します。

kubectl edit cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG]

reservedAddresses の下に gateway、hostname、ip、netmask を記載したブロックを追加します。

各ユーザークラスタで同じ手順を行います。

ユーザークラスタ内のノード数を確認するには:

kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] get nodes

ここで [USER_CLUSTER_KUBECONFIG] is the path of your user cluster's kubeconfig file.

ユーザークラスタ用に予約されたアドレスを表示するには:

kubectl get cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
-n [USER_CLUSTER_NAME] [USER_CLUSTER_NAME] -o yaml

ここで

[ADMIN_CLUSTER_KUBECONFIG] は、管理クラスタの kubeconfig ファイルのパスです。
[USER_CLUSTER_NAME] は、ユーザークラスタの名前です。

ユーザークラスタのクラスタオブジェクトを編集するには:

kubectl edit cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
-n [USER_CLUSTER_NAME] [USER_CLUSTER_NAME]

構成ファイルの変更

管理ワークステーション VM で、管理者クラスタとユーザークラスタの作成に使用した構成ファイルを編集します。bundlepath の値を設定します。ここで、[VERSION] はクラスタをアップグレードする GKE On-Prem のバージョンです。

bundlepath: /var/lib/gke/bundles/gke-onprem-vsphere-[VERSION].tgz

自動で有効になる機能について

新しい GKE On-Prem バージョンには、特定の VMware vSphere 機能に関する新機能やサポートが含まれています。場合によっては、GKE On-Prem バージョンにアップグレードすると、このような機能が自動的に有効になります。GKE On-Prem のリリースノートで新機能について学びます。GKE On-Prem 構成ファイルに新しい機能が表示されることがあります。

構成ファイルで新しい機能を無効にする

新しい GKE On-Prem バージョンで自動的に有効になり、構成ファイルによって実行される新しい機能を無効にする必要がある場合は、クラスタをアップグレードする前に以下の手順に沿って操作を行います。

アップグレードした管理ワークステーションから、現在の構成ファイルとは異なる名前で新しい構成ファイルを作成します。
```
gkectl create-config --config [CONFIG_NAME]
```
新しい構成ファイルと機能のフィールドを開きます。ファイルを閉じます。
現在の構成ファイルを開き、新しい機能のフィールドを適切な仕様に追加します。
フィールドに false または同等の値を入力します。
構成ファイルを保存します。クラスタのアップグレードを続行します。

クラスタをアップグレードする前には、必ずリリースノートを確認してください。アップグレード後に既存のクラスタの構成を宣言型の方法で変更することはできません。

`gkectl prepare` の実行

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

必要に応じて、vSphere 環境に新しいノードの OS イメージをコピーし、その OS イメージをテンプレートとしてマークします。
新しいバンドルで指定された更新済みの Docker イメージを構成済みの場合は、それを非公開 Docker レジストリに push します。

前述のタスクを行うには、次のコマンドを実行します。

gkectl prepare --config [CONFIG_FILE] [FLAGS]

ここで

[CONFIG_FILE] は、アップグレードの実行に使用する GKE On-Prem 構成ファイルです。
[FLAGS] は、オプションのフラグのセットです。たとえば、vSphere インフラストラクチャのチェックをスキップする --skip-validation-infra フラグを指定できます。

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

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

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

ここで

[ADMIN_CLUSTER_KUBECONFIG] は、管理クラスタの kubeconfig ファイルです。
[CONFIG_FILE] は、アップグレードの実行に使用する GKE On-Prem 構成ファイルです。
[FLAGS] は、オプションのフラグのセットです。たとえば、vSphere インフラストラクチャのチェックをスキップする --skip-validation-infra フラグを指定できます。

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

ユーザークラスタをアップグレードするには、ユーザークラスタをアップグレードする前に管理クラスタを目的のバージョン以上にアップグレードする必要があります。

gkectl

管理ワークステーションから、次のコマンドを実行します。

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

ここで

[ADMIN_CLUSTER_KUBECONFIG] は、管理クラスタの kubeconfig ファイルです。
[CLUSTER_NAME] は、アップグレードするユーザークラスタの名前です。
[CONFIG_FILE] は、アップグレードの実行に使用する GKE On-Prem 構成ファイルです。
[FLAGS] は、オプションのフラグのセットです。たとえば、vSphere インフラストラクチャのチェックをスキップする --skip-validation-infra フラグを指定できます。

Console

ユーザークラスタは、インストール時または作成後に Google Cloud コンソールに登録できます。Google Cloud コンソールの GKE メニューから、登録済みの GKE On-Prem クラスタと Google Kubernetes Engine クラスタを表示してログインできます。

GKE On-Prem ユーザークラスタのアップグレードが有効になると、Google Cloud コンソールに通知が表示されます。この通知をクリックすると、使用可能なバージョンのリストとクラスタをアップグレードするために実行できる gkectl コマンドが表示されます。

Google Cloud Console の GKE メニューに移動します。

GKE メニューに移動
ユーザークラスタの [通知] 列に、[アップグレード可能] があればそれをクリックします。
gkectl upgrade cluster コマンドをコピーします。
管理ワークステーションから、gkectl upgrade cluster コマンドを実行します。ここで、[ADMIN_CLUSTER_KUBECONFIG] は管理クラスタの kubeconfig ファイル、[CLUSTER_NAME] はアップグレード対象のユーザークラスタの名前、[CONFIG_FILE] は、アップグレードに使用している GKE On-Prem 構成ファイルです。

アップグレードの再開

管理クラスタのアップグレード完了後にユーザークラスタのアップグレードが中断された場合、--skip-validation-all フラグを指定して同じアップグレードコマンドを実行することで、そのユーザークラスタのアップグレードを再開できます。

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

管理クラスタのアップグレードの再開について

管理クラスタのアップグレードは中断しないでください。現時点では、管理クラスタのアップグレードは常に再開できるとは限りません。なんらかの理由で管理クラスタのアップグレードが中断された場合は、サポートにお問い合わせください。

既知の問題

以下は、クラスタのアップグレードに関連する既知の問題です。

バージョン 1.1.0-gke.6、1.2.0-gke.6: `stackdriver.proxyconfigsecretname` フィールドが削除される

stackdriver.proxyconfigsecretname フィールドはバージョン 1.1.0-gke.6 で削除されました。フィールドが構成ファイルに存在する場合、GKE On-Prem のプリフライトチェックはエラーを返します。

この問題を回避するには、1.2.0-gke.6 にアップグレードする前に構成ファイルから proxyconfigsecretname フィールドを削除しておきます。

Stackdriver が古いバージョンを参照する

バージョン 1.2.0-gke.6 以前では、Stackdriver はクラスタアップグレードの後に構成を更新できないことが報告されています。Stackdriver は以前のバージョンを参照しているため、Stackdriver はテレメトリーパイプラインの最新の機能を受け取ることができません。この問題により、Google サポートによるクラスタのトラブルシューティングが難しくなることがあります。

クラスタを 1.2.0-gke.6 にアップグレードした後、管理クラスタとユーザークラスタに対して次のコマンドを実行します。

kubectl --kubeconfig=[KUBECONFIG] \
-n kube-system --type=json patch stackdrivers stackdriver \
-p '[{"op":"remove","path":"/spec/version"}]'

ここで、[KUBECONFIG] はクラスタの kubeconfig ファイルへのパスです。

PodDisruptionBudgets を使用するワークロードが中断する

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

バージョン 1.2.0-gke.6: アップグレード後に Prometheus と Grafana が無効になる

ユーザークラスタでは、アップグレード中に Prometheus と Grafana は自動的に無効になります。ただし、構成データと指標データは失われません。管理クラスタでは、Prometheus と Grafana が引き続き有効です。

手順については、GKE On-Prem のリリースノートをご覧ください。

バージョン 1.1.2-gke.0: 削除済みユーザークラスタノードが vSAN データストアから削除されない

手順については、GKE On-Prem のリリースノートをご覧ください。

バージョン 1.1.1-gke.2: vSAN データストアフォルダ内のデータディスクが削除できる

vSAN データストアを使用している場合は、VMDK を保存するフォルダを作成する必要があります。既知の問題により、フォルダのファイルパスではなく、Universally Unique Identifier（UUID）のパスを vcenter.datadisk に指定する必要があります。この不一致によりアップグレードが失敗する可能性があります。

手順については、GKE On-Prem のリリースノートをご覧ください。

バージョン 1.0.2-gke.3 からバージョン 1.1.0-gke.6 にアップグレードする: OIDC に関する問題

OpenID Connect（OIDC）が構成されているバージョン 1.0.11、1.0.1-gke.5、1.0.2-gke.3 クラスタは、バージョン 1.1.0-gke.6 にアップグレードできません。この問題は、バージョン 1.1.1-gke.2 で修正されています。

インストール時にバージョン 1.0.11、1.0.1-gke.5、1.0.2-gke.3 のクラスタを OIDC で構成した場合、クラスタをアップグレードできません。代わりに、新しいクラスタを作成する必要があります。

バージョン 1.0.11 からバージョン 1.0.2-gke.3 にアップグレードする

バージョン 1.0.2-gke.3 では、次の OIDC フィールド（usercluster.oidc）が導入されています。これらのフィールドによって、Google Cloud コンソールからクラスタにログインできるようになります。

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

OIDC を使用する場合、Google Cloud コンソールからクラスタにログインしない場合でも、clientsecret フィールドは必須です。OIDC を使用するには、clientsecret にプレースホルダの値を指定する必要があります。

oidc:
  clientsecret: "secret"

ノードがアップグレードプロセスを完了できない

追加の中断を許可できない PodDisruptionBudget オブジェクトが構成されている場合、ノードのアップグレードを繰り返し試行しても、コントロールプレーンバージョンへのアップグレードが失敗する可能性があります。このエラーを回避するには、Deployment または HorizontalPodAutoscaler をスケールアップして、PodDisruptionBudget 構成を維持しながらノードをドレインすることをおすすめします。

中断を許可しないすべての PodDisruptionBudget オブジェクトを表示するには、次を行います。

kubectl get poddisruptionbudget --all-namespaces -o jsonpath='{range .items[?(@.status.disruptionsAllowed==0)]}{.metadata.name}/{.metadata.namespace}{"\n"}{end}'

付録

バージョン 1.1.0-gke.6 で有効になっている VMware DRS ルールについて

バージョン 1.1.0-gke.6 以降、GKE On-Prem はユーザークラスタのノードに対して VMware Distributed Resource Scheduler（DRS）の反アフィニティルールを自動的に作成し、データセンター内の少なくとも 3 つの物理ホストにそれらを分散させます。バージョン 1.1.0-gke.6 以降、この機能は新しいクラスタと既存のクラスタで自動的に有効になります。

アップグレードを行う前に、vSphere 環境が次の条件を満たしていることを確認してください。

VMware DRS が有効になっていること。VMware DRS には、vSphere Enterprise Plus ライセンスエディションが必要です。DRS を有効にする方法については、クラスタ内の VMware DRS の有効化をご覧ください。
vcenter フィールドで指定された vSphere ユーザーアカウントに Host.Inventory.EditCluster 権限があること。
利用可能な物理ホストが少なくとも 3 つあること。

1.1.0-gke.6 にアップグレードする前に VMware DRS を無効にする

既存のユーザークラスタでこの機能を有効にしない場合（たとえば、機能に対応するのに十分なホストがない場合）は、ユーザークラスタをアップグレードする前に、次の手順を実行します。

既存の GKE On-Prem 構成ファイルを開きます。
usercluster 仕様の下に antiaffinitygroups フィールドを追加します。
```
usercluster:
      ...
      antiaffinitygroups:
        enabled: false
```
ファイルを保存します。
構成ファイルを使用してアップグレードします。クラスタはアップグレードされますが、この機能は有効になりません。

別のアップグレードのシナリオ

共通脆弱性識別子（CVE）などのセキュリティパッチが管理ワークステーションのバージョンにない場合は、別の方法で GKE On-Prem をアップグレードできます。別の方法では、gkectl とユーザークラスタのみがアップグレードされます。このシナリオでは、管理ワークステーションはアップグレードされません。したがって、すべてのセキュリティアップデートが既存の管理ワークステーションに適用された後に、この代替方法を使用する必要があります。

Google Cloud CLI コンポーネント gcloud components update を更新します。
最新の gkectl ツールをダウンロードしてインストールします。
バンドルをダウンロードします。
ユーザークラスタをアップグレードします。

トラブルシューティング

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

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

現象

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

考えられる原因

ノードの 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` コマンドを冗長モードで実行する

-v5

`stderr` に対する `gkectl` エラーのロギング

--alsologtostderr

管理ワークステーションで `gkectl` ログを見つける

デバッグフラグを渡さない場合でも、次の管理ワークステーションディレクトリで gkectl ログを表示できます。

/home/ubuntu/.config/gke-on-prem/logs

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

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

kube-system Namespace で Cluster API コントローラ Pod の名前を確認します。ここで、[ADMIN_CLUSTER_KUBECONFIG] は管理クラスタの kubeconfig ファイルのパスです。
```
kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system get pods | grep clusterapi-controllers
```
Pod のログを開きます。ここで、[POD_NAME] は Pod の名前です。必要に応じて、grep または同様のツールを使用してエラーを検索します。
```
kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system logs [POD_NAME] vsphere-controller-manager
```

GKE On-Prem のアップグレード

始める前に

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

順次的なアップグレード

例

GKE On-Prem 構成ファイルと kubeconfig ファイルをバックアップする

管理ワークステーションのアップグレード

OVA をダウンロードする

OVA を vSphere にインポートし、VM テンプレートとしてマークする

govc の変数を作成する

OVA を vSphere（標準スイッチ）にインポートする

OVA を vSphere（分散スイッチ）にインポートする

新しい管理ワークステーション VM 用に Terraform のテンプレート変数を設定する

Terraform を使用して管理ワークステーションをアップグレードする

管理ワークステーションに接続する

バックアップした構成ファイルと kubeconfig ファイルをコピーする

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

十分な IP アドレスが使用可能であることを確認する

DHCP

静的 IP

構成ファイルの変更

自動で有効になる機能について

構成ファイルで新しい機能を無効にする

gkectl prepare の実行

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

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

gkectl

Console

アップグレードの再開

管理クラスタのアップグレードの再開について

既知の問題

バージョン 1.1.0-gke.6、1.2.0-gke.6: stackdriver.proxyconfigsecretname フィールドが削除される

Stackdriver が古いバージョンを参照する

PodDisruptionBudgets を使用するワークロードが中断する

バージョン 1.2.0-gke.6: アップグレード後に Prometheus と Grafana が無効になる

バージョン 1.1.2-gke.0: 削除済みユーザー クラスタノードが vSAN データストアから削除されない

バージョン 1.1.1-gke.2: vSAN データストア フォルダ内のデータディスクが削除できる

バージョン 1.0.2-gke.3 からバージョン 1.1.0-gke.6 にアップグレードする: OIDC に関する問題

バージョン 1.0.11 からバージョン 1.0.2-gke.3 にアップグレードする

ノードがアップグレード プロセスを完了できない

付録

バージョン 1.1.0-gke.6 で有効になっている VMware DRS ルールについて

1.1.0-gke.6 にアップグレードする前に VMware DRS を無効にする

別のアップグレードのシナリオ

トラブルシューティング

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

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

gkectl コマンドを冗長モードで実行する

stderr に対する gkectl エラーのロギング

管理ワークステーションで gkectl ログを見つける

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

`govc` の変数を作成する

`gkectl prepare` の実行

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

バージョン 1.1.0-gke.6、1.2.0-gke.6: `stackdriver.proxyconfigsecretname` フィールドが削除される

バージョン 1.1.2-gke.0: 削除済みユーザークラスタノードが vSAN データストアから削除されない

バージョン 1.1.1-gke.2: vSAN データストアフォルダ内のデータディスクが削除できる

ノードがアップグレードプロセスを完了できない

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

`gkectl` コマンドを冗長モードで実行する

`stderr` に対する `gkectl` エラーのロギング

管理ワークステーションで `gkectl` ログを見つける