Types

​

Serverless

Serverless workloads should be used for web applications that serve traffic on a single port, but may not need to run 100% of the time.

Serverless workloads may:

• Scale to zero.

Serverless workloads may not:

• Serve traffic on multiple ports.

Serverless workloads must:

• Expose a network endpoint.

​

Standard

Standard workloads have greater flexibility in network exposure, but may not scale to zero.

Standard workloads may:

• Expose no network endpoint.
• Serve traffic on multiple ports.

Standard workloads may not:

• Scale to zero.

​

Cron

Cron workloads should be used when you need to perform a background task on a regular schedule.

Cron workloads may not:

• Serve traffic.
• Scale to zero.
• Include a container that runs indefinitely.

Cron workloads must:

• Exit upon completion of the task at hand. Control Plane will start a new replica of your workload at the next scheduled execution time.

​

Cron Configuration

• job.schedule
  • A string, which determines how often the cron workload should execute. This field uses the Kubernetes cron schedule syntax.
• job.concurrencyPolicy
  • Either Forbid or Replace. This determines what Control Plane will do when a prior execution of your workload is still running when the next scheduled execution time arrives.
    • Forbid: subsequent executions will be forgone until the running execution completes.
    • Replace: the running execution will be stopped so that a new execution can begin.
• job.historyLimit
  • An integer between 1 and 10 representing the number of prior executions to be retained for reference.
• job.restartPolicy
  • Either Never or OnFailure. This determines whether your workload will be restarted when it fails on execution.
• job.activeDeadlineSeconds
  • Optional: By default there is no deadline. Job executions are allowed to run indefinitely.
  • If this property is set, this is the maximum number of a seconds a job execution can run. If the job does not exit in the allotted time, Control Plane will remove it.

​

Run Now

Cron workloads can be run on-demand by submitting a runCronWorkload command via POST https://api.cpln.io/org/my-org/gvc/my-gvc/workload/my-cron-workload/-command

type: runCronWorkload
spec:
  location: aws-us-west-2
  containerOverrides:
    - name: my-container
      command: '/bin/sh'
      cpu: '25m'
      memory: '32Mi'
      image: 'ubuntu:latest'
      args:
        - '-c'
        - sleep 10
      env:
        - name: MY_ENV_VAR
          value: some-new-value

​

runCronWorkload Spec

• location
  • The name of the location as specified in your GVC configuration.
• containerOverrides
  • Optional: A list of objects that override specific parts of a container’s configuration.
• containerOverrides[].name
  • The name of the container to override in the workload specification.
• containerOverrides[].command
  • A new command for the container during this execution only. This field corresponds to workload.containers[].command in the workload specification.
• containerOverrides[].cpu
  • A new CPU configuration for the container during this execution. This field corresponds to workload.containers[].cpu in the workload specification.
• containerOverrides[].memory
  • A new memory allocation for the container during this execution. This field corresponds to workload.containers[].memory in the workload specification.
• containerOverrides[].image
  • A new image for the container during this execution. This field corresponds to workload.containers[].image in the workload specification.
• containerOverrides[].args
  • A new list of arguments for the container during this execution only. This field corresponds to workload.containers[].args in the workload specification.
• containerOverrides[].env
  • A new list of environment variables for the container during this execution only. This field corresponds to workload.containers[].env in the workload specification.

​

Run via the CLI

Run a cron workload using the cpln CLI via cpln workload cron start. e.g.

echo '[{"name":"my-container","command":"/bin/bash","args":["-c","sleep 10"],"env":[{"name":"MY_ENV_VAR","value":"some-new-value"}]}]' | cpln workload cron start cron --gvc my-gvc --org my-org --file -

​

Job History

A cron workload retains up to job.historyLimit job executions in its history. Each job execution will be in one of the following statuses:

• Invalid
• Active
• Success
• Failure
• Removed

​

The Removed Status

The Removed status indicates that a job execution was deleted before it could finish execution. There are several reasons this can happen, but the most common are:

• The job.concurrencyPolicy is Replace and while the job was still executing, job.Schedule dictated that the job should begin again.
• The job.activeDeadlineSeconds limit was exceeded.

​

Stateful

​

Overview

Stateful workloads are similar to standard and serverless workloads in many ways. Much of the base functionality including Universal Cloud Identity, metrics, logs, audit trail, etc. remains the same.

​

Capacity AI

Stateful workloads do not support Capacity AI. To optimize costs specify minCpu and minMemory

​

Autoscaling

Stateful workloads do not support concurrency-based horizontal autoscaling.

​

Cost Optimization

To reduce costs when using a stateful workload, set minCpu and minMemory to a low value. These values are used to reserve resources on Control Plane. In Kubernetes parlance, these values are the resource requests

​

minCpu

• minCpu and cpu can be at most 4000m apart
• The ratio between minCpu and cpu must be at least 1:4

​

minMemory

• minMemory and memory can be at most 4096Mi apart
• The ratio between minMemory and memory must be at least 1:4

​

Key Features

​

Stable Replica Identities

Each replica has a permanent identity. If a replica is rescheduled, restarted, or recreated for any reason, its identity will remain constant. Identities are of the form - e.g. for a workload called my-workload, the replica identities would be:

• my-workload-0
• my-workload-1
• etc.

​

Stable Hostnames

Each replica has a hostname corresponding to its identity. Hostnames are of the form {replicaIdentity}.{workloadName} e.g. for a workload called my-workload, the replica hostnames would be:

• my-workload-0.my-workload
• my-workload-1.my-workload
• etc.

So to make an HTTP request to a specific replica, one might execute:

curl http://my-workload-1.my-workload:8080 from another workload running on Control Plane

​

Persistent Storage

Stateful workloads can mount a volume set as a volume in one or more of its containers. To do this, simply add a volume to a container’s list of volumes of the form:

uri: cpln://volumeset/my-volume-set
path: /some/mount/directory

​

Considerations When Using Persistent Storage

• Volume sets are GVC scoped.
• A workload can only use volume sets in the same GVC.
• A volume set can be used by at most one workload (unless you use the shared file system type)
• A workload may use any number of volume sets.
• The volume set uri must begin with cpln://volumeset/.

​

Examples

​

PostgreSQL

This example demonstrates how to run a simple postgresql instance on Control Plane.

​

NATS

This example demonstrates how to run NATS on Control Plane.

​

Planned Features

• Access to a specific replica via the external endpoint. Currently, the external endpoint load-balances connections across all available replicas.