Kubernetes是否支持连接耗尽？ 例如，对于某些部署，我将使用新版本的webapp容器推出新的容器版本。 在连接排放模式下，Kubernetes应该从新映像中启动新容器，将所有新流量用于服务此新实例。但旧实例将存在一段时间，并且能够发送对现有连接的响应。
答案 0 :(得分：9)
Kubernetes 确实支持连接耗尽，但它是如何发生的，由Pod控制，称为graceful termination。
我们举一个通过服务提供流量的Pod集的示例。这是一个简化的示例，完整的详细信息可以在documentation。
中找到Terminating状态。这会将其从服务流量中删除。维护现有连接，但只要负载均衡器识别出更改，新连接就应该停止。terminationGracePeriodSeconds（默认为30秒），或直到Pod自行完成。这不仅涵盖了简单的终止案例，而且在滚动更新部署中使用了完全相同的流程，每个Pod都以完全相同的方式终止，并有机会进行清理。
如果您未在应用程序中处理SIGTERM，您的Pod将立即终止，因为SIGTERM的默认操作是立即终止进程，并且自Pod退出后不使用宽限期独自一人。
如果您需要“连接耗尽”，这是您在Kubernetes中实现它的基本方法：
terminationGracePeriodSeconds足够长的时间让Pod自行清理。答案 1 :(得分：1)
不，部署本身不支持连接耗尽。当老豆荚停止时，有效地排出连接。新的pod开始，连接到旧pod的客户端将不得不重新连接到新的pod。当客户端连接到服务时，它对客户端都是透明的。您确实需要确保您的应用程序可以处理同时运行的不同版本，但这无论如何都是一个好主意，因为它可以最大限度地减少升级中的停机时间。允许您执行A / B测试等操作。
有几种不同的策略可以让您调整升级的方式：部署支持两种更新策略：Recreate或RollingUpdate。
使用“重新创建”，旧窗格将在新窗格启动之前停止。这导致了一段时间的停机，但确保所有客户端都连接到旧版本或新版本 - 永远不会有旧版本和新版本的时间。新的pod同时为客户提供服务。如果您可以接受停机时间，那么这可能是您的选择。
但是，大多数情况下，停机对服务来说是不可接受的，因此RollingUpdate更合适。这启动了新的pods＆amp;因为它这样做会阻止旧的豆荚。当旧的pod停止时，连接到它们的客户端必须重新连接。最终将没有旧的豆荚和所有客户都将重新连接到新的pod。
虽然没有按照建议进行连接耗尽的选项，但您可以通过maxUnavailable和maxSurge选项配置滚动更新。来自http://kubernetes.io/docs/user-guide/deployments/#rolling-update-deployment：
.spec.strategy.rollingUpdate.maxUnavailable是一个可选字段，用于指定更新过程中可用的最大Pod数。该值可以是绝对数（例如5）或所需Pod的百分比（例如10％）。绝对数是通过四舍五入的百分比计算的。如果.spec.strategy.rollingUpdate.maxSurge为0，则此值不能为0.默认情况下，使用固定值1。 例如，当此值设置为30％时，旧的副本集可以在滚动更新开始时立即按比例缩小到所需Pod的70％。准备好新的Pod后，可以进一步缩小旧的副本集，然后扩展新的副本集，确保在更新期间始终可用的Pod总数至少为所需Pod的70％。
.spec.strategy.rollingUpdate.maxSurge是一个可选字段，指定可在所需Pod数量之上创建的最大Pod数。值可以是绝对数（例如5）或所需Pod的百分比（例如10％）。如果MaxUnavailable为0，则此值不能为0.绝对数量是通过向上舍入的百分比计算的。默认情况下，使用值1。 例如，当此值设置为30％时，新的副本集可以在滚动更新开始时立即按比例放大，这样旧的和新的Pod的总数不会超过所需Pod的130％。一旦旧的Pod被杀死，新的副本集可以进一步扩展，确保在更新期间随时运行的Pod总数最多为所需Pod的130％。
希望有所帮助。