GKE on VMware の既知の問題

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

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

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

または問題を検索します。

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

update

1.28.0-1.28.400、1.29.0

標準の CNI で複数のネットワークインターフェースを使用できない

標準の CNI バイナリ bridge, ipvlan, vlan, macvlan, dhcp, tuning, host-local, ptp, portmap は、影響を受けるバージョンの OS イメージには含まれていません。これらの CNI バイナリはデータプレーン v2 では使用されませんが、複数ネットワークインターフェース機能の追加のネットワークインターフェースに使用されます。

これらの CNI プラグインを使用した複数のネットワークインターフェースは動作しません。

回避策:

この機能を使用している場合は、修正を含むバージョンにアップグレードしてください。

update

1.15、1.16、1.28

Netapp Trident の依存関係が vSphere CSI ドライバと干渉する

クラスタノードに multipathd をインストールすると、vSphere CSI ドライバの動作が妨げられ、ユーザーワークロードを起動できなくなります。

回避策:

multipathd の無効化

更新

1.15, 1.16

必要な構成を追加すると、管理クラスタの Webhook によって更新がブロックされることがある

検証がスキップされたために管理クラスタで必要な構成が空の場合、管理クラスタ Webhook によって追加がブロックされることがあります。たとえば、既存の管理クラスタで gkeConnect フィールドが設定されていない場合、gkectl update admin コマンドでこのフィールドを追加すると、次のエラーメッセージが表示される場合があります。


admission webhook "vonpremadmincluster.onprem.cluster.gke.io" denied the request: connect: Required value: GKE connect is required for user clusters

回避策:

1.15 管理クラスタの場合は、--disable-admin-cluster-webhook フラグを指定して gkectl update admin コマンドを実行します。次のような例になります。
```
        gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig ADMIN_CLUSTER_KUBECONFIG --disable-admin-cluster-webhook
        
```
1.16 管理クラスタの場合は、--force フラグを指定して gkectl update admin コマンドを実行します。次のような例になります。
```
        gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig ADMIN_CLUSTER_KUBECONFIG --force
        
```

構成

1.15.0-1.15.10, 1.16.0-1.16.6, 1.28.0-1.28.200

`manualLB` 仕様が空の場合、`controlPlaneNodePort` フィールドのデフォルトが 30968 になる

手動ロードバランサ（loadBalancer.kind が "ManualLB" に設定されている場合）を使用する場合は、バージョン 1.16 以降の高可用性（HA）管理クラスタの構成ファイルの loadBalancer.manualLB セクションを構成する必要はありません。ただし、このセクションが空の場合、GKE on VMware は manualLB.controlPlaneNodePort を含むすべての NodePort にデフォルト値を割り当てるため、クラスタの作成は失敗し、次のエラーメッセージが表示されます。


- Validation Category: Manual LB
  - [FAILURE] NodePort configuration: manualLB.controlPlaneNodePort must
   not be set when using HA admin cluster, got: 30968

回避策:

HA 管理クラスタの管理クラスタ構成で、manualLB.controlPlaneNodePort: 0 を指定します。


loadBalancer:
  ...
  kind: ManualLB
  manualLB:
    controlPlaneNodePort: 0
  ...

ストレージ

1.28.0-1.28.100

Ubuntu OS イメージに nfs-common がありません

Ubuntu OS イメージに nfs-common がありません。これにより、NetApp などの NFS に依存するドライバを使用している場合に問題が発生する可能性があります。

1.28 にアップグレードした後にログに次のようなエントリが含まれている場合、この問題の影響を受けています。


Warning FailedMount 63s (x8 over 2m28s) kubelet MountVolume.SetUp failed for volume "pvc-xxx-yyy-zzz" : rpc error: code = Internal desc = error mounting NFS volume 10.0.0.2:/trident_pvc_xxx-yyy-zzz on mountpoint /var/lib/kubelet/pods/aaa-bbb-ccc/volumes/kubernetes.io~csi/pvc-xxx-yyy-zzz/mount: exit status 32".

回避策:

ノードが Canonical からパッケージをダウンロードできることを確認します。

次に、以下の DaemonSet をクラスタに適用して、nfs-common をインストールします。


apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: install-nfs-common
  labels:
    name: install-nfs-common
  namespace: kube-system
spec:
  selector:
    matchLabels:
      name: install-nfs-common
  minReadySeconds: 0
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 100%
  template:
    metadata:
      labels:
        name: install-nfs-common
    spec:
      hostPID: true
      hostIPC: true
      hostNetwork: true
      initContainers:
      - name: install-nfs-common
        image: ubuntu
        imagePullPolicy: IfNotPresent
        securityContext:
          privileged: true
        command:
        - chroot
        - /host
        - bash
        - -c
        args:
        - |
          apt install -y nfs-common
        volumeMounts:
        - name: host
          mountPath: /host
      containers:
      - name: pause
        image: gcr.io/gke-on-prem-release/pause-amd64:3.1-gke.5
        imagePullPolicy: IfNotPresent
      volumes:
      - name: host
        hostPath:
          path: /

ストレージ

1.28.0-1.28.100

管理クラスタの構成テンプレートにストレージポリシーフィールドがありません

管理クラスタ内の SPBM は、1.28.0 以降のバージョンでサポートされています。しかし、構成ファイルのテンプレートは vCenter.storagePolicyName フィールドがありません。

回避策:

管理クラスタのストレージポリシーを構成する場合は、管理クラスタ構成ファイルに「vCenter.storagePolicyName」フィールドを追加します。手順をご確認ください。

ロギングとモニタリング

1.28.0-1.28.100

Kubernetes Metadata API は VPC-SC をサポートしていません

最近追加された API kubernetesmetadata.googleapis.com は、VPC-SC をサポートしていません。そのため、メタデータ収集エージェントが VPC-SC の下のこの API に到達できなくなります。その後、指標のメタデータラベルが失われます。

回避策:

次のコマンドを実行して、「kube-system」名前空間で CR「stackdriver」で「featureGates.disableExperimentalMetadataAgent」フィールドを「true」に設定します。

`kubectl -n kube-system patch stackdriver stackdriver -p '{"spec":{"featureGates":{"disableExperimentalMetadataAgent":true}}}'`

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

`kubectl -n kube-system patch deployment stackdriver-operator -p '{"spec":{"template":{"spec":{"containers":[{"name":"stackdriver-operator","env":[{"name":"ENABLE_LEGACY_METADATA_AGENT","value":"true"}]}]}}}}'`

アップグレードと更新

1.15.0-1.15.7、1.16.0-1.16.4、1.28.0

管理クラスタとコントロールプレーン V2 が有効になっているユーザークラスタが、異なる vSphere 認証情報を使用すると、clusterapi-controller がクラッシュすることがある

管理クラスタとコントロールプレーン V2 が有効になっているユーザークラスタが、異なる vSphere 認証情報を使用する場合（たとえば、管理クラスタの vSphere 認証情報を更新した後）、再起動後に clusterapi-controller が vCenter に接続できないことがあります。管理クラスタの「kube-system」名前空間で実行されている clusterapi-controller のログを表示します。


kubectl logs -f -l component=clusterapi-controllers -c vsphere-controller-manager \
    -n kube-system --kubeconfig KUBECONFIG

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


E1214 00:02:54.095668       1 machine_controller.go:165] Error checking existence of machine instance for machine object gke-admin-node-77f48c4f7f-s8wj2: Failed to check if machine gke-admin-node-77f48c4f7f-s8wj2 exists: failed to find datacenter "VSPHERE_DATACENTER": datacenter 'VSPHERE_DATACENTER' not found

回避策:

vSphere 認証情報を更新して、管理クラスタとコントロールプレーン V2 が有効になっているすべてのユーザークラスタが同じ vSphere 認証情報を使用するようにします。

ロギングとモニタリング

1.14

Prometheus Alert Manager で etcd の失敗した GRPC リクエスト数が多い

Prometheus は、次の例のようなアラートを報告する場合があります。


Alert Name: cluster:gke-admin-test1: Etcd cluster kube-system/kube-etcd: 100% of requests for Watch failed on etcd instance etcd-test-xx-n001.

このアラートが無視できる誤検出であるかどうかを確認するには、次の手順を行います。

未加工の grpc_server_handled_total 指標を、アラートメッセージで指定された grpc_method と照合します。この例では、Watch の grpc_code ラベルを確認します。

この指標は、次の MQL クエリで Cloud Monitoring を使用して確認できます。
```
fetch
    k8s_container | metric 'kubernetes.io/anthos/grpc_server_handled_total' | align rate(1m) | every 1m
```
コードが次のいずれかでない場合、OK 以外のすべてのコードのアラートは無視しても問題ありません。
```
Unknown|FailedPrecondition|ResourceExhausted|Internal|Unavailable|DataLoss|DeadlineExceeded
```

回避策:

こうした誤検出のアラートを無視するように Prometheus を構成するには、次のオプションを確認します。

Alert Manager の UI からアラートをミュートします。
アラートのミュートが選択できない場合は、次の手順で誤検出を抑制します。
1. 変更を維持できるように、モニタリングオペレーターを 0 レプリカにスケールダウンします。
2. 次の例に示すように、prometheus-config configmap を変更して、etcdHighNumberOfFailedGRPCRequests アラート構成に grpc_method!="Watch" を追加します。
  - オリジナル:
```
rate(grpc_server_handled_total{cluster="CLUSTER_NAME",grpc_code!="OK",job=~".*etcd.*"}[5m])
```
  - 最終更新:
```
rate(grpc_server_handled_total{cluster="CLUSTER_NAME",grpc_code=~"Unknown|FailedPrecondition|ResourceExhausted|Internal|Unavailable|DataLoss|DeadlineExceeded",grpc_method!="Watch",job=~".*etcd.*"}[5m])
```
    次の CLUSTER_NAME を使用するクラスタの名前に置き換えます。
3. Prometheus と Alertmanager Statefulset を再起動して、新しい構成を読み込みます。
コードが問題のあるケースのいずれかに該当する場合は、etcd ログと kube-apiserver ログを確認して、さらにデバッグしてください。

ネットワーキング

1.16.0-1.16.2, 1.28.0

下り（外向き）NAT の長時間接続が切断される

トラフィックがない場合、接続が確立されてから 5 ～ 10 分後に、下り（外向き）NAT 接続が切断されることがあります。

conntrack は受信方向（クラスタへの外部接続）でのみ重要であるため、この問題は、接続がしばらくの間情報を送信せず、宛先側で何かを送信する場合にのみ発生します。下り（外向き）NAT の Pod が常にメッセージをインスタンス化している場合、この問題は発生しません。

この問題は、anetd ガベージコレクションによって、デーモンが未使用と判断した conntrack エントリが誤って削除されるために発生します。最近、アップストリームの修正が anetd に組み込まれて、動作が修正されました。

回避策:

簡単な回避策はありません。また、バージョン 1.16 ではこの動作による問題は見られていません。この問題により、長時間接続が切断された場合、回避策として、下り（外向き）IP アドレスと同じノード上のワークロードを使用するか、TCP 接続でメッセージを一貫して送信します。

オペレーション

1.14、1.15、1.16

CSR 署名者が、証明書に署名するときに `spec.expirationSeconds` を無視する

expirationSeconds を設定して CertificateSigningRequest（CSR）を作成すると、expirationSeconds は無視されます。

回避策:

この問題の影響を受ける場合は、ユーザークラスタ構成ファイルに disableNodeIDVerificationCSRSigning: true を追加してユーザークラスタを更新し、gkectl update cluster コマンドを実行して、この構成でクラスタを更新します。

ネットワーキング、アップグレード、アップデート

1.16.0-1.16.3

`disable_bundled_ingress` でユーザークラスタのロードバランサの検証が失敗する

既存のクラスタに対してバンドルされた Ingress を無効化しようとすると、gkectl update cluster コマンドは次の例のようなエラーで失敗します。


[FAILURE] Config: ingress IP is required in user cluster spec

このエラーは、プリフライトチェック中に gkectl がロードバランサの上り（内向き）IP アドレスを確認するために発生します。バンドルされた Ingress を無効にする場合、このチェックは必要ありませんが、disableBundledIngress が true に設定されている場合、gkectl プリフライトチェックは失敗します。

回避策:

次の例に示すように、クラスタを更新するときに --skip-validation-load-balancer パラメータを使用します。


gkectl update cluster \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG  \
  --skip-validation-load-balancer

詳細については、既存のクラスタのバンドルされた Ingress を無効にするをご覧ください。

アップグレードと更新

1.13, 1.14, 1.15.0-1.15.6

CA のローテーション後に管理クラスタの更新が失敗する

管理クラスタの認証局（CA）証明書をローテーションすると、それ以降の gkectl update admin コマンドの実行は失敗します。返されるエラーは次のようになります。


failed to get last CARotationStage: configmaps "ca-rotation-stage" not found

回避策:

この問題の影響を受ける場合は、gkectl update admin コマンドで --disable-update-from-checkpoint フラグを使用して管理クラスタを更新できます。


gkectl update admin --config ADMIN_CONFIG_file \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --disable-update-from-checkpoint

--disable-update-from-checkpoint フラグを使用する場合、update コマンドはクラスタの更新中にチェックポイントファイルを信頼できる情報源として使用しません。チェックポイントファイルは、将来の使用のために引き続き更新されます。

ストレージ

1.15.0-1.15.6, 1.16.0-1.16.2

Pod の起動の失敗により、CSI ワークロードのプリフライトチェックが失敗する

プリフライトチェック中に、CSI ワークロード検証チェックにより、Pod が default 名前空間にインストールされます。CSI ワークロード Pod は、vSphere CSI ドライバがインストールされていることを確認し、動的なボリュームプロビジョニングを行います。この Pod が起動しない場合、CSI ワークロード検証チェックは失敗します。

この Pod の起動の妨げとなる既知の問題がいくつかあります。

Pod にリソース上限が指定されていない場合（アドミッション Webhook がインストールされている一部のクラスタの場合）、Pod は起動しません。
default 名前空間で自動 Istio サイドカーインジェクションが有効になっているクラスタに Anthos Service Mesh がインストールされている場合、CSI ワークロード Pod は起動しません。

CSI ワークロード Pod が起動しない場合は、プリフライト検証中に次のようなタイムアウトエラーが表示されます。


- [FAILURE] CSI Workload: failure in CSIWorkload validation: failed to create writer Job to verify the write functionality using CSI: Job default/anthos-csi-workload-writer-<run-id> replicas are not in Succeeded phase: timed out waiting for the condition

Pod リソースセットの不足が失敗の原因であるかどうかを確認するには、次のコマンドを実行して anthos-csi-workload-writer-<run-id> ジョブのステータスを確認します。


kubectl describe job anthos-csi-workload-writer-<run-id>

CSI ワークロード Pod のリソースの上限が正しく設定されていない場合、ジョブステータスの中に次のようなエラーメッセージが表示されます。


CPU and memory resource limits is invalid, as it are not defined for container: volume-tester

Istio サイドカーインジェクションが原因で CSI ワークロード Pod が起動しない場合は、default 名前空間で自動 Istio サイドカーインジェクションを一時的に無効にできます。名前空間のラベルを確認し、次のコマンドを使用して istio.io/rev で始まるラベルを削除します。


kubectl label namespace default istio.io/rev-

Pod が正しく構成されていない場合は、vSphere CSI ドライバを使用した動的ボリュームプロビジョニングが機能していることを手動で確認します。

standard-rwo StorageClass を使用する PVC を作成します。
PVC を使用する Pod を作成します。
Pod がボリュームに対してデータを読み書きできることを確認します。
適切な操作を確認したら、Pod と PVC を削除します。

vSphere CSI ドライバを使用した動的ボリュームプロビジョニングが機能する場合は、--skip-validation-csi-workload フラグを指定して gkectl diagnose または gkectl upgrade を実行し、CSI ワークロードチェックをスキップします。

オペレーション

1.16.0-1.16.2

ユーザー管理の管理ワークステーションにログオンすると、gkectl update cluster コマンドがタイムアウトしてユーザークラスタの更新に失敗することがあります。これは、管理クラスタのバージョンが 1.15 で、gkectl update cluster を実行する前に gkectl update admin を実行した場合に発生します。この障害が発生した場合、クラスタを更新しようとすると、次のエラーが表示されます。


      Preflight check failed with failed to run server-side preflight checks: server-side preflight checks failed: timed out waiting for the condition
Preflight check failed with failed to run server-side preflight checks: server-side preflight checks failed: timed out waiting for the condition

1.15 管理クラスタの更新中に、プリフライトチェックをトリガーする validation-controller がクラスタから削除されます。その後、ユーザークラスタを更新しようとすると、タイムアウトに達するまでプリフライトチェックがハングします。

回避策:

次のコマンドを実行して validation-controller を再デプロイします。


      gkectl prepare --kubeconfig ADMIN_KUBECONFIG --bundle-path BUNDLE_PATH --upgrade-platform

準備が完了したら、gkectl update cluster を再度実行してユーザークラスタを更新します。

オペレーション

1.16.0-1.16.2

ユーザー管理の管理ワークステーションにログオンすると、gkectl create cluster コマンドがタイムアウトしてユーザークラスタの作成に失敗することがあります。これは、管理クラスタのバージョンが 1.15 の場合に発生します。この障害が発生した場合、クラスタを作成しようとすると、次のエラーが表示されます。


      Preflight check failed with failed to run server-side preflight checks: server-side preflight checks failed: timed out waiting for the condition
Preflight check failed with failed to run server-side preflight checks: server-side preflight checks failed: timed out waiting for the condition

validation-controller が 1.16 で追加されたため、1.15 の管理クラスタを使用すると、プリフライトチェックをトリガーする役割を担う validation-controller が欠落しています。そのため、ユーザークラスタを作成しようとすると、タイムアウトに達するまでプリフライトチェックがハングします。

回避策:

次のコマンドを実行して validation-controller をデプロイします。


      gkectl prepare --kubeconfig ADMIN_KUBECONFIG --bundle-path BUNDLE_PATH --upgrade-platform

準備が完了したら、gkectl create cluster を再度実行してユーザークラスタを作成します。

アップグレードと更新

1.16.0-1.16.2

アドオンサービスのプロジェクトまたはロケーションが互いに一致しない場合、管理クラスタの更新またはアップグレードが失敗する

管理クラスタをバージョン 1.15.x から 1.16.x にアップグレードする場合、または、connect、stackdriver、cloudAuditLogging、または gkeOnPremAPI 構成を追加する場合、管理クラスタを更新すると、管理クラスタの Webhook によってオペレーションが拒否される場合があります。次のいずれかのエラーメッセージが表示される場合があります。

"projects for connect, stackdriver and cloudAuditLogging must be the same when specified during cluster creation."
"locations for connect, gkeOnPremAPI, stackdriver and cloudAuditLogging must be in the same region when specified during cluster creation."
"locations for stackdriver and cloudAuditLogging must be the same when specified during cluster creation."

管理クラスタの更新またはアップグレードでは、kind クラスタの管理クラスタを調整するために onprem-admin-cluster-controller が必要です。kind クラスタで管理クラスタの状態が復元されると、管理クラスタの Webhook は、OnPremAdminCluster オブジェクトが管理クラスタの作成用か、更新またはアップグレードのためにオペレーションを再開するかを区別できません。一部の作成専用検証は、更新やアップグレード時に予期せずに呼び出されます。

回避策:

onprem.cluster.gke.io/skip-project-location-sameness-validation: true アノテーションを OnPremAdminCluster オブジェクトに追加します。

onpremadminclusters クラスタリソースを編集します。
```
kubectl edit onpremadminclusters ADMIN_CLUSTER_NAME -n kube-system –kubeconfig ADMIN_CLUSTER_KUBECONFIG
```
以下を置き換えます。
- ADMIN_CLUSTER_NAME: 管理クラスタの名前。
- ADMIN_CLUSTER_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス
onprem.cluster.gke.io/skip-project-location-sameness-validation: true アノテーションを追加してカスタムリソースを保存します。
管理クラスタの種類に応じて、次のいずれかの手順を行います。
- チェックポイントファイルがある HA 以外の管理クラスタの場合: update コマンドにパラメータ disable-update-from-checkpoint を追加するか、upgrade コマンドにパラメータ「disable-upgrade-from-checkpooint」を追加します。これらのパラメータは、次回 update または upgrade コマンドを実行する場合にのみ必要です。
  - ```
  gkectl update admin --config ADMIN_CONFIG_file --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --disable-update-from-checkpoint
```
- ```
gkectl upgrade admin --config ADMIN_CONFIG_file --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --disable-upgrade-from-checkpoint
```
- HA 管理クラスタまたはチェックポイントファイルが無効になっている場合: 通常どおり管理クラスタを更新またはアップグレードします。update または upgrade コマンドに追加のパラメータは必要ありません。

オペレーション

1.16.0-1.16.2

ユーザー管理の管理ワークステーションを使用している場合、ユーザークラスタの削除に失敗する

ユーザー管理の管理ワークステーションにログオンすると、gkectl delete cluster コマンドがタイムアウトしてユーザークラスタの削除に失敗することがあります。これは、ユーザー管理のワークステーションで最初に gkectl を実行して、ユーザークラスタを作成、更新、またはアップグレードした場合に発生します。この障害が発生した場合、クラスタを削除しようとすると、次のエラーが表示されます。


      failed to wait for user cluster management namespace "USER_CLUSTER_NAME-gke-onprem-mgmt"
      to be deleted: timed out waiting for the condition

削除の際は、まずクラスタのすべてのオブジェクトが削除されます。Validation オブジェクト（作成、更新、アップグレード中に作成されたもの）の削除は、削除の段階で停止します。これは、ファイナライザがオブジェクトの削除をブロックすることにより、クラスタの削除が失敗するためです。

回避策:

すべての Validation オブジェクトの名前を取得します。


         kubectl  --kubeconfig ADMIN_KUBECONFIG get validations \
           -n USER_CLUSTER_NAME-gke-onprem-mgmt

Validation オブジェクトごとに、次のコマンドを実行して、Validation オブジェクトからファイナライザを削除します。
```
      kubectl --kubeconfig ADMIN_KUBECONFIG patch validation/VALIDATION_OBJECT_NAME \
        -n USER_CLUSTER_NAME-gke-onprem-mgmt -p '{"metadata":{"finalizers":[]}}' --type=merge
      
```
すべての Validation オブジェクトからファイナライザを削除した後、オブジェクトが削除され、ユーザークラスタの削除オペレーションは自動的に完了します。お客様側での対応は必要ありません。

ネットワーキング

1.15, 1.16

外部サーバーへの下り（外向き）NAT ゲートウェイトラフィックが失敗する

送信元 Pod と下り（外向き）NAT ゲートウェイ Pod が 2 つの異なるワーカーノードにある場合、送信元 Pod からのトラフィックは外部サービスに到達できません。Pod が同じホストにある場合、外部サービスまたはアプリケーションへの接続は成功します。

この問題は、トンネルアグリゲーションが有効になっているときに、vSphere が VXLAN パケットを破棄すると発生します。NSX と VMware には、既知の VXLAN ポート（4789）で集計されたトラフィックのみを送信する既知の問題があります。

回避策:

Cilium が使用する VXLAN ポートを 4789 に変更します。

cilium-config ConfigMap を編集します。


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

cilium-config ConfigMap に以下を追加します。
```
tunnel-port: 4789
```

anetd DaemonSet を再起動します。


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

この回避策は、クラスタがアップグレードされるたびに元に戻されます。各アップグレード後に再構成する必要があります。完全に修正するには、VMware が vSphere での問題を解決する必要があります。

アップグレード

1.15.0-1.15.4

常時オンのシークレット暗号化が有効になっている管理クラスタのアップグレードが失敗する

コントローラで生成された暗号鍵と、管理マスターデータディスク上で保持される鍵の不一致が原因で、常時オンのシークレット暗号化が有効になっている管理クラスタの 1.14.x から 1.15.x へのアップグレードが失敗します。gkectl upgrade admin の出力には、次のエラーメッセージが含まれます。


      E0926 14:42:21.796444   40110 console.go:93] Exit with error:
      E0926 14:42:21.796491   40110 console.go:93] Failed to upgrade the admin cluster: failed to create admin cluster: failed to wait for OnPremAdminCluster "admin-cluster-name" to become ready: failed to wait for OnPremAdminCluster "admin-cluster-name" to be ready: error: timed out waiting for the condition, message: failed to wait for OnPremAdminCluster "admin-cluster-name" to stay in ready status for duration "2m0s": OnPremAdminCluster "non-prod-admin" is not ready: ready condition is not true: CreateOrUpdateControlPlane: Creating or updating credentials for cluster control plane

kubectl get secrets -A --kubeconfig KUBECONFIG` を実行すると、次のエラーで失敗します。


      Internal error occurred: unable to transform key "/registry/secrets/anthos-identity-service/ais-secret": rpc error: code = Internal desc = failed to decrypt: unknown jwk

回避策

管理クラスタのバックアップがある場合は、次の手順でアップグレードの失敗を回避します。

管理クラスタの構成ファイルで secretsEncryption を無効にし、次のコマンドを使用してクラスタを更新します。
```
gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig KUBECONFIG
```
新しい管理マスター VM が作成されたら、管理マスター VM に SSH 接続し、データディスクの新しい鍵をバックアップの古い鍵に置き換えます。鍵は管理マスターの /opt/data/gke-k8s-kms-plugin/generatedkeys にあります。
/etc/kubernetes/manifests の kms-plugin.yaml 静的 Pod マニフェストを更新して、元の暗号鍵の kid フィールドと一致するように --kek-id を更新します。
/etc/kubernetes/manifests/kms-plugin.yaml を別のディレクトリに移動して kms-plugin 静的 Pod を再起動してから、それを元に戻します。
gkectl upgrade admin を再度実行して、管理のアップグレードを再開します。

アップグレードの失敗を防ぐ

まだアップグレードしていない場合は、1.15.0～1.15.4 にアップグレードしないことをおすすめします。影響を受けるバージョンにアップグレードする必要がある場合は、管理クラスタをアップグレードする前に次の手順を行います。

管理クラスタをバックアップします。
管理クラスタの構成ファイルで secretsEncryption を無効にし、次のコマンドを使用してクラスタを更新します。
```
gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig KUBECONFIG
```
管理クラスタをアップグレードします。
常時オンのシークレット暗号化を有効にします。

ストレージ

1.11-1.16

変更ブロックのトラッキング（CBT）の使用時のディスクエラーとアタッチの失敗

GKE on VMware は、ディスク上の変更ブロックのトラッキング（CBT）をサポートしていません。一部のバックアップソフトウェアは、CBT 機能を使用してディスクの状態を追跡し、バックアップを実行します。これにより、GKE on VMware を実行する VM にディスクが接続できなくなります。詳細については、VMware Knowledge Base の記事をご覧ください。

回避策:

サードパーティのバックアップソフトウェアを使用すると、ディスクで CBT が有効になる可能性があるため、GKE on VMware VM をバックアップしないでください。これらの VM をバックアップする必要はありません。

この変更はアップデートやアップグレード後に保持されないため、ノードで CBT を有効にしないでください。

CBT が有効になっているディスクがすでにある場合は、VMware Knowledge Base の記事の解決策の手順に沿って、ファーストクラスのディスクで CBT を無効にします。

ストレージ

1.14、1.15、1.16

共有ファイルへの並列追加が複数のホストから行われた場合の NFSv3 でのデータ破損

Nutanix ストレージアレイを使用して NFSv3 共有をホストに提供すると、データが破損したり、Pod が正常に動作しなくなったりする場合があります。この問題は、VMware と Nutanix の特定のバージョンの間の既知の互換性の問題が原因で発生します。詳細については、関連する VMware Knowledge Base の記事をご覧ください。

回避策:

VMware の KB 記事は最新でないため、現在の解決策はありません。この問題を解決するには、ホスト上の ESXi を最新バージョンに更新し、ストレージアレイ上の Nutanix を最新バージョンに更新します。

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

1.13.10, 1.14.6, 1.15.3

kubelet と Kubernetes コントロールプレーン間のバージョンの不一致

特定の GKE on VMware リリースでは、ノードで実行されている kubelet は Kubernetes コントロールプレーンとは異なるバージョンを使用します。OS イメージにプリロードされた kubelet バイナリが異なるバージョンを使用しているため、不一致があります。

次の表に、特定されたバージョンの不一致の一覧を示します。

GKE on VMware のバージョン	kubelet のバージョン	Kubernetes のバージョン
1.13.10	v1.24.11-gke.1200	v1.24.14-gke.2100
1.14.6	v1.25.8-gke.1500	v1.25.10-gke.1200
1.15.3	v1.26.2-gke.1001	v1.26.5-gke.2100

回避策:

なんらかのご対応を行っていただく必要はありません。この不整合は Kubernetes パッチバージョン間のみであり、このバージョンスキューによる問題はありません。

アップグレードと更新

1.15.0-1.15.4

CA バージョンが 1 より大きい管理クラスタのアップグレードまたは更新が失敗する

管理クラスタの認証局（CA）バージョンが 1 より大きい場合、Webhook の CA バージョン検証により更新またはアップグレードが失敗します。gkectl アップグレード / 更新の出力には、次のエラーメッセージが含まれます。


    CAVersion must start from 1

回避策:

管理クラスタの auto-resize-controller Deployment をスケールダウンして、ノードの自動サイズ変更を無効にします。1.15 で管理クラスタのカスタムリソースに導入された新しいフィールドによって、auto-resize-controller で nil ポインタエラーが発生する可能性があるため、このようにする必要があります。
```
 kubectl scale deployment auto-resize-controller -n kube-system --replicas=0 --kubeconfig KUBECONFIG
      
```

--disable-admin-cluster-webhook フラグを指定して gkectl コマンドを実行します。次に例を示します。


        gkectl upgrade admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig KUBECONFIG --disable-admin-cluster-webhook

オペレーション

1.13, 1.14.0-1.14.8, 1.15.0-1.15.4, 1.16.0-1.16.1

非 HA コントロールプレーン V2 クラスタの削除がタイムアウトまで停止する

非 HA コントロールプレーン V2 クラスタが削除されると、タイムアウトするまでノードの削除時に停止します。

回避策:

クラスタに重要なデータを含む StatefulSet が含まれている場合は、Cloud カスタマーケアに連絡してこの問題を解決してください。

それ以外の場合は、次の手順を行います。

vSphere からすべてのクラスタ VM を削除します。VM は、vSphere UI を介して削除するか、次のコマンドを実行します。
```
      govc vm.destroy
```
.

クラスタをもう一度強制的に削除します。


     gkectl delete cluster --cluster USER_CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG --force

ストレージ

1.15.0+, 1.16.0+

バージョン 1.15 以降にアップグレードすると、in-tree PVC/PV に対して一定の CNS attachvolume タスクが毎分表示される

クラスタに in-tree vSphere 永続ボリューム（たとえば、standard StorageClass で作成された PVC）が含まれている場合、vCenter から 1 分ごとに com.vmware.cns.tasks.attachvolume のタスクが発生します。

回避策:

vSphere CSI 機能の configMap を編集し、list-volumes を false に設定します。


     kubectl edit configmap internal-feature-states.csi.vsphere.vmware.com -n kube-system --kubeconfig KUBECONFIG

vSphere CSI コントローラ Pod を再起動します。


     kubectl rollout restart vsphere-csi-controller -n kube-system --kubeconfig KUBECONFIG

ストレージ

1.16.0

PVC に対する誤った警告

クラスタに intree vSphere 永続ボリュームが含まれている場合、コマンド gkectl diagnose および gkectl upgrade を実行すると、クラスタのストレージ設定を検証するときに永続ボリュームの要求（PVC）に対して誤った警告が発生することがあります。次のような警告メッセージが表示されます。


    CSIPrerequisites pvc/pvc-name: PersistentVolumeClaim pvc-name bounds to an in-tree vSphere volume created before CSI migration enabled, but it doesn't have the annotation pv.kubernetes.io/migrated-to set to csi.vsphere.vmware.com after CSI migration is enabled

回避策:

次のコマンドを実行して、先ほどの警告が表示された PVC のアノテーションを確認します。


    kubectl get pvc PVC_NAME -n PVC_NAMESPACE -oyaml --kubeconfig KUBECONFIG

出力の annotations フィールドに次の内容が含まれている場合、警告は無視して問題ありません。


      pv.kubernetes.io/bind-completed: "yes"
      pv.kubernetes.io/bound-by-controller: "yes"
      volume.beta.kubernetes.io/storage-provisioner: csi.vsphere.vmware.com

アップグレードと更新

1.15.0+, 1.16.0+

複数のキーが期限切れになった場合、サービスアカウントキーのローテーションが失敗する

クラスタで非公開レジストリが使用されておらず、コンポーネントアクセスサービスアカウントキーと Logging-monitoring（または Connect-register）サービスアカウントキーが期限切れになった場合は、サービスアカウントキーをローテーションするときに、gkectl update credentials が次のようなエラーで失敗します。


Error: reconciliation failed: failed to update platform: ...

回避策:

まず、コンポーネントアクセスサービスアカウントキーをローテーションします。同じエラーメッセージが表示されますが、コンポーネントアクセスサービスアカウントキーのローテーション後に他のキーをローテーションできるはずです。

それでも更新が成功しない場合は、Cloud カスタマーケアに問い合わせて、この問題を解決してください。

アップグレード

1.16.0-1.16.5

ユーザークラスタコントローラが 1.16 にアップグレードされると、1.15 ユーザーマスターマシンで予期しない再作成が発生する

ユーザークラスタのアップグレード中に、ユーザークラスタコントローラが 1.16 にアップグレードされた後、同じ管理クラスタで管理されている他の 1.15 ユーザークラスタがある場合、そのユーザーマスターマシンが予期せず再作成される可能性があります。

1.16 ユーザークラスタコントローラにバグがあり、1.15 ユーザーマスターマシンの再作成をトリガーできます。

対処方法は、この事象がどのように発生するかによって異なります。

Google Cloud コンソールを使用してユーザークラスタをアップグレードするときの回避策:

オプション 1: 修正を適用した GKE on VMware の 1.16.6 以降のバージョンを使用します。

オプション 2: 次の手順を行います。

次のコマンドを使用して、再実行アノテーションを手動で追加します。


kubectl edit onpremuserclusters USER_CLUSTER_NAME -n USER_CLUSTER_NAME-gke-onprem-mgmt --kubeconfig ADMIN_KUBECONFIG

再実行のアノテーションは次のとおりです。


onprem.cluster.gke.io/server-side-preflight-rerun: true

OnPremUserCluster の status フィールドを確認して、アップグレードの進行状況をモニタリングします。

自分の管理ワークステーションを使用してユーザークラスタをアップグレードする場合の回避策:

オプション 1: 修正を適用した GKE on VMware の 1.16.6 以降のバージョンを使用します。

オプション 2: 次の手順を行います。

次の内容のビルド情報ファイル /etc/cloud/build.info を追加します。これにより、プリフライトチェックは、サーバーではなく管理ワークステーションでローカルに実行されます。
```
gke_on_prem_version: GKE_ON_PREM_VERSION
```
次に例を示します。
```
gke_on_prem_version: 1.16.0-gke.669
```
アップグレードコマンドを再実行します。
アップグレードが完了したら、build.info ファイルを削除します。

作成

1.16.0-1.16.5、1.28.0-1.28.100

ホスト名が IP ブロックファイルにないとき、プリフライトチェックが失敗する

クラスタの作成時に、IP ブロックファイル内のすべての IP アドレスにホスト名を指定しないと、プリフライトチェックは次のエラーメッセージで失敗します。


multiple VMs found by DNS name  in xxx datacenter. Anthos Onprem doesn't support duplicate hostname in the same vCenter and you may want to rename/delete the existing VM.`

プリフライトチェックに、空のホスト名が重複であると想定するバグがあります。

回避策:

オプション 1: 修正を含むバージョンを使用します。

オプション 2: --skip-validation-net-config フラグを追加して、このプリフライトチェックをバイパスします。

オプション 3: IP ブロックファイル内の IP アドレスごとに一意のホスト名を指定します。

アップグレードと更新

1.16

非 HA 管理クラスタとコントロールプレーン v1 のユーザークラスタを使用している場合、管理クラスタをアップグレードまたは更新するときにボリュームマウントが失敗する

非 HA 管理クラスタとコントロールプレーン v1 ユーザークラスタの場合、管理クラスタをアップグレードまたは更新すると、ユーザークラスタマスターマシンの再起動と同時に管理クラスタマスターマシンの再作成が行われることがあり、これにより競合状態が発生する可能性があります。これにより、ユーザークラスタコントロールプレーンの Pod が管理クラスタコントロールプレーンと通信できなくなり、ユーザークラスタコントロールプレーンの kube-etcd と kube-apiserver のボリュームアタッチの問題が発生します。

この問題を確認するには、影響を受けた Pod に対して次のコマンドを実行します。


kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace USER_CLUSTER_NAME describe pod IMPACTED_POD_NAME

次のようなイベントが表示されます。


Events:
  Type     Reason       Age                  From               Message
  ----     ------       ----                 ----               -------
  Warning  FailedMount  101s                 kubelet            Unable to attach or mount volumes: unmounted volumes=[kube-audit], unattached volumes=[], failed to process volumes=[]: timed out waiting for the condition
  Warning  FailedMount  86s (x2 over 3m28s)  kubelet            MountVolume.SetUp failed for volume "pvc-77cd0635-57c2-4392-b191-463a45c503cb" : rpc error: code = FailedPrecondition desc = volume ID: "bd313c62-d29b-4ecd-aeda-216648b0f7dc" does not appear staged to "/var/lib/kubelet/plugins/kubernetes.io/csi/csi.vsphere.vmware.com/92435c96eca83817e70ceb8ab994707257059734826fedf0c0228db6a1929024/globalmount"

回避策:

ユーザーコントロールプレーンノードに SSH で接続します。これはコントロールプレーン v1 ユーザークラスタであるため、ユーザーコントロールプレーンノードは管理クラスタにあります。
次のコマンドを使用して kubelet を再起動します。
```
    sudo systemctl restart kubelet
    
```
再起動後、kubelet はステージグローバルマウントを適切に再構築できます。

アップグレードと更新

1.16.0

コントロールプレーンノードの作成に失敗する

管理クラスタのアップグレードまたは更新中に、競合状態によって、vSphere クラウドコントローラマネージャーが新しいコントロールプレーンノードを予期せず削除する場合があります。これにより、clusterapi-controller がノードの作成を待機するために停止し、最終的にアップグレードや更新がタイムアウトします。この場合、gkectl アップグレード / 更新コマンドの出力は次のようになります。


    controlplane 'default/gke-admin-hfzdg' is not ready: condition "Ready": condition is not ready with reason "MachineInitializing", message "Wait for the control plane machine "gke-admin-hfzdg-6598459f9zb647c8-0\" to be rebooted"...

この症状を特定するには、次のコマンドを実行して、管理クラスタで vSphere クラウドコントローラマネージャーにログインします。


    kubectl get pods --kubeconfig ADMIN_KUBECONFIG -n kube-system | grep vsphere-cloud-controller-manager
    kubectl logs -f vsphere-cloud-controller-manager-POD_NAME_SUFFIX --kubeconfig ADMIN_KUBECONFIG -n kube-system

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


    node name: 81ff17e25ec6-qual-335-1500f723 has a different uuid. Skip deleting this node from cache.

回避策:

障害が発生したマシンを再起動して、削除されたノードオブジェクトを再作成します。
各コントロールプレーンノードに SSH で接続し、vSphere クラウドコントローラマネージャの静的 Pod を再起動します。
```
      sudo crictl ps | grep vsphere-cloud-controller-manager | awk '{print $1}'
      sudo crictl stop PREVIOUS_COMMAND_OUTPUT
      
```
アップグレード / 更新コマンドを再実行します。

オペレーション

1.16

同じデータセンター内でホスト名が重複していると、クラスタのアップグレードまたは作成に失敗する

同じデータセンター内でホスト名が重複していると、1.15 クラスタのアップグレード、または静的 IP を持つ 1.16 クラスタの作成が失敗します。これは、vSphere クラウドコントローラマネージャーがノードオブジェクトに外部 IP とプロバイダ ID を追加できなかったことが原因で発生します。これにより、クラスタのアップグレード / 作成がタイムアウトします。

問題を特定するには、クラスタの vSphereクラウドコントローラマネージャーの Pod ログを取得します。使用するコマンドは、クラスタタイプによって次のように異なります。

管理クラスタ:


      kubectl get pods --kubeconfig ADMIN_KUBECONFIG -n kube-system | grep vsphere-cloud-controller-manager
      kubectl logs -f vsphere-cloud-controller-manager-POD_NAME_SUFFIX --kubeconfig ADMIN_KUBECONFIG -n kube-system

ユーザークラスタ（kubeception）:


      kubectl get pods --kubeconfig ADMIN_KUBECONFIG -n USER_CLUSTER_NAME | grep vsphere-cloud-controller-manager
      kubectl logs -f vsphere-cloud-controller-manager-POD_NAME_SUFFIX --kubeconfig ADMIN_KUBECONFIG -n USER_CLUSTER_NAME

ユーザークラスタ: （コントロールプレーン V2）:


      kubectl get pods --kubeconfig USER_KUBECONFIG -n kube-system | grep vsphere-cloud-controller-manager
      kubectl logs -f vsphere-cloud-controller-manager-POD_NAME_SUFFIX --kubeconfig USER_KUBECONFIG -n kube-system

サンプルのエラーメッセージを次に示します。


    I1003 17:17:46.769676       1 search.go:152] Finding node admin-vm-2 in vc=vcsa-53598.e5c235a1.asia-northeast1.gve.goog and datacenter=Datacenter
    E1003 17:17:46.771717       1 datacenter.go:111] Multiple vms found VM by DNS Name. DNS Name: admin-vm-2

データセンター内でホスト名が重複しているかどうかを確認します。

次のアプローチを使用してホスト名が重複しているかどうかを確認し、必要に応じて回避策を行います。


          export GOVC_DATACENTER=GOVC_DATACENTER
          export GOVC_URL=GOVC_URL
          export GOVC_USERNAME=GOVC_USERNAME
          export GOVC_PASSWORD=GOVC_PASSWORD
          export GOVC_INSECURE=true
          govc find . -type m -guest.hostName HOSTNAME

コマンドと出力の例


          export GOVC_DATACENTER=mtv-lifecycle-vc01
          export GOVC_URL=https://mtv-lifecycle-vc01.anthos/sdk
          export GOVC_USERNAME=xxx
          export GOVC_PASSWORD=yyy
          export GOVC_INSECURE=true
          govc find . -type m -guest.hostName f8c3cd333432-lifecycle-337-xxxxxxxz
          ./vm/gke-admin-node-6b7788cd76-wkt8g
          ./vm/gke-admin-node-6b7788cd76-99sg2
          ./vm/gke-admin-master-5m2jb

行う回避策は、失敗したオペレーションによって異なります。

アップグレードの回避策:

該当するクラスタタイプに対して回避策を行います。

ユーザークラスタ:
1. user-ip-block.yaml で影響を受けるマシンのホスト名を一意の名前に更新し、強制更新をトリガーします。
```
          gkectl update cluster --kubeconfig ADMIN_KUBECONFIG --config NEW_USER_CLUSTER_CONFIG --force
          
```
2. gkectl upgrade cluster を再実行

管理クラスタ:

admin-ip-block.yaml で影響を受けるマシンのホスト名を一意の名前に更新し、強制更新をトリガーします。


          gkectl update admin --kubeconfig ADMIN_KUBECONFIG --config NEW_ADMIN_CLUSTER_CONFIG --force --skip-cluster-ready-check

非 HA 管理クラスタであり、管理マスター VM が重複するホスト名を使用していることが判明した場合は、次の操作も必要になります。
管理マスターマシン名を取得する


          kubectl get machine --kubeconfig ADMIN_KUBECONFIG -owide -A

管理マスターマシンオブジェクトを更新する
注: NEW_ADMIN_MASTER_HOSTNAME は、手順 1 で admin-ip-block.yaml で設定したものと同じである必要があります。


          kubectl patch machine ADMIN_MASTER_MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG --type='json' -p '[{"op": "replace", "path": "/spec/providerSpec/value/networkSpec/address/hostname", "value":"NEW_ADMIN_MASTER_HOSTNAME"}]'

管理マスターマシンオブジェクトでホスト名が更新されたことを確認します。


          kubectl get machine ADMIN_MASTER_MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG -oyaml
          kubectl get machine ADMIN_MASTER_MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG -o jsonpath='{.spec.providerSpec.value.networkSpec.address.hostname}'

チェックポイントを無効にして管理クラスタのアップグレードを再実行します。


          gkectl upgrade admin --kubeconfig ADMIN_KUBECONFIG --config ADMIN_CLUSTER_CONFIG --disable-upgrade-from-checkpoint

インストールの回避策:

該当するクラスタタイプに対して回避策を行います。

管理クラスタ:
1. 管理ノードマシンを削除します。
2. データディスクを削除します。
3. 管理クラスタのチェックポイントファイルを削除します。
4. admin-ip-block.yaml で影響を受けるマシンのホスト名を一意の名前に更新します。
5. gkectl create admin を再実行します。
ユーザークラスタ:
1. リソースをクリーンアップします。
2. user-ip-block.yaml で影響を受けるマシンのホスト名を一意の名前に更新します。
3. gkectl create cluster を再実行します。

オペレーション

1.16.0, 1.16.1, 1.16.2, 1.16.3

`$` と ` は vSphere のユーザー名またはパスワードでサポートされない

vSphere のユーザー名またはパスワードに $ または ` が含まれている場合、次のオペレーションは失敗します。

コントロールプレーン V2 が有効になっている 1.15 ユーザークラスタを 1.16 にアップグレードする
1.15 高可用性（HA）管理クラスタを 1.16 にアップグレードする
コントロールレーン V2 を有効にした 1.16 ユーザークラスタを作成する
1.16 HA 管理クラスタを作成する

修正を含む 1.16.4 以降のバージョンの GKE on VMware を使用するか、以下の回避策を行います。行う回避策は、失敗したオペレーションによって異なります。

アップグレードの回避策:

vCenter 側で vCenter のユーザー名またはパスワードを変更して、$ と ` を削除します。
認証情報構成ファイル内の vCenter のユーザー名またはパスワードを更新します。
クラスタの強制更新をトリガーします。

ユーザークラスタ:


        gkectl update cluster --kubeconfig ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG --force

管理クラスタ:


        gkectl update admin --kubeconfig ADMIN_KUBECONFIG --config ADMIN_CLUSTER_CONFIG --force --skip-cluster-ready-check

インストールの回避策:

vCenter 側で vCenter のユーザー名またはパスワードを変更して、$ と ` を削除します。
認証情報構成ファイル内の vCenter のユーザー名またはパスワードを更新します。
該当するクラスタタイプに対して回避策を行います。

管理クラスタ:
1. 管理ノードマシンを削除します。
2. データディスクを削除します。
3. 管理クラスタのチェックポイントファイルを削除します。
4. gkectl create admin を再実行します。
ユーザークラスタ:
1. リソースをクリーンアップします。
2. gkectl create cluster を再実行します。

ストレージ

1.11+, 1.12+, 1.13+, 1.14+, 1.15+, 1.16

同じ名前でノードを再作成した後の PVC 作成の失敗

ノードを削除してから同じノード名で再作成すると、後続の PersistentVolumeClaim（PVC）の作成が、次のようなエラーで失敗する可能性がわずかにあります。


    The object 'vim.VirtualMachine:vm-988369' has already been deleted or has not been completely created

これは、vSphere CSI コントローラが、削除されたマシンをキャッシュから削除しない競合状態が原因で発生します。

回避策:

vSphere CSI コントローラ Pod を再起動します。


    kubectl rollout restart vsphere-csi-controller -n kube-system --kubeconfig KUBECONFIG

オペレーション

1.16.0

gkectl repair admin-master で kubeconfig unmarshall エラーが返される

HA 管理クラスタで gkectl repair admin-master コマンドを実行すると、gkectl が次のエラーメッセージを返します。


  Exit with error: Failed to repair: failed to select the template: failed to get cluster name from kubeconfig, please contact Google support. failed to decode kubeconfig data: yaml: unmarshal errors:
    line 3: cannot unmarshal !!seq into map[string]*api.Cluster
    line 8: cannot unmarshal !!seq into map[string]*api.Context

回避策:

コマンドに --admin-master-vm-template= フラグを追加して、修復するマシンの VM テンプレートを指定します。


  gkectl repair admin-master --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
      --config ADMIN_CLUSTER_CONFIG_FILE \
      --admin-master-vm-template=/DATA_CENTER/vm/VM_TEMPLATE_NAME

マシンの VM テンプレートを確認するには:

vSphere クライアントの [ホストとクラスタ] ページに移動します。
[VM テンプレート] をクリックし、管理クラスタ名でフィルタします。
管理クラスタの 3 つの VM テンプレートが表示されます。
修復するマシンの名前と一致する VM テンプレート名をコピーし、repair コマンドでそのテンプレート名を使用します。


  gkectl repair admin-master \
      --config=/home/ubuntu/admin-cluster.yaml \
      --kubeconfig=/home/ubuntu/kubeconfig \
      --admin-master-vm-template=/atl-qual-vc07/vm/gke-admin-98g94-zx...7vx-0-tmpl

ネットワーキング

1.10.0+, 1.11.0+, 1.12.0+, 1.13.0+, 1.14.0-1.14.7, 1.15.0-1.15.3, 1.16.0

ディスク容量不足により Seesaw VM が破損する

クラスタのロードバランサタイプとして Seesaw を使用していて、Seesaw VM が停止している、または起動に失敗し続ける場合は、vSphere コンソールに次のエラーメッセージが表示されることがあります。


    GRUB_FORCE_PARTUUID set, initrdless boot failed. Attempting with initrd

このエラーは、Seesaw VM で実行されている fluent-bit が正しいログローテーションで構成されていないため、VM のディスク容量が少ないことを示します。

回避策:

du -sh -- /var/lib/docker/containers/* | sort -rh を使用して、ディスク容量の大部分を消費しているログファイルを見つけます。最大サイズのログファイルをクリーンアップして、VM を再起動します。

注: VM に完全にアクセスできない場合は、ディスクを作業中の VM（管理ワークステーションなど）にアタッチし、アタッチされたディスクからファイルを削除してから、ディスクを元の Seesaw VM に再度アタッチします。

この問題の再発を防ぐには、VM に接続して /etc/systemd/system/docker.fluent-bit.service ファイルを変更します。Docker コマンドに --log-opt max-size=10m --log-opt max-file=5 を追加してから、systemctl restart docker.fluent-bit.service を実行します。

オペレーション

1.13, 1.14.0-1.14.6, 1.15

管理クラスタのアップグレードまたは更新後の管理 SSH 公開鍵エラー

チェックポイントを有効にして非高可用性管理クラスタをアップグレード（gkectl upgrade admin）または更新（gkectl update admin）しようとすると、アップグレードや更新が次のようなエラーで失敗する場合があります。


Checking admin cluster certificates...FAILURE
    Reason: 20 admin cluster certificates error(s).
Unhealthy Resources:
    AdminMaster clusterCA bundle: failed to get clusterCA bundle on admin master, command [ssh -o IdentitiesOnly=yes -i admin-ssh-key -o StrictHostKeyChecking=no -o ConnectTimeout=30 ubuntu@AdminMasterIP -- sudo cat /etc/kubernetes/pki/ca-bundle.crt] failed with error: exit status 255, stderr: Authorized uses only. All activity may be monitored and reported.
    ubuntu@AdminMasterIP: Permission denied (publickey).


failed to ssh AdminMasterIP, failed with error: exit status 255, stderr: Authorized uses only. All activity may be monitored and reported.
    ubuntu@AdminMasterIP: Permission denied (publickey)


error dialing ubuntu@AdminMasterIP: failed to establish an authenticated SSH connection: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey]...

回避策:

修正を含む GKE on VMware のパッチバージョンにアップグレードできない場合は、Google サポートにお問い合わせください。

アップグレード

1.13.0-1.13.9, 1.14.0-1.14.6, 1.15.1-1.15.2

GKE On-Prem API に登録された管理クラスタのアップグレードが失敗することがある

管理クラスタが GKE On-Prem API に登録されている場合、フリートメンバーシップを更新できないため、影響を受けるバージョンに管理クラスタをアップグレードできないことがあります。この障害が発した場合、クラスタをアップグレードしようとすると、次のエラーが表示されます。


    failed to register cluster: failed to apply Hub Membership: Membership API request failed: rpc error: code = InvalidArgument desc = InvalidFieldError for field endpoint.on_prem_cluster.resource_link: field cannot be updated

管理クラスタは、クラスタを明示的に登録する、または GKE On-Prem クライアントを使用してユーザークラスタをアップグレードするときに API に登録されます。

回避策:

管理クラスタの登録を解除します。


    gcloud alpha container vmware admin-clusters unenroll ADMIN_CLUSTER_NAME --project CLUSTER_PROJECT --location=CLUSTER_LOCATION --allow-missing

そして、管理クラスタのアップグレードを再開します。古い「failed to register cluster」エラーが一時的に表示される場合があります。しばらくすると、自動的に更新されます。

アップグレードと更新

1.13.0-1.13.9, 1.14.0-1.14.4, 1.15.0

登録済みの管理クラスタのリソースリンクアノテーションが保持されない

管理クラスタが GKE On-Prem API に登録されると、そのリソースリンクアノテーションは OnPremAdminCluster カスタムリソースに適用されます。これは、間違ったアノテーションキーが使用されているという理由で、クラスタ管理の更新中に保持されません。これにより、管理クラスタが GKE On-Prem API に再度誤って登録される可能性があります。

回避策:

管理クラスタの登録を解除します。


    gcloud alpha container vmware admin-clusters unenroll ADMIN_CLUSTER_NAME --project CLUSTER_PROJECT --location=CLUSTER_LOCATION --allow-missing

そして、管理クラスタをもう一度再登録します。

ネットワーキング

1.15.0-1.15.2

CoreDNS `orderPolicy` が認識されない

OrderPolicy がパラメータとして認識されないため、使用されません。代わりに、GKE on VMware は常に Random を使用します。

この問題は、CoreDNS テンプレートが更新されておらず、orderPolicy が無視されることが原因で発生します。

回避策:

CoreDNS テンプレートを更新し、修正を適用します。この修正は、アップグレードするまで維持されます。

既存のテンプレートを編集します。


kubectl edit cm -n kube-system coredns-template

ファイルの内容を次のコードで置き換えます。


coredns-template: |-
  .:53 {
    errors
    health {
      lameduck 5s
    }
    ready
    kubernetes cluster.local in-addr.arpa ip6.arpa {
      pods insecure
      fallthrough in-addr.arpa ip6.arpa
    }
{{- if .PrivateGoogleAccess }}
    import zones/private.Corefile
{{- end }}
{{- if .RestrictedGoogleAccess }}
    import zones/restricted.Corefile
{{- end }}
    prometheus :9153
    forward . {{ .UpstreamNameservers }} {
      max_concurrent 1000
      {{- if ne .OrderPolicy "" }}
      policy {{ .OrderPolicy }}
      {{- end }}
    }
    cache 30
{{- if .DefaultDomainQueryLogging }}
    log
{{- end }}
    loop
    reload
    loadbalance
}{{ range $i, $stubdomain := .StubDomains }}
{{ $stubdomain.Domain }}:53 {
  errors
{{- if $stubdomain.QueryLogging }}
  log
{{- end }}
  cache 30
  forward . {{ $stubdomain.Nameservers }} {
    max_concurrent 1000
    {{- if ne $.OrderPolicy "" }}
    policy {{ $.OrderPolicy }}
    {{- end }}
  }
}
{{- end }}

アップグレードと更新

1.10, 1.11, 1.12, 1.13.0-1.13.7, 1.14.0-1.14.3

OnPremAdminCluster のステータスがチェックポイントと実際の CR の間で一致しない

特定の競合状態のために、チェックポイントと実際の CR の間で OnPremAdminCluster ステータスが一致しない場合があります。この問題が発生した場合、管理クラスタをアップグレードした後に更新するときに、次のエラーが発生することがあります。


Exit with error:
E0321 10:20:53.515562  961695 console.go:93] Failed to update the admin cluster: OnPremAdminCluster "gke-admin-rj8jr" is in the middle of a create/upgrade ("" -> "1.15.0-gke.123"), which must be completed before it can be updated
Failed to update the admin cluster: OnPremAdminCluster "gke-admin-rj8jr" is in the middle of a create/upgrade ("" -> "1.15.0-gke.123"), which must be completed before it can be updated

この問題を回避するには、チェックポイントを編集するか、アップグレードや更新のチェックポイントを無効にする必要があります。回避策については、Google サポートチームまでお問い合わせください。

オペレーション

1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1

調整プロセスにより、管理クラスタの管理者証明書が変更される

GKE on VMware は、クラスタアップグレード時など、調整プロセスごとに管理クラスタのコントロールプレーンの管理証明書を変更します。この動作により、管理クラスタ（特にバージョン 1.15 のクラスタ）で無効な証明書を取得する可能性が高くなります。

この問題の影響を受けると、次のような問題が発生する可能性があります。

無効な証明書が原因で、次のコマンドがタイムアウトしてエラーを返す場合があります。
- gkectl create admin
- gkectl upgrade amdin
- gkectl update admin
これらのコマンドは、次のような承認エラーを返す場合があります。
```
Failed to reconcile admin cluster: unable to populate admin clients: failed to get admin controller runtime client: Unauthorized
```
管理クラスタの kube-apiserver ログには、次のようなエラーが含まれている場合があります。
```
Unable to authenticate the request" err="[x509: certificate has expired or is not yet valid...
```

回避策:

修正を含む GKE on VMware のバージョン 1.13.10 以降、1.14.6 以降、1.15.2 以降にアップグレードします。アップグレードができない場合は、Cloud カスタマーケアに連絡して、この問題を解決してください。

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

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 以降にアップグレードしてください。

一時的な修正として、Anthos Network Gateway コンポーネントに PriorityClass を手動で割り当てることができます。GKE 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.0-1.15.2

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

管理クラスタ名を取得します。


kubectl get onpremadmincluster -n kube-system --kubeconfig=ADMIN_KUBECONFIG

フリートメンバーシップを削除します。


gcloud container fleet memberships delete ADMIN_CLUSTER_NAME

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

オペレーション

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 より前のバージョンの GKE on VMware への Docker のインストールに失敗します。

回避策:

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

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

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

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

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

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

注: このオプションの場合、クラスタが 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

`RootDistanceMaxSec` 構成が `ubuntu` ノードで有効になっていない

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


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

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

回避策:

次の DaemonSet をクラスタに適用して、RootDistanceMaxSec を構成します。


apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: change-root-distance
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: change-root-distance
  template:
    metadata:
      labels:
        app: change-root-distance
    spec:
      hostIPC: true
      hostPID: true
      tolerations:
      # Make sure pods gets scheduled on all nodes.
      - effect: NoSchedule
        operator: Exists
      - effect: NoExecute
        operator: Exists
      containers:
      - name: change-root-distance
        image: ubuntu
        command: ["chroot", "/host", "bash", "-c"]
        args:
        - |
          while true; do
            conf_file="/etc/systemd/timesyncd.conf.d/90-gke.conf"
            if [ -f $conf_file ] && $(grep -q "RootDistanceMaxSec=20" $conf_file); then
              echo "timesyncd has the expected RootDistanceMaxSec, skip update"
            else
              echo "updating timesyncd config to RootDistanceMaxSec=20"
              mkdir -p /etc/systemd/timesyncd.conf.d
              cat > $conf_file << EOF
          [Time]
          RootDistanceMaxSec=20
          EOF
              systemctl restart systemd-timesyncd
            fi
            sleep 600
          done
        volumeMounts:
        - name: host
          mountPath: /host
        securityContext:
          privileged: true
      volumes:
      - name: host
        hostPath:
          path: /

アップグレードと更新

1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2

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

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


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 フィールドのバックフィルが不適切であるために発生します。

回避策:

修正を含む GKE on VMware のバージョンにアップグレードします。アップグレードができない場合は、Cloud カスタマーケアに連絡して、この問題を解決してください。

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

1.13, 1.14, 1.15, 1.16

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

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

回避策:

修正を含む GKE 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

回避策:

$ のない非公開レジストリのユーザー名を使用するか、修正が適用された GKE 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 に戻しますが、最新の鍵データを保持します。

USER_CLUSTER_NAME 名前空間の管理クラスタ内の Secret を確認し、ksa-signing-key Secret の名前を取得します。
```
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., 1.16

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 にアップグレードすると、kind クラスタは docker.io から次のコンテナイメージを pull します。

docker.io/kindest/kindnetd

docker.io/kindest/local-path-provisioner

docker.io/kindest/local-path-helper

docker.io が管理ワークステーションからアクセスできない場合、管理クラスタの作成またはアップグレードでは kind クラスタが取り込まれません。管理ワークステーションで次のコマンドを実行すると、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
...

これらのコンテナイメージは、kind クラスタのコンテナイメージにプリロードされている必要があります。ただし、kind 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 テーブルエントリが正しくなくなります。

影響を受けるノードでコントロールプレーン VIP を ping できますが、コントロールプレーン 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 Secret を更新します。ただし、現在のシステムでは 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 コンソールで登録済みクラスタからクラスタを見つけることができるかどうか確認できます。

回避策:

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-Host アフィニティルールが原因でノードプールの作成が失敗する

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 が Failed 状態のままになる

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

回避策:

失敗した Pod は無視するか、手動で削除しても問題ありません。

セキュリティの構成

1.15.0-1.15.1

非公開レジストリの認証情報が原因で 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 Migration の後に無視されるパラメータが StorageClasses にないことを確認します。たとえば、パラメータ diskformat を伴う StorageClass がある場合、gkectl upgrade admin は StorageClass にフラグを付け、プリフライト検証で失敗を報告します。 GKE on VMware 1.10 以前で作成された管理クラスタには diskformat: thin を備えた StorageClass があり、これによりこの検証は失敗しますが、この StorageClass は CSI Migration の後も正常に動作します。これらの障害は、代わりに警告として解釈する必要があります。

詳細については、in-tree vSphere ボリュームの vSphere コンテナストレージプラグインへの移行の StorageClass パラメータのセクションをご覧ください。

回避策:

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

ストレージ

1.15, 1.16

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

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

クラスタ認証情報の更新後に管理クラスタの 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 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
```
Deployment が正常にロールアウトされたら、更新された 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 ためにクラッシュループすることがあります。この動作は、クラスタ名が audit-proxy Pod / コンテナマニフェストに伝播されないという更新ロジックのバグが原因で発生します。

回避策:

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

コントロールプレーン v1 ユーザークラスタの場合は、kube-apiserver StatefulSet の 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 が削除されました。

GKE 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 できない場合があります。

この問題は、GKE 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 Deployment で使用されるイメージ pull Secret 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 Deployment のクラスタの、デフォルトのイメージ pull Secret を、以下の方法で追加できます。

デフォルトの Secret を gke-connect 名前空間にコピーします。


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 Deployment 名を取得します。


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

デフォルトの Secret を 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 の変更を監視しない

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

この問題は、GKE on VMware リリース 1.12.7、1.13.6、1.14.3 以降のリリースで修正されています。これらの新しいリリースでは、etcd バージョン 3.4.21 を使用します。GKE 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. [アクティブな指標カテゴリ] メニューで、[Anthos] を選択します。
3. [アクティブな指標] メニューで etcd_network_client_grpc_sent_bytes_total を選択します。
4. [適用] をクリックします。

アップグレードと更新

1.10, 1.11, 1.12, 1.13　および　1.14

GKE Identity Service によってコントロールプレーンのレイテンシが発生する可能性がある

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

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

1.12.6+
1.13.6+
1.14.2+

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

GKE 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 が返される場合は、GKE Identity Service の HTTP サーバーは起動していません。その場合は続行してください。

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

GKE 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 を特定して再起動します。

GKE 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

GKE Identity Service のログで、無効なトークンコンテキストを確認します。
```
kubectl logs -f -l k8s-app=ais -n anthos-identity-service \
    --kubeconfig KUBECONFIG
```
無効な各トークンコンテキストに関連付けられたトークンペイロードを取得するには、次のコマンドを使用して、関連する各サービスアカウントの Secret を解析します。
```
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 maintenance Pod が影響を受けます。「etcddefrag」コンテナは、各デフラグサイクル中に 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 にトラフィックをリダイレクトしました。GKE 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 テーブル挿入エラーによるアプリケーションタイムアウト

GKE 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 つの Deployment で Windows ノード taint を含むすべての taint が容認されるためです。

回避策:

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


    # 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+

データプレーン v2 と互換性のない Anthos Service Mesh と他のサービスメッシュ

データプレーン V2 はロードバランシングを引き受け、パケットベースの DNAT の代わりにカーネルソケットを作成します。つまり、Pod がバイパスされ、IPTable を使用しないため、Anthos Service Mesh はパケット検査を実行できません。

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

この問題は、GKE on Bare Metal 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 は、PV/PVC を切断するときに 6 分後にタイムアウトし、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+, 1.16+

VM がシャットダウン / 再起動時に DHCP リースを予期せずに開放し、これにより IP が変更される可能性がある

systemd v244 では、systemd-networkd で KeepConfiguration 構成のデフォルトの動作が変更されました。この変更前は、VM はシャットダウンまたは再起動時に DHCP リース開放メッセージを DHCP サーバーに送信しませんでした。変更後、VM はこのようなメッセージを送信し、IP を DHCP サーバーに返します。その結果、開放された IP が別の VM に再割り当てされたり、異なる IP が VM に割り当てられたりする可能性があります。その結果、VM 上で IP 競合（vSphere レベルではなく Kubernetes レベルで）や 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 は、シャットダウン / 再起動時に IP を DHCP サーバーに解放しません。リースが期限切れになると、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.12.5, 1.13.0-1.13.5, 1.14.0-1.14.1

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

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

1.11.x クラスタを 1.12.x にアップグレードすると、admin-cluster-creds Secret の 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または新しいインストールモデルで作成されたユーザークラスタでは、自動スケーリングが有効なノードプールは常に、user-cluster.yaml 内の autoscaling.minReplicas を使用します。cluster-autoscaler 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

cluster autoscaler 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

IP ブロックファイルで 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.10, 1.11, 1.12, 1.13, 1.14.0

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

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


  error getting ClusterInformation: connection is unauthorized: Unauthorized

この問題は、Calico を使用してクラスタを作成または 1.14 にアップグレードしてから 24 時間後にのみ発生します。

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

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

回避策:

この問題は、GKE on VMware バージョン 1.14.1 で修正されました。このバージョンまたはそれ以降のバージョンにアップグレードしてください。

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

バージョン 1.12 より、gmp-system名前空間と CRD は、デフォルトでは、enableGMPForApplicationsフラグをfalse に設定してstackdriverオブジェクトで管理されます。1.12 にアップグレードする前に名前空間に 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` clusterrolebinding と clusterrole が、ユーザークラスタを削除した後に削除される。

ユーザークラスタの削除時に、cluster-autoscaler の対応する clusterrole と clusterrolebinding も削除されます。これは、cluster autoscaler が有効になっている同じ管理クラスタ上のすべてのユーザークラスタに影響します。これは、同じ管理クラスタ内のすべてのクラスタオートスケーラー 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

回避策:

回避策を表示する

clusterrole と clusterrolebinding が管理クラスタにないかどうかを確認する


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 を管理クラスタに適用します。各ユーザークラスタの clusterrolebinding にサービスアカウントサブジェクトを追加します。


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

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

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 コマンドがタイムアウトする可能性がありますが、コントローラはクラスタの調整を継続して、アップグレードまたは更新プロセスが最終的に完了します。

回避策:

この問題に関して、ご使用の環境と要件に応じていくつかの緩和策を用意しています。

オプション 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 Deployment に関連する 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

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

VMware

1.10, 1.11, 1.12, 1.13

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

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

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

GKE 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 をインストールするときの一般的な現象は、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 を復元する

一般に、管理クラスタは GKE 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 の脆弱性スキャンにおける誤検出

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

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

たとえば、CVE のスキャン結果で次の誤検出が発生することがあります。これらの CVE は GKE 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 チェックに失敗した場合、通常、GKE 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 とメモリの急増に関する問題

GKE 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 がバンドルされたロードバランサがデプロイされている場合、GKE on VMware バージョン 1.9 以降をデプロイすると、stackdriver-operator は gke-metrics-agent-conf ConfigMap の作成に失敗し、gke-connect-agent Pod がクラッシュループに入ります。

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

回避策:

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

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

ロギングとモニタリング

1.10、1.11、1.12、1.13、1.14、1.15

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

GKE on VMware バージョン 1.10 から 1.15 では、[お支払い] ページで予想外に高い Metrics volume の料金が表示される場合があります。この問題は、次の両方の状況に該当する場合にのみ影響します。

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

この問題の影響を受けるかどうかを確認するには、ユーザー定義の指標を一覧表示します。external.googleapis.com/prometheus の名前の接頭辞が付いた不要な指標に対する請求が表示され、kubectl -n kube-system get stackdriver stackdriver -o yaml のレスポンスで enableStackdriverForApplications が true に設定されている場合も、この問題に該当します。

回避策

この問題の影響を受ける場合は、クラスタをバージョン 1.12 以降にアップグレードし、enableStackdriverForApplications フラグの使用を停止して、prometheus.io/scrap=true アノテーションに依存しない、新しいアプリケーションモニタリングソリューションの managed-service-for-prometheus に切り替えることをおすすめします。新しいソリューションでは、enableCloudLoggingForApplications フラグと enableGMPForApplications フラグをそれぞれ使用して、アプリケーションごとにログと指標の収集を個別に制御することもできます。

enableStackdriverForApplications フラグの使用を停止するには、「stackdriver」オブジェクトを開いて編集します。


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

enableStackdriverForApplications: true の行を削除し、保存してエディタを閉じます。

アノテーションベースの指標の収集を終了できない場合は、次の手順を行います。

不要な請求の指標が含まれるソースの 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 データディスクの作成時にインストーラが失敗する

カスタムロールが誤った権限レベルでバインドされている場合は、GKE 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 エラーが頻繁に発生する

GKE 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 で不明な指標データ

GKE 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 に、CPU 上限を 100m から 200m に引き上げるには、次の resourceAttrOverride セクションを 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

回避策:

この問題は、GKE 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

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

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

回避策:

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

GKE Identity Service を無効にします。GKE Identity Service を無効にしても、デプロイされた GKE Identity Service バイナリや GKE Identity Service ClientConfig は削除されません。GKE Identity Service を無効にするには、次のコマンドを実行します。
```
gcloud container fleet identity-service disable \
    --project PROJECT_ID
```
PROJECT_ID は、クラスタのフリートホストプロジェクトの名前に置き換えます。
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`

GKE on VMware バージョン 1.10、1.11、1.12 の場合、ディスク上にバッファリングされたログが破損している場合に、stackdriver-log-forwarder Daremonset で 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, 1.16

`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 がログを送信しなくなります。この問題は、GKE 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

Datastore で空き容量の不足が誤って報告される

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 を使用して GKE 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 の Deployment をスケールダウンします。


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, 1.16

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

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

ただし、管理クラスタがユーザークラスタとは異なるプロジェクト ID または異なるサービスアカウントを使用する場合、管理クラスタからの監査ログは Google Cloud に取り込まれません。この症状は、管理クラスタの audit-proxy Pod での一連の Permission Denied エラーの発生です。

回避策:

回避策を表示する

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

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


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/` が VM のディスク容量を占有している

/var/log/audit/ が監査ログでいっぱいになっています。ディスク使用量を確認するには、sudo du -h -d 1 /var/log/audit を実行します。

管理ワークステーションの特定の gkectl コマンド（gkectl diagnose snapshot など）は、ディスク使用量に影響します。

GKE on VMware 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

これは、GKE 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 ルックアップに失敗した

GKE 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` を使用する

GKE 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 へのアップグレードがブロックされる

GKE 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 の更新に準拠するために行われます。

影響を受けるカスタムリソースを適用または編集する追加ロジックがない場合は、何もする必要はありません。GKE on VMware のアップグレードプロセスでは、影響を受けるリソースの移行が処理され、グループ名の変更後も既存の仕様が維持されます。

ただし、影響を受けるリソースを適用または編集するロジックを実行する場合は、特に注意する必要があります。まず、マニフェストファイルで新しいグループ名で参照する必要があります。次に例を示します。


apiVersion: addons.gke.io/v1alpha1  ## instead of `addons.sigs.k8s.io/v1alpha1`
kind: Stackdriver

次に、resourceAttrOverride と storageSizeOverride の仕様値が文字列型であることを確認します。次に例を示します。


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, 1.16

ホストの正常なシャットダウンを介して VM が移動された場合、COS VM に IP が表示されない

ESXi サーバーに障害があり、サーバーで vCenter HA 機能が有効になっている場合、障害のある ESXi サーバー内のすべての VM が vMotion メカニズムをトリガーし、別の通常の ESXi サーバーに移動されます。移行された COS VM の IP が失われます。

回避策:

VM を再起動する

ネットワーキング

1.14.7、1.15.0-1.15.3、1.16.0 より前のすべてのバージョン

Seesaw から送信された GARP 応答でターゲット IP が設定されない

Seesaw が 20 秒ごとに送信する定期的な GARP（Gratuitous ARP）では、ARP ヘッダーにターゲット IP が設定されません。一部のネットワークはこのようなパケット（Cisco ACI など）を受け入れない場合があります。スプリットブレイン（VRRP パケットのドロップによる）が復元された後、サービスが長く停止する可能性があります。

回避策:

いずれかの Seesaw VM で sudo seesaw -c failover を実行して、Seeaw フェイルオーバーをトリガーします。これによってトラフィックが復元されます。

1.16、1.28.0-1.28.200

Kubelet に、「/etc/kubernetes/manifests」がワーカーノードに存在しないことを示すログが大量に表示される

ワーカーノードに「staticPodPath」が誤って設定されました

回避策:

フォルダ「/etc/kubernetes/manifests」を手動で作成します

さらにサポートが必要な場合は、Cloud カスタマーケアにお問い合わせください。

GKE on VMware の既知の問題

標準の CNI で複数のネットワーク インターフェースを使用できない

Netapp Trident の依存関係が vSphere CSI ドライバと干渉する

必要な構成を追加すると、管理クラスタの Webhook によって更新がブロックされることがある

manualLB 仕様が空の場合、controlPlaneNodePort フィールドのデフォルトが 30968 になる

Ubuntu OS イメージに nfs-common がありません

管理クラスタの構成テンプレートにストレージ ポリシー フィールドがありません

Kubernetes Metadata API は VPC-SC をサポートしていません

管理クラスタとコントロール プレーン V2 が有効になっているユーザー クラスタが、異なる vSphere 認証情報を使用すると、clusterapi-controller がクラッシュすることがある

Prometheus Alert Manager で etcd の失敗した GRPC リクエスト数が多い

下り（外向き）NAT の長時間接続が切断される

CSR 署名者が、証明書に署名するときに spec.expirationSeconds を無視する

disable_bundled_ingress でユーザー クラスタのロードバランサの検証が失敗する

CA のローテーション後に管理クラスタの更新が失敗する

Pod の起動の失敗により、CSI ワークロードのプリフライト チェックが失敗する

管理クラスタのバージョンが 1.15 の場合、ユーザー クラスタの更新がタイムアウトする

管理クラスタのバージョンが 1.15 の場合、ユーザー クラスタの作成がタイムアウトする

アドオン サービスのプロジェクトまたはロケーションが互いに一致しない場合、管理クラスタの更新またはアップグレードが失敗する

ユーザー管理の管理ワークステーションを使用している場合、ユーザー クラスタの削除に失敗する

外部サーバーへの下り（外向き）NAT ゲートウェイ トラフィックが失敗する

常時オンのシークレット暗号化が有効になっている管理クラスタのアップグレードが失敗する

回避策

アップグレードの失敗を防ぐ

変更ブロックのトラッキング（CBT）の使用時のディスクエラーとアタッチの失敗

共有ファイルへの並列追加が複数のホストから行われた場合の NFSv3 でのデータ破損

kubelet と Kubernetes コントロール プレーン間のバージョンの不一致

CA バージョンが 1 より大きい管理クラスタのアップグレードまたは更新が失敗する

非 HA コントロール プレーン V2 クラスタの削除がタイムアウトまで停止する

バージョン 1.15 以降にアップグレードすると、in-tree PVC/PV に対して一定の CNS attachvolume タスクが毎分表示される

PVC に対する誤った警告

複数のキーが期限切れになった場合、サービス アカウント キーのローテーションが失敗する

ユーザー クラスタ コントローラが 1.16 にアップグレードされると、1.15 ユーザー マスター マシンで予期しない再作成が発生する

ホスト名が IP ブロック ファイルにないとき、プリフライト チェックが失敗する

非 HA 管理クラスタとコントロール プレーン v1 のユーザー クラスタを使用している場合、管理クラスタをアップグレードまたは更新するときにボリューム マウントが失敗する

コントロール プレーン ノードの作成に失敗する

同じデータセンター内でホスト名が重複していると、クラスタのアップグレードまたは作成に失敗する

$ と ` は vSphere のユーザー名またはパスワードでサポートされない

同じ名前でノードを再作成した後の PVC 作成の失敗

gkectl repair admin-master で kubeconfig unmarshall エラーが返される

ディスク容量不足により Seesaw VM が破損する

管理クラスタのアップグレードまたは更新後の管理 SSH 公開鍵エラー

GKE On-Prem API に登録された管理クラスタのアップグレードが失敗することがある

登録済みの管理クラスタのリソースリンク アノテーションが保持されない

CoreDNS orderPolicy が認識されない

OnPremAdminCluster のステータスがチェックポイントと実際の CR の間で一致しない

調整プロセスにより、管理クラスタの管理者証明書が変更される

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

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

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

gkectl prepare windows 失敗します。

RootDistanceMaxSec 構成が ubuntu ノードで有効になっていない

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-Host アフィニティ ルールが原因でノードプールの作成が失敗する

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

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

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

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

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

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

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

gkectl upgrade cluster の直後に追加のコントロール プレーンが再デプロイされる

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

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

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

etcd ウォッチの不足

GKE Identity Service によってコントロール プレーンのレイテンシが発生する可能性がある

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

ユーザー クラスタ コントロール プレーン Pod のヘルスチェックを受けない

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

標準の CNI で複数のネットワークインターフェースを使用できない

`manualLB` 仕様が空の場合、`controlPlaneNodePort` フィールドのデフォルトが 30968 になる

管理クラスタの構成テンプレートにストレージポリシーフィールドがありません

管理クラスタとコントロールプレーン V2 が有効になっているユーザークラスタが、異なる vSphere 認証情報を使用すると、clusterapi-controller がクラッシュすることがある

CSR 署名者が、証明書に署名するときに `spec.expirationSeconds` を無視する

`disable_bundled_ingress` でユーザークラスタのロードバランサの検証が失敗する

Pod の起動の失敗により、CSI ワークロードのプリフライトチェックが失敗する

管理クラスタのバージョンが 1.15 の場合、ユーザークラスタの更新がタイムアウトする

管理クラスタのバージョンが 1.15 の場合、ユーザークラスタの作成がタイムアウトする

アドオンサービスのプロジェクトまたはロケーションが互いに一致しない場合、管理クラスタの更新またはアップグレードが失敗する

ユーザー管理の管理ワークステーションを使用している場合、ユーザークラスタの削除に失敗する

外部サーバーへの下り（外向き）NAT ゲートウェイトラフィックが失敗する

kubelet と Kubernetes コントロールプレーン間のバージョンの不一致

非 HA コントロールプレーン V2 クラスタの削除がタイムアウトまで停止する

複数のキーが期限切れになった場合、サービスアカウントキーのローテーションが失敗する

ユーザークラスタコントローラが 1.16 にアップグレードされると、1.15 ユーザーマスターマシンで予期しない再作成が発生する

ホスト名が IP ブロックファイルにないとき、プリフライトチェックが失敗する

非 HA 管理クラスタとコントロールプレーン v1 のユーザークラスタを使用している場合、管理クラスタをアップグレードまたは更新するときにボリュームマウントが失敗する

コントロールプレーンノードの作成に失敗する

`$` と ` は vSphere のユーザー名またはパスワードでサポートされない

登録済みの管理クラスタのリソースリンクアノテーションが保持されない

CoreDNS `orderPolicy` が認識されない

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

`gkectl prepare windows` 失敗します。

`RootDistanceMaxSec` 構成が `ubuntu` ノードで有効になっていない

`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-Host アフィニティルールが原因でノードプールの作成が失敗する

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

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

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

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

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

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

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

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

GKE Identity Service によってコントロールプレーンのレイテンシが発生する可能性がある

ユーザークラスタコントロールプレーン Pod のヘルスチェックを受けない

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

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

コントロールプレーン V2 を使用した Windows ノードで calico-typha または anetd-operator クラッシュループが発生する

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

データプレーン v2 と互換性のない Anthos Service Mesh と他のサービスメッシュ

`kube-controller-manager` は、6 分後に永続ボリュームを強制的に切断することがある

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

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

コントロールプレーン V2 が有効になっている場合、クラスタオートスケーラーが機能しない

IP ブロックファイルで CIDR を使用できない

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

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

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

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

クラスタスナップショットの `system` シナリオで ClusterAPI オブジェクトが見つからない

vSAN 設定のノードのドレインでユーザークラスタの削除が停止する

`Cluster Autoscaler` clusterrolebinding と clusterrole が、ユーザークラスタを削除した後に削除される。

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

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

`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 クラスタのアップグレード中に短時間使用できなくなる場合があります