Anthos clusters on VMware

このページには、Anthos clusters on VMware の既知の問題がすべて記載されています。既知の問題をプロダクトバージョンまたはカテゴリでフィルタするには、次のプルダウンメニューから目的のフィルタを選択します。

Anthos clusters on VMware のバージョンを選択します。

問題のカテゴリを選択します。

または、次を検索します。

Category 識別されたバージョン問題と回避策

ネットワーキング、オペレーション

1.10, 1.11, 1.12, 1.13, 1.14

優先度クラスがないため、Anthos Network Gateway コンポーネントが強制排除または保留中になる

kube-system のネットワークゲートウェイ Pod には、次の要約出力例に示すように、Pending または Evicted のステータスが表示されることがあります。


$ kubectl -n kube-system get pods | grep ang-node
ang-node-bjkkc     2/2     Running     0     5d2h
ang-node-mw8cq     0/2     Evicted     0     6m5s
ang-node-zsmq7     0/2     Pending     0     7h

これらのエラーは、ノードのリソースを原因とする強制排除イベント、または Pod のスケジューリング不能を示しています。Anthos Network Gateway Pod には PriorityClass がないため、他のワークロードと同じデフォルトの優先度が設定されます。ノードにリソースの制約があると、ネットワークゲートウェイ Pod が強制排除される場合があります。この動作は ang-node DaemonSet では特にうまくいきません。これらの Pod は特定のノードでスケジュールする必要があり、移行できないためです。

回避策:

1.15 以降にアップグレードします。

短期的な修正として、PriorityClass を Anthos Network Gateway コンポーネントに手動で割り当てることができます。Anthos clusters on VMware コントローラは、クラスタアップグレードなどの調整プロセス中にこれらの手動の変更を上書きします。

system-cluster-critical PriorityClass を ang-controller-manager と autoscaler のクラスタコントローラの Deployment に割り当てます。
system-node-critical PriorityClass を ang-daemon ノードの DaemonSet に割り当てます。

アップグレードと更新

1.12, 1.13, 1.14, 1.15

gcloud にクラスタを登録した後、管理クラスタのアップグレードが失敗する

gcloud を使用して、空でない gkeConnect セクションに管理クラスタを登録した後、クラスタをアップグレードしようとすると、次のエラーが発生することがあります。


failed to register cluster: failed to apply Hub Mem\
bership: Membership API request failed: rpc error: code = InvalidArgument desc = InvalidFieldError for field endpoint.o\
n_prem_cluster.admin_cluster: field cannot be updated

gke-connect 名前空間を削除できます。


kubectl delete ns gke-connect --kubeconfig=ADMIN_KUBECONFIG

管理クラスタのアップグレードを再開します。

オペレーション

1.13.0-1.13.8, 1.14.0-1.14.5, 1.15.0-1.15.1

`gkectl diagnose snapshot --log-since` が、クラスタノードで実行されている `journalctl` コマンドの時間枠を制限できない

クラスタのスナップショットをとる機能には影響しません。これは、クラスタノード上で journalctl を実行してデフォルトで収集されるログがすべてスナップショットに含まれているためです。したがって、デバッグ情報が欠落することはありません。

インストール、アップグレード、更新

1.9+, 1.10+, 1.11+, 1.12+

`gkectl prepare windows` 失敗します。

MicrosoftDockerProvider は非推奨となったため、gkectl prepare windows は 1.13 より前のバージョンの Anthos clusters on VMware に Docker をインストールできません。

回避策:

この問題を回避するための一般的な考え方は、Anthos clusters on VMware 1.13 にアップグレードして、1.13 gkectl を使用して Windows VM テンプレートを作成し、Windows ノードプールを作成することです。以下に示すように、現在のバージョンから Anthos clusters on VMware 1.13 にアクセスするには、次の 2 つの方法があります。

注: 現在のバージョンでこの問題を回避するには、1.13 にアップグレードする必要はありませんが、より多くの手順を手動で行う必要があります。Google までお問い合わせください。

オプション 1: Blue/Green アップグレード

Windows ノードプールがある Anthos clusters on VMware 1.13 以降のバージョンを使用して新しいクラスタを作成し、ワークロードを新しいクラスタに移行してから、現在のクラスタを破棄できます。Anthos の最新のマイナーバージョンの使用をおすすめします。

注: これには新しいクラスタをプロビジョニングするための追加リソースが必要ですが、既存のワークロードのダウンタイムと中断は少なくなります。

オプション 2: Anthos clusters on VMware 1.13 にアップグレードするときに、Windows ノードプールを削除して再度追加する

注: このオプションでは、クラスタが 1.13 にアップグレードされて Windows ノードプールが再び追加されるまで、Windows ワークロードを実行できません。

user-cluster.yaml ファイルから Windows ノードプール構成ファイルを削除して、既存の Windows ノードプールを削除して、次のコマンドを実行します。
```
gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
```
対応するターゲットマイナーバージョンのアップグレードユーザーガイドに従って、Linux 専用管理 + ユーザークラスタを 1.12 にアップグレードします。
（1.13 にアップグレードする前に、必ずこの手順を実行してください）enableWindowsDataplaneV2: true が OnPremUserCluster CR で構成されていることを確認します。そうしないと、クラスタは新しく作成された、Docker がインストールされていない 1.13 Windows VM テンプレートと互換性のない Windows ノードプール用の Docker を引き続き使用します。構成されていないか、false に設定されている場合は、クラスタを更新して user-cluster.yaml で true に設定し、次のコマンドを実行します。
```
gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
```
ユーザーアップグレードガイドに沿って、Linux のみの管理 + ユーザークラスタを 1.13 にアップグレードします。

1.13 gkectl を使用して Windows VM テンプレートを準備します。


gkectl prepare windows --base-vm-template BASE_WINDOWS_VM_TEMPLATE_NAME --bundle-path 1.13_BUNDLE_PATH --kubeconfig=ADMIN_KUBECONFIG

OSImage フィールドを新しく作成された Windows VM テンプレートに設定して、Windows ノードプールの構成を user-cluster.yaml に再び追加します。

クラスタを更新して Windows ノードプールを追加する


gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE

インストール、アップグレード、更新

1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1

`ubuntu` ノードでは `RootDistanceMaxSec` の構成が有効にならない

ノードでは RootDistanceMaxSec のデフォルト値の 5 秒が使用され、20 秒と予想される構成になります。「/var/log/startup.log」にある VM に SSH で接続してノードの起動ログを確認すると、次のエラーを確認できます。


+ has_systemd_unit systemd-timesyncd
/opt/bin/master.sh: line 635: has_systemd_unit: command not found

5 秒を使用すると、クロックドリフトが 5 秒を超えると、システムクロックが NTP サーバーと同期しなくなる可能性があります。RootDistanceMaxSec

回避策:

ノードに SSH で接続し、RootDistanceMaxSec を構成します。


mkdir -p /etc/systemd/timesyncd.conf.d
cat > /etc/systemd/timesyncd.conf.d/90-gke.conf <<EOF
[Time]
RootDistanceMaxSec=20
EOF
systemctl restart systemd-timesyncd

アップグレードと更新

1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2

`osImageType` フィールドが空のため、`gkectl update admin` が失敗する

バージョン 1.13 を使用してバージョン 1.12 の管理クラスタを更新すると、次のエラーが表示されることがあります。gkectl


Failed to update the admin cluster: updating OS image type in admin cluster
is not supported in "1.12.x-gke.x"

バージョン 1.13 または 1.14 のクラスタに gkectl update admin を使用すると、レスポンスで次のメッセージが表示される場合があります。


Exit with error:
Failed to update the cluster: the update contains multiple changes. Please
update only one feature at a time

gkectl ログを確認すると、空の文字列から ubuntu_containerd への osImageType の設定が複数変更されていることがわかります。

この更新エラーは、バージョン 1.9 で導入された管理クラスタ構成ファイルの osImageType フィールドのバックフィルが不適切であるために発生します。

回避策:

修正したバージョンの Anthos clusters on VMware にアップグレードします。アップグレードが困難な場合は、Cloud カスタマーケアにお問い合わせください。

インストール、セキュリティ

1.13, 1.14, 1.15

SNI は、コントロールプレーン V2 のユーザークラスタで動作しません

コントロールプレーン V2 が次の場合、 authentication.sni を持つユーザークラスタの Kubernetes API サーバーに追加のサービス証明書を提供する機能は使用できません。有効（ enableControlplaneV2: true）。

回避策:

修正で Anthos clusters on VMware パッチが利用可能になるまで、SNI を使用する必要がある場合は、コントロールプレーン V2（enableControlplaneV2: false）を無効にします。

インストール

1.0-1.11, 1.12, 1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1

非公開レジストリのユーザー名で `$` を行うと、管理コントロールプレーンのマシンの起動に失敗する

プライベートレジストリのユーザー名に $ が含まれている場合、管理コントロールプレーンのマシンが起動できません。管理コントロールプレーンマシンで /var/log/startup.log を確認すると、次のエラーが表示されます。


++ REGISTRY_CA_CERT=xxx
++ REGISTRY_SERVER=xxx
/etc/startup/startup.conf: line 7: anthos: unbound variable

回避策:

$ を使用せずに非公開レジストリのユーザー名を使用するか、修正後のバージョンの Anthos clusters on VMware を使用します。

アップグレードと更新

1.12.0-1.12.4

管理クラスタの更新中にサポートされていない変更に関する誤検出の警告

管理クラスタを更新すると、ログに次の誤検出の警告が表示されますが、無視してかまいません。


    console.go:47] detected unsupported changes: &v1alpha1.OnPremAdminCluster{
      ...
      - 		CARotation:        &v1alpha1.CARotationConfig{Generated: &v1alpha1.CARotationGenerated{CAVersion: 1}},
      + 		CARotation:        nil,
      ...
    }

アップグレードと更新

1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1

KSA 署名鍵のローテーション後にユーザークラスタを更新できない

設定後KSA 署名鍵をローテーションするその後ユーザークラスタを更新する、gkectl update次のエラーメッセージで失敗する場合があります。


Failed to apply OnPremUserCluster 'USER_CLUSTER_NAME-gke-onprem-mgmt/USER_CLUSTER_NAME':
admission webhook "vonpremusercluster.onprem.cluster.gke.io" denied the request:
requests must not decrement *v1alpha1.KSASigningKeyRotationConfig Version, old version: 2, new version: 1"

回避策:

KSA 署名鍵のバージョンを 1 に戻します。ただし、最新の鍵データを保持します。

管理クラスタの Namespace の Secret を確認し、ksa-signing-key secret の名前を取得します。USER_CLUSTER_NAME
```
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME get secrets | grep ksa-signing-key
```

ksa-signing-key Secret をコピーし、コピーした Secret に service-account-cert という名前を付けます。


kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME get secret KSA-KEY-SECRET-NAME -oyaml | \
sed 's/ name: .*/ name: service-account-cert/' | \
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME apply -f -

以前の ksa-signing-key Secret を削除します。


kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME delete secret KSA-KEY-SECRET-NAME

ksa-signing-key-rotation-stage configmap の data.data フィールドを '{"tokenVersion":1,"privateKeyVersion":1,"publicKeyVersions":[1]}' に更新します。
```
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME \
edit configmap ksa-signing-key-rotation-stage
```

検証 Webhook を無効にして、OnPremUserCluster カスタムリソースのバージョン情報を編集します。


kubectl --kubeconfig=ADMIN_KUBECONFIG patch validatingwebhookconfiguration onprem-user-cluster-controller -p '
webhooks:
- name: vonpremnodepool.onprem.cluster.gke.io
  rules:
  - apiGroups:
    - onprem.cluster.gke.io
    apiVersions:
    - v1alpha1
    operations:
    - CREATE
    resources:
    - onpremnodepools
- name: vonpremusercluster.onprem.cluster.gke.io
  rules:
  - apiGroups:
    - onprem.cluster.gke.io
    apiVersions:
    - v1alpha1
    operations:
    - CREATE
    resources:
    - onpremuserclusters
'

OnPremUserCluster カスタムリソースの spec.ksaSigningKeyRotation.generated.ksaSigningKeyRotation フィールドを 1 に更新します。
```
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME-gke-onprem-mgmt \
edit onpremusercluster USER_CLUSTER_NAME
```
ターゲットユーザークラスタの準備が整うまで待機し、次の方法でステータスを確認できます。
```
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME-gke-onprem-mgmt \
get onpremusercluster
```

ユーザークラスタの検証 Webhook を復元します。


kubectl --kubeconfig=ADMIN_KUBECONFIG patch validatingwebhookconfiguration onprem-user-cluster-controller -p '
webhooks:
- name: vonpremnodepool.onprem.cluster.gke.io
  rules:
  - apiGroups:
    - onprem.cluster.gke.io
    apiVersions:
    - v1alpha1
    operations:
    - CREATE
    - UPDATE
    resources:
    - onpremnodepools
- name: vonpremusercluster.onprem.cluster.gke.io
  rules:
  - apiGroups:
    - onprem.cluster.gke.io
    apiVersions:
    - v1alpha1
    operations:
    - CREATE
    - UPDATE
    resources:
    - onpremuserclusters
'

修正済みのバージョンにクラスタがアップグレードされるまで、別の KSA 署名鍵のローテーションを使用しないでください。

オペレーション

1.13.1+, 1.14, 1.15

Terraform がユーザークラスタを削除しても、F5 BIG-IP 仮想サーバーがクリーンアップされない

Terraform を使用して F5 BIG-IP ロードバランサを持つユーザークラスタを削除しても、クラスタの削除後に F5 BIG-IP 仮想サーバーは削除されません。

回避策:

F5 リソースを削除するには、ユーザークラスタ F5 パーティションをクリーンアップする手順を行います。

インストール、アップグレード、更新

1.13.8, 1.14.4

kind クラスタが `docker.io` からコンテナイメージを pull する

バージョン 1.13.8 またはバージョン 1.14.4 の管理クラスタを作成するか、管理クラスタをバージョン 1.13.8 または 1.14.4 にアップグレードすると、その種類クラスタは docker.io から次のコンテナイメージを pull します。 :

docker.io/kindest/kindnetd

docker.io/kindest/local-path-provisioner

docker.io/kindest/local-path-helper

docker.io が管理ワークステーションからアクセスできない場合、管理クラスタの作成またはアップグレードが種類のクラスタを起動できません。管理ワークステーションで次のコマンドを実行すると、ErrImagePull に保留中の対応するコンテナが表示されます。


docker exec gkectl-control-plane kubectl get pods -A

レスポンスには、次のようなエントリが含まれます。


...
kube-system         kindnet-xlhmr                             0/1
    ErrImagePull  0    3m12s
...
local-path-storage  local-path-provisioner-86666ffff6-zzqtp   0/1
    Pending       0    3m12s
...

これらのコンテナイメージは、その種類のクラスタコンテナイメージにプリロードされている必要があります。ただし、種類 v0.18.0 にはプリロードされたコンテナイメージに問題があるため、誤ってインターネットから pull される可能性があります。

回避策:

管理クラスタの作成またはアップグレードが保留されている間に、管理ワークステーションで次のコマンドを実行します。


docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/kindnetd:v20230330-48f316cd@sha256:c19d6362a6a928139820761475a38c24c0cf84d507b9ddf414a078cf627497af docker.io/kindest/kindnetd:v20230330-48f316cd
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/kindnetd:v20230330-48f316cd@sha256:c19d6362a6a928139820761475a38c24c0cf84d507b9ddf414a078cf627497af docker.io/kindest/kindnetd@sha256:c19d6362a6a928139820761475a38c24c0cf84d507b9ddf414a078cf627497af

docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-helper:v20230330-48f316cd@sha256:135203f2441f916fb13dad1561d27f60a6f11f50ec288b01a7d2ee9947c36270 docker.io/kindest/local-path-helper:v20230330-48f316cd
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-helper:v20230330-48f316cd@sha256:135203f2441f916fb13dad1561d27f60a6f11f50ec288b01a7d2ee9947c36270 docker.io/kindest/local-path-helper@sha256:135203f2441f916fb13dad1561d27f60a6f11f50ec288b01a7d2ee9947c36270

docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-provisioner:v0.0.23-kind.0@sha256:f2d0a02831ff3a03cf51343226670d5060623b43a4cfc4808bd0875b2c4b9501 docker.io/kindest/local-path-provisioner:v0.0.23-kind.0
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-provisioner:v0.0.23-kind.0@sha256:f2d0a02831ff3a03cf51343226670d5060623b43a4cfc4808bd0875b2c4b9501 docker.io/kindest/local-path-provisioner@sha256:f2d0a02831ff3a03cf51343226670d5060623b43a4cfc4808bd0875b2c4b9501

オペレーション

1.13.0-1.13.7, 1.14.0-1.14.4, 1.15.0

ネットワークで重複する GARP リクエストが除外されていると、HA コントロールプレーン V2 のユーザークラスタと管理クラスタでフェイルオーバーが失敗する

クラスタ VM が、重複する GARP（Gratuitous ARP）リクエストを除外するスイッチに接続している場合、keepalived リーダー選出が競合状態になり、一部のノードで ARP テーブルエントリが正しくない可能性があります。

影響を受けるノードでpingコントロールプレーン VIP が機能しますが、コントロールプレーン VIP への TCP 接続がタイムアウトします。

回避策:

影響を受けるクラスタの各コントロールプレーンノードで、次のコマンドを実行します。


    iptables -I FORWARD -i ens192 --destination CONTROL_PLANE_VIP -j DROP

アップグレードと更新

1.13.0-1.13.7, 1.14.0-1.14.4, 1.15.0

vCenter 証明書のローテーション後に `vsphere-csi-controller` を再起動する必要がある

vsphere-csi-controller は、vCenter 証明書のローテーション後に vCenter シークレットを更新します。ただし、現在のシステムでは vsphere-csi-controller の Pod が適切に再起動されないため、ローテーション後に vsphere-csi-controller がクラッシュします。

回避策:

1.13 以降のバージョンで作成されたクラスタの場合は、以下の手順に従って vsphere-csi-controller を再起動します。


kubectl --kubeconfig=ADMIN_KUBECONFIG rollout restart deployment vsphere-csi-controller -n kube-system

インストール

1.10.3-1.10.7, 1.11, 1.12, 1.13.0-1.13.1

クラスタ登録のエラーによって管理クラスタの作成に失敗しない

管理クラスタの作成中にクラスタ登録が失敗した場合でも、コマンド gkectl create admin はエラーで失敗せず、成功する可能性があります。つまり、管理クラスタの作成は、フリートに登録しなくても「成功」します。

この問題を特定するには、gkectl create admin のログで次のエラーメッセージを探します。


Failed to register admin cluster

また、Cloud Console で登録済みクラスタからクラスタを見つけることもできます。

回避策:

1.12 以降のバージョンで作成されたクラスタの場合は、クラスタの作成後に管理クラスタの登録を再試行する手順を行ってください。以前のバージョンで作成されたクラスタの場合、

「foo: bar」のような架空の Key-Value ペアを connect-register SA キーファイルに追加します。
gkectl update admin を実行して、管理クラスタを再登録します。

アップグレードと更新

1.10, 1.11, 1.12, 1.13.0-1.13.1

管理クラスタのアップグレード中に管理クラスタの再登録がスキップされる

管理クラスタのアップグレード中に、ユーザーコントロールプレーンノードのアップグレードがタイムアウトした場合、更新された Connect Agent バージョンに管理クラスタは再登録されません。

回避策:

クラスタが登録済みクラスタに表示されているかどうかを確認します。必要であれば、認証の設定後にクラスタにログインします。クラスタがまだ登録されている場合は、以下の手順をスキップして登録を再試行してください。 1.12 以降のバージョンにアップグレードされたクラスタの場合は、クラスタの作成後に管理クラスタの登録を再試行する手順に沿って操作してください。以前のバージョンにアップグレードされたクラスタの場合:

「foo: bar」のような架空の Key-Value ペアを connect-register SA キーファイルに追加します。
gkectl update admin を実行して、管理クラスタを再登録します。

構成

1.15.0

`vCenter.dataDisk` に関する誤ったエラーメッセージ

高可用性管理クラスタの場合、gkectl prepare は次の誤ったエラーメッセージを表示します。


vCenter.dataDisk must be present in the AdminCluster spec

回避策:

このエラーは無視してかまいません。

VMware

1.15.0

VM ホストアフィニティルールが冗長であるためノードプールの作成に失敗する

以下を使用するノードプールを作成するときVM ホストアフィニティ競合状態によって複数の競合が発生する可能性があります。VM ホストアフィニティルール同じ名前で作成されます。これにより、ノードプールの作成に失敗することがあります。

回避策:

古い冗長ルールを削除して、ノードプールの作成を続行できるようにします。これらのルールの名前は [USER_CLUSTER_NAME]～[HASH] です。

オペレーション

1.15.0

`failed to delete the admin master node object and reboot the admin master VM` が原因で `gkectl repair admin-master` が失敗する可能性があります。

gkectl repair admin-master コマンドは、競合状態により次のエラーで失敗する場合があります。


Failed to repair: failed to delete the admin master node object and reboot the admin master VM

回避策:

このコマンドはべき等です。コマンドが成功するまで安全に再実行できます。

アップグレードと更新

1.15.0

コントロールプレーンノードの再作成または更新後に Pod が失敗状態のままになる

コントロールプレーンノードを再作成または更新すると、NodeAffinity の述語の失敗により、特定の Pod が Failed 状態のままになることがあります。このような障害が発生した Pod は、通常のクラスタオペレーションや正常性には影響しません。

回避策:

失敗した Pod は無視するか、手動で削除できます。

セキュリティの構成

1.15

非公開レジストリの認証情報が原因で OnPremUserCluster の準備ができていない

準備済みの認証情報と非公開レジストリを使用していて、非公開レジストリ用に準備された認証情報を構成していない場合、OnPremUserCluster の準備ができていない可能性があります。次のエラーメッセージが表示される場合があります。


failed to check secret reference for private registry …

回避策:

準備された認証情報の構成の手順に従って、ユーザークラスタの非公開レジストリの認証情報を準備します。

アップグレードと更新

1.15.0

`gkectl upgrade admin` が `StorageClass standard sets the parameter diskformat which is invalid for CSI Migration` で失敗する

gkectl upgrade admin 中に、CSI Migration のストレージプリフライトチェックは、CSI 移行後に無視されるパラメータが StorageClasses にないことを確認します。たとえば、パラメータ diskformat を含む StorageClass がある場合、gkectl upgrade admin は StorageClass にフラグを付け、プリフライト検証で失敗を報告します。 Anthos 1.10 以前で作成された管理クラスタには diskformat: thin という StorageClass がありますが、この検証は失敗しますが、この StorageClass は CSI 移行後も正常に動作します。これらの障害は、代わりに警告として解釈されます。

詳細については、ツリー内の vSphere ボリュームの vSphere Container Storage プラグインへの移行の StorageClass パラメータのセクションをご覧ください。

回避策:

CSI 移行後に、パラメータを無視した StorageClass がクラスタにあることを確認したら、フラグ --skip-validation-cluster-health で gkectl upgrade admin を実行します。

ストレージ

1.15

Windows ファイルシステムを使用して移行された in-tree vSphere ボリュームは、vSphere CSI ドライバでは使用できません。

特定の条件下では、ディスクを Windows ノードに読み取り専用として接続できます。これにより、対応する Volume が Pod 内で読み取り専用になります。この問題は、ノードの新しいセットが古いノードセット（クラスタのアップグレードやノードプールの更新など）を置き換える場合に発生する可能性が高くなります。正常に動作していたステートフルワークロードで、新しいノードセットのボリュームに書き込めなくなる場合があります。

回避策:

ボリュームに書き込めない Pod の UID を取得します。


kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pod \
    POD_NAME --namespace POD_NAMESPACE \
    -o=jsonpath='{.metadata.uid}{"\n"}'

PersistentVolumeClaim を使用して PersistentVolume の名前を取得します。


kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pvc \
    PVC_NAME --namespace POD_NAMESPACE \
    -o jsonpath='{.spec.volumeName}{"\n"}'

Pod が実行されているノードの名前を確認します。


kubectl --kubeconfig USER_CLUSTER_KUBECONFIGget pods \
    --namespace POD_NAMESPACE \
    -o jsonpath='{.spec.nodeName}{"\n"}'

SSH または vSphere ウェブインターフェースを使用して、ノードへの PowerShell アクセスを取得します。

環境変数を設定します。


PS C:\Users\administrator> pvname=PV_NAME
PS C:\Users\administrator> podid=POD_UID

PersistentVolume に関連付けられているディスクのディスク番号を特定します。


PS C:\Users\administrator> disknum=(Get-Partition -Volume (Get-Volume -UniqueId ("\\?\"+(Get-Item (Get-Item
"C:\var\lib\kubelet\pods\$podid\volumes\kubernetes.io~csi\$pvname\mount").Target).Target))).DiskNumber

ディスクが readonly であることを確認します。
```
PS C:\Users\administrator> (Get-Disk -Number $disknum).IsReadonly
```
結果は True になります。

readonly を false に設定する。


PS C:\Users\administrator> Set-Disk -Number $disknum -IsReadonly $false
PS C:\Users\administrator> (Get-Disk -Number $disknum).IsReadonly

Pod を削除して再起動できるようにします。


kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete pod POD_NAME \
    --namespace POD_NAMESPACE

Pod は同じノードにスケジュールされます。ただし、Pod が新しいノードにスケジュールされている場合は、新しいノードで上記の手順を繰り返す必要があります。

アップグレードと更新

1.12, 1.13.0-1.13.7, 1.14.0-1.14.4

`vsphere-csi-secret` が `gkectl update credentials vsphere --admin-cluster` の後に更新されない

クラスタ認証情報の更新後に管理クラスタの vSphere 認証情報を更新した場合、管理クラスタの kube-system 名前空間で vsphere-csi-secret が引き続き古い認証情報を使用することがあります。

回避策:

vsphere-csi-secret Secret 名を取得します。


kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system get secrets | grep vsphere-csi-secret

上記の手順で取得した vsphere-csi-secret シークレットのデータを更新します。


kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system patch secret CSI_SECRET_NAME -p \
  "{\"data\":{\"config\":\"$( \
    kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system get secrets CSI_SECRET_NAME -ojsonpath='{.data.config}' \
      | base64 -d \
      | sed -e '/user/c user = \"VSPHERE_USERNAME_TO_BE_UPDATED\"' \
      | sed -e '/password/c password = \"VSPHERE_PASSWORD_TO_BE_UPDATED\"' \
      | base64 -w 0 \
    )\"}}"

vsphere-csi-controller を再起動します。


kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system rollout restart deployment vsphere-csi-controller

ロールアウトのステータスを次の方法で追跡できます。
```
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system rollout status deployment vsphere-csi-controller
```
デプロイが正常にロールアウトされたら、更新された vsphere-csi-secret をコントローラで使用する必要があります。

アップグレードと更新

1.10, 1.11, 1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2

`gkectl update cluster` で Cloud Audit Logs を有効にするときに `audit-proxy` がクラッシュループする

audit-proxy は、--cluster-name が空であるためにクラッシュループする可能性があります。この動作は、更新ロジックのバグが原因で発生します。このバグでは、クラスタ名が監査プロキシ Pod / コンテナマニフェストに伝播されません。

回避策:

enableControlplaneV2: true のコントロールプレーン v2 ユーザークラスタの場合は、SSH を使用してユーザーコントロールプレーンのマシンに接続し、--cluster_name=USER_CLUSTER_NAME で /etc/kubernetes/manifests/audit-proxy.yaml を更新します。

コントロールプレーン v1 のユーザークラスタの場合は、kube-apiserver ステートフルセットの audit-proxy コンテナを編集して --cluster_name=USER_CLUSTER_NAME を追加します。


kubectl edit statefulset kube-apiserver -n USER_CLUSTER_NAME --kubeconfig=ADMIN_CLUSTER_KUBECONFIG

アップグレードと更新

1.11, 1.12, 1.13.0-1.13.5, 1.14.0-1.14.1

`gkectl upgrade cluster` の直後に追加のコントロールプレーンを再デプロイする

gkectl upgrade cluster の直後に、コントロールプレーン Pod が再デプロイされる可能性があります。 gkectl list clusters のクラスタの状態が RUNNING から RECONCILING に変わります。ユーザークラスタへのリクエストがタイムアウトする場合があります。

これは、gkectl upgrade cluster の後にコントロールプレーンの証明書のローテーションが自動的に行われるためです。

この問題は、コントロールプレーン v2 を使用しないユーザークラスタでのみ発生します。

回避策:

クラスタ状態が gkectl list clusters に再び RUNNING に戻るまで待つか、修正を伴うバージョン 1.13.6 以降、1.14.2 以降、または 1.15 以降にアップグレードします。

アップグレードと更新

1.12.7

不正なリリース 1.12.7-gke.19 が削除されました。

Anthos clusters on VMware 1.12.7-gke.19 は不適切リリースであるため、使用しないでください。これらのアーティファクトは、Cloud Storage バケットから削除されています。

回避策:

代わりに 1.12.7-gke.20 リリースを使用してください。

アップグレードと更新

1.12.0+, 1.13.0-1.13.7, 1.14.0-1.14.3

`gke-connect-agent` では、レジストリ認証情報の更新後も引き続き古いイメージが使用されます

次のいずれかの方法でレジストリ認証情報を更新する場合:

gkectl update credentials componentaccess（非公開レジストリを使用しない場合）
gkectl update credentials privateregistry（非公開レジストリを使用する場合）

gke-connect-agent が引き続き古いイメージを使用しているか、ImagePullBackOff が原因で gke-connect-agent Pod を pull できない可能性があります。

この問題は、Anthos clusters on VMware リリース 1.13.8、1.14.4、およびそれ以降のリリースで修正されます。

回避策:

オプション 1: gke-connect-agent を手動で再デプロイする。

gke-connect 名前空間を削除します。


kubectl --kubeconfig=KUBECONFIG delete namespace gke-connect

元の登録サービスアカウントキーを使用して gke-connect-agent を再デプロイします（鍵を更新する必要はありません）。

管理クラスタの場合:


gkectl update credentials register --kubeconfig=ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG_FILE --admin-cluster

ユーザークラスタの場合:


gkectl update credentials register --kubeconfig=ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE

オプション 2: gke-connect-agent のデプロイで使用されるイメージ pull シークレット regcred のデータを手動で変更できます。


kubectl --kubeconfig=KUBECONFIG -n=gke-connect patch secrets regcred -p "{\"data\":{\".dockerconfigjson\":\"$(kubectl --kubeconfig=KUBECONFIG -n=kube-system get secrets private-registry-creds -ojsonpath='{.data.\.dockerconfigjson}')\"}}"

オプション 3: gke-connect-agent デプロイで、クラスタのデフォルトのイメージ pull シークレットを追加できます。

デフォルトの Secret を gke-connect Namespace にコピーします。


kubectl --kubeconfig=KUBECONFIG -n=kube-system get secret private-registry-creds -oyaml | sed 's/ namespace: .*/ namespace: gke-connect/' | kubectl --kubeconfig=KUBECONFIG -n=gke-connect apply -f -

gke-connect-agent デプロイメント名を取得します。


kubectl --kubeconfig=KUBECONFIG -n=gke-connect get deployment | grep gke-connect-agent

デフォルトシークレットを gke-connect-agent Deployment に追加します。


kubectl --kubeconfig=KUBECONFIG -n=gke-connect patch deployment DEPLOYMENT_NAME -p '{"spec":{"template":{"spec":{"imagePullSecrets": [{"name": "private-registry-creds"}, {"name": "regcred"}]}}}}'

インストール

1.13, 1.14

手動による LB 構成チェックの失敗

手動ロードバランサを使用してクラスタを作成する前に、gkectl check-config を実行して構成を検証すると、次のエラーメッセージでコマンドが失敗します。


 - Validation Category: Manual LB    Running validation check for "Network
configuration"...panic: runtime error: invalid memory address or nil pointer
dereference

回避策:

オプション 1: 修正を含むパッチバージョン 1.13.7 と 1.14.4 を使用できます。

オプション 2: 同じコマンドを実行して構成を検証することもできますが、ロードバランサの検証はスキップできます。


gkectl check-config --skip-validation-load-balancer

オペレーション

1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13, and 1.14

etcd ウォッチの不足

etcd バージョン 3.4.13 以前を実行しているクラスタでは、ウォッチの枯渇と非運用リソースのウォッチが発生する可能性があります。これは、次の問題につながる可能性があります。

Pod のスケジューリングが中断される
ノードが登録できない
kubelet が Pod の変更を監視しない

これらの問題により、クラスタが機能しなくなる場合があります。

この問題は、Anthos clusters on VMware リリース 1.12.7、1.13.6、1.14.3、およびそれ以降のリリースで修正されています。これらの新しいリリースでは、etcd バージョン 3.4.21 を使用しています。以前のバージョンの Anthos clusters on VMware は、この問題の影響を受けます。

回避策

すぐにアップグレードできない場合は、クラスタ内のノード数を減らすことで、クラスタの障害のリスクを軽減できます。etcd_network_client_grpc_sent_bytes_total 指標が 300 MBps 未満になるまでノードを削除する。

Metrics Explorer でこの指標を表示するには:

Google Cloud コンソールの Metrics Explorer に移動します。
Metrics Explorer に移動
[Configuration] タブを選択します。
[指標の選択] を展開し、フィルタバーに「Kubernetes Container」と入力し、サブメニューを使用して指標を選択します。
1. [有効なリソース] メニューで、[Kubernetes Container] を選択します。
2. [アクティブな指標カテゴリ] メニューで、[環境] を選択します。
3. [ACTIVE METRICS] メニューで etcd_network_client_grpc_sent_bytes_total を選択します。
4. [適用] をクリックします。

アップグレードと更新

1.10, 1.11, 1.12, 1.13　および　1.14

Anthos Identity Service がコントロールプレーンのレイテンシを引き起こす可能性がある

クラスタが再起動またはアップグレードされると、Anthos Identity Service は、認証 Webhook を介して kube-apiserver から Anthos Identity Service に転送された期限切れの JWT トークンで構成されるトラフィックで圧倒される可能性があります。Anthos Identity Service はクラッシュループしませんが、応答しなくなり、それ以上リクエストを処理できなくなります。この問題は、最終的にコントロールプレーンのレイテンシにつながります。

この問題は、次の Anthos clusters on VMware リリースで修正されています。

1.12.6+
1.13.6+
1.14.2+

この問題の影響を受けたかどうかを判断するには、次の手順を行います。

Anthos Identity Service エンドポイントに外部からアクセスできるかどうかを確認します。
```
curl -s -o /dev/null -w "%{http_code}" \
    -X POST https://CLUSTER_ENDPOINT/api/v1/namespaces/anthos-identity-service/services/https:ais:https/proxy/authenticate -d '{}'
```
CLUSTER_ENDPOINT は、クラスタのコントロールプレーンの VIP とコントロールプレーンロードバランサのポート（172.16.20.50:443 など）に置き換えます。

この問題の影響を受けると、コマンドは 400 ステータスコードを返します。リクエストがタイムアウトした場合は、ais Pod を再起動し、curl コマンドを再実行して問題が解決するかどうかを確認します。ステータスコード 000 が返されれば、問題は解決されており、完了です。それでも 400 ステータスコードが返される場合、Anthos Identity Service HTTP サーバーは起動していません。この場合は、続行します。

Anthos Identity Service と kube-apiserver のログを確認します。

Anthos Identity Service のログを確認します。


kubectl logs -f -l k8s-app=ais -n anthos-identity-service \
    --kubeconfig KUBECONFIG

ログに次のようなエントリが含まれている場合は、この問題の影響を受けています。


I0811 22:32:03.583448      32 authentication_plugin.cc:295] Stopping OIDC authentication for ???. Unable to verify the OIDC ID token: JWT verification failed: The JWT does not appear to be from this identity provider. To match this provider, the 'aud' claim must contain one of the following audiences:

クラスタの kube-apiserver ログを確認します。

次のコマンドの KUBE_APISERVER_POD は、特定のクラスタの kube-apiserver Pod の名前です。

管理クラスタ:


kubectl --kubeconfig ADMIN_KUBECONFIG logs \
    -n kube-system KUBE_APISERVER_POD kube-apiserver

ユーザークラスタ:


kubectl --kubeconfig ADMIN_KUBECONFIG logs \
    -n USER_CLUSTER_NAME KUBE_APISERVER_POD kube-apiserver

kube-apiserver ログに次のようなエントリが含まれている場合、この問題の影響を受けます。


E0811 22:30:22.656085       1 webhook.go:127] Failed to make webhook authenticator request: error trying to reach service: net/http: TLS handshake timeout
E0811 22:30:22.656266       1 authentication.go:63] "Unable to authenticate the request" err="[invalid bearer token, error trying to reach service: net/http: TLS handshake timeout]"

回避策

すぐにクラスタをアップグレードして修正できない場合は、回避策として問題のある Pod を特定して再起動できます。

Anthos Identity Service の詳細レベルを 9 に増やします。


kubectl patch deployment ais -n anthos-identity-service --type=json \
    -p='[{"op": "add", "path": "/spec/template/spec/containers/0/args/-", \
    "value":"--vmodule=cloud/identity/hybrid/charon/*=9"}]' \
    --kubeconfig KUBECONFIG

Anthos Identity Service のログで、無効なトークンコンテキストを確認します。
```
kubectl logs -f -l k8s-app=ais -n anthos-identity-service \
    --kubeconfig KUBECONFIG
```
無効な各トークンコンテキストに関連付けられたトークンペイロードを取得するには、次のコマンドを使用して、関連する各サービスアカウントシークレットを解析します。
```
kubectl -n kube-system get secret SA_SECRET \
    --kubeconfig KUBECONFIG \
    -o jsonpath='{.data.token}' | base64 --decode
```
トークンをデコードしてソース Pod 名と名前空間を表示するには、jwt.io のデバッガにトークンをコピーします。
トークンから特定された Pod を再起動します。

オペレーション

1.8, 1.9, 1.10

etcd-Maintenance Pod のメモリ使用量の増加の問題

etcddefrag:gke_master_etcddefrag_20210211.00_p0 イメージを使用する etcd メンテナンス Pod が影響を受けます。「etcddefrag」コンテナは、defrag サイクルごとに etcd サーバーへの新しい接続を開き、古い接続はクリーンアップされません。

回避策:

オプション 1: 修正を含む最新のパッチバージョン 1.8 から 1.11 にアップグレードします。

オプション 2: 1.9.6 と 1.10.3 より前のパッチバージョンを使用している場合は、管理クラスタとユーザークラスタの etcd-Maintenance Pod をスケールダウンする必要があります。


kubectl scale --replicas 0 deployment/gke-master-etcd-maintenance -n USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG
kubectl scale --replicas 0 deployment/gke-master-etcd-maintenance -n kube-system --kubeconfig ADMIN_CLUSTER_KUBECONFIG

オペレーション

1.9, 1.10, 1.11, 1.12, 1.13

ユーザークラスタコントロールプレーン Pod のヘルスチェックが失敗する

クラスタヘルスチェックコントローラと gkectl diagnose cluster コマンドは、名前空間全体にわたる Pod のヘルスチェックを含む一連のヘルスチェックを実行します。ただし、ユーザーコントロールプレーン Pod が誤ってスキップされ始めます。コントロールプレーン v2 モードを使用しても、クラスタには影響しません。

回避策:

ワークロードやクラスタ管理には影響しません。コントロールプレーン Pod の正常性を確認するには、次のコマンドを実行します。


kubectl get pods -owide -n USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG

アップグレードと更新

1.6+, 1.7+

1.6 と 1.7 の管理クラスタのアップグレードは、`k8s.gcr.io` -> `registry.k8s.io` リダイレクトの影響を受ける可能性があります。

Kubernetes は、2023 年 3 月 20 日にトラフィックを k8s.gcr.io から registry.k8s.io にリダイレクトしました。Anthos clusters on VMware 1.6.x と 1.7.x では、管理クラスタのアップグレードではコンテナイメージ k8s.gcr.io/pause:3.2 が使用されます。管理ワークステーションにプロキシを使用していて、プロキシで registry.k8s.io が許可されず、コンテナイメージ k8s.gcr.io/pause:3.2 がローカルにキャッシュされていない場合、コンテナイメージを pull するときに管理クラスタのアップグレードが失敗します。

回避策:

registry.k8s.io を管理ワークステーションのプロキシの許可リストに追加します。

ネットワーキング

1.10, 1.11, 1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2

ロードバランサ作成時の Seesaw 検証の失敗

gkectl create loadbalancer が次のエラーメッセージで失敗します。


- Validation Category: Seesaw LB - [FAILURE] Seesaw validation: xxx cluster lb health check failed: LB"xxx.xxx.xxx.xxx" is not healthy: Get "http://xxx.xxx.xxx.xxx:xxx/healthz": dial tcpxxx.xxx.xxx.xxx:xxx: connect: no route to host

これは、Seesaw グループファイルがすでに存在するためです。また、プリフライトチェックは、存在しない Seesaw ロードバランサの検証を試みます。

回避策:

このクラスタの既存の Seesaw グループファイルを削除します。ファイル名は管理クラスタの場合は seesaw-for-gke-admin.yaml、ユーザークラスタの場合は seesaw-for-{CLUSTER_NAME}.yaml になります。

ネットワーキング

1.14

conntrack テーブル挿入エラーによるアプリケーションタイムアウト

Anthos clusters on VMware バージョン 1.14 では、Ubuntu または COS オペレーティングシステムイメージを使用する場合、netfilter 接続トラッキング（conntrack）テーブルの挿入エラーの影響を受けやすくなります。挿入に失敗すると、ランダムなアプリケーションタイムアウトが発生し、conntrack テーブルに新しいエントリ用のスペースがある場合でも発生する可能性があります。この障害は、チェーン長に基づいてテーブルの挿入を制限するカーネル 5.15 以降の変更が原因で発生します。

この問題の影響を受けるかどうかを確認するには、次のコマンドを使用して各ノードのカーネル内接続トラッキングシステムの統計情報を確認します。


sudo conntrack -S

レスポンスは次のようになります。


cpu=0       found=0 invalid=4 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=1       found=0 invalid=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=2       found=0 invalid=16 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=3       found=0 invalid=13 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=4       found=0 invalid=9 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=5       found=0 invalid=1 insert=0 insert_failed=0 drop=0 early_drop=0 error=519 search_restart=0 clash_resolve=126 chaintoolong=0
...

レスポンスの chaintoolong 値がゼロ以外の値である場合、この問題の影響を受けます。

回避策

短期的な緩和策としては、netfiler ハッシュテーブル（nf_conntrack_buckets）と netfilter 接続トラッキングテーブル（nf_conntrack_max）の両方のサイズを増やします。各クラスタノードで次のコマンドを使用して、テーブルのサイズを増やします。


sysctl -w net.netfilter.nf_conntrack_buckets=TABLE_SIZE
sysctl -w net.netfilter.nf_conntrack_max=TABLE_SIZE

TABLE_SIZE は、新しいサイズ（バイト単位）に置き換えます。デフォルトのテーブルサイズの値は 262144 です。ノード上のコア数の 65,536 倍に等しい値を設定することをおすすめします。たとえば、ノードに 8 つのコアがある場合は、テーブルサイズを 524288 に設定します。

ネットワーキング

1.13.0-1.13.2

コントロールプレーン v2 の Windows ノードでの calico-typha または anetd-operator クラッシュループ

コントロールプレーン v2 または新規インストールモデルでは、calico-typha または anetd-operator が Windows ノードにスケジュールされ、クラッシュループに入る可能性があります。

これは、2 つのデプロイで Windows ノード taint を含むすべての taint が容認されるためです。

回避策:

1.13.3 以降にアップグレードするか、次のコマンドを実行して「calico-typha」または「anetd-operator」のデプロイを編集します。


    # If dataplane v2 is not used.
    kubectl edit deployment -n kube-system calico-typha --kubeconfig USER_CLUSTER_KUBECONFIG
    # If dataplane v2 is used.
    kubectl edit deployment -n kube-system anetd-operator --kubeconfig USER_CLUSTER_KUBECONFIG

次の spec.template.spec.tolerations を削除します。


    - effect: NoSchedule
      operator: Exists
    - effect: NoExecute
      operator: Exists

次の toleration を追加します。


    - key: node-role.kubernetes.io/master
      operator: Exists

構成

1.14.0-1.14.2

ユーザークラスタの非公開レジストリの認証情報ファイルを読み込めない

認証情報 fileRef を指定して privateRegistry セクションを指定すると、ユーザークラスタを作成できない場合があります。プリフライトが次のメッセージで失敗する場合があります。


[FAILURE] Docker registry access: Failed to login.

回避策:

このフィールドを指定しなかった場合や、管理クラスタと同じ非公開レジストリの認証情報を使用する場合は、ユーザークラスタ構成ファイルの privateRegistry セクションを削除するか、コメント化します。
ユーザークラスタに特定の非公開レジストリの認証情報を使用する場合は、次のように privateRegistry セクションを一時的に指定します。
```
privateRegistry:
  address: PRIVATE_REGISTRY_ADDRESS
  credentials:
    username: PRIVATE_REGISTRY_USERNAME
    password: PRIVATE_REGISTRY_PASSWORD
  caCertPath: PRIVATE_REGISTRY_CACERT_PATH
```
（注: これは一時的な修正であり、これらのフィールドはすでに非推奨です）。1.14.3 以降にアップグレードする場合は、認証情報ファイルの使用を検討してください）。

運用

1.10+

Dataplane v2 と互換性のない Anthos Service Mesh と他のサービスメッシュ

Dataplane V2 は負荷分散を引き受け、パケットベースの DNAT の代わりにカーネルソケットを作成します。つまり、Pod Service がバイパスされ、IPTable が使用されないため、Anthos Service Mesh はパケット検査を実行できません。

kube-proxy のフリーモードでは、サイドカーがパケット検査を実行できないため、接続が失われるか、Anthos Service Mesh を使用したサービスのトラフィックのルーティングが正しくないことが示されます。

この問題は、ベアメタル版 Anthos クラスタ 1.10 のすべてのバージョンで発生しますが、1.10（1.10.2 以降）のいくつかの新しいバージョンには回避策があります。

回避策:

完全な互換性を確保するために 1.11 にアップグレードするか、1.10.2 以降を実行している場合は次のコマンドを実行します。


    kubectl edit cm -n kube-system cilium-config --kubeconfig USER_CLUSTER_KUBECONFIG

bpf-lb-sock-hostns-only: true を configmap に追加し、anetd DaemonSet を再起動します。


      kubectl rollout restart ds anetd -n kube-system --kubeconfig USER_CLUSTER_KUBECONFIG

ストレージ

1.12+, 1.13.3

`kube-controller-manager` は、6 分後に永続ボリュームを強制的に切断する可能性があります。

kube-controller-manager は、6 分後に PV/PVC を切断するときにタイムアウトし、PV/PVC を強制的に切断します。kube-controller-manager からの詳細なログには、次のようなイベントが表示されます。


$ cat kubectl_logs_kube-controller-manager-xxxx | grep "DetachVolume started" | grep expired

kubectl_logs_kube-controller-manager-gke-admin-master-4mgvr_--container_kube-controller-manager_--kubeconfig_kubeconfig_--request-timeout_30s_--namespace_kube-system_--timestamps:2023-01-05T16:29:25.883577880Z W0105 16:29:25.883446       1 reconciler.go:224] attacherDetacher.DetachVolume started for volume "pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16" (UniqueName: "kubernetes.io/csi/csi.vsphere.vmware.com^126f913b-4029-4055-91f7-beee75d5d34a") on node "sandbox-corp-ant-antho-0223092-03-u-tm04-ml5m8-7d66645cf-t5q8f"
This volume is not safe to detach, but maxWaitForUnmountDuration 6m0s expired, force detaching

問題を確認するには、ノードにログインして次のコマンドを実行します。


# See all the mounting points with disks
lsblk -f

# See some ext4 errors
sudo dmesg -T

kubelet のログに次のようなエラーが表示されます。


Error: GetDeviceMountRefs check failed for volume "pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16" (UniqueName: "kubernetes.io/csi/csi.vsphere.vmware.com^126f913b-4029-4055-91f7-beee75d5d34a") on node "sandbox-corp-ant-antho-0223092-03-u-tm04-ml5m8-7d66645cf-t5q8f" :
the device mount path "/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16/globalmount" is still mounted by other references [/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16/globalmount

回避策:

SSH を使用して該当するノードに接続し、ノードを再起動します。

アップグレードと更新

1.12+, 1.13+, 1.14+

サードパーティの CSI ドライバが使用されていると、クラスタのアップグレードが停止する

サードパーティの CSI ドライバを使用している場合は、クラスタをアップグレードできない場合があります。gkectl cluster diagnose コマンドから次のエラーが返されることがあります。


"virtual disk "kubernetes.io/csi/csi.netapp.io^pvc-27a1625f-29e3-4e4f-9cd1-a45237cc472c" IS NOT attached to machine "cluster-pool-855f694cc-cjk5c" but IS listed in the Node.Status"

回避策:

--skip-validation-all オプションを使用してアップグレードを行います。

オペレーション

1.10+, 1.11+, 1.12+, 1.13+, 1.14+

`gkectl repair admin-master` は、VM ハードウェアのバージョンをアップグレードせずに管理マスター VM を作成します。

gkectl repair admin-master を介して作成された管理マスターノードで、想定よりも低い VM ハードウェアバージョンが使用される場合があります。問題が発生すると、gkectl diagnose cluster レポートからエラーが表示されます。


CSIPrerequisites [VM Hardware]: The current VM hardware versions are lower than vmx-15 which is unexpected. Please contact Anthos support to resolve this issue.

回避策:

管理マスターノードをシャットダウンし、https://kb.vmware.com/s/article/1003746 に従って、エラーで説明されている想定されるバージョンにノードをアップグレードします。メッセージを受け取り、ノードを起動します。

オペレーティングシステム

1.10+, 1.11+, 1.12+, 1.13+, 1.14+, 1.15+

VM がシャットダウンおよび再起動時に DHCP リースを予期せずリリースすると、IP が変更される可能性がある

systemd v244 では、systemd-networkd の KeepConfiguration 構成に対するデフォルトの動作変更があります。この変更前は、VM はシャットダウンまたは再起動時に DHCP リースリリースメッセージを送信しませんでした。この変更後、VM はこのようなメッセージを送信し、DHCP サーバーに IP を返します。その結果、解放された IP が別の VM に再割り当てされたり、異なる IP が VM に割り当てられたりする可能性があります（vSphere レベルではなく Kubernetes レベルで）。 VM の IP 変更（または、さまざまな方法でクラスタが破損する可能性があります）

たとえば、次のような現象が発生する場合があります。

vCenter UI には、同じ IP を使用する VM がないことがわかりますが、

kubectl get
        nodes -o wide

は重複する IP を持つノードを返します。


NAME   STATUS    AGE  VERSION          INTERNAL-IP    EXTERNAL-IP    OS-IMAGE            KERNEL-VERSION    CONTAINER-RUNTIME
node1  Ready     28h  v1.22.8-gke.204  10.180.85.130  10.180.85.130  Ubuntu 20.04.4 LTS  5.4.0-1049-gkeop  containerd://1.5.13
node2  NotReady  71d  v1.22.8-gke.204  10.180.85.130  10.180.85.130  Ubuntu 20.04.4 LTS  5.4.0-1049-gkeop  containerd://1.5.13

calico-node エラーにより新しいノードを起動できない


2023-01-19T22:07:08.817410035Z 2023-01-19 22:07:08.817 [WARNING][9] startup/startup.go 1135: Calico node 'node1' is already using the IPv4 address 10.180.85.130.
2023-01-19T22:07:08.817514332Z 2023-01-19 22:07:08.817 [INFO][9] startup/startup.go 354: Clearing out-of-date IPv4 address from this node IP="10.180.85.130/24"
2023-01-19T22:07:08.825614667Z 2023-01-19 22:07:08.825 [WARNING][9] startup/startup.go 1347: Terminating
2023-01-19T22:07:08.828218856Z Calico node failed to start

回避策:

次の DaemonSet をクラスタにデプロイして、systemd-networkd のデフォルトの動作の変更を元に戻します。この DaemonSet を実行する VM は、シャットダウンや再起動時に DHCP サーバーに IP を解放しません。リースが期限切れになると、IP は DHCP サーバーによって自動的に解放されます。


      apiVersion: apps/v1
      kind: DaemonSet
      metadata:
        name: set-dhcp-on-stop
      spec:
        selector:
          matchLabels:
            name: set-dhcp-on-stop
        template:
          metadata:
            labels:
              name: set-dhcp-on-stop
          spec:
            hostIPC: true
            hostPID: true
            hostNetwork: true
            containers:
            - name: set-dhcp-on-stop
              image: ubuntu
              tty: true
              command:
              - /bin/bash
              - -c
              - |
                set -x
                date
                while true; do
                  export CONFIG=/host/run/systemd/network/10-netplan-ens192.network;
                  grep KeepConfiguration=dhcp-on-stop "${CONFIG}" > /dev/null
                  if (( $? != 0 )) ; then
                    echo "Setting KeepConfiguration=dhcp-on-stop"
                    sed -i '/\[Network\]/a KeepConfiguration=dhcp-on-stop' "${CONFIG}"
                    cat "${CONFIG}"
                    chroot /host systemctl restart systemd-networkd
                  else
                    echo "KeepConfiguration=dhcp-on-stop has already been set"
                  fi;
                  sleep 3600
                done
              volumeMounts:
              - name: host
                mountPath: /host
              resources:
                requests:
                  memory: "10Mi"
                  cpu: "5m"
              securityContext:
                privileged: true
            volumes:
            - name: host
              hostPath:
                path: /
            tolerations:
            - operator: Exists
              effect: NoExecute
            - operator: Exists
              effect: NoSchedule

運用、アップグレード、更新

1.12.0+, 1.13.0+, 1.14.0+

管理クラスタが 1.11.x からアップグレードされた後に、コンポーネントアクセスサービスアカウントキーが消去される

この問題は、1.11.x からアップグレードされた管理クラスタにのみ影響し、1.12 以降に新しく作成された管理クラスタには影響しません。

1.11.x クラスタを 1.12.x にアップグレードすると、admin-cluster-creds シークレットの component-access-sa-key フィールドは空に消去されます。これは、次のコマンドを実行して確認できます。


kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get secret admin-cluster-creds -o yaml | grep 'component-access-sa-key'

出力が空の場合、キーが消去されています。

コンポーネントアクセスサービスアカウントキーが削除された後、新しいユーザークラスタのインストールまたは既存のユーザークラスタのアップグレードは失敗します。発生する可能性のあるエラーメッセージの一部を以下に示します。

検証プリフライトが遅い（エラーメッセージ: "Failed to create the test VMs: failed to get service account key: service account is not configured."）
gkectl prepare により準備に失敗し、エラーメッセージ "Failed to prepare OS images: dialing: unexpected end of JSON input" が表示されました。
Google Cloud Console または gcloud CLI を使用して 1.13 ユーザークラスタをアップグレードする場合は、gkectl update admin --enable-preview-user-cluster-central-upgrade を実行してアップグレードプラットフォームコントローラをデプロイすると、コマンドが失敗し、次のメッセージが表示されます。"failed to download bundle to disk: dialing: unexpected end of JSON input"（このメッセージは、kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get onprembundle -oyaml の出力の status フィールドで確認できます）

回避策:

次のコマンドを実行して、コンポーネントアクセスサービスアカウントキーを手動で Secret に追加し直します。


kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get secret admin-cluster-creds -ojson | jq --arg casa "$(cat COMPONENT_ACESS_SERVICE_ACOOUNT_KEY_PATH | base64 -w 0)" '.data["component-access-sa-key"]=$casa' | kubectl --kubeconfig ADMIN_KUBECONFIG apply -f -

オペレーション

1.13.0+, 1.14.0+

コントロールプレーン V2 が有効な場合、クラスタオートスケーラーが動作しない

次のコマンドで作成されたユーザークラスタの場合コントロールプレーン V2または新しいインストールモデル、ノードプール自動スケーリング常にautoscaling.minReplicas （user-cluster.yaml 内）。クラスタオートスケーラー Pod のログには、異常状態の Pod も表示されます。


  > kubectl --kubeconfig $USER_CLUSTER_KUBECONFIG -n kube-system \
  logs $CLUSTER_AUTOSCALER_POD --container_cluster-autoscaler
 TIMESTAMP  1 gkeonprem_provider.go:73] error getting onpremusercluster ready status: Expected to get a onpremusercluster with id foo-user-cluster-gke-onprem-mgmt/foo-user-cluster
 TIMESTAMP 1 static_autoscaler.go:298] Failed to get node infos for groups: Expected to get a onpremusercluster with id foo-user-cluster-gke-onprem-mgmt/foo-user-cluster

クラスタオートスケーラー Pod を確認するには、次のコマンドを実行します。


  > kubectl --kubeconfig $USER_CLUSTER_KUBECONFIG -n kube-system \
   get pods | grep cluster-autoscaler
cluster-autoscaler-5857c74586-txx2c                          4648017n    48076Ki    30s

回避策:

修正したバージョンにアップグレードするまで、「gkectl update cluster」を使用してすべてのノードプールで自動スケーリングを無効にする

インストール

1.12.0-1.12.4, 1.13.0-1.13.3, 1.14.0

CIDR ブロックファイルで CIDR は使用できません。

ユーザーが IP ブロックファイルで CIDR を使用すると、次の検証で構成の検証は失敗します。


- Validation Category: Config Check
    - [FAILURE] Config: AddressBlock for admin cluster spec is invalid: invalid IP:
172.16.20.12/30

回避策:

修正を伴うバージョン 1.12.5、1.13.4、1.14.1 以降にアップグレードするまで、IP ブロックファイルに個々の IP を含めます。

アップグレードと更新

1.14.0-1.14.1

admin-cluster.yaml の OS イメージタイプの更新は、ユーザーコントロールプレーンのマシンが再作成されるのを待機しない

admin-cluster.yaml でコントロールプレーンの OS イメージタイプを更新するときに、対応するユーザークラスタがコントロールプレーン V2 を介して作成された場合、ユーザーコントロールプレーンのマシンが gkectl コマンドが終了したときの再作成

回避策:

更新が完了したら、ユーザーコントロールプレーンのマシンが kubectl --kubeconfig USER_KUBECONFIG get nodes -owide を使用してノード OS のイメージタイプをモニタリングして再作成を完了するのを待ちます。Ubuntu から COS に更新する場合、更新コマンドが完了した後も、すべてのコントロールプレーンマシンが Ubuntu から COS に完全に変更されるまで待つ必要があります。

オペレーション

1.14.0

Calico CNI サービスアカウントの認証トークンの問題による Pod の作成または削除エラー

Anthos clusters on VMware 1.14.0 の Calico に関する問題により、Pod の作成と削除が失敗し、kubectl describe pods の出力に次のエラーメッセージが表示されます。


  error getting ClusterInformation: connection is unauthorized: Unauthorized

この問題は、クラスタが Calico を使用して 1.14 で作成または 1.14 にアップグレードされてから 24 時間以内にのみ確認されます。

管理クラスタは常に Calico を使用しますが、ユーザークラスタでは、user-cluster.yaml に config フィールド「enableDataPlaneV2」があります。このフィールドが false に設定されているか、指定されていない場合、ユーザークラスタで Calico を使用します。

ノードの install-cni コンテナは、24 時間有効なトークンで kubeconfig を作成します。このトークンは、calico-node Pod によって定期的に更新する必要があります。calico-node Pod がノード上の kubeconfig ファイルを含むディレクトリにアクセスできないため、トークンを更新できません。

回避策:

この問題を軽減するには、管理クラスタとユーザークラスタの calico-node DaemonSet に次のパッチを適用します。


  kubectl -n kube-system get daemonset calico-node \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG -o json \
    | jq '.spec.template.spec.containers[0].volumeMounts += [{"name":"cni-net-dir","mountPath":"/host/etc/cni/net.d"}]' \
    | kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f -

  kubectl -n kube-system get daemonset calico-node \
    --kubeconfig USER_CLUSTER_KUBECONFIG -o json \
    | jq '.spec.template.spec.containers[0].volumeMounts += [{"name":"cni-net-dir","mountPath":"/host/etc/cni/net.d"}]' \
    | kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f -

以下を置き換えます。

ADMIN_CLUSTER_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス
USER_CLUSTER_CONFIG_FILE: ユーザークラスタの構成ファイルのパス

インストール

1.12.0-1.12.4, 1.13.0-1.13.3, 1.14.0

CIDR を使用すると IP ブロックの検証が失敗する

ユーザーが適切な構成を持っていても、クラスタの作成に失敗します。クラスタに十分な IP がないため、作成に失敗する。

回避策:

CIDR をいくつかの小さな CIDR ブロックに分割します。次に例を示します。10.0.0.0/30以下のようになります。10.0.0.0/31, 10.0.0.2/31N+1 CIDR がある場合（N はクラスタ内のノードの数）、これで十分です。

運用、アップグレード、更新

1.11.0 - 1.11.1, 1.10.0 - 1.10.4, 1.9.0 - 1.9.6

管理クラスタのバックアップには、常時オンのシークレット暗号鍵と構成は含まれていません

クラスタのバックアップとともに常時オンのシークレット暗号化機能が有効になっている場合、管理クラスタのバックアップには、常時オンのシークレット暗号化機能に必要な暗号鍵と構成が含まれません。そのため、gkectl repair admin-master --restore-from-backup を使用してこのバックアップで管理マスターを修復すると、次のエラーが発生します。


Validating admin master VM xxx ...
Waiting for kube-apiserver to be accessible via LB VIP (timeout "8m0s")...  ERROR
Failed to access kube-apiserver via LB VIP. Trying to fix the problem by rebooting the admin master
Waiting for kube-apiserver to be accessible via LB VIP (timeout "13m0s")...  ERROR
Failed to access kube-apiserver via LB VIP. Trying to fix the problem by rebooting the admin master
Waiting for kube-apiserver to be accessible via LB VIP (timeout "18m0s")...  ERROR
Failed to access kube-apiserver via LB VIP. Trying to fix the problem by rebooting the admin master

回避策:

対応するマイナーバージョンの利用可能なパッチバージョンの gkectl バイナリを使用して、重要なクラスタオペレーションの後に管理クラスタのバックアップを実行します。たとえば、クラスタで 1.10.2 バージョンが実行されている場合は、gkectl を使用して管理クラスタをバックアップおよび復元するの説明に従って、1.10.5 gkectl バイナリを使用して手動管理クラスタのバックアップを行います。

運用、アップグレード、更新

1.10+

管理マスター VM の新しいブートディスク（たとえば`gkectl repair admin-master`）は、gkectl update コマンドを使用して常時オンシークレット暗号化機能が有効になっている場合に失敗します。

クラスタ作成時に常時オンのシークレット暗号化機能が有効になっていないが、後で gkectl update オペレーションを使用して有効になっている場合、gkectl repair admin-master は管理クラスタのコントロールプレーンノードを修復できません。クラスタの作成時に常時オンのシークレット暗号化機能を有効にすることをおすすめします。現在、緩和策はありません。

アップグレードと更新

1.10

最初のユーザークラスタを 1.9 から 1.10 にアップグレードすると、他のユーザークラスタのノードを再作成します

最初のユーザークラスタを 1.9 から 1.10 にアップグレードすると、同じ管理クラスタにある他のユーザークラスタ内のノードが再作成される可能性があります。この再作成は、ローリング方式で行われます。

disk_label が MachineTemplate.spec.template.spec.providerSpec.machineVariables から削除され、すべての MachineDeployment で予期せず更新がトリガーされました。

回避策:

回避策を表示する

すべてのユーザークラスタの clusterapi-controllers のレプリカを 0 にスケールダウンします。


kubectl scale --replicas=0 -n=USER_CLUSTER_NAME deployment/clusterapi-controllers --kubeconfig ADMIN_CLUSTER_KUBECONFIG

各ユーザークラスタを 1 つずつアップグレードします。

アップグレードと更新

1.10.0

クラスタのアップグレード後に Docker が頻繁に再起動する

ユーザークラスタを 1.10.0 にアップグレードすると、Docker が頻繁に再起動することがあります。

この問題は、kubectl describe node NODE_NAME --kubeconfig USER_CLUSTER_KUBECONFIG を実行して検出できます。

ノードの条件で、Docker が頻繁に再起動するかどうかが示されます。出力の例を次に示します。


Normal   FrequentDockerRestart    41m (x2 over 141m)     systemd-monitor  Node condition FrequentDockerRestart is now: True, reason: FrequentDockerRestart

根本原因を理解するには、症状のあるノードに SSH で接続し、sudo journalctl --utc -u docker や sudo journalctl -x などのコマンドを実行する必要があります。

回避策:

コンテナランタイムに containerd を使用する
クラスタを最新バージョン 1.10 にアップグレードします。

アップグレードと更新

1.11, 1.12

バージョン 1.12 へのアップグレード後に自己デプロイ型 GMP コンポーネントが保持されない

バージョン 1.12 より前の Anthos clusters on VMware を使用していて、クラスタの gmp-system 名前空間に Google が管理する Prometheus（GMP）コンポーネントを手動で設定している場合、コンポーネントは次のようになります。バージョン 1.12.x にアップグレードすると、保持されません。

バージョン 1.12 より、gmp-system名前空間と CRD は、デフォルトでは、enableGMPForApplicationsフラグをfalse に設定してstackdriverオブジェクトで管理されます。1.12 にアップグレードする前に Namespace に GMP コンポーネントを手動でデプロイすると、stackdriver によってリソースが削除されます。

回避策:

既存のすべての PodMonitoring カスタムリソース（CR）をバックアップします。
すべてのクラスタをバージョン 1.12 にアップグレードし、Prometheus のマネージドサービスを有効にします。
PodMonitoring CR を再デプロイします。

オペレーション

1.11, 1.12, 1.13.0 - 1.13.1

クラスタスナップショットの `system` シナリオに ClusterAPI オブジェクトがない

system シナリオでは、クラスタスナップショットに default 名前空間のリソースは含まれません。

ただし、この名前空間の下にある Cluster API オブジェクトなどの一部の Kubernetes リソースには、有用なデバッグ情報が含まれています。クラスタスナップショットには、それらが含まれている必要があります。

回避策:

次のコマンドを手動で実行して、デバッグ情報を収集できます。


export KUBECONFIG=USER_CLUSTER_KUBECONFIG
kubectl get clusters.cluster.k8s.io -o yaml
kubectl get controlplanes.cluster.k8s.io -o yaml
kubectl get machineclasses.cluster.k8s.io -o yaml
kubectl get machinedeployments.cluster.k8s.io -o yaml
kubectl get machines.cluster.k8s.io -o yaml
kubectl get machinesets.cluster.k8s.io -o yaml
kubectl get services -o yaml
kubectl describe clusters.cluster.k8s.io
kubectl describe controlplanes.cluster.k8s.io
kubectl describe machineclasses.cluster.k8s.io
kubectl describe machinedeployments.cluster.k8s.io
kubectl describe machines.cluster.k8s.io
kubectl describe machinesets.cluster.k8s.io
kubectl describe services

ここで

USER_CLUSTER_KUBECONFIG は、ユーザークラスタの kubeconfig ファイルです。

アップグレードと更新

1.11.0-1.11.4, 1.12.0-1.12.3, 1.13.0-1.13.1

vSAN の設定でユーザークラスタの削除がノードのドレインから先に進まない

ユーザークラスタを削除、更新、アップグレードすると、次の場合にノードのドレインが停止することがあります。

バージョン 1.12.x 以降、管理クラスタが vSAN で vSphere CSI ドライバを使用している
管理クラスタとユーザークラスタに in-tree vSphere プラグインによって作成された PVC/PV オブジェクトはありません。

症状を特定するには、次のコマンドを実行します。


kubectl logs clusterapi-controllers-POD_NAME_SUFFIX  --kubeconfig ADMIN_KUBECONFIG -n USER_CLUSTER_NAMESPACE

以下は、上記のコマンドのエラーメッセージの例です。


E0920 20:27:43.086567 1 machine_controller.go:250] Error deleting machine object [MACHINE]; Failed to delete machine [MACHINE]: failed to detach disks from VM "[MACHINE]": failed to convert disk path "kubevols" to UUID path: failed to convert full path "ds:///vmfs/volumes/vsan:[UUID]/kubevols": ServerFaultCode: A general system error occurred: Invalid fault

kubevols は、vSphere in-tree ドライバのデフォルトディレクトリです。作成された PVC/PV オブジェクトがない場合、現在の実装では kubevols が常に存在すると想定されているため、kubevols の検出でノードのドレインが停止します。

回避策:

ノードを作成するデータストアにディレクトリ kubevols を作成します。これは、user-cluster.yaml または admin-cluster.yaml ファイルの vCenter.datastore フィールドで定義されます。

構成

1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13, 1.14

`Cluster Autoscaler` クラスタロールバインディングとクラスタロールは、ユーザークラスタを削除した後に削除されます。

ユーザークラスタの削除時に、クラスタオートスケーラーの対応する clusterrole と clusterrolebinding も削除されます。これは、クラスタオートスケーラーが有効になっている同じ管理クラスタ上のすべてのユーザークラスタに影響します。これは、同じ管理クラスタ内のすべてのクラスタオートスケーラー Pod に同じ clusterrole と clusterrolebinding が使用されるためです。

症状には次のようなものがあります。

cluster-autoscaler ログ


kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
cluster-autoscaler

ADMIN_CLUSTER_KUBECONFIG


2023-03-26T10:45:44.866600973Z W0326 10:45:44.866463       1 reflector.go:424] k8s.io/client-go/dynamic/dynamicinformer/informer.go:91: failed to list *unstructured.Unstructured: onpremuserclusters.onprem.cluster.gke.io is forbidden: User "..." cannot list resource "onpremuserclusters" in API group "onprem.cluster.gke.io" at the cluster scope
2023-03-26T10:45:44.866646815Z E0326 10:45:44.866494       1 reflector.go:140] k8s.io/client-go/dynamic/dynamicinformer/informer.go:91: Failed to watch *unstructured.Unstructured: failed to list *unstructured.Unstructured: onpremuserclusters.onprem.cluster.gke.io is forbidden: User "..." cannot list resource "onpremuserclusters" in API group "onprem.cluster.gke.io" at the cluster scope

回避策:

回避策を表示する

クラスタロールとクラスタロールバインディングが管理クラスタにないかどうかを確認する


kubectl get clusterrolebindings --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system | grep cluster-autoscaler


kubectl get clusterrole --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system | grep cluster-autoscaler

次の clusterrole と clusterrolebind と管理クラスタに適用される場合は、それらを適用します。各ユーザークラスタの clusterrolebind にサービスアカウントサブジェクトを追加します。


apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-autoscaler
rules:
- apiGroups: ["cluster.k8s.io"]
  resources: ["clusters"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["cluster.k8s.io"]
  resources: ["machinesets","machinedeployments", "machinedeployments/scale","machines"]
  verbs: ["get", "list", "watch", "update", "patch"]
- apiGroups: ["onprem.cluster.gke.io"]
  resources: ["onpremuserclusters"]
  verbs: ["get", "list", "watch"]
- apiGroups:
  - coordination.k8s.io
  resources:
  - leases
  resourceNames: ["cluster-autoscaler"]
  verbs:
  - get
  - list
  - watch
  - create
  - update
  - patch
- apiGroups:
  - ""
  resources:
  - nodes
  verbs: ["get", "list", "watch", "update", "patch"]
- apiGroups:
  - ""
  resources:
  - pods
  verbs: ["get", "list", "watch"]
- apiGroups:
  - ""
  resources:
  - pods/eviction
  verbs: ["create"]
# read-only access to cluster state
- apiGroups: [""]
  resources: ["services", "replicationcontrollers", "persistentvolumes", "persistentvolumeclaims"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
  resources: ["daemonsets", "replicasets"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
  resources: ["statefulsets"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["batch"]
  resources: ["jobs"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["policy"]
  resources: ["poddisruptionbudgets"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["storage.k8s.io"]
  resources: ["storageclasses", "csinodes"]
  verbs: ["get", "list", "watch"]
# misc access
- apiGroups: [""]
  resources: ["events"]
  verbs: ["create", "update", "patch"]
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["create"]
- apiGroups: [""]
  resources: ["configmaps"]
  resourceNames: ["cluster-autoscaler-status"]
  verbs: ["get", "update", "patch", "delete"]


apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  labels:
    k8s-app: cluster-autoscaler
  name: cluster-autoscaler
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-autoscaler
subjects:
  - kind: ServiceAccount
  name: cluster-autoscaler
  namespace:  NAMESPACE_OF_USER_CLUSTER_1 
  - kind: ServiceAccount
  name: cluster-autoscaler
  namespace:  NAMESPACE_OF_USER_CLUSTER_2 
  ...

構成

1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13

ユーザークラスタの削除後に管理クラスタ `cluster-health-controller` と `vsphere-metrics-exporter` が機能しない

ユーザークラスタを削除すると、対応する clusterrole も削除されるため、自動修復と vSphere 指標のエクスポータが動作しない

症状には次のようなものがあります。

cluster-health-controller ログ


kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
cluster-health-controller

ADMIN_CLUSTER_KUBECONFIG


error retrieving resource lock default/onprem-cluster-health-leader-election: configmaps "onprem-cluster-health-leader-election" is forbidden: User "system:serviceaccount:kube-system:cluster-health-controller" cannot get resource "configmaps" in API group "" in the namespace "default": RBAC: clusterrole.rbac.authorization.k8s.io "cluster-health-controller-role" not found

vsphere-metrics-exporter ログ


kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
vsphere-metrics-exporter

ADMIN_CLUSTER_KUBECONFIG


vsphere-metrics-exporter/cmd/vsphere-metrics-exporter/main.go:68: Failed to watch *v1alpha1.Cluster: failed to list *v1alpha1.Cluster: clusters.cluster.k8s.io is forbidden: User "system:serviceaccount:kube-system:vsphere-metrics-exporter" cannot list resource "clusters" in API group "cluster.k8s.io" in the namespace "default"

回避策:

回避策を表示する

次の YAML を管理クラスタに適用します。

vsphere-metrics-exporter の場合


kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: vsphere-metrics-exporter
rules:
  - apiGroups:
      - cluster.k8s.io
    resources:
      - clusters
    verbs: [get, list, watch]
  - apiGroups:
      - ""
    resources:
      - nodes
    verbs: [get, list, watch]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  labels:
    k8s-app: vsphere-metrics-exporter
  name: vsphere-metrics-exporter
  namespace: kube-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: vsphere-metrics-exporter
subjects:
  - kind: ServiceAccount
    name: vsphere-metrics-exporter
    namespace: kube-system

cluster-health-controller


apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-health-controller-role
rules:
- apiGroups:
  - "*"
  resources:
  - "*"
  verbs:
  - "*"

構成

1.12.1-1.12.3, 1.13.0-1.13.2

`gkectl check-config` が OS イメージの検証で失敗する

gkectl prepare を実行せずに gkectl check-config が失敗する可能性がある既知の問題。gkectl prepare を実行する前にコマンドを実行することをおすすめします。

この場合、gkectl check-config コマンドは次のエラーメッセージで失敗します。


Validator result: {Status:FAILURE Reason:os images [OS_IMAGE_NAME] don't exist, please run `gkectl prepare` to upload os images. UnhealthyResources:[]}

回避策:

オプション 1: gkectl prepare を実行して、欠落している OS イメージをアップロードします。

オプション 2: gkectl check-config --skip-validation-os-images を使用して OS イメージの検証をスキップする

アップグレードと更新

1.11, 1.12, 1.13

アンチアフィニティグループの更新に `gkectl update admin/cluster` が失敗する

anti affinity groups の更新時に gkectl update admin/cluster が失敗する可能性がある既知の問題。

この場合、gkectl update コマンドは次のエラーメッセージで失敗します。


Waiting for machines to be re-deployed...  ERROR
Exit with error:
Failed to update the cluster: timed out waiting for the condition

回避策:

回避策を表示する

更新を有効にするには、after が失敗した更新をマシンに再作成する必要があります。

管理クラスタを更新する場合は、ユーザーマスターノードと管理アドオンノードを再作成する必要があります

ユーザークラスタを更新する場合は、ユーザーワーカーノードを再作成する必要があります。

ユーザーワーカーノードを再作成するには

オプション 1
ノードプールの更新に沿って、CPU またはメモリを変更して、ノードのローリング再作成をトリガーします。

オプション 2
kubectl delete を使用してマシンを 1 つずつ再作成する


kubectl delete machines MACHINE_NAME --kubeconfig USER_KUBECONFIG

ユーザーマスターノードを再作成するには

オプション 1
コントロールプレーンのサイズを変更して、CPU またはメモリを変更して、ノードのローリング再作成をトリガーします。

オプション 2
kubectl delete を使用してマシンを 1 つずつ再作成する


kubectl delete machines MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG

管理アドオンノードを再作成するには

kubectl delete を使用してマシンを 1 つずつ再作成する


kubectl delete machines MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG

インストール、アップグレード、更新

1.13.0-1.13.8, 1.14.0-1.14.4, 1.15.0

構成されたホスト名にピリオドが含まれている場合はノードの登録に失敗する

クラスタの作成、アップグレード、更新、およびノードの自動修復時に、ipMode.type　が　staticで、IP ブロックファイルの設定ホスト名にピリオドが 1 つ以上含まれている場合に、ノードの登録に失敗します。この場合、ノードの証明書署名リクエスト（CSR）は自動的に承認されません。

ノードの保留中の CSR を表示するには、次のコマンドを実行します。


kubectl get csr -A -o wide

次のログでエラーメッセージを確認します。

管理クラスタ内のログで、clusterapi-controllers Pod の clusterapi-controller-manager コンテナのログを表示します。


kubectl logs clusterapi-controllers-POD_NAME \
    -c clusterapi-controller-manager -n kube-system \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

ユーザークラスタ内の同じログを表示するには、次のコマンドを実行します。
```
kubectl logs clusterapi-controllers-POD_NAME \
    -c clusterapi-controller-manager -n USER_CLUSTER_NAME \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG
```
ここで
- ADMIN_CLUSTER_KUBECONFIG は、管理クラスタの kubeconfig ファイルです。
- USER_CLUSTER_NAME は、ユーザークラスタの名前です。
表示される可能性のあるエラーメッセージの例を次に示します。"msg"="failed to validate token id" "error"="failed to find machine for node node-worker-vm-1" "validate"="csr-5jpx9"
問題ノード上の kubelet ログを表示します。
```
journalctl --u kubelet
```
表示されるエラーメッセージの例を次に示します。"Error getting node" err="node \"node-worker-vm-1\" not found"

IP ブロックファイルのホスト名フィールドにドメイン名を指定した場合、最初のピリオドに続く文字はすべて無視されます。たとえば、ホスト名を bob-vm-1.bank.plc として指定した場合、VM ホスト名とノード名は bob-vm-1 に設定されます。

ノード ID の確認が有効になっている場合、CSR 承認者はノード名をマシン仕様のホスト名と比較し、名前の調整に失敗します。承認者が CSR を拒否し、ノードがブートストラップに失敗します。

回避策:

ユーザークラスタ

ノード ID の確認を無効にするには、次の手順を行います。

ユーザークラスタの構成ファイルに次のフィールドを追加します。
```
disableNodeIDVerification: true
disableNodeIDVerificationCSRSigning: true
```
ファイルを保存し、次のコマンドを実行してユーザークラスタを更新します。
```
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG_FILE
```
以下を置き換えます。
- ADMIN_CLUSTER_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス
- USER_CLUSTER_CONFIG_FILE: ユーザークラスタの構成ファイルのパス

管理クラスタ

OnPremAdminCluster カスタムリソースを開いて編集します。


kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    edit onpremadmincluster -n kube-system

次のアノテーションをカスタムリソースに追加します。
```
features.onprem.cluster.gke.io/disable-node-id-verification: enabled
```
管理クラスタのコントロールプレーンで kube-controller-manager マニフェストを編集します。
1. 管理クラスタのコントロールプレーンノードに SSH で接続します。
2. kube-controller-manager マニフェストを編集用に開きます。
```
sudo vi /etc/kubernetes/manifests/kube-controller-manager.yaml
```
3. controllers のリストを見つけます。
```
--controllers=*,bootstrapsigner,tokencleaner,-csrapproving,-csrsigning
```
4. このセクションを以下のように更新します。
```
--controllers=*,bootstrapsigner,tokencleaner
```

Deployment Cluster API コントローラを開いて編集します。


kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    edit deployment clusterapi-controllers -n kube-system

node-id-verification-enabled と node-id-verification-csr-signing-enabled の値を false に変更します。
```
--node-id-verification-enabled=false
--node-id-verification-csr-signing-enabled=false
```

インストール、アップグレード、更新

1.11.0-1.11.4

プライベートレジストリ証明書バンドルによる管理コントロールプレーンマシンの起動の失敗

管理クラスタの作成 / アップグレードは次のログで恒久的に停止し、最終的にタイムアウトになります。


Waiting for Machine gke-admin-master-xxxx to become ready...

外部クラスタスナップショットの Cluster API コントローラのログには、次のログが含まれます。


Invalid value 'XXXX' specified for property startup-data

Cluster API コントローラログのファイルパスの例を次に示します。


kubectlCommands/kubectl_logs_clusterapi-controllers-c4fbb45f-6q6g6_--container_vsphere-controller-manager_--kubeconfig_.home.ubuntu..kube.kind-config-gkectl_--request-timeout_30s_--namespace_kube-system_--timestamps
    VMware has a 64k vApp property size limit. In the identified versions,
    the data passed via vApp property is close to the limit. When the private
    registry certificate contains a certificate bundle, it may cause the final
    data to exceed the 64k limit.
    
Workaround:
    Only include the required certificates in the private registry
    certificate file configured in privateRegistry.caCertPath in
    the admin cluster config file.
    Or upgrade to a version with the fix when available.

ネットワーキング

1.10, 1.11.0-1.11.3, 1.12.0-1.12.2, 1.13.0

`NetworkGatewayNodes`同時ステータス更新の競合状態から NetworkGatewayNode が異常とマークされる

networkgatewaygroups.status.nodes で、一部のノードが NotHealthy と Up で切り替わります。

そのノードで実行されている ang-daemon Pod のログに、次のようなエラーが繰り返し表示されます。


2022-09-16T21:50:59.696Z ERROR ANGd Failed to report status {"angNode": "kube-system/my-node", "error": "updating Node CR status: sending Node CR update: Operation cannot be fulfilled on networkgatewaynodes.networking.gke.io \"my-node\": the object has been modified; please apply your changes to the latest version and try again"}

NotHealthy ステータスにより、コントローラで追加のフローティング IP がノードに割り当てられなくなります。これにより、他のノードへの負荷が増加したり、高可用性の冗長性が失われる可能性があります。

それ以外の場合、データプレーンのアクティビティは影響を受けません。

networkgatewaygroup オブジェクトで競合が発生すると、再試行処理の不具合により、一部のステータス更新が失敗します。ステータス更新の失敗が多すぎると、ang-controller-manager はノードがそのハートビート時間の上限を超えたとみなし、ノードを NotHealthy としてマークします。

再試行処理の不具合は、以降のバージョンで修正されています。

回避策:

利用可能な場合は、修正されたバージョンにアップグレードします。

アップグレードと更新

1.12.0-1.12.2, 1.13.0

競合状態は、更新中または更新中にマシンオブジェクトの削除をブロックする

古いマシンオブジェクトの削除を待機しているときに、クラスタのアップグレードまたは更新が停止する場合がある既知の問題。これは、マシンオブジェクトからファイナライザを削除できないためです。これは、ノードプールのローリングアップデートオペレーションに影響します。

この場合、gkectl コマンドが次のエラーメッセージでタイムアウトします。


E0821 18:28:02.546121   61942 console.go:87] Exit with error:
E0821 18:28:02.546184   61942 console.go:87] error: timed out waiting for the condition, message: Node pool "pool-1" is not ready: ready condition is not true: CreateOrUpdateNodePool: 1/3 replicas are updated
Check the status of OnPremUserCluster 'cluster-1-gke-onprem-mgmt/cluster-1' and the logs of pod 'kube-system/onprem-user-cluster-controller' for more detailed debugging information.

clusterapi-controller Pod のログに、次のようなエラーが表示されます。


$ kubectl logs clusterapi-controllers-[POD_NAME_SUFFIX] -n cluster-1
    -c vsphere-controller-manager --kubeconfig [ADMIN_KUBECONFIG]
    | grep "Error removing finalizer from machine object"
[...]
E0821 23:19:45.114993       1 machine_controller.go:269] Error removing finalizer from machine object cluster-1-pool-7cbc496597-t5d5p; Operation cannot be fulfilled on machines.cluster.k8s.io "cluster-1-pool-7cbc496597-t5d5p": the object has been modified; please apply your changes to the latest version and try again

このバグがなくても、実行が成功した場合でも、同じマシンでエラーが数分間繰り返されます。ほとんどの場合、エラーはすぐに解決しますが、まれに、この競合状態で数時間スタックすることがあります。

問題は、基盤となる VM がすでに vCenter で削除されているのに、対応するマシンオブジェクトを削除できないということです。これは、他のコントローラからの更新が頻繁に発生するため、ファイナライザの削除時に停止します。その結果、gkectl コマンドがタイムアウトする可能性がありますが、コントローラはクラスタを調整し続けるため、アップグレードまたは更新の処理は最終的に完了します。

回避策:

Google では、この問題を回避するさまざまなオプションを用意しています。これは、環境と要件によって異なります。

オプション 1: 自動的にアップグレードが完了するまで待ちます。

環境内の分析と再現に基づいて、手動による介入を行うことなく、最終的にアップグレードを単独で完了できます。このオプションの注意点は、各マシンオブジェクトに対してファイナライザの削除に要する時間が不明であることです。この処理は、運が良ければ直ちに行われる可能性があります。また、マシンセットコントローラの調整が過度に高速で処理され、マシンコントローラが調整の間にファイナライザを削除する機会を得られない状況になると、数時間にわたり続行される可能性があります。

この選択肢の優れている点は、お客様側で操作する必要がなく、ワークロードが中断されないことです。アップグレードが完了するまで、さらに時間がかかります。
オプション 2: 古いすべてのマシンオブジェクトに自動修復アノテーションを適用する。

マシンセットコントローラは、自動修復のアノテーションが付加されており削除タイムスタンプがゼロ以外のマシンを除外し、それらのマシンに対して削除呼び出しを行うことを繰り返しません。これにより、競合状態を回避できます。

デメリットは、マシン上の Pod が強制排除されるのではなく、直接削除されるため、PDB 構成が考慮されないため、ダウンタイムが発生する可能性があります。。

すべてのマシン名を取得するコマンド:
```
kubectl --kubeconfig CLUSTER_KUBECONFIG get machines
```
各マシンの自動修復アノテーションを適用するコマンド。
```
kubectl annotate --kubeconfig CLUSTER_KUBECONFIG \
    machine MACHINE_NAME \
    onprem.cluster.gke.io/repair-machine=true
```

この問題が発生して、アップグレードや更新が長期間完了しない場合は、緩和策についてサポートチームにお問い合わせください。

インストール、アップグレード、更新

1.10.2, 1.11, 1.12, 1.13

`gkectl`　gkectl prepare OS イメージ検証のプリフライトの失敗

gkectl prepare コマンドが次のエラーで失敗しました。


- Validation Category: OS Images
    - [FAILURE] Admin cluster OS images exist: os images [os_image_name] don't exist, please run `gkectl prepare` to upload os images.

gkectl prepare のプリフライトチェックに誤った検証が含まれていました。

回避策:

フラグ --skip-validation-os-images を追加して、同じコマンドを実行します。

インストール

1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13

`https://` 接頭辞または `http://` 接頭辞を持つ vCenter URL はクラスタの起動エラーを引き起こす可能性がある

次のエラーで管理クラスタの作成に失敗しました。


Exit with error:
Failed to create root cluster: unable to apply admin base bundle to external cluster: error: timed out waiting for the condition, message:
Failed to apply external bundle components: failed to apply bundle objects from admin-vsphere-credentials-secret 1.x.y-gke.z to cluster external: Secret "vsphere-dynamic-credentials" is invalid:
[data[https://xxx.xxx.xxx.username]: Invalid value: "https://xxx.xxx.xxx.username": a valid config key must consist of alphanumeric characters, '-', '_' or '.'
(e.g. 'key.name', or 'KEY_NAME', or 'key-name', regex used for validation is '[-._a-zA-Z0-9]+'), data[https://xxx.xxx.xxx.password]:
Invalid value: "https://xxx.xxx.xxx.password": a valid config key must consist of alphanumeric characters, '-', '_' or '.'
(e.g. 'key.name', or 'KEY_NAME', or 'key-name', regex used for validation is '[-._a-zA-Z0-9]+')]

この URL は秘密鍵の一部として使用されており、「/」や「:」はサポートされていません。

回避策:

管理クラスタまたはユーザークラスタの構成 yaml の vCenter.Address フィールドから、https:// 接頭辞または http:// 接頭辞を削除します。

インストール、アップグレード、更新

1.10, 1.11, 1.12, 1.13

`util.CheckFileExists` の `gkectl prepare` のパニック

gkectl prepare が次のスタックトレースでパニックする可能性があります。


panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0xde0dfa]

goroutine 1 [running]:
gke-internal.googlesource.com/syllogi/cluster-management/pkg/util.CheckFileExists(0xc001602210, 0x2b, 0xc001602210, 0x2b) pkg/util/util.go:226 +0x9a
gke-internal.googlesource.com/syllogi/cluster-management/gkectl/pkg/config/util.SetCertsForPrivateRegistry(0xc000053d70, 0x10, 0xc000f06f00, 0x4b4, 0x1, 0xc00015b400)gkectl/pkg/config/util/utils.go:75 +0x85
...

gkectl prepare が非公開レジストリ証明書ディレクトリを誤った権限で作成したことが問題でした。

回避策:

この問題を解決するには、管理ワークステーションで次のコマンドを実行します。


sudo mkdir -p /etc/docker/certs.d/PRIVATE_REGISTRY_ADDRESS
sudo chmod 0755 /etc/docker/certs.d/PRIVATE_REGISTRY_ADDRESS

アップグレードと更新

1.10, 1.11, 1.12, 1.13

`gkectl repair admin-master` と再開可能な管理者アップグレードは連携しません

管理クラスタのアップグレード試行に失敗した場合は、gkectl repair admin-master を実行しないでください。これを行うと、以降の管理アップグレードの試行が失敗し、管理マスターの電源障害や VM にアクセスできないなどの問題が発生する可能性があります。

回避策:

この障害のシナリオがすでに発生している場合は、サポートにお問い合わせください。

アップグレードと更新

1.10, 1.11

管理クラスタのアップグレードを再開すると、管理コントロールプレーンの VM テンプレートがなくなる可能性がある

管理クラスタのアップグレードの再開後に管理コントロールプレーンのマシンが再作成されない場合、管理コントロールプレーンの VM テンプレートは削除されます。管理コントロールプレーン VM のテンプレートは、gkectl repair admin-master でコントロールプレーンマシンを復元するために使用される管理マスターのテンプレートです。

回避策:

管理コントロールプレーンの VM テンプレートは、次回の管理クラスタのアップグレード時に再生成されます。

オペレーティングシステム

1.12, 1.13

cgroup v2 がワークロードに影響する可能性がある

バージョン 1.12.0 では、Container-Optimized OS（COS）ノードに対して、cgroup v2（統合型）がデフォルトで有効になっています。これにより、COS クラスタ内のワークロードが不安定になる可能性があります。

回避策:

バージョン 1.12.1 で cgroup v1（ハイブリッド）に切り替えました。COS ノードを使用している場合は、リリースされたらすぐにバージョン 1.12.1 にアップグレードすることをおすすめします。

1.10, 1.11, 1.12, 1.13

ClientConfig のカスタムリソース

gkectl update は、ClientConfig カスタムリソースに手動で加えた変更を元に戻します。

回避策:

毎回手動で変更した後に ClientConfig リソースをバックアップすることを強くおすすめします。

インストール

1.10, 1.11, 1.12, 1.13

`gkectl check-config` 検証が失敗: F5 BIG-IP パーティションが見つからない

F5 BIG-IP パーティションが存在している場合でも見つからず、検証で不合格になります。

F5 BIG-IP API に問題があると、検証が失敗することがあります。

回避策:

もう一度 gkectl check-config を実行してみてください。

インストール

1.12

cert-manager/ca-injector のリーダー選出の問題により、ユーザークラスタのインストールが失敗した

apiserver/etcd が低速の場合、クラッシュループの cert-manager-cainjector が原因でインストールが失敗する場合があります。


# These are logs from `cert-manager-cainjector`, from the command
# `kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system
  cert-manager-cainjector-xxx`

I0923 16:19:27.911174       1 leaderelection.go:278] failed to renew lease kube-system/cert-manager-cainjector-leader-election: timed out waiting for the condition

E0923 16:19:27.911110       1 leaderelection.go:321] error retrieving resource lock kube-system/cert-manager-cainjector-leader-election-core:
  Get "https://10.96.0.1:443/api/v1/namespaces/kube-system/configmaps/cert-manager-cainjector-leader-election-core": context deadline exceeded

I0923 16:19:27.911593       1 leaderelection.go:278] failed to renew lease kube-system/cert-manager-cainjector-leader-election-core: timed out waiting for the condition

E0923 16:19:27.911629       1 start.go:163] cert-manager/ca-injector "msg"="error running core-only manager" "error"="leader election lost"

回避策:

回避策を表示する

問題を軽減するために、次のコマンドを実行します。

まず、monitoring-operator をスケールダウンして、cert-manager Deployment への変更が元に戻されないようにします。


kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system \
    scale deployment monitoring-operator --replicas=0

cert-manager-cainjector Deployment を編集してリーダー選出を無効にします。これは、レプリカが 1 つしか実行されていないためです。単一レプリカの場合は必要ありません。


# Add a command line flag for cainjector: `--leader-elect=false`
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG edit \
    -n kube-system deployment cert-manager-cainjector

cert-manager-cainjector デプロイに関連する YAML スニペットは、次の例のようになります。


...
apiVersion: apps/v1
kind: Deployment
metadata:
  name: cert-manager-cainjector
  namespace: kube-system
...
spec:
  ...
  template:
    ...
    spec:
      ...
      containers:
      - name: cert-manager
        image: "gcr.io/gke-on-prem-staging/cert-manager-cainjector:v1.0.3-gke.0"
        args:
        ...
        - --leader-elect=false
...

インストールが完了するまで、緩和策として monitoring-operator レプリカを 0 のままにします。それ以外の場合は、変更が元に戻されます。

インストールが完了し、クラスタが稼働したら、2 日目のオペレーションで monitoring-operator を有効にします。


kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system \
    scale deployment monitoring-operator --replicas=1

各アップグレード後に、変更が元に戻されます。この問題が今後のリリースで修正されるまで、同じ手順を繰り返して問題を軽減します。

セキュリティ、アップグレード、更新

1.10, 1.11, 1.12, 1.13

管理クラスタのアップグレード前に証明書の更新が必要になる場合がある

管理クラスタのアップグレードプロセスを開始する前に、管理クラスタの証明書が現在有効であることを確認し、有効でない場合は更新する必要があります。

アップグレードプロセスをすでに開始しており、証明書の有効期限に関するエラーが見つかった場合は、Google サポートにお問い合わせください。

注: このガイダンスは管理クラスタ証明書の更新専用です。

回避策:

回避策を表示する

開始する前に、管理ワークステーションに OpenSSL がインストールされていることを確認してください。

KUBECONFIG 変数を設定します。
```
KUBECONFIG=ABSOLUTE_PATH_ADMIN_CLUSTER_KUBECONFIG
```
ABSOLUTE_PATH_ADMIN_CLUSTER_KUBECONFIG は、管理クラスタの kubeconfig ファイルの絶対パスに置き換えます。

管理マスターノードの IP アドレスと SSH 認証鍵を取得します。


kubectl --kubeconfig "${KUBECONFIG}" get secrets \
    -n kube-system sshkeys \
    -o jsonpath='{.data.vsphere_tmp}' | base64 -d > \
    ~/.ssh/admin-cluster.key && chmod 600 ~/.ssh/admin-cluster.key

export MASTER_NODE_IP=$(kubectl --kubeconfig "${KUBECONFIG}" \
    get nodes -o \
    jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}' \
    --selector='node-role.kubernetes.io/master')

証明書が期限切れでないかを確認します。
```
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" \
    "sudo kubeadm alpha certs check-expiration"
```
証明書が期限切れの場合は、管理クラスタをアップグレードする前に証明書を更新する必要があります。
管理証明書が期限切れになった場合は管理クラスタの kubeconfig ファイルも期限切れになるため、有効期限が切れる前にこのファイルをバックアップする必要があります。
1. 管理クラスタの kubeconfig ファイルをバックアップします。
```
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" \
  "sudo cat /etc/kubernetes/admin.conf" > new_admin.conf
vi "${KUBECONFIG}"
```
2. kubeconfig の client-certificate-data と client-key-data を作成した new_admin.conf ファイルの client-certificate-data と client-key-data に置き換えます。

古い証明書をバックアップします。これは省略可能ですが、推奨される手順です。


# ssh into admin master if you didn't in the previous step
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}"

# on admin master
sudo tar -czvf backup.tar.gz /etc/kubernetes
logout

# on worker node
sudo scp -i ~/.ssh/admin-cluster.key \
ubuntu@"${MASTER_NODE_IP}":/home/ubuntu/backup.tar.gz .

kubeadm を使用して証明書を更新します。


# ssh into admin master
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}"
# on admin master
sudo kubeadm alpha certs renew all

管理マスターノードで実行されている静的 Pod を再起動します。


# on admin master
cd /etc/kubernetes
sudo mkdir tempdir
sudo mv manifests/*.yaml tempdir/
sleep 5
echo "remove pods"
# ensure kubelet detect those change remove those pods
# wait until the result of this command is empty
sudo docker ps | grep kube-apiserver

# ensure kubelet start those pods again
echo "start pods again"
sudo mv tempdir/*.yaml manifests/
sleep 30

# ensure kubelet start those pods again
# should show some results
sudo docker ps | grep -e kube-apiserver -e kube-controller-manager \
    -e kube-scheduler -e etcd

# clean up
sudo rm -rf tempdir

logout

更新された証明書を検証し、kube-apiserver の証明書を検証します。証明書の有効期限を確認します。
```
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" \
    "sudo kubeadm alpha certs check-expiration"
```

kube-apiserver の証明書を確認します。


# Get the IP address of kube-apiserver
cat $KUBECONFIG | grep server

# Get the current kube-apiserver certificate

openssl s_client -showcerts -connect : \
    | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'  \
    > current-kube-apiserver.crt

# check expiration date of this cert
openssl x509 -in current-kube-apiserver.crt -noout -enddate

VMware

1.10, 1.11, 1.12, 1.13

バージョンが7.0U2 より低い場合は vCenter を再起動またはアップグレードする

バージョンが 7.0U2 より低い場合、vCenter がアップグレードなどの後に再起動されると、vCenter の VM 情報にあるネットワーク名が正しくないため、マシンが Unavailable 状態になります。最終的に、そのノードは自動修復されて新しいノードが作成されます。

リモートホストによって切断された SSH 接続

Anthos clusters on VMware バージョン 1.7.2 以降の場合、Ubuntu OS イメージは CIS L1 Server Benchmark で強化されています。

CIS ルール「5.2.16 Ensure SSH Idle Timeout Interval is configured」を満たすために、/etc/ssh/sshd_config には次の設定が行われます。


ClientAliveInterval 300
ClientAliveCountMax 0

これらの設定の目的は、アイドル状態の 5 分後にクライアントセッションを終了することです。ただし、ClientAliveCountMax 0 値により予期しない動作が発生します。管理ワークステーションまたはクラスタノードで SSH セッションを使用すると、時間のかかるコマンドを実行する際など、SSH クライアントがアイドル状態になっていなくても SSH 接続が切断され、次のメッセージが表示されてコマンドが終了する可能性があります。


Connection to [IP] closed by remote host.
Connection to [IP] closed.

回避策:

次のいずれかを行ってください。

SSH の切断時にコマンドが終了しないようにするには、nohup を使用します。
```
nohup gkectl upgrade admin --config admin-cluster.yaml \
    --kubeconfig kubeconfig
```
ゼロ以外の ClientAliveCountMax 値を使用するように sshd_config を更新します。CIS ルールでは、3 未満の値を使用することが推奨されます。
```
sudo sed -i 's/ClientAliveCountMax 0/ClientAliveCountMax 1/g' \
    /etc/ssh/sshd_config
sudo systemctl restart sshd
```

SSH セッションの再接続を確認してください。

インストール

1.10, 1.11, 1.12, 1.13

`cert-manager` のインストールが競合している

1.13 リリースでは、monitoring-operator によって cert-manager が cert-manager 名前空間にインストールされます。なんらかの理由で独自の cert-manager をインストールする必要がある場合は、次の手順で競合を回避してください。

注: この作業はクラスタごとに 1 回のみ適用する必要があり、変更はクラスタのアップグレード後も保持されます。

cert-manager注: 独自のをインストールするときの一般的な現象は、のバージョンまたはイメージ（v1.7.2 など）が古いバージョンに戻される場合があることです。これは、monitoring-operator が cert-manager を調整し、プロセスでバージョンを元に戻す場合に発生します。

回避策:

アップグレード中の競合を回避する

使用しているバージョンの cert-manager をアンインストールします。独自のリソースを定義した場合は、リソースをバックアップすることをおすすめします。
アップグレードを実施します。
独自の cert-manager を復元するには、次の手順を行います。

ユーザークラスタで独自の cert-manager を復元する

monitoring-operator デプロイを 0 にスケーリングします。


kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    -n USER_CLUSTER_NAME \
    scale deployment monitoring-operator --replicas=0

monitoring-operator によって管理される cert-manager デプロイを 0 にスケールします。


kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n cert-manager scale deployment cert-manager --replicas=0
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n cert-manager scale deployment cert-manager-cainjector\
    --replicas=0
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n cert-manager scale deployment cert-manager-webhook --replicas=0

使用しているバージョンの cert-manager を再インストールします。必要に応じて、カスタマイズしたリソースを復元します。

アップストリームのデフォルト cert-manager のインストールを使用している場合、または cert-manager が cert-manager 名前空間にインストールされている場合は、この手順をスキップできます。それ以外の場合は、metrics-ca cert-manager.io/v1 証明書と metrics-pki.cluster.local Issuer リソースを cert-manager から、インストールした cert-manager のクラスタリソース名前空間にコピーします。


relevant_fields='
{
  apiVersion: .apiVersion,
  kind: .kind,
  metadata: {
    name: .metadata.name,
    namespace: "YOUR_INSTALLED_CERT_MANAGER_NAMESPACE"
  },
  spec: .spec
}
'
f1=$(mktemp)
f2=$(mktemp)
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    get issuer -n cert-manager metrics-pki.cluster.local -o json \
    | jq "${relevant_fields}" > $f1
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    get certificate -n cert-manager metrics-ca -o json \
    | jq "${relevant_fields}" > $f2
kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f $f1
kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f $f2

管理クラスタに独自の cert-manager を復元する

一般に、管理クラスタは Anthos clusters on VMware のコントロールプレーンワークロードのみを実行するため、管理クラスタに cert-manager を再インストールする必要はありません。まれに、独自の cert-manager を管理クラスタにインストールする必要が生じた場合は、競合を回避するために次の手順に沿って操作してください。Apigee をご利用いただいており、Apigee の cert-manager のみを必要とされる場合は、管理クラスタコマンドを実行する必要はありません。

monitoring-operator デプロイを 0 にスケーリングします。


kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    -n kube-system scale deployment monitoring-operator --replicas=0

monitoring-operator によって管理される cert-manager デプロイを 0 にスケールします。


kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    -n cert-manager scale deployment cert-manager \
    --replicas=0

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
     -n cert-manager scale deployment cert-manager-cainjector \
     --replicas=0

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    -n cert-manager scale deployment cert-manager-webhook \
    --replicas=0

使用しているバージョンの cert-manager を再インストールします。必要に応じて、カスタマイズしたリソースを復元します。


relevant_fields='
{
  apiVersion: .apiVersion,
  kind: .kind,
  metadata: {
    name: .metadata.name,
    namespace: "YOUR_INSTALLED_CERT_MANAGER_NAMESPACE"
  },
  spec: .spec
}
'
f3=$(mktemp)
f4=$(mktemp)
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \n
    get issuer -n cert-manager metrics-pki.cluster.local -o json \
    | jq "${relevant_fields}" > $f3
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    get certificate -n cert-manager metrics-ca -o json \
    | jq "${relevant_fields}" > $f4
kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f $f3
kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f $f4

オペレーティングシステム

1.10, 1.11, 1.12, 1.13

Docker、containerd、runc の脆弱性スキャンにおける誤検出

Anthos clusters on VMware に付属する Ubuntu OS イメージ内の Docker、containerd、runc は、Ubuntu PPA を使用して特別なバージョンに固定されます。これにより、コンテナランタイムの変更が各リリース前に Anthos clusters on VMware によって認定されるようになります。

ただし、特殊なバージョンは Ubuntu CVE Tracker に知られていません。これは、さまざまな CVE スキャンツールによって脆弱性フィードとして使用されます。したがって、docker、containerd、runc の脆弱性スキャン結果に誤検出が生じます。

たとえば、CVE のスキャン結果で次の誤検出が発生することがあります。これらの CVE は Anthos clusters on VMware の最新のパッチバージョンですでに修正されています。

CVE の修正については、リリースノートをご覧ください。

回避策:

Canonical はこの問題を認識しており、修正は https://github.com/canonical/sec-cvescan/issues/73 で追跡されています。

アップグレードと更新

1.10, 1.11, 1.12, 1.13

管理者クラスタとユーザークラスタの間のネットワーク接続は、非 HA クラスタのアップグレード中に短時間使用できなくなる場合があります

HA 以外のクラスタを 1.9 から 1.10 にアップグレードする場合に、ユーザークラスタに対する kubectl exec、kubectl log、Webhook がしばらく使用できなくなる場合があります。このダウンタイムは最大で 1 分です。これは、受信リクエスト（kubectl exec、kubectl log、Webhook）がユーザークラスタの kube-apiserver によって処理されるために発生します。ユーザー kube-apiserver は Statefulset です。HA 以外のクラスタでは、Statefulset のレプリカは 1 つだけです。そのため、アップグレード中、新しい kube-apiserver の準備ができるまで古い kube-apiserver が使用できなくなる可能性があります。

回避策:

このダウンタイムはアップグレードプロセス中にのみ発生します。アップグレード時のダウンタイムを短縮するために、HA クラスタに切り替えることをおすすめします。

インストール、アップグレード、更新

1.10, 1.11, 1.12, 1.13

クラスタの作成またはアップグレード後の HA クラスタの診断で Konnectivity の準備チェックが失敗した

HA クラスタの作成またはアップグレードを行っているときにクラスタの診断で konnectivity の readiness チェックに失敗した場合、通常、Anthos clusters on VMware（kubectl exec、kubectl log、Webhook）の機能には影響しません。これは、不安定なネットワーキングなどの問題が原因で、1、2 個の konnectivity のレプリカが一定期間読み取り不能になっている可能性があるためです。

回避策:

konnectivity は自己回復します。30 分から 1 時間待ってから、クラスタ診断を再実行してください。

オペレーティングシステム

1.7, 1.8, 1.9, 1.10, 1.11

`/etc/cron.daily/aide` CPU とメモリの急増に関する問題

Anthos clusters on VMware バージョン 1.7.2 以降では、Ubuntu OS イメージが CIS L1 Server Benchmark で強化されています。

そのため、cron スクリプト /etc/cron.daily/aide がインストールされ、CIS L1 サーバールールの「1.4.2 ファイルシステムの整合性が確保されていることを定期的に確認する」を実施する aide チェックがスケジュール設定されます。

cron ジョブは、毎日午前 6 時 25 分（UTC）に実行されます。ファイルシステム上のファイルの数によっては、この aide プロセスが原因で、CPU とメモリの使用量が急増することがあります。

回避策:

急増がワークロードに影響を与える場合は、毎日の cron ジョブを無効にできます。


sudo chmod -x /etc/cron.daily/aide

ネットワーキング

1.10, 1.11, 1.12, 1.13

ロードバランサと NSX-T ステートフル分散ファイアウォールルールが予期しない動作をする。

NSX-T ステートフル分散ファイアウォールルールを使用する環境に Seesaw がバンドルされたロードバランサがデプロイされている場合、Anthos clusters on VMware バージョン 1.9 以降をデプロイすると、stackdriver-operator は gke-metrics-agent-confConfigMap の作成に失敗し、gke-connect-agent Pod がクラッシュループに入る。

根本的な問題は、Seesaw が非対称接続フローを使用するため、Seesaw ロードバランサを通るクライアントからユーザークラスタ API サーバーへの接続がステートフル NSX-T 分散ファイアウォールルールによって解除されることです。NSX-T 分散ファイアウォールルールとのインテグレーションの問題は、Seesaw を使用するすべての Anthos clusters on VMware リリースに影響します。独自のアプリケーションで、32K を超えるサイズの大規模な Kubernetes オブジェクトを作成すると、同様の接続の問題が発生することがあります。

回避策:

こちらの手順に沿って NSX-T 分散ファイアウォールルールを無効にするか、Seesaw VM 用のステートレス分散ファイアウォールルールを使用します。

クラスタで手動ロードバランサを使用している場合は、こちらの手順に沿って、バックエンドノードの障害を検出したときにクライアント接続がリセットされるようにロードバランサを構成します。この構成を行わないと、サーバーインスタンスがダウンしたときに Kubernetes API サーバーのクライアントが数分間応答不能になる可能性があります。

ロギングとモニタリング

1.10, 1.11, 1.12, 1.13, 1.14, 1.15

予想外の請求のモニタリング

Anthos clusters on VMware バージョン 1.10 から、料金ページで予想外に高い Metrics volume の料金が請求される場合があります。この問題は、次の両方の状況に該当する場合にのみ影響します。

アプリケーションのモニタリングが有効（enableStackdriverForApplications=true）
Managed Service for Prometheus が有効になっていない（enableGMPForApplications）
アプリケーション Pod には prometheus.io/scrap=true アノテーションが付いています。（Anthos Service Mesh をインストールすると、このアノテーションも追加されます）。

この問題の影響を受けるかどうかを確認するには、ユーザー定義の指標を一覧表示します。不要な指標に対する請求が表示される場合は、この問題に該当します。

回避策

響を受ける場合は、クラスタをバージョン 1.12 にアップグレードして、この問題に対処する新しいアプリケーションモニタリングソリューションの managed-service-for-prometheus に切り替えることをおすすめします。

アプリケーションログの収集とアプリケーション指標の収集を制御するフラグ

バンドルされた Google Cloud Managed Service for Prometheus

バージョン 1.12 にアップグレードできない場合は、次の手順を行います。

不要な請求の指標が含まれるソースの Pod と Service を見つけます。


kubectl --kubeconfig KUBECONFIG \
  get pods -A -o yaml | grep 'prometheus.io/scrape: "true"'
kubectl --kubeconfig KUBECONFIG get \
  services -A -o yaml | grep 'prometheus.io/scrape: "true"'

Pod または Service から prometheus.io/scrap=true アノテーションを削除します。アノテーションが Anthos Service Mesh によって追加される場合は、Prometheus オプションを使用しない Anthos Service Mesh の構成、または Istio 指標の統合機能の無効化を検討してください。

インストール

1.11, 1.12, 1.13

vSphere データディスクの作成時にインストーラが失敗する

カスタムロールが誤った権限レベルでバインドされている場合は、Anthos clusters on VMware インストーラが失敗する可能性があります。

ロールバインディングが間違っていると、vSphere データディスクの作成で govc がハングし、0 サイズのディスクが作成されます。この問題を解決するには、vSphere vcenter レベル（root）でカスタムロールをバインドします。

回避策:

DC レベル（またはルートよりも低いレベル）でカスタムロールをバインドする場合は、ルート vCenter レベルで読み取り専用ロールをユーザーにバインドする必要があります。

ロールの作成の詳細については、vCenter ユーザーアカウント権限をご覧ください。

ロギングとモニタリング

1.9.0-1.9.4, 1.10.0-1.10.1

monitoring.googleapis.com への高いネットワークトラフィック

ユーザーワークロードがない新しいクラスタであっても、monitoring.googleapis.com へのネットワークトラフィック量が多い場合があります。

この問題は、バージョン 1.10.0-1.10.1 とバージョン 1.9.0-1.9.4 に影響します。この問題は、バージョン 1.10.2 と 1.9.5 で修正されています。

回避策:

回避策を表示する

バージョン 1.10.2/1.9.5 以降にアップグレードします。

以前のバージョンでこの問題を回避するには:

「stackdriver-operator」をスケールダウンします。
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system \
    scale deployment stackdriver-operator --replicas=0
```
USER_CLUSTER_KUBECONFIG は、ユーザークラスタ kubeconfig ファイルのパスに置き換えます。

編集用に gke-metrics-agent-conf ConfigMap を開きます。


kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system \
    edit configmap gke-metrics-agent-conf

プローブ間隔を 0.1 秒から 13 秒に拡張します。


  processors:
    disk_buffer/metrics:
      backend_endpoint: https://monitoring.googleapis.com:443
      buffer_dir: /metrics-data/nsq-metrics-metrics
      probe_interval: 13s
      retention_size_mib: 6144
  disk_buffer/self:
      backend_endpoint: https://monitoring.googleapis.com:443
      buffer_dir: /metrics-data/nsq-metrics-self
      probe_interval: 13s
      retention_size_mib: 200
    disk_buffer/uptime:
      backend_endpoint: https://monitoring.googleapis.com:443
      buffer_dir: /metrics-data/nsq-metrics-uptime
      probe_interval: 13s
      retention_size_mib: 200

編集セッションを閉じます。

gke-metrics-agent DaemonSet のバージョンを 1.1.0-anthos.8 に変更します。


kubectl --kubeconfig USER_CLUSTER_KUBECONFIG  \
  --namespace kube-system  set image daemonset/gke-metrics-agent \
  gke-metrics-agent=gcr.io/gke-on-prem-release/gke-metrics-agent:1.1.0-anthos.8

ロギングとモニタリング

1.10, 1.11

`gke-metrics-agent` で CrashLoopBackOff エラーが頻繁に発生する

Anthos clusters on VMware バージョン 1.10 以降の場合、「stackdriver」オブジェクトで「enableStackdriverForApplications」が「true」に設定されている場合、「gke-metrics-agent」DaemonSet で CrashLoopBackOff が頻繁に発生します。

回避策:

この問題を軽減するには、次のコマンドを実行して、アプリケーション指標の収集を無効にします。これらのコマンドでアプリケーションログの収集は無効になりません。

次の変更を元に戻さないようにするには、stackdriver-operator をスケールダウンします。
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system scale deploy stackdriver-operator \
    --replicas=0
```
USER_CLUSTER_KUBECONFIG は、ユーザークラスタ kubeconfig ファイルのパスに置き換えます。

編集用に gke-metrics-agent-conf ConfigMap を開きます。


kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system edit configmap gke-metrics-agent-conf

services.pipelines で、metrics/app-metrics セクション全体をコメントアウトします。


services:
  pipelines:
    #metrics/app-metrics:
    #  exporters:
    #  - googlecloud/app-metrics
    #  processors:
    #  - resource
    #  - metric_to_resource
    #  - infer_resource
    #  - disk_buffer/app-metrics
    #  receivers:
    #  - prometheus/app-metrics
    metrics/metrics:
      exporters:
      - googlecloud/metrics
      processors:
      - resource
      - metric_to_resource
      - infer_resource
      - disk_buffer/metrics
      receivers:
      - prometheus/metrics

編集セッションを閉じます。

gke-metrics-agent DaemonSet を再起動します。


kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system rollout restart daemonset gke-metrics-agent

ロギングとモニタリング

1.11, 1.12, 1.13

ダッシュボードでサポートが終了した指標を置き換える

サポートが終了した指標が OOTB ダッシュボードで使用されている場合は、空のグラフがいくつか表示されます。Monitoring ダッシュボードでサポートが終了した指標を見つけるには、次のコマンドを実行します。


gcloud monitoring dashboards list > all-dashboard.json

# find deprecated metrics
cat all-dashboard.json | grep -E \
  'kube_daemonset_updated_number_scheduled\
    |kube_node_status_allocatable_cpu_cores\
    |kube_node_status_allocatable_pods\
    |kube_node_status_capacity_cpu_cores'

次のサポートが終了した指標を、サポートされている指標に移行する必要があります。

非推奨	置換
`kube_daemonset_updated_number_scheduled`	`kube_daemonset_status_updated_number_scheduled`
`kube_node_status_allocatable_cpu_cores` `kube_node_status_allocatable_memory_bytes` `kube_node_status_allocatable_pods`	`kube_node_status_allocatable`
`kube_node_status_capacity_cpu_cores` `kube_node_status_capacity_memory_bytes` `kube_node_status_capacity_pods`	`kube_node_status_capacity`
`kube_hpa_status_current_replicas`	`kube_horizontalpodautoscaler_status_current_replicas`

回避策:

サポートが終了した指標を置き換えるには:

Google Cloud Monitoring ダッシュボードで「GKE On-Prem ノードのステータス」を削除します。これらの手順に沿って、「GKE On-Prem ノードのステータス」を再インストールします。
Google Cloud Monitoring ダッシュボードで「GKE On-Prem のノード使用率」を削除します。これらの手順に沿って、「GKE On-Prem ノード使用率」を再インストールします。
Google Cloud Monitoring ダッシュボードで「GKE on-prem vSphere vm health」を削除します。こちらの手順に沿って、「GKE On-Prem vSphere vm health」を再インストールします。

このサポート終了は、Kubernetes 1.22 に必要な kube-state-metrics エージェントを v1.9 から v2.4 にアップグレードしたことによるものです。カスタムダッシュボードまたはアラートポリシーで、接頭辞 kube_ を持つサポートが終了した kube-state-metrics 指標をすべて置換できます。

ロギングとモニタリング

1.10, 1.11, 1.12, 1.13

Cloud Monitoring で不明な指標データ

Anthos clusters on VMware バージョン 1.10 以降の場合、Cloud Monitoring のクラスタのデータには、次のような無関係なサマリー指標のエントリが含まれている場合があります。


Unknown metric: kubernetes.io/anthos/go_gc_duration_seconds_summary_percentile

無関係なサマリー指標が含まれている可能性があるその他の指標タイプ:

apiserver_admission_step_admission_duration_seconds_summary
go_gc_duration_seconds
scheduler_scheduling_duration_seconds
gkeconnect_http_request_duration_seconds_summary
alertmanager_nflog_snapshot_duration_seconds_summary

これらのサマリータイプの指標は指標リストに含まれていますが、現時点では gke-metrics-agent ではサポートされていません。

ロギングとモニタリング

1.10, 1.11, 1.12, 1.13

一部のノードで指標が見つからない

すべてのノードではありませんが、一部のノードでは、次の指標が見つからない場合があります。

kubernetes.io/anthos/container_memory_working_set_bytes
kubernetes.io/anthos/container_cpu_usage_seconds_total
kubernetes.io/anthos/container_network_receive_bytes_total

回避策:

この問題を解決するには、回避策として次の手順に沿って処理します。[バージョン 1.9.5 以降、1.10.2 以降、1.11.0]: 次の手順 1 ～ 4 に従って、gke-metrics-agent の CPU を増やします。

stackdriver リソースを編集用に開きます。


kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system edit stackdriver stackdriver

gke-metrics-agent の CPU リクエストを 10m から 50m に引き上げるには、次の resourceAttrOverride セクションを追加して 100m から 200m に CPU 上限を追加しますstackdriver マニフェストに移動します。


spec:
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      limits:
        cpu: 100m
        memory: 4608Mi
      requests:
        cpu: 10m
        memory: 200Mi

編集したリソースは、次のようになります。


spec:
  anthosDistribution: on-prem
  clusterLocation: us-west1-a
  clusterName: my-cluster
  enableStackdriverForApplications: true
  gcpServiceAccountSecretName: ...
  optimizedMetrics: true
  portable: true
  projectID: my-project-191923
  proxyConfigSecretName: ...
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      limits:
        cpu: 200m
        memory: 4608Mi
      requests:
        cpu: 50m
        memory: 200Mi

変更を保存し、テキストエディタを終了します。
変更が有効になっていることを確認するには、次のコマンドを実行します。
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system get daemonset gke-metrics-agent -o yaml \
    | grep "cpu: 50m"
```
変更が有効になっている場合は、このコマンドで cpu: 50m が検出されます。

ロギングとモニタリング

1.11.0-1.11.2, 1.12.0

管理クラスタにスケジューラとコントローラマネージャーの指標がない

管理クラスタがこの問題の影響を受ける場合、スケジューラとコントローラマネージャーの指標がありません。たとえば、以下の 2 つの指標が欠落しています。


# scheduler metric example
scheduler_pending_pods
# controller-manager metric example
replicaset_controller_rate_limiter_use

回避策:

v1.11.3 以降、v1.12.1 以降、v1.13 以降にアップグレードします。

1.11.0-1.11.2, 1.12.0

ユーザークラスタにスケジューラとコントローラマネージャーの指標がない

ユーザークラスタがこの問題の影響を受ける場合、スケジューラとコントローラマネージャーの指標がありません。たとえば、以下の 2 つの指標が欠落しています。


# scheduler metric example
scheduler_pending_pods
# controller-manager metric example
replicaset_controller_rate_limiter_use

回避策:

この問題は、Anthos clusters on VMware バージョン 1.13.0 以降で修正されています。修正済みのクラスタをクラスタにアップグレードします。

インストール、アップグレード、更新

1.10, 1.11, 1.12, 1.13

作成時に管理クラスタを登録できない

バージョン 1.9.x または 1.10.0 の管理クラスタを作成するときに、指定された gkeConnect 仕様で管理クラスタを登録できない場合は、次のエラーが発生します。


Failed to create root cluster: failed to register admin cluster: failed to register cluster: failed to apply Hub Membership: Membership API request failed: rpc error:  ode = PermissionDenied desc = Permission 'gkehub.memberships.get' denied on PROJECT_PATH

この管理クラスタは引き続き使用できますが、後で管理クラスタをバージョン 1.10.y にアップグレードしようとすると、次のエラーが発生します。


failed to migrate to first admin trust chain: failed to parse current version "": invalid version: "" failed to migrate to first admin trust chain: failed to parse current version "": invalid version: ""

回避策:

回避策を表示する

このエラーが発生した場合は、以下の手順に沿ってクラスタ登録の問題を解決してください。この修正を行うと、管理クラスタをアップグレードできます。

gkectl update admin を実行して、管理クラスタを正しいサービスアカウントキーに登録します。

OnPremAdminCluster カスタムリソースにパッチを適用するための専用のサービスアカウントを作成します。


export KUBECONFIG=ADMIN_CLUSTER_KUBECONFIG

# Create Service Account modify-admin
kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
  name: modify-admin
  namespace: kube-system
EOF

# Create ClusterRole
kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  creationTimestamp: null
  name: modify-admin-role
rules:
- apiGroups:
  - "onprem.cluster.gke.io"
  resources:
  - "onpremadminclusters/status"
  verbs:
  - "patch"
EOF

# Create ClusterRoleBinding for binding the permissions to the modify-admin SA

kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  creationTimestamp: null
  name: modify-admin-rolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: modify-admin-role
subjects:
- kind: ServiceAccount
  name: modify-admin
  namespace: kube-system
EOF

ADMIN_CLUSTER_KUBECONFIG は、管理クラスタ kubeconfig ファイルのパスに置き換えます。

次のコマンドを実行して、OnPremAdminCluster カスタムリソースを更新します。


export KUBECONFIG=ADMIN_CLUSTER_KUBECONFIG

SERVICE_ACCOUNT=modify-admin

SECRET=$(kubectl get serviceaccount ${SERVICE_ACCOUNT} \
    -n kube-system -o json \
    | jq -Mr '.secrets[].name | select(contains("token"))')

TOKEN=$(kubectl get secret ${SECRET} -n kube-system -o json \
    | jq -Mr '.data.token' | base64 -d)

kubectl get secret ${SECRET} -n kube-system -o json \
    | jq -Mr '.data["ca.crt"]' \
    | base64 -d > /tmp/ca.crt

APISERVER=https://$(kubectl -n default get endpoints kubernetes \
    --no-headers | awk '{ print $2 }')

# Find out the admin cluster name and gkeOnPremVersion from the OnPremAdminCluster CR
ADMIN_CLUSTER_NAME=$(kubectl get onpremadmincluster -n kube-system \
    --no-headers | awk '{ print $1 }')
GKE_ON_PREM_VERSION=$(kubectl get onpremadmincluster \
    -n kube-system $ADMIN_CLUSTER_NAME \
    -o=jsonpath='{.spec.gkeOnPremVersion}')

# Create the Status field and set the gkeOnPremVersion in OnPremAdminCluster CR
curl -H "Accept: application/json" \
    --header "Authorization: Bearer $TOKEN" -XPATCH \
    -H "Content-Type: application/merge-patch+json" \
    --cacert /tmp/ca.crt \
    --data '{"status": {"gkeOnPremVersion": "'$GKE_ON_PREM_VERSION'"}}' \
    $APISERVER/apis/onprem.cluster.gke.io/v1alpha1/namespaces/kube-system/onpremadminclusters/$ADMIN_CLUSTER_NAME/status

--disable-upgrade-from-checkpoint フラグを使用して管理クラスタのアップグレードを再試行します。
```
gkectl upgrade admin --config ADMIN_CLUSTER_CONFIG \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --disable-upgrade-from-checkpoint
```
ADMIN_CLUSTER_CONFIG は、管理クラスタ構成ファイルのパスで置き換えます。

1.10, 1.11, 1.12, 1.13

Anthos Identity Service を使用すると Connect Agent が予期せず再起動する場合がある

Anthos Identity Service 機能を使用して Anthos Identity Service ClientConfig を管理している場合は、Connect Agent が予期せず再起動する可能性があります。

回避策:

既存のクラスタでこの問題が発生した場合は、次のいずれかを行います。

Anthos Identity Service（AIS）を無効にします。AIS を無効にしても、デプロイされた AIS バイナリや AIS ClientConfig は削除されません。AIS を無効にするには、次のコマンドを実行します。
```
gcloud beta container hub identity-service disable \
    --project PROJECT_NAME
```
PROJECT_NAME は、クラスタのフリートホストプロジェクトの名前に置き換えます。
Connect Agent のバージョンをアップグレードするために、クラスタをバージョン 1.9.3 以降またはバージョン 1.10.1 以降に更新します。

ネットワーキング

1.10, 1.11, 1.12, 1.13

Cisco ACI は Direct Server Return（DSR）と連動しない

Seesaw は DSR モードで動作します。デフォルトでは、データプレーン IP 学習が原因で Cisco ACI では機能しません。

回避策:

この問題を回避するには、Seesaw IP アドレスを Cisco Application Policy Infrastructure Controller（APIC）の L4-L7 仮想 IP として追加して、IP ラーニングを無効にします。

[テナント] > [アプリケーションプロファイル] > [アプリケーション EPG] または [uSeg EPG] に移動すると、L4-L7 仮想 IP オプションを構成できます。IP ラーニングの無効化に失敗すると、Cisco API ファブリック内の異なるロケーション間で IP エンドポイントのフラッピングが発生します。

VMware

1.10, 1.11, 1.12, 1.13

vSphere 7.0 Update 3 の問題

VMware では最近、次の vSphere 7.0 Update 3 リリースで重大な問題を特定しました。

vSphere ESXi 7.0 Update 3 (build 18644231)
vSphere ESXi 7.0 Update 3a (build 18825058)
vSphere ESXi 7.0 Update 3b (build 18905247)
vSphere vCenter 7.0 Update 3b (build 18901211)

回避策:

VMWare はその後、これらのリリースを削除しました。ESXi と vCenter Server を新しいバージョンにアップグレードする必要があります。

オペレーティングシステム

1.10, 1.11, 1.12, 1.13

emptyDir ボリュームを、COS ノードで実行されている Pod に `exec` としてマウントできない

Container-Optimized OS（COS）イメージを使用するノードで動作する Pod の場合、emptyDir ボリュームを exec としてマウントすることはできません。noexec としてマウントされます。exec user process caused: permission denied というエラーメッセージが表示されます。たとえば、次のテスト Pod をデプロイすると、このエラーメッセージが表示されます。


apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: test
  name: test
spec:
  containers:
  - args:
    - sleep
    - "5000"
    image: gcr.io/google-containers/busybox:latest
    name: test
    volumeMounts:
      - name: test-volume
        mountPath: /test-volume
    resources:
      limits:
        cpu: 200m
        memory: 512Mi
  dnsPolicy: ClusterFirst
  restartPolicy: Always
  volumes:
    - emptyDir: {}
      name: test-volume

テスト Pod で mount | grep test-volume を実行すると、noexec オプションが表示されます。


/dev/sda1 on /test-volume type ext4 (rw,nosuid,nodev,noexec,relatime,commit=30)

回避策:

回避策を表示する

DaemonSet リソースを適用します。たとえば、以下のようになります。


apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fix-cos-noexec
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: fix-cos-noexec
  template:
    metadata:
      labels:
        app: fix-cos-noexec
    spec:
      hostIPC: true
      hostPID: true
      containers:
      - name: fix-cos-noexec
        image: ubuntu
        command: ["chroot", "/host", "bash", "-c"]
        args:
        - |
          set -ex
          while true; do
            if ! $(nsenter -a -t 1 findmnt -l | grep -qe "^/var/lib/kubelet\s"); then
              echo "remounting /var/lib/kubelet with exec"
              nsenter -a -t 1 mount --bind /var/lib/kubelet /var/lib/kubelet
              nsenter -a -t 1 mount -o remount,exec /var/lib/kubelet
            fi
            sleep 3600
          done
        volumeMounts:
        - name: host
          mountPath: /host
        securityContext:
          privileged: true
      volumes:
      - name: host
        hostPath:
          path: /

アップグレードと更新

1.10, 1.11, 1.12, 1.13

ノードプールで自動スケーリングが無効にした後、クラスタノードプールのレプリカの更新が機能しない

ノードプールで自動スケーリングを有効にしてから無効にすると、ノードプールのレプリカは更新されません。

回避策:

対応するノードプールのマシンデプロイから cluster.x-k8s.io/cluster-api-autoscaler-node-group-max-size と cluster.x-k8s.io/cluster-api-autoscaler-node-group-min-size アノテーションを削除します。

ロギングとモニタリング

1.11, 1.12, 1.13

Windows モニタリングダッシュボードに Linux クラスタからのデータが表示される

バージョン 1.11 以降では、すぐに使用できるモニタリングダッシュボードの Windows Pod ステータスダッシュボードと Windows ノードステータスダッシュボードにも Linux クラスタのデータが表示されます。これは、Windows ノードと Pod の指標も Linux クラスタに公開されているためです。

ロギングとモニタリング

1.10、1.11、1.12

定数 CrashLoopBackOff 内の `stackdriver-log-forwarder`

Anthos clusters on VMware バージョン 1.10、1.11、1.12 の場合、ディスクに破損したバッファログがあると、stackdriver-log-forwarder DaemonSet に CrashLoopBackOff エラーが発生する可能性があります。

回避策:

この問題を軽減するには、ノード上のバッファ内のログをクリーンアップする必要があります。

予期しない動作を防ぐには、stackdriver-log-forwarder をスケールダウンします。
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n kube-system patch daemonset stackdriver-log-forwarder -p '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}'
```
USER_CLUSTER_KUBECONFIG は、ユーザークラスタ kubeconfig ファイルのパスに置き換えます。

クリーンアップした DaemonSet をデプロイして、壊れたチャンクをクリーンアップします。


kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n kube-system -f - << EOF
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluent-bit-cleanup
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: fluent-bit-cleanup
  template:
    metadata:
      labels:
        app: fluent-bit-cleanup
    spec:
      containers:
      - name: fluent-bit-cleanup
        image: debian:10-slim
        command: ["bash", "-c"]
        args:
        - |
          rm -rf /var/log/fluent-bit-buffers/
          echo "Fluent Bit local buffer is cleaned up."
          sleep 3600
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        securityContext:
          privileged: true
      tolerations:
      - key: "CriticalAddonsOnly"
        operator: "Exists"
      - key: node-role.kubernetes.io/master
        effect: NoSchedule
      - key: node-role.gke.io/observability
        effect: NoSchedule
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
EOF

クリーンアップの DaemonSet がすべてのチャンクをクリーンアップしたことを確認するには、次のコマンドを実行します。2 つのコマンドの出力では、クラスタ内のノード数が同じになるはずです。
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  logs -n kube-system -l app=fluent-bit-cleanup | grep "cleaned up" | wc -l

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system get pods -l app=fluent-bit-cleanup --no-headers | wc -l
```

クリーンアップの DaemonSet を削除します。


kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system delete ds fluent-bit-cleanup

stackdriver-log-forwarder　の再開：


kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system patch daemonset stackdriver-log-forwarder --type json -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'

ロギングとモニタリング

1.10, 1.11, 1.12, 1.13, 1.14, 1.15

`stackdriver-log-forwarder` は、Cloud Logging にログを送信しません

クラスタからの Cloud Logging にログが表示されず、ログに次のエラーが見つかった場合。


2023-06-02T10:53:40.444017427Z [2023/06/02 10:53:40] [error] [input chunk] chunk 1-1685703077.747168499.flb would exceed total limit size in plugin stackdriver.0
2023-06-02T10:53:40.444028047Z [2023/06/02 10:53:40] [error] [input chunk] no available chunk

ログ入力レートがロギングエージェントの上限を超えている可能性があります。これにより、stackdriver-log-forwarder がログを送信しなくなります。この問題は、Anthos clusters on VMware のすべてのバージョンで発生します。

回避策:

この問題を軽減するには、Logging エージェントのリソース上限を増やす必要があります。

stackdriver リソースを編集用に開きます。


kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system edit stackdriver stackdriver

stackdriver-log-forwarder の CPU リクエストを増やすには、次の resourceAttrOverride セクションを stackdriver マニフェストに追加します。


spec:
  resourceAttrOverride:
    stackdriver-log-forwarder/stackdriver-log-forwarder:
      limits:
        cpu: 1200m
        memory: 600Mi
      requests:
        cpu: 600m
        memory: 600Mi

編集したリソースは、次のようになります。


spec:
  anthosDistribution: on-prem
  clusterLocation: us-west1-a
  clusterName: my-cluster
  enableStackdriverForApplications: true
  gcpServiceAccountSecretName: ...
  optimizedMetrics: true
  portable: true
  projectID: my-project-191923
  proxyConfigSecretName: ...
  resourceAttrOverride:
    stackdriver-log-forwarder/stackdriver-log-forwarder:
      limits:
        cpu: 1200m
        memory: 600Mi
      requests:
        cpu: 600m
        memory: 600Mi

変更を保存し、テキストエディタを終了します。
変更が有効になっていることを確認するには、次のコマンドを実行します。
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system get daemonset stackdriver-log-forwarder -o yaml \
    | grep "cpu: 1200m"
```
変更が有効になっている場合は、このコマンドで cpu: 1200m が検出されます。

セキュリティ

1.13

NodeReady 後に Kubelet サービスは一時的に利用できなくなる

ノードが準備できているが、kubelet サーバー証明書の準備ができていない。この 10 秒間は kubectl exec と kubectl logs を使用できません。これは、新しいサーバー証明書の承認者がノードの更新後の有効な IP を認識するまでに時間がかかるためです。

この問題は、kubelet サーバー証明書にのみ影響し、Pod のスケジューリングには影響しません。

アップグレードと更新

1.12

管理クラスタのアップグレードで、後のユーザークラスタのアップグレードがブロックされない

次のエラーでユーザークラスタのアップグレードに失敗しました。


.LBKind in body is required (Check the status of OnPremUserCluster 'cl-stg-gdl-gke-onprem-mgmt/cl-stg-gdl' and the logs of pod 'kube-system/onprem-user-cluster-controller' for more detailed debugging information.

管理クラスタは完全にはアップグレードされず、ステータスバージョンは 1.10 のままです。1.12 へのユーザークラスタのアップグレードは、プリフライトチェックによってブロックされず、バージョンスキューの問題によって失敗します。

回避策:

まず管理クラスタを 1.11 にアップグレードしてから、ユーザークラスタを 1.12 にアップグレードします。

ストレージ

1.10.0-1.10.5, 1.11.0-1.11.2, 1.12.0

データストアの空き容量が不足していると誤って報告される

gkectl diagnose cluster コマンドが次のエラーで失敗しました。


Checking VSphere Datastore FreeSpace...FAILURE
    Reason: vCenter datastore: [DATASTORE_NAME] insufficient FreeSpace, requires at least [NUMBER] GB

データストアの空き容量の検証は、既存のクラスタノードプールには使用しないでください。この検証は gkectl diagnose cluster に誤って追加されたものです。

回避策:

このエラーメッセージは無視して構いません。または、--skip-validation-infra を使用して検証をスキップできます。

運用、ネットワーキング

1.11, 1.12.0-1.12.1

管理クラスタが MetalLB ロードバランサの構成で構成されている場合、新しいユーザークラスタを追加できない場合があります。

ユーザークラスタの削除プロセスがなんらかの理由で停止し、MatalLB ConfigMap が無効になる場合があります。この状態では新しいユーザークラスタを追加できません。

回避策:

ユーザークラスタを強制的に削除できます。

インストール、オペレーティングシステム

1.10, 1.11, 1.12, 1.13

ユーザークラスタに Container-Optimized OS（COS）を使用しているときに障害が発生する

管理クラスタで osImageType が cos を使用している場合、管理クラスタの作成後およびユーザークラスタの作成前に gkectl check-config を実行すると、失敗します。


Failed to create the test VMs: VM failed to get IP addresses on the network.

ユーザークラスタ check-config 用に作成されたテスト VM はデフォルトで管理クラスタと同じ osImageType を使用します。現在、テスト VM は COS と互換性がありません。

回避策:

gkectl check-config --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG --fast を使用して、テスト VM を作成するスロープリフライトチェックを回避します。

ロギングとモニタリング

1.12.0-1.12.1

管理クラスタ内の Grafana がユーザークラスタに到達できない

この問題は、管理クラスタで Grafana を使用して Anthos clusters on VMware バージョン 1.12.0 と 1.12.1 でユーザークラスタをモニタリングするユーザーに影響します。これは、ユーザークラスタの pushprox-client 証明書と管理クラスタの pushprox-server の許可リストの不一致が原因です。この症状は、次のようなエラーログが出力されるユーザークラスタの pushprox-client で発生します。


level=error ts=2022-08-02T13:34:49.41999813Z caller=client.go:166 msg="Error reading request:" err="invalid method \"RBAC:\""

回避策:

回避策を表示する

次の手順を行います。

管理クラスタの kube-system 名前空間で monitoring-operator のデプロイをスケールダウンします。


kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --namespace kube-system scale deploy monitoring-operator \
    --replicas=0

管理クラスタの kube-system 名前空間で pushprox-server-rbac-proxy-config ConfigMap を編集します。


kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --namespace kube-system edit cm pushprox-server-rbac-proxy-config

external-pushprox-server-auth-proxy リスナーの principals 行を見つけて、pushprox-client.metrics-consumers.kube-system.cluster. から kube-system 部分文字列を削除して、すべてのユーザークラスタの principal_name を修正します。新しい構成は次のようになります。


permissions:
- or_rules:
    rules:
    - header: { name: ":path", exact_match: "/poll" }
    - header: { name: ":path", exact_match: "/push" }
principals: [{"authenticated":{"principal_name":{"exact":"pushprox-client.metrics-consumers.kube-system.cluster.local"}}},{"authenticated":{"principal_name":{"exact":"pushprox-client.metrics-consumers.kube-system.cluster."}}},{"authenticated":{"principal_name":{"exact":"pushprox-client.metrics-consumers.cluster."}}}]

管理クラスタで pushprox-server Deployment を再起動し、影響を受けるユーザークラスタで pushprox-client Deployment を再起動します。


kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system rollout restart deploy pushprox-server
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system rollout restart deploy pushprox-client

上記の手順で問題を解決できます。問題が解決した 1.12.2 以降にクラスタがアップグレードされたら、管理クラスタの kube-system monitoring-operator をスケールアップして、パイプラインを再度管理できるようにします。
```
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system scale deploy monitoring-operator --replicas=1
```

その他

1.11.3

`gkectl repair admin-master` で、復元に使用する VM テンプレートがない

gkectl repair admin-master コマンドが次のエラーで失敗しました。


Failed to repair: failed to select the template: no VM templates is available for repairing the admin master (check if the admin cluster version >= 1.4.0 or contact support

gkectl repair admin-master は、管理コントロールプレーン VM の名前の末尾の文字が t、m、p、l である場合、管理コントロールプレーン VM の修復に使用する VM テンプレートを取得できません。

回避策:

--skip-validation を指定してコマンドを再実行します。

ロギングとモニタリング

1.11, 1.12, 1.13, 1.14, 1.15

権限が拒否されたため Cloud Audit Logging が失敗する

Anthos Cloud Audit Logging には、現在 GKE Hub を使用しているユーザークラスタに対してのみ自動的に実行される特別な権限設定が必要です。 Cloud Audit Logging には、管理クラスタと同じプロジェクト ID とサービスアカウントを使用するユーザークラスタを少なくとも 1 つ設定することをおすすめします。これにより、Cloud Audit Logging に必要な権限が管理クラスタに付与されます。

ただし、管理クラスタがユーザークラスタごとに異なるプロジェクト ID またはサービスアカウントを使用している場合、管理クラスタの監査ログはクラウドに挿入できません。この症状は、管理クラスタの audit-proxy Pod 内の一連の Permission Denied エラーです。

回避策:

回避策を表示する

この問題を解決するには、cloudauditlogging Hub 機能を操作して権限を設定します。

まず、プロジェクトで Anthos Cloud Audit Logging の許可リストに登録されている既存のサービスアカウントを確認します。


curl -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features/cloudauditlogging

レスポンスに応じて、次のいずれかを行います。
- 404 Not_found エラーが発生した場合、このプロジェクト ID の許可リストに登録されたサービスアカウントがないことを意味します。cloudauditlogging Hub 機能を有効にすることで、サービスアカウントを許可リストに登録できます。
```
curl -X POST -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    -H "Content-Type: application/json" \
    https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features?feature_id=cloudauditlogging -d \
    '{"spec":{"cloudauditlogging":{"allowlistedServiceAccounts":["SERVICE_ACCOUNT_EMAIL"]}}}'
```
- "code": "OK" を指定した "lifecycleState": "ENABLED" と、allowlistedServiceAccounts でサービスアカウントのリストを含む機能仕様を受け取った場合は、このプロジェクトで許可されている既存のサービスアカウントが存在することを意味しており、クラスタ内のこのリストからのサービスアカウントを使用するか、許可リストに新しいサービスアカウントを追加できます。
```
curl -X PATCH -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    -H "Content-Type: application/json" \
    https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features/cloudauditlogging?update_mask=spec.cloudauditlogging.allowlistedServiceAccounts -d \
    '{"spec":{"cloudauditlogging":{"allowlistedServiceAccounts":["SERVICE_ACCOUNT_EMAIL"]}}}'
```
- "code": "FAILED" を指定した "lifecycleState": "ENABLED" を含む機能仕様を受け取った場合は、権限の設定が失敗したことを意味します。レスポンスの description フィールドで問題を解決するか、現在の許可リストをバックアップして cloudauditlogging Hub 機能を削除し、このセクションのステップ 1 に従って再度有効にしてください。cloudauditlogging Hub 機能は、次の方法で削除できます。
```
curl -X DELETE -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features/cloudauditlogging
```

上記のコマンドで:

PROJECT_ID は、クラスタの監査ロギングプロジェクトに置き換えます。
SERVICE_ACCOUNT_EMAIL は、クラスタの監査ロギングサービスアカウントのメールアドレスに置き換えます。

運用、セキュリティ

1.11

`gkectl diagnose` の証明書チェックの失敗

ワークステーションがユーザークラスタのワーカーノードにアクセスできない場合、gkectl diagnose を実行すると次のエラーが発生します。


Checking user cluster certificates...FAILURE
    Reason: 3 user cluster certificates error(s).
    Unhealthy Resources:
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out

ワークステーションが管理クラスタのワーカーノードまたは管理クラスタのワーカーノードにアクセスできない場合、gkectl diagnose を実行すると次のエラーが発生します。


Checking admin cluster certificates...FAILURE
    Reason: 3 admin cluster certificates error(s).
    Unhealthy Resources:
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out

回避策:

これらのメッセージは無視しても問題ありません。

オペレーティングシステム

1.8, 1.9, 1.10, 1.11, 1.12, 1.13

`/var/log/audit/` が管理ワークステーションのディスクスペースを占有する

/var/log/audit/ が監査ログでいっぱいになっています。ディスク使用量を確認するには、sudo du -h -d 1 /var/log/audit を実行します。

管理ワークステーション上の特定の gkectl コマンド（たとえば、gkectl diagnose snapshot）は、ディスク使用量に影響します。

Anthos v1.8 以降では、Ubuntu イメージが CIS レベル 2 のベンチマークで強化されています。コンプライアンスルールの 1 つである「4.1.2.2 監査ログが自動的に削除されないことを確認する」では、auditd の設定 max_log_file_action = keep_logs を確認します。これにより、すべての監査ルールがディスクに保持されます。

回避策:

回避策を表示する

管理ワークステーション

管理ワークステーションの場合、auditd の設定を手動で変更してログを自動的にローテーションしてから、auditd サービスを再起動できます。


sed -i 's/max_log_file_action = keep_logs/max_log_file_action = rotate/g' /etc/audit/auditd.conf
sed -i 's/num_logs = .*/num_logs = 250/g' /etc/audit/auditd.conf
systemctl restart auditd

前述の設定では、監査ログが 250 個を超えるファイル（それぞれ 8M サイズ）を生成すると、auditd が自動的にログをローテーションします。

クラスタノード

クラスタノードの場合は、1.11.5 以降、1.12.4 以降、1.13.2 以降、1.14 以降にアップグレードします。まだそれらのバージョンにアップグレードできない場合は、次の DaemonSet をクラスタに適用します。


apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: change-auditd-log-action
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: change-auditd-log-action
  template:
    metadata:
      labels:
        app: change-auditd-log-action
    spec:
      hostIPC: true
      hostPID: true
      containers:
      - name: update-audit-rule
        image: ubuntu
        command: ["chroot", "/host", "bash", "-c"]
        args:
        - |
          while true; do
            if $(grep -q "max_log_file_action = keep_logs" /etc/audit/auditd.conf); then
              echo "updating auditd max_log_file_action to rotate with a max of 250 files"
              sed -i 's/max_log_file_action = keep_logs/max_log_file_action = rotate/g' /etc/audit/auditd.conf
              sed -i 's/num_logs = .*/num_logs = 250/g' /etc/audit/auditd.conf
              echo "restarting auditd"
              systemctl restart auditd
            else
              echo "auditd setting is expected, skip update"
            fi
            sleep 600
          done
        volumeMounts:
        - name: host
          mountPath: /host
        securityContext:
          privileged: true
      volumes:
      - name: host
        hostPath:
          path: /

この auditd 構成の変更は、CIS レベル 2 のルール「4.1.2.2 監査ログが自動的に削除されないことを確認する」に違反することに注意してください。

ネットワーキング

1.10, 1.11.0-1.11.3, 1.12.0-1.12.2, 1.13.0

`NetworkGatewayGroup` フローティング IP がノードアドレスと競合する

次の検証 Webhook エラーのため、ユーザーは NetworkGatewayGroup オブジェクトを作成または更新できません。


[1] admission webhook "vnetworkgatewaygroup.kb.io" denied the request: NetworkGatewayGroup.networking.gke.io "default" is invalid: [Spec.FloatingIPs: Invalid value: "10.0.0.100": IP address conflicts with node address with name: "my-node-name"

影響を受けるバージョンでは、kubelet がノードに割り当てられたフローティング IP アドレスに誤ってバインドされ、node.status.addresses のノードアドレスとして報告されます。検証 Webhook は、NetworkGatewayGroup フローティング IP アドレスをクラスタ内のすべての node.status.addresses と照合して、これを競合と見なします。

回避策:

NetworkGatewayGroup オブジェクトの作成または更新が失敗しているのと同じクラスタで、ANG 検証 Webhook を一時的に無効にして変更内容を送信します。

Webhook 構成ファイルを保存して、最後に復元できるようにします。


kubectl -n kube-system get validatingwebhookconfiguration \
    ang-validating-webhook-configuration -o yaml > webhook-config.yaml

Webhook 構成を編集します。


kubectl -n kube-system edit validatingwebhookconfiguration \
    ang-validating-webhook-configuration

Webhook 構成リストから vnetworkgatewaygroup.kb.io 項目を削除し、変更を適用するために閉じます。
NetworkGatewayGroup オブジェクトを作成または編集します。

元の Webhook 構成を再適用します。


kubectl -n kube-system apply -f webhook-config.yaml

インストール、アップグレード、更新

1.10.0-1.10.2

管理クラスタのタイムアウトの作成またはアップグレード

管理クラスタのアップグレード中に、管理コントロールプレーン VM が作成時に停止することがあります。管理コントロールプレーン VM は起動時に無限待機ループに入り、/var/log/cloud-init-output.log ファイルに次のような無限ループエラーが表示されます。


+ echo 'waiting network configuration is applied'
waiting network configuration is applied
++ get-public-ip
+++ ip addr show dev ens192 scope global
+++ head -n 1
+++ grep -v 192.168.231.1
+++ grep -Eo 'inet ([0-9]{1,3}\.){3}[0-9]{1,3}'
+++ awk '{print $2}'
++ echo
+ '[' -n '' ']'
+ sleep 1
+ echo 'waiting network configuration is applied'
waiting network configuration is applied
++ get-public-ip
+++ ip addr show dev ens192 scope global
+++ grep -Eo 'inet ([0-9]{1,3}\.){3}[0-9]{1,3}'
+++ awk '{print $2}'
+++ grep -v 192.168.231.1
+++ head -n 1
++ echo
+ '[' -n '' ']'
+ sleep 1

これは、Anthos clusters on VMware が起動スクリプトでノード IP アドレスを取得しようとすると、grep -v ADMIN_CONTROL_PLANE_VIP を使用して NIC にも割り当て可能な管理クラスタコントロールプレーン VIP をスキップするためです。ただし、コマンドは、コントロールプレーン VIP の接頭辞を持つ IP アドレスもスキップするため、起動スクリプトがハングアップします。

たとえば、管理クラスタのコントロールプレーン VIP が 192.168.1.25 であるとします。管理クラスタコントロールプレーン VM の IP アドレスに同じ接頭辞（192.168.1.254 など）がある場合、作成時にコントロールプレーン VM がスタックします。ブロードキャストアドレスのコントロールプレーン VIP と同じ接頭辞（192.168.1.255 など）がある場合、この問題が発生する可能性があります。

回避策:

管理クラスタ作成タイムアウトがブロードキャスト IP アドレスによるものである場合は、管理クラスタのコントロールプレーン VM で次のコマンドを実行します。
```
ip addr add ${ADMIN_CONTROL_PLANE_NODE_IP}/32 dev ens192
```
これにより、ブロードキャストアドレスのない行が作成され、起動プロセスのブロックを解除できます。起動スクリプトのブロックを解除したら、次のコマンドを実行して、追加された行を削除します。
```
ip addr del ${ADMIN_CONTROL_PLANE_NODE_IP}/32 dev ens192
```
ただし、管理クラスタ作成タイムアウトの原因がコントロールプレーン VM の IP アドレスの場合、起動スクリプトのブロックを解除することはできません。別の IP アドレスに切り替えて再作成するか、バージョン 1.10.3 以降にアップグレードします。

オペレーティングシステム、アップグレード、アップデート

1.10.0-1.10.2

COS イメージを使用した管理クラスタの状態（プレビュー機能）が、管理クラスタのアップグレードまたは管理マスターの修復時に失われる

COS イメージを使用している場合、DataDisk は管理クラスタのマスターノードに正しくマウントされず、COS イメージを使用する管理クラスタの状態が、管理クラスタのアップグレードまたは管理マスターの修復時に失われます。（COS イメージを使用した管理クラスタはプレビュー機能です）

回避策:

osImageType を ubuntu_containerd に設定して管理クラスタを再作成する

osImageType を cos に設定した管理クラスタを作成したら、管理クラスタの SSH 認証鍵を取得して管理マスターノードに SSH 接続します。 df -h の結果には /dev/sdb1 98G 209M 93G 1% /opt/data が含まれます。lsblk の結果には -sdb1 8:17 0 100G 0 part /opt/data が含まれます。

オペレーティングシステム

1.10

`.local` ドメインで、systemd-resolved が DNS ルックアップに失敗した

Anthos clusters on VMware バージョン 1.10.0 では、Ubuntu の名前解決は、デフォルトで 127.0.0.53 でリッスンするローカルの systemd-resolve にルーティングされます。これは、バージョン 1.10.0 で使用される Ubuntu 20.04 イメージで、/etc/resolv.conf が 127.0.0.53 localhost DNS スタブを指す /run/systemd/resolve/stub-resolv.conf にシンボリックリンクされているためです。

その結果、名前が検索ドメインとして指定されていない限り、localhost DNS 名前解決では、名前が .local 接尾辞を持つアップストリーム DNS サーバー（/run/systemd/resolve/resolv.conf で指定）の確認が拒否されます。

これにより、.local 名の検索はすべて失敗します。たとえば、ノードの起動時に、kubelet は .local 接尾辞が付いた非公開レジストリからイメージの pull に失敗します。.local 接尾辞を持つ vCenter アドレスを指定しても、管理ワークステーションでは動作しません。

回避策:

クラスタノードのこの問題は、管理クラスタの構成ファイルとユーザークラスタ構成ファイルで searchDomainsForDNS フィールドを指定してドメインを含めると回避できます。

現在、gkectl update は searchDomainsForDNS フィールドの更新をまだサポートしていません。

したがって、クラスタを作成する前にこのフィールドを設定していない場合は、ノードに SSH で接続し、/etc/resolv.conf のシンボリックリンクを /run/systemd/resolve/stub-resolv.conf（127.0.0.53 ローカルスタブを含む）から /run/systemd/resolve/resolv.conf（実際のアップストリーム DNS を指す）に変更することでローカルの systemd-resolved スタブを迂回する必要があります。


sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf

管理ワークステーションの場合、gkeadm では検索ドメインの指定がサポートされていないため、この問題を手動で回避する必要があります。

注: このソリューションは、VM の再作成では保持されません。VM が再作成されるたびに、この回避策を再適用する必要があります。

インストール、オペレーティングシステム

1.10

Docker ブリッジ IP は `172.17.0.1/16` ではなく `169.254.123.1/24` を使用する

Anthos clusters on VMware は、--bip=169.254.123.1/24 を使用する Docker ブリッジの IP アドレス専用のサブネットを指定します。これにより、デフォルトの 172.17.0.1/16 サブネットは予約されません。ただし、バージョン 1.10.0 では、Ubuntu OS イメージにバグがあり、カスタマイズされた Docker 構成が無視されています。

その結果として、Docker はデフォルトの 172.17.0.1/16 をブリッジ IP アドレスサブネットとして選択します。この IP アドレス範囲内にすでに実行中のワークロードがある場合、IP アドレスの競合が発生する可能性があります。

回避策:

この問題を回避するには、次の systemd 構成ファイルを dockerd 用に名前変更した後、サービスを再起動する必要があります。


sudo mv /etc/systemd/system/docker.service.d/50-cloudimg-settings.cfg \
    /etc/systemd/system/docker.service.d/50-cloudimg-settings.conf

sudo systemctl daemon-reload

sudo systemctl restart docker

Docker が正しいブリッジ IP アドレスを選択していることを確認します。


ip a | grep docker0

注: このソリューションは、VM の再作成では保持されません。VM が再作成されるたびに、この回避策を再適用する必要があります。

アップグレードと更新

1.11

Stackdriver の準備状況によって 1.11 へのアップグレード

Anthos clusters on VMware バージョン 1.11.0 では、ロギングとモニタリングに関連するカスタムリソースの定義が変更されています。

stackdriver カスタムリソースのグループ名が addons.sigs.k8s.io から addons.gke.io に変更されました。
monitoring および metricsserver カスタムリソースのグループ名を addons.k8s.io から addons.gke.io に変更しました。
上記のリソースの仕様は、そのスキーマに対して検証されます。特に、stackdriver カスタムリソースの resourceAttrOverride と storageSizeOverride 仕様には、CPU、メモリ、ストレージサイズのリクエストと制限の値に文字列型が必要です。

グループ名の変更は、Kubernetes 1.22 の CustomResourceDefinition の更新に準拠して行われます。

影響を受けるカスタムリソースを適用または編集する追加のロジックがない場合は、アクションは不要です。Anthos clusters on VMware のアップグレードプロセスは、影響を受けるリソースの移行を処理し、グループ名の変更後も既存の仕様を保持します。

ただし、影響を受けるリソースを適用または編集するロジックを実行する場合は、特別な注意が必要です。まず、マニフェストファイルの新しいグループ名で参照する必要があります。次に例を示します。


apiVersion: addons.gke.io/v1alpha1  ## instead of `addons.sigs.k8s.io/v1alpha1`
kind: Stackdriver

次に、resourceAttrOverride と storageSizeOverride の仕様値が string 型であることを確認します。次に例を示します。


spec:
  resourceAttrOverride:
    stackdriver-log-forwarder/stackdriver-log-forwarder
      limits:
        cpu: 1000m # or "1"
        # cpu: 1 # integer value like this would not work
        memory: 3000Mi

そうしないと、適用と編集が有効ではなく、ロギングとモニタリングのコンポーネントで予期しないステータスが発生する可能性があります。次のような症状が考えられます。

onprem-user-cluster-controller の調整エラーログ。例:


potential reconciliation error: Apply bundle components failed, requeue after 10s, error: failed to apply addon components: failed to apply bundle objects from stackdriver-operator-addon 1.11.2-gke.53 to cluster my-cluster: failed to create typed live object: .spec.resourceAttrOverride.stackdriver-log-forwarder/stackdriver-log-forwarder.limits.cpu: expected string, got &value.valueUnstructured{Value:1}

kubectl edit stackdriver stackdriver の失敗。例:


Error from server (NotFound): stackdrivers.addons.gke.io "stackdriver" not found

上記のエラーが発生した場合は、アップグレード前に Stackdriver CR 仕様でサポートされていないタイプが存在しています。回避策として、古いグループ名 kubectl edit stackdrivers.addons.sigs.k8s.io stackdriver の Stackdriver CR を手動で編集して、次の操作を行います。

リソースリクエストとリソース制限を文字列型に変更します。
addons.gke.io/migrated-and-deprecated: true アノテーションがあれば削除します。

アップグレードプロセスを再開または再起動します。

オペレーティングシステム

1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13, 1.14, 1.15

ホストの正常なシャットダウンを介して VM が移動された場合、COS VM には IP は表示されません

ESXi サーバーに障害があり、サーバーで vCenter HA 機能が有効になっている場合、障害のある ESXi サーバー内のすべての VM が vMotion メカニズムをトリガーし、別の通常の ESXi サーバーに移動します。移行した COS VM の IP が失われます。

回避策:

VM を再起動する

さらにサポートが必要な場合は、Google サポートにお問い合わせください。

Anthos clusters on VMware

優先度クラスがないため、Anthos Network Gateway コンポーネントが強制排除または保留中になる

gcloud にクラスタを登録した後、管理クラスタのアップグレードが失敗する

gkectl diagnose snapshot --log-since が、クラスタノードで実行されている journalctl コマンドの時間枠を制限できない

gkectl prepare windows 失敗します。

ubuntu ノードでは RootDistanceMaxSec の構成が有効にならない

osImageType フィールドが空のため、gkectl update admin が失敗する

SNI は、コントロール プレーン V2 のユーザー クラスタで動作しません

非公開レジストリのユーザー名で $ を行うと、管理コントロール プレーンのマシンの起動に失敗する

管理クラスタの更新中にサポートされていない変更に関する誤検出の警告

KSA 署名鍵のローテーション後にユーザー クラスタを更新できない

Terraform がユーザー クラスタを削除しても、F5 BIG-IP 仮想サーバーがクリーンアップされない

kind クラスタが docker.io からコンテナ イメージを pull する

ネットワークで重複する GARP リクエストが除外されていると、HA コントロール プレーン V2 のユーザー クラスタと管理クラスタでフェイルオーバーが失敗する

vCenter 証明書のローテーション後に vsphere-csi-controller を再起動する必要がある

クラスタ登録のエラーによって管理クラスタの作成に失敗しない

管理クラスタのアップグレード中に管理クラスタの再登録がスキップされる

vCenter.dataDisk に関する誤ったエラー メッセージ

VM ホスト アフィニティ ルールが冗長であるためノードプールの作成に失敗する

failed to delete the admin master node object and reboot the admin master VM が原因で gkectl repair admin-master が失敗する可能性があります。

コントロール プレーン ノードの再作成または更新後に Pod が失敗状態のままになる

非公開レジストリの認証情報が原因で OnPremUserCluster の準備ができていない

gkectl upgrade admin が StorageClass standard sets the parameter diskformat which is invalid for CSI Migration で失敗する

Windows ファイル システムを使用して移行された in-tree vSphere ボリュームは、vSphere CSI ドライバでは使用できません。

vsphere-csi-secret が gkectl update credentials vsphere --admin-cluster の後に更新されない

gkectl update cluster で Cloud Audit Logs を有効にするときに audit-proxy がクラッシュ ループする

gkectl upgrade cluster の直後に追加のコントロール プレーンを再デプロイする

不正なリリース 1.12.7-gke.19 が削除されました。

gke-connect-agent では、レジストリ認証情報の更新後も引き続き古いイメージが使用されます

手動による LB 構成チェックの失敗

etcd ウォッチの不足

Anthos Identity Service がコントロール プレーンのレイテンシを引き起こす可能性がある

etcd-Maintenance Pod のメモリ使用量の増加の問題

ユーザー クラスタ コントロール プレーン Pod のヘルスチェックが失敗する

1.6 と 1.7 の管理クラスタのアップグレードは、k8s.gcr.io -> registry.k8s.io リダイレクトの影響を受ける可能性があります。

ロードバランサ作成時の Seesaw 検証の失敗

conntrack テーブル挿入エラーによるアプリケーション タイムアウト

コントロール プレーン v2 の Windows ノードでの calico-typha または anetd-operator クラッシュ ループ

ユーザー クラスタの非公開レジストリの認証情報ファイルを読み込めない

Dataplane v2 と互換性のない Anthos Service Mesh と他のサービス メッシュ

kube-controller-manager は、6 分後に永続ボリュームを強制的に切断する可能性があります。

サードパーティの CSI ドライバが使用されていると、クラスタのアップグレードが停止する

gkectl repair admin-master は、VM ハードウェアのバージョンをアップグレードせずに管理マスター VM を作成します。

VM がシャットダウンおよび再起動時に DHCP リースを予期せずリリースすると、IP が変更される可能性がある

管理クラスタが 1.11.x からアップグレードされた後に、コンポーネント アクセス サービス アカウント キーが消去される

コントロール プレーン V2 が有効な場合、クラスタ オートスケーラーが動作しない

CIDR ブロック ファイルで CIDR は使用できません。

admin-cluster.yaml の OS イメージタイプの更新は、ユーザー コントロール プレーンのマシンが再作成されるのを待機しない

Calico CNI サービス アカウントの認証トークンの問題による Pod の作成または削除エラー

CIDR を使用すると IP ブロックの検証が失敗する

管理クラスタのバックアップには、常時オンのシークレット暗号鍵と構成は含まれていません

回避策:

管理 マスター VM の新しいブートディスク（たとえばgkectl repair admin-master）は、gkectl update コマンドを使用して常時オンシークレット暗号化機能が有効になっている場合に失敗します。

最初のユーザー クラスタを 1.9 から 1.10 にアップグレードすると、他のユーザー クラスタのノードを再作成します

回避策を表示する

クラスタのアップグレード後に Docker が頻繁に再起動する

バージョン 1.12 へのアップグレード後に自己デプロイ型 GMP コンポーネントが保持されない

クラスタ スナップショットの system シナリオに ClusterAPI オブジェクトがない

vSAN の設定でユーザー クラスタの削除がノードのドレインから先に進まない

Cluster Autoscaler クラスタロール バインディングとクラスタロールは、ユーザー クラスタを削除した後に削除されます。

回避策を表示する

ユーザー クラスタの削除後に管理クラスタ cluster-health-controller と vsphere-metrics-exporter が機能しない

回避策を表示する

gkectl check-config が OS イメージの検証で失敗する

アンチ アフィニティ グループの更新に gkectl update admin/cluster が失敗する

回避策を表示する

ユーザー ワーカーノードを再作成するには

ユーザー マスターノードを再作成するには

管理アドオンノードを再作成するには

構成されたホスト名にピリオドが含まれている場合はノードの登録に失敗する

プライベート レジストリ証明書バンドルによる管理コントロール プレーン マシンの起動の失敗

NetworkGatewayNodes同時ステータス更新の競合状態から NetworkGatewayNode が異常とマークされる

競合状態は、更新中または更新中にマシン オブジェクトの削除をブロックする

gkectl gkectl prepare OS イメージ検証のプリフライトの失敗

https:// 接頭辞または http:// 接頭辞を持つ vCenter URL はクラスタの起動エラーを引き起こす可能性がある

util.CheckFileExists の gkectl prepare のパニック

gkectl repair admin-master と再開可能な管理者アップグレードは連携しません

管理クラスタのアップグレードを再開すると、管理コントロール プレーンの VM テンプレートがなくなる可能性がある

cgroup v2 がワークロードに影響する可能性がある

ClientConfig のカスタム リソース

`gkectl diagnose snapshot --log-since` が、クラスタノードで実行されている `journalctl` コマンドの時間枠を制限できない

`gkectl prepare windows` 失敗します。

`ubuntu` ノードでは `RootDistanceMaxSec` の構成が有効にならない

`osImageType` フィールドが空のため、`gkectl update admin` が失敗する

SNI は、コントロールプレーン V2 のユーザークラスタで動作しません

非公開レジストリのユーザー名で `$` を行うと、管理コントロールプレーンのマシンの起動に失敗する

KSA 署名鍵のローテーション後にユーザークラスタを更新できない

Terraform がユーザークラスタを削除しても、F5 BIG-IP 仮想サーバーがクリーンアップされない

kind クラスタが `docker.io` からコンテナイメージを pull する

ネットワークで重複する GARP リクエストが除外されていると、HA コントロールプレーン V2 のユーザークラスタと管理クラスタでフェイルオーバーが失敗する

vCenter 証明書のローテーション後に `vsphere-csi-controller` を再起動する必要がある

`vCenter.dataDisk` に関する誤ったエラーメッセージ

VM ホストアフィニティルールが冗長であるためノードプールの作成に失敗する

`failed to delete the admin master node object and reboot the admin master VM` が原因で `gkectl repair admin-master` が失敗する可能性があります。

コントロールプレーンノードの再作成または更新後に Pod が失敗状態のままになる

`gkectl upgrade admin` が `StorageClass standard sets the parameter diskformat which is invalid for CSI Migration` で失敗する

Windows ファイルシステムを使用して移行された in-tree vSphere ボリュームは、vSphere CSI ドライバでは使用できません。

`vsphere-csi-secret` が `gkectl update credentials vsphere --admin-cluster` の後に更新されない

`gkectl update cluster` で Cloud Audit Logs を有効にするときに `audit-proxy` がクラッシュループする

`gkectl upgrade cluster` の直後に追加のコントロールプレーンを再デプロイする

`gke-connect-agent` では、レジストリ認証情報の更新後も引き続き古いイメージが使用されます

Anthos Identity Service がコントロールプレーンのレイテンシを引き起こす可能性がある

ユーザークラスタコントロールプレーン Pod のヘルスチェックが失敗する

1.6 と 1.7 の管理クラスタのアップグレードは、`k8s.gcr.io` -> `registry.k8s.io` リダイレクトの影響を受ける可能性があります。

conntrack テーブル挿入エラーによるアプリケーションタイムアウト

コントロールプレーン v2 の Windows ノードでの calico-typha または anetd-operator クラッシュループ

ユーザークラスタの非公開レジストリの認証情報ファイルを読み込めない

Dataplane v2 と互換性のない Anthos Service Mesh と他のサービスメッシュ

`kube-controller-manager` は、6 分後に永続ボリュームを強制的に切断する可能性があります。

`gkectl repair admin-master` は、VM ハードウェアのバージョンをアップグレードせずに管理マスター VM を作成します。

管理クラスタが 1.11.x からアップグレードされた後に、コンポーネントアクセスサービスアカウントキーが消去される

コントロールプレーン V2 が有効な場合、クラスタオートスケーラーが動作しない

CIDR ブロックファイルで CIDR は使用できません。

admin-cluster.yaml の OS イメージタイプの更新は、ユーザーコントロールプレーンのマシンが再作成されるのを待機しない

Calico CNI サービスアカウントの認証トークンの問題による Pod の作成または削除エラー

管理マスター VM の新しいブートディスク（たとえば`gkectl repair admin-master`）は、gkectl update コマンドを使用して常時オンシークレット暗号化機能が有効になっている場合に失敗します。

最初のユーザークラスタを 1.9 から 1.10 にアップグレードすると、他のユーザークラスタのノードを再作成します

クラスタスナップショットの `system` シナリオに ClusterAPI オブジェクトがない

vSAN の設定でユーザークラスタの削除がノードのドレインから先に進まない

`Cluster Autoscaler` クラスタロールバインディングとクラスタロールは、ユーザークラスタを削除した後に削除されます。

ユーザークラスタの削除後に管理クラスタ `cluster-health-controller` と `vsphere-metrics-exporter` が機能しない

`gkectl check-config` が OS イメージの検証で失敗する

アンチアフィニティグループの更新に `gkectl update admin/cluster` が失敗する

ユーザーワーカーノードを再作成するには

ユーザーマスターノードを再作成するには

プライベートレジストリ証明書バンドルによる管理コントロールプレーンマシンの起動の失敗

`NetworkGatewayNodes`同時ステータス更新の競合状態から NetworkGatewayNode が異常とマークされる

競合状態は、更新中または更新中にマシンオブジェクトの削除をブロックする

`gkectl`　gkectl prepare OS イメージ検証のプリフライトの失敗

`https://` 接頭辞または `http://` 接頭辞を持つ vCenter URL はクラスタの起動エラーを引き起こす可能性がある

`util.CheckFileExists` の `gkectl prepare` のパニック

`gkectl repair admin-master` と再開可能な管理者アップグレードは連携しません

管理クラスタのアップグレードを再開すると、管理コントロールプレーンの VM テンプレートがなくなる可能性がある

ClientConfig のカスタムリソース

`gkectl check-config` 検証が失敗: F5 BIG-IP パーティションが見つからない

cert-manager/ca-injector のリーダー選出の問題により、ユーザークラスタのインストールが失敗した

`cert-manager` のインストールが競合している

管理者クラスタとユーザークラスタの間のネットワーク接続は、非 HA クラスタのアップグレード中に短時間使用できなくなる場合があります

`/etc/cron.daily/aide` CPU とメモリの急増に関する問題

ロードバランサと NSX-T ステートフル分散ファイアウォールルールが予期しない動作をする。

monitoring.googleapis.com への高いネットワークトラフィック

`gke-metrics-agent` で CrashLoopBackOff エラーが頻繁に発生する

管理クラスタにスケジューラとコントローラマネージャーの指標がない

ユーザークラスタにスケジューラとコントローラマネージャーの指標がない

emptyDir ボリュームを、COS ノードで実行されている Pod に `exec` としてマウントできない

ノードプールで自動スケーリングが無効にした後、クラスタノードプールのレプリカの更新が機能しない

Windows モニタリングダッシュボードに Linux クラスタからのデータが表示される

定数 CrashLoopBackOff 内の `stackdriver-log-forwarder`

`stackdriver-log-forwarder` は、Cloud Logging にログを送信しません

管理クラスタのアップグレードで、後のユーザークラスタのアップグレードがブロックされない

管理クラスタが MetalLB ロードバランサを使用している場合、新しいユーザークラスタを追加できない

ユーザークラスタに Container-Optimized OS（COS）を使用しているときに障害が発生する

管理クラスタ内の Grafana がユーザークラスタに到達できない

`gkectl repair admin-master` で、復元に使用する VM テンプレートがない

`gkectl diagnose` の証明書チェックの失敗

`/var/log/audit/` が管理ワークステーションのディスクスペースを占有する

`NetworkGatewayGroup` フローティング IP がノードアドレスと競合する

`.local` ドメインで、systemd-resolved が DNS ルックアップに失敗した

Docker ブリッジ IP は `172.17.0.1/16` ではなく `169.254.123.1/24` を使用する