VMware 用 Google Distributed Cloud（ソフトウェアのみ）の既知の問題

このページでは、Google Distributed Cloud on VMware の既知の問題について説明します。このページは、基盤となるテクノロジー インフラストラクチャのライフサイクルを管理し、サービスレベル目標（SLO）が達成されていない場合やアプリケーションで障害が発生した場合にアラートやページに対応する IT 管理者とオペレーターを対象としています。Google Cloud のコンテンツで参照する一般的なロールとタスク例の詳細については、一般的な GKE Enterprise ユーザーロールとタスクをご覧ください。

既知の問題をプロダクトのバージョンまたは問題のカテゴリでフィルタするには、次のプルダウン メニューからフィルタを選択してください。

Google Distributed Cloud のバージョン: 1.29 1.28 1.16 1.15 1.14 1.13 1.12

問題のカテゴリ: 構成 インストール アップグレード 更新 運用 ロギングとモニタリング ネットワーキング セキュリティ ストレージ オペレーティング システム VMware ID その他

問題を具体的に指定:

カテゴリ	該当するバージョン	問題と回避策
アップグレード	1.16、1.28	アップグレード前の調整のタイムアウトが原因でユーザー クラスタのアップグレードが失敗する ユーザー クラスタをアップグレードするときに、アップグレード前の調整オペレーションが定義されたタイムアウトより長くかかり、アップグレードが失敗することがあります。次のようなエラー メッセージが表示されます。 Failed to reconcile the user cluster before upgrade: the pre-upgrade reconcile failed, error message: failed to wait for reconcile to complete: error: timed out waiting for the condition, message: Cluster reconcile hasn't finished yet, please fix that before rerun the upgrade. アップグレード前の調整オペレーションのタイムアウトは、5 分間と、ユーザー クラスタのノードプールごとに 1 分間です。 回避策: gkectl diagnose cluster コマンドがエラーなしで合格することを確認します。 gkectl upgrade cluster コマンドに --skip-reconcile-before-preflight フラグを追加して、アップグレード前の調整オペレーションをスキップします。例: gkectl upgrade cluster --skip-reconcile-before-preflight --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --config USER_CLUSTER_CONFIG_FILE
更新	1.16、1.28、1.29、1.30	DataplaneV2 ForwardMode の更新で anetd DaemonSet の再起動が自動的にトリガーされない gkectl update cluster を使用してユーザー クラスタの dataplaneV2.forwardMode フィールドを更新すると、変更は ConfigMap でのみ更新されます。anetd DaemonSet は、再起動されるまで構成変更を取得せず、変更は適用されません。 回避策: gkectl update cluster コマンドが完了すると、Done updating the user cluster の出力が表示されます。このメッセージが表示されたら、次のコマンドを実行して anetd DaemonSet を再起動し、構成変更を取得します。 kubectl --kubeconfig USER_CLUSTER_KUBECONFIG rollout restart daemonset anetd 再起動後に DaemonSet の準備状況を確認します。 kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get daemonset anetd 上記のコマンドの出力で、DESIRED 列の番号が READY 列の番号と一致することを確認します。
アップグレード	1.16	クラスタのアップグレード中に、管理クラスタのバックアップ ステージで etcdctl コマンドが見つからない 1.16 から 1.28 へのユーザー クラスタのアップグレード中に、管理クラスタがバックアップされます。管理クラスタのバックアップ プロセスで、「etcdctl: command not found」というエラー メッセージが表示されます。ユーザー クラスタのアップグレードが成功し、管理クラスタが正常な状態を維持します。唯一の問題は、管理クラスタのメタデータ ファイルがバックアップされていないことです。 この問題は、etcdctl バイナリが 1.28 で追加され、1.16 ノードで使用できないことが原因です。 管理クラスタのバックアップには、etcd のスナップショットを取得してから、管理クラスタのメタデータ ファイルを書き込むなどの複数のステップが含まれます。etcd Pod への exec 後に etcdctl をトリガーできるため、etcd バックアップは継続します。しかし、メタデータ ファイルの書き込みは、ノードにインストールされる etcdctl バイナリに依存するため、この処理は失敗します。ただし、メタデータ ファイルのバックアップが失敗しても、バックアップの妨げにはなりません。したがって、ユーザー クラスタのアップグレードと同様に、バックアップ プロセスは成功します。 回避策: メタデータ ファイルのバックアップを作成する場合、gkectl を使用して管理クラスタをバックアップして復元するの説明に従って、管理クラスタのバージョンと一致するバージョンの gkectl を使用して、別の管理クラスタ バックアップをトリガーします。
インストール	1.16～1.29	手動ロード バランシングを使用したユーザー クラスタの作成が失敗する 手動ロード バランシング用に構成されたユーザー クラスタを作成すると、バンドルされた Ingress が無効になっている場合でも、ingressHTTPNodePort 値が 30,000 以上である必要があることを示す gkectl check-config エラーが発生します。 この問題は、ingressHTTPNodePort フィールドと ingressHTTPSNodePort フィールドが設定されているかどうかに関係なく発生します。 回避策: この問題を回避するには、gkectl check-config から返された結果を無視します。バンドルされた Ingress を無効にするには、バンドルされた Ingress を無効にするをご覧ください。
更新	1.29.0	ユーザー クラスタを Controlplane V2 に移行した後、管理クラスタの metrics-server PDB が正しく構成されない PodDisruptionBudget（PDB）の問題は、高可用性（HA）管理クラスタを使用しているときに発生します。移行後にロールのない管理クラスタノードが 0 個または 1 個あります。ロールのないノード オブジェクトがあるかどうか確認するには、次のコマンドを実行します。 kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get nodes -o wide 移行後にロールのないノード オブジェクトが複数ある場合、PDB の構成が正しくありません。 症状: admin cluster diagnose の出力には、次の情報が含まれます。 Checking all poddisruptionbudgets...FAILURE Reason: 1 pod disruption budget error(s). Unhealthy Resources: PodDisruptionBudget metrics-server: gke-managed-metrics-server/metrics-server might be configured incorrectly: the total replicas(1) should be larger than spec.MinAvailable(1). 回避策: 次のコマンドを実行して PDB を削除します。 kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG delete pdb metrics-server -n gke-managed-metrics-server
インストール、アップグレード、更新	1.28.0-1.28.600、1.29.0-1.29.100	Binary Authorization ウェブブックが CNI プラグインをブロックするため、nodepool の 1 つが起動しない まれな競合状態で Binary Authorization Webhook と gke-connect Pod のインストール順序が正しくないため、ノードが準備完了状態にならず、ユーザー クラスタの作成が停止することがあります。影響を受けるシナリオでは、ノードが準備完了状態にならないことが原因で、ユーザー クラスタの作成が停止することがあります。この場合、次のメッセージが表示されます。 Node pool is not ready: ready condition is not true: CreateOrUpdateNodePool: 2/3 replicas are ready 回避策: 構成ファイルから Binary Authorization 構成を削除します。設定手順については、GKE on VMware での Binary Authorization の Day 2 インストール ガイドをご覧ください。 現在のクラスタ作成プロセス中に異常なノードのブロックを解除するには、次のコマンドを使用して、ユーザー クラスタ内の Binary Authorization Webhook 構成を一時的に削除します。 kubectl --kubeconfig USER_KUBECONFIG delete ValidatingWebhookConfiguration binauthz-validating-webhook-configuration ブートストラップ プロセスが完了したら、次の Webhook 構成を再度追加できます。 apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingWebhookConfiguration metadata: name: binauthz-validating-webhook-configuration webhooks: - name: "binaryauthorization.googleapis.com" namespaceSelector: matchExpressions: - key: control-plane operator: DoesNotExist objectSelector: matchExpressions: - key: "image-policy.k8s.io/break-glass" operator: NotIn values: ["true"] rules: - apiGroups: - "" apiVersions: - v1 operations: - CREATE - UPDATE resources: - pods - pods/ephemeralcontainers admissionReviewVersions: - "v1beta1" clientConfig: service: name: binauthz namespace: binauthz-system path: /binauthz # CA Bundle will be updated by the cert rotator. caBundle: Cg== timeoutSeconds: 10 # Fail Open failurePolicy: "Ignore" sideEffects: None
アップグレード	1.16、1.28、1.29	deletionTimestamp でミラーリングされたマシンが原因で CPV2 ユーザー クラスタのアップグレードが停止する ユーザー クラスタのアップグレード中に、ユーザー クラスタ内にミラーリングされたマシン オブジェクトに deletionTimestamp が含まれていると、アップグレード オペレーションが停止することがあります。アップグレードが停止した場合、次のエラー メッセージが表示されます。 machine is still in the process of being drained and subsequently removed この問題は、以前にユーザー クラスタ内にミラーリングされたマシンに gkectl delete machine を実行して、ユーザー コントロール プレーン ノードの修復を試みた場合に発生することがあります。 回避策: ミラーリングされたマシン オブジェクトを取得し、バックアップのためにローカル ファイルに保存します。 次のコマンドを実行して、ミラーリングされたマシンからファイナライザを削除し、ユーザー クラスタから削除されるまで待ちます。 kubectl --kubeconfig ADMIN_KUBECONFIG patch machine/MACHINE_OBJECT_NAME -n USER_CLUSTER_NAME-gke-onprem-mgmt -p '{"metadata":{"finalizers":[]}}' --type=merge Controlplane V2 ユーザー クラスタのコントロール プレーン ノードの手順に沿って、コントロール プレーン ノードでノードの修復をトリガーし、正しいソースマシン仕様がユーザー クラスタに再同期されるようにします。 gkectl upgrade cluster を再実行して、アップグレードを再開します。
構成、インストール	1.15、1.16、1.28、1.29	異なるサブネットにあるコントロール プレーン VIP が原因でクラスタの作成に失敗する HA 管理クラスタまたは ControlPlane V2 ユーザー クラスタの場合、コントロール プレーン VIP は他のクラスタノードと同じサブネットに存在する必要があります。そうでないと、kubelet はコントロール プレーン VIP を使用して API サーバーと通信できないため、クラスタの作成に失敗します。 回避策: クラスタを作成する前に、コントロール プレーン VIP が他のクラスタノードと同じサブネットに構成されていることを確認します。
インストール、アップグレード、更新	1.29.0～1.29.100	FQDN 以外の vCenter ユーザー名を使用すると、クラスタの作成またはアップグレードに失敗する クラスタの作成 / アップグレードが失敗し、vCenter ユーザー名が無効であることを示す vsphere CSI Pod のエラーが表示されます。これは、使用されているユーザー名が完全修飾ドメイン名ではないためです。vsphere-csi-controller Pod のエラー メッセージは次のとおりです。 GetCnsconfig failed with err: username is invalid, make sure it is a fully qualified domain username この問題は、完全修飾ドメインのユーザー名の使用を強制する検証が vSphere CSI ドライバに追加されたバージョン 1.29 以降でのみ発生します。 回避策: 認証情報構成ファイルの vCenter ユーザー名に完全修飾ドメイン名を使用します。たとえば、username1 ではなく、[e-mail] を使用します。
アップグレード、更新	1.28.0～1.28.500	バージョン 1.10 以前で作成されたクラスタで、管理クラスタのアップグレードに失敗する 管理クラスタを 1.16 から 1.28 にアップグレードすると、新しい管理マスターマシンのブートストラップ中にコントロール プレーン証明書を生成できない場合があります。この問題は、バージョン 1.28 以降の Kubernetes API サーバーで証明書の生成方法が変更されたことが原因で発生します。この問題は、バージョン 1.10 以前で作成されたクラスタを、リーフ証明書をローテーションしないまま 1.16 までアップグレードすると発生します。 管理クラスタのアップグレード失敗の原因が、この問題であるかどうかを判断するには、次の操作を行います。 SSH を使用して、アップグレードに失敗した管理マスターマシンに接続します。 /var/log/startup.log を開いて、次のようなエラーを検索します。 Error adding extensions from section apiserver_ext 801B3213B57F0000:error:1100007B:X509 V3 routines:v2i_AUTHORITY_KEYID:unable to get issuer keyid:../crypto/x509/v3_akid.c:177: 801B3213B57F0000:error:11000080:X509 V3 routines:X509V3_EXT_nconf_int:error in extension:../crypto/x509/v3_conf.c:48:section=apiserver_ext, name=authorityKeyIdentifier, value=keyid> 回避策: SSH を使用して、管理マスターマシンに接続します。詳細については、SSH を使用した管理クラスタノードへの接続をご覧ください。 /etc/startup/pki-yaml.sh を編集します。apiserver_ext、client_ext、etcd_server_ext、kubelet_server_ext の拡張機能のセクションで authorityKeyIdentifier=keyidset を見つけて、authorityKeyIdentifier=keyid,issuer に変更します。例: [ apiserver_ext ] keyUsage = critical, digitalSignature, keyEncipherment extendedKeyUsage=serverAuth basicConstraints = critical,CA:false authorityKeyIdentifier = keyid,issuer subjectAltName = @apiserver_alt_names 変更を /etc/startup/pki-yaml.sh に保存します。 /opt/bin/master.sh を実行して証明書を生成し、マシンの起動を完了します。 gkectl upgrade admin を再度実行して、管理クラスタをアップグレードします。 アップグレードが完了したら、ローテーションを開始するの説明に従って、管理クラスタとユーザー クラスタの両方のリーフ証明書をローテーションします。 証明書のローテーションが完了したら、前と同じ手順で /etc/startup/pki-yaml.sh を編集し、/opt/bin/master.sh を実行します。
構成	1.29.0	Dataplane V2 が有効になっているクラスタで、誤った警告メッセージが表示される gkectl を使用して、すでに Dataplane V2 が有効になっているクラスタの作成、更新、アップグレードを実行すると、次のような誤った警告メッセージが出力されます。 WARNING: Your user cluster is currently running our original architecture with [DataPlaneV1(calico)]. To enable new and advanced features we strongly recommend to update it to the newer architecture with [DataPlaneV2] once our migration tool is available. これは gkectl のバグです。クラスタの構成ファイルで enableDataplaneV2: true が設定されていても、dataplaneV2.forwardMode が使用されていないと、この警告が常に表示されます。 回避策: この警告は無視してかまいません。
構成	1.28.0-1.28.400、1.29.0	HA 管理クラスタのインストールのプリフライト チェックで、必要な静的 IP の数が正しく報告されない HA 管理クラスタを作成する際のプリフライト チェックで、次のような誤ったエラー メッセージが表示されます。 - Validation Category: Network Configuration - [FAILURE] CIDR, VIP and static IP (availability and overlapping): needed at least X+1 IP addresses for admin cluster with X nodes 1.28 以降の HA 管理クラスタにはアドオンノードがないため、この要件は該当しません。また、3 つの管理クラスタ コントロール プレーン ノードの IP は、管理クラスタの構成ファイルの network.controlPlaneIPBlock セクションに指定されているため、IP ブロック ファイルの IP は kubeception ユーザー クラスタ コントロール プレーン ノードにのみ必要です。 回避策: 修正されていないリリースで適切でないプリフライト チェックをスキップするには、gkectl コマンドに --skip-validation-net-config を追加します。
運用	1.29.0～1.29.100	管理クラスタを非 HA から HA に移行した後、Connect Agent が Google Cloud が接続できなくなる 管理クラスタを非 HA から HA に移行すると、管理クラスタの Connect Agent が gkeconnect.googleapis.com との接続を失い、「Failed to verify JWT signature」というエラーが表示されます。これは、移行中に KSA 署名鍵が変更されるため、OIDC JWK を更新するために再登録が必要になるためです。 回避策: 管理クラスタを Google Cloud に再接続するには、次の手順で再登録をトリガーします。 まず、gke-connect Deployment の名前を取得します。 kubectl --kubeconfig KUBECONFIG get deployment -n gke-connect gke-connect Deployment を削除します。 kubectl --kubeconfig KUBECONFIG delete deployment GKE_CONNECT_DEPLOYMENT -n gke-connect onpremadmincluster CR に force-reconcile アノテーションを追加して、onprem-admin-cluster-controller の強制調整をトリガーします。 kubectl --kubeconfig KUBECONFIG patch onpremadmincluster ADMIN_CLUSTER_NAME -n kube-system --type merge -p ' metadata: annotations: onprem.cluster.gke.io/force-reconcile: "true" ' 使用可能な既存の gke-connect Deployment が見つからない場合は、onprem-admin-cluster-controller が常に gke-connect Deployment を再デプロイし、クラスタを再登録します。 回避策を実施した後、gke-connect-agent ログから「Failed to verify JWT signature」400 エラーが消えているはずです（コントローラが調整を完了するまでに数分かかる場合があります）。 kubectl --kubeconfig KUBECONFIG logs GKE_CONNECT_POD_NAME -n gke-connect
インストール、オペレーティング システム	1.28.0-1.28.500～1.29.0	Docker ブリッジ IP で COS クラスタのコントロール プレーン ノードに 172.17.0.1/16 が使用される Google Distributed Cloud は、デフォルトの 172.17.0.1/16 サブネットの予約を防ぐため、Docker 構成で Docker ブリッジ IP 専用のサブネット --bip=169.254.123.1/24 を指定します。ただし、バージョン 1.28.0～1.28.500 と 1.29.0 では、COS OS イメージの回帰により、Google Distributed Cloud が Docker の構成をカスタマイズした後、Docker サービスが再起動されません。その結果、Docker はデフォルトの 172.17.0.1/16 をブリッジ IP アドレス サブネットとして選択します。この IP アドレス範囲内にすでに実行中のワークロードがある場合、IP アドレスの競合が発生する可能性があります。 回避策: この問題を回避するには、docker サービスを再起動する必要があります。 sudo systemctl restart docker Docker が正しいブリッジ IP アドレスを選択していることを確認します。 ip a | grep docker0 注: VM を再作成すると、この解決策は無効になります。VM が再作成されるたびに、この回避策を実施し直す必要があります。
更新	1.28.0～1.28.400、1.29.0～1.29.100	標準 CNI で複数のネットワーク インターフェースが機能しない 標準の CNI バイナリ bridge, ipvlan, vlan, macvlan, dhcp, tuning, host-local, ptp, portmap は、影響を受けるバージョンの OS イメージに含まれていません。これらの CNI バイナリは Dataplane v2 では使用されませんが、複数のネットワーク インターフェース機能で追加のネットワーク インターフェースに使用されます。 これらの CNI プラグインを使用すると、複数のネットワーク インターフェースは機能しません。 回避策: この機能を使用している場合は、修正が適用されたバージョンにアップグレードしてください。
更新	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 セクションを構成する必要はありません。ただし、このセクションが空の場合、Google Distributed Cloud は 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 Namespace の 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	管理クラスタと Controlplane V2 が有効になっているユーザー クラスタが異なる vSphere 認証情報を使用すると、clusterapi-controller がクラッシュすることがある 管理クラスタと Controlplane V2 が有効になっているユーザー クラスタが異なる vSphere 認証情報を使用していると（たとえば、管理クラスタの vSphere 認証情報の更新後）、再起動後に clusterapi-controller が vCenter に接続できないことがあります。管理クラスタの kube-system Namespace で実行されている 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 認証情報を更新して、管理クラスタと Controlplane 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 と比較します。この例では、grpc_code ラベルで Watch を確認します。 この指標は、次の 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 でアラートをミュートします。 アラートのミュートが選択できない場合は、次の手順で誤検出を抑制します。 変更が永続的に保持されるように、モニタリング オペレーターを 0 個のレプリカにスケールダウンします。 次の例に示すように、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 をクラスタの名前に置き換えます。 Prometheus と Alertmanager Statefulset を再起動して、新しい構成を取得します。 コードが問題のあるケースのいずれかに該当する場合は、etcd ログと kube-apiserver ログを確認して、さらにデバッグします。
ネットワーキング	1.16.0～1.16.2、1.28.0	接続時間の長い下り（外向き）NAT が切断される トラフィックがない場合、接続が確立されてから 5～10 分後に、下り（外向き）NAT 接続が切断されることがあります。 conntrack は、インバウンド方向（クラスタへの外部接続）でのみ問題になります。この問題は、接続がしばらく情報を送信していないときに宛先側で何かを送信すると発生します。下り（外向き）NAT の Pod が常にメッセージングをインスタンス化する場合、この問題は発生しません。 この問題は、デーモンが未使用と判断した conntrack エントリが anetd ガベージ コレクションによって誤って削除されるために発生します。この動作を修正するため、最近 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 がプリフライト チェック中にロードバランサの Ingress 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 Workload 検証チェックによって Pod が default Namespace にインストールされます。CSI ワークロード Pod は、vSphere CSI ドライバがインストールされ、動的ボリューム プロビジョニングを実行できることを確認します。この Pod が起動しないと、CSI ワークロードの検証チェックが失敗します。 この Pod の起動の妨げとなる既知の問題がいくつかあります。 Pod にリソース上限が指定されていない場合（Admission Webhook がインストールされている一部のクラスタの場合）、Pod は起動しません。 default Namespace で自動 Istio サイドカー インジェクションが有効になっている状態で、Cloud 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 Namespace で Istio サイドカーの自動インジェクションを一時的に無効にできます。Namespace のラベルを確認し、次のコマンドを使用して 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	管理クラスタのバージョンが 1.15 の場合、ユーザー クラスタの更新がタイムアウトする ユーザー管理の管理ワークステーションにログオンすると、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	管理クラスタのバージョンが 1.15 の場合、ユーザー クラスタの作成がタイムアウトする ユーザー管理の管理ワークステーションにログオンすると、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 がそれぞれ異なるワーカーノードにある場合、送信元 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）の使用時のディスクエラーとアタッチの失敗 Google Distributed Cloud は、ディスクの変更ブロック トラッキング（CBT）をサポートしていません。一部のバックアップ ソフトウェアは、CBT 機能を使用してディスクの状態を追跡し、バックアップを行います。このため、Google Distributed Cloud を実行する VM にディスクを接続できません。詳細については、VMware Knowledge Base の記事をご覧ください。 回避策: サードパーティのバックアップ ソフトウェアを使用すると、ディスクで CBT が有効になる可能性があるため、Google Distributed Cloud VM をバックアップしないでください。これらの VM をバックアップする必要はありません。 この変更は、更新またはアップグレードを行うと破棄されるため、ノードで CBT を有効にしないでください。 CBT が有効になっているディスクがすでにある場合は、VMware Knowledge Base の記事の解決策の手順に沿って、ファースト クラスのディスクで CBT を無効にします。
ストレージ	1.14、1.15、1.16	複数のホストから共有ファイルに並列追加が行われると NFSv3 上のデータが破損する Nutanix ストレージ アレイを使用して NFSv3 共有をホストに提供すると、データが破損したり、Pod が正常に動作しなくなることがあります。この問題は、特定のバージョンの VMware と Nutanix のバージョン間で確認されている互換性の問題が原因で発生します。詳細については、関連する VMware KB の記事をご覧ください。 回避策: VMware の KB 記事は最新でないため、現在実施できる解決策はありません。この問題を解決するには、ホスト上の ESXi を最新バージョンに更新し、ストレージ アレイ上の Nutanix を最新バージョンに更新します。
オペレーティング システム	1.13.10、1.14.6、1.15.3	kubelet と Kubernetes コントロール プレーンのバージョンの不一致 一部の Google Distributed Cloud リリースでは、ノードで実行される kubelet と Kubernetes コントロール プレーンのバージョンが一致していない場合があります。OS イメージにプリロードされた kubelet バイナリが異なるバージョンを使用しているため、このような不一致が発生します。 次の表に、確認されているバージョンの不一致を示します。 Google Distributed Cloud のバージョン 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	1 より大きいバージョンの CA を使用した管理クラスタのアップグレードまたは更新が失敗する 管理クラスタの認証局（CA）のバージョンが 1 より大きい場合、Webhook の CA バージョンの検証により、更新またはアップグレードが失敗します。gkectl upgrade / update の出力には、次のエラー メッセージが含まれます。 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 Controlplane V2 クラスタの削除で停止する 非 HA Controlplane V2 クラスタが削除されると、タイムアウトするまで、ノードの削除で処理が停止します。 回避策: クラスタに重要なデータを含む StatefulSet が含まれている場合は、Cloud カスタマーケアにお問い合わせください。 それ以外の場合は、次の操作を行います。 vSphere からすべてのクラスタ VM を削除します。vSphere UI で VM を削除するか、次のコマンドを実行します。 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 deployment 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: 修正適用済みのバージョン 1.16.6 以降の GKE on VMware を使用します。 オプション 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: 修正適用済みのバージョン 1.16.6 以降の GKE on VMware を使用します。 オプション 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 ユーザー クラスタ（Controlplane 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 失敗したオペレーションによって回避策が異なります。 アップグレード時の回避策: クラスタタイプに応じて回避策を行います。 ユーザー クラスタ: user-ip-block.yaml で、影響を受けるマシンのホスト名を一意の名前に変更し、強制更新をトリガーします。 gkectl update cluster --kubeconfig ADMIN_KUBECONFIG --config NEW_USER_CLUSTER_CONFIG --force 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 インストールの回避策: クラスタタイプに応じて回避策を行います。 管理クラスタ: 管理ノードマシンを削除します。 データディスクを削除します。 管理クラスタのチェックポイント ファイルを削除します。 admin-ip-block.yaml で、影響を受けるマシンのホスト名を一意の名前に変更します。 gkectl create admin を再実行します。 ユーザー クラスタ: リソースをクリーンアップします。 user-ip-block.yaml で、影響を受けるマシンのホスト名を一意の名前に変更します。 gkectl create cluster を再実行します。
運用	1.16.0、1.16.1、1.16.2、1.16.3	vSphere のユーザー名またはパスワードで $ と ` がサポートされない vSphere のユーザー名またはパスワードに $ または ` が含まれていると、次の処理を行うことができません。 Controlplane V2 が有効になっている 1.15 ユーザー クラスタを 1.16 にアップグレードする 1.15 高可用性（HA）管理クラスタを 1.16 にアップグレードする コントロール レーン V2 が有効な 1.16 ユーザー クラスタを作成する 1.16 HA 管理クラスタを作成する 修正が適用された 1.16.4 以降のバージョンの Google Distributed Cloud を使用するか、以下の回避策を実施してください。失敗したオペレーションによって回避策が異なります。 アップグレード時の回避策: 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 のユーザー名またはパスワードを更新します。 クラスタタイプに応じて回避策を行います。 管理クラスタ: 管理ノードマシンを削除します。 データディスクを削除します。 管理クラスタのチェックポイント ファイルを削除します。 gkectl create admin を再実行します。 ユーザー クラスタ: リソースをクリーンアップします。 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 deployment 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 クライアントの [Hosts and Clusters] ページに移動します。 [VM Templates] をクリックして、管理クラスタ名でフィルタします。 管理クラスタの 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 公開鍵エラーが発生する チェックポイントを有効にして非 HA 管理クラスタをアップグレード（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]... 回避策: 修正が適用された Google Distributed Cloud のパッチ バージョンにアップグレードできない場合は、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 管理クラスタが API に登録されるのは、クラスタを明示的に登録した場合だけはありません。GKE On-Prem クライアントを使用してユーザー クラスタをアップグレードした場合にも登録されます。 回避策: 管理クラスタの登録を解除します。 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 に再度登録される可能性があります。 管理クラスタが API に登録されるのは、クラスタを明示的に登録した場合だけはありません。GKE On-Prem クライアントを使用してユーザー クラスタをアップグレードした場合にも登録されます。 回避策: 管理クラスタの登録を解除します。 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 は、パラメータとして認識されないため、使用されません。代わりに、Google Distributed Cloud は常に 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	調整プロセスにより、管理クラスタの管理証明書が変更される Google Distributed Cloud は、クラスタ アップグレード時など、調整プロセスごとに管理クラスタのコントロール プレーンの管理証明書を変更します。この動作により、管理クラスタ（特にバージョン 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... 回避策: 修正が適用された Google Distributed Cloud のバージョン 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 を手動で割り当てる方法があります。Google Distributed Cloud コントローラは、クラスタのアップグレードなどの調整プロセス中に、こうした手動による変更を上書きします。 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 Namespace を削除します。 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 より前のバージョンの Google Distributed Cloud に Docker をインストールできません。 回避策: この問題を回避する一般的な方法は、Google Distributed Cloud 1.13 にアップグレードし、1.13 の gkectl を使用して Windows VM テンプレートを作成してから、Windows ノードプールを作成する方法です。以下に示すように、現在のバージョンから Google Distributed Cloud 1.13 にするには、次の 2 つの方法があります。 注: 現在のバージョンでこの問題を回避するには、1.13 にアップグレードする必要はありませんが、より多くの操作を手動で行う必要があります。この方法を検討する場合は、Google までお問い合わせください。 オプション 1: Blue/Green アップグレード Windows ノードプールを備えた Google Distributed Cloud 1.13 以降のバージョンで新しいクラスタを作成し、ワークロードを新しいクラスタに移行してから、現在のクラスタを破棄できます。最新の Google Distributed Cloud マイナー バージョンを使用することをおすすめします。 注: 新しいクラスタをプロビジョニングするために追加のリソースが必要になりますが、既存のワークロードのダウンタイムや停止は少なくなります。 オプション 2: Windows ノードプールを削除し、Google Distributed Cloud 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 ログを確認すると、osImageType の設定が空の文字列から ubuntu_containerd に変更されている箇所があります。 これらの更新エラーは、バージョン 1.9 で導入された管理クラスタ構成ファイルの osImageType フィールドが適切にバックフィルされていないために発生しています。 回避策: 修正が適用された Google Distributed Cloud のバージョンにアップグレードします。アップグレードできない場合は、この問題の解決方法を Cloud カスタマーケアにお問い合わせください。
インストール、セキュリティ	1.13、1.14、1.15、1.16	Controlplane V2 のユーザー クラスタで SNI が動作しない Controlplane V2 が有効な場合（enableControlplaneV2: true）、authentication.sni を使用するユーザー クラスタの Kubernetes API サーバーに追加のサービス証明書を提供する機能は動作しません。 回避策: SNI を使用する必要がある場合は、修正を適用した Google Distributed Cloud パッチが利用可能になるまで、Controlplane 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 回避策: $ なしで非公開レジストリのユーザー名を使用するか、修正が適用された Google Distributed Cloud のバージョンを使用します。
アップグレード、更新	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 Namespace の管理クラスタで 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 Controlplane 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 が失敗状態のままになる コントロール プレーン ノードの再作成または更新後に、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 移行のストレージ プリフライト チェックは、CSI 移行の後に無視されるパラメータが StorageClasses にないことを確認します。たとえば、diskformat パラメータが設定された StorageClass がある場合、gkectl upgrade admin は StorageClass にフラグを付け、プリフライト検証で失敗を報告します。Google Distributed Cloud 1.10 以前で作成された管理クラスタには、diskformat: thin が設定された StorageClass があります。このため、この検証は失敗しますが、この StorageClass は CSI 移行の後も正常に動作します。このエラーは、警告として解釈する必要があります。 詳細については、in-tree vSphere ボリュームの vSphere コンテナ ストレージ プラグインへの移行の StorageClass パラメータのセクションをご覧ください。 回避策: CSI 移行後に、CSI 移行の後で無視されるパラメータのある StorageClass がクラスタに存在することを確認したら、--skip-validation-cluster-health フラグを使用して gkectl upgrade admin を実行します。
ストレージ	1.15、1.16	Windows ファイル システムを使用して移行された in-tree vSphere ボリュームが vSphere CSI ドライバで使用できない 特定の条件下では、Windows ノードにディスクを読み取り専用としてアタッチできます。これにより、対応するボリュームが 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 Namespace で 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 デプロイが正常にロールアウトされたら、更新された 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 の Controlplane 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 の後にコントロール プレーンの証明書のローテーションが自動的に行われるために発生します。 この問題は、Controlplane v2 を使用していないユーザー クラスタでのみ発生します。 回避策: gkectl list clusters で、クラスタの状態が再び RUNNING に戻るまで待つか、修正が適用されたバージョン（1.13.6 以降、1.14.2 以降、または 1.15 以降）にアップグレードします。
アップグレード、更新	1.12.7	問題のあるリリース 1.12.7-gke.19 の削除 Google Distributed Cloud 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 できない場合があります。 この問題は、Google Distributed Cloud リリース 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 Namespace にコピーします。 kubectl --kubeconfig=KUBECONFIG -n=kube-system get secret private-registry-creds -oyaml | sed 's/ namespace: .*/ namespace: gke-connect/' | kubectl --kubeconfig=KUBECONFIG -n=gke-connect apply -f - gke-connect-agent 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、1.14	etcd ウォッチの不足 etcd バージョン 3.4.13 以前を実行しているクラスタで、ウォッチが不足したり、動作していないリソースのウォッチが発生する場合があります。これにより、次の問題が発生する可能性があります。 Pod のスケジューリングが中断される ノードが登録できない kubelet が Pod の変更をモニタリングしない これらの問題により、クラスタが機能しなくなる場合があります。 この問題は、Google Distributed Cloud リリース 1.12.7、1.13.6、1.14.3 以降のリリースで修正されています。これらの新しいリリースでは、etcd バージョン 3.4.21 が使用されています。Google Distributed Cloud の以前のバージョンはすべて、この問題の影響を受けます。 回避策 直ちにアップグレードできない場合は、クラスタ内のノード数を減らすことで、クラスタ障害のリスクを軽減できます。etcd_network_client_grpc_sent_bytes_total 指標が 300 MBps 未満になるまでノードを削除します。 この指標を Metrics Explorer で表示するには: Google Cloud コンソールの Metrics Explorer に移動します。 Metrics Explorer に移動 [構成] タブを選択します。 [指標の選択] を開き、フィルタバーに「Kubernetes Container」と入力してから、サブメニューを使用して指標を選択します。 [有効なリソース] メニューで [Kubernetes コンテナ] を選択します。 [有効な指標カテゴリ] メニューで [Anthos] を選択します。 [アクティブな指標] メニューで [etcd_network_client_grpc_sent_bytes_total] を選択します。 [適用] をクリックします。
アップグレード、更新	1.10、1.11、1.12、1.13、1.14	GKE Identity Service が原因でコントロール プレーンのレイテンシが高くなる クラスタの再起動またはアップグレード後に、認証 Webhook を介して kube-apiserver から GKE Identity Service に転送された期限切れの JWT トークンで構成されるトラフィックで、GKE Identity Service が過負荷状態になる可能性があります。GKE Identity Service はクラッシュ ループしませんが、応答不能となり、それ以上リクエストを処理できなくなります。この問題により、最終的にコントロール プレーンのレイテンシが高くなります。 この問題は、次の Google Distributed Cloud リリースで修正されています。 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 の名前と Namespace を確認します。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 コマンドは、どちらも Namespace 全体の Pod のヘルスチェックを含む一連のヘルスチェックを実行します。しかし、ユーザー コントロール プレーン Pod が誤ってスキップされます。Controlplane 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 へのリダイレクトの影響を受ける可能性がある 2023 年 3 月 20 日、Kubernetes はトラフィックを k8s.gcr.io から registry.k8s.io にリダイレクトしました。Google Distributed Cloud 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 テーブル挿入エラーによるアプリケーションのタイムアウト Google Distributed Cloud バージョン 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	Controlplane v2 を使用した Windows ノードで calico-typha または anetd-operator クラッシュ ループが発生する Controlplane 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+	Cloud Service Mesh と他のサービス メッシュが Dataplane v2 と互換性がない Dataplane v2 はロード バランシングを引き継ぎ、パケットベースの DNAT の代わりにカーネル ソケットを作成します。Pod はバイパスされ、IPTables は使用されないため、Cloud Service Mesh はパケット検査を実施できません。 サイドカーはパケット検査を実行できないため、kube-proxy のフリーモードでは、接続が失われるか、Cloud Service Mesh を使用したサービスでトラフィック ルーティングが正しく行われません。 この問題は、Google Distributed Cloud 1.10 のすべてのバージョンで発生しますが、1.10（1.10.2 以降）の一部の新しいバージョンには回避策があります。 回避策: 完全な互換性を確保する場合は 1.11 にアップグレードします。1.10.2 以降を実行している場合は以下を実行します。 kubectl edit cm -n kube-system cilium-config --kubeconfig USER_CLUSTER_KUBECONFIG configmap に bpf-lb-sock-hostns-only: true を追加し、anendd DaemonSet を再起動します。 kubectl rollout restart ds anetd -n kube-system --kubeconfig USER_CLUSTER_KUBECONFIG
ストレージ	1.12+、1.13.3	kube-controller-manager が 6 分後に永続ボリュームを強制的に切断することがある PV / PVC を切断するときに、kube-controller-manager が 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 に割り当てられたり、VM に異なる IP が割り当てられ、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 コンソールまたは 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+	Controlplane V2 が有効になっていると、クラスタ オートスケーラーが機能しない Controlplane 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 イメージタイプを更新するときに、対応するユーザー クラスタが Controlplane 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 の作成エラーまたは削除エラーが発生する Google Distributed Cloud 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 ファイルを含むディレクトリにアクセスできないため、トークンを更新できません。 回避策: この問題は、Google Distributed Cloud バージョン 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/31 のようにします。N+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+	gkectl update コマンドを使用して常時有効なシークレット暗号化機能が有効になっている場合、管理マスター VM を新しいブートディスク（たとえばgkectl repair admin-master）で再作成できない クラスタ作成時に、常時有効のシークレット暗号化機能を有効にせず、後で 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 より前の Google Distributed Cloud を使用していて、クラスタの gmp-system Namespace に Google マネージド Prometheus（GMP）コンポーネントを手動で設定している場合、バージョン 1.12.x にアップグレードすると、コンポーネントが維持されません。 バージョン 1.12 以降では、gmp-system Namespace と CRD は stackdriver オブジェクトで管理され、デフォルトで enableGMPForApplications フラグが false に設定されています。1.12 にアップグレードする前に、Namespace に GMP コンポーネントを手動でデプロイすると、stackdriver によってリソースが削除されます。 回避策: 既存のすべての PodMonitoring カスタム リソース（CR）をバックアップします。 すべてのクラスタをバージョン 1.12 にアップグレードし、Managed Service for Prometheus を有効にします。 PodMonitoring CR を再デプロイします。
運用	1.11、1.12、1.13.0～1.13.1	クラスタ スナップショットの system シナリオに ClusterAPI オブジェクトがない system シナリオでは、クラスタ スナップショットに default Namespace のリソースは含まれません。 ただし、この Namespace の下にある 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 環境でユーザー クラスタを削除しているときに、ノードのドレインが停止する 次のシナリオで、ユーザー クラスタを削除、更新、またはアップグレードしているときにノードのドレインが停止することがあります。 管理クラスタが、vSAN でバージョン 1.12.x 以降の 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 ドライバのデフォルト ディレクトリです。現在の実装では kubevols が常に存在すると想定されているため、PVC / PV オブジェクトが作成されていないと、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 が有効になっている同じ管理クラスタのすべてのユーザー クラスタに影響します。この問題は、同じ管理クラスタ内のすべての cluster autoscaler Pod に同じ clusterrole と clusterrolebinding が使用されるために発生します。 次のような症状がみられます。 cluster-autoscaler ログ kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \ cluster-autoscaler ここで、ADMIN_CLUSTER_KUBECONFIG は、管理クラスタの 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 は、管理クラスタの 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 は、管理クラスタの kubeconfig ファイルです。表示される可能性のあるエラー メッセージの例: vsphere-metrics-exporter/cmd/vsphere-metrics-exporter/main.go:68: Failed to watch *v1alpha1.Cluster: failed to list *v1alpha1.Cluster: clusters.cluster.k8s.io is forbidden: User "system:serviceaccount:kube-system:vsphere-metrics-exporter" cannot list resource "clusters" in API group "cluster.k8s.io" in the namespace "default" 回避策: 回避策の手順を表示 次の YAML を管理クラスタに適用します。 vsphere-metrics-exporter の場合 kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: vsphere-metrics-exporter rules: - apiGroups: - cluster.k8s.io resources: - clusters verbs: [get, list, watch] - apiGroups: - "" resources: - nodes verbs: [get, list, watch] --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: labels: k8s-app: vsphere-metrics-exporter name: vsphere-metrics-exporter namespace: kube-system roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: vsphere-metrics-exporter subjects: - kind: ServiceAccount name: vsphere-metrics-exporter namespace: kube-system cluster-health-controller の場合 apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: cluster-health-controller-role rules: - apiGroups: - "*" resources: - "*" verbs: - "*"
構成	1.12.1～1.12.3、1.13.0～1.13.2	gkectl check-config が OS イメージ検証で失敗する これは、gkectl prepare を実行せずに gkectl check-config が失敗する可能性がある既知の問題です。gkectl prepare を実行する前にこのコマンドの実行をすすめているため、混乱が生じています。 gkectl check-config コマンドが次のエラー メッセージで失敗します。 Validator result: {Status:FAILURE Reason:os images [OS_IMAGE_NAME] don't exist, please run `gkectl prepare` to upload os images. UnhealthyResources:[]} 回避策: オプション 1: gkectl prepare を実行して、不足している OS イメージをアップロードします。 オプション 2: gkectl check-config --skip-validation-os-images を使用して、OS イメージの検証をスキップします。
アップグレード、更新	1.11、1.12、1.13	アンチ アフィニティ グループの更新時に gkectl update admin/cluster が失敗する これは、anti affinity groups の更新時に gkectl update admin/cluster が失敗する可能性がある既知の問題です。 gkectl update コマンドが次のエラー メッセージで失敗します。 Waiting for machines to be re-deployed... ERROR Exit with error: Failed to update the cluster: timed out waiting for the condition 回避策: 回避策の手順を表示 更新を有効にするには、更新が失敗した after にマシンを再作成する必要があります。 管理クラスタを更新する場合は、ユーザー マスターノードと管理アドオンノードを再作成する必要があります。 ユーザー クラスタを更新する場合は、ユーザー ワーカーノードを再作成する必要があります。 ユーザー ワーカーノードを再作成するには オプション 1 ノードプールの更新に従って CPU またはメモリを変更して、ノードのローリング再作成をトリガーします。 オプション 2 kubectl delete を使用してマシンを 1 つずつ再作成します。 kubectl delete machines MACHINE_NAME --kubeconfig USER_KUBECONFIG ユーザー マスターノードを再作成するには オプション 1 コントロール プレーンのサイズの変更に従って CPU またはメモリを変更して、ノードのローリング再作成をトリガーします。 オプション 2 kubectl delete を使用してマシンを 1 つずつ再作成します。 kubectl delete machines MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG 管理アドオンノードを再作成するには kubectl delete を使用してマシンを 1 つずつ再作成します。 kubectl delete machines MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG
インストール、アップグレード、更新	1.13.0～1.13.8、1.14.0～1.14.4、1.15.0	構成されたホスト名にピリオドが含まれていると、ノードの登録に失敗する クラスタの作成、アップグレード、更新、ノードの自動修復時に、ipMode.type が static で、IP ブロック ファイルに構成されているホスト名にピリオドが 1 つ以上含まれていると、ノードの登録に失敗します。この場合、ノードの証明書署名リクエスト（CSR）は自動的に承認されません。 ノードの保留中の CSR を表示するには、次のコマンドを実行します。 kubectl get csr -A -o wide 次のログでエラー メッセージがないか確認します。 管理クラスタで、clusterapi-controllers Pod の clusterapi-controller-manager コンテナのログを表示します。 kubectl logs clusterapi-controllers-POD_NAME \ -c clusterapi-controller-manager -n kube-system \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG ユーザー クラスタで同じログを表示するには、次のコマンドを実行します。 kubectl logs clusterapi-controllers-POD_NAME \ -c clusterapi-controller-manager -n USER_CLUSTER_NAME \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG ここで ADMIN_CLUSTER_KUBECONFIG は、管理クラスタの kubeconfig ファイルです。 USER_CLUSTER_NAME は、ユーザー クラスタの名前です。 表示される可能性のあるエラー メッセージの例: "msg"="failed to validate token id" "error"="failed to find machine for node node-worker-vm-1" "validate"="csr-5jpx9" 問題のあるノードの kubelet ログを表示します。 journalctl --u kubelet 表示される可能性のあるエラー メッセージの例: "Error getting node" err="node \"node-worker-vm-1\" not found" IP ブロック ファイルのホスト名フィールドにドメイン名を指定すると、最初のピリオドに続く文字は無視されます。たとえば、ホスト名を bob-vm-1.bank.plc と指定すると、VM のホスト名とノード名が bob-vm-1 に設定されます。 ノード ID の検証が有効になっていると、CSR 承認者はノード名とマシン仕様のホスト名を比較し、名前の調整に失敗します。承認者が CSR を拒否し、ノードがブートストラップに失敗します。 回避策: ユーザー クラスタ 次の手順でノード ID の検証を無効にします。 ユーザー クラスタの構成ファイルに次のフィールドを追加します。 disableNodeIDVerification: true disableNodeIDVerificationCSRSigning: true ファイルを保存し、次のコマンドを実行してユーザー クラスタを更新します。 gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --config USER_CLUSTER_CONFIG_FILE 次のように置き換えます。 ADMIN_CLUSTER_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス。 USER_CLUSTER_CONFIG_FILE: ユーザー クラスタの構成ファイルのパス。 管理クラスタ OnPremAdminCluster カスタム リソースを開いて編集します。 kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ edit onpremadmincluster -n kube-system カスタム リソースに次のアノテーションを追加します。 features.onprem.cluster.gke.io/disable-node-id-verification: enabled 管理クラスタ コントロール プレーンで kube-controller-manager マニフェストを編集します。 管理クラスタのコントロール プレーン ノードに SSH で接続します。 kube-controller-manager マニフェストを開いて編集します。 sudo vi /etc/kubernetes/manifests/kube-controller-manager.yaml controllers のリストを見つけます。 --controllers=*,bootstrapsigner,tokencleaner,-csrapproving,-csrsigning このセクションを以下のように更新します。 --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.
Networking	1.10, 1.11.0-1.11.3, 1.12.0-1.12.2, 1.13.0	NetworkGatewayNodes marked unhealthy from concurrent status update conflict In networkgatewaygroups.status.nodes, some nodes switch between NotHealthy and Up. Logs for the ang-daemon Pod running on that node reveal repeated errors: 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: 最終的に単独でアップグレードが完了するまで待機します。 環境での分析と再現に基づいて、アップグレードは手動による介入なしで最終的に完了します。このオプションの注意点は、各マシン オブジェクトでファイナライザの削除にどのくらい時間がかかるかわからないことです。この処理は、すぐに行われる可能性もありますが、machineset コントローラの調整が非常に高速で処理され、調整の間にマシン コントローラがファイナライザを削除する時間がないと、数時間にわたり継続する可能性があります。 このオプションの優れている点は、お客様側で操作する必要がなく、ワークロードが中断されないことです。アップグレードが完了するまで、さらに時間がかかります。 オプション 2: すべての古いマシン オブジェクトに自動修復アノテーションを適用します。 machineset コントローラは、自動修復アノテーションが適用され、削除タイムスタンプがゼロ以外のマシンを除外し、それらのマシンに対する削除呼び出しを繰り返しません。これにより、競合状態を回避できます。 デメリットは、マシン上の 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	vCenter URL に https:// または http:// 接頭辞が含まれていると、クラスタの起動に失敗することがある 次のエラーで管理クラスタの作成に失敗します。 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 にアップグレードすることをおすすめします。
ID	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" 回避策: 回避策の手順を表示 問題を軽減するために、次のコマンドを実行します。 まず、cert-manager Deployment への変更が元に戻されないように、monitoring-operator をスケールダウンします。 kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system \ scale deployment monitoring-operator --replicas=0 実行中のレプリカは 1 つしかないため、cert-manager-cainjector Deployment を編集してリーダー選出を無効にします。単一レプリカの場合、この操作は必要ありません。 # 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 のままにします。そうしないと、変更が元に戻されます。 インストールが完了し、クラスタが稼働したら、Day 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 状態になります。最終的に、そのノードは自動修復されて新しいノードが作成されます。 関連する govmomi のバグ。 回避策: この回避策は VMware のサポートによって提供されます。 この問題は、vCenter バージョン 7.0U2 以降で修正されています。 それより前のバージョンの場合は、ホストを右クリックして、[Connection] > [Disconnect] の順に選択します。次に、再接続します。これにより、VM のポートグループが強制的に更新されます。
オペレーティング システム	1.10、1.11、1.12、1.13	SSH 接続がリモートホストによって切断される Google Distributed Cloud バージョン 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 Namespace にインストールされます。なんらかの理由で独自の cert-manager をインストールする必要がある場合は、次の手順で競合を回避してください。 この作業はクラスタごとに 1 回だけ行う必要があります。変更はクラスタのアップグレード後も保持されます。 注: 独自の cert-manager をインストールする場合の一般的な症状として、cert-manager のバージョンまたはイメージ（v1.7.2 など）が古いバージョンに戻されることがあります。これは、monitoring-operator が cert-manager を調整し、バージョンを元に戻す場合に発生します。 回避策: アップグレード中の競合を回避します。 使用しているバージョンの cert-manager をアンインストールします。独自のリソースを定義している場合は、リソースをバックアップすることをおすすめします。 アップグレードを実行します。 独自の cert-manager を復元するには、次の操作を行います。 ユーザー クラスタで独自の cert-manager を復元する monitoring-operator Deployment を 0 にスケーリングします。 kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ -n USER_CLUSTER_NAME \ scale deployment monitoring-operator --replicas=0 monitoring-operator によって管理される cert-manager Deployment を 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 Namespace にインストールされている場合は、この手順をスキップできます。それ以外の場合は、metrics-ca cert-manager.io/v1 証明書と metrics-pki.cluster.local Issuer リソースを cert-manager から、インストールした cert-manager のクラスタ リソースの Namespace にコピーします。 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 を復元する 一般に、管理クラスタは Google Distributed Cloud コントロール プレーン ワークロードのみを実行するため、管理クラスタに cert-manager を再インストールする必要はありません。まれに、独自の cert-manager を管理クラスタにインストールする必要が生じた場合は、競合を回避するために次のように操作してください。Apigee を利用していて、Apigee の cert-manager のみを必要とする場合は、管理クラスタ コマンドを実行する必要はありません。 monitoring-operator Deployment を 0 にスケーリングします。 kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ -n kube-system scale deployment monitoring-operator --replicas=0 monitoring-operator によって管理される cert-manager Deployment を 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 を再インストールします。必要に応じて、カスタマイズしたリソースを復元します。 アップストリームのデフォルト cert-manager のインストールを使用している場合、または cert-manager が cert-manager Namespace にインストールされている場合は、この手順をスキップできます。それ以外の場合は、metrics-ca cert-manager.io/v1 証明書と metrics-pki.cluster.local Issuer リソースを cert-manager から、インストールした cert-manager のクラスタ リソースの Namespace にコピーします。 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 の脆弱性スキャンにおける誤検出 Google Distributed Cloud の Ubuntu OS イメージ内の Docker、containerd、runc は、Ubuntu PPA を使用して特別なバージョンに固定されています。これにより、コンテナ ランタイムの変更が各リリース前に Google Distributed Cloud によって認定されるようになります。 ただし、特殊なバージョンは、さまざまな CVE スキャンツールで脆弱性フィードとして使用されている Ubuntu CVE Tracker に認識されていません。このため、Docker、containerd、runc の脆弱性スキャンで誤検出が発生します。 たとえば、CVE スキャンで次の誤検出が発生することがあります。これらの CVE は、Google Distributed Cloud の最新のパッチ バージョンで修正済みです。 CVE-2019-16884 CVE-2019-19921 CVE-2020-15157 CVE-2020-15257 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 の readiness チェックが失敗した HA クラスタの作成またはアップグレード中にクラスタの診断で konnectivity の readiness チェックに失敗した場合、通常、Google Distributed Cloud（kubectl exec、kubectl log、Webhook）の機能に影響はありません。この状況は、不安定なネットワーキングなどの問題が原因で、konnectivity の 1、2 個のレプリカが一定期間読み取り不能になっていると発生します。 回避策: konnectivity は自己回復します。30 分から 1 時間待ってから、クラスタの診断を再度実行してください。
オペレーティング システム	1.7、1.8、1.9、1.10、1.11	/etc/cron.daily/aide CPU とメモリの急増に関する問題 Google Distributed Cloud バージョン 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 がバンドルされているロードバランサがデプロイされている場合、Google Distributed Cloud バージョン 1.9 以降をデプロイすると、stackdriver-operator が gke-metrics-agent-conf ConfigMap の作成に失敗し、gke-connect-agent Pod がクラッシュ ループに入る可能性があります。 根本的な問題は、Seesaw が非対称接続フローを使用するため、Seesaw ロードバランサを通るクライアントからユーザー クラスタ API サーバーへの接続が、ステートフル NSX-T 分散ファイアウォール ルールによって解除されることです。NSX-T 分散ファイアウォール ルールとの連携の問題は、Seesaw を使用するすべての Google Distributed Cloud リリースに影響します。独自のアプリケーションで、32K を超える大規模な Kubernetes オブジェクトを作成すると、同様の接続問題が発生することがあります。 回避策: こちらの手順に沿って NSX-T 分散ファイアウォール ルールを無効にするか、Seesaw VM にステートレス分散ファイアウォール ルールを使用します。 クラスタで手動ロードバランサを使用している場合は、こちらの手順に沿って、バックエンド ノードの障害検出時にクライアント接続がリセットされるようロードバランサを構成します。この構成を行わないと、サーバー インスタンスが停止したときに、Kubernetes API サーバーのクライアントが数分間応答不能になる可能性があります。
ロギングとモニタリング	1.10、1.11、1.12、1.13、1.14、1.15	予想外の請求のモニタリング Google Distributed Cloud バージョン 1.10～1.15 で、[お支払い] ページに予想外に高い Metrics volume の料金が表示される場合があります。この問題は、次の両方の状況に該当する場合にのみ影響します。 アプリケーションのロギングとモニタリングが有効になっている（enableStackdriverForApplications=true） アプリケーション Pod に prometheus.io/scrap=true アノテーションがある（このアノテーションは Cloud 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 アノテーションを削除します。アノテーションが Cloud Service Mesh によって追加される場合は、Prometheus オプションなしで Cloud Service Mesh を構成するか、Istio 指標マージ機能をオフにすることを検討してください。
インストール	1.11、1.12、1.13	vSphere データディスクの作成時にインストーラが失敗する カスタムロールが誤った権限レベルでバインドされていると、Google Distributed Cloud インストーラが失敗する可能性があります。 ロール バインディングが間違っていると、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 エラーが頻繁に発生する Google Distributed Cloud バージョン 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 node status」を削除します。こちらの手順で「GKE on-prem node status」を再インストールします。 Google Cloud Monitoring ダッシュボードで「GKE on-prem node utilization」を削除します。こちらの手順で「GKE on-prem node utilization」を再インストールします。 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 で不明な指標データ Google Distributed Cloud バージョン 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	管理クラスタに scheduler と controller-manager の指標がない 管理クラスタがこの問題の影響を受ける場合、scheduler と controller-manager の指標が欠落しています。たとえば、次の 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	ユーザー クラスタに scheduler と controller-manager の指標がない ユーザー クラスタがこの問題の影響を受ける場合、scheduler と controller-manager の指標が欠落しています。たとえば、次の 2 つの指標が欠落しています。 # scheduler metric example scheduler_pending_pods # controller-manager metric example replicaset_controller_rate_limiter_use 回避策: この問題は、Google Distributed Cloud バージョン 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 は、管理クラスタの構成ファイルのパスに置き換えます。
ID	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 は、クラスタのフリートホスト プロジェクトの 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 モードで動作します。デフォルトでは、data-plane IP の学習が原因で Cisco ACI では機能しません。 回避策: この問題を回避するには、Seesaw IP アドレスを Cisco Application Policy Infrastructure Controller（APIC）の L4-L7 仮想 IP として追加し、IP の学習を無効にします。 [Tenant] > [Application Profiles] > [Application EPGs] または [uSeg EPGs] に移動すると、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（ビルド 18644231） vSphere ESXi 7.0 Update 3a（ビルド 18825058） vSphere ESXi 7.0 Update 3b（ビルド 18905247） vSphere vCenter 7.0 Update 3b（ビルド 18901211） 回避策: その後、VMWare はこれらのリリースを削除しました。ESXi と vCenter Server を新しいバージョンにアップグレードする必要があります。
オペレーティング システム	1.10、1.11、1.12、1.13	COS ノードで実行されている Pod に emptyDir ボリュームを 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 Google Distributed Cloud バージョン 1.10、1.11、1.12 の場合、ディスクでバッファリングされたログが破損していると、stackdriver-log-forwarder DaemonSet で CrashLoopBackOff エラーが発生することがあります。 回避策: この問題を軽減するには、ノード上のバッファログをクリーンアップする必要があります。 予期しない動作を防ぐには、stackdriver-log-forwarder をスケールダウンします。 kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \ -n kube-system patch daemonset stackdriver-log-forwarder -p '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}' USER_CLUSTER_KUBECONFIG は、ユーザー クラスタの kubeconfig ファイルのパスに置き換えます。 クリーンアップした DaemonSet をデプロイして、壊れたチャンクをクリーンアップします。 kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \ -n kube-system -f - << EOF apiVersion: apps/v1 kind: DaemonSet metadata: name: fluent-bit-cleanup namespace: kube-system spec: selector: matchLabels: app: fluent-bit-cleanup template: metadata: labels: app: fluent-bit-cleanup spec: containers: - name: fluent-bit-cleanup image: debian:10-slim command: ["bash", "-c"] args: - | rm -rf /var/log/fluent-bit-buffers/ echo "Fluent Bit local buffer is cleaned up." sleep 3600 volumeMounts: - name: varlog mountPath: /var/log securityContext: privileged: true tolerations: - key: "CriticalAddonsOnly" operator: "Exists" - key: node-role.kubernetes.io/master effect: NoSchedule - key: node-role.gke.io/observability effect: NoSchedule volumes: - name: varlog hostPath: path: /var/log EOF クリーンアップの DaemonSet がすべてのチャンクをクリーンアップしたことを確認するには、次のコマンドを実行します。2 つのコマンドの出力で、クラスタ内のノード数が同じになるはずです。 kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \ logs -n kube-system -l app=fluent-bit-cleanup | grep "cleaned up" | wc -l kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \ -n kube-system get pods -l app=fluent-bit-cleanup --no-headers | wc -l クリーンアップの DaemonSet を削除します。 kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \ -n kube-system delete ds fluent-bit-cleanup stackdriver-log-forwarder を再開します。 kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \ -n kube-system patch daemonset stackdriver-log-forwarder --type json -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'
ロギングとモニタリング	1.10、1.11、1.12、1.13、1.14、1.15、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 ログの入力レートが Logging エージェントの制限を超えている可能性があります。このため、stackdriver-log-forwarder はログを送信しません。この問題は、すべての Google Distributed Cloud バージョンで発生します。 回避策: この問題を軽減するには、Logging エージェントのリソース上限を増やす必要があります。 stackdriver リソースを開いて編集します。 kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \ --namespace kube-system edit stackdriver stackdriver stackdriver-log-forwarder の CPU リクエストを増やすには、次の resourceAttrOverride セクションを stackdriver マニフェストに追加します。 spec: resourceAttrOverride: stackdriver-log-forwarder/stackdriver-log-forwarder: limits: cpu: 1200m memory: 600Mi requests: cpu: 600m memory: 600Mi 編集後のリソースは次のようになります。 spec: anthosDistribution: on-prem clusterLocation: us-west1-a clusterName: my-cluster enableStackdriverForApplications: true gcpServiceAccountSecretName: ... optimizedMetrics: true portable: true projectID: my-project-191923 proxyConfigSecretName: ... resourceAttrOverride: stackdriver-log-forwarder/stackdriver-log-forwarder: limits: cpu: 1200m memory: 600Mi requests: cpu: 600m memory: 600Mi 変更を保存し、テキスト エディタを終了します。 変更が有効になっていることを確認するには、次のコマンドを実行します。 kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \ --namespace kube-system get daemonset stackdriver-log-forwarder -o yaml \ | grep "cpu: 1200m" 編集内容が有効になっている場合は、このコマンドで cpu: 1200m が検出されます。
セキュリティ	1.13	NodeReady 後に Kubelet サービスが一時的に利用できなくなる ノードの準備ができても kubelet サーバー証明書の準備ができていない期間が少しあります。この 10 秒間は kubectl exec と kubectl logs を使用できません。これは、新しいサーバー証明書の承認者が、更新された有効なノードの IP を確認するのに時間がかかるためです。 この問題は kubelet サーバー証明書にのみ影響します。Pod のスケジューリングには影響しません。
アップグレード、更新	1.12	部分的な管理クラスタのアップグレードで、後のユーザー クラスタのアップグレードがブロックされない ユーザー クラスタのアップグレードが次のエラーで失敗します。 .LBKind in body is required (Check the status of OnPremUserCluster 'cl-stg-gdl-gke-onprem-mgmt/cl-stg-gdl' and the logs of pod 'kube-system/onprem-user-cluster-controller' for more detailed debugging information. 管理クラスタが完全にアップグレードされておらず、ステータス バージョンがまだ 1.10 になっています。1.12 へのユーザー クラスタのアップグレードは、プリフライト チェックではブロックされませんが、バージョン スキューの問題で失敗します。 回避策: 管理クラスタを 1.11 にアップグレードしてから、ユーザー クラスタを 1.12 にアップグレードします。
ストレージ	1.10.0～1.10.5、1.11.0～1.11.2、1.12.0	データストアで不足している空き容量が正しく報告されない gkectl diagnose cluster コマンドが次のエラーで失敗します。 Checking VSphere Datastore FreeSpace...FAILURE Reason: vCenter datastore: [DATASTORE_NAME] insufficient FreeSpace, requires at least [NUMBER] GB データストアの空き容量の検証は、既存のクラスタ ノードプールに使用しないでください。この検証は gkectl diagnose cluster に誤って追加されたものです。 回避策: このエラー メッセージは無視して構いません。--skip-validation-infra を使用して検証をスキップできます。
運用、ネットワーキング	1.11、1.12.0～1.12.1	管理クラスタが MetalLB ロードバランサを使用していると、新しいユーザー クラスタを追加できない 管理クラスタが 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 を使用し、Google Distributed Cloud バージョン 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 Namespace で monitoring-operator の Deployment をスケールダウンします。 kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --namespace kube-system scale deploy monitoring-operator \ --replicas=0 管理クラスタの kube-system Namespace で 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 管理コントロール プレーン VM の名前の末尾の文字が t、m、p、l である場合、gkectl repair admin-master は、管理コントロール プレーン 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 など）は、ディスクの使用量に影響します。 Google Distributed Cloud v1.8 以降では、Ubuntu イメージが CIS レベル 2 のベンチマークで強化されています。コンプライアンス ルールの一つである「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 前述の設定では、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 これは、Google Distributed Cloud が起動スクリプトでノード 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 ルックアップに失敗する Google Distributed Cloud バージョン 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 を使用する Google Distributed Cloud は、--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 へのアップグレードがブロックされる Google Distributed Cloud バージョン 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 の更新に準拠するために行われました。 影響を受けるカスタム リソースを適用または編集する追加のロジックがない場合、対応は必要ありません。Google Distributed Cloud のアップグレード プロセスでは、影響を受けるリソースの移行が行われ、グループ名の変更後も既存の仕様が保持されます。 ただし、影響を受けるリソースを適用または編集するロジックを実行する場合は、特別な注意が必要です。まず、マニフェスト ファイルで新しいグループ名を使用して参照する必要があります。例: 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 を実行して、Seesaw フェイルオーバーをトリガーします。これによってトラフィックが復元されます。
オペレーティング システム	1.16、1.28.0～1.28.200	Kubelet で、ワーカーノードに /etc/kubernetes/manifests が存在しないことを示すログが大量に表示される ワーカーノードに staticPodPath が誤って設定されています。 回避策: /etc/kubernetes/manifests フォルダを手動で作成します

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