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