共享进程命名空间
这个标志最重要的部分是它只在一个 pod 中工作,一个 pod 中的所有容器将在彼此之间共享进程。
job
应该使用所描述的方法。Job 创建了一个单独的pod
,因此它不会以这种方式工作。容器应该是“主” pod 的一部分,所有其他容器都可以访问该 pod 的运行进程。
有关进程共享的更多详细信息。
可能的解决方法
可以使用kubectl
命令直接从容器中获取进程。
以下是如何使用pgrep
命令检查进程状态的示例。pgrepContainer
容器需要已经安装了命令pgrep
。
job.yaml:
apiVersion: batch/v1
kind: Job
metadata:
name: "{{ .Release.Name }}-postinstall-hook"
annotations: "helm.sh/hook": post-install
spec:
template:
spec:
serviceAccountName: config-user # service account with appropriate permissions is required using this approach
volumes:
- name: check-script
configMap:
name: check-script
restartPolicy: Never
containers:
- name: post-install-job
image: "bitnami/kubectl" # using this image with kubectl so we can connect to the cluster
command: ["bash", "/mnt/script/checkScript.sh"]
volumeMounts:
- name: check-script
mountPath: /mnt/script
其中configmap.yaml
包含脚本和逻辑,用于检查循环中的三个进程,每个进程每 10 秒进行 60 次迭代:
apiVersion: v1
kind: ConfigMap
metadata:
name: check-script
data:
checkScript.sh: |
#!/bin/bash
podName=test
pgrepContainer=app-1
process1=sleep
process2=pause
process3=postgres
attempts=0
until [ $attempts -eq 60 ]; do
kubectl exec ${podName} -c ${pgrepContainer} -- pgrep ${process1} 1>/dev/null 2>&1 \
&& kubectl exec ${podName} -c ${pgrepContainer} -- pgrep ${process2} 1>/dev/null 2>&1 \
&& kubectl exec ${podName} -c ${pgrepContainer} -- pgrep ${process3} 1>/dev/null 2>&1
if [ $? -eq 0 ]; then
break
fi
attempts=$((attempts + 1))
sleep 10
echo "Waiting for all containers to be ready...$[ ${attempts}*10 ] s"
done
if [ $attempts -eq 60 ]; then
echo "ERROR: Timeout"
exit 1
fi
echo "All containers are ready !"
echo "Configuring telegraf and fluentd services"
最终结果将如下所示:
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
test 2/2 Running 0 20m
test-postinstall-hook-dgrc9 0/1 Completed 0 20m
$ kubectl logs test-postinstall-hook-dgrc9
Waiting for all containers to be ready...10 s
All containers are ready !
Configuring telegraf and fluentd services
以上是另一种方法,您可以使用它的逻辑作为基础来实现您的最终目标。
启动后
也可以考虑在某些逻辑所在的位置使用postStart 钩子。它将在容器创建后运行。由于主应用程序需要时间来启动并且已经有等待它的逻辑,所以这不是问题:
不能保证钩子会在容器 ENTRYPOINT 之前执行