我正在一个场景中，我希望能够在等待中维护一些X数量的Pod（并由kube管理），然后根据用户请求（通过某些外部系统）在其中一个上启动kube作业等待的豆荚。因此，现在等待的豆荚数为X-1，而kube启动另一个豆荚以将该数字带回X。 这样，我将可以减少创建容器，启动容器并准备开始实际处理所需的时间。可以通过某种消息传递（akka或rabbitmq）将处理数据发送到那些容器。 我认为ReplicationControllers是保留闲置Pod的最佳位置，但是当我创建作业时，如何指定我希望能够使用正在等待并由ReplicationController管理的Pod之一。
答案 0 :(得分：2)
我认为我可以将其工作到一个可以建立此解决方案的状态。
因此，我要做的是从replicas: X开始RC（X是我希望维护的空闲Pod的数量，通常不是很大）。它启动的Pod具有自定义标签status: idle或类似的标签。 RC spec.selector具有相同的自定义标签值以与其管理的Pod匹配，因此spec.selector.status: idle。创建此RC时，kube确保确保使用其status = idle创建X个吊舱。如下所示：
apiVersion: v1
kind: ReplicationController
metadata:
name: testrc
spec:
replicas: 3
selector:
status: idle
template:
metadata:
name: idlepod
labels:
status: idle
spec:
containers:
...
另一方面，我有一个具有spec.manualSelector: true的作业Yaml（是的，我已经考虑到标签集必须是唯一的）。启用manualSelector后，我现在可以在工作中定义选择器，如下所示。
apiVersion: batch/v1
kind: Job
metadata:
generateName: testjob-
spec:
manualSelector: true
selector:
matchLabels:
status: active
...
显然，RC通过选择器创建了status = idle的吊舱，而job希望使用status = active的吊舱。
因此，现在每当我有要求开始新工作的请求时，我都会在RC管理的一个容器上更新标签，以使其状态为活动。 RC上的选择器将影响此Pod从其控件中的释放，并由于设置了replicas: X而启动另一个Pod。并且释放的吊舱不再是RC的控制者，现在是孤立的。最后，当我创建一个作业时，此作业模板上的选择器将与孤立的吊舱的标签匹配，然后该吊舱将由新作业控制。我将消息发送到此窗格，该消息将开始实际处理并最终完成。
附注：请原谅我的格式。我是新来的。