发生了什么？
正如 pr #49449 所说：当 gracePeriod 为 0 时，不要尝试运行 preStopHook。当我们执行强制删除 pod 时，不会执行 pre-stop hook。但是这个 pr #115835 破坏了这种行为。它会在强制删除时执行 pre-stop hook。
你期望发生什么？
上述两个 PR 的行为是冲突的。我不知道哪种方法符合预期
我们如何尽可能精确地最小化地重现它？
- 使用以下 yaml 应用 pod:
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: nginx-daemonset
spec:
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx-container
image: hub.easystack.io/captain/nginx:1.21
volumeMounts:
- name: root-volume
mountPath: /root/
lifecycle:
preStop:
exec:
command: ["/bin/sh", "-c", "echo 'hello world' > /root/tempfile && sleep 5"]
volumes:
- name: root-volume
hostPath:
path: /root/- 强制删除一个 pod:
kubectl delete po nginx-daemonset-pml7f --force
你可以查看 pre-stop 执行的结果
我们需要了解其他信息吗？
- 无响应*
Kubernetes 版本
$ kubectl version
server Version: v1.28.2
# paste output here云提供商
...
操作系统版本
# On Linux:
$ cat /etc/os-release
# paste output here
$ uname -a
# paste output here
Linux node-1.domain.tld 4.18.0-372.19.1.es8_8.x86_64 #1 SMP Tue Jan 2 14:54:00 CST 2024 x86_64 x86_64 x86_64 GNU/Linux
# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here安装工具
容器运行时(CRI)和版本(如果适用)
相关插件(CNI,CSI,...)和版本(如果适用)
8条答案
按热度按时间gc0ot86w1#
/cc
rqcrx0a62#
/sig node
smtd7mpg3#
Let me do some research.
/assign
o4hqfura4#
我认为是 #115835 的变化导致了原始功能的实现被破坏。尽管我们在强制删除 Pod 和 Container Lifecycle Hooks 文档中没有解释这一点(当 gracePeriod 为 0 时，preStopHook 将不会被执行)。我会修复这个问题，并修改文档以说明当我们使用
--grace-period=0强制删除 pod 时，preStopHook 不会被运行。/triage 已接受
/priority 重要-即将到来
tkclm6bt5#
在PR #115835中，我们在执行preStop钩子之前使用
gracePeriodOverride覆盖gracePeriod,这带来了两个破坏性的变化。a). 当使用
--grace-period=0强制删除pod时，我们不会执行preStop钩子。b).
calculateEffectiveGracePeriod函数的结果将始终应用于preStop钩子。对于a,我们需要修复它，因为它破坏了原始逻辑。我们总是在
calculateEffectiveGracePeriod函数中为gracePeriod设置一个大于或等于1的值。参考：
kubernetes/pkg/kubelet/pod_workers.go
第1001行到第1004行
| | // no matter what, we always supply a grace period of 1 |
| | ifgracePeriod<1 { |
| | gracePeriod=1 |
| | } |
尽管我看到了这个行为的解释，但我仍然好奇为什么我们需要将
gracePeriod设置为1,因为我在killContainer中看到当gracePeriod小于minimumGracePeriodInSeconds时，我们总是将其设置为minimumGracePeriodInSeconds的值。参考：
kubernetes/pkg/kubelet/kuberuntime/kuberuntime_container.go
第765行到第768行
| | // always give containers a minimal shutdown window to avoid unnecessary SIGKILLs |
| | ifgracePeriod<minimumGracePeriodInSeconds { |
| | gracePeriod=minimumGracePeriodInSeconds |
| | } |
对我来说，解决这个问题的方法是让
calculateEffectiveGracePeriod不将gracePeriod设置为大于或等于1的值，或者当我们执行pod.DeletionGracePeriodSeconds=0时不要覆盖gracePeriod。对于b,我认为我们做对了，但现在似乎在
calculateEffectiveGracePeriod函数(当pod被驱逐或强制删除时，使用terminationGracePeriodSeconds的值作为删除pod的时间)中存在一些bug。我已经看到有人提交了一个修复它的PR,例如： #119570swvgeqrz6#
我认为是 #115835 中的更改导致了原始功能的实现被破坏。
尽管我们在强制删除 Pod 和 Container Lifecycle Hooks 文档中没有解释(当 gracePeriod 为 0 时，preStopHook 将不会被执行)。
我会修复这个问题，并修改文档以说明当我们使用
--grace-period=0强制删除 pod 时，不会运行 preStopHook。/triage accepted /priority important-soon
大家好，我也很关心在使用 --force 参数时预期的行为是什么。
PreStop
在容器因 API 请求或管理事件(如存活性/启动探针失败、抢占、资源争用等)而被终止之前立即调用此钩子。...
顺便说一下，从 1.25 到 1.29 的语句没有任何变化。
当执行强制删除操作时，API 服务器不会等待来自 kubelet 的确认，表明 Pod 已在其运行的节点上终止。它会立即从 API 中删除 Pod,以便可以使用相同的名称创建一个新的 Pod。在节点上，设置为立即终止的 Pod 仍将被给予一个小的宽限期，然后才会被强制杀死。
这里没有提到“小宽限期”有多长。我只是认为在 #115835 实现的修复之前的行为与此声明不一致，而新的行为至少在某种程度上是这样。
期待Maven组的澄清。
非常感谢。
hsgswve47#
jucafojl8#
@HirazawaUi: 标签
priority/无法应用，因为仓库中没有它们。对此的回应：
/remove-priority important-soon
/priority important-longterm
使用 PR 评论与我互动的说明已提供。如果您对我的行为有任何疑问或建议，请针对 here 仓库提出问题。