发生了什么?
Kubelet发出的驱逐总是尊重Pod.Spec.TerminationGracePeriodSeconds。
你期望发生什么?
Kubelet发出的驱逐不应该尊重Pod.Spec.TerminationGracePeriodSeconds,这可能是非常长的。
我们如何尽可能最小精确地重现它?
apiVersion: v1
kind: Pod
metadata:
name: foo
spec:
containers:
- name: busybox
image: busybox:latest
imagePullPolicy: IfNotPresent
command: ['sh', '-c', 'echo Running ; sleep 3600']
volumeMounts:
- name: empty-dir-vol
mountPath: /var/empty-dir
volumes:
- emptyDir:
sizeLimit: "1Mi"
name: empty-dir-vol
terminationGracePeriodSeconds: 3600
- 使用上述规格创建一个Pod。
- 然后在Pod上shell并执行
cd /var/empty-dir; dd if=/dev/zero of=largefile.txt bs=1M count=10
以创建一个超过卷限制的文件。 - 观察驱逐被触发,但Pod没有被杀死。
我们需要知道其他任何事情吗?
尽管驱逐管理器在大多数情况下将宽限期设置为0,但该值始终被覆盖为Pod.Spec.TerminationGracePeriodSeconds。
Kubernetes版本
N/A
云提供商
N/A
操作系统版本
# On Linux:
$ cat /etc/os-release
# paste output here
$ uname -a
# paste output here
# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here
安装工具
容器运行时(CRI)和版本(如果适用)
相关插件(CNI,CSI,...)和版本(如果适用)
8条答案
按热度按时间1rhkuytd1#
这个问题目前正在等待分类。
如果SIG或子项目确定这是一个相关的问题,他们将通过应用
triage/accepted
标签并提供进一步的指导来接受它。组织成员可以通过在评论中写入
/triage accepted
来添加triage/accepted
标签。有关使用PR评论与我互动的说明,请查看here。如果您对我的行为有任何问题或建议,请针对kubernetes/test-infra仓库提出一个问题。
pxy2qtax2#
这种行为取决于软驱逐或硬驱逐。如果是软驱逐,我们应该使用配置选项(如果已配置)覆盖pod宽限期。我们有#124063来帮助解决这个问题。
lawou6xi3#
v64noz0r4#
请分享一下您的kubelet配置,我很想看看您是否设置了SoftEviction。
omtl5h9j5#
以下是文本内容的翻译结果:
https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/eviction/eviction_manager.go#L409 是相关代码区域。
lymnna716#
https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/eviction/eviction_manager.go#L409 is the relevant area of the code.
Hi @kannon92, thanks for the reply.
It is not about SoftEviction, which should not apply to emptyDir eviction anyway.
The issue is that the int64(0) value eviction_manager set for non-soft eviction will always be overridden to Pod.Spec.TerminationGracePeriodSeconds later here.
kubernetes/pkg/kubelet/pod_workers.go
Line 998 in 69b648a
| | ifgracePeriod==0&&pod.Spec.TerminationGracePeriodSeconds!=nil { |
vulvrdjw7#
重复的#115819
juud5qan8#
我相信修复已经在此处完成:https://github.com/kubernetes/kubernetes/pull/124063/files#diff-c6d21f5481c391a3f32bcfddf45c9c20132b2876e8be9690289474b76b71d809L998