语境
在 kubernetes 集群中，我有一个正在运行的 postrgreSQL pod，它通过 ClusterIP 服务暴露给集群。我使用集成 DNS 解析从同一命名空间内的另一个 pod（.NET Core）访问它。
我的部署是通过 gitlab-ci 完成的。
我想dotnet database update在 gitlab 管道中运行命令以应用数据库迁移作为作业，而不是在部署后从 Web 应用程序 pod 中运行该命令，因为迁移应用程序容易失败，如果在 pod 部署后发生这种情况，我将得到一个无法访问的 Web 应用程序。因此，在管道中将其作为作业运行将阻止 pod 的部署并保持“安全”版本运行。
哪些地方不起作用
postgres pod 没有暴露在集群之外，因此 gitlab 管道无法访问它（更糟糕的是，.net 应用程序文件期望 k8s DNS 解析能够正常工作，因此服务器 url 只是“postgres”）
我的选择
- 我可以通过将服务类型更改为 node-port 暂时公开该 pod，但是这样很麻烦，IP 可能会从一个管道运行到另一个管道运行，需要很长时间才能归属 IP。总体而言，这似乎是一个糟糕、缓慢且不稳定的解决方案。
- 我可以使用
kubectl port-forward service/postgres 5432:5432命令，这就是我在 localhost 中所做的。问题是它会“阻止”命令行，直到发送退出信号，因此dotnet在端口绑定时我的命令无法运行。尽管进行了广泛的研究我还没有找到任何 k8s 原生方法来分离此命令并且也没有找到在 gitlab-ci 中执行此操作的任何方法。 - 我可以从管道启动临时 Pod在安装了 dotnet-tools 的 dotnet-sdk 映像上运行，克隆存储库，运行 dotnet-ef 命令，然后销毁容器。这个解决方案似乎过于复杂了，会让我失去很多从 gitlab 管道运行的优势（主要是 GIT 存储库自动克隆）。
问题
有没有第四种选择 - 集成到 gitlab 管道中，这样如果迁移失败，部署就不会被应用 - 速度快（不用等待 IP 地址归属，避免在命令启动前延迟超过几秒钟） - 可重复/可靠（例如在 NodePort 情况下，如果 IP 地址归属失败会怎样？） - 易于实施、理解和维护