Terraform kubernetes 部署与 pod 就绪门答案

【问题标题】：Terraform kubernetes deployment with pod readinessgatesTerraform kubernetes 部署与 pod 就绪门
【发布时间】：2025-12-28 11:15:12
【问题描述】：

我们使用 terraform 资源“kubernetes_deployment”来部署我们的 pod。我们的 Pod 有准备就绪探针，但这些探针还不够好，因为我们需要外部反馈来确定 Pod 是否准备好。在我们的例子中，只有在外部程序在 aws S3 存储桶中创建文件后，Pod 才准备就绪，这是一个手动步骤，可能在随机时间（可以是几天/几周）完成，所以准备情况探测不好，因为它将失败并使我们的 pod 处于“未就绪”状态。我们知道 Kubernetes 1.14 引入了一个叫做就绪门的东西。见https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate 但是，似乎 terraform 资源“kubernetes_deployment”不支持 pod 就绪门。

请注意，我们更喜欢使用 kubernetes 部署（而不是直接定义 pod），因为我们需要滚动更新策略。

我们如何使用 terraform 定义 pod 就绪门？

【问题讨论】：

我在 terreform-kubernetes github repo 上为此打开了一个功能请求：github.com/terraform-providers/terraform-provider-kubernetes/…

标签： kubernetes terraform

【解决方案1】：

目前您无法使用 terraform 定义 pod 就绪门。

您可以在terreform-kubernetes github repo 上创建功能请求或自行添加此功能并创建拉取请求。

现在您可以使用 initContainers（正如 Yuri 已经提到的）或者使用 readiness probe 和命令，使用 bash 串起来检查应用程序的准备情况和文件的存在。

但可能你能做的最好的事情是重写你的应用程序，这样它就可以处理文件还不存在的情况。

【讨论】：

readiness 探针使用 bash 来“串在一起”的命令检查应用程序的就绪性和文件的存在性对我们不起作用，因为当文件不存在时，就绪性探针将反复失败并 pod将移至“未就绪”状态。在这种情况下，当最终创建文件时，我们将无法将其移回“就绪”状态
我不能重写应用程序，所以它可以处理文件不存在的情况，因为这个文件是一个“应用程序策略”文件，没有它应用程序不知道如何处理请求.如果文件存在，我可以更改就绪探测以返回 http 状态代码 200，如果文件不存在，则返回 http 状态代码 250（kubernetes 认为从 200 到 399 的任何值都是成功的）。然而，这种方法给应用程序客户端带来了额外的负担，需要检查 http 状态代码并在收到代码 250 时重试。似乎是一种不好的方法，
“在这种情况下，当最终创建文件时，我们将无法将其移回“就绪”状态” - 你为什么这么认为？创建文件后，readines 探针应停止失败，并且 pod 状态应更改为“就绪”。
我的印象是，在准备失败“failureThreshold”次后，它放弃了，再也不会尝试了。但是根据您的评论，我再次阅读了文档，看来您是对的，就绪探针在失败后继续尝试，并且一旦文件存在最终将成功:)

【解决方案2】：

尝试使用 initcontainer 检查 S3 存储桶的状态。我在下面给你发了一个例子：

'' 初始化容器： - 名称：安装图片：忙箱命令： -wget - “-O” -“/work-dir/index.html” - http://kubernetes.io ’”

【讨论】：

感谢 initcontainer 示例。 initcontainer 意味着一个额外的容器和额外的资源（mem/cpu）。它还引入了另一个故障点。所以我们对采用这种方法犹豫不决