我的工作负载需要网络连接才能正常启动，我想使用postStart lifecycle hook，它会等到准备就绪然后再执行某些操作。但是，生命周期挂钩似乎阻止了CNI。永远不会为以下工作负载分配IP:
kubectl apply -f <(cat <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
spec:
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
lifecycle:
postStart:
exec:
command:
- "/bin/sh"
- "-c"
- |
while true; do
sleep
done
EOF
)
kubectl get pods -o wide
这意味着我的工作量永远不会开始(尝试连接时挂起)，并且我的生命周期钩子(Hook)永远循环。有办法解决这个问题吗？
编辑:我用sidecar而不是生命周期钩子(Hook)来实现相同的目的-仍然不确定为什么生命周期钩子(Hook)不起作用，执行CNI是容器创建IMO的一部分，因此我希望在配置了网络之后触发生命周期钩子(Hook)
最佳答案
这是一个有趣的问题:-)答案不多，但我做了一些调查，我认为我可以分享-也许有一定用处。
我从问题中发布的Yaml开始。然后，我登录到运行此Pod的机器并找到了容器。
$ kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE
nginx-8f59d655b-ds7x2 0/1 ContainerCreating 0 3m <none> node-x
$ ssh node-x
node-x$ docker ps | grep nginx-8f59d655b-ds7x2
2064320d1562 881bd08c0b08 "nginx -g 'daemon off" 3 minutes ago Up 3 minutes k8s_nginx_nginx-8f59d655b-ds7x2_default_14d1e071-4cd4-11e9-8104-42010af00004_0
2f09063ed20b k8s.gcr.io/pause-amd64:3.1 "/pause" 3 minutes ago Up 3 minutes k8s_POD_nginx-8f59d655b-ds7x2_default_14d1e071-4cd4-11e9-8104-42010af00004_0
运行
/pause的第二个容器是基础结构容器。另一个是Pod的nginx容器。请注意，通常该信息也可以通过kubectl get pod获得，但在这种情况下则不是。奇怪。在容器中，我希望网络已建立并且nginx正在运行。让我们验证一下:
node-x$ docker exec -it 2064320d1562 bash
root@nginx-8f59d655b-ds7x2:/# apt update && apt install -y iproute2 procps
...installs correctly...
root@nginx-8f59d655b-ds7x2:/# ip a s eth0
3: eth0@if2136: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1410 qdisc noqueue state UP group default
link/ether 0a:58:0a:f4:00:a9 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 10.244.0.169/24 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::da:d3ff:feda:1cbe/64 scope link
valid_lft forever preferred_lft forever
这样就建立了网络，路由已经到位，而eth0上的IP地址实际上位于应该位于的覆盖网络上。现在查看进程列表:
root@nginx-8f59d655b-ds7x2:/# ps auwx
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.1 32652 4900 ? Ss 18:56 0:00 nginx: master process nginx -g daemon off;
root 5 5.9 0.0 4276 1332 ? Ss 18:56 0:46 /bin/sh -c while true; do sleep done
nginx 94 0.0 0.0 33108 2520 ? S 18:56 0:00 nginx: worker process
root 13154 0.0 0.0 36632 2824 ? R+ 19:09 0:00 ps auwx
root 24399 0.0 0.0 18176 3212 ? Ss 19:02 0:00 bash
嗯，nginx正在运行，preStop命令也在运行。但是请注意较大的PID。部署文件中有一个错字，它正在执行不带参数的
sleep-这是一个错误。root@nginx-8f59d655b-ds7x2:/# sleep
sleep: missing operand
Try 'sleep --help' for more information.
这是从循环开始的，因此 fork 的负载导致较大的PID。
作为另一项测试，我还尝试从节点上 curl 服务器:
node-x$ curl http://10.244.0.169
...
<p><em>Thank you for using nginx.</em></p>
...
这是非常期待的。因此，最后我想强制执行preStop命令，以便从容器内部杀死包含 shell 程序的 shell 程序:
root@nginx-8f59d655b-ds7x2:/# kill -9 5
...container is terminated in a second, result of the preStop hook failure...
$ kubectl get pod
NAME READY STATUS RESTARTS AGE
nginx-8f59d655b-ds7x2 0/1 PostStartHookError: rpc error: code = ResourceExhausted desc = grpc: received message larger than max (53423560 vs. 16777216) 0 21m
嗯，所以我想象值(value)50MB(!)的消息是由于缺少参数导致的睡眠失败。实际上，更令人毛骨悚然的是，部署无法从此故障中恢复。这个Pod会永远徘徊，而不是您期望的那样(生成另一个Pod然后重试)。
此时，我删除了部署，并使用固定在preStop挂钩中的sleep(
sleep 1)重新创建了该部署。结果几乎是相同的，在这种情况下，Deployment也不会生成另一个Pod(因此，这不仅是因为它阻塞了日志)。现在，我确实在最上面说过，这实际上不是答案。但也许有些收获:生命周期挂钩需要一些工作才能被认为有用和安全。
关于kubernetes - Kubernetes postStart生命周期 Hook 块CNI，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/55298354/