是否可以将不同的卷安装到同一部署的Pod

时间:2019-01-04 02:15:15

标签: kubernetes google-compute-engine airflow google-kubernetes-engine

我有一个gce气流(作曲者)集群,里面有一堆工人:

$ kubectl get pods
NAME                                 READY     STATUS    RESTARTS   AGE
airflow-redis-0                      1/1       Running   0          7h
airflow-scheduler                    2/2       Running   0          7h
airflow-sqlproxy                     1/1       Running   0          8h
airflow-worker                       50/50     Running   0          7h
composer-fluentd-daemon              1/1       Running   0          7h
composer-fluentd-daemon              1/1       Running   0          7h

我还有一堆独特的持久性NFS卷,其中包含需要处理的数据。有没有一种方法可以动态地将不同的NFS卷挂载到每个相应的工作器。

或者,可以在工作程序中调用的DockerOperator挂载与其特定工作负载有关的NFS卷。

理论上,工作流程为:Spin up 1x worker per Dataset> Get Dataset> Run Dataset through Model> Dump results

一种实现此目的的方法是将数据集下载到正在处理的给定容器中。但是,这些数据集每个只有数百GB,并且需要针对不同的模型进行多次处理。

最终,我们计划将所有这些数据放入BigTable中,但我需要在概念上证明使用具有数百gb数据量的卷,然后才能批准启动具有多个tb数据的BigTable集群在里面。

输入表示赞赏。告诉我我用更好的解决方案做错了也是可行的答案。

2 个答案:

答案 0 :(得分:1)

根据定义,部署使用一组相同的副本作为Pod(即ReplicaSet)。因此,部署中的所有Pod都将具有PodSpec,指向相同的卷。

听起来像您自己需要编写一些自定义逻辑,以协调旋转具有不同卷的新工作负载(例如Jobs)。

您可以通过简单地部署一个bash脚本来循环执行此操作,该脚本调用kubectl(默认情况下,pod中的kubectl可以直接运行)。或者,您可以编写使用Kubernetes API并进行一些API调用以发现新卷,创建工作负载以对其进行处理(然后清理卷)的东西。

答案 1 :(得分:1)

您描述的工作流程比普通(长时间运行)的Pod更适合Job的模型。您将需要为每个任务创建一个单独的作业规范,以指向其各自的数据,并且如果您的集群正在执行其他工作,则需要注意批量数据处理容器不要压倒可用的计算资源。

实际上您是否有不同的NFS卷(服务器名称/导出的目录),或者单个NFS卷中只有许多文件树?如果是后者,那么另一条对您来说很有效的路径是建立一个诸如RabbitMQ之类的排队系统,并将所有路径加载到那里的队列中。然后,您将编写一个长时间运行的进程,该进程从队列中顺序读取单个项目,对其执行所需的任何工作,写入其结果,提交工作项目,然后重复(在单个线程中)。然后,您可以使用Deployment将其扩展到所需的并行处理量。

无论如何,您的输出表明您直接在裸露的吊舱上工作,并试图通过在单个吊舱中放置多个并行工作人员容器来扩展工作人员。最好使用更高级别的控制器之一(最常见的是Deployment),并使用其replicas:控件启动所描述容器的多个副本。除其他外,这将使您能够将负载分散到多个节点上,并使您可以滚动更新,使Pod逐渐重新启动,从而避免在更改Pod的基础映像或其他详细信息时造成中断。