2016-12-16 7 views
6

Jestem pewien, że brakuje mi czegoś oczywistego. Szukałem poprzez dokumentacji ScheduledJobs/CronJobs na Kubernetes, ale nie mogę znaleźć sposób, aby wykonać następujące czynności zgodnie z harmonogramem:Cron Jobs in Kubernetes - połącz się z istniejącą kapsułą, wykonaj skrypt

  1. połączyć się z istniejącą Pod
  2. wykonania skryptu
  3. Disconnect

Mam alternatywne metody robienia tego, ale one nie mają racji.

  1. zaplanować zadanie cron dla: kubectl Exec -To $ (kubectl dostać strąki --selector = jakiś selektor | szef -1)/ścieżka/do/skryptu

  2. Utwórz jedną instalację, która ma "Cron Pod", która również zawiera aplikację, i wiele "Podstonów Nie Cron", które są tylko aplikacją. The Cron Pod używałby innego obrazu (jednego z zaplanowanymi zadaniami cron).

wolałbym użyć Kubernetes ScheduledJobs jeśli to możliwe, aby zapobiec tej samej pracy działa kilka razy na raz, a także dlatego, że wydaje mi się bardziej odpowiedni sposób to zrobić.

Czy istnieje sposób, aby to zrobić przez ScheduledJobs/CronJobs?

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

+0

Dlaczego trzeba połączyć się z istniejącą kapsułą? Nie możesz wykonać swojego skryptu w nowej kapsule? Inną możliwością jest otwarcie serwera na głównej podsieci (np. HTTP) i wykonanie połączenia z zaplanowanego zadania. – kichik

+0

Jest to aplikacja Symfony, do której chciałbym wywołać komendy. Na serwerze jest wielu najemców i łatwiej byłoby "ls -s */| ciąć -f1 -d '/ "', aby uzyskać listę katalogów (instalacji), niż by ręcznie utworzyć wpis cron dla każdej instalacji. To zakończy się czymś w rodzaju 'installation = $ (ls -d */| cut-f1 -d '/'); cd/path/$ installation; php app/console some: command'A Nowy moduł nie będzie znać każdej instalacji i nie będzie miał dostępu do zmiennych instalacyjnych bez rozłączania i konfigurowania aplikacji tak, jakby była prawdziwą instancją. – Aeisor

Odpowiedz

0

O ile jestem świadomy nie ma „oficjalny” sposób to zrobić tak, jak chcesz, i to wierzę projektem. Strąki mają być efemeryczne i skalowalne w poziomie, a zadania mają na celu wyjście. Posiadanie zadania cron "dołącz" do istniejącego strąka nie pasuje do tego modułu. Scheduler nie miałby pojęcia, czy praca została zakończona.

Zamiast tego zadanie może wywołać instancję aplikacji, aby uruchomić zadanie, a następnie usunąć je po zakończeniu zadania. Aby to zrobić, możesz użyć tego samego obrazu dla zadania, jak w przypadku wdrożenia, ale użyj innego "Punktu wejścia", ustawiając command:.

Jeśli praca wymaga dostępu do danych utworzonych przez aplikację, dane te będą musiały być przechowywane poza aplikacją/podpisem, można to zrobić na kilka sposobów, ale oczywistymi sposobami będzie baza danych lub trwały wolumin. Na przykład useing bazy danych będzie wyglądać mniej więcej tak:

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" 

i pracę, która łączy się z tej samej bazy danych, ale z innym „punkt_wejścia”:

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" 

lub metody trwałe objętościowego wyglądać następująco:

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 

z taką pracę, dołączając do tej samej objętości:

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