基于已验证用户活动的应用程序启动和关闭

企业中有些应用程序和服务不需要一直运行，并且用户基数有限（如少数人）。基于已验证用户活动的应用程序启动和关闭

这些应用程序可以关闭并根据调度或甚至更好的用户活动启动。所以，我们正在谈论按需服务（如容器包装）和节点启动和关闭。

现在，首先要说的是，我提到认证用户活动的原因是因为在此基础上启动和关闭（即不基于较低级别的网络流量）是有意义的。可以想象企业SSO（基于OAuth 2）参与其中。

所以，我的问题是，是否有人试图实施我所描述的使用Consul或Kubernetes？

对于Consul的情况，可能是键值存储可以用来给“微”（即小用户群）类应用程序一个TTL，每当一个经过认证的用户请求访问给定的“Micro “它的TTL类应用程序已更新。在TTL窗口期间，我们希望检查节点（s），容器和服务的健康状况 - 在窗口之外我们不会（因为我们想要保存在操作前）。

这个问题与this autoscaling question类似，但是这个用例是基于经过验证的用户群（最有可能使用SSO）从0节点到0然后降低到0的意义上的不同。

来源

2016-01-04 Nico de Wet

如果您想根据经过身份验证的用户活动来控制服务的启动/停止，那么使用webhooks实现它更有意义 – number5

在此阶段，在关闭端，它看起来像Kubernetes容器探针，用于探测适当的HTTP端点（ala Spring Boot Actuator端点）可能是一种可能的行动方案。该端点将公开经过身份验证的用户数量。尽管对于基于TTL的关闭用例，探测器仍需要有状态。就停产而言，在库柏特斯的术语中，我们会关闭一个容器或一个容器（一组容器）。需要通过webhooks场景来思考。 –

在Kubernetes的情况下，下接下来描述的确切的使用情况下，Horizontal Pod Autoscaling documentation列表步骤（即，特征是上的积压，并且可以V1.1后实施。Kubernetes的）。引用的功能描述（Unidling proposal）如下：

缩放从0开始的豆荚数。所有豆荚可以关闭，然后在有需求时打开。当没有豆荚的服务请求到达时，kube-proxy将生成autoscaler的事件来创建新的豆荚。

所以基本上可以做到我将来使用Kubernetes描述的内容，但目前还不可能。这本身并没有解决仅基于经过验证的用户活动从0进行缩放的要求。

值得注意的是，作为一个集群不可知论者，on-demand container activation based on systemd。如果没有控制过程，这个解决方案当然不会缩减到0，但它仍然值得注意。

来源

2016-01-06 08:56:53

基于已验证用户活动的应用程序启动和关闭

回答

相关问题