既知の問題

Version 1.13 

• Version 1.28 (latest)
• Version 1.16
• Version 1.15
• Earlier versions (unsupported)

このドキュメントでは、Anthos clusters on VMware（GKE On-Prem）バージョン 1.13 に関する既知の問題について説明します。

/var/log/audit/ ディスク容量不足

Category

OS

識別されたバージョン

1.8.0+, 1.9.0+, 1.10.0+, 1.11.0+, 1.12.0+, 1.13.0+

現象

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

原因

Anthos v1.8 以降では、Ubuntu イメージが CIS レベル 2 のベンチマークで強化されています。また、コンプライアンス ルールの一つである 4.1.2.2 Ensure audit logs are not automatically deleted によって、auditd 設定 max_log_file_action = keep_logs が保証されています。これにより、すべての監査ルールがディスクに保持されます。

回避策

管理ワークステーション

管理ワークステーションの場合、auditd の設定を手動で変更してログを自動的にローテーションしてから、auditd サービスを再起動できます。

sed -i 's/max_log_file_action = keep_logs/max_log_file_action = rotate/g' /etc/audit/auditd.conf
sed -i 's/num_logs = .*/num_logs = 250/g' /etc/audit/auditd.conf
systemctl restart auditd

前述の設定では、監査ログが 250 個を超えるファイル（それぞれ 8M サイズ）を生成すると、auditd が自動的にログをローテーションします。

クラスタノード

クラスタノードの場合は、潜在的な問題を回避するために、次の 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 Ensure audit logs are not automatically deleted に違反しますので、注意してください。

NetworkGatewayGroup フローティング IP がノードアドレスと競合する

Category

ネットワーキング

識別されたバージョン

1.10.x、1.11.0-1.11.3、1.12.0-1.12.2、1.13.0

現象

次の検証 Webhook エラーのため、ユーザーは NetworkGatewayGroup オブジェクトを作成または更新できません。

[1] admission webhook "vnetworkgatewaygroup.kb.io" denied the request:
NetworkGatewayGroup.networking.gke.io "default" is invalid:
[Spec.FloatingIPs: Invalid value: "10.0.0.100": IP address conflicts with
node address with name: "my-node-name"

原因

影響を受けるバージョンでは、kubelet がノードに割り当てられたフローティング IP アドレスに誤ってバインドし、node.status.address 内のノードアドレスとして報告できます。検証 Webhook は、NetworkGatewayGroup フローティング IP アドレスをクラスタ内のすべての node.status.address に照らしてチェックし、競合とみなします。

回避策

NetworkGatewayGroup オブジェクトの作成または更新が失敗しているのと同じクラスタで、ANG 検証 Webhook を一時的に無効にして変更内容を送信します。

1. Webhook 構成を保存して、最後に復元できるようにします。

   kubectl -n kube-system get validatingwebhookconfiguration ang-validating-webhook-configuration -o yaml > webhook-config.yaml
   

2. Webhook 構成を編集します。

   kubectl -n kube-system edit validatingwebhookconfiguration ang-validating-webhook-configuration
   

3. Webhook 構成リストから vnetworkgatewaygroup.kb.io 項目を削除し、変更を適用するために閉じます。

4. NetworkGatewayGroup オブジェクトを作成または編集します。

5. 元の Webhook 構成を再適用します。

   kubectl -n kube-system apply -f webhook-config.yaml`
   

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

Category

ネットワーキング

識別されたバージョン

1.10.0+、1.11.0-1.11.3、1.12.0-1.12.2、1.13.0

現象

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

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

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

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

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

原因

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

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

回避策

該当する場合は、固定バージョンにアップグレードします。

競合状態では、更新やアップグレード中にマシン オブジェクトの削除がブロックされる

Category

アップグレード/更新

識別されたバージョン

1.12.0、1.12.1、1.12.2、1.13.0

現象

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

具体的には、gkectl コマンドがタイムアウトし、次のエラー メッセージが表示されます。

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

clusterapi-controller Pod ログでは、エラーは次のようになります。

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

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

原因

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

回避策

Google はこの問題に対して、環境と要件に応じてさまざまな緩和策を用意しています。

• オプション 1: アップグレードが最終的に完了するまで待つ

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

  この選択肢の優れている点は、お客様側で操作する必要がなく、ワークロードが中断されないことです。アップグレードが完了するまでの時間が長くなるだけです。

• オプション 2: 古いマシンのオブジェクトに自動修復のアノテーションを適用する

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

  デメリットは、マシン上の Pod がエビクションされずに直接削除されることです。つまり、PDB 構成が無視されるため、ワークロードのダウンタイムが発生する可能性があります。

  すべてのマシン名を取得するためのコマンド:

  kubectl --kubeconfig CLUSTER_KUBECONFIG get machines
  

  各マシンに自動修復アノテーションを適用するコマンド:

  kubectl annotate --kubeconfig CLUSTER_KUBECONFIG machine MACHINE_NAME onprem.cluster.gke.io/repair-machine=true
  

上記の問題が発生した場合に上記の緩和策がお試しになる場合は、サポートチームまでお問い合わせください。

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

Category

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

識別されたバージョン

1.10.2+、1.11、1.12、1.13

現象

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

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

原因

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

回避策

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

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

Category

インストール

識別されたバージョン

1.7.0+

現象

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

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 は Secret キーの一部として使用され、「/」や「:」はサポートされません。

回避策

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

util.CheckFileExists 上の gkectl prepare panic

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

gkectl repair admin-master と resumable admin upgrade が連携していない

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

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

バージョン 1.12.0 では、cgroup v2（統合）が Container Optimized OS（COS）ノードでデフォルトで有効になっています。これにより、COS クラスタ内のワークロードが不安定になる可能性があります。バージョン 1.12.1 では、cgroup v1（ハイブリッド）に戻ります。COS ノードを使用している場合は、リリースされたらすぐにバージョン 1.12.1 にアップグレードすることをおすすめします。

ClientConfig のカスタム リソース

gkectl update は、ClientConfig カスタム リソースに手動で加えた変更を元に戻します。毎回手動で変更した後に ClientConfig リソースをバックアップすることを強くおすすめします。

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

現象

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

考えられる原因

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

解決策

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

PodDisruptionBudgets を使用するワークロードが中断する

クラスタをアップグレードすると、PodDisruptionBudgets（PDB）を使用するワークロードで中断やダウンタイムが発生することがあります。

ノードがアップグレード プロセスを完了できない

追加の中断を許可できない PodDisruptionBudget オブジェクトが構成されている場合、ノードのアップグレードを繰り返し試行しても、コントロール プレーン バージョンへのアップグレードが失敗する可能性があります。このエラーを回避するには、Deployment または HorizontalPodAutoscaler をスケールアップして、PodDisruptionBudget 構成を維持しながらノードをドレインすることをおすすめします。

中断を許可しないすべての PodDisruptionBudget オブジェクトを表示するには、次を行います。

kubectl get poddisruptionbudget --all-namespaces -o jsonpath='{range .items[?(@.status.disruptionsAllowed==0)]}{.metadata.name}/{.metadata.namespace}{"\n"}{end}'

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

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

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

I0923 16:19:27.911174       1 leaderelection.go:278] failed to renew lease kube-system/cert-manager-cainjector-leader-election: timed out waiting for the condition
E0923 16:19:27.911110       1 leaderelection.go:321] error retrieving resource lock kube-system/cert-manager-cainjector-leader-election-core: Get "https://10.96.0.1:443/api/v1/namespaces/kube-system/configmaps/cert-manager-cainjector-leader-election-core": context deadline exceeded
I0923 16:19:27.911593       1 leaderelection.go:278] failed to renew lease kube-system/cert-manager-cainjector-leader-election-core: timed out waiting for the condition
E0923 16:19:27.911629       1 start.go:163] cert-manager/ca-injector "msg"="error running core-only manager" "error"="leader election lost"

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

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

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

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

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

cert-manager-cainjector デプロイに関連する yaml スニペットは ... apiVersion: apps/v1 kind: Deployment metadata: name: cert-manager-cainjector namespace: kube-system ... spec: ... template: ... spec: ... containers: - name: cert-manager image: "gcr.io/gke-on-prem-staging/cert-manager-cainjector:v1.0.3-gke.0" args: ... - --leader-elect=false ... のようになります。

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

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

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

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

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

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

注: アップグレード プロセスを開始したときに証明書の有効期限に関するエラーが表示された場合は、Google サポートにお問い合わせください。

注: このガイダンスは、管理クラスタ証明書の更新のみを対象としています。

管理クラスタの証明書の更新プロセス

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

2. KUBECONFIG 変数を設定します。

   KUBECONFIG=ABSOLUTE_PATH_ADMIN_CLUSTER_KUBECONFIG
   

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

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

   kubectl --kubeconfig "${KUBECONFIG}" get secrets -n kube-system sshkeys \
   -o jsonpath='{.data.vsphere_tmp}' | base64 -d > \
   ~/.ssh/admin-cluster.key && chmod 600 ~/.ssh/admin-cluster.key
   
   export MASTER_NODE_IP=$(kubectl --kubeconfig "${KUBECONFIG}" get nodes -o \
   jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}' \
   --selector='node-role.kubernetes.io/master')
   

4. 証明書が期限切れでないかを確認します。

   ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" \
   "sudo kubeadm alpha certs check-expiration"
   

   証明書が期限切れの場合は、管理クラスタをアップグレードする前に証明書を更新する必要があります。

5. 古い証明書をバックアップします。

   これは省略可能ですが、推奨される手順です。

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

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

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

7. 管理マスターノードを再起動します。

     # on admin master
     cd /etc/kubernetes
     sudo mkdir tempdir
     sudo mv manifests/*.yaml tempdir/
     sleep 5
     echo "remove pods"
     # ensure kubelet detect those change remove those pods
     # wait until the result of this command is empty
     sudo docker ps | grep kube-apiserver
   
     # ensure kubelet start those pods again
     echo "start pods again"
     sudo mv tempdir/*.yaml manifests/
     sleep 30
     # ensure kubelet start those pods again
     # should show some results
     sudo docker ps | grep -e kube-apiserver -e kube-controller-manager -e kube-scheduler -e etcd
   
     # clean up
     sudo rm -rf tempdir
   
     logout
    

8. 管理証明書が期限切れになった場合は管理クラスタの kubeconfig ファイルも期限切れになるため、有効期限が切れる前にこのファイルをバックアップする必要があります。

   • 管理クラスタの kubeconfig ファイルをバックアップします。

     ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" 
     
     "sudo cat /etc/kubernetes/admin.conf" > new_admin.conf
     vi "${KUBECONFIG}"
     

   • kubeconfig の client-certificate-data と client-key-data を作成した new_admin.conf ファイルの client-certificate-data と client-key-data に置き換えます。

9. 更新された証明書を検証し、kube-apiserver の証明書を検証します。

   • 証明書の有効期限を確認します。

     ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" 
     
     "sudo kubeadm alpha certs check-expiration"
     

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

     # Get the IP address of kube-apiserver
     cat $KUBECONFIG | grep server
     # Get the current kube-apiserver certificate
     openssl s_client -showcerts -connect : 
     
     | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'  
     
     > current-kube-apiserver.crt
     # check expiration date of this cert
     openssl x509 -in current-kube-apiserver.crt -noout -enddate
     

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

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

関連する govmomi のバグ: https://github.com/vmware/govmomi/issues/2552

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

1. The issue is fixed in vCenter versions 7.0U2 and above.

2. For lower versions:
Right-click the host, and then select Connection > Disconnect. Next, reconnect, which forces an update of the
VM's portgroup.

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

Anthos clusters on VMware バージョン 1.7.2 以降の場合、Ubuntu OS イメージは CIS L1 Server Benchmark で強化されています。CIS ルール「5.2.16 Ensure SSH Idle Timeout Interval is configured」を満たすために、/etc/ssh/sshd_config には次の設定が行われます。

ClientAliveInterval 300
ClientAliveCountMax 0

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

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

回避策として、次のいずれかを行います。

• SSH の切断時にコマンドが終了しないようにするには、nohup を使用します。

  nohup gkectl upgrade admin --config admin-cluster.yaml --kubeconfig kubeconfig
  

• ゼロ以外の ClientAliveCountMax 値を使用するように sshd_config を更新します。CIS ルールでは、3 未満の値を使用することが推奨されます。

  sudo sed -i 's/ClientAliveCountMax 0/ClientAliveCountMax 1/g' /etc/ssh/sshd_config
  sudo systemctl restart sshd
  

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

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

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

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

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

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

1. 使用しているバージョンの cert-manager をアンインストールします。独自のリソースを定義した場合は、バックアップすることをおすすめします。

2. アップグレードを実施します。

3. 独自の cert-manager を復元するには、次の手順を行います。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  relevant_fields='
  {
  apiVersion: .apiVersion,
  kind: .kind,
  metadata: {
  name: .metadata.name,
  namespace: "YOUR_INSTALLED_CERT_MANAGER_NAMESPACE"
  },
  spec: .spec
  }
  '
  f3=$(mktemp)
  f4=$(mktemp)
  kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG 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
   

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

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

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

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

• CVE-2019-16884
• CVE-2019-19921
• CVE-2020-15157
• CVE-2020-15257

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

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

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

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

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

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

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

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

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

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

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

ロギングとモニタリング

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

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

gcloud monitoring dashboards list > all-dashboard.json
# find deprecated metrics
cat all-dashboard.json | grep -E 'kube_daemonset_updated_number_scheduled|kube_node_status_allocatable_cpu_cores|kube_node_status_allocatable_pods|kube_node_status_capacity_cpu_cores'

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

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

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

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

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

3. 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 指標をすべて置換できます。

Cloud Monitoring で不明な指標データ

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

Unknown metric: kubernetes.io/anthos/go_gc_duration_seconds_summary_percentile

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

• apiserver_admission_step_admission_duration_seconds_summary
• go_gc_duration_seconds
• scheduler_scheduling_duration_seconds
• gkeconnect_http_request_duration_seconds_summary
• alertmanager_nflog_snapshot_duration_seconds_summary

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

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

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

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

この問題を解決するには、回避策として次の手順に沿って処理します。

• [バージョン 1.9.5 以降、1.10.2 以降、1.11.0]: 次の手順 1 ～ 4 に従って、gke-metrics-agent の CPU を増やします。

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

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

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

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

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

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

3. 変更を保存し、テキスト エディタを終了します。

4. 変更が有効になっていることを確認するには、次のコマンドを実行します。

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system get daemonset gke-metrics-agent -o yaml | grep "cpu: 50m"
   

   変更が有効になっている場合は、このコマンドで cpu: 50m が検出されます。

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

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

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

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

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

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

バージョン 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: code = 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: ""

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

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

2. 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 ファイルのパスに置き換えます。

3. 次のコマンドを実行して、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
   

4. --disable-upgrade-from-checkpoint フラグを使用して管理クラスタのアップグレードを再試行します。

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

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

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

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

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

• Anthos Identity Service（AIS）を無効にします。AIS を無効にしても、デプロイされた AIS バイナリや AIS ClientConfig は削除されません。AIS を無効にするには、次のコマンドを実行します。

  gcloud beta container hub identity-service disable --project PROJECT_NAME

  PROJECT_NAME は、クラスタのフリートホスト プロジェクトの名前に置き換えます。

• Connect Agent のバージョンをアップグレードするために、クラスタをバージョン 1.9.3 以降またはバージョン 1.10.1 以降に更新します。

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

Seesaw は DSR モードで動作します。デフォルトでは、データプレーン IP 学習が原因で Cisco ACI では機能しません。この問題を回避するには、Seesaw IP アドレスを Cisco Application Policy Infrastructure Controller（APIC）の L4-L7 仮想 IP として追加して、IP ラーニングを無効にします。

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

vSphere 7.0 Update 3 の問題

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

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

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

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

この問題が含まれているバージョン

1.10.x (x < 6), 1.11.x (x < 3), 1.12.0

説明

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)

問題を解決した後の予想される結果

/ # mount | grep test-volume /dev/sda1 on /test-volume type ext4 (rw,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.12.0、1.11.0-1.11.2、1.10.0-1.10.5 に影響します。

この問題は、回避方法として、対応するノードプールのマシンデプロイから cluster.x-k8s.io/cluster-api-autoscaler-node-group-max-size アノテーションと cluster.x-k8s.io/cluster-api-autoscaler-node-group-min-size アノテーションを削除して、修正できます。

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

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

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

バージョン 1.13 以降では、ノードが準備できても kubelet サーバー証明書の準備ができていない期間が少しあります。この 10 秒間は、kubectl exec と kubectl logs は使用できません。これは、新しいサーバー証明書の承認者がノードの更新された有効な IP を認識するのに時間がかかるためです。これは kubelet サーバー証明書にのみ影響し、Pod のスケジューリングには影響しません。