Skip to content

Latest commit

 

History

History
144 lines (102 loc) · 6.26 KB

workloads.md

File metadata and controls

144 lines (102 loc) · 6.26 KB
Raw

Workloads

The workload type (workloadType) is a field in the component schematic used by the developer to direct the runtime to properly execute the given component. Workload types are container-based and distinguished by the following characteristics:

  • Whether they have a service endpoint: an automatically assigned virtual IP address and DNS name addressable within the network scope to which the component belongs.
  • Whether they are replicable: An application operator can increase or decrease the number of component replicas by applying and configuring traits when available.
  • Whether they are daemonized: Rudr will attempt to restart replicas that exit, regardless of error code.

Rudr supports all of the Open Application Model Core Workload Types:

Name Type Service endpoint Replicable Daemonized
Server core.oam.dev/v1alpha1.Server Yes Yes Yes
Singleton Server core.oam.dev/v1alpha1.SingletonServer Yes No Yes
Task core.oam.dev/v1alpha1.Task No Yes No
Singleton Task core.oam.dev/v1alpha1.SingletonTask No No No
Worker core.oam.dev/v1alpha1.Worker No Yes Yes
Singleton Worker core.oam.dev/v1alpha1.SingletonWorker No No Yes

Workload types are assigned to components as part of the developer role. They indicate to the application operator what trait(s) in the application configuration that the component might require.

Workloads are named using the GROUP/VERSION.KIND Kubernetes convention, where GROUP is a uniquely named service collection, VERSION is an API version, and KIND is a group-unique name of a service. For example:

apiVersion: core.oam.dev/v1alpha1
kind: ComponentSchematic
metadata:
  name: alpine-forever-v1
spec:
  workloadType: core.oam.dev/v1alpha1.SingletonServer
  parameters:
    - name: message
           type: string
           required: false
    - name: unused_integer
           type: number
           required: false
           default: 5678
  containers:
    - name: runner
      image: technosophos/alpine-forever:latest
      env:
      - name: FOO
        value: bar
        fromParam: message
      - name: UNUSED
        value: "1234"
        fromParam: unused_integer

For more on specific workload types, refer to the sections below.

Server

A Server is used for a long-running, scalable workload with a network endpoint and stable name to receive network traffic for the component as a whole. Common use cases include web applications and services that expose APIs.

The Server workload in Rudr is implemented by a Kubernetes Deployment binding with a Kubernetes Service.

Workload details

Type Service endpoint Replicable Daemonized
core.oam.dev/v1alpha1.Server ☑ ☑ ☑

Supported traits

Singleton Server

A Singleton Server is a special case of the Server workload type that is limited to at most one replica of the container being run at a time.

IMPORTANT: Operators should not attempt to modify the replicaCount on a Deployment created by a SingletonServer.

The Singleton Server in Rudr is implemented by a Kubernetes Deployment binding with a Kubernetes Service.

Workload details

Type Service endpoint Replicable Daemonized
core.oam.dev/v1alpha1.SingletonServer ☑ ☑

Supported traits

Task

A Task is used to run code or a script to completion. Its commonly used to run cron jobs or one-time highly parallelizable tasks that exit and free up resources upon completion.

The Task in Rudr is implemented by a Kubernetes Job.

Workload details

Type Service endpoint Replicable Daemonized
core.oam.dev/v1alpha1.Task ☑

Supported traits

Singleton Task

A Singleton Task is a special case of the task workload type that is limited to at most one replica of the container being run at a time.

It is implemented by a Kubernetes Job.

Workload details

Type Service endpoint Replicable Daemonized
core.oam.dev/v1alpha1.SingletonTask

Supported traits

Worker

A Worker is used for long-running, scalable workloads that do not have a service endpoint for network requests, aside from optional liveliness and readiness probe endpoints on individual replicas. Workers are typically used to pull from queues or provide other offline processing.

Workload details

Type Service endpoint Replicable Daemonized
core.oam.dev/v1alpha1.Worker ☑ ☑

Supported traits

Singleton Worker

A singleton worker is a special case of the worker workload type that is limited to at most one replica of the container being run at a time.

Workload details

Type Service endpoint Replicable Daemonized
core.oam.dev/v1alpha1.SingletonWorker ☑

Supported traits