扩展服务以响应Kubernetes上的请求 [英] Scaling service in response to requests on Kubernetes

问题描述

让我们说:

1. 我有一项服务，该服务在启动时会带有一个ID.

1. I have a service which when started takes an id.

我希望每个服务进程都在单独的k8s pod中运行.

I want each service process to run in a separate k8s pod.

我想在用户输入id N作为响应的前面放置一个API:

I want to put an API in front of this where a user enters an id N and in response:

1. 如果ID为N的服务正在运行，我会将用户路由到该服务.

1. If a service for id N is running I route the user to it.

如果没有为id N运行的服务，我将启动一个服务(即旋转一个新的pod)，然后将用户路由到那里.

If no service is running for id N I start one (i.e. spin up a new pod) then route the user there.

我对(3.2)有一些想法:

Some ideas I've had for (3.2):

1. 路由器"服务使用k8s api直接启动新的pod.感觉错了，但也许不是吗?

1. The "router" service directly spins up new pods using the k8s api. That feels wrong but perhaps it isn't?

没有正在运行的服务的传入请求进入队列，根据队列大小触发水平pod扩展，并让新服务将id移出队列.

Incoming requests that have no running service go in a queue, trigger horizontal pod scaling based on queue size and have the new service take the id off the queue.

是否有我想念的原始元素可以在这里帮助我?在kubernetes上实现此功能的最惯用的方法是什么?如果完全相关，我将在AKS上运行所有这些操作.

Is there a primitive I've missed that could help me here? What's the most idiomatic way to implement this on kubernetes? If it's at all relevant I'll be running all this on AKS.

推荐答案

在我看来，阅读您的需求，就像您在Kubernetes上需要更多类型的自己的PaaS一样，而不是一种扩展服务.有几种现有的解决方案，例如检查" Deis工作流程".

如果您真的想从头开始创建这样的解决方案，我将用作(1& 2)的概念证明，这是Kubernetes的软件包管理器工具，称为
您实际上可以将'release'与'id'等同对待.在K8S集群中未创建任何发布=您的服务已缩放为零.除了"helm"客户端工具之外，您还可以轻松地找到应用程序URL(特定用户ID的目标路由).使用 Kubernetes API客户端库或直接通过 Kubernetes REST API ，您的前端将使用(3).

Reading your requirements it looks to me, like you require more a type of own PaaS on top of Kubernetes, rather than kind of Scaling service. There are couple of existing solutions out there, e.g. check 'Deis Workflow'.

If you really intend to create such a solution from scratch I would use as a proof of concept for (1 & 2), a package manager tool for Kubernetes, called helm, which works on higher level abstraction - bundles in single 'release' a Kubernetes resources that make up the whole working application: Pod, Service, Persistence Volume, etc. .

You could literally treat 'release' equally with an 'id'. No releases created in K8S cluster = your service is scaled to zero. Beside 'helm' client tool gives you an easy way to find out application URLs (target route for specific user id). The same information would be accessible from Kubernetes API using Kubernetes API client libraries or directly by Kubernetes REST API, that your frontend would use (3).

这篇关于扩展服务以响应Kubernetes上的请求的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！