Kubernetes中的Cron作业 - 连接到现有Pod，执行脚本

Question

我确定我错过了一些明显的东西。我已经完成在Kubernetes ScheduledJobs/CronJobs的文件看，但我不能找到一种方法，做一个时间表如下：

1. 连接到现有波德
2. 执行脚本
3. 断开

我有这样做的替代方法，但他们不觉得正确。

1. 安排一个cron任务：kubectl EXEC -IT $（kubectl获取豆荚--selector =一些选择器|头-1）/路径/到/脚本

2. 创建具有一个部署一个“Cron Pod”也包含应用程序，许多“Non Cron Pods”仅仅是应用程序。 Cron Pod会使用一个不同的图像（一个预定了cron任务）。

我宁愿使用Kubernetes ScheduledJobs如果可能的话，防止跑多次同样的工作，同时也因为它给我的印象做的更合适的方式。

有没有办法通过ScheduledJobs/CronJobs来做到这一点？

http://kubernetes.io/docs/user-guide/cron-jobs/

Answer 1

据我所知是没有“正式”的方式来做到这一点，你所希望的方式，那就是我相信的设计。豆荚应该是短暂的并且可以水平扩展，而乔布斯则设计成退出。将cron作业“附加”到现有的容器并不适合该模块。调度员不知道工作是否完成。

相反，作业可以调出一个专门用于运行作业的应用程序实例，然后在作业完成后将其删除。要做到这一点，您可以使用与作业相同的Image作为部署，但通过设置command:来使用不同的“入口点”。

如果他们的工作需要访问由您的应用程序创建的数据，那么这些数据将需要在应用程序/ Pod之外持久化，您可以通过几种方法来实现，但显而易见的方式是数据库或持久卷。 例如期运用数据库会是这个样子：

apiVersion: extensions/v1beta1 
kind: Deployment 
metadata: 
    name: APP 
spec: 
    template: 
    metadata: 
     labels: 
     name: THIS 
     app: THAT 
    spec: 
     containers: 
     - image: APP:IMAGE 
      name: APP 
      command: 
      - app-start 
      env: 
      - name: DB_HOST 
       value: "127.0.0.1" 
      - name: DB_DATABASE 
       value: "app_db" 

和连接到同一数据库的工作，但有不同的“入口点”：

apiVersion: batch/v1 
kind: Job 
metadata: 
    name: APP-JOB 
spec: 
    template: 
    metadata: 
     name: APP-JOB 
     labels: 
     app: THAT 
    spec: 
     containers: 
     - image: APP:IMAGE 
     name: APP-JOB 
     command: 
     - app-job 
     env: 
      - name: DB_HOST 
      value: "127.0.0.1" 
      - name: DB_DATABASE 
      value: "app_db" 

或永久体积法会是这个样子：

apiVersion: extensions/v1beta1 
kind: Deployment 
metadata: 
    name: APP 
spec: 
    template: 
    metadata: 
     labels: 
     name: THIS 
     app: THAT 
    spec: 
     containers: 
     - image: APP:IMAGE 
      name: APP 
      command: 
      - app-start 
      volumeMounts: 
      - mountPath: "/var/www/html" 
      name: APP-VOLUME 
     volumes: 
     - name: APP-VOLUME 
      persistentVolumeClaim: 
      claimName: APP-CLAIM 

--- 

apiVersion: v1 
kind: PersistentVolume 
metadata: 
    name: APP-VOLUME 
spec: 
    capacity: 
    storage: 10Gi 
    accessModes: 
    - ReadWriteMany 
    persistentVolumeReclaimPolicy: Retain 
    nfs: 
    path: /app 

--- 

apiVersion: v1 
kind: PersistentVolumeClaim 
metadata: 
    name: APP-CLAIM 
spec: 
    accessModes: 
    - ReadWriteMany 
    resources: 
    requests: 
     storage: 10Gi 
    selector: 
    matchLabels: 
     service: app 

有了这样的工作，连接到同一个卷：

apiVersion: batch/v1 
kind: Job 
metadata: 
    name: APP-JOB 
spec: 
    template: 
    metadata: 
     name: APP-JOB 
     labels: 
     app: THAT 
    spec: 
     containers: 
     - image: APP:IMAGE 
     name: APP-JOB 
     command: 
     - app-job 
     volumeMounts: 
     - mountPath: "/var/www/html" 
      name: APP-VOLUME 
    volumes: 
     - name: APP-VOLUME 
     persistentVolumeClaim: 
      claimName: APP-CLAIM