kubernetes SideCar启动探测1.28

gzjq41n4  于 5个月前  发布在  Kubernetes
关注(0)|答案(5)|浏览(85)

发生了什么?
在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,...)和版本(如果适用)

xtupzzrd

xtupzzrd1#

/sig testing
/sig scheduling
0vvn1miw

0vvn1miw2#

/remove-sig testing
/remove-sig scheduling
/sig node
piwo6bdm

piwo6bdm3#

/triage accepted
/priority important-longerm
/assign @SergeyKanzhelev
vshtjzan

vshtjzan4#

@mmiranda96: 标签(s) priority/important-longerm 无法应用,因为仓库中没有它们。
对此的回应:
/triage 已接受
/priority 重要-长时间
/assign @SergeyKanzhelev
使用PR评论与我互动的说明已提供。如果您对我的行为有任何疑问或建议,请针对该仓库提交一个问题。

kognpnkq

kognpnkq5#

这看起来不仅仅限于具有重启策略为 Always 的 init 容器,常规容器也应该有相同的行为。
容器启动和其启动探针启动之间存在时间差。如果您的容器快速退出,它可能根本不会运行启动探针。

command: ['sh', '-c', 'sleep 3 ; echo "containerId: $(cat /proc/1/uid_map  | awk "{ print $3 }") logging $(date +%s)" >> /opt/logs.txt']

我们应该在具有重启策略为 Always 的情况下何时运行此命令?
我不明白这个场景是什么。
具有重启策略为 Always 的 init 容器应该长时间运行。

相关问题