本文档介绍 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 Level2 基准强化。其中一条合规性规则 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
上述设置会使 auditd 在生成超过 250 个文件(每个文件大小为 8M)时自动轮替其日志。
集群节点
对于集群节点,将以下 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 Level2 规则 4.1.2.2 Ensure audit logs are not automatically deleted
。
systemd-timesyncd 在 Ubuntu 节点重新启动后无法运行
类别
操作系统
已识别的版本
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)
这可能会导致同步超时问题。
原因
Ubuntu 操作系统映像上错误地安装了 chrony
,并且 chrony
和 systemd-timesyncd
之间存在冲突,使得每次重新启动 Ubuntu 虚拟机时,systemd-timesyncd
都会变为非活跃状态,而 chrony
则变为活跃状态。但是,systemd-timesyncd
应该是虚拟机的默认 ntp 客户端。
临时解决方法
方法 1:每次虚拟机重新启动时手动运行 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
。
使用 PodDisruptionBudget 的工作负载中断
升级集群可能会导致使用 PodDisruptionBudget (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 以停用主节点选举,这是安全的,因为我们只有一个副本正在运行。不需要针对一个副本执行此操作。
# 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 作为缓解措施,直到安装完成为止。否则将会还原更改。
安装完成且集群启动并运行后,启用 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 的虚拟机信息中的网络名称将变得不正确,导致机器处于 Unavailable
状态。这最终会导致自动修复节点以创建新的节点。
相关的 govmmi 错误: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 操作系统映像通过 CIS L1 Server Benchmark 进行了安全强化。为满足 CIS 规则“5.2.16 确保已配置 SSH 空闲超时间隔”,/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.
您可以通过以下方法之一来解决此问题:
使用
nohup
防止命令在 SSH 断开连接时终止,nohup gkectl upgrade admin --config admin-cluster.yaml --kubeconfig kubeconfig
更新
sshd_config
以使用非零ClientAliveCountMax
值。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
集群颁发者(控制平面和可观测性组件依赖其创建和轮替证书 Secret)要求将 metrics-ca
证书 Secret 存储在集群资源命名空间中。对于 monitoring-operator 安装,此命名空间为 kube-system
,对于您的安装,此命名空间可能为 cert-manager
。
如果安装失败,请按照以下步骤操作,以成功升级到 1.9.0 或 1.9.1 版:
避免升级期间发生冲突
在用户集群中恢复您自己的 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
颁发者资源从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
通常,您无需在管理员集群中重新安装 cert-manager,因为管理员集群仅运行 Anthos clusters on VMware 控制层面工作负载。在极少数情况下,您还需要在管理员集群中安装自己的 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
颁发者资源从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
将
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
颁发者资源从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
通常,您无需在管理员集群中重新安装 cert-manager,因为管理员集群仅运行 Anthos clusters on VMware 控制层面工作负载。在极少数情况下,您还需要在管理员集群中安装自己的 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
颁发者资源从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 操作系统映像中的 docker、containerd 和 runc 使用 Ubuntu PPA 固定到特殊版本。这可确保 Anthos clusters on VMware 在每个版本之前限定所有容器运行时更改。
但是,Ubuntu CVE Tracker(用作各种 CVE 扫描工具的漏洞 Feed)并不了解特殊版本。因此,您将在 docker、containerd 和 runc 漏洞扫描结果中看到误报。
例如,您可能会从 CVE 扫描结果中看到以下误报。这些 CVE 已在 Anthos clusters on VMware 的最新补丁程序版本中修复。
如需了解任何 CVE 修复,请参阅版本说明。
Canonical 知道该问题,并且 https://github.com/canonical/sec-cvescan/issues/73 跟踪了该修复。
使用 Seesaw 或手动模式负载均衡器时健康状况不佳的 konnectivity 服务器 Pod
如果您使用的是 Seesaw 或手动模式负载均衡器,则您可能会发现 konnectivity 服务器 Pod 运行状况不佳。这是因为 Seesaw 不支持在服务中重复使用 IP 地址。对于手动模式,创建负载平衡器服务不会自动在负载平衡器上预配该服务。
1.9 版集群启用了 SSH 隧道。这样一来,即使连接服务器运行状况不佳,您仍然可以使用 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 操作系统映像通过 CIS L1 Server Benchmark 进行了安全强化。
因此,安装了 cron 脚本 /etc/cron.daily/aide
,以便安排 aide
检查以确保遵循 CIS L1 服务器规则“1.4.2 确保定期检查文件系统完整性”。
Cron 作业每天的运行时间为世界协调时间 (UTC) 上午 6:25。根据文件系统上的文件数,您可能会在该时间前后遇到由此 aide
进程引起的 CPU 和内存用量激增。
如果激增影响了您的工作负载,您可以停用每日 Cron 作业:
`sudo chmod -x /etc/cron.daily/aide`.
负载均衡器和 NSX-T 有状态分布式防火墙规则以不可预测的方式进行交互
部署 Anthos Clusters on VMware 1.9 版或更高版本时,如果部署在使用 NSX-T 有状态分布式防火墙规则的环境中具有 Seesaw 捆绑负载均衡器,则 stackdriver-operator
可能无法创建 gke-metrics-agent-conf
ConfigMap 并会导致 gke-connect-agent
Pod 进入崩溃循环。
潜在的问题是,有状态的 NSX-T 分布式防火墙规则通过 Seesaw 负载均衡器终止从客户端到用户集群 API 服务器的连接,因为 Seesaw 使用非对称连接流。NSX-T 分布式防火墙规则的集成问题会影响使用 Seesaw 的所有 Anthos clusters on VMware 版本。当应用创建大小超过 32K 的大型 Kubernetes 对象时,您可能会在自己的应用中看到类似的连接问题。按照这些说明停用 NSX-T 分布式防火墙规则,或者将无状态分布式防火墙规则用于 Seesaw 虚拟机。
如果您的集群使用手动负载均衡器,请按照这些说明配置负载均衡器,使其在检测到后端节点故障时重置客户端连接。如果没有此配置,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 替换为集群的舰队宿主项目的名称。
将集群更新至 1.9.3 版、1.10.1 版或更高版本,以便升级 Connect Agent 版本。
流向 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
,请将以下resourceAttrOverride
部分添加到stackdriver
清单: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 不适用于直接服务器返回 (DSR)
Seesaw 在 DSR 模式下运行,默认情况下,它在 Cisco ACI 中无法正常运行,这是由于数据层面 IP 学习导致的。一种可能的解决方法是将 Seesaw IP 地址添加为 Cisco 应用政策基础架构控制器 (APIC) 中的 L4-L7 虚拟 IP 地址,以停用 IP 学习。
如需配置 L4-L7 虚拟 IP 地址选项,请转到租户 > 应用配置文件 > 应用 EPG 或 uSeg EPG。如果无法停用 IP 学习,则 Cisco API 架构中的不同位置之间会存在 IP 端点波动。
gkectl diagnose 检查证书失败
如果您的工作站无法访问用户集群工作器节点,则在运行 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