1

我正在尝试与服务一起创建部署，然后在部署完成后立即访问该服务：

> kubectl create -f my-deployment.yaml
> kubectl create -f my-service.yaml
> kubectl rollout status deployment/my-deployment --watch --timeout 10m # This usually takes ~30 seconds

deployment "my-deployment" successfully rolled out

> curl "my-service" # This happens inside a pod, so the service DNS name should be available

有时这可行，但似乎存在竞争条件 - 如果curl命令发生得太快，似乎套接字无法连接并且我得到连接超时。

如果没有准备好的 pod，这似乎是我会得到的行为，根据这个问题：当服务收到请求但没有准备好的 pod 时会发生什么？

我预计推出的完成意味着服务可以保证准备就绪。不是这样吗？是否有一些 Kubernetes 命令可以“等待”服务可用？（我注意到服务没有条件，所以你不能这样做kubectl wait......）

4

2 回答 2

2

我的回答与您的要求略有不同，但可能对您有用。我建议使用Helm来改善您的部署体验。

它对你有什么帮助？

Helm 有几个标志，例如可以在更新期间应用的--wait 。它将确保在继续之前成功创建所有资源。

于 2020-01-13T09:12:47.227 回答
2

要知道服务是否准备就绪，您可以检查是否存在带有服务名称的端点对象以及该端点对象是否具有 IP。如果 IP 存在，则表示服务已准备就绪。但是不能保证它仍然不会失败，因为您的基础架构中可能存在网络问题。

管理 pod 的 K8s 原语（例如 Deployment）仅将 pod 状态考虑到决策制定中，例如滚动更新期间的推进。

例如，在部署滚动更新期间，一个新的 pod 准备就绪。另一方面，由于某种原因（例如 API 机制、端点控制器、kube-proxy、iptables 或基础设施编程的缓慢），服务、网络策略和负载均衡器尚未为新 pod 做好准备。这可能会导致服务中断或后端容量损失。在极端情况下，如果滚动更新在任何新的替换 Pod 实际开始服务流量之前完成，这将导致服务中断。

这是由上述问题激发的提高 pod 就绪性的建议。

于 2020-01-13T09:15:23.627 回答