基于已验证的用户活动的应用程序启动和关闭 [英] Application startup and shutdown based on authenticated user activity

问题描述

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

There are applications and services in enterprises that do not need to run all the time and that have a limited user base (say a handful of people).

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

These applications can be shut down and started either based on scheduling or even better user activity. So, we are talking about on-demand service (say wrapped by a container) and node start-up and shut down.

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

Now, first to mention that the reason why I mention authenticated user activity is because is makes sense to startup and shutdown on that basis (i.e. not based on lower level network traffic). One can imagine corporate SSO (say OAuth 2 based) being involved.

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

So, my question is whether anyone has attempted to implement what I have described using Consul or Kubernetes?

在Consul的情况下，键值存储区可以用于为微型（即小型用户群）类应用程序提供TTL，每个经过身份验证的用户请求访问给定的微型类应用程序时，其TTL会更新。在TTL窗口中，我们要检查节点，容器和服务的运行状况-在窗口之外我们不检查（因为我们要保存在op ex上）。

In the case of Consul, it could be that the key-value store could be used to give "Micro" (i.e. small user base) class applications a TTL, each time an authenticated user requests access to a given "Micro" class application it's TTL is updated. During the TTL window we want to check the health of the node(s), containers and services - outside of the window we don't (since we want to save on op ex).

此问题与此自动缩放问题相似，但在感觉到该用例是关于从0个节点进行缩放，然后根据经过身份验证的用户群（最有可能使用SSO）将其缩减为0。

This question is similar to this autoscaling question, however different in the sense that this use case is about scaling from 0 nodes and then down to 0 based on an authenticated user base (most likely using SSO).

推荐答案

对于 Kubernetes ， Horizo​​ntal Pod自动缩放文档列出了 后续步骤中所述的确切用例。 （即该功能在积压中，可以在v1.1。Kubernetes之后实现）。引用的功能描述（统一提案）如下：

In the case of Kubernetes, the Horizontal Pod Autoscaling documentation lists the exact use case described under Next steps (i.e. the feature is on the backlog and may be implemented after v1.1. of Kubernetes). The cited feature description (Unidling proposal) is as follows:

缩放容器的数量，从0开始。可以关闭所有容器，然后在有需求时将其打开。当没有Pod的服务请求到达时，kube-proxy将为autoscaler生成一个事件以创建一个新的pod。

因此，基本上可以使用Kubernetes来完成我日后描述的操作，但目前尚不可能。这本身并不能满足仅根据经过身份验证的用户活动从0开始扩展的要求。

So basically, it may be possible to do what I've described in future using Kubernetes, but it is not possible right now. This in itself does not address the requirement to only scale from 0 based on authenticated user activity.

值得注意的是，与群集无关的基于systemd的按需容器激活。当然，如果没有控制过程，该解决方案将不会缩小到0，但是仍然值得注意。

It's worth noting, as a cluster-agnostic aside, on-demand container activation based on systemd. This solution will of course not scale back down to 0 without a controlling process, but it's still worth noting.

这篇关于基于已验证的用户活动的应用程序启动和关闭的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！