Anthos clusters on VMware は、VMware 用 Google Distributed Cloud（ソフトウェアのみ）になりました。詳細については、プロダクトの概要をご覧ください。

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

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

Google Distributed Cloud のバージョン:

問題のカテゴリ:

問題を具体的に指定:

カテゴリ該当するバージョン問題と回避策

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

1.28.0-1.28.600、1.29.0-1.29.100

Binary Authorization ウェブブックが CNI プラグインをブロックするため、nodepool の 1 つが起動しない

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

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

回避策:

構成ファイルから Binary Authorization 構成を削除します。設定手順については、GKE on VMware での Binary Authorization の Day 2 インストールガイドをご覧ください。

現在のクラスタ作成プロセス中に異常なノードのブロックを解除するには、次のコマンドを使用して、ユーザークラスタ内の Binary Authorization Webhook 構成を一時的に削除します。

        kubectl --kubeconfig USER_KUBECONFIG delete ValidatingWebhookConfiguration binauthz-validating-webhook-configuration

ブートストラッププロセスが完了したら、次の Webhook 構成を再度追加できます。

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: binauthz-validating-webhook-configuration
webhooks:
- name: "binaryauthorization.googleapis.com"
  namespaceSelector:
    matchExpressions:
    - key: control-plane
      operator: DoesNotExist
  objectSelector:
    matchExpressions:
    - key: "image-policy.k8s.io/break-glass"
      operator: NotIn
      values: ["true"]
  rules:
  - apiGroups:
    - ""
    apiVersions:
    - v1
    operations:
    - CREATE
    - UPDATE
    resources:
    - pods
    - pods/ephemeralcontainers
  admissionReviewVersions:
  - "v1beta1"
  clientConfig:
    service:
      name: binauthz
      namespace: binauthz-system
      path: /binauthz
    # CA Bundle will be updated by the cert rotator.
    caBundle: Cg==
  timeoutSeconds: 10
  # Fail Open
  failurePolicy: "Ignore"
  sideEffects: None

アップグレード

1.16、1.28、1.29

`deletionTimestamp` でミラーリングされたマシンが原因で CPV2 ユーザークラスタのアップグレードが停止する

ユーザークラスタのアップグレード中に、ユーザークラスタ内にミラーリングされたマシンオブジェクトに deletionTimestamp が含まれていると、アップグレードオペレーションが停止することがあります。アップグレードが停止した場合、次のエラーメッセージが表示されます。

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

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

回避策:

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

構成、インストール

1.15、1.16、1.28、1.29

異なるサブネットにあるコントロールプレーン VIP が原因でクラスタの作成に失敗する

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

回避策:

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

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

1.29.0～1.29.100

FQDN 以外の vCenter ユーザー名を使用すると、クラスタの作成またはアップグレードに失敗する

クラスタの作成 / アップグレードが失敗し、vCenter ユーザー名が無効であることを示す vsphere CSI Pod のエラーが表示されます。これは、使用されているユーザー名が完全修飾ドメイン名ではないためです。vsphere-csi-controller Pod のエラーメッセージは次のとおりです。

    GetCnsconfig failed with err: username is invalid, make sure it is a fully qualified domain username

この問題は、完全修飾ドメインのユーザー名の使用を強制する検証が vSphere CSI ドライバに追加されたバージョン 1.29 以降でのみ発生します。

回避策:

認証情報構成ファイルの vCenter ユーザー名に完全修飾ドメイン名を使用します。たとえば、username1 ではなく、username1@example.com を使用します。

アップグレード、更新

1.28.0～1.28.500

バージョン 1.10 以前で作成されたクラスタで、管理クラスタのアップグレードに失敗する

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

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

SSH を使用して、アップグレードに失敗した管理マスターマシンに接続します。
/var/log/startup.log を開いて、次のようなエラーを検索します。

Error adding extensions from section apiserver_ext
801B3213B57F0000:error:1100007B:X509 V3 routines:v2i_AUTHORITY_KEYID:unable to get issuer keyid:../crypto/x509/v3_akid.c:177:
801B3213B57F0000:error:11000080:X509 V3 routines:X509V3_EXT_nconf_int:error in extension:../crypto/x509/v3_conf.c:48:section=apiserver_ext, name=authorityKeyIdentifier, value=keyid>

回避策:

SSH を使用して、管理マスターマシンに接続します。詳細については、SSH を使用した管理クラスタノードへの接続をご覧ください。

/etc/startup/pki-yaml.sh を編集します。apiserver_ext、client_ext、etcd_server_ext、kubelet_server_ext の拡張機能のセクションで authorityKeyIdentifier=keyidset を見つけて、authorityKeyIdentifier=keyid,issuer に変更します。例:

      [ apiserver_ext ]
      keyUsage = critical, digitalSignature, keyEncipherment
      extendedKeyUsage=serverAuth
      basicConstraints = critical,CA:false
      authorityKeyIdentifier = keyid,issuer
      subjectAltName = @apiserver_alt_names

変更を /etc/startup/pki-yaml.sh に保存します。
/opt/bin/master.sh を実行して証明書を生成し、マシンの起動を完了します。
gkectl upgrade admin を再度実行して、管理クラスタをアップグレードします。
アップグレードが完了したら、ローテーションを開始するの説明に従って、管理クラスタとユーザークラスタの両方のリーフ証明書をローテーションします。
証明書のローテーションが完了したら、前と同じ手順で /etc/startup/pki-yaml.sh を編集し、/opt/bin/master.sh を実行します。

構成

1.29.0

Dataplane V2 が有効になっているクラスタで、誤った警告メッセージが表示される

gkectl を使用して、すでに Dataplane V2 が有効になっているクラスタの作成、更新、アップグレードを実行すると、次のような誤った警告メッセージが出力されます。

WARNING: Your user cluster is currently running our original architecture with 
[DataPlaneV1(calico)]. To enable new and advanced features we strongly recommend
to update it to the newer architecture with [DataPlaneV2] once our migration 
tool is available.

これは gkectl のバグです。クラスタの構成ファイルで enableDataplaneV2: true が設定されていても、dataplaneV2.forwardMode が使用されていないと、この警告が常に表示されます。

回避策:

この警告は無視してかまいません。

構成

1.28.0-1.28.400、1.29.0

HA 管理クラスタのインストールのプリフライトチェックで、必要な静的 IP の数が正しく報告されない

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

- Validation Category: Network Configuration
    - [FAILURE] CIDR, VIP and static IP (availability and overlapping): needed
    at least X+1 IP addresses for admin cluster with X nodes

1.28 以降の HA 管理クラスタにはアドオンノードがないため、この要件は該当しません。また、3 つの管理クラスタコントロールプレーンノードの IP は、管理クラスタの構成ファイルの network.controlPlaneIPBlock セクションに指定されているため、IP ブロックファイルの IP は kubeception ユーザークラスタコントロールプレーンノードにのみ必要です。

回避策:

修正されていないリリースで適切でないプリフライトチェックをスキップするには、gkectl コマンドに --skip-validation-net-config を追加します。

運用

1.29.0～1.29.100

管理クラスタを非 HA から HA に移行した後、Connect Agent が Google Cloud が接続できなくなる

管理クラスタを非 HA から HA に移行すると、管理クラスタの Connect Agent が gkeconnect.googleapis.com との接続を失い、「Failed to verify JWT signature」というエラーが表示されます。これは、移行中に KSA 署名鍵が変更されるため、OIDC JWK を更新するために再登録が必要になるためです。

回避策:

管理クラスタを Google Cloud に再接続するには、次の手順で再登録をトリガーします。

まず、gke-connect Deployment の名前を取得します。

kubectl --kubeconfig KUBECONFIG get deployment -n gke-connect

gke-connect Deployment を削除します。

kubectl --kubeconfig KUBECONFIG delete deployment GKE_CONNECT_DEPLOYMENT -n gke-connect

onpremadmincluster CR に force-reconcile アノテーションを追加して、onprem-admin-cluster-controller の強制調整をトリガーします。

kubectl --kubeconfig KUBECONFIG patch onpremadmincluster ADMIN_CLUSTER_NAME -n kube-system --type merge -p '
metadata:
  annotations:
    onprem.cluster.gke.io/force-reconcile: "true"
'

使用可能な既存の gke-connect Deployment が見つからない場合は、onprem-admin-cluster-controller が常に gke-connect Deployment を再デプロイし、クラスタを再登録します。

回避策を実施した後、gke-connect-agent ログから「Failed to verify JWT signature」400 エラーが消えているはずです（コントローラが調整を完了するまでに数分かかる場合があります）。

kubectl --kubeconfig KUBECONFIG logs GKE_CONNECT_POD_NAME -n gke-connect

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

1.28.0-1.28.500～1.29.0

Docker ブリッジ IP で COS クラスタのコントロールプレーンノードに 172.17.0.1/16 が使用される

Google Distributed Cloud は、デフォルトの 172.17.0.1/16 サブネットの予約を防ぐため、Docker 構成で Docker ブリッジ IP 専用のサブネット --bip=169.254.123.1/24 を指定します。ただし、バージョン 1.28.0～1.28.500 と 1.29.0 では、COS OS イメージの回帰により、Google Distributed Cloud が Docker の構成をカスタマイズした後、Docker サービスが再起動されません。その結果、Docker はデフォルトの 172.17.0.1/16 をブリッジ IP アドレスサブネットとして選択します。この IP アドレス範囲内にすでに実行中のワークロードがある場合、IP アドレスの競合が発生する可能性があります。

回避策:

この問題を回避するには、docker サービスを再起動する必要があります。

sudo systemctl restart docker

Docker が正しいブリッジ IP アドレスを選択していることを確認します。

ip a | grep docker0

注: VM を再作成すると、この解決策は無効になります。VM が再作成されるたびに、この回避策を実施し直す必要があります。

更新

1.28.0～1.28.400、1.29.0～1.29.100

標準 CNI で複数のネットワークインターフェースが機能しない

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

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

回避策:

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

更新

1.15、1.16、1.28

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

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

回避策:

multipathd を無効にします。

更新

1.15、1.16

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

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

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

回避策:

1.15 管理クラスタの場合は、--disable-admin-cluster-webhook フラグを指定して gkectl update admin コマンドを実行します。例:

        gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig ADMIN_CLUSTER_KUBECONFIG --disable-admin-cluster-webhook

1.16 管理クラスタの場合は、--force フラグを指定して gkectl update admin コマンドを実行します。例:

        gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig ADMIN_CLUSTER_KUBECONFIG --force

構成

1.15.0～1.15.10、1.16.0～1.16.6、1.28.0～1.28.200

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

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

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

回避策:

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

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

ストレージ

1.28.0～1.28.100

Ubuntu OS イメージに nfs-common がない

Ubuntu OS イメージに nfs-common がないため、NetApp などの NFS 依存ドライバを使用している環境で問題が発生する可能性があります。

1.28 にアップグレードした後に、ログに

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

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

回避策:

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

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

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

ストレージ

1.28.0～1.28.100

管理クラスタの構成テンプレートにストレージポリシーフィールドがない

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

回避策:

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

ロギングとモニタリング

1.28.0～1.28.100

Kubernetes Metadata API が VPC-SC に対応していない

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

回避策:

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

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

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

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

アップグレード、更新

1.15.0～1.15.7、1.16.0～1.16.4、1.28.0

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

管理クラスタと Controlplane V2 が有効になっているユーザークラスタが異なる vSphere 認証情報を使用していると（たとえば、管理クラスタの vSphere 認証情報の更新後）、再起動後に clusterapi-controller が vCenter に接続できないことがあります。管理クラスタの kube-system Namespace で実行されている clusterapi-controller のログを確認します。

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

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

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

回避策:

vSphere 認証情報を更新して、管理クラスタと Controlplane V2 が有効になっているすべてのユーザークラスタで同じ vSphere 認証情報が使用されるようにします。

ロギングとモニタリング

1.14

Prometheus Alert Manager に、etcd で失敗した GRPC リクエストが大量に表示される

Prometheus が次のようなアラートを報告することがあります。

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

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

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

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

回避策:

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

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

ネットワーキング

1.16.0～1.16.2、1.28.0

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

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

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

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

回避策:

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

運用

1.14、1.15、1.16

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

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

回避策:

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

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

1.16.0～1.16.3

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

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

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

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

回避策:

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

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

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

アップグレード、更新

1.13、1.14、1.15.0～1.15.6

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

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

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

回避策:

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

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

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

ストレージ

1.15.0～1.15.6、1.16.0～1.16.2

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

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

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

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

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

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

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

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

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

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

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

kubectl label namespace default istio.io/rev-

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

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

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

運用

1.16.0～1.16.2

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

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

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

回避策:

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

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

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

運用

1.16.0～1.16.2

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

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

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

回避策:

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

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

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

アップグレード、更新

1.16.0～1.16.2

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

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

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

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

回避策:

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

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

運用

1.16.0～1.16.2

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

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

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

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

回避策:

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

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

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

ネットワーキング

1.15、1.16

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

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

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

回避策:

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

cilium-config ConfigMap を編集します。

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

cilium-config ConfigMap に次のように追加します。
```
tunnel-port: 4789
```

anetd DaemonSet を再起動します。

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

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

アップグレード

1.15.0～1.15.4

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

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

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

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

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

回避策

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

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

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

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

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

ストレージ

1.11～1.16

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

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

回避策:

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

この変更は、更新またはアップグレードを行うと破棄されるため、ノードで CBT を有効にしないでください。

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

ストレージ

1.14、1.15、1.16

複数のホストから共有ファイルに並列追加が行われると NFSv3 上のデータが破損する

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

回避策:

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

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

1.13.10、1.14.6、1.15.3

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

一部の Google Distributed Cloud リリースでは、ノードで実行される kubelet と Kubernetes コントロールプレーンのバージョンが一致していない場合があります。OS イメージにプリロードされた kubelet バイナリが異なるバージョンを使用しているため、このような不一致が発生します。

次の表に、確認されているバージョンの不一致を示します。

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

回避策:

必要な対応はありません。この不一致は、Kubernetes パッチバージョン間のみであり、このバージョンの違いによる問題はありません。

アップグレード、更新

1.15.0～1.15.4

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

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

    CAVersion must start from 1

回避策:

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

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

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

運用

1.13、1.14.0～1.14.8、1.15.0～1.15.4、1.16.0～1.16.1

タイムアウトするまで非 HA Controlplane V2 クラスタの削除で停止する

非 HA Controlplane V2 クラスタが削除されると、タイムアウトするまで、ノードの削除で処理が停止します。

回避策:

クラスタに重要なデータを含む StatefulSet が含まれている場合は、Cloud カスタマーケアにお問い合わせください。

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

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

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

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

ストレージ

1.15.0+、1.16.0+

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

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

回避策:

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

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

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

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

ストレージ

1.16.0

PVC に関する誤った警告

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

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

回避策:

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

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

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

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

アップグレード、更新

1.15.0+、1.16.0+

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

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

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

回避策:

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

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

アップグレード

1.16.0～1.16.5

ユーザークラスタコントローラが 1.16 にアップグレードされると、1.15 ユーザーマスターマシンが予期せず再作成される

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

作成

1.16.0～1.16.5、1.28.0～1.28.100

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

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

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

プリフライトチェックのバグにより、空のホスト名が重複とみなされます。

回避策:

オプション 1: 修正適用済みのバージョンを使用します。

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

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

アップグレード、更新

1.16

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

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

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

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

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

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

回避策:

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

アップグレード、更新

1.16.0

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

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

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

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

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

このコマンドから次のようなエラーメッセージが返されます。

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

回避策:

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

運用

1.16

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

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

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

管理クラスタ:

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

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

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

ユーザークラスタ（Controlplane V2）:

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

次のようなエラーメッセージが表示されます。

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

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

次の方法でホスト名が重複しているかどうか確認し、必要に応じて回避策を行います。

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

コマンドと出力例:

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

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

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

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

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

管理クラスタ:

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

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

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

          kubectl get machine --kubeconfig ADMIN_KUBECONFIG -owide -A

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

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

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

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

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

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

インストールの回避策:

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

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

運用

1.16.0、1.16.1、1.16.2、1.16.3

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

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

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

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

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

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

ユーザークラスタ:

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

管理クラスタ:

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

インストールの回避策:

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

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

ストレージ

1.11+、1.12+、1.13+、1.14+、1.15+、1.16

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

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

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

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

回避策:

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

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

運用

1.16.0

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

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

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

回避策:

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

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

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

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

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

ネットワーキング

1.10.0+、1.11.0+、1.12.0+、1.13.0+、1.14.0-1.14.7、1.15.0～1.15.3、1.16.0

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

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

    GRUB_FORCE_PARTUUID set, initrdless boot failed. Attempting with initrd

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

回避策:

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

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

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

運用

1.13、1.14.0～1.14.6、1.15

管理クラスタのアップグレードまたは更新後に、管理 SSH 公開鍵エラーが発生する

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

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

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

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

回避策:

修正が適用された Google Distributed Cloud のパッチバージョンにアップグレードできない場合は、Google サポートにお問い合わせください。

アップグレード

1.13.0～1.13.9、1.14.0～1.14.6、1.15.1～1.15.2

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

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

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

管理クラスタが API に登録されるのは、クラスタを明示的に登録した場合だけはありません。GKE On-Prem クライアントを使用してユーザークラスタをアップグレードした場合にも登録されます。

回避策:

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

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

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

アップグレード、更新

1.13.0～1.13.9、1.14.0～1.14.4、1.15.0

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

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

回避策:

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

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

管理クラスタを再登録します。

ネットワーキング

1.15.0～1.15.2

CoreDNS `orderPolicy` が認識されない

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

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

回避策:

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

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

kubectl edit cm -n kube-system coredns-template

テンプレートの内容を次のように変更します。

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

アップグレード、更新

1.10、1.11、1.12、1.13.0～1.13.7、1.14.0～1.14.3

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

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

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

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

運用

1.13.0～1.13.9、1.14.0～1.14.5、1.15.0～1.15.1

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

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

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

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

回避策:

修正が適用された Google Distributed Cloud のバージョン 1.13.10 以降、1.14.6 以降、1.15.2 以降にアップグレードします。アップグレードできない場合は、Cloud カスタマーケアにお問い合わせください。

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

1.10、1.11、1.12、1.13、1.14

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

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

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

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

回避策:

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

短期的な解決策として、Anthos Network Gateway コンポーネントに PriorityClass を手動で割り当てる方法があります。Google Distributed Cloud コントローラは、クラスタのアップグレードなどの調整プロセス中に、こうした手動による変更を上書きします。

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

アップグレード、更新

1.12、1.13、1.14、1.15.0～1.15.2

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

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

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

gke-connect Namespace を削除します。

kubectl delete ns gke-connect --kubeconfig=ADMIN_KUBECONFIG

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

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

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

gcloud container fleet memberships delete ADMIN_CLUSTER_NAME

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

運用

1.13.0～1.13.8、1.14.0～1.14.5、1.15.0～1.15.1

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

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

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

1.9+、1.10+、1.11+、1.12+

`gkectl prepare windows` が失敗する

MicrosoftDockerProvider が非推奨となっているため、gkectl prepare windows は、1.13 より前のバージョンの Google Distributed Cloud に Docker をインストールできません。

回避策:

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

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

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

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

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

オプション 2: Windows ノードプールを削除し、Google Distributed Cloud 1.13 にアップグレードする際に再度追加する

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

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

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

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

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

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

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

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

1.13.0～1.13.9、1.14.0～1.14.5、1.15.0～1.15.1

`RootDistanceMaxSec` 構成が `ubuntu` ノードに反映されない

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

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

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

回避策:

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

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

アップグレード、更新

1.12.0～1.12.6、1.13.0～1.13.6、1.14.0～1.14.2

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

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

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

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

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

gkectl ログを確認すると、osImageType の設定が空の文字列から ubuntu_containerd に変更されている箇所があります。

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

回避策:

修正が適用された Google Distributed Cloud のバージョンにアップグレードします。アップグレードできない場合は、この問題の解決方法を Cloud カスタマーケアにお問い合わせください。

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

1.13、1.14、1.15、1.16

Controlplane V2 のユーザークラスタで SNI が動作しない

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

回避策:

SNI を使用する必要がある場合は、修正を適用した Google Distributed Cloud パッチが利用可能になるまで、Controlplane V2（enableControlplaneV2: false）を無効にします。

インストール

1.0-1.11、1.12、1.13.0～1.13.9、1.14.0～1.14.5、1.15.0～1.15.1

非公開レジストリのユーザー名に `$` が含まれていると、管理コントロールプレーンのマシンを起動できない

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

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

回避策:

$ なしで非公開レジストリのユーザー名を使用するか、修正が適用された Google Distributed Cloud のバージョンを使用します。

アップグレード、更新

1.12.0～1.12.4

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

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

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

アップグレード、更新

1.13.0～1.13.9、1.14.0～1.14.5、1.15.0～1.15.1

KSA 署名鍵のローテーション後にユーザークラスタの更新が失敗する

KSA 署名鍵をローテーションした後に、ユーザークラスタを更新すると、gkectl update が失敗し、次のエラーメッセージが表示される可能性があります。

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

回避策:

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

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

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

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

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

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

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

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

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

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

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

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

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

運用

1.13.1+、1.14, 1、1.16

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

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

回避策:

F5 リソースを削除するには、ユーザークラスタの F5 パーティションをクリーンアップするの手順に沿って操作します。

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

1.13.8、1.14.4

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

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

docker.io/kindest/kindnetd

docker.io/kindest/local-path-provisioner

docker.io/kindest/local-path-helper

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

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

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

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

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

回避策:

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

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

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

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

運用

1.13.0～1.13.7、1.14.0～1.14.4、1.15.0

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

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

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

回避策:

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

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

アップグレード、更新

1.13.0～1.13.7、1.14.0～1.14.4、1.15.0

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

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

回避策:

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

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

インストール

1.10.3～1.10.7、1.11、1.12、1.13.0～1.13.1

クラスタ登録でエラーが発生しても、管理クラスタの作成が失敗しない

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

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

Failed to register admin cluster

また、Cloud コンソールで登録済みクラスタの中にクラスタがあるかどうか確認できます。

回避策:

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

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

アップグレード、更新

1.10、1.11、1.12、1.13.0～1.13.1

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

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

回避策:

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

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

構成

1.15.0

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

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

vCenter.dataDisk must be present in the AdminCluster spec

回避策:

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

VMware

1.15.0

冗長な VM-Host アフィニティルールが原因でノードプールの作成が失敗する

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

回避策:

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

運用

1.15.0

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

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

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

回避策:

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

アップグレード、更新

1.15.0

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

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

回避策:

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

セキュリティ、構成

1.15.0～1.15.1

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

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

failed to check secret reference for private registry …

回避策:

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

アップグレード、更新

1.15.0

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

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

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

回避策:

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

ストレージ

1.15、1.16

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

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

回避策:

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

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

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

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

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

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

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

環境変数を設定します。

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

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

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

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

readonly を false に設定します。

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

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

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

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

アップグレード、更新

1.12、1.13.0～1.13.7、1.14.0～1.14.4

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

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

回避策:

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

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

上記の手順で取得した vsphere-csi-secret Secret のデータを更新します。

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

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

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

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

アップグレード、更新

1.10、1.11、1.12.0～1.12.6、1.13.0～1.13.6、1.14.0～1.14.2

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

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

回避策:

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

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

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

アップグレード、更新

1.11、1.12、1.13.0～1.13.5、1.14.0～1.14.1

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

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

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

この問題は、Controlplane v2 を使用していないユーザークラスタでのみ発生します。

回避策:

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

アップグレード、更新

1.12.7

問題のあるリリース 1.12.7-gke.19 の削除

Google Distributed Cloud 1.12.7-gke.19 には問題があるため、使用しないでください。これらのアーティファクトは、Cloud Storage バケットから削除されています。

回避策:

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

アップグレード、更新

1.12.0+、1.13.0～1.13.7、1.14.0～1.14.3

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

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

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

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

この問題は、Google Distributed Cloud リリース 1.13.8、1.14.4、およびそれ以降のリリースで修正される予定です。

回避策:

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

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

kubectl --kubeconfig=KUBECONFIG delete namespace gke-connect

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

管理クラスタの場合:

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

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

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

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

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

オプション 3: gke-connect-agent Deployment のクラスタのデフォルトのイメージ pull Secret を以下の方法で追加できます。

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

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

gke-connect-agent Deployment 名を取得します。

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

デフォルトの Secret を gke-connect-agent Deployment に追加します。

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

インストール

1.13、1.14

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

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

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

回避策:

オプション 1: 修正が適用されたパッチバージョン 1.13.7 または 1.14.4 を使用します。

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

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

運用

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

etcd ウォッチの不足

etcd バージョン 3.4.13 以前を実行しているクラスタで、ウォッチが不足したり、動作していないリソースのウォッチが発生する場合があります。これにより、次の問題が発生する可能性があります。

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

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

この問題は、Google Distributed Cloud リリース 1.12.7、1.13.6、1.14.3 以降のリリースで修正されています。これらの新しいリリースでは、etcd バージョン 3.4.21 が使用されています。Google Distributed Cloud の以前のバージョンはすべて、この問題の影響を受けます。

回避策

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

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

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

アップグレード、更新

1.10、1.11、1.12、1.13、1.14

GKE Identity Service が原因でコントロールプレーンのレイテンシが高くなる

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

この問題は、次の Google Distributed Cloud リリースで修正されています。

1.12.6+
1.13.6+
1.14.2+

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

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

この問題の影響を受ける場合、コマンドはステータスコード 400 を返します。リクエストがタイムアウトした場合は、ais Pod を再起動し、curl コマンドを再実行して、問題が解決するかどうかを確認します。ステータスコード 000 が返された場合、問題は解決されています。これ以上の操作は必要ありません。ステータスコード 400 が返された場合は、GKE Identity Service の HTTP サーバーが起動していません。その場合は、次の操作を行います。

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

GKE Identity Service のコンテナログを確認します。

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

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

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

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

次のコマンドを実行します。KUBE_APISERVER_POD は、指定されたクラスタ上の kube-apiserver Pod の名前です。

管理クラスタ:

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

ユーザークラスタ:

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

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

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

回避策

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

GKE Identity Service のログの詳細レベルを 9 にします。

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

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

運用

1.8、1.9、1.10

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

etcddefrag:gke_master_etcddefrag_20210211.00_p0 イメージを使用する etcd-maintenance Pod が影響を受けます。etcddefrag コンテナは、デフラグサイクルのたびに etcd サーバーとの接続を新たに開始しますが、古い接続はクリーンアップされません。

回避策:

オプション 1: 修正が適用されている最新のパッチバージョンにアップグレードします（1.8 から 1.11）。

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

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

運用

1.9、1.10、1.11、1.12、1.13

ユーザークラスタコントロールプレーン Pod のヘルスチェックが実行されない

クラスタのヘルスコントローラと gkectl diagnose cluster コマンドは、どちらも Namespace 全体の Pod のヘルスチェックを含む一連のヘルスチェックを実行します。しかし、ユーザーコントロールプレーン Pod が誤ってスキップされます。Controlplane v2 モードを使用している場合、これはクラスタに影響しません。

回避策:

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

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

アップグレード、更新

1.6+、1.7+

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

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

回避策:

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

ネットワーキング

1.10、1.11、1.12.0～1.12.6、1.13.0～1.13.6、1.14.0～1.14.2

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

gkectl create loadbalancer が失敗し、次のエラーメッセージが表示されます。

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

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

回避策:

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

ネットワーキング

1.14

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

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

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

sudo conntrack -S

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

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

レスポンスの chaintoolong 値がゼロ以外であれば、この問題の影響を受けています。

回避策

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

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

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

ネットワーキング

1.13.0～1.13.2

Controlplane v2 を使用した Windows ノードで calico-typha または anetd-operator クラッシュループが発生する

Controlplane v2 または新しいインストールモデルを使用すると、calico-typha または anetd-operator が Windows ノードにスケジュールされ、クラッシュループが発生する場合があります。

これは、2 つの Deployment で Windows ノード taint を含むすべての taint が許容されるためです。

回避策:

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

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

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

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

次の Toleration を追加します。

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

構成

1.14.0～1.14.2

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

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

[FAILURE] Docker registry access: Failed to login.

回避策:

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

運用

1.10+

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

Dataplane v2 はロードバランシングを引き継ぎ、パケットベースの DNAT の代わりにカーネルソケットを作成します。Pod はバイパスされ、IPTables は使用されないため、Cloud Service Mesh はパケット検査を実施できません。

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

この問題は、Google Distributed Cloud 1.10 のすべてのバージョンで発生しますが、1.10（1.10.2 以降）の一部の新しいバージョンには回避策があります。

回避策:

完全な互換性を確保する場合は 1.11 にアップグレードします。1.10.2 以降を実行している場合は以下を実行します。

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

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

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

ストレージ

1.12+、1.13.3

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

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

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

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

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

# See all the mounting points with disks
lsblk -f

# See some ext4 errors
sudo dmesg -T

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

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

回避策:

SSH を使用して、影響を受けているノードに接続し、ノードを再起動します。

アップグレード、更新

1.12+、1.13+、1.14+

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

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

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

回避策:

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

運用

1.10+、1.11+、1.12+、1.13+、1.14+

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

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

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

回避策:

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

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

1.10+、1.11+、1.12+、1.13+、1.14+、1.15+、1.16+

VM のシャットダウン / 再起動時に DHCP リースが予期せずに解放され、IP が変更されることがある

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

たとえば、次のような症状が発生します。

vCenter UI では、同じ IP を使用する VM はありませんが、

kubectl get
        nodes -o wide

を実行すると、重複する IP を持つノードが報告されます。

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

calico-node エラーにより、新しいノードを起動できません。

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

回避策:

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

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

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

1.12.0～1.12.5、1.13.0～1.13.5、1.14.0～1.14.1

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

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

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

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

出力が空の場合、キーが消去されていることを意味します。

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

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

回避策:

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

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

運用

1.13.0+、1.14.0+

Controlplane V2 が有効になっていると、クラスタオートスケーラーが機能しない

Controlplane V2 または新しいインストールモデルで作成されたユーザークラスタでは、自動スケーリングが有効なノードプールは常に、user-cluster.yaml の autoscaling.minReplicas を使用します。cluster-autoscaler Pod のログには、異常な状態の Pod も記録されます。

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

cluster-autoscaler Pod を確認するには、次のコマンドを実行します。

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

回避策:

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

インストール

1.12.0 から 1.12.4、1.13.0～1.13.3、1.14.0

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

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

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

回避策:

修正が適用されたバージョン 1.12.5、1.13.4、1.14.1 以降にアップグレードするまで、IP ブロックファイルに個々の IP を記述します。

アップグレード、更新

1.14.0～1.14.1

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

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

回避策:

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

運用

1.10、1.11、1.12、1.13、1.14.0

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

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

  error getting ClusterInformation: connection is unauthorized: Unauthorized

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

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

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

回避策:

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

すぐにアップグレードできない場合は、管理クラスタとユーザークラスタの calico-node DaemonSet に次のパッチを適用します。

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

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

次のように置き換えます。

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

インストール

1.12.0 から 1.12.4、1.13.0～1.13.3、1.14.0

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

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

回避策:

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

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

1.11.0～1.11.1、1.10.0～1.10.4、1.9.0～1.9.6

管理クラスタのバックアップに、常時有効なシークレット暗号鍵と構成が含まれていない

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

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

回避策:

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

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

1.10+

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

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

アップグレード、更新

1.10

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

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

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

回避策:

回避策の手順を表示

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

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

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

アップグレード、更新

1.10.0

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

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

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

ノード状態で、Docker が頻繁に再起動するかどうか確認できます。出力の例を次に示します。

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

根本原因を把握するには、問題が発生しているノードに SSH 接続し、sudo journalctl --utc -u docker や sudo journalctl -x などのコマンドを実行する必要があります。

回避策:

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

アップグレード、更新

1.11、1.12

バージョン 1.12 にアップグレードした後、セルフデプロイの GMP コンポーネントが維持されない

バージョン 1.12 より前の Google Distributed Cloud を使用していて、クラスタの gmp-system Namespace に Google マネージド Prometheus（GMP）コンポーネントを手動で設定している場合、バージョン 1.12.x にアップグレードすると、コンポーネントが維持されません。

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

回避策:

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

運用

1.11、1.12、1.13.0～1.13.1

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

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

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

回避策:

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

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

ここで

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

アップグレード、更新

1.11.0～1.11.4、1.12.0～1.12.3、1.13.0～1.13.1

vSAN 環境でユーザークラスタを削除しているときに、ノードのドレインが停止する

次のシナリオで、ユーザークラスタを削除、更新、またはアップグレードしているときにノードのドレインが停止することがあります。

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

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

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

このコマンドから次のようなエラーメッセージが返されます。

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

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

回避策:

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

構成

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

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

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

次のような症状がみられます。

cluster-autoscaler ログ

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

ADMIN_CLUSTER_KUBECONFIG

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

回避策:

回避策の手順を表示

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

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

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

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

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

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

構成

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

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

ユーザークラスタの削除時に、対応する clusterrole も削除されるため、自動修復と vsphere 指標エクスポータが機能しなくなります。

次のような症状がみられます。

cluster-health-controller ログ

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

ADMIN_CLUSTER_KUBECONFIG

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

vsphere-metrics-exporter ログ

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

ADMIN_CLUSTER_KUBECONFIG

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

回避策:

回避策の手順を表示

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

vsphere-metrics-exporter の場合

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

cluster-health-controller の場合

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

構成

1.12.1～1.12.3、1.13.0～1.13.2

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

これは、gkectl prepare を実行せずに gkectl check-config が失敗する可能性がある既知の問題です。gkectl prepare を実行する前にこのコマンドの実行をすすめているため、混乱が生じています。

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

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

回避策:

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

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

アップグレード、更新

1.11、1.12、1.13

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

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

gkectl update コマンドが次のエラーメッセージで失敗します。

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

回避策:

回避策の手順を表示

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

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

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

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

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

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

kubectl delete machines MACHINE_NAME --kubeconfig USER_KUBECONFIG

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

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

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

kubectl delete machines MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG

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

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

kubectl delete machines MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG

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

1.13.0～1.13.8、1.14.0～1.14.4、1.15.0

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

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

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

kubectl get csr -A -o wide

次のログでエラーメッセージがないか確認します。

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

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

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

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

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

回避策:

ユーザークラスタ

次の手順でノード ID の検証を無効にします。

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

管理クラスタ

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

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

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

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

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

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

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

1.11.0～1.11.4

非公開レジストリの証明書バンドルが原因で、管理コントロールプレーンマシンの起動に失敗する

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

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

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

Invalid value 'XXXX' specified for property startup-data

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

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

Networking

1.10, 1.11.0-1.11.3, 1.12.0-1.12.2, 1.13.0

`NetworkGatewayNodes` marked unhealthy from concurrent status update conflict

In networkgatewaygroups.status.nodes, some nodes switch between NotHealthy and Up.

Logs for the ang-daemon Pod running on that node reveal repeated errors:

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

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

データプレーンのアクティビティに、それ以外の影響はありません。

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

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

回避策:

利用可能であれば、修正されたバージョンにアップグレードします。

アップグレード、更新

1.12.0～1.12.2、1.13.0

競合状態により、更新中またはアップグレード中にマシンオブジェクトの削除がブロックされる

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

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

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

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

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

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

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

回避策:

この問題には、環境と要件に応じていくつかの緩和策があります。

オプション 1: 最終的に単独でアップグレードが完了するまで待機します。

環境での分析と再現に基づいて、アップグレードは手動による介入なしで最終的に完了します。このオプションの注意点は、各マシンオブジェクトでファイナライザの削除にどのくらい時間がかかるかわからないことです。この処理は、すぐに行われる可能性もありますが、machineset コントローラの調整が非常に高速で処理され、調整の間にマシンコントローラがファイナライザを削除する時間がないと、数時間にわたり継続する可能性があります。

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

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

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

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

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

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

1.10.2、1.11、1.12、1.13

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

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

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

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

回避策:

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

インストール

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

vCenter URL に `https://` または `http://` 接頭辞が含まれていると、クラスタの起動に失敗することがある

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

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

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

回避策:

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

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

1.10、1.11、1.12、1.13

`util.CheckFileExists` で `gkectl prepare` がパニックする

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

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

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

この問題は、gkectl prepare が非公開レジストリの証明書ディレクトリを誤った権限で作成したことが原因で発生します。

回避策:

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

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

アップグレード、更新

1.10、1.11、1.12、1.13

`gkectl repair admin-master` と再開可能な管理アップグレードが連携しない

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

回避策:

この状況がすでに発生している場合は、サポートにお問い合わせください。

アップグレード、更新

1.10、1.11

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

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

回避策:

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

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

1.12、1.13

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

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

回避策:

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

1.10、1.11、1.12、1.13

ClientConfig カスタムリソース

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

回避策:

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

インストール

1.10、1.11、1.12、1.13

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

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

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

回避策:

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

インストール

1.12

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

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

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

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

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

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

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

回避策:

回避策の手順を表示

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

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

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

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

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

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

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

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

インストールが完了し、クラスタが稼働したら、Day 2 運用で monitoring-operator を有効にします。

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

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

VMware

1.10、1.11、1.12、1.13

バージョンが 7.0U2 より前の場合の vCenter の再起動またはアップグレード

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

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

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

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

ClientAliveInterval 300
ClientAliveCountMax 0

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

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

回避策:

次のいずれかを行います。

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

SSH セッションを再接続します。

インストール

1.10、1.11、1.12、1.13

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

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

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

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

回避策:

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

使用しているバージョンの cert-manager をアンインストールします。独自のリソースを定義している場合は、リソースをバックアップすることをおすすめします。

アップグレードを実行します。

独自の cert-manager を復元するには、次の操作を行います。

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

monitoring-operator Deployment を 0 にスケーリングします。
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ -n USER_CLUSTER_NAME \ scale deployment monitoring-operator --replicas=0

monitoring-operator によって管理される cert-manager Deployment を 0 にスケーリングします。
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \ -n cert-manager scale deployment cert-manager --replicas=0 kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \ -n cert-manager scale deployment cert-manager-cainjector\ --replicas=0 kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \ -n cert-manager scale deployment cert-manager-webhook --replicas=0

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

アップストリームのデフォルト cert-manager のインストールを使用している場合、または cert-manager が cert-manager Namespace にインストールされている場合は、この手順をスキップできます。それ以外の場合は、metrics-ca cert-manager.io/v1 証明書と metrics-pki.cluster.local Issuer リソースを cert-manager から、インストールした cert-manager のクラスタリソースの Namespace にコピーします。
relevant_fields=' { apiVersion: .apiVersion, kind: .kind, metadata: { name: .metadata.name, namespace: "YOUR_INSTALLED_CERT_MANAGER_NAMESPACE" }, spec: .spec } ' f1=$(mktemp) f2=$(mktemp) kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \ get issuer -n cert-manager metrics-pki.cluster.local -o json \ | jq "${relevant_fields}" > $f1 kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \ get certificate -n cert-manager metrics-ca -o json \ | jq "${relevant_fields}" > $f2 kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f $f1 kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f $f2

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

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

monitoring-operator Deployment を 0 にスケーリングします。
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ -n kube-system scale deployment monitoring-operator --replicas=0

monitoring-operator によって管理される cert-manager Deployment を 0 にスケーリングします。
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ -n cert-manager scale deployment cert-manager \ --replicas=0 kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ -n cert-manager scale deployment cert-manager-cainjector \ --replicas=0 kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ -n cert-manager scale deployment cert-manager-webhook \ --replicas=0

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

アップストリームのデフォルト cert-manager のインストールを使用している場合、または cert-manager が cert-manager Namespace にインストールされている場合は、この手順をスキップできます。それ以外の場合は、metrics-ca cert-manager.io/v1 証明書と metrics-pki.cluster.local Issuer リソースを cert-manager から、インストールした cert-manager のクラスタリソースの Namespace にコピーします。
relevant_fields=' { apiVersion: .apiVersion, kind: .kind, metadata: { name: .metadata.name, namespace: "YOUR_INSTALLED_CERT_MANAGER_NAMESPACE" }, spec: .spec } ' f3=$(mktemp) f4=$(mktemp) kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \n get issuer -n cert-manager metrics-pki.cluster.local -o json \ | jq "${relevant_fields}" > $f3 kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ get certificate -n cert-manager metrics-ca -o json \ | jq "${relevant_fields}" > $f4 kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f $f3 kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f $f4

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

1.10、1.11、1.12、1.13

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

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

ただし、特殊なバージョンは、さまざまな CVE スキャンツールで脆弱性フィードとして使用されている Ubuntu CVE Tracker に認識されていません。このため、Docker、containerd、runc の脆弱性スキャンで誤検出が発生します。

たとえば、CVE スキャンで次の誤検出が発生することがあります。これらの CVE は、Google Distributed Cloud の最新のパッチバージョンで修正済みです。

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

回避策:

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

アップグレード、更新

1.10、1.11、1.12、1.13

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

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

回避策:

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

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

1.10、1.11、1.12、1.13

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

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

回避策:

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

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

1.7、1.8、1.9、1.10、1.11

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

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

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

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

回避策:

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

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

ネットワーキング

1.10、1.11、1.12、1.13

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

NSX-T ステートフル分散ファイアウォールルールを使用する環境に、Seesaw がバンドルされているロードバランサがデプロイされている場合、Google Distributed Cloud バージョン 1.9 以降をデプロイすると、stackdriver-operator が gke-metrics-agent-conf ConfigMap の作成に失敗し、gke-connect-agent Pod がクラッシュループに入る可能性があります。

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

回避策:

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

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

ロギングとモニタリング

1.10、1.11、1.12、1.13、1.14、1.15

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

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

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

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

回避策

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

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

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

enableStackdriverForApplications: true 行を削除してから保存し、エディタを終了します。

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

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

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

Pod または Service から prometheus.io/scrap=true アノテーションを削除します。アノテーションが Cloud Service Mesh によって追加される場合は、Prometheus オプションなしで Cloud Service Mesh を構成するか、Istio 指標マージ機能をオフにすることを検討してください。

インストール

1.11、1.12、1.13

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

カスタムロールが誤った権限レベルでバインドされていると、Google Distributed Cloud インストーラが失敗する可能性があります。

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

回避策:

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

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

ロギングとモニタリング

1.9.0～1.9.4、1.10.0～1.10.1

monitoring.googleapis.com に対する大量のネットワークトラフィック

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

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

回避策:

回避策の手順を表示

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

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

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

gke-metrics-agent-conf ConfigMap を開いて編集します。

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

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

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

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

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

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

ロギングとモニタリング

1.10、1.11

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

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

回避策:

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

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

gke-metrics-agent-conf ConfigMap を開いて編集します。

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

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

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

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

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

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

ロギングとモニタリング

1.11、1.12、1.13

ダッシュボードで非推奨の指標を置き換える

非推奨の指標が OOTB ダッシュボードで使用されていると、空のグラフがいくつか表示されます。Monitoring ダッシュボードで非推奨の指標を見つけるには、次のコマンドを実行します。

gcloud monitoring dashboards list > all-dashboard.json

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

次の非推奨の指標を別の指標に移行する必要があります。

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

回避策:

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

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

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

ロギングとモニタリング

1.10、1.11、1.12、1.13

Cloud Monitoring で不明な指標データ

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

Unknown metric: kubernetes.io/anthos/go_gc_duration_seconds_summary_percentile

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

apiserver_admission_step_admission_duration_seconds_summary
go_gc_duration_seconds
scheduler_scheduling_duration_seconds
gkeconnect_http_request_duration_seconds_summary
alertmanager_nflog_snapshot_duration_seconds_summary

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

ロギングとモニタリング

1.10、1.11、1.12、1.13

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

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

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

回避策:

この問題を解決するには、回避策として次の操作を行います。[バージョン 1.9.5 以降、1.10.2 以降、1.11.0]: 次のステップ 1～4 で、gke-metrics-agent の CPU を増やします。

stackdriver リソースを開いて編集します。

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

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

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

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

spec:
  anthosDistribution: on-prem
  clusterLocation: us-west1-a
  clusterName: my-cluster
  enableStackdriverForApplications: true
  gcpServiceAccountSecretName: ...
  optimizedMetrics: true
  portable: true
  projectID: my-project-191923
  proxyConfigSecretName: ...
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      limits:
        cpu: 200m
        memory: 4608Mi
      requests:
        cpu: 50m
        memory: 200Mi

変更を保存し、テキストエディタを終了します。
変更が有効になっていることを確認するには、次のコマンドを実行します。
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system get daemonset gke-metrics-agent -o yaml \
    | grep "cpu: 50m"
```
編集内容が有効になっている場合は、このコマンドで cpu: 50m が検出されます。

ロギングとモニタリング

1.11.0～1.11.2、1.12.0

管理クラスタに scheduler と controller-manager の指標がない

管理クラスタがこの問題の影響を受ける場合、scheduler と controller-manager の指標が欠落しています。たとえば、次の 2 つの指標が欠落しています。

# scheduler metric example
scheduler_pending_pods
# controller-manager metric example
replicaset_controller_rate_limiter_use

回避策:

v1.11.3+、v1.12.1+、または v1.13+ にアップグレードします。

1.11.0～1.11.2、1.12.0

ユーザークラスタに scheduler と controller-manager の指標がない

ユーザークラスタがこの問題の影響を受ける場合、scheduler と controller-manager の指標が欠落しています。たとえば、次の 2 つの指標が欠落しています。

# scheduler metric example
scheduler_pending_pods
# controller-manager metric example
replicaset_controller_rate_limiter_use

回避策:

この問題は、Google Distributed Cloud バージョン 1.13.0 以降で修正されています。修正が適用されたバージョンにクラスタをアップグレードします。

インストール、アップグレード、更新

1.10、1.11、1.12、1.13

作成時に管理クラスタを登録できない

バージョン 1.9.x または 1.10.0 の管理クラスタを作成するときに、指定された gkeConnect 仕様で管理クラスタを登録できない場合、次のエラーが発生します。

Failed to create root cluster: failed to register admin cluster: failed to register cluster: failed to apply Hub Membership: Membership API request failed: rpc error:  ode = PermissionDenied desc = Permission 'gkehub.memberships.get' denied on PROJECT_PATH

この管理クラスタは引き続き使用できますが、後で管理クラスタをバージョン 1.10.y にアップグレードしようとすると、次のエラーが発生します。

failed to migrate to first admin trust chain: failed to parse current version "": invalid version: "" failed to migrate to first admin trust chain: failed to parse current version "": invalid version: ""

回避策:

回避策の手順を表示

このエラーが発生した場合は、以下の手順でクラスタ登録の問題を解決してください。この修正を行うと、管理クラスタをアップグレードできます。

gkectl update admin を実行して、管理クラスタを正しいサービスアカウントキーに登録します。

OnPremAdminCluster カスタムリソースにパッチを適用するために専用のサービスアカウントを作成します。

export KUBECONFIG=ADMIN_CLUSTER_KUBECONFIG

# Create Service Account modify-admin
kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
  name: modify-admin
  namespace: kube-system
EOF

# Create ClusterRole
kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  creationTimestamp: null
  name: modify-admin-role
rules:
- apiGroups:
  - "onprem.cluster.gke.io"
  resources:
  - "onpremadminclusters/status"
  verbs:
  - "patch"
EOF

# Create ClusterRoleBinding for binding the permissions to the modify-admin SA

kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  creationTimestamp: null
  name: modify-admin-rolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: modify-admin-role
subjects:
- kind: ServiceAccount
  name: modify-admin
  namespace: kube-system
EOF

ADMIN_CLUSTER_KUBECONFIG は、管理クラスタの kubeconfig ファイルのパスに置き換えます。

次のコマンドを実行して、OnPremAdminCluster カスタムリソースを更新します。

export KUBECONFIG=ADMIN_CLUSTER_KUBECONFIG

SERVICE_ACCOUNT=modify-admin

SECRET=$(kubectl get serviceaccount ${SERVICE_ACCOUNT} \
    -n kube-system -o json \
    | jq -Mr '.secrets[].name | select(contains("token"))')

TOKEN=$(kubectl get secret ${SECRET} -n kube-system -o json \
    | jq -Mr '.data.token' | base64 -d)

kubectl get secret ${SECRET} -n kube-system -o json \
    | jq -Mr '.data["ca.crt"]' \
    | base64 -d > /tmp/ca.crt

APISERVER=https://$(kubectl -n default get endpoints kubernetes \
    --no-headers | awk '{ print $2 }')

# Find out the admin cluster name and gkeOnPremVersion from the OnPremAdminCluster CR
ADMIN_CLUSTER_NAME=$(kubectl get onpremadmincluster -n kube-system \
    --no-headers | awk '{ print $1 }')
GKE_ON_PREM_VERSION=$(kubectl get onpremadmincluster \
    -n kube-system $ADMIN_CLUSTER_NAME \
    -o=jsonpath='{.spec.gkeOnPremVersion}')

# Create the Status field and set the gkeOnPremVersion in OnPremAdminCluster CR
curl -H "Accept: application/json" \
    --header "Authorization: Bearer $TOKEN" -XPATCH \
    -H "Content-Type: application/merge-patch+json" \
    --cacert /tmp/ca.crt \
    --data '{"status": {"gkeOnPremVersion": "'$GKE_ON_PREM_VERSION'"}}' \
    $APISERVER/apis/onprem.cluster.gke.io/v1alpha1/namespaces/kube-system/onpremadminclusters/$ADMIN_CLUSTER_NAME/status

--disable-upgrade-from-checkpoint フラグを使用して管理クラスタのアップグレードを再試行します。
```
gkectl upgrade admin --config ADMIN_CLUSTER_CONFIG \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --disable-upgrade-from-checkpoint
```
ADMIN_CLUSTER_CONFIG は、管理クラスタの構成ファイルのパスに置き換えます。

1.10、1.11、1.12、1.13

GKE Identity Service を使用すると Connect Agent が予期せず再起動する場合がある

GKE Identity Service 機能を使用して GKE Identity Service ClientConfig を管理している場合は、Connect Agent が予期せず再起動することがあります。

回避策:

既存のクラスタでこの問題が発生した場合は、次のいずれかを行います。

GKE Identity Service を無効にします。GKE Identity Service を無効にしても、デプロイされた GKE Identity Service バイナリや GKE Identity Service ClientConfig は削除されません。GKE Identity Service を無効にするには、次のコマンドを実行します。
```
gcloud container fleet identity-service disable \
    --project PROJECT_ID
```
PROJECT_ID は、クラスタのフリートホストプロジェクトの ID に置き換えます。
Connect Agent のバージョンをアップグレードするために、クラスタをバージョン 1.9.3 以降またはバージョン 1.10.1 以降に更新します。

ネットワーキング

1.10、1.11、1.12、1.13

Cisco ACI が Direct Server Return（DSR）と連動しない

Seesaw は DSR モードで動作します。デフォルトでは、data-plane IP の学習が原因で Cisco ACI では機能しません。

回避策:

この問題を回避するには、Seesaw IP アドレスを Cisco Application Policy Infrastructure Controller（APIC）の L4-L7 仮想 IP として追加し、IP の学習を無効にします。

[Tenant] > [Application Profiles] > [Application EPGs] または [uSeg EPGs] に移動すると、L4-L7 仮想 IP オプションを構成できます。IP の学習の無効化に失敗すると、Cisco API ファブリック内の異なるロケーション間で IP エンドポイントでフラッピングが発生します。

VMware

1.10、1.11、1.12、1.13

vSphere 7.0 Update 3 の問題

VMware は最近、次の vSphere 7.0 Update 3 リリースで重大な問題を確認しました。

vSphere ESXi 7.0 Update 3（ビルド 18644231）
vSphere ESXi 7.0 Update 3a（ビルド 18825058）
vSphere ESXi 7.0 Update 3b（ビルド 18905247）
vSphere vCenter 7.0 Update 3b（ビルド 18901211）

回避策:

その後、VMWare はこれらのリリースを削除しました。ESXi と vCenter Server を新しいバージョンにアップグレードする必要があります。

オペレーティングシステム

1.10、1.11、1.12、1.13

COS ノードで実行されている Pod に emptyDir ボリュームを `exec` としてマウントできない

Container-Optimized OS（COS）イメージを使用するノードで動作する Pod で、emptyDir ボリュームを exec としてマウントできません。noexec としてマウントすると、「exec user process caused: permission denied」というエラーメッセージが表示されます。たとえば、次のテスト Pod をデプロイすると、次のエラーメッセージが表示されます。

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: test
  name: test
spec:
  containers:
  - args:
    - sleep
    - "5000"
    image: gcr.io/google-containers/busybox:latest
    name: test
    volumeMounts:
      - name: test-volume
        mountPath: /test-volume
    resources:
      limits:
        cpu: 200m
        memory: 512Mi
  dnsPolicy: ClusterFirst
  restartPolicy: Always
  volumes:
    - emptyDir: {}
      name: test-volume

テスト Pod で mount | grep test-volume を実行すると、noexec オプションが表示されます。

/dev/sda1 on /test-volume type ext4 (rw,nosuid,nodev,noexec,relatime,commit=30)

回避策:

回避策の手順を表示

DaemonSet リソースを適用します。例:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fix-cos-noexec
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: fix-cos-noexec
  template:
    metadata:
      labels:
        app: fix-cos-noexec
    spec:
      hostIPC: true
      hostPID: true
      containers:
      - name: fix-cos-noexec
        image: ubuntu
        command: ["chroot", "/host", "bash", "-c"]
        args:
        - |
          set -ex
          while true; do
            if ! $(nsenter -a -t 1 findmnt -l | grep -qe "^/var/lib/kubelet\s"); then
              echo "remounting /var/lib/kubelet with exec"
              nsenter -a -t 1 mount --bind /var/lib/kubelet /var/lib/kubelet
              nsenter -a -t 1 mount -o remount,exec /var/lib/kubelet
            fi
            sleep 3600
          done
        volumeMounts:
        - name: host
          mountPath: /host
        securityContext:
          privileged: true
      volumes:
      - name: host
        hostPath:
          path: /

アップグレード、更新

1.10、1.11、1.12、1.13

ノードプールで自動スケーリングが無効になると、クラスタノードプールのレプリカの更新が機能しない

ノードプールで自動スケーリングを有効にしてから無効にすると、ノードプールのレプリカが更新されません。

回避策:

対応するノードプールのマシンデプロイから cluster.x-k8s.io/cluster-api-autoscaler-node-group-max-size アノテーションと cluster.x-k8s.io/cluster-api-autoscaler-node-group-min-size アノテーションを削除します。

ロギングとモニタリング

1.11、1.12、1.13

Windows モニタリングダッシュボードに Linux クラスタからのデータが表示される

バージョン 1.11 以降では、すぐに使えるモニタリングダッシュボード（Windows Pod ステータスダッシュボードと Windows ノードステータスダッシュボード）に Linux クラスタからのデータも表示されます。これは、Windows ノードと Pod の指標が Linux クラスタで公開されるためです。

ロギングとモニタリング

1.10、1.11、1.12

定数 CrashLoopBackOff 内の `stackdriver-log-forwarder`

Google Distributed Cloud バージョン 1.10、1.11、1.12 の場合、ディスクでバッファリングされたログが破損していると、stackdriver-log-forwarder DaemonSet で CrashLoopBackOff エラーが発生することがあります。

回避策:

この問題を軽減するには、ノード上のバッファログをクリーンアップする必要があります。

予期しない動作を防ぐには、stackdriver-log-forwarder をスケールダウンします。
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n kube-system patch daemonset stackdriver-log-forwarder -p '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}'
```
USER_CLUSTER_KUBECONFIG は、ユーザークラスタの kubeconfig ファイルのパスに置き換えます。

クリーンアップした DaemonSet をデプロイして、壊れたチャンクをクリーンアップします。

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n kube-system -f - << EOF
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluent-bit-cleanup
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: fluent-bit-cleanup
  template:
    metadata:
      labels:
        app: fluent-bit-cleanup
    spec:
      containers:
      - name: fluent-bit-cleanup
        image: debian:10-slim
        command: ["bash", "-c"]
        args:
        - |
          rm -rf /var/log/fluent-bit-buffers/
          echo "Fluent Bit local buffer is cleaned up."
          sleep 3600
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        securityContext:
          privileged: true
      tolerations:
      - key: "CriticalAddonsOnly"
        operator: "Exists"
      - key: node-role.kubernetes.io/master
        effect: NoSchedule
      - key: node-role.gke.io/observability
        effect: NoSchedule
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
EOF

クリーンアップの DaemonSet がすべてのチャンクをクリーンアップしたことを確認するには、次のコマンドを実行します。2 つのコマンドの出力で、クラスタ内のノード数が同じになるはずです。
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  logs -n kube-system -l app=fluent-bit-cleanup | grep "cleaned up" | wc -l

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system get pods -l app=fluent-bit-cleanup --no-headers | wc -l
```

クリーンアップの DaemonSet を削除します。

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system delete ds fluent-bit-cleanup

stackdriver-log-forwarder を再開します。

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system patch daemonset stackdriver-log-forwarder --type json -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'

ロギングとモニタリング

1.10、1.11、1.12、1.13、1.14、1.15、1.16

`stackdriver-log-forwarder` が Cloud Logging にログを送信しない

Cloud Logging にクラスタからのログが表示されず、次のエラーがログに記録されています。

2023-06-02T10:53:40.444017427Z [2023/06/02 10:53:40] [error] [input chunk] chunk 1-1685703077.747168499.flb would exceed total limit size in plugin stackdriver.0
2023-06-02T10:53:40.444028047Z [2023/06/02 10:53:40] [error] [input chunk] no available chunk

ログの入力レートが Logging エージェントの制限を超えている可能性があります。このため、stackdriver-log-forwarder はログを送信しません。この問題は、すべての Google Distributed Cloud バージョンで発生します。

回避策:

この問題を軽減するには、Logging エージェントのリソース上限を増やす必要があります。

stackdriver リソースを開いて編集します。

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system edit stackdriver stackdriver

stackdriver-log-forwarder の CPU リクエストを増やすには、次の resourceAttrOverride セクションを stackdriver マニフェストに追加します。

spec:
  resourceAttrOverride:
    stackdriver-log-forwarder/stackdriver-log-forwarder:
      limits:
        cpu: 1200m
        memory: 600Mi
      requests:
        cpu: 600m
        memory: 600Mi

編集後のリソースは次のようになります。

spec:
  anthosDistribution: on-prem
  clusterLocation: us-west1-a
  clusterName: my-cluster
  enableStackdriverForApplications: true
  gcpServiceAccountSecretName: ...
  optimizedMetrics: true
  portable: true
  projectID: my-project-191923
  proxyConfigSecretName: ...
  resourceAttrOverride:
    stackdriver-log-forwarder/stackdriver-log-forwarder:
      limits:
        cpu: 1200m
        memory: 600Mi
      requests:
        cpu: 600m
        memory: 600Mi

変更を保存し、テキストエディタを終了します。
変更が有効になっていることを確認するには、次のコマンドを実行します。
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system get daemonset stackdriver-log-forwarder -o yaml \
    | grep "cpu: 1200m"
```
編集内容が有効になっている場合は、このコマンドで cpu: 1200m が検出されます。

セキュリティ

1.13

NodeReady 後に Kubelet サービスが一時的に利用できなくなる

ノードの準備ができても kubelet サーバー証明書の準備ができていない期間が少しあります。この 10 秒間は kubectl exec と kubectl logs を使用できません。これは、新しいサーバー証明書の承認者が、更新された有効なノードの IP を確認するのに時間がかかるためです。

この問題は kubelet サーバー証明書にのみ影響します。Pod のスケジューリングには影響しません。

アップグレード、更新

1.12

部分的な管理クラスタのアップグレードで、後のユーザークラスタのアップグレードがブロックされない

ユーザークラスタのアップグレードが次のエラーで失敗します。

.LBKind in body is required (Check the status of OnPremUserCluster 'cl-stg-gdl-gke-onprem-mgmt/cl-stg-gdl' and the logs of pod 'kube-system/onprem-user-cluster-controller' for more detailed debugging information.

管理クラスタが完全にアップグレードされておらず、ステータスバージョンがまだ 1.10 になっています。1.12 へのユーザークラスタのアップグレードは、プリフライトチェックではブロックされませんが、バージョンスキューの問題で失敗します。

回避策:

管理クラスタを 1.11 にアップグレードしてから、ユーザークラスタを 1.12 にアップグレードします。

ストレージ

1.10.0～1.10.5、1.11.0～1.11.2、1.12.0

データストアで不足している空き容量が正しく報告されない

gkectl diagnose cluster コマンドが次のエラーで失敗します。

Checking VSphere Datastore FreeSpace...FAILURE
    Reason: vCenter datastore: [DATASTORE_NAME] insufficient FreeSpace, requires at least [NUMBER] GB

データストアの空き容量の検証は、既存のクラスタノードプールに使用しないでください。この検証は gkectl diagnose cluster に誤って追加されたものです。

回避策:

このエラーメッセージは無視して構いません。--skip-validation-infra を使用して検証をスキップできます。

運用、ネットワーキング

1.11、1.12.0～1.12.1

管理クラスタが MetalLB ロードバランサの構成で設定されていると、新しいユーザークラスタを追加できない場合があります。

ユーザークラスタの削除プロセスがなんらかの理由で停止し、その結果、MatalLB ConfigMap が無効になる場合があります。この状態では新しいユーザークラスタを追加できません。

回避策:

ユーザークラスタを強制的に削除できます。

インストール、オペレーティングシステム

1.10、1.11、1.12、1.13

ユーザークラスタに Container-Optimized OS（COS）を使用すると失敗する

管理クラスタで osImageType が cos を使用している場合、管理クラスタを作成してからユーザークラスタを作成するまでの間に gkectl check-config を実行すると、次のエラーで処理が失敗します。

Failed to create the test VMs: VM failed to get IP addresses on the network.

デフォルトでは、ユーザークラスタ check-config 用に作成されたテスト VM は管理クラスタと同じ osImageType を使用します。現在、テスト VM は COS と互換性がありません。

回避策:

gkectl check-config --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG --fast を使用して、テスト VM を作成するスロープリフライトチェックを回避します。

ロギングとモニタリング

1.12.0～1.12.1

管理クラスタの Grafana がユーザークラスタに到達できない

この問題は、管理クラスタで Grafana を使用し、Google Distributed Cloud バージョン 1.12.0 と 1.12.1 でユーザークラスタをモニタリングしているユーザーに影響します。これは、ユーザークラスタの pushprox-client 証明書と管理クラスタの pushprox-server の許可リストの不一致が原因で発生します。この症状は、次のようなエラーログが出力されるユーザークラスタの pushprox-client で発生します。

level=error ts=2022-08-02T13:34:49.41999813Z caller=client.go:166 msg="Error reading request:" err="invalid method \"RBAC:\""

回避策:

回避策の手順を表示

次の操作を行います。

管理クラスタの kube-system Namespace で monitoring-operator の Deployment をスケールダウンします。

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --namespace kube-system scale deploy monitoring-operator \
    --replicas=0

管理クラスタの kube-system Namespace で pushprox-server-rbac-proxy-config ConfigMap を編集します。

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --namespace kube-system edit cm pushprox-server-rbac-proxy-config

external-pushprox-server-auth-proxy リスナーの principals 行を見つけて、pushprox-client.metrics-consumers.kube-system.cluster. から kube-system 部分文字列を削除し、すべてのユーザークラスタの principal_name を修正します。新しい構成は次のようになります。

permissions:
- or_rules:
    rules:
    - header: { name: ":path", exact_match: "/poll" }
    - header: { name: ":path", exact_match: "/push" }
principals: [{"authenticated":{"principal_name":{"exact":"pushprox-client.metrics-consumers.kube-system.cluster.local"}}},{"authenticated":{"principal_name":{"exact":"pushprox-client.metrics-consumers.kube-system.cluster."}}},{"authenticated":{"principal_name":{"exact":"pushprox-client.metrics-consumers.cluster."}}}]

管理クラスタで pushprox-server Deployment を再起動し、影響を受けるユーザークラスタで pushprox-client Deployment を再起動します。

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system rollout restart deploy pushprox-server
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system rollout restart deploy pushprox-client

上記の手順で問題が解決するはずです。問題が修正された 1.12.2 以降にクラスタがアップグレードされたら、管理クラスタの kube-system monitoring-operator をスケールアップして、パイプラインを再度管理できるようにします。
```
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system scale deploy monitoring-operator --replicas=1
```

その他

1.11.3

`gkectl repair admin-master` で、復元に使用する VM テンプレートがない

gkectl repair admin-master コマンドが次のエラーで失敗します。

Failed to repair: failed to select the template: no VM templates is available for repairing the admin master (check if the admin cluster version >= 1.4.0 or contact support

管理コントロールプレーン VM の名前の末尾の文字が t、m、p、l である場合、gkectl repair admin-master は、管理コントロールプレーン VM の修復に使用する VM テンプレートを取得できません。

回避策:

--skip-validation を使用して、コマンドを再実行します。

ロギングとモニタリング

1.11、1.12、1.13、1.14、1.15、1.16

権限が拒否されたため Cloud Audit Logs が失敗する

Cloud Audit Logs には、現在 GKE Hub を使用しているユーザークラスタに対してのみ自動的に実行される特別な権限設定が必要です。管理クラスタに必要な権限が付与されるように、Cloud Audit Logs には、管理クラスタと同じプロジェクト ID とサービスアカウントを使用するユーザークラスタを少なくとも 1 つ設定することをおすすめします。

ただし、管理クラスタがユーザークラスタとは異なるプロジェクト ID またはサービスアカウントを使用している場合、管理クラスタの監査ログは Google Cloud に挿入されません。この状況になると、管理クラスタの audit-proxy Pod での一連の Permission Denied エラーが発生します。

回避策:

回避策の手順を表示

この問題を解決するには、cloudauditlogging Hub 機能を操作して権限を設定します。

まず、プロジェクトで Cloud Audit Logs の許可リストに登録されている既存のサービスアカウントを確認します。

curl -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features/cloudauditlogging

レスポンスに応じて、次のいずれかを行います。
- 404 Not_found エラーが発生した場合、このプロジェクト ID の許可リストに登録されたサービスアカウントがないことを意味します。cloudauditlogging Hub 機能を有効にすることで、サービスアカウントを許可リストに登録できます。
```
curl -X POST -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    -H "Content-Type: application/json" \
    https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features?feature_id=cloudauditlogging -d \
    '{"spec":{"cloudauditlogging":{"allowlistedServiceAccounts":["SERVICE_ACCOUNT_EMAIL"]}}}'
```
- "code": "OK" を指定した "lifecycleState": "ENABLED" を含む機能仕様と、allowlistedServiceAccounts のサービスアカウントのリストが返された場合、このプロジェクトで許可されている既存のサービスアカウントが存在することを意味しています。クラスタ内でこのリストのサービスアカウントを使用するか、許可リストに新しいサービスアカウントを追加できます。
```
curl -X PATCH -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    -H "Content-Type: application/json" \
    https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features/cloudauditlogging?update_mask=spec.cloudauditlogging.allowlistedServiceAccounts -d \
    '{"spec":{"cloudauditlogging":{"allowlistedServiceAccounts":["SERVICE_ACCOUNT_EMAIL"]}}}'
```
- "code": "FAILED" を指定した "lifecycleState": "ENABLED" を含む機能仕様が返された場合は、権限の設定が失敗したことを意味します。レスポンスの description フィールドで問題を解決するか、現在の許可リストをバックアップして cloudauditlogging Hub 機能を削除し、このセクションのステップ 1 の手順で再度有効にします。cloudauditlogging Hub 機能は、次の方法で削除できます。
```
curl -X DELETE -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features/cloudauditlogging
```

上記のコマンドで:

PROJECT_ID は、クラスタの監査ロギングプロジェクトに置き換えます。
SERVICE_ACCOUNT_EMAIL は、クラスタの監査ロギングサービスアカウントのメールアドレスに置き換えます。

運用、セキュリティ

1.11

`gkectl diagnose` 証明書チェックの失敗

ワークステーションがユーザークラスタのワーカーノードにアクセスできない場合、gkectl diagnose の実行時に次のエラーが発生します。

Checking user cluster certificates...FAILURE
    Reason: 3 user cluster certificates error(s).
    Unhealthy Resources:
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out

ワークステーションが管理クラスタのワーカーノードまたは管理クラスタのワーカーノードにアクセスできない場合、gkectl diagnose を実行すると次のエラーが発生します。

Checking admin cluster certificates...FAILURE
    Reason: 3 admin cluster certificates error(s).
    Unhealthy Resources:
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out

回避策:

このメッセージは無視してかまいません。

オペレーティングシステム

1.8、1.9、1.10、1.11、1.12、1.13

`/var/log/audit/` が VM のディスク容量を占有している

/var/log/audit/ が監査ログでいっぱいになります。ディスクの使用量を確認するには、sudo du -h -d 1 /var/log/audit を実行します。

管理ワークステーションの特定の gkectl コマンド（gkectl diagnose snapshot など）は、ディスクの使用量に影響します。

Google Distributed Cloud v1.8 以降では、Ubuntu イメージが CIS レベル 2 のベンチマークで強化されています。コンプライアンスルールの一つである「4.1.2.2 監査ログが自動的に削除されないことを確認する」によって、auditd 設定 max_log_file_action = keep_logs が保証されます。これにより、すべての監査ルールがディスクに保持されます。

回避策:

回避策の手順を表示

管理ワークステーション

管理ワークステーションの場合、auditd の設定を手動で変更してログを自動的にローテーションしてから、auditd サービスを再起動できます。

sed -i 's/max_log_file_action = keep_logs/max_log_file_action = rotate/g' /etc/audit/auditd.conf sed -i 's/num_logs = .*/num_logs = 250/g' /etc/audit/auditd.conf systemctl restart auditd

前述の設定では、auditd が 250 個を超えるファイル（それぞれ 8M）を生成すると、auditd は自動的にログをローテーションします。

クラスタノード

クラスタノードの場合は、1.11.5+、1.12.4+、1.13.2+、または 1.14+ にアップグレードします。これらのバージョンにまだアップグレードできない場合は、次の DaemonSet をクラスタに適用します。
apiVersion: apps/v1 kind: DaemonSet metadata: name: change-auditd-log-action namespace: kube-system spec: selector: matchLabels: app: change-auditd-log-action template: metadata: labels: app: change-auditd-log-action spec: hostIPC: true hostPID: true containers: - name: update-audit-rule image: ubuntu command: ["chroot", "/host", "bash", "-c"] args: - | while true; do if $(grep -q "max_log_file_action = keep_logs" /etc/audit/auditd.conf); then echo "updating auditd max_log_file_action to rotate with a max of 250 files" sed -i 's/max_log_file_action = keep_logs/max_log_file_action = rotate/g' /etc/audit/auditd.conf sed -i 's/num_logs = .*/num_logs = 250/g' /etc/audit/auditd.conf echo "restarting auditd" systemctl restart auditd else echo "auditd setting is expected, skip update" fi sleep 600 done volumeMounts: - name: host mountPath: /host securityContext: privileged: true volumes: - name: host hostPath: path: /

この auditd 構成を変更すると、CIS レベル 2 のルール「4.1.2.2 監査ログが自動的に削除されないことを確認する」に違反するので、注意してください。

ネットワーキング

1.10、1.11.0～1.11.3、1.12.0～1.12.2、1.13.0

`NetworkGatewayGroup` フローティング IP がノードアドレスと競合する

次の検証 Webhook エラーのため、ユーザーが NetworkGatewayGroup オブジェクトを作成または更新できません。

[1] admission webhook "vnetworkgatewaygroup.kb.io" denied the request: NetworkGatewayGroup.networking.gke.io "default" is invalid: [Spec.FloatingIPs: Invalid value: "10.0.0.100": IP address conflicts with node address with name: "my-node-name"

影響を受けるバージョンでは、kubelet がノードに割り当てられたフローティング IP アドレスに誤ってバインドされ、node.status.addresses でノードアドレスとして報告される可能性があります。検証 Webhook は、NetworkGatewayGroup フローティング IP アドレスをクラスタ内のすべての node.status.addresses と照合し、競合とみなします。

回避策:

NetworkGatewayGroup オブジェクトの作成または更新が失敗しているクラスタで、ANG 検証 Webhook を一時的に無効にして変更内容を送信します。

最後に復元できるように Webhook 構成を保存します。

kubectl -n kube-system get validatingwebhookconfiguration \
    ang-validating-webhook-configuration -o yaml > webhook-config.yaml

Webhook 構成を編集します。

kubectl -n kube-system edit validatingwebhookconfiguration \
    ang-validating-webhook-configuration

Webhook 構成リストから vnetworkgatewaygroup.kb.io 項目を削除して終了し、変更を適用します。
NetworkGatewayGroup オブジェクトを作成または編集します。

元の Webhook 構成を再適用します。

kubectl -n kube-system apply -f webhook-config.yaml

インストール、アップグレード、更新

1.10.0～1.10.2

管理クラスタの作成またはアップグレードのタイムアウト

管理クラスタのアップグレード中に、管理コントロールプレーン VM の作成が停止することがあります。管理コントロールプレーン VM は起動時に無限待機ループに入り、/var/log/cloud-init-output.log ファイルに次のような無限ループエラーが表示されます。

+ echo 'waiting network configuration is applied'
waiting network configuration is applied
++ get-public-ip
+++ ip addr show dev ens192 scope global
+++ head -n 1
+++ grep -v 192.168.231.1
+++ grep -Eo 'inet ([0-9]{1,3}\.){3}[0-9]{1,3}'
+++ awk '{print $2}'
++ echo
+ '[' -n '' ']'
+ sleep 1
+ echo 'waiting network configuration is applied'
waiting network configuration is applied
++ get-public-ip
+++ ip addr show dev ens192 scope global
+++ grep -Eo 'inet ([0-9]{1,3}\.){3}[0-9]{1,3}'
+++ awk '{print $2}'
+++ grep -v 192.168.231.1
+++ head -n 1
++ echo
+ '[' -n '' ']'
+ sleep 1

これは、Google Distributed Cloud が起動スクリプトでノード IP アドレスを取得しようとすると、grep -v ADMIN_CONTROL_PLANE_VIP を使用して、NIC にも割り当て可能な管理クラスタコントロールプレーン VIP をスキップするためです。ただし、このコマンドは、コントロールプレーン VIP の接頭辞を持つ IP アドレスもスキップするため、起動スクリプトがハングアップします。

たとえば、管理クラスタのコントロールプレーン VIP が 192.168.1.25 であるとします。管理クラスタのコントロールプレーン VM の IP アドレスに同じ接頭辞（たとえば、192.168.1.254）がある場合、コントロールプレーン VM は作成中に停止します。この問題は、ブロードキャストアドレスにコントロールプレーン VIP と同じ接頭辞（192.168.1.255 など）がある場合にも発生する可能性があります。

回避策:

管理クラスタ作成のタイムアウトがブロードキャスト IP アドレスによるものである場合は、管理クラスタのコントロールプレーン VM で次のコマンドを実行します。
```
ip addr add ${ADMIN_CONTROL_PLANE_NODE_IP}/32 dev ens192
```
これにより、ブロードキャストアドレスなしで行を作成し、起動プロセスのブロックを解除します。起動スクリプトのブロックを解除したら、次のコマンドを実行して、追加された行を削除します。
```
ip addr del ${ADMIN_CONTROL_PLANE_NODE_IP}/32 dev ens192
```
ただし、管理クラスタ作成のタイムアウトがコントロールプレーン VM の IP アドレスによるものである場合は、起動スクリプトのブロックを解除できません。別の IP アドレスに切り替えて再作成するか、バージョン 1.10.3 以降にアップグレードします。

オペレーティングシステム、アップグレード、更新

1.10.0～1.10.2

COS イメージを使用した管理クラスタの状態が、管理クラスタのアップグレードまたは管理マスターの修復時に失われる

COS イメージを使用している場合、DataDisk は管理クラスタのマスターノードに正しくマウントされず、COS イメージを使用する管理クラスタの状態が、管理クラスタのアップグレードまたは管理マスターの修復時に失われます（COS イメージを使用した管理クラスタはプレビュー機能です）。

回避策:

osImageType を ubuntu_containerd に設定して管理クラスタを再作成します。

osImageType を cos に設定して管理クラスタを作成した後、管理クラスタの SSH 認証鍵を取得して、管理マスターノードに SSH 接続します。df -h の結果には /dev/sdb1 98G 209M 93G 1% /opt/data が含まれます。lsblk の結果には -sdb1 8:17 0 100G 0 part /opt/data が含まれます。

オペレーティングシステム

1.10

`.local` ドメインで systemd-resolved が DNS ルックアップに失敗する

Google Distributed Cloud バージョン 1.10.0 のデフォルトでは、Ubuntu の名前解決は 127.0.0.53 でリッスンするローカルの systemd-resolve にルーティングされます。これは、バージョン 1.10.0 で使用される Ubuntu 20.04 イメージで、/etc/resolv.conf が 127.0.0.53 localhost DNS スタブを指す /run/systemd/resolve/stub-resolv.conf にシンボリックリンクされているためです。

その結果、名前が検索ドメインとして指定されていない限り、localhost DNS 名前解決では、名前に .local 接尾辞のあるアップストリーム DNS サーバー（/run/systemd/resolve/resolv.conf で指定）の確認が拒否されます。

これにより、.local 名のルックアップはすべて失敗します。たとえば、ノードの起動時に、kubelet は .local 接尾辞の付いた非公開レジストリからのイメージの pull に失敗します。.local 接尾辞を持つ vCenter アドレスを指定しても、管理ワークステーションでは動作しません。

回避策:

クラスタノードのこの問題は、管理クラスタの構成ファイルとユーザークラスタの構成ファイルで searchDomainsForDNS フィールドを指定してドメインを含めると回避できます。

現在、gkectl update は searchDomainsForDNS フィールドの更新をまだサポートしていません。

したがって、このフィールドをクラスタの作成前に設定していない場合は、ノードに SSH で接続し、/etc/resolv.conf のシンボリックリンクを /run/systemd/resolve/stub-resolv.conf（127.0.0.53 ローカルスタブを含む）から /run/systemd/resolve/resolv.conf（実際のアップストリーム DNS を指す）に変更することでローカルの systemd-resolved スタブをバイパスする必要があります。

sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf

管理ワークステーションの場合、gkeadm では検索ドメインの指定がサポートされていないため、この問題を手動で回避する必要があります。

このソリューションは、VM の再作成では保持されません。VM が再作成されるたびに、この回避策をやり直す必要があります。

インストール、オペレーティングシステム

1.10

Docker ブリッジ IP が `172.17.0.1/16` ではなく `169.254.123.1/24` を使用する

Google Distributed Cloud は、--bip=169.254.123.1/24 を使用する Docker ブリッジの IP アドレス専用のサブネットを指定します。これにより、デフォルトの 172.17.0.1/16 サブネットは予約されません。ただし、バージョン 1.10.0 では、Ubuntu OS イメージにバグがあり、カスタマイズされた Docker 構成が無視されます。

その結果、Docker はデフォルトの 172.17.0.1/16 をブリッジ IP アドレスサブネットとして選択します。この IP アドレス範囲内にすでに実行中のワークロードがある場合、IP アドレスの競合が発生する可能性があります。

回避策:

この問題を回避するには、次の systemd 構成ファイルを dockerd 用に名前を変更した後、サービスを再起動する必要があります。

sudo mv /etc/systemd/system/docker.service.d/50-cloudimg-settings.cfg \
    /etc/systemd/system/docker.service.d/50-cloudimg-settings.conf

sudo systemctl daemon-reload

sudo systemctl restart docker

Docker が正しいブリッジ IP アドレスを選択していることを確認します。

ip a | grep docker0

注: VM を再作成すると、この解決策は無効になります。VM が再作成されるたびに、この回避策を実施し直す必要があります。

アップグレード、更新

1.11

Stackdriver の準備状況により 1.11 へのアップグレードがブロックされる

Google Distributed Cloud バージョン 1.11.0 では、ロギングとモニタリングに関連するカスタムリソースの定義が変更されています。

stackdriver カスタムリソースのグループ名が addons.sigs.k8s.io から addons.gke.io に変更されました。
monitoring および metricsserver カスタムリソースのグループ名が addons.k8s.io から addons.gke.io に変更されました。
上記のリソースの仕様では、そのスキーマに対する検証が開始します。特に、stackdriver カスタムリソースの resourceAttrOverride と storageSizeOverride の仕様では、CPU、メモリ、ストレージサイズのリクエストと上限の値に文字列型を設定する必要があります。

グループ名の変更は、Kubernetes 1.22 の CustomResourceDefinition の更新に準拠するために行われました。

影響を受けるカスタムリソースを適用または編集する追加のロジックがない場合、対応は必要ありません。Google Distributed Cloud のアップグレードプロセスでは、影響を受けるリソースの移行が行われ、グループ名の変更後も既存の仕様が保持されます。

ただし、影響を受けるリソースを適用または編集するロジックを実行する場合は、特別な注意が必要です。まず、マニフェストファイルで新しいグループ名を使用して参照する必要があります。例:

apiVersion: addons.gke.io/v1alpha1  ## instead of `addons.sigs.k8s.io/v1alpha1`
kind: Stackdriver

次に、resourceAttrOverride と storageSizeOverride の仕様の値が文字列型であることを確認します。例:

spec:
  resourceAttrOverride:
    stackdriver-log-forwarder/stackdriver-log-forwarder
      limits:
        cpu: 1000m # or "1"
        # cpu: 1 # integer value like this would not work 
        memory: 3000Mi

そうしないと、適用と編集が有効にならないため、ロギングとモニタリングのコンポーネントで予期しないステータスが発生する可能性があります。症状としては、次のものがあります。

onprem-user-cluster-controller の調整エラーログ。例:

potential reconciliation error: Apply bundle components failed, requeue after 10s, error: failed to apply addon components: failed to apply bundle objects from stackdriver-operator-addon 1.11.2-gke.53 to cluster my-cluster: failed to create typed live object: .spec.resourceAttrOverride.stackdriver-log-forwarder/stackdriver-log-forwarder.limits.cpu: expected string, got &value.valueUnstructured{Value:1}

kubectl edit stackdriver stackdriver の失敗。例:

Error from server (NotFound): stackdrivers.addons.gke.io "stackdriver" not found

上記のエラーが発生した場合は、アップグレード前に Stackdriver CR 仕様でサポートされていないタイプが存在していたことを意味します。回避策として、古いグループ名 kubectl edit stackdrivers.addons.sigs.k8s.io stackdriver の Stackdriver CR を手動で編集して、次の操作を行います。

リソースリクエストと上限を文字列型に変更します。
addons.gke.io/migrated-and-deprecated: true アノテーションが存在する場合は削除します。

その後、アップグレードプロセスを再開または再起動します。

オペレーティングシステム

1.7、1.8、1.9、1.10、1.11、1.12、1.13、1.14、1.15,、1.16

ホストの正常でないシャットダウンで VM が移行された場合、COS VM の IP が表示されない

ESXi サーバーに障害が発生したときに、サーバーで vCenter HA 機能が有効になっていると、障害のある ESXi サーバー内のすべての VM が vMotion をトリガーし、別の正常な ESXi サーバーに移行されます。移行された COS VM の IP は失われます。

回避策:

VM を再起動します。

ネットワーキング

1.14.7 より前のすべてのバージョン、1.15.0～1.15.3、1.16.0

Seesaw から送信された GARP 応答でターゲット IP が設定されていない

Seesaw が 20 秒ごとに送信する定期的な GARP（Gratuitous ARP）で、ARP ヘッダーにターゲット IP が設定されません。一部のネットワークは、このようなパケットを受け入れない場合があります（Cisco ACI など）。（VRRP パケットのドロップによる）スプリットブレインが復元された後、サービスが長く停止する可能性があります。

回避策:

いずれかの Seesaw VM で sudo seesaw -c failover を実行して、Seesaw フェイルオーバーをトリガーします。これによってトラフィックが復元されます。

オペレーティングシステム

1.16、1.28.0～1.28.200

Kubelet で、ワーカーノードに /etc/kubernetes/manifests が存在しないことを示すログが大量に表示される

ワーカーノードに staticPodPath が誤って設定されています。

回避策:

/etc/kubernetes/manifests フォルダを手動で作成します

さらにサポートが必要な場合は、Cloud カスタマーケアにお問い合わせください。

VMware 用 Google Distributed Cloud（ソフトウェアのみ）の既知の問題

Binary Authorization ウェブブックが CNI プラグインをブロックするため、nodepool の 1 つが起動しない

deletionTimestamp でミラーリングされたマシンが原因で CPV2 ユーザー クラスタのアップグレードが停止する

異なるサブネットにあるコントロール プレーン VIP が原因でクラスタの作成に失敗する

FQDN 以外の vCenter ユーザー名を使用すると、クラスタの作成またはアップグレードに失敗する

バージョン 1.10 以前で作成されたクラスタで、管理クラスタのアップグレードに失敗する

Dataplane V2 が有効になっているクラスタで、誤った警告メッセージが表示される

HA 管理クラスタのインストールのプリフライト チェックで、必要な静的 IP の数が正しく報告されない

管理クラスタを非 HA から HA に移行した後、Connect Agent が Google Cloud が接続できなくなる

Docker ブリッジ IP で COS クラスタのコントロール プレーン ノードに 172.17.0.1/16 が使用される

標準 CNI で複数のネットワーク インターフェースが機能しない

Netapp Trident の依存関係が vSphere CSI ドライバに干渉する

必要な構成を追加するときに、管理クラスタの Webhook によって更新がブロックされることがある

manualLB 仕様が空の場合、controlPlaneNodePort フィールドのデフォルトが 30968 になる

Ubuntu OS イメージに nfs-common がない

管理クラスタの構成テンプレートにストレージ ポリシー フィールドがない

Kubernetes Metadata API が VPC-SC に対応していない

管理クラスタと Controlplane V2 が有効になっているユーザー クラスタが異なる vSphere 認証情報を使用すると、clusterapi-controller がクラッシュすることがある

Prometheus Alert Manager に、etcd で失敗した GRPC リクエストが大量に表示される

接続時間の長い下り（外向き）NAT が切断される

証明書に署名するときに、CSR 署名者が spec.expirationSeconds を無視する

disable_bundled_ingress のユーザー クラスタのロードバランサの検証が失敗する

CA のローテーション後に管理クラスタの更新が失敗する

Pod の起動に失敗したため、CSI ワークロードのプリフライト チェックが失敗する

管理クラスタのバージョンが 1.15 の場合、ユーザー クラスタの更新がタイムアウトする

管理クラスタのバージョンが 1.15 の場合、ユーザー クラスタの作成がタイムアウトする

アドオン サービスのプロジェクトまたはロケーションが一致しない場合、管理クラスタの更新やアップグレードが失敗する

ユーザー管理の管理ワークステーションを使用している場合、ユーザー クラスタの削除に失敗する

外部サーバーの下り（外向き）NAT ゲートウェイ トラフィックが失敗する

常時有効なシークレット暗号化が有効になっていると、管理クラスタのアップグレードが失敗する

回避策

アップグレードの失敗を防ぐ

変更ブロック トラッキング（CBT）の使用時のディスクエラーとアタッチの失敗

複数のホストから共有ファイルに並列追加が行われると NFSv3 上のデータが破損する

kubelet と Kubernetes コントロール プレーンのバージョンの不一致

1 より大きいバージョンの CA を使用した管理クラスタのアップグレードまたは更新が失敗する

タイムアウトするまで非 HA Controlplane V2 クラスタの削除で停止する

バージョン 1.15 以降にアップグレードすると、in-tree PVC / PV に対して一定の CNS attachvolume タスクが毎分表示される

PVC に関する誤った警告

複数のキーが期限切れになると、サービス アカウント キーのローテーションが失敗する

ユーザー クラスタ コントローラが 1.16 にアップグレードされると、1.15 ユーザー マスター マシンが予期せず再作成される

ホスト名が IP ブロック ファイルにないと、プリフライト チェックが失敗する

非 HA 管理クラスタとコントロール プレーン v1 のユーザー クラスタを使用している場合、管理クラスタをアップグレードまたは更新するとボリューム マウントが失敗する

コントロール プレーン ノードの作成に失敗する

同じデータセンター内でホスト名が重複していると、クラスタのアップグレードまたは作成に失敗する

vSphere のユーザー名またはパスワードで $ と ` がサポートされない

同じ名前でノードを再作成した後に PVC 作成に失敗する

gkectl repair admin-master で kubeconfig unmarshall エラーが返される

ディスク容量不足により Seesaw VM が破損する

管理クラスタのアップグレードまたは更新後に、管理 SSH 公開鍵エラーが発生する

GKE On-Prem API に登録された管理クラスタのアップグレードに失敗することがある

登録済みの管理クラスタのリソース リンク アノテーションが保持されない

CoreDNS orderPolicy が認識されない

OnPremAdminCluster のステータスがチェックポイントと実際の CR の間で一致しない

調整プロセスにより、管理クラスタの管理証明書が変更される

優先度クラスがないため、Anthos Network Gateway コンポーネントが強制排除されるか、保留中になる

クラスタを gcloud に登録した後、管理クラスタのアップグレードが失敗する

gkectl diagnose snapshot --log-since が、クラスタノードで実行されている journalctl コマンドの期間を制限できない

gkectl prepare windows が失敗する

RootDistanceMaxSec 構成が ubuntu ノードに反映されない

osImageType フィールドが空のため、gkectl update admin が失敗する

Controlplane V2 のユーザー クラスタで SNI が動作しない

非公開レジストリのユーザー名に $ が含まれていると、管理コントロール プレーンのマシンを起動できない

管理クラスタの更新中に、サポートされていない変更に関する誤検出の警告が発生する

KSA 署名鍵のローテーション後にユーザー クラスタの更新が失敗する

Terraform がユーザー クラスタを削除したとき、F5 BIG-IP 仮想サーバーがクリーンアップされない

kind クラスタが docker.io からコンテナ イメージを pull する

ネットワークで重複する GARP リクエストが除外されていると、HA Controlplane V2 のユーザー クラスタと管理クラスタでフェイルオーバーが失敗する

vCenter 証明書のローテーション後に vsphere-csi-controller を再起動する必要がある

クラスタ登録でエラーが発生しても、管理クラスタの作成が失敗しない

管理クラスタのアップグレード中に管理クラスタの再登録がスキップされることがある

vCenter.dataDisk に関する誤ったエラー メッセージ

冗長な VM-Host アフィニティ ルールが原因でノードプールの作成が失敗する

failed to delete the admin master node object and reboot the admin master VM が原因で gkectl repair admin-master が失敗することがある

コントロール プレーン ノードの再作成または更新後に Pod が失敗状態のままになる

非公開レジストリの認証情報のため、OnPremUserCluster の準備ができていない

gkectl upgrade admin が StorageClass standard sets the parameter diskformat which is invalid for CSI Migration で失敗する

Windows ファイル システムを使用して移行された in-tree vSphere ボリュームが vSphere CSI ドライバで使用できない

gkectl update credentials vsphere --admin-cluster の後に vsphere-csi-secret が更新されない

gkectl update cluster で Cloud Audit Logs を有効にすると audit-proxy がクラッシュループする

`deletionTimestamp` でミラーリングされたマシンが原因で CPV2 ユーザークラスタのアップグレードが停止する

異なるサブネットにあるコントロールプレーン VIP が原因でクラスタの作成に失敗する

HA 管理クラスタのインストールのプリフライトチェックで、必要な静的 IP の数が正しく報告されない

Docker ブリッジ IP で COS クラスタのコントロールプレーンノードに 172.17.0.1/16 が使用される

標準 CNI で複数のネットワークインターフェースが機能しない

`manualLB` 仕様が空の場合、`controlPlaneNodePort` フィールドのデフォルトが 30968 になる

管理クラスタの構成テンプレートにストレージポリシーフィールドがない

管理クラスタと Controlplane V2 が有効になっているユーザークラスタが異なる vSphere 認証情報を使用すると、clusterapi-controller がクラッシュすることがある

証明書に署名するときに、CSR 署名者が `spec.expirationSeconds` を無視する

`disable_bundled_ingress` のユーザークラスタのロードバランサの検証が失敗する

Pod の起動に失敗したため、CSI ワークロードのプリフライトチェックが失敗する

管理クラスタのバージョンが 1.15 の場合、ユーザークラスタの更新がタイムアウトする

管理クラスタのバージョンが 1.15 の場合、ユーザークラスタの作成がタイムアウトする

アドオンサービスのプロジェクトまたはロケーションが一致しない場合、管理クラスタの更新やアップグレードが失敗する

ユーザー管理の管理ワークステーションを使用している場合、ユーザークラスタの削除に失敗する

外部サーバーの下り（外向き）NAT ゲートウェイトラフィックが失敗する

変更ブロックトラッキング（CBT）の使用時のディスクエラーとアタッチの失敗

kubelet と Kubernetes コントロールプレーンのバージョンの不一致

複数のキーが期限切れになると、サービスアカウントキーのローテーションが失敗する

ユーザークラスタコントローラが 1.16 にアップグレードされると、1.15 ユーザーマスターマシンが予期せず再作成される

ホスト名が IP ブロックファイルにないと、プリフライトチェックが失敗する

非 HA 管理クラスタとコントロールプレーン v1 のユーザークラスタを使用している場合、管理クラスタをアップグレードまたは更新するとボリュームマウントが失敗する

コントロールプレーンノードの作成に失敗する

vSphere のユーザー名またはパスワードで `$` と ` がサポートされない

登録済みの管理クラスタのリソースリンクアノテーションが保持されない

CoreDNS `orderPolicy` が認識されない

`gkectl diagnose snapshot --log-since` が、クラスタノードで実行されている `journalctl` コマンドの期間を制限できない

`gkectl prepare windows` が失敗する

`RootDistanceMaxSec` 構成が `ubuntu` ノードに反映されない

`osImageType` フィールドが空のため、`gkectl update admin` が失敗する

Controlplane V2 のユーザークラスタで SNI が動作しない

非公開レジストリのユーザー名に `$` が含まれていると、管理コントロールプレーンのマシンを起動できない

KSA 署名鍵のローテーション後にユーザークラスタの更新が失敗する

Terraform がユーザークラスタを削除したとき、F5 BIG-IP 仮想サーバーがクリーンアップされない

kind クラスタが `docker.io` からコンテナイメージを pull する

ネットワークで重複する GARP リクエストが除外されていると、HA Controlplane V2 のユーザークラスタと管理クラスタでフェイルオーバーが失敗する

vCenter 証明書のローテーション後に `vsphere-csi-controller` を再起動する必要がある

`vCenter.dataDisk` に関する誤ったエラーメッセージ

冗長な VM-Host アフィニティルールが原因でノードプールの作成が失敗する

`failed to delete the admin master node object and reboot the admin master VM` が原因で `gkectl repair admin-master` が失敗することがある

コントロールプレーンノードの再作成または更新後に Pod が失敗状態のままになる

`gkectl upgrade admin` が `StorageClass standard sets the parameter diskformat which is invalid for CSI Migration` で失敗する

Windows ファイルシステムを使用して移行された in-tree vSphere ボリュームが vSphere CSI ドライバで使用できない

`gkectl update credentials vsphere --admin-cluster` の後に `vsphere-csi-secret` が更新されない

`gkectl update cluster` で Cloud Audit Logs を有効にすると `audit-proxy` がクラッシュループする

`gkectl upgrade cluster` の直後に、追加のコントロールプレーンが再デプロイされる

`gke-connect-agent` で、レジストリ認証情報の更新後も引き続き古いイメージが使用される

GKE Identity Service が原因でコントロールプレーンのレイテンシが高くなる

ユーザークラスタコントロールプレーン Pod のヘルスチェックが実行されない

1.6 と 1.7 の管理クラスタをアップグレードすると、`k8s.gcr.io` から `registry.k8s.io` へのリダイレクトの影響を受ける可能性がある

Controlplane v2 を使用した Windows ノードで calico-typha または anetd-operator クラッシュループが発生する

ユーザークラスタの非公開レジストリの認証情報ファイルを読み込めない

Cloud Service Mesh と他のサービスメッシュが Dataplane v2 と互換性がない

`kube-controller-manager` が 6 分後に永続ボリュームを強制的に切断することがある

`gkectl repair admin-master` が、VM ハードウェアのバージョンをアップグレードせずに管理マスター VM を作成する

管理クラスタが 1.11.x からアップグレードされた後に、コンポーネントアクセスサービスアカウントキーが消去される

Controlplane V2 が有効になっていると、クラスタオートスケーラーが機能しない

IP ブロックファイルで CIDR を使用できない

admin-cluster.yaml の OS イメージタイプが、ユーザーコントロールプレーンのマシンが再作成される前に更新される

Calico CNI サービスアカウントの認証トークンの問題で Pod の作成エラーまたは削除エラーが発生する

gkectl update コマンドを使用して常時有効なシークレット暗号化機能が有効になっている場合、管理マスター VM を新しいブートディスク（たとえば`gkectl repair admin-master`）で再作成できない

最初のユーザークラスタを 1.9 から 1.10 にアップグレードすると、他のユーザークラスタのノードが再作成される

クラスタスナップショットの `system` シナリオに ClusterAPI オブジェクトがない

vSAN 環境でユーザークラスタを削除しているときに、ノードのドレインが停止する

ユーザークラスタを削除した後に、`Cluster Autoscaler` clusterrolebinding と clusterrole が削除される

ユーザークラスタを削除した後、管理クラスタの `cluster-health-controller` と `vsphere-metrics-exporter` が機能しない

`gkectl check-config` が OS イメージ検証で失敗する

アンチアフィニティグループの更新時に `gkectl update admin/cluster` が失敗する

ユーザーワーカーノードを再作成するには

ユーザーマスターノードを再作成するには

非公開レジストリの証明書バンドルが原因で、管理コントロールプレーンマシンの起動に失敗する

`NetworkGatewayNodes` marked unhealthy from concurrent status update conflict

競合状態により、更新中またはアップグレード中にマシンオブジェクトの削除がブロックされる

`gkectl` gkectl prepare の OS イメージ検証のプリフライトが失敗する

vCenter URL に `https://` または `http://` 接頭辞が含まれていると、クラスタの起動に失敗することがある

`util.CheckFileExists` で `gkectl prepare` がパニックする

`gkectl repair admin-master` と再開可能な管理アップグレードが連携しない

管理クラスタのアップグレードを再開すると、管理コントロールプレーンの VM テンプレートが削除される可能性がある

ClientConfig カスタムリソース

`gkectl check-config` 検証エラー: F5 BIG-IP パーティションが見つからない