Optional labels control the underlying compute resources of the Pod.
kind: Pod apiVersion: v1 metadata: name: .. labels: pod.staroid.com/isolation: sandboxed # 'sandboxed' or 'dedicated'. 'dedicated' schedule the Pod to the dedicated Node. Defaults to 'sandboxed'. pod.staroid.com/instance-type: standard-2 # 'standard-2', 'standard-4', 'standard-8', 'gpu-1'. Choose instance type for 'dedicated' mode. Defaults to 'standard-2'. pod.staroid.com/spot: false # 'true' or 'false'. 'true' uses Spot instance. Defaults to 'false'. spec: securityContext: runAsUser: 1000 # Must not be 0. Defaults to UID of the container image. runAsGroup: 3000 # Between 1-65535 fsGroup: 2000 # Define only for 'dedicated' Pod. 'sandboxed' will fail to start if it is defined. ...
spec.tolerations are ignored.
dedicated. Defaults to
sandboxedmakes Pod run containers using gVisor. It gives faster container creation in most cases and flexible cpu, memory configuration. Cpu, memory usage will be charged based on their actual consumption between minimum
dedicatedallocates a Node and schedule the Pod there. It gives higher IO performance and cheaper compute unit cost than the
sandboxed. However, creating a new Pod usually takes a much longer time and less flexibility on cpu and memory configuration. In this mode, Pod is charged based on
pod.staroid.com/instance-typeregardless of actual consumption.
gpu-1. Defaults to
standard-2. Only effective on
gpu-1instance type is available on AWS based cluster only, at this point.
Available cloud region
Tesla V100 (16GB)
false. Defaults to
Pod with spot
truemay experience some disruptions (such as Pod relocated to another Node) in every few hours. However, it provides significant cost savings.
Must not be
0. When not defined, the default UID of the container image will be used.
sandboxedPod will fail to start if it is defined.
Pod spec.serviceAccountName (experimental)¶
Staroid supports non-root containers. That’s why
spec.securityContext.runAsUsermust not be
0. Most applications able to run with non-root UID and this is usually a good practice. However, some applications require root permission. For example, the developer tool may want users to install additional os packages in the container.
rootif root UID is required.
For example,kind: Pod apiVersion: v1 metadata: name: .. spec: serviceAccountName: root securityContext: runAsUser: 0 ...
This is an experimental feature. Support for root UID can be changed in the future.