Features

Function#

Define a Job#

Just define a job via CR. The job will reliably run as expected.

Let’s start with the simplest example.

apiVersion: ext.burningxflame.github.com/v1
kind: CronJob
metadata:
  namespace: <ns>
  name: <name>
spec:
  # schedule expression
  expr: "* * * * *"
  # regularly called on the specified schedule
  callback:
    http:
      url: http://<host>/<path>
  # other fields ...

RESTful API → is also available.

Cron Job#

Use cron expressions to represent schedules.

e.g.

apiVersion: ext.burningxflame.github.com/v1
kind: CronJob
metadata:
  namespace: <ns>
  name: <name>
spec:
  expr: "* * * * *" # cron expression
  # other fields ...

An optional second field is also accepted, besides the standard cron spec.

The format of expr is:
[second] <minute> <hour> <day of month> <month> <day of week>

Time Zone#

By default, all cron jobs are scheduled in local time zone.
You can specify a different time zone.

e.g.

apiVersion: ext.burningxflame.github.com/v1
kind: CronJob
metadata:
  namespace: <ns>
  name: <name>
spec:
  expr: "CRON_TZ=America/New_York * 1 * * *" # cron expression with time zone
  # other fields ...

The format of expr is:
[tz] [second] <minute> <hour> <day of month> <month> <day of week>

Periodic Job#

Schedule a job at a fixed interval.

e.g.

apiVersion: ext.burningxflame.github.com/v1
kind: CronJob
metadata:
  namespace: <ns>
  name: <name>
spec:
  expr: "@every 1m" # fixed interval
  # other fields ...

The format of expr is @every <duration>, where <duration> is a duration string in the format defined by Go time.ParseDuration ↗ .

HTTP Callback#

Regularly send an HTTP Post request without header nor body, to the specified url.

e.g.

apiVersion: ext.burningxflame.github.com/v1
kind: CronJob
metadata:
  namespace: <ns>
  name: <name>
spec:
  callback: # regularly called on the specified schedule
    http: # HTTP Post request
      url: http://<host>/<path>
  # other fields ...

HTTP Callback with Header and/or Body#

Regularly send an HTTP Post request with header and/or body, to the specified url.

e.g.

apiVersion: ext.burningxflame.github.com/v1
kind: CronJob
metadata:
  namespace: <ns>
  name: <name>
spec:
  callback: # regularly called on the specified schedule
    http: # HTTP Post request
      url: http://<host>/<path>
      header:
        Content-Type: application/x-www-form-urlencoded
      body: xda=lafayl&cet=hvesud
  # other fields ...

TCP Callback#

Regularly connect to the specified TCP address, send the specified body, and expect to receive the specified ack.

e.g.

apiVersion: ext.burningxflame.github.com/v1
kind: CronJob
metadata:
  namespace: <ns>
  name: <name>
spec:
  callback: # regularly called on the specified schedule
    tcp:
      addr: <host>:<port> # the TCP address to be connected
      body: qgBTpMtbXWnzVCXMv50OLA== # the data to be sent. base64 encoded.
      ack: LI67iYenlxY= # the data expected to be received. base64 encoded.
  # other fields ...

HTTP over UDS Callback#

Similiar to HTTP callback, but over UDS. Only supported in Meshless mode.

e.g.

apiVersion: ext.burningxflame.github.com/v1
kind: CronJob
metadata:
  namespace: <ns>
  name: <name>
spec:
  callback: # regularly called on the specified schedule
    httpUds: # HTTP Post request over UDS
      svcId: ... # the destination meshlet service
      url: http://<host>/<path> # the <host> here doesn't matter
      header:
        Content-Type: application/x-www-form-urlencoded
      body: xda=lafayl&cet=hvesud
  # other fields ...

See also

• Service ID →
• HTTP Callback →
• HTTP Callback with Header and/or Body →

UDS Callback#

Similiar to TCP callback, but via UDS instead. Only supported in Meshless mode.

e.g.

apiVersion: ext.burningxflame.github.com/v1
kind: CronJob
metadata:
  namespace: <ns>
  name: <name>
spec:
  callback: # regularly called on the specified schedule
    uds:
      svcId: ... # the destination meshlet service
      body: qgBTpMtbXWnzVCXMv50OLA== # the data to be sent. base64 encoded.
      ack: LI67iYenlxY= # the data expected to be received. base64 encoded.
  # other fields ...

See also

• Service ID →
• TCP Callback →

Callback with Retry#

Callbacks can be retried in case of error.

e.g.

apiVersion: ext.burningxflame.github.com/v1
kind: CronJob
metadata:
  namespace: <ns>
  name: <name>
spec:
  callback:
    retryTimes: 2 # number of retries
    retryInterval: 3s # the time to wait between retries
  # other fields ...

The format of retryInterval is defined by Go time.ParseDuration ↗ .

Callback with Timeout#

Callbacks can be abandoned if the call does not finish in a specified duration.

e.g.

apiVersion: ext.burningxflame.github.com/v1
kind: CronJob
metadata:
  namespace: <ns>
  name: <name>
spec:
  callback:
    timeout: 3s
  # other fields ...

The format of timeout is defined by Go time.ParseDuration ↗ .

Time Zone Change#

You can change the local time zone at runtime, and it takes effect immediately.
All cron jobs without specific time zone will be scheduled in the new local time zone.

Job History#

Job execution history is recored.
You can specify history size. Only the latest n (history size) execution records of every job are kept.

Limit Schedule Times#

You can limit how many times a job can be scheduled.

e.g.

apiVersion: ext.burningxflame.github.com/v1
kind: CronJob
metadata:
  namespace: <ns>
  name: <name>
spec:
  times: 12 # limit how many times a job can be scheduled
  # other fields ...

If times is specified and the job exceeds that limit, the job becomes ineffective, i.e. it won’t be scheduled any more.
You can modify times if you like. e.g. if you extend times of an ineffective job, the job will be scheduled again until it exceeds the new limit.
You can remove times, which is default, and the job will be scheduled forever.

Scalability#

Horizontal Scaling#

DCS Enterprise is horizontally scalable. In theory, there’s no scalability cap, i.e. you can achieve unlimited throughput by specifying an unlimited number of replicas.

Reliability#

Truly Distributed, Load Balanced#

Truly Distributed, Load Balanced and Horizontally Scalable.
All instances are active. Each instance handles a portion of workload.
This architecture provides the best scalability and reliability.

Zero Downtime During Scaling Out/In#

Truly Distributed, Load Balanced and Horizontally Scalable, and thus zero downtime during scaling out/in.

Zero Downtime During Upgrade#

Truly Distributed, Load Balanced and Horizontally Scalable, and thus zero downtime during upgrade.

Zero Downtime on Time Zone Changes#

See also Time Zone Change → .

Time zone changes are automatically detected and applied at runtime with zero downtime.

Zero Downtime on Temporary Errors#

Auto-recover on temporary errors. Zero downtime.

See also Goroutine-level Guardian →

Zero Downtime on Process Crash#

Auto-recover on process crash. Zero downtime.

See also Process-level Guardian →

Deployment#

Docker Image and Helm Chart#

Docker images and Helm charts are provided to enable you to install/upgrade DCS in a flash.

Upgrade#

Seamlessly Upgrade to a New Version#

Backward compatibility guaranteed.
To upgrade to a new version, just download the new release and run helm upgrade and that’s it.

Seamlessly Upgrade from Pro to Enterprise#

DCS Enterprise is backward compatible with DCS Pro.
To upgrade from Pro to Enterprise, just download a release of DCS Enterprise and run helm upgrade and that’s it.