Kubernetes 如何在 hpa 缩减事件期间保持会话亲和性

Question

我已经使用部署在 kubernetes 中部署了我的应用程序。

1. 每当用户登录到应用程序 pod 时，都会为该用户生成会话。
2. 为了保持会话粘性，我使用 Nginx 入口注释设置了会话 cookie。
3. 当 hpa 缩减 pods 应用程序用户在 pod 终止时正在逐步解决注销问题。如果 ingress 使用此 pod 生成了会话。它需要重新登录。
4. 我想要的是某种优雅的连接终止。当 pod 处于终止状态时，它应该为现有会话提供服务，直到宽限期。

Answer 1

我想要的是某种优雅的连接终止。什么时候 pod 处于终止状态，它应该为现有会话提供服务 直到宽限期。

您可以使用 POD 规范中的密钥：terminationGracePeriodSeconds

这将等待提到的第二个，然后 POD 将被终止。

您可以阅读更多内容：https://cloud.google.com/blog/products/containers-kubernetes/kubernetes-best-practices-terminating-with-grace

Answer 2

Harsh Manvar的答案很好，不过，我想扩展一下:)

您当然可以在 POD 规范中使用 terminationGracePeriodSeconds。看示例yaml：

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: my-image
  terminationGracePeriodSeconds: 60

此时，Kubernetes 会等待一段称为终止宽限期的指定时间。默认情况下，这是 30 秒。需要注意的是，这与 preStop 挂钩和 SIGTERM 信号并行发生。 Kubernetes 不会等待 preStop 挂钩完成。

如果您的应用在 TerminationGracePeriod 完成之前完成关闭并退出，Kubernetes 会立即进入下一步。

如果您的 pod 通常需要超过 30 秒才能关闭，请确保延长宽限期。您可以通过在 Pod YAML 中设置 terminateGracePeriodSeconds 选项来做到这一点。例如，将其更改为 60 秒。

更多信息请看here。

如果您想知道pod lifecycle 的具体外观，请参阅此官方文档链接。关于termination of pods 的部分应该是最有趣的。您还将有它描述终止是如何发生的。

建议部署在 Kubernetes 上的应用程序具有符合推荐标准的设计。 一套现代的基于云的应用程序的标准称为Twelve-Factor App：

十二因素流程是无状态且无共享的。任何需要持久化的数据都必须存储在有状态的支持服务中，通常是数据库。 一些网络系统依赖于“粘性会话”——也就是说，将用户会话数据缓存在应用程序进程的内存中，并期望来自同一访问者的未来请求被路由到同一进程。粘性会话违反了十二因素，永远不应使用或依赖。会话状态数据非常适合用于提供超时的数据存储，例如 Memcached 或 Redis。