在 Kubernetes 中控制单个 Pod 中容器终止的顺序

Question

我在一个 pod 里有两个容器。一个是我的应用程序容器，第二个是 CloudSQL 代理容器。基本上，我的应用程序容器依赖于这个CloudSQL容器。

问题是，当 Pod 终止时，CloudSQL 代理容器首先终止，几秒钟后我的应用程序容器才会终止。

因此，在我的容器终止之前，它会不断向 CloudSQL 容器发送请求，从而导致错误：

could not connect to server: Connection refused Is the server running on host "127.0.0.1" and accepting TCP/IP connections on port 5432

这就是为什么，我认为指定终止顺序是个好主意，以便我的应用程序容器首先终止，然后才终止 cloudsql 容器。

我无法在文档中找到任何可以做到这一点的东西。但也许有某种方法。

Answer 1

目前，这在 Kubernetes pod API 中还不能直接实现。容器可以按任何顺序终止。Cloud SQL Pod 的死亡速度可能比应用程序快，例如，如果要执行的清理操作较少，或者要排出的动态请求较少。

从 Pod 终止：

当用户请求删除 Pod 时，系统会记录允许强制杀死 Pod 之前的预期宽限期，并向每个容器中的主进程发送 TERM 信号。

---

您可以通过将 Cloud SQL 和主容器包装在不同的入口点中来在一定程度上解决此问题，这些入口点使用共享的 Pod 级文件系统相互传达它们的退出状态。

此解决方案不适用于 Cloud SQL 代理的 1.16 版本(请参阅注释(，因为此版本不再将 shell 与容器捆绑在一起。1.17 版本现在有 Alpine 或 Debian Buster 变体，因此此版本现在是一个可行的升级目标，再次与此解决方案兼容。

如下所示的包装器可能会对此有所帮助：

containers:
- command: ["/bin/bash", "-c"]
args:
- |
trap "touch /lifecycle/main-terminated" EXIT
<your entry point goes here>
volumeMounts:
- name: lifecycle
mountPath: /lifecycle
- name: cloudsql_proxy
image: gcr.io/cloudsql-docker/gce-proxy
command: ["/bin/bash", "-c"]
args:
- |
/cloud_sql_proxy <your flags> &
PID=$!
function stop {
while true; do
if [[ -f "/lifecycle/main-terminated" ]]; then
kill $PID
fi
sleep 1
done
}
trap stop EXIT
# We explicitly call stop to ensure the sidecar will terminate
# if the main container exits outside a request from Kubernetes
# to kill the Pod.
stop &
wait $PID
volumeMounts:
- name: lifecycle
mountPath: /lifecycle

您还需要一个本地暂存空间来用于传达生命周期事件：

volumes:
- name: lifecycle
emptyDir:

此解决方案如何工作？它会在 Cloud SQL 代理容器中拦截 Kubernetes 主管在关闭时传递给每个 Pod 容器的SIGTERM信号。该容器中运行的"主进程"是一个 shell，它生成了一个运行 Cloud SQL 代理的子进程。因此，云 SQL 代理不会立即终止。相反，shell 代码会阻止等待来自主容器的信号(通过文件系统中出现的文件(它已成功退出。只有在此时，Cloud SQL 代理进程才会终止，并且挎斗容器才会返回。

当然，如果您的容器关闭时间过长并超过配置的宽限期，这对强制终止没有影响。

该解决方案取决于您正在运行的容器是否具有可用的 shell;Cloud SQL 代理也是如此(使用alpine或debian变体时，1.16 和 1.17 及更高版本除外(，但您可能需要更改本地容器构建，以确保您自己的应用程序容器也是如此。