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

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

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

Google Distributed Cloud のバージョン:

問題のカテゴリ:

問題を具体的に指定:

カテゴリ 該当するバージョン 問題と回避策
移行 1.29、1.30

シークレット暗号化が有効になっている場合、ユーザー クラスタの Controlplane V2 への移行が失敗する

ユーザー クラスタを Controlplane V2 に移行するときに、常時有効なシークレット暗号化が有効になっている場合、移行プロセスでシークレット暗号鍵が正しく処理されません。この問題により、新しい Controlplane V2 クラスタは Secret を復号できません。次のコマンドの出力が空でない場合、常時有効なシークレット暗号化が有効になっているため、クラスタはこの問題の影響を受けています。

    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
      get onpremusercluster USER_CLUSTER_NAME \
      -n USER_CLUSTER_NAME-gke-onprem-mgmt \
      -o jsonpath={.spec.secretsEncryption}

移行をすでに開始していて、移行に失敗した場合は、Google にサポートを依頼してください。それ以外の場合は、移行前に常時有効なシークレット暗号化を無効にして Secret を復号します。
移行 1.29.0～1.29.600、1.30.0～1.30.100

シークレット暗号化が有効になっている場合、非 HA から HA への管理クラスタの移行が失敗する

管理クラスタで 1.14 以前に常時有効なシークレット暗号化が有効になっており、古いバージョンから影響を受ける 1.29 バージョンと 1.30 バージョンにアップグレードした場合、管理クラスタを非 HA から HA に移行すると、移行プロセスでシークレット暗号鍵が適切に処理されません。この問題により、新しい HA 管理クラスタは Secret を復号できません。

クラスタが古い形式のキーを使用しているかどうかを確認するには:

    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secret -n kube-system admin-master-component-options -o jsonpath='{.data.data}' | base64 -d | grep -oP '"GeneratedKeys":\[.*?\]'

出力に次のような空のキーが表示される場合、クラスタはこの問題の影響を受ける可能性があります。

    "GeneratedKeys":[{"KeyVersion":"1","Key":""}]

移行をすでに開始していて、移行に失敗した場合は、Google にサポートを依頼してください。

それ以外の場合は、移行を開始する前に暗号鍵をローテーションします。
アップグレード 1.16、1.28、1.29、1.30

管理ワークステーションのアップグレード中に credential.yaml が誤って再生成される

gkeadm upgrade admin-workstation コマンドを使用して管理ワークステーションをアップグレードすると、credential.yaml ファイルが正しく再生成されません。ユーザー名とパスワードのフィールドが空白になります。また、privateRegistry キーにスペルミスがあります。

privateRegistry キーの同じスペルミスが admin-cluster.yaml ファイルにも存在します。
credential.yaml ファイルは管理クラスタのアップグレード プロセス中に再生成されるため、修正したとしてもスペルミスが残ります。

回避策:

  • credential.yaml の非公開レジストリキー名を更新して、admin-cluster.yaml の privateRegistry.credentials.fileRef.entry と一致させます。
  • credential.yaml で非公開レジストリのユーザー名とパスワードを更新します。
アップグレード 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.0～1.28.800、1.29.0-1～1.29.400、1.30.0

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

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 Webhook と gke-connect Pod のインストール順序が正しくないため、ノードが準備完了状態にならず、ユーザー クラスタの作成が停止することがあります。影響を受けるシナリオでは、ノードが準備完了状態にならないことが原因で、ユーザー クラスタの作成が停止することがあります。この場合、次のメッセージが表示されます。

     Node pool is not ready: ready condition is not true: CreateOrUpdateNodePool: 2/3 replicas are ready

回避策:

  1. 構成ファイルから Binary Authorization 構成を削除します。設定手順については、GKE on VMware での Binary Authorization の Day 2 インストール ガイドをご覧ください。
  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 が含まれていると、アップグレード オペレーションが停止することがあります。アップグレードが停止した場合、次のエラー メッセージが表示されます。

    machine is still in the process of being drained and subsequently removed

この問題は、以前にユーザー クラスタ内にミラーリングされたマシンに gkectl delete machine を実行して、ユーザー コントロール プレーン ノードの修復を試みた場合に発生することがあります。

回避策:

  1. ミラーリングされたマシン オブジェクトを取得し、バックアップのためにローカル ファイルに保存します。
  2. 次のコマンドを実行して、ミラーリングされたマシンからファイナライザを削除し、ユーザー クラスタから削除されるまで待ちます。
        kubectl --kubeconfig ADMIN_KUBECONFIG patch machine/MACHINE_OBJECT_NAME -n USER_CLUSTER_NAME-gke-onprem-mgmt -p '{"metadata":{"finalizers":[]}}' --type=merge
  3. Controlplane V2 ユーザー クラスタのコントロール プレーン ノードの手順に沿って、コントロール プレーン ノードでノードの修復をトリガーし、正しいソースマシン仕様がユーザー クラスタに再同期されるようにします。
  4. gkectl upgrade cluster を再実行して、アップグレードを再開します。
構成、インストール 1.15、1.16、1.28、1.29

HA 管理クラスタまたは ControlPlane V2 ユーザー クラスタの場合、コントロール プレーン VIP は他のクラスタノードと同じサブネットに存在する必要があります。そうでないと、kubelet はコントロール プレーン VIP を使用して API サーバーと通信できないため、クラスタの作成に失敗します。

回避策:

クラスタを作成する前に、コントロール プレーン VIP が他のクラスタノードと同じサブネットに構成されていることを確認します。
インストール、アップグレード、更新 1.29.0～1.29.100

クラスタの作成 / アップグレードが失敗し、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 ではなく、username1@example.com を使用します。
アップグレード、更新 1.28.0～1.28.500

管理クラスタを 1.16 から 1.28 にアップグレードすると、新しい管理マスターマシンのブートストラップ中にコントロール プレーン証明書を生成できない場合があります。この問題は、バージョン 1.28 以降の Kubernetes API サーバーで証明書の生成方法が変更されたことが原因で発生します。この問題は、バージョン 1.10 以前で作成されたクラスタを、リーフ証明書をローテーションしないまま 1.16 までアップグレードすると発生します。

管理クラスタのアップグレード失敗の原因が、この問題であるかどうかを判断するには、次の操作を行います。

  1. SSH を使用して、アップグレードに失敗した管理マスターマシンに接続します。
  2. /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>

回避策:

  1. SSH を使用して、管理マスターマシンに接続します。詳細については、SSH を使用した管理クラスタノードへの接続をご覧ください。
  2. /etc/startup/pki-yaml.sh のコピーを作成して /etc/startup/pki-yaml-copy.sh という名前を付ける
  3. /etc/startup/pki-yaml-copy.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
  4. 変更を /etc/startup/pki-yaml-copy.sh に保存します。
  5. テキスト エディタを使用して /opt/bin/master.sh を開き、/etc/startup/pki-yaml.sh が含まれるすべての箇所を /etc/startup/pki-yaml-copy.sh に置き換えて保存します。
  6. /opt/bin/master.sh を実行して証明書を生成し、マシンの起動を完了します。
  7. gkectl upgrade admin を再度実行して、管理クラスタをアップグレードします。
  8. アップグレードが完了したら、ローテーションを開始するの説明に従って、管理クラスタとユーザー クラスタの両方のリーフ証明書をローテーションします。
  9. 証明書のローテーションが完了したら、前と同じ手順で /etc/startup/pki-yaml-copy.sh を編集し、/opt/bin/master.sh を実行します。
構成 1.29.0

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 管理クラスタを作成する際のプリフライト チェックで、次のような誤ったエラー メッセージが表示されます。

- 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 が 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

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

これらの CNI プラグインを使用すると、複数のネットワーク インターフェースは機能しません。

回避策:

この機能を使用している場合は、修正が適用されたバージョンにアップグレードしてください。
更新 1.15、1.16、1.28

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

回避策:

  • multipathd を無効にします。
更新 1.15、1.16

検証がスキップされて管理クラスタに必要な構成が空になっているときに、これらの構成を追加すると、管理クラスタの 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

手動ロードバランサを使用する場合（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 がないため、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

最近追加された 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 認証情報を使用していると（たとえば、管理クラスタの 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 Name: cluster:gke-admin-test1: Etcd cluster kube-system/kube-etcd: 100% of requests for Watch failed on etcd instance etcd-test-xx-n001.

次の手順で、このアラートが無視できる誤検出かどうか確認します。

  1. 元の 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
  2. コードが次のいずれかでない場合、OK 以外のすべてのコードのアラートは無視しても問題ありません。
    Unknown|FailedPrecondition|ResourceExhausted|Internal|Unavailable|DataLoss|DeadlineExceeded

回避策:

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

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

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

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

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


回避策:

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

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

回避策:

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

既存のクラスタで、バンドルされた 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）証明書をローテーションすると、それ以降の 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

プリフライト チェック中に、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 ドライバを使用した動的ボリューム プロビジョニングが機能することを手動で確認します。

  1. standard-rwo StorageClass を使用する PVC を作成します。
  2. PVC を使用する Pod を作成します。
  3. Pod がボリュームに対してデータの読み取り / 書き込みが可能であることを確認します。
  4. 適切な動作を確認したら、Pod と PVC を削除します。

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

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

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

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

回避策:

  1. 次のコマンドを実行して validation-controller を再デプロイします。
          gkectl prepare --kubeconfig ADMIN_KUBECONFIG --bundle-path BUNDLE_PATH --upgrade-platform
  2. 準備が完了したら、gkectl update cluster を再度実行してユーザー クラスタを更新します。
運用 1.16.0～1.16.2

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

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

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

回避策:

  1. 次のコマンドを実行して validation-controller をデプロイします。
          gkectl prepare --kubeconfig ADMIN_KUBECONFIG --bundle-path BUNDLE_PATH --upgrade-platform
  2. 準備が完了したら、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 オブジェクトに追加します。

  1. onpremadminclusters クラスタ リソースを編集します。
    kubectl edit onpremadminclusters ADMIN_CLUSTER_NAME -n kube-system –kubeconfig ADMIN_CLUSTER_KUBECONFIG
     次のように置き換えます。
    • ADMIN_CLUSTER_NAME: 管理クラスタの名前。
    • ADMIN_CLUSTER_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス
  2. onprem.cluster.gke.io/skip-project-location-sameness-validation: true アノテーションを追加して、カスタム リソースを保存します。
  3. 管理クラスタの種類に応じて、次のいずれかの操作を行います。
    • チェックポイント ファイルがある非 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 オブジェクト（作成、更新、アップグレード中に作成されたもの）の削除は、削除の段階で停止します。これは、ファイナライザがオブジェクトの削除をブロックし、クラスタの削除が失敗するためです。

回避策:

  1. すべての Validation オブジェクトの名前を取得します。
             kubectl  --kubeconfig ADMIN_KUBECONFIG get validations \
           -n USER_CLUSTER_NAME-gke-onprem-mgmt
  2. 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

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

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


回避策:

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

  1. cilium-config ConfigMap を編集します。
    kubectl edit cm -n kube-system cilium-config --kubeconfig USER_CLUSTER_KUBECONFIG
  2. cilium-config ConfigMap に次のように追加します。
    tunnel-port: 4789
  3. 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

回避策

管理クラスタのバックアップがある場合は、次の手順でアップグレード エラーを回避してください。

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

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

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

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

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

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


回避策:

VMware の KB 記事は最新でないため、現在実施できる解決策はありません。この問題を解決するには、ホスト上の ESXi を最新バージョンに更新し、ストレージ アレイ上の Nutanix を最新バージョンに更新します。
オペレーティング システム 1.13.10、1.14.6、1.15.3

一部の 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

管理クラスタの認証局（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 クラスタが削除されると、タイムアウトするまで、ノードの削除で処理が停止します。

回避策:

クラスタに重要なデータを含む 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+

クラスタに 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

クラスタに 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 のユーザー マスター マシンの再作成がトリガーされます。

回避策は、この問題が発生した状況によって異なります。

Google Cloud コンソールでユーザー クラスタをアップグレードする場合の回避策:

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

オプション 2: 次の操作を行います。

  1. 次のコマンドを実行して、再実行のアノテーションを手動で追加します。
    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
  2. OnPremUserCluster の status フィールドで、アップグレードの進行状況をモニタリングします。

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

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

オプション 2: 次の操作を行います。

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

クラスタの作成時に、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 ユーザー クラスタの場合、管理クラスタをアップグレードまたは更新すると、ユーザー クラスタ マスター マシンの再起動と同時に管理クラスタ マスター マシンの再作成が行われることがあります。これにより、競合状態が発生する可能性があります。この状況が発生すると、ユーザー クラスタ コントロール プレーン 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"

回避策:

  1. ユーザー コントロール プレーン ノードに SSH で接続します。これはコントロール プレーン v1 ユーザー クラスタであるため、ユーザー コントロール プレーン ノードは管理クラスタにあります。
  2. 次のコマンドを使用して 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.

回避策:

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

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

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

クラスタタイプに応じて回避策を行います。

  • ユーザー クラスタ:
    1. user-ip-block.yaml で、影響を受けるマシンのホスト名を一意の名前に変更し、強制更新をトリガーします。
                gkectl update cluster --kubeconfig ADMIN_KUBECONFIG --config NEW_USER_CLUSTER_CONFIG --force
    2. gkectl upgrade cluster を再実行します。
  • 管理クラスタ:
    1. admin-ip-block.yaml で、影響を受けるマシンのホスト名を一意の名前に変更し、強制更新をトリガーします。
                gkectl update admin --kubeconfig ADMIN_KUBECONFIG --config NEW_ADMIN_CLUSTER_CONFIG --force --skip-cluster-ready-check
    2. 非 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}'
    3. チェックポイントを無効にして管理クラスタのアップグレードを再実行します。
                gkectl upgrade admin --kubeconfig ADMIN_KUBECONFIG --config ADMIN_CLUSTER_CONFIG --disable-upgrade-from-checkpoint

インストールの回避策:

クラスタタイプに応じて回避策を行います。
運用 1.16.0、1.16.1、1.16.2、1.16.3

vSphere のユーザー名またはパスワードに $ または ` が含まれていると、次の処理を行うことができません。

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

修正が適用された 1.16.4 以降のバージョンの Google Distributed Cloud を使用するか、以下の回避策を実施してください。失敗したオペレーションによって回避策が異なります。

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

  1. vCenter 側で vCenter のユーザー名またはパスワードを変更して、$ と ` を削除します。
  2. 認証情報構成ファイルで vCenter のユーザー名またはパスワードを更新します。
  3. クラスタの強制更新をトリガーします。
    • ユーザー クラスタ:
              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

インストールの回避策:

  1. vCenter 側で vCenter のユーザー名またはパスワードを変更して、$ と ` を削除します。
  2. 認証情報構成ファイルで vCenter のユーザー名またはパスワードを更新します。
  3. クラスタタイプに応じて回避策を行います。
ストレージ 1.11+、1.12+、1.13+、1.14+、1.15+、1.16

ノードを削除してから同じノード名で再作成した後に、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

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 テンプレートを確認するには:

  1. vSphere クライアントの [Hosts and Clusters] ページに移動します。
  2. [VM Templates] をクリックして、管理クラスタ名でフィルタします。

    管理クラスタの 3 つの VM テンプレートが表示されます。

  3. 修復するマシンの名前と一致する 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 を使用しているときに、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

チェックポイントを有効にして非 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 に登録されていると、フリート メンバーシップを更新できず、影響を受けるバージョンに管理クラスタをアップグレードできないことがあります。この状況でクラスタをアップグレードしようとすると、次のエラーが表示されます。

    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

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

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


回避策:

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

  1. 既存のテンプレートを編集します。
    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

特定の競合状態のため、チェックポイントと実際の 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

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 を使用して、空でない 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+

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 ワークロードを実行できません。

  1. user-cluster.yaml ファイルから Windows ノードプール構成を削除して、既存の Windows ノードプールを削除してから、次のコマンドを実行します。
    gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
  2. 対応するターゲット マイナー バージョンのアップグレード ユーザーガイドに従って、Linux 専用の管理クラスタとユーザー クラスタを 1.12 にアップグレードします。
  3. （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
  4. アップグレード ユーザーガイドに従って、Linux 専用の管理クラスタとユーザー クラスタを 1.13 にアップグレードします。
  5. 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
  6. OSImage フィールドを新しく作成した Windows VM テンプレートに設定し、Windows ノードプール構成を user-cluster.yaml に再度追加します。
  7. クラスタを更新して 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

ノードでは、予想される構成（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

バージョン 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 が有効な場合（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 署名鍵をローテーションした後に、ユーザー クラスタを更新すると、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 に戻します。ただし、最新の鍵データを保持します。
  1. USER_CLUSTER_NAME Namespace の管理クラスタで Secret を確認し、ksa-signing-key Secret の名前を取得します。
    kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME get secrets | grep ksa-signing-key
  2. 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 -
  3. 以前の ksa-signing-key の Secret を削除します。
    kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME delete secret KSA-KEY-SECRET-NAME
  4. 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
  5. 検証 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
'
  6. OnPremUserCluster カスタム リソースの spec.ksaSigningKeyRotation.generated.ksaSigningKeyRotation フィールドを 1 に更新します。
    kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME-gke-onprem-mgmt \
edit onpremusercluster USER_CLUSTER_NAME
  7. ターゲット ユーザー クラスタの準備ができる待機します。ステータスは次の方法で確認できます。
    kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME-gke-onprem-mgmt \
get onpremusercluster
  8. ユーザー クラスタの検証 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
'
  9. 修正が適用されたバージョンにクラスタがアップグレードされるまで、別の KSA 署名鍵のローテーションを使用しないでください。
運用 1.13.1+、1.14, 1、1.16

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


回避策:

F5 リソースを削除するには、ユーザー クラスタの F5 パーティションをクリーンアップするの手順に沿って操作します。
インストール、アップグレード、更新 1.13.8、1.14.4

バージョン 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

    クラスタ 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

    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 以降のバージョンで作成されたクラスタの場合は、クラスタの作成後に管理クラスタの登録の再試行の手順に沿って操作してください。以前のバージョンで作成されたクラスタで、次の操作を行います。

    1. foo: bar のような架空の Key-Value ペアを connect-register SA キーファイルに追加します。
    2. gkectl update admin を実行して、管理クラスタを再登録します。
    アップグレード、更新 1.10、1.11、1.12、1.13.0～1.13.1

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


    回避策:

    クラスタが登録済みクラスタに含まれているかどうか確認します。また、認証の設定後にクラスタにログインして確認することもできます。クラスタがまだ登録されている場合は、以下の手順をスキップして、登録を再試行できます。1.12 以降のバージョンにアップグレードされたクラスタの場合は、クラスタの作成後に管理クラスタ登録の再試行の手順に沿って操作してください。以前のバージョンにアップグレードされたクラスタの場合は、次の操作を行います。
    1. foo: bar のような架空の Key-Value ペアを connect-register SA キーファイルに追加します。
    2. gkectl update admin を実行して、管理クラスタを再登録します。
    構成 1.15.0

    高可用性管理クラスタで、gkectl prepare が次のような誤ったエラー メッセージを表示します。

    vCenter.dataDisk must be present in the AdminCluster spec

    回避策:

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

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


    回避策:

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

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

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


    回避策:

    このコマンドはべき等です。コマンドが成功するまで安全に再実行できます。
    アップグレード、更新 1.15.0

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


    回避策:

    失敗した Pod を無視するか、手動で削除します。
    セキュリティ、構成 1.15.0～1.15.1

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

    failed to check secret reference for private registry …


    回避策:

    準備済みの認証情報を構成するの手順に沿って、ユーザー クラスタの非公開レジストリの認証情報を準備します。
    アップグレード、更新 1.15.0

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


    回避策:

    1. ボリュームに書き込めない Pod の UID を取得します。
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pod \
    POD_NAME --namespace POD_NAMESPACE \
    -o=jsonpath='{.metadata.uid}{"\n"}'
    2. PersistentVolumeClaim を使用して PersistentVolume の名前を取得します。
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pvc \
    PVC_NAME --namespace POD_NAMESPACE \
    -o jsonpath='{.spec.volumeName}{"\n"}'
    3. Pod が実行されているノードの名前を確認します。
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIGget pods \
    --namespace POD_NAMESPACE \
    -o jsonpath='{.spec.nodeName}{"\n"}'
    4. SSH または vSphere ウェブ インターフェースを使用して、ノードへの PowerShell アクセスを取得します。
    5. 環境変数を設定します。
      PS C:\Users\administrator> pvname=PV_NAME
PS C:\Users\administrator> podid=POD_UID
    6. 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
    7. ディスクが readonly であることを確認します。
      PS C:\Users\administrator> (Get-Disk -Number $disknum).IsReadonly
       結果は True のようになります。
    8. readonly を false に設定します。
      PS C:\Users\administrator> Set-Disk -Number $disknum -IsReadonly $false
PS C:\Users\administrator> (Get-Disk -Number $disknum).IsReadonly
    9. Pod を削除して再起動できるようにします。
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete pod POD_NAME \
    --namespace POD_NAMESPACE
    10. 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 が引き続き古い認証情報を使用することがあります。


    回避策:

    1. vsphere-csi-secret Secret 名を取得します。
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system get secrets | grep vsphere-csi-secret
    2. 上記の手順で取得した 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 \
    )\"}}"
    3. vsphere-csi-controller を再起動します。
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system rollout restart deployment vsphere-csi-controller
    4. ロールアウトのステータスは次の方法で追跡できます。
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system rollout status deployment vsphere-csi-controller
       Deployment が正常にロールアウトされたら、更新された vsphere-csi-secret をコントローラで使用する必要があります。
    アップグレード、更新 1.10、1.11、1.12.0～1.12.6、1.13.0～1.13.6、1.14.0～1.14.2

    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 の直後に、コントロール プレーン 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

    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

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

    • 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 を手動で再デプロイします。

    1. gke-connect Namespace を削除します。
      kubectl --kubeconfig=KUBECONFIG delete namespace gke-connect
    2. 元の登録サービス アカウント キーを使用して 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 を以下の方法で追加できます。

    1. デフォルトの 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 -
    2. gke-connect-agent Deployment 名を取得します。
      kubectl --kubeconfig=KUBECONFIG -n=gke-connect get deployment | grep gke-connect-agent
    3. デフォルトの 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

    手動ロードバランサを使用してクラスタを作成する前に、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 バージョン 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 で表示するには:

    1. Google Cloud コンソールの Metrics Explorer に移動します。

      Metrics Explorer に移動

    2. [構成] タブを選択します。
    3. [指標の選択] を開き、フィルタバーに「Kubernetes Container」と入力してから、サブメニューを使用して指標を選択します。
      1. [有効なリソース] メニューで [Kubernetes コンテナ] を選択します。
      2. [有効な指標カテゴリ] メニューで [Anthos] を選択します。
      3. [アクティブな指標] メニューで [etcd_network_client_grpc_sent_bytes_total] を選択します。
      4. [適用] をクリックします。
    アップグレード、更新 1.10、1.11、1.12、1.13、1.14

    クラスタの再起動またはアップグレード後に、認証 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+

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

    1. 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 サーバーが起動していません。その場合は、次の操作を行います。

    2. GKE Identity Service と kube-apiserver のログを確認します。
      1. 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:
      2. クラスタの 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 を特定して再起動します。

    1. 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
    2. GKE Identity Service のログで、無効なトークン コンテキストを確認します。
      kubectl logs -f -l k8s-app=ais -n anthos-identity-service \
    --kubeconfig KUBECONFIG
    3. 無効なトークン コンテキストに関連付けられたトークン ペイロードを確認します。次のコマンドを使用して、関連するサービス アカウントの Secret を解析します。
      kubectl -n kube-system get secret SA_SECRET \
    --kubeconfig KUBECONFIG \
    -o jsonpath='{.data.token}' | base64 --decode
    4. トークンをデコードしてソース Pod の名前と Namespace を確認します。jwt.io のデバッガにトークンをコピーします。
    5. トークンから特定された Pod を再起動します。
    運用 1.8、1.9、1.10

    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

    クラスタのヘルス コントローラと 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

    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

    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 または新しいインストール モデルを使用すると、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+

    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

    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 ドライバを使用している場合、クラスタをアップグレードできないことがあります。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 ハードウェア バージョンを使用することがあります。問題が発生すると、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+

    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.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 または新しいインストール モデルで作成されたユーザー クラスタでは、自動スケーリングが有効なノードプールは常に、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 を使用すると、構成の検証が失敗し、次のエラーが表示されます。

    - 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 イメージタイプを更新するときに、対応するユーザー クラスタが 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

    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

    ユーザーが適切な構成を行っているにもかかわらず、クラスタの作成に失敗します。クラスタに十分な 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

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

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

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

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


    回避策:
    アップグレード、更新 1.10.0

    ユーザー クラスタを 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 などのコマンドを実行する必要があります。


    回避策:
    アップグレード、更新 1.11、1.12

    バージョン 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 によってリソースが削除されます。


    回避策:
    運用 1.11、1.12、1.13.0～1.13.1

    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 でバージョン 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 で対応する 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

    回避策:

    構成 1.7、1.8、1.9、1.10、1.11、1.12、1.13

    ユーザー クラスタの削除時に、対応する 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"

    回避策:

    構成 1.12.1～1.12.3、1.13.0～1.13.2

    これは、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

    これは、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

    回避策:
    インストール、アップグレード、更新 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 の検証を無効にします。

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

    管理クラスタ

    1. OnPremAdminCluster カスタム リソースを開いて編集します。
      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    edit onpremadmincluster -n kube-system
    2. カスタム リソースに次のアノテーションを追加します。
      features.onprem.cluster.gke.io/disable-node-id-verification: enabled
    3. 管理クラスタ コントロール プレーンで kube-controller-manager マニフェストを編集します。
      1. 管理クラスタのコントロール プレーン ノードに SSH で接続します。
      2. kube-controller-manager マニフェストを開いて編集します。
        sudo vi /etc/kubernetes/manifests/kube-controller-manager.yaml
      3. controllers のリストを見つけます。
        --controllers=*,bootstrapsigner,tokencleaner,-csrapproving,-csrsigning
      4. このセクションを以下のように更新します。
        --controllers=*,bootstrapsigner,tokencleaner
    4. Deployment Cluster API コントローラを開いて編集します。
      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    edit deployment clusterapi-controllers -n kube-system
    5. 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

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

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

    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

    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 を実行しないでください。これを行うと、以降の管理アップグレードが失敗し、管理マスターのパワーオン障害や VM にアクセスできないなどの問題が発生する可能性があります。


    回避策:

    この状況がすでに発生している場合は、サポートにお問い合わせください。
    アップグレード、更新 1.10、1.11

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


    回避策:

    管理コントロール プレーンの VM テンプレートは、次の管理クラスタのアップグレード中に再生成されます。
    オペレーティング システム 1.12、1.13

    バージョン 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

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


    回避策:

    毎回手動で変更した後に ClientConfig リソースをバックアップすることを強くおすすめします。
    インストール 1.10、1.11、1.12、1.13

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

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


    回避策:

    もう一度 gkectl check-config を実行してみてください。
    インストール 1.12

    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"

    回避策:
    VMware 1.10、1.11、1.12、1.13

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

    関連する govmomi のバグ。


    回避策:

    この回避策は VMware のサポートによって提供されます。

    1. この問題は、vCenter バージョン 7.0U2 以降で修正されています。
    2. それより前のバージョンの場合は、ホストを右クリックして、[Connection] > [Disconnect] の順に選択します。次に、再接続します。これにより、VM のポートグループが強制的に更新されます。
    オペレーティング システム 1.10、1.11、1.12、1.13

    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

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

    この作業はクラスタごとに 1 回だけ行う必要があります。変更はクラスタのアップグレード後も保持されます。

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

    回避策:

    アップグレード中の競合を回避します。

    1. 使用しているバージョンの cert-manager をアンインストールします。独自のリソースを定義している場合は、リソースをバックアップすることをおすすめします。
    2. アップグレードを実行します。
    3. 独自の 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

    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 の修正については、リリースノートをご覧ください。


    回避策:

    Canonical はこの問題を認識しており、修正は https://github.com/canonical/sec-cvescan/issues/73 で追跡されています。
    アップグレード、更新 1.10、1.11、1.12、1.13

    非 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 チェックに失敗した場合、通常、Google Distributed Cloud（kubectl exec、kubectl log、Webhook）の機能に影響はありません。この状況は、不安定なネットワーキングなどの問題が原因で、konnectivity の 1、2 個のレプリカが一定期間読み取り不能になっていると発生します。


    回避策:

    konnectivity は自己回復します。30 分から 1 時間待ってから、クラスタの診断を再度実行してください。
    オペレーティング システム 1.7、1.8、1.9、1.10、1.11

    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 ステートフル分散ファイアウォール ルールを使用する環境に、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 行を削除してから保存し、エディタを終了します。

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

    1. 不要な請求の指標が含まれるソースの 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"'
    2. Pod または Service から prometheus.io/scrap=true アノテーションを削除します。アノテーションが Cloud Service Mesh によって追加される場合は、Prometheus オプションなしで Cloud Service Mesh を構成するか、Istio 指標マージ機能をオフにすることを検討してください。
    インストール 1.11、1.12、1.13

    カスタムロールが誤った権限レベルでバインドされていると、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 へのネットワーク トラフィック量が多い場合があります。

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


    回避策:
    ロギングとモニタリング 1.10、1.11

    Google Distributed Cloud バージョン 1.10 以降の場合、stackdriver オブジェクトで enableStackdriverForApplications が true に設定されていると、gke-metrics-agent DaemonSet で CrashLoopBackOff エラーが頻繁に発生します。


    回避策:

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

    1. 次の変更を元に戻さないようにするには、stackdriver-operator をスケールダウンします。
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system scale deploy stackdriver-operator \
    --replicas=0
       USER_CLUSTER_KUBECONFIG は、ユーザー クラスタの kubeconfig ファイルのパスに置き換えます。
    2. gke-metrics-agent-conf ConfigMap を開いて編集します。
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system edit configmap gke-metrics-agent-conf
    3. 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
    4. 編集セッションを閉じます。
    5. 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

    回避策:

    非推奨の指標を置き換えるには

    1. Google Cloud Monitoring ダッシュボードで「GKE on-prem node status」を削除します。こちらの手順で「GKE on-prem node status」を再インストールします。
    2. Google Cloud Monitoring ダッシュボードで「GKE on-prem node utilization」を削除します。こちらの手順で「GKE on-prem node utilization」を再インストールします。
    3. Google Cloud Monitoring ダッシュボードで「GKE on-prem vSphere vm health」を削除します。こちらの手順で「GKE On-Prem vSphere vm health」を再インストールします。

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

    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 を増やします。

    1. stackdriver リソースを開いて編集します。
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system edit stackdriver stackdriver
    2. 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
    3. 変更を保存し、テキスト エディタを終了します。
    4. 変更が有効になっていることを確認するには、次のコマンドを実行します。
      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 の指標が欠落しています。たとえば、次の 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 の指標が欠落しています。たとえば、次の 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: ""

    回避策:
    ID 1.10、1.11、1.12、1.13

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


    回避策:

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

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

    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

    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

    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)

    回避策:
    アップグレード、更新 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

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

    Google Distributed Cloud バージョン 1.10、1.11、1.12 の場合、ディスクでバッファリングされたログが破損していると、stackdriver-log-forwarder DaemonSet で CrashLoopBackOff エラーが発生することがあります。


    回避策:

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

    1. 予期しない動作を防ぐには、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 ファイルのパスに置き換えます。
    2. クリーンアップした 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
    3. クリーンアップの 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
    4. クリーンアップの DaemonSet を削除します。
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system delete ds fluent-bit-cleanup
    5. 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

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

    2023-06-02T10:53:40.444017427Z [2023/06/02 10:53:40] [error] [input chunk] chunk 1-1685703077.747168499.flb would exceed total limit size in plugin stackdriver.0
2023-06-02T10:53:40.444028047Z [2023/06/02 10:53:40] [error] [input chunk] no available chunk
    ログ入力レートがロギング エージェントの上限を超えている可能性があります。これにより、stackdriver-log-forwarder がログを送信しなくなります。この問題は、すべての Google Distributed Cloud バージョンで発生します。

    回避策:

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

    1. stackdriver リソースを開いて編集します。
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system edit stackdriver stackdriver
    2. 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
    3. 変更を保存し、テキスト エディタを終了します。
    4. 変更が有効になっていることを確認するには、次のコマンドを実行します。
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system get daemonset stackdriver-log-forwarder -o yaml \
    | grep "cpu: 1200m"
       変更が有効になっている場合は、このコマンドで cpu: 1200m が検出されます。
    セキュリティ 1.13

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

    この問題は kubelet サーバー証明書にのみ影響します。Pod のスケジューリングには影響しません。
    アップグレード、更新 1.12

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

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

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


    回避策:

    管理クラスタを 1.11 にアップグレードしてから、ユーザー クラスタを 1.12 にアップグレードします。
    ストレージ 1.10.0～1.10.5、1.11.0～1.11.2、1.12.0

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

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

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


    回避策:

    このエラー メッセージは無視して構いません。--skip-validation-infra を使用して検証をスキップできます。
    運用、ネットワーキング 1.11、1.12.0～1.12.1

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

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


    回避策:

    ユーザー クラスタを強制的に削除できます。
    インストール、オペレーティング システム 1.10、1.11、1.12、1.13

    管理クラスタで 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 を使用し、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:\""

    回避策:
    その他 1.11.3

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

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

    回避策:
    運用、セキュリティ 1.11

    ワークステーションがユーザー クラスタのワーカーノードにアクセスできない場合、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/ が監査ログでいっぱいになります。ディスクの使用量を確認するには、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 が保証されます。これにより、すべての監査ルールがディスクに保持されます。


    回避策:
    ネットワーキング 1.10、1.11.0～1.11.3、1.12.0～1.12.2、1.13.0

    次の検証 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 を一時的に無効にして変更内容を送信します。

    1. 最後に復元できるように Webhook 構成を保存します。
      kubectl -n kube-system get validatingwebhookconfiguration \
    ang-validating-webhook-configuration -o yaml > webhook-config.yaml
    2. Webhook 構成を編集します。
      kubectl -n kube-system edit validatingwebhookconfiguration \
    ang-validating-webhook-configuration
    3. Webhook 構成リストから vnetworkgatewaygroup.kb.io 項目を削除して終了し、変更を適用します。
    4. NetworkGatewayGroup オブジェクトを作成または編集します。
    5. 元の 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 イメージを使用している場合、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

    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

    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

    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 を手動で編集して、次の操作を行います。

    1. リソース リクエストと上限を文字列型に変更します。
    2. addons.gke.io/migrated-and-deprecated: true アノテーションが存在する場合は削除します。
    その後、アップグレード プロセスを再開または再起動します。
    オペレーティング システム 1.7 以降

    ESXi サーバーに障害が発生したときに、サーバーで vCenter HA 機能が有効になっていると、障害のある ESXi サーバー内のすべての VM が vMotion をトリガーし、別の正常な ESXi サーバーに移行されます。移行された COS VM の IP は失われます。

    回避策:

    VM を再起動します。
    ネットワーキング 1.14.7 より前のすべてのバージョン、1.15.0～1.15.3、1.16.0

    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

    ワーカーノードに staticPodPath が誤って設定されています。

    回避策:

    /etc/kubernetes/manifests フォルダを手動で作成します
    さらにサポートが必要な場合は、Cloud カスタマーケアにお問い合わせください。