发生了什么?
在initContainer执行其操作和启动探针之间似乎存在一些时间同步或竞争条件。以这个例子为例:
containers:
- name: myapp
image: alpine:latest
command: ['sh', '-c', 'tail -F /opt/logs.txt']
volumeMounts:
- name: data
mountPath: /opt
initContainers:
- name: logshipper
image: alpine:latest
restartPolicy: Always
command: ['sh', '-c', 'sleep 3 ; echo "containerId: $(cat /proc/1/uid_map | awk "{ print $3 }") logging $(date +%s)" >> /opt/logs.txt']
startupProbe:
exec:
command: ["true"]
periodSeconds: 1
initialDelaySeconds: 0
volumeMounts:
- name: data
mountPath: /opt
这个例子通过了启动探针,容器myapp
启动正常,但是如果我移除了sleep
或者将其缩短到少于3
秒的时间,那么myapp
容器永远不会启动。
你期望发生什么?myapp
应该由于startupProbe
通过而启动,但似乎执行得太慢了。
我们如何尽可能精确地最小化地重现它?
提供上面的例子,但启用sidecar功能门,并使用以下示例:
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
featureGates:
"SidecarContainers": true
pod:
apiVersion: v1
kind: Pod
metadata:
name: pod
spec:
volumes:
- name: data
emptyDir:
sizeLimit: 500Mi
containers:
- name: myapp
image: alpine:latest
command: ['sh', '-c', 'tail -F /opt/logs.txt']
volumeMounts:
- name: data
mountPath: /opt
initContainers:
- name: logshipper
image: alpine:latest
restartPolicy: Always
command: ['sh', '-c', 'sleep 5 ; echo "containerId: $(cat /proc/1/uid_map | awk "{ print $3 }") logging $(date +%s)" >> /opt/logs.txt']
startupProbe:
exec:
command: ["true"]
periodSeconds: 1
initialDelaySeconds: 0
volumeMounts:
- name: data
mountPath: /opt
- name: logshipper1
image: alpine:latest
restartPolicy: Always
command: ['sh', '-c', 'sleep 5 ; echo "containerId: $(cat /proc/1/uid_map | awk "{ print $3 }") logging $(date +%s)" >> /opt/logs.txt']
startupProbe:
exec:
command: ["true"]
periodSeconds: 1
initialDelaySeconds: 0
volumeMounts:
- name: data
mountPath: /opt
我们需要知道其他任何信息吗?
版本是1.28
Kubernetes版本
❯ kubectl version
Client Version: v1.28.2
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.28.0
云提供商
本地/ Kind
操作系统版本
❯ cat /etc/os-release
NAME="Arch Linux"
PRETTY_NAME="Arch Linux"
ID=arch
BUILD_ID=rolling
ANSI_COLOR="38;2;23;147;209"
HOME_URL="https://archlinux.org/"
DOCUMENTATION_URL="https://wiki.archlinux.org/"
SUPPORT_URL="https://bbs.archlinux.org/"
BUG_REPORT_URL="https://bugs.archlinux.org/"
PRIVACY_POLICY_URL="https://terms.archlinux.org/docs/privacy-policy/"
LOGO=archlinux-logo
安装工具
容器运行时(CRI)和版本(如果适用)
Docker
相关插件(CNI,CSI,...)和版本(如果适用)
5条答案
按热度按时间xtupzzrd1#
0vvn1miw2#
piwo6bdm3#
vshtjzan4#
@mmiranda96: 标签(s)
priority/important-longerm
无法应用,因为仓库中没有它们。对此的回应:
/triage 已接受
/priority 重要-长时间
/assign @SergeyKanzhelev
使用PR评论与我互动的说明已提供。如果您对我的行为有任何疑问或建议,请针对该仓库提交一个问题。
kognpnkq5#
这看起来不仅仅限于具有重启策略为
Always
的 init 容器,常规容器也应该有相同的行为。容器启动和其启动探针启动之间存在时间差。如果您的容器快速退出,它可能根本不会运行启动探针。
我们应该在具有重启策略为
Always
的情况下何时运行此命令?我不明白这个场景是什么。
具有重启策略为
Always
的 init 容器应该长时间运行。