基于经过身份验证的用户活动的应用程序启动和关闭答案

【问题标题】：Application startup and shutdown based on authenticated user activity基于经过身份验证的用户活动的应用程序启动和关闭
【发布时间】：2016-04-08 13:31:52
【问题描述】：

企业中有一些应用程序和服务不需要一直运行并且用户群有限（比如少数人）。

可以根据计划甚至更好的用户活动来关闭和启动这些应用程序。因此，我们谈论的是按需服务（比如由容器包装）和节点启动和关闭。

现在，首先要提到的是，我之所以提到经过身份验证的用户活动，是因为在此基础上启动和关闭是有意义的（即不基于较低级别的网络流量）。可以想象涉及到企业 SSO（比如基于 OAuth 2）。

所以，我的问题是，是否有人尝试使用 Consul 或 Kubernetes 来实现我所描述的内容？

在 Consul 的情况下，键值存储可用于为“Micro”（即小型用户群）类应用程序提供 TTL，每次经过身份验证的用户请求访问给定的“Micro”类应用程序的 TTL 已更新。在 TTL 窗口期间，我们想要检查节点、容器和服务的健康状况 - 在我们不希望的窗口之外（因为我们想要保存 op ex）。

此问题与this autoscaling question 类似，但不同之处在于此用例是关于从 0 个节点扩展到基于经过身份验证的用户群（最有可能使用 SSO）的 0 个节点。

【问题讨论】：

如果你想根据经过身份验证的用户活动来控制服务的启动/停止，使用 webhook 实现它更有意义
在这个阶段，在关闭端，它看起来像一个 Kubernetes 容器探测器，它探测一个适当的 HTTP 端点（也就是 Spring Boot Actuator 端点）可能是一种潜在的行动方案。端点将公开经过身份验证的用户的数量。尽管对于基于 TTL 的关闭用例，探针需要是有状态的。在关闭方面，用 Kurbernetes 的术语来说，我们要么关闭单个容器，要么关闭 pod（容器集）。需要考虑 webhook 场景。

标签： kubernetes consul

【解决方案1】：

在Kubernetes 的情况下，Horizontal Pod Autoscaling documentation 列出了后续步骤中描述的确切用例（即，该功能已积压，可能会实施Kubernetes v1.1 之后）。引用的特征描述（Unidling proposal）如下：

从 0 开始缩放 pod 的数量。所有的 pod 都可以关闭，当有需求时再开启。当一个没有 pod 的服务请求到达时，kube-proxy 将生成一个事件供 autoscaler 创建一个新的 pod。

因此，基本上，将来使用 Kubernetes 可能会执行我所描述的操作，但现在还不可能。这本身并不能满足仅根据经过身份验证的用户活动从 0 进行扩展的要求。

值得注意的是，除了与集群无关，on-demand container activation based on systemd。这个解决方案当然不会在没有控制过程的情况下缩减到 0，但仍然值得注意。

【讨论】：