我已经使用部署在kubernetes中部署了我的应用程序。
- 每当用户登录到应用程序时，pod都会为该用户生成会话
- 为了保持会话粘性，我使用Nginx入口注释设置了会话cookie
- 当hpa缩小pod应用程序时，当pod被终止时，用户会出现注销问题。如果ingress已经使用这个pod生成了一个会话。它需要再次登录
- 我想要的是某种优雅的连接终止。当pod处于终止状态时，它应该为现有会话提供服务，直到宽限期
我想要的是某种优雅的连接终止。什么时候pod处于终止状态，它应该为现有会话提供服务直到宽限期。
您可以使用POD规范中的密钥：terminationGracePeriodSeconds
这将等待所提到的第二个，并且在该第二个之后POD将被终止。
您可以在以下位置阅读更多信息：https://cloud.google.com/blog/products/containers-kubernetes/kubernetes-best-practices-terminating-with-grace
答案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将立即进入下一步。
如果你的吊舱通常需要超过30秒才能关闭，请确保增加宽限期。您可以通过在Pod YAML中设置terminationGracePeriodSeconds选项来实现这一点。例如，将其更改为60秒。
有关更多信息，请查看此处。
如果你想知道pod的生命周期到底是什么样子，请查看官方文档的链接。关于pod终止的部分应该是最有趣的。您还将了解终止的具体方式。
建议部署在Kubernetes上的应用程序具有符合推荐标准的设计。现代基于云的应用程序的一套标准被称为十二因素应用程序：
十二因素进程是无状态的，不共享任何内容。任何需要持久化的数据都必须存储在有状态的支持服务中，通常是数据库。一些网络系统依赖于"粘性会话"，即将用户会话数据缓存在应用程序进程的内存中，并期望将来来自同一访问者的请求被路由到同一进程。粘性会话违反了十二因素，不应使用或依赖。会话状态数据是提供时间过期的数据存储(如Memcached或Redis(的一个很好的候选者。