如何仅允许Kubernetes中的节点上的一个类型的容器。守护进程不适合这个用例。仅允许Kubernetes节点上的一个类型的容器
例如, - 限制节点上的一个Elasticsearch窗格的调度,以防止在节点关闭时数据丢失。
可以通过仔细规划pod的CPU /内存资源和机群类型来实现。
有没有其他方法可以做到这一点?
如何仅允许Kubernetes中的节点上的一个类型的容器。守护进程不适合这个用例。仅允许Kubernetes节点上的一个类型的容器
例如, - 限制节点上的一个Elasticsearch窗格的调度,以防止在节点关闭时数据丢失。
可以通过仔细规划pod的CPU /内存资源和机群类型来实现。
有没有其他方法可以做到这一点?
如果为每个节点最多只能满足一次pod约束,那么调度程序将只能为每个节点放置一个pod。这种约束的一个很好的例子是主机端口(调度程序不会尝试放置两个需要相同主机端口的Pod,因为第二个端口永远不能运行)。
另见How to require one pod per minion/kublet when configuring a replication controller?
我跑在kubernetes/GCE集群MC的工作,对我来说M:N调度在某种意义上是非常重要的M个就业机会,我想每个节点的一项工作/吊舱N个节点运行(M >> N)。
对于我的解决办法是有明确的CPU极限荚JSON文件
"resources": {
"limits": {
"cpu": "700m"
}
}
设置,我没有复制控制器,只是纯粹的批量式的集群。 Numbe节点N
的通常是100-200-300,M
为约10K-20K
Kubernetes 1.4引入Inter-pod affinity and anti-affinity
。从documentation:Inter-pod affinity and anti-affinity allow you to constrain which nodes your pod is eligible to schedule on based on labels on pods that are already running on the node
。
这并不妨碍在一个节点上安排一个pod,但是如果且仅当调度器没有选择时,至少该节点将在节点上进行调度。
是否为每个节点创建一个elasticsearch部署选项?如果是的话,我发现它最容易使用nodeSelector和Always restart策略。你可以在不同的标签上进行匹配,这里我简单地使用Azure AvailabilitySet的区域。例如。像这样
spec: containers: ... nodeSelector: failure-domain.beta.kubernetes.io/zone: "2" ... restartPolicy: Always