2016-12-16 10 views
6

私は何かが明らかに欠けていると確信しています。私はKubernetes上ScheduledJobs/cronジョブのドキュメントに目を通してきたが、私はスケジュールに次の操作を実行する方法を見つけることができません。クーベルネットのCronジョブ - 既存のポッドに接続し、スクリプトを実行してください

  1. 接続し、既存のポッド
  2. スクリプトを実行
  3. 外し

私はこれに代わる方法がありますが、それは正しいと感じません。用

  1. スケジュールのcronタスク:kubectl幹部は$ -it(kubectl GETポッド--selector =いくつかのセレクタを|ヘッド-1)/パス/に/スクリプト

  2. 持つものの展開を作成します。アプリケーションを格納している「Cron Pod」と、単なるアプリケーションである「Non Cron Pods」もあります。 Cron Podは、別のイメージ(cronタスクがスケジュールされたもの)を使用します。それはそれをやって、より適切な方法として私を打つために一度ともに複数回実行している同じ仕事を防止することができる場合

私はKubernetes ScheduledJobsを使用することを好むだろう。

ScheduledJobs/CronJobsでこれを行う方法はありますか?

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

+0

なぜ既存のポッドに接続する必要がありますか?新しいポッドでスクリプトを実行できませんか?もう1つの可能性は、メインポッド上のサーバー(HTTPなど)を開き、スケジュールされたジョブからそのサーバーに電話をかけることです。 – kichik

+0

これは私がコマンドを呼びたいSymfonyアプリケーションです。サーバ上には多くのテナントが存在し、 'ls -s */| cut -f1 -d '/' 'を実行すると、インストールごとにcronエントリを手動で作成するよりも、ディレクトリ(インストール)の繰り返し可能なリストを取得できます。 'installation = $(ls -d */| cut -f1 -d '/')のようになります。 cd/path/$ installation; php app/console some:command' 新しいポッドは各インストールを認識せず、実際のインスタンスのようにアプリケーションをプルダウンして設定することなくインストール変数にアクセスすることはできません。 – Aeisor

答えて

0

は、私の知る限りでは、あなたが望むこの方法を行うには「公式」の方法はありません承知しているとして、それは私が設計によって信じています。ポッドは一時的で水平方向にスケーラブルであり、ジョブは終了するように設計されています。既存のポッドにcronジョブを「接続」させることは、そのモジュールに適合しません。スケジューラはジョブが完了したかどうかわかりません。

代わりに、ジョブは、ジョブを実行するためのアプリケーションのインスタンスを起動し、ジョブが完了したらジョブを停止することができます。これを行うには、ジョブと同じImageをデプロイメント用に使用できますが、command:を設定して別の「エントリーポイント」を使用します。

アプリケーションがアプリケーションで作成したデータにアクセスする必要がある場合、そのデータをアプリケーション/ポッドの外に保存する必要がある場合は、これをいくつかの方法で行うことができますが、明白な方法はデータベースまたは永続ボリュームです。

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" 

または永続ボリュームアプローチだろうデータベースをuseingたとえば は、次のようになります同じボリュームへの取り付け、このような仕事で

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 
関連する問題