故障集群6bc9e9c5f193d7f0024c
错误文本:
[FAILED] unexpected WARNING event fired
In [It] at: k8s.io/kubernetes/test/e2e/kubectl/kubectl.go:2016 @ 05/20/24 03:19:38.085
最近的故障:
5/23/2024, 1:51:37 PM ci-aws-kops-eks-pod-identity-sandbox
5/22/2024, 9:46:19 PM ci-cloud-provider-aws-e2e-kubetest2
5/22/2024, 2:13:01 PM ci-kubernetes-e2e-ubuntu-ec2-containerd
5/21/2024, 8:02:28 PM ci-kubernetes-e2e-ec2-eks-al2023
5/20/2024, 3:44:23 PM ci-cloud-provider-aws-e2e-kubetest2
/kind failing-test
/kind flake
在添加日志后的新相关故障集群:
故障集群e8882803613ba87c8846
错误文本:
[FAILED] unexpected non-timeout WARNING event fired, got: LAST SEEN TYPE REASON OBJECT MESSAGE
15s Warning FailedCreatePodSandBox Pod/e2e-test-httpd-pod Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox "209afbc1d8ebeb7c8d4d403a93a2fc8d1580d94a42a59d279a9334af8d07d114": plugin type="aws-cni" name="aws-cni" failed (add): add cmd: failed to assign an IP address to container
In [It] at: k8s.io/kubernetes/test/e2e/kubectl/kubectl.go:2017 @ 05/28/24 12:39:41.445
最近的故障:
5/29/2024, 1:05:52 AM pr:pull-kubernetes-e2e-ec2
5/28/2024, 10:38:24 PM pr:pull-kubernetes-e2e-ec2
5/28/2024, 10:57:19 AM pr:pull-kubernetes-e2e-ec2
5/28/2024, 10:38:00 AM pr:pull-kubernetes-e2e-ec2
5/28/2024, 3:51:14 AM pr:pull-kubernetes-e2e-ec2
/kind failing-test
/kind flake
8条答案
按热度按时间du7egjpx1#
这个问题目前正在等待分类。
如果SIG或子项目确定这是一个相关的问题,他们将通过应用
triage/accepted
标签并提供进一步的指导来接受它。组织成员可以通过在评论中写入
/triage accepted
来添加triage/accepted
标签。有关使用PR评论与我互动的说明,请查看here。如果您对我的行为有任何问题或建议,请针对kubernetes-sigs/prow仓库提出一个问题。
x7yiwoj42#
在添加了一些日志记录后,看起来出现了以下警告:
resulting in the failure :
我检查过的每个此端到端测试的失败都是由于上述原因。
https://storage.googleapis.com/k8s-triage/index.html?ci=0&pr=1&sig=cli#e8882803613ba87c8846
可能是aws-cni的问题?
/sig network
/kind flake
ryhaxcpt3#
/remove-sig cli
jdzmm42g4#
在AWS网络部署中,我们对可见性了解不多,你能将这个问题转交给正确的人吗?
vtwuwzda5#
/assign
nwnhqdif6#
cc @orsenthil
lkaoscv77#
添加命令:无法为容器分配IP地址
这似乎表明IP地址不可用或分配失败。进一步调查。
9fkzdhlc8#
我查看了AWS示例的日志
plugin.log或ipamd.log没有显示任何失败,并且池中有足够的IP地址。
在containerd-log.txt中观察到的错误是kubelet无法给容器分配IP地址。这可能是因为压力或pods的周转而发生,通常会通过重试来解决。
在一个示例日志中,我注意到该示例的网络带宽超过了警告阈值。由于双向PPS超过了示例的最大值,数据包被排队和/或丢弃。
我们可以在这里测试一些理论来减少不稳定性
如果最近发生了任何更新,如VPC CNI的更改;并且可以尝试使用旧版本进行测试。