既知の問題

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

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

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 のカスタムリソース

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

Anthos 1.9.0 での 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.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

更新された証明書を検証し、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 セッションの再接続を確認してください。

バージョン 1.9.0 または 1.9.1 にアップグレードすると `cert-manager` と競合する

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

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

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

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

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

使用しているバージョンの 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

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

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

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

使用しているバージョンの 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 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 を復元する

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 を再インストールします。必要に応じて、カスタマイズしたリソースを復元します。

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

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

Seesaw または手動モードのロードバランサを使用している場合に異常が発生する Konectivity サーバーの Pod

Seesaw または手動モードのロードバランサを使用している場合、konnectivity サーバーの Pod が正常でないことに気付く場合があります。これは、Seesaw がサービスにわたって IP アドレスの再利用をサポートしていないために発生します。手動モードの場合、ロードバランササービスを作成しても、ロードバランサ上でサービスが自動的にプロビジョニングされません。

SSH トンネリングは、バージョン 1.9 のクラスタで有効になっています。そのため、konnectivity サーバーが正常な状態ではない場合でも、SSH トンネルを使用して、クラスタ内やクラスタへの接続に影響を与えないようにできます。したがって、こうした異常状態の Pod について懸念する必要はありません。

バージョン 1.9.0 から 1.9.x にアップグレードする場合は、アップグレードする前に、正常でない konnectivity サーバーのデプロイを削除することをおすすめします。次のコマンドを実行します。

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n USER_CLUSTER_NAME delete Deployment konnectivity-server

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

ロードバランサと 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 サーバーのクライアントが数分間応答不能になる可能性があります。

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

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

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

govc（vSphere に対するコマンドラインインターフェース）に vCenter Server と vSphere 環境の要素を宣言するいくつかの変数に次の内容を指定します。

注: これらの値の多くは、管理クラスタの構成ファイルで確認できます。または、vCenter Server にログインすることで確認できます。
```
export GOVC_URL=https://VCENTER_SERVER_ADDRESS
export GOVC_USERNAME=VCENTER_SERVER_USERNAME
export GOVC_PASSWORD=VCENTER_SERVER_PASSWORD
export GOVC_DATASTORE=VSPHERE_DATASTORE
export GOVC_DATACENTER=VSPHERE_DATACENTER
export GOVC_INSECURE=true
# DATA_DISK_NAME should not include the suffix ".vmdk"
export DATA_DISK_NAME=DATA_DISK_NAME
```
次のように置き換えます。
- VCENTER_SERVER_ADDRESS は、vCenter Server の IP アドレスまたはホスト名です。
- VCENTER_SERVER_USERNAME は、vCenter Server で管理者ロールまたは同等の権限を持つアカウントのユーザー名です。
- VCENTER_SERVER_PASSWORD は、vCenter Server アカウントのパスワードです。
- VSPHERE_DATASTORE は、vSphere 環境で構成したデータストアの名前です。
- VSPHERE_DATACENTER は、vSphere 環境で構成したデータセンターの名前です。
- DATA_DISK_NAME は、データディスクの名前です。

DATA_DISK_NAME‑checkpoint.yaml ファイルをダウンロードします。

govc datastore.download ${DATA_DISK_NAME}-checkpoint.yaml temp-checkpoint.yaml

チェックポイントフィールドを編集します。

# Find out the gkeOnPremVersion
export KUBECONFIG=ADMIN_CLUSTER_KUBECONFIG
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}')

# Replace the gkeOnPremVersion in temp-checkpoint.yaml
sed -i "s/gkeonpremversion: \"\"/gkeonpremversion: \"$GKE_ON_PREM_VERSION\"/" temp-checkpoint.yaml

#The steps below are only needed for upgrading from 1.9x to 1.10x clusters.

# Find out the provider ID of the admin control-plane VM
ADMIN_CONTROL_PLANE_MACHINE_NAME=$(kubectl get machines --no-headers | grep master)
ADMIN_CONTROL_PLANE_PROVIDER_ID=$(kubectl get machines $ADMIN_CONTROL_PLANE_MACHINE_NAME -o=jsonpath='{.spec.providerID}' | sed 's/\//\\\//g')

# Fill in the providerID field in temp-checkpoint.yaml
sed -i "s/providerid: null/providerid: \"$ADMIN_CONTROL_PLANE_PROVIDER_ID\"/" temp-checkpoint.yaml

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

新しいチェックサムを生成します。
- チェックポイントファイルの最後の行を次のように変更します。
```
checksum:$NEW_CHECKSUM
```
  NEW_CHECKSUM は、次のコマンドの出力に置き換えます。
```
sha256sum temp-checkpoint.yaml
```
新しいチェックポイントファイルをアップロードします。
```
govc datastore.upload temp-checkpoint.yaml ${DATA_DISK_NAME}-checkpoint.yaml
```

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 以降に更新します。

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 \
   edit daemonset gke-metrics-agent

image: gcr.io/gke-on-prem-release/gke-metrics-agent:1.1.0-anthos.8 # use 1.1.0-anthos.8
imagePullPolicy: IfNotPresent
name: 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～4 に従って gke-metrics-agent の CPU を増やします。
[バージョン 1.9.0-1.9.4]: ステップ 1～9

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

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

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

spec:
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      limits:
        cpu: 100m
        memory: 4608Mi
      requests:
        cpu: 50m
        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: 100m
        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 が検出されます。

変更が元の状態に戻ることを回避するには、stackdriver-operator をスケールダウンします。

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system scale deploy stackdriver-operator --replicas=0

gke-metrics-agent-conf を編集用に開きます。

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system edit configmap gke-metrics-agent-conf

構成を編集して、probe_interval: 0.1s のインスタンスをすべて probe_interval: 13s に変更します。

 183     processors:
 184       disk_buffer/metrics:
 185         backend_endpoint: https://monitoring.googleapis.com:443
 186         buffer_dir: /metrics-data/nsq-metrics-metrics
 187         probe_interval: 13s
 188         retention_size_mib: 6144
 189       disk_buffer/self:
 190         backend_endpoint: https://monitoring.googleapis.com:443
 191         buffer_dir: /metrics-data/nsq-metrics-self
 192         probe_interval: 13s
 193         retention_size_mib: 200
 194       disk_buffer/uptime:
 195         backend_endpoint: https://monitoring.googleapis.com:443
 196         buffer_dir: /metrics-data/nsq-metrics-uptime
 197         probe_interval: 13s
 198         retention_size_mib: 200

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

gke-metrics-agent DaemonSet のバージョンを 1.1.0-anthos.8 に変更します。

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system \
   edit daemonset gke-metrics-agent

image: gcr.io/gke-on-prem-release/gke-metrics-agent:1.1.0-anthos.8 # use 1.1.0-anthos.8
imagePullPolicy: IfNotPresent
name: gke-metrics-agent

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

証明書エラーをチェックする 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

識別されたバージョン

現象

原因

回避策

管理ワークステーション

クラスタノード

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

Category

識別されたバージョン

現象

原因

回避策

ClientConfig のカスタム リソース

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

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

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

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

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

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

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

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

バージョン 1.9.0 または 1.9.1 にアップグレードすると cert-manager と競合する

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

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

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

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

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

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

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

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

Seesaw または手動モードのロードバランサを使用している場合に異常が発生する Konectivity サーバーの Pod

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

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

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

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

monitoring.googleapis.com への高いネットワーク トラフィック

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

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

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

ClientConfig のカスタムリソース

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

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

バージョン 1.9.0 または 1.9.1 にアップグレードすると `cert-manager` と競合する

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

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

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

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

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

monitoring.googleapis.com への高いネットワークトラフィック