feat: support cronjob specification through values.yaml

[hspitzley-czi]

Adds support for CronJob specification via Stack Helm chart. Given the following values.yaml chart renders as follows:

values.yaml:

# Service defaults
global:
  replicaCount: 1

  # Settings for the primary container
  image:
    repository: nginx
    pullPolicy: IfNotPresent
    tag: "latest"

  args: []
  command: []

  imagePullSecrets: []
  nameOverride: ""
  fullnameOverride: ""

  dnsPolicy: ClusterFirst
  restartPolicy: Always

  # Probes for the primary container
  livenessProbe:
    failureThreshold: 3
    httpGet:
      path: /
      port: http
      scheme: HTTP
    periodSeconds: 10
    successThreshold: 1
    timeoutSeconds: 1
    initialDelaySeconds: 30
  readinessProbe:
    failureThreshold: 3
    httpGet:
      path: /
      port: http
      scheme: HTTP
    periodSeconds: 10
    successThreshold: 1
    timeoutSeconds: 1
    initialDelaySeconds: 30
  startupProbe:
    enabled: false
    failureThreshold: 3
    successThreshold: 1
    initialDelaySeconds: 0
    timeoutSeconds: 1
    periodSeconds: 10
    exec:
      command:
        - ps
        - '-ef'
    
  resources:
    limits:
      cpu: '1'
      memory: '1Gi'
    requests:
      cpu: '100m'
      memory: '128Mi'

  service:
    type: ClusterIP
    port: 80

  initContainers: []
  sidecars: []

  appContext:
    envContextConfigMapName: "" # App environment level configuration configmap name
    stackContextConfigMapName: "" # Stack level configuration configmap name

  appSecrets:
    envSecret: # App environment level configuration secret
      secretName: foo
      secretKey: bar
    stackSecret: # Stack level configuration secret
      secretName: ""
      secretKey: ""

  # Global annotations to add to all resources
  annotations: {}
  # Annotations to add to pods
  podAnnotations: {}
  # Labels to add to pods
  podLabels: {}

  serviceAccount:
    # Specifies whether a service account should be created
    create: false
    # Automatically mount a ServiceAccount's API credentials?
    automount: true
    # Annotations to add to the service account
    annotations: {}
    # The name of the service account to use.
    # If not set and create is true, a name is generated using the fullname template
    name: ""

  podSecurityContext: {}
    # fsGroup: 2000

  securityContext: {}
    # capabilities:
    #   drop:
    #   - ALL
    # readOnlyRootFilesystem: true
    # runAsNonRoot: true
    # runAsUser: 1000

  ingress:
    enabled: true
    className: ""
    host: chart-example.local
    annotations: {}
      # kubernetes.io/ingress.class: nginx
      # kubernetes.io/tls-acme: "true"
    hosts:
      - paths:
          - path: /
            pathType: ImplementationSpecific
    tls: []
    #  - secretName: chart-example-tls
    #    hosts:
    #      - chart-example.local

  autoscaling:
    enabled: true
    minReplicas: 1
    maxReplicas: 10
    targetCPUUtilizationPercentage: 80
    targetMemoryUtilizationPercentage: 80

  # Additional volumes on the output Deployment definition.
  volumes: []
  # - name: foo
  #   secret:
  #     secretName: mysecret
  #     optional: false

  # Additional volumeMounts on the output Deployment definition.
  volumeMounts: []
  # - name: foo
  #   mountPath: "/etc/foo"
  #   readOnly: true

  nodeSelector:
    kubernetes.io/arch: arm64

  tolerations: []

  affinity: {}

  topologySpreadConstraints: []

  env:
    - name: ENV_VAR1
      value: "value1"
    - name: ENV_VAR2
      value: "value2"
  envFrom:
    - configMapRef:
        name: configmap1
    - secretRef:
        name: secret1
        optional: true

# Service overrides
services:
  service1:
    args: ["arg1", "arg2"]
    command: ["command1", "command2"]
    autoscaling:
      enabled: true
      minReplicas: 2
      maxReplicas: 10
      maxUnavailable: 1
    replicaCount: 2
    envFrom:
      - configMapRef:
          name: configmap1
      - secretRef:
          name: secret1
          optional: true
    sidecars:
      - name: sidecar1
        image: "sidecar1:latest"
      - name: sidecar2
        image: "sidecar2:latest"
    initContainers:
      - name: initContainer1
        image: "alpine:latest"
        command: ["echo", "Hello World"]

cronJobs:
  cronJob1:
    schedule: "* * * * *"
    image:
      repository: nginx
      pullPolicy: IfNotPresent
      tag: "latest"
    command: ["command1", "command2"]
    args: ["arg1", "arg2"]

rendered cronjob manifest:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: stack-cronJob1
spec:
  schedule: "* * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: stack-cronJob1
            image: "nginx:latest"
            imagePullPolicy: IfNotPresent
            args:
              - arg1
              - arg2
            command:
              - command1
              - command2
            resources:
              limits:
                cpu: "1"
                memory: 1Gi
              requests:
                cpu: 100m
                memory: 128Mi
            envFrom:
            - secretRef:
                name: foo
                optional: true
            - configMapRef:
                name: configmap1
            - secretRef:
                name: secret1
                optional: true
            env:
              - name: ENV_VAR1
                value: value1
              - name: ENV_VAR2
                value: value2
          restartPolicy: OnFailure
          nodeSelector:
            kubernetes.io/arch: arm64

[jakeyheath]

is there a downside to having the user full control of the entire spec? that way, we don't have keep changing the template if they want support for something like multiple container cronjobs for instance

[hspitzley-czi]

i dont think that is possible with the way we generate some things for them. eg: Argus secrets injection, service accounts, image specification

[hspitzley-czi]

tested here: https://github.com/chanzuckerberg/core-platform/pull/282