バージョン 1.8このバージョンは、Anthos バージョンサポートポリシーに記載されているようにサポートされており、Anthos clusters on VMware（GKE On-Prem）に影響を与えるセキュリティの脆弱性、露出、問題に関する最新のパッチとアップデートが提供されます。詳細については、リリースノートをご覧ください。これは最新バージョンではありません。

利用可能なバージョン: 1.11 1.10 1.9 以前のバージョン

既知の問題

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

/var/log/audit/ のディスク容量がいっぱいになる

識別されたバージョン

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 に違反しますので、注意してください。

「failed to register user cluster」が原因でユーザークラスタのアップグレード / 更新が失敗する

識別されたバージョン

1.7.0+、1.8.0+

現象

以下の場合、上述の gkectl コマンドがタイムアウトしたときに gkectl diagnose cluster を実行します。

GKE Connect を有効にしたユーザークラスタの 1.8 バージョンへのアップグレード。
GKE Connect を有効にした 1.8 バージョンのユーザークラスタで gkectl update cluster を実行する。
gkectl update cluster を実行して 1.8 バージョンのユーザークラスタで GKE Connect を有効にする。

$ gkectl diagnose cluster --kubeconfig kubeconfig --cluster-name foo-cluster
…
    Unhealthy Resources:
      OnPremUserCluster foo-cluster: not ready: ready condition is not true: ClusterCreateOrUpdate: failed to register user cluster "foo-cluster": failed to register cluster: ...
...

なお、GKE Connect の機能には影響がないはずです。つまり、コマンドの前に GKE Connect が機能していた場合、機能の継続が想定されます。

原因

1.8 バージョンで使用されている Connect Agent バージョン 20210514-00-00 はサポートが終了しています。

回避策

この問題を緩和するには、Google サポートにお問い合わせください。

Ubuntu ノードで再起動後に systemd-timesyncd が実行されない

識別されたバージョン

1.7.1-1.7.5、1.8.0-1.8.4、1.9.0+

現象

systemctl status systemd-timesyncd は、サービスが期限切れであることを示します。

● systemd-timesyncd.service - Network Time Synchronization
Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
Active: inactive (dead)

その結果、同期のタイムアウトの問題が発生する可能性があります。

原因

chrony が Ubuntu OS イメージに誤ってインストールされ、chrony と systemd-timesyncd の競合が発生しました。競合が発生すると、Ubuntu VM が再起動するたびに systemd-timesyncd が非アクティブになり、chrony がアクティブになります。ただし、systemd-timesyncd は VM のデフォルトの ntp クライアントである必要があります。

回避策

オプション 1: VM が再起動されるたびに手動で restart systemd-timesyncd を実行します。

オプション 2: 次の Daemonset をデプロイして、systemd-timesyncd が機能不能になった場合に常に再起動されるようにします。

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: ensure-systemd-timesyncd
spec:
  selector:
    matchLabels:
      name: ensure-systemd-timesyncd
  template:
    metadata:
      labels:
        name: ensure-systemd-timesyncd
    spec:
      hostIPC: true
      hostPID: true
      containers:
      - name: ensure-systemd-timesyncd
        # Use your preferred image.
        image: ubuntu
        command:
        - /bin/bash
        - -c
        - |
          while true; do
            echo $(date -u)
            echo "Checking systemd-timesyncd status..."
            chroot /host systemctl status systemd-timesyncd
            if (( $? != 0 )) ; then
              echo "Restarting systemd-timesyncd..."
              chroot /host systemctl start systemd-timesyncd
            else
              echo "systemd-timesyncd is running."
            fi;
            sleep 60
          done
        volumeMounts:
        - name: host
          mountPath: /host
        resources:
          requests:
            memory: "10Mi"
            cpu: "10m"
        securityContext:
          privileged: true
      volumes:
      - name: host
        hostPath:
          path: /
````

## ClientConfig custom resource

`gkectl update` reverts any manual changes that you have made to the ClientConfig
custom resource. We strongly recommend that you back up the ClientConfig
resource after every manual change.

## gkectl check-config</code> validation fails: can't find F5 BIG-IP partitions

<dl>
<dt>Symptoms</dt>
<dd><p>Validation fails because F5 BIG-IP partitions can't be found, even though they exist.</p></dd>
<dt>Potential causes</dt>
<dd><p>An issue with the F5 BIG-IP API can cause validation to fail.</p></dd>
<dt>Resolution</dt>
<dd><p>Try running <code>gkectl check-config</code> again.</p></dd>
</dl>

## Disruption for workloads with PodDisruptionBudgets {:#workloads_pdbs_disruption}

Upgrading clusters can cause disruption or downtime for workloads that use
[PodDisruptionBudgets](https://kubernetes.io/docs/concepts/workloads/pods/disruptions/){:.external}
(PDBs).

## Nodes fail to complete their upgrade process

If you have `PodDisruptionBudget` objects configured that are unable to
allow any additional disruptions, node upgrades might fail to upgrade to the
control plane version after repeated attempts. To prevent this failure, we
recommend that you scale up the `Deployment` or `HorizontalPodAutoscaler` to
allow the node to drain while still respecting the `PodDisruptionBudget`
configuration.

To see all `PodDisruptionBudget` objects that do not allow any disruptions:

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

Anthos 1.8.2 と 1.8.3 での cert-manager/ca-injector のリーダー選出の問題が原因で、ユーザークラスタのインストールが失敗しました。

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

  kubectl logs --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system deployments/cert-manager-cainjector

は次のログのようなものを作成する場合があります。

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-cainjector Deployment への変更が元に戻されないようにします。

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

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

# Ensure that we run only 1 cainjector replica, even during rolling updates.
kubectl patch --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system deployment cert-manager-cainjector --type=strategic --patch '
spec:
  strategy:
    rollingUpdate:
      maxSurge: 0
'
# Add a command line flag for cainjector: `--leader-elect=false`
kubectl patch --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system deployment cert-manager-cainjector --type=json --patch '[
    {
        "op": "add",
        "path": "/spec/template/spec/containers/0/args/-",
        "value": "--leader-elect=false"
    }
]'

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

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

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

1.8.4 以降（または 1.9 にアップグレードする場合は 1.9.1 以降）にアップグレードした後は、Anthos がcainjectorのリーダー選出を無効にするため、これらの手順は不要になります。それまでの間、各アップグレード中にこの問題に直面した場合は、同じ緩和手順を再度行う必要があります。

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

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

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

開始する前に、管理ワークステーションに OpenSSL がインストールされていることを確認してください。
KUBECONFIG 変数を設定します。
```
KUBECONFIG=ABSOLUTE_PATH_ADMIN_CLUSTER_KUBECONFIG
```
ABSOLUTE_PATH_ADMIN_CLUSTER_KUBECONFIG は、管理クラスタの kubeconfig ファイルの絶対パスに置き換えます。

管理マスターノードの 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')

証明書が期限切れでないかを確認します。
```
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" \
"sudo kubeadm alpha certs check-expiration"
```
証明書が期限切れの場合は、管理クラスタをアップグレードする前に証明書を更新する必要があります。
管理証明書が期限切れになった場合は管理クラスタの 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 に置き換えます。

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

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

# ssh into admin master if you didn't in the previous step
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 .

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

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

管理マスターノードで実行されている静的 Pod を再起動します。

  # 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

管理クラスタワーカーノードの証明書を更新する

ノード証明書の有効期限を確認する

    kubectl get nodes -o wide
    # find the oldest node, fill NODE_IP with the internal ip of that node
    ssh -i ~/.ssh/admin-cluster.key ubuntu@"${NODE_IP}"
    openssl x509 -enddate -noout -in /var/lib/kubelet/pki/kubelet-client-current.pem
    logout

証明書の有効期限が近づいている場合は、手動によるノードの修復でノード証明書を更新します。

更新された証明書を検証し、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

/etc/cron.daily/aide スクリプトでは /run のすべての容量が使用されるため、Pod でクラッシュループが発生します

Anthos clusters on VMware 1.7.2 以降では、Ubuntu OS イメージが CIS L1 Server Benchmark で強化されています。. そのため、cron スクリプト /etc/cron.daily/aide がインストールされ、CIS L1 サーバールールの「1.4.2 ファイルシステムの整合性が確保されていることを定期的に確認する」を実施する AIDE チェックがスケジュール設定されます。

このスクリプトは、cron ログを保存するために /run/aide を一時ディレクトリとして使用し、時間の経過とともに /run のすべての領域を使用する可能性があります。この問題の回避策については、/etc/cron.Daily/aide スクリプトが /run のすべての領域を使用するをご覧ください。

1 つ以上の Pod がノードでクラッシュを繰り返す場合は、そのノードで df -h /run を実行します。コマンド出力で 100% のスペース使用量が示される場合は、この問題が発生している可能性があります。

この問題は、バージョン 1.8.1 で修正されています。1.7.2 と 1.8.0 のバージョンの場合は、次の 2 つの回避策のいずれかでこの問題を手動で解決できます。

/run/aide/cron.daily.old* のログファイルを定期的に削除する（推奨）。
/etc/cron.Daily/aide スクリプトが /run のすべての領域を使用するの手順をご覧ください。（注: この回避策は、ノードのコンプライアンスの状態に影響を与える可能性があります）。

バージョン 1.8.0 で Seesaw ロードバランサをアップグレードする

gkectl upgrade loadbalancer を使用して、バージョン 1.8.0 の Seesaw ロードバランサの一部のパラメータを更新しようとすると、DHCP または IPAM モードでは動作しません。セットアップにこの構成が含まれている場合は、バージョン 1.8.0 にアップグレードするのではなく、バージョン 1.8.1 以降にアップグレードしてください。

パスワードの有効期限の問題により、管理ワークステーションにログインできません

この問題は、Anthos clusters on VMware で次のいずれかのバージョンを使用している場合に発生することがあります。

1.7.2-gke.2
1.7.3-gke.2
1.8.0-gke.21
1.8.0-gke.24
1.8.0-gke.25
1.8.1-gke.7
1.8.2-gke.8

管理ワークステーション、クラスタノード、Seesaw ノードなどの Anthos VM に SSH で接続しようとすると、次のエラーが発生することがあります。

WARNING: Your password has expired.

このエラーは、VM の ubuntu ユーザーパスワードが期限切れになっていることにより発生します。VM にログインする前に、ユーザーパスワードの有効期限を、手動で大きな値にリセットする必要があります。

パスワードの有効期限エラーの予防策

上記の影響を受けるバージョンを実行していて、ユーザーパスワードがまだ期限切れになっていない場合は、SSH エラーが表示される前に有効期限を延長する必要があります。

各 Anthos VM で次のコマンドを実行します。

sudo chage -M 99999 ubuntu

パスワード有効期限エラーの緩和策

ユーザーパスワードがすでに期限切れになっていて、VM にログインして有効期限を延長できない場合は、各コンポーネントで次の緩和手順を行います。

管理ワークステーション

一時 VM を使用して次の手順を行います。1.7.1-gke.4 バージョンを使用して管理ワークステーションを作成し、一時 VM として使用できます。

一時 VM と管理ワークステーションがパワーオフ状態にあることを確認します。
管理ワークステーションのブートディスクを一時 VM にアタッチします。このブートディスクは「Hard disk 1」というラベルが付いたディスクです。
これらのコマンドを実行して、VM 内にブートディスクをマウントします。dev/sdc1 は自分のブートディスク ID に置き換えてください。
```
sudo mkdir -p /mnt/boot-disk
sudo mount /dev/sdc1 /mnt/boot-disk
```
ubuntu ユーザーの有効期限に、99999 日などの大きな値を設定します。
```
sudo chroot /mnt/boot-disk chage -M 99999 ubuntu
```
一時 VM をシャットダウンします。
管理ワークステーションをパワーオンします。通常どおり SSH で接続できるはずです。
クリーンアップとして、一時 VM を削除します。

管理クラスタのコントロールプレーン VM

手順に沿って、管理クラスタコントロールプレーン VM を再作成します。

管理クラスタのアドオン VM

管理ワークステーションから次のコマンドを実行して、VM を再作成します。

  kubectl --kubeconfig=ADMIN_CLUSTER_KUBECONFIG patch machinedeployment gke-admin-node --type=json -p="[{'op': 'add', 'path': '/spec/template/spec/metadata/annotations', 'value': {"kubectl.kubernetes.io/restartedAt": "version1"}}]"

このコマンドを実行したら、管理クラスタアドオン VM が再作成を完了し、準備が整うのを待ってから、次の手順に進みます。

ユーザークラスタのコントロールプレーン VM

管理ワークステーションから次のコマンドを実行して、VM を再作成します。

usermaster=`kubectl --kubeconfig=ADMIN_CLUSTER_KUBECONFIG get machinedeployments -l set=user-master -o name` && kubectl --kubeconfig=ADMIN_CLUSTER_KUBECONFIG patch $usermaster --type=json -p="[{'op': 'add', 'path': '/spec/template/spec/metadata/annotations', 'value': {"kubectl.kubernetes.io/restartedAt": "version1"}}]"

このコマンドの実行後、ユーザークラスタコントロールプレーン VM が再作成を完了して準備が整うのを待ってから、次の手順に進みます。

ユーザークラスタのワーカー VM

管理ワークステーションから次のコマンドを実行して、VM を再作成します。

for md in `kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG get machinedeployments -l set=node -o name`; do kubectl patch --kubeconfig=USER_CLUSTER_KUBECONFIG $md --type=json -p="[{'op': 'add', 'path': '/spec/template/spec/metadata/annotations', 'value': {"kubectl.kubernetes.io/restartedAt": "version1"}}]"; done

Seesaw VM

管理ワークステーションから次のコマンドを実行して、Seesaw VM を再作成します。多少のダウンタイムが発生します。ロードバランサで HA が有効になっている場合、ダウンタイムは最大 2 秒です。

gkectl upgrade loadbalancer --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG --admin-cluster --no-diff
gkectl upgrade loadbalancer --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG --no-diff

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

`gkectl create-config admin` と `gkectl create-config cluster` のパニック

バージョン 1.8.0～1.8.3 では、gkectl create-config admin/cluster コマンドがメッセージ panic: invalid version: "latest" でパニックします。

この問題を回避するには、gkectl create-config admin/cluster --gke-on-prem-version=DESIRED_CLUSTER_VERSION を使用します。DESIRED_CLUSTER_VERSION は、目的のバージョン（1.8.2-gke.8 など）で置き換えます。

管理クラスタのタイムアウトの作成/アップグレード

この問題は、1.8.0 から 1.8.3 に影響します。

管理クラスタの作成または管理クラスタのアップグレードが、次のエラーでタイムアウトする場合があります。

Error getting kubeconfig: error running remote command 'sudo cat /etc/kubernetes/admin.conf': error: Process exited with status 1, stderr: 'cat: /etc/kubernetes/admin.conf: No such file or directory

この場合はさらに、外部クラスタスナップショットの nodes/ADMIN_MASTER_NODE/files/var/log/startup.log のログは、次のメッセージで終了します。

[preflight] You can also perform this action in beforehand using 'kubeadm config images pull'

このエラーは、管理コントロールプレーン VM とコンテナレジストリの間でネットワークが遅い場合に発生します。レイテンシを短縮して帯域幅を増やすには、ネットワークまたはプロキシの設定を確認してください。

リモートホストによって切断された 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 セッションの再接続を確認してください。

バージョン 1.8.2 以降にアップグレードすると `cert-manager` と競合する

Anthos clusters on VMware を使用して独自の cert-manager をインストールしている場合、バージョン 1.8.2 以降にアップグレードしようとすると、障害が発生する可能性があります。これは、cert-manager 名前空間にインストールされている cert-manager のバージョンと monitoring-operator バージョンの間の競合の結果です。

VMware バージョン 1.8.2 以降の Anthos クラスタにアップグレードした後に cert-manager の別のコピーをインストールしようとすると、monitoring-operator によって管理されている既存のコピーとの競合により、インストールが失敗する可能性があります。

コントロールプレーンとオブザーバビリティコンポーネントが証明書のシークレットの作成とローテーションに依存する metrics-ca クラスタの発行元では、クラスタリソースの名前空間に metrics-ca 証明書のシークレットを保存する必要があります。この名前空間は、モニタリングオペレーターのインストールでは kube-system であり、独自のインストールでは cert-manager の可能性があります。

インストールに失敗した場合は、次の手順に沿ってバージョン 1.8.2 以降に正しくアップグレードしてください。

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

使用しているバージョンの cert-manager をアンインストールします。独自のリソースを定義した場合は、バックアップすることをおすすめします。
アップグレードを実施します。
独自の cert-manager を復元するには、次の手順を行います。

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

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

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

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

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

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

metrics-ca cert-manager.io/v1 証明書と metrics-pki.cluster.local Issuer リソースを kube-system から、インストールした cert-manager のクラスタリソース名前空間にコピーします。上流のデフォルト cert-manager インストールを使用している場合、インストールされている 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 kube-system metrics-pki.cluster.local -o json | jq "${relevant_fields}" > $f1
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get certificate -n kube-system 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 kube-system scale deployment cert-manager --replicas=0
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system scale deployment cert-manager-cainjector --replicas=0
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system scale deployment cert-manager-webhook --replicas=0

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

relevant_fields='
{
apiVersion: .apiVersion,
kind: .kind,
metadata: {
name: .metadata.name,
namespace: "YOUR_INSTALLED_CERT_MANAGER_NAMESPACE"
},
spec: .spec
}
'
f3=$(mktemp)
f4=$(mktemp)
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get issuer -n kube-system metrics-pki.cluster.local -o json | jq "${relevant_fields}" > $f3
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get certificate -n kube-system 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 の修正については、リリースノートをご覧ください。

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

`/etc/cron.daily/aide` CPU とメモリの急増に関する問題

Anthos clusters on VMware バージョン 1.7.2 以降では、Ubuntu OS イメージが CIS L1 Server Benchmark で強化されています。

そのため、cron スクリプト /etc/cron.daily/aide がインストールされ、CIS L1 サーバールールの「1.4.2 ファイルシステムの整合性が確保されていることを定期的に確認する」を実施する aide チェックがスケジュール設定されます。

cron ジョブは、毎日午前 6 時 25 分（UTC）に実行されます。ファイルシステム上のファイルの数によっては、この aide プロセスが原因で、CPU とメモリの使用量が急増することがあります。

急増がワークロードに影響を与える場合は、毎日の cron ジョブを無効にできます。

`sudo chmod -x /etc/cron.daily/aide`.

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 エンドポイントのフラッピングが発生します。

サービスアカウントの署名なしトークンが長すぎると、Seesaw ロードバランサのログが破損する場合がある

ロギングモニタリングのサービスアカウントの署名なしトークンが 512 KB を超えると、Seesaw ロードバランサログが破損する可能性があります。この問題を解決するには、バージョン 1.9 以降にアップグレードしてください。

ソフトウェアのデッドロックが発生した `anetd` デーモンが原因の、Pod 間の接続の問題

enableDataplaneV2 が true に設定されたクラスタでは、anetd デーモン（Daemonset として実行）がソフトウェアのデッドロックに陥るため、Pod 間の接続の問題が発生する可能性があります。この状態では、anetd デーモンは古いノード（以前に削除されたノード）をピアとして認識し、新しいピアとして新しく追加されたノードを見逃します。

この問題が発生した場合は、次の手順に従って anetd デーモンを再起動し、ピアノードを更新して、接続を復元する必要があります。

クラスタ内のすべての anetd デーモンを検索します。

kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG -n kube-system get pods -o wide | grep anetd

anetd デーモンが古いピアを認識しているかどうかを確認する。
```
kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG -n kube-system exec -it ANETD_XYZ -- cilium-health status
```
ANETD_XYZ は、anetd Pod の名前に置き換えます。

影響を受けるすべての Pod を再起動します。

kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG -n kube-system delete pod ANETD_XYZ

証明書エラーをチェックする gkectl 診断

ワークステーションがユーザークラスタのワーカーノードにアクセスできない場合、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

既知の問題

/var/log/audit/ のディスク容量がいっぱいになる

Category

識別されたバージョン

現象

原因

回避策

管理ワークステーション

クラスタノード

「failed to register user cluster」が原因でユーザー クラスタのアップグレード / 更新が失敗する

Category

識別されたバージョン

現象

原因

回避策

Ubuntu ノードで再起動後に systemd-timesyncd が実行されない

Category

識別されたバージョン

現象

原因

回避策

Anthos 1.8.2 と 1.8.3 での cert-manager/ca-injector のリーダー選出の問題が原因で、ユーザー クラスタのインストールが失敗しました。

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

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

/etc/cron.daily/aide スクリプトでは /run のすべての容量が使用されるため、Pod でクラッシュ ループが発生します

バージョン 1.8.0 で Seesaw ロードバランサをアップグレードする

パスワードの有効期限の問題により、管理ワークステーションにログインできません

パスワードの有効期限エラーの予防策

パスワード有効期限エラーの緩和策

管理ワークステーション

管理クラスタのコントロール プレーン VM

管理クラスタのアドオン VM

ユーザー クラスタのコントロール プレーン VM

ユーザー クラスタのワーカー VM

Seesaw VM

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

gkectl create-config admin と gkectl create-config cluster のパニック

管理クラスタのタイムアウトの作成/アップグレード

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

バージョン 1.8.2 以降にアップグレードすると cert-manager と競合する

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

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

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

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

/etc/cron.daily/aide CPU とメモリの急増に関する問題

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

サービス アカウントの署名なしトークンが長すぎると、Seesaw ロードバランサのログが破損する場合がある

ソフトウェアのデッドロックが発生した anetd デーモンが原因の、Pod 間の接続の問題

証明書エラーをチェックする gkectl 診断

「failed to register user cluster」が原因でユーザークラスタのアップグレード / 更新が失敗する

Anthos 1.8.2 と 1.8.3 での cert-manager/ca-injector のリーダー選出の問題が原因で、ユーザークラスタのインストールが失敗しました。

/etc/cron.daily/aide スクリプトでは /run のすべての容量が使用されるため、Pod でクラッシュループが発生します

管理クラスタのコントロールプレーン VM

ユーザークラスタのコントロールプレーン VM

ユーザークラスタのワーカー VM

`gkectl create-config admin` と `gkectl create-config cluster` のパニック

バージョン 1.8.2 以降にアップグレードすると `cert-manager` と競合する

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

`/etc/cron.daily/aide` CPU とメモリの急増に関する問題

サービスアカウントの署名なしトークンが長すぎると、Seesaw ロードバランサのログが破損する場合がある

ソフトウェアのデッドロックが発生した `anetd` デーモンが原因の、Pod 間の接続の問題