このドキュメントでは、Anthos clusters on VMware(GKE On-Prem)バージョン 1.9 に関する既知の問題について説明します。
/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
に違反しますので、注意してください。
Ubuntu ノードで再起動後に systemd-timesyncd が実行されない
Category
OS
識別されたバージョン
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
を再インストールします。必要に応じて、カスタマイズしたリソースを復元します。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 } ' 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 を復元する
一般に、管理クラスタは 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 の修正については、リリースノートをご覧ください。
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-conf
ConfigMap の作成に失敗し、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 環境の要素を宣言するいくつかの変数に次の内容を指定します。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