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

利用可能なバージョン

既知の問題

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

「GCP への登録に失敗しました」という理由で、ユーザークラスタのアップグレードが失敗する

識別されたバージョン

1.7.0+、1.8.0+

現象

ユーザークラスタを 1.7 バージョンにアップグレードすると、コマンド gkectl upgrade cluster は失敗し、次のようなエラーメッセージが表示されます。

$ gkectl upgrade cluster --kubeconfig kubeconfig --config user-cluster.yaml
…
Upgrading to bundle version: "1.7.1-gke.4"
…
Exit with error:

failed to register to GCP, gcloud output: , error: error running command 'gcloud alpha container hub memberships register foo-cluster --kubeconfig kubeconfig --context cluster --version 20210129-01-00  --enable-workload-identity --has-private-issuer --verbosity=error --quiet': error: exit status 1, stderr: 'Waiting for membership to be created...

このエラーは、Connect Agent がアップグレードされていないことを除いて、ユーザークラスタのアップグレードがほぼ完了していることを意味します。ただし、GKE 接続の機能性に影響はありません。

原因

1.7 バージョンで使用されている Connect Agent バージョン 20210129-01-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.

## `kubectl describe CSINode` and `gkectl diagnose snapshot`

`kubectl describe CSINode` and `gkectl diagnose snapshot` sometimes fail due to
the
[OSS Kubernetes issue](https://github.com/kubernetes/kubectl/issues/848){:.external}
on dereferencing nil pointer fields.

## OIDC and the CA certificate

The OIDC provider doesn't use the common CA by default. You must explicitly
supply the CA certificate.

Upgrading the admin cluster from 1.5 to 1.6.0 breaks 1.5 user clusters that use
an OIDC provider and have no value for `authentication.oidc.capath` in the
[user cluster configuration file](/anthos/clusters/docs/on-prem/1.7/how-to/user-cluster-configuration-file).

To work around this issue, run the following script:

<section><pre class="devsite-click-to-copy">
USER_CLUSTER_KUBECONFIG=<var class="edit">YOUR_USER_CLUSTER_KUBECONFIG</var>

IDENTITY_PROVIDER=<var class="edit">YOUR_OIDC_PROVIDER_ADDRESS</var>

openssl s_client -showcerts -verify 5 -connect $IDENTITY_PROVIDER:443 < /dev/null | awk '/BEGIN CERTIFICATE/,/END CERTIFICATE/{ if(/BEGIN CERTIFICATE/){i++}; out="tmpcert"i".pem"; print >out}'

ROOT_CA_ISSUED_CERT=$(ls tmpcert*.pem | tail -1)

ROOT_CA_CERT="/etc/ssl/certs/$(openssl x509 -in $ROOT_CA_ISSUED_CERT -noout -issuer_hash).0"

cat tmpcert*.pem $ROOT_CA_CERT > certchain.pem CERT=$(echo $(base64 certchain.pem) | sed 's\ \\g') rm tmpcert1.pem tmpcert2.pem

kubectl --kubeconfig $USER_CLUSTER_KUBECONFIG patch clientconfig default -n kube-public --type json -p "[{ \"op\": \"replace\", \"path\": \"/spec/authentication/0/oidc/certificateAuthorityData\", \"value\":\"${CERT}\"}]"
</pre></section>

Replace the following:

* <var>YOUR_OIDC_IDENTITY_PROVICER</var>: The address of your OIDC provider:

* <var>YOUR_YOUR_USER_CLUSTER_KUBECONFIG</var>: The path of your user cluster
  kubeconfig file.

## 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}' ```

Log Forwarder が過剰な数の OAuth 2.0 リクエストを行う

VMware の Anthos クラスタ、バージョン 1.7.1 では、過剰な OAuth 2.0 リクエストを実行することで Log Forwarder がメモリを消費する問題が発生する可能性があります。回避策として、stackdriver-operator バージョンをダウングレードし、ディスクをクリーンアップして、Log Forwarder を再起動します。

ステップ 0: 必要に応じてイメージを非公開レジストリにダウンロードする

非公開レジストリを使用する場合は、次の手順でこれらのイメージを非公開レジストリにダウンロードしてから、先に進んでください。非公開レジストリを使用しない場合は、このステップを省略します。

PRIVATE_REGISTRY_HOST を、非公開 Docker レジストリのホスト名または IP アドレスに置き換えます。

stackdriver-operator

docker pull gcr.io/gke-on-prem-release/stackdriver-operator:v0.0.440

docker tag gcr.io/gke-on-prem-release/stackdriver-operator:v0.0.440 \
    PRIVATE_REGISTRY_HOST/stackdriver-operator:v0.0.440

docker push PRIVATE_REGISTRY_HOST/stackdriver-operator:v0.0.440

fluent-bit

docker pull gcr.io/gke-on-prem-release/fluent-bit:v1.6.10-gke.3

docker tag gcr.io/gke-on-prem-release/fluent-bit:v1.6.10-gke.3 \
    PRIVATE_REGISTRY_HOST/fluent-bit:v1.6.10-gke.3

docker push PRIVATE_REGISTRY_HOST/fluent-bit:v1.6.10-gke.3

prometheus

docker pull gcr.io/gke-on-prem-release/prometheus:2.18.1-gke.0

docker tag gcr.io/gke-on-prem-release/prometheus:2.18.1-gke.0 \
    PRIVATE_REGISTRY_HOST/prometheus:2.18.1-gke.0

docker push PRIVATE_REGISTRY_HOST/prometheus:2.18.1-gke.0

ステップ 1: stackdriver-operator のバージョンをダウングレードする

stackdriver-operator のバージョンは、次のコマンドを実行してダウングレードします。

kubectl  --kubeconfig [CLUSTER_KUBECONFIG] -n kube-system patch deployment stackdriver-operator -p \
  '{"spec":{"template":{"spec":{"containers":[{"name":"stackdriver-operator","image":"gcr.io/gke-on-prem-release/stackdriver-operator:v0.0.440"}]}}}}'

手順 2: Log Forwarder のためにディスクバッファをクリーンアップする

クラスタに DaemonSet をデプロイしてバッファをクリーンアップします。

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

ディスクバッファがクリーンアップされたことを確認します。

kubectl --kubeconfig [CLUSTER_KUBECONFIG] logs -n kube-system -l app=fluent-bit-cleanup | grep "cleaned up" | wc -l

出力に、クラスタのノード数が表示されます。

kubectl --kubeconfig [CLUSTER_KUBECONFIG] -n kube-system get pods -l app=fluent-bit-cleanup --no-headers | wc -l

出力に、クラスタのノード数が表示されます。

クリーンアップの DaemonSet を削除します。

kubectl --kubeconfig [CLUSTER_KUBECONFIG] -n kube-system delete ds fluent-bit-cleanup

ステップ 3: Log Forwarder を再起動する

kubectl --kubeconfig [CLUSTER_KUBECONFIG] -n kube-system rollout restart ds/stackdriver-log-forwarder

ログと指標が `stackdriver.projectID` で指定されたプロジェクトに送信されない

Anthos clusters on VMware 1.7 では、クラスタ構成ファイルの stackdriver.serviceAccountKeyPath フィールドで指定されたサービスアカウントの親プロジェクトにログが送信されます。stackdriver.projectID の値は無視されます。この問題は、今後のリリースで修正される予定です。

回避策として、logging-monitoring サービスアカウントの親プロジェクトでログを確認してください。

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

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

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

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

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

kubectl --kubeconfig [ADMIN_CLUSTER_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 [ADMIN_CLUSTER_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 [ADMIN_CLUSTER_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 [ADMIN_CLUSTER_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% のスペース使用量が示される場合は、この問題が発生している可能性があります。

今後のリリースで修正が見込まれます。それまでは、この問題は次の 2 つの回避策のいずれかで解決できます。

/run/aide/cron.daily.old* のログファイルを定期的に削除する（推奨）。
上述の外部リンクに記載されている手順を行います。（注: この回避策は、ノードのコンプライアンスの状態に影響を与える可能性があります）。

Anthos Service Mesh バージョン 1.7 以降を搭載した Anthos clusters on VMware を使用する

Anthos Service Mesh バージョン 1.7 以降を搭載した Anthos clusters on VMware を使用していて、VMware バージョン 1.6.0～1.6.3 の Anthos クラスタか、VMware バージョン 1.7.0～1.7.2 の Anthos クラスタにアップグレードする場合は、次のカスタムリソース定義（CRD）から bundle.gke.io/component-name ラベルと bundle.gke.io/component-version ラベルを削除する必要があります。

destinationrules.networking.istio.io
envoyfilters.networking.istio.io
serviceentries.networking.istio.io
virtualservices.networking.istio.io

このコマンドを実行して、ユーザークラスタ内の CRD destinationrules.networking.istio.io を更新します。
```
kubectl edit crd destinationrules.networking.istio.io --kubeconfig USER_CLUSTER_KUBECONFIG
```
CRD から bundle.gke.io/component-version ラベルと bundle.gke.io/component-name ラベルを削除します。

または、1.6.4 と 1.7.3 がリリースされるのを待ってから、1.6.4 または 1.7.3 に直接アップグレードすることもできます。

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

この問題は、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.

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

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

既知の問題

「GCP への登録に失敗しました」という理由で、ユーザークラスタのアップグレードが失敗する

Category

識別されたバージョン

現象

原因

回避策

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

Category

識別されたバージョン

現象

原因

回避策

Log Forwarder が過剰な数の OAuth 2.0 リクエストを行う

ステップ 0: 必要に応じてイメージを非公開レジストリにダウンロードする

ステップ 1: stackdriver-operator のバージョンをダウングレードする

手順 2: Log Forwarder のためにディスクバッファをクリーンアップする

ステップ 3: Log Forwarder を再起動する

ログと指標が `stackdriver.projectID` で指定されたプロジェクトに送信されない

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

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

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

Anthos Service Mesh バージョン 1.7 以降を搭載した Anthos clusters on VMware を使用する

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

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

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

管理ワークステーション

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

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

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

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

Seesaw VM

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

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

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

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

既知の問題

「GCP への登録に失敗しました」という理由で、ユーザー クラスタのアップグレードが失敗する

Category

識別されたバージョン

現象

原因

回避策

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

Category

識別されたバージョン

現象

原因

回避策

Log Forwarder が過剰な数の OAuth 2.0 リクエストを行う

ステップ 0: 必要に応じてイメージを非公開レジストリにダウンロードする

ステップ 1: stackdriver-operator のバージョンをダウングレードする

手順 2: Log Forwarder のためにディスク バッファをクリーンアップする

ステップ 3: Log Forwarder を再起動する

ログと指標が stackdriver.projectID で指定されたプロジェクトに送信されない

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

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

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

Anthos Service Mesh バージョン 1.7 以降を搭載した Anthos clusters on VMware を使用する

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

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

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

管理ワークステーション

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

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

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

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

Seesaw VM

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

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

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

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

「GCP への登録に失敗しました」という理由で、ユーザークラスタのアップグレードが失敗する

手順 2: Log Forwarder のためにディスクバッファをクリーンアップする

ログと指標が `stackdriver.projectID` で指定されたプロジェクトに送信されない

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

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

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

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

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