Runtime Classes

Thalassa Cloud Kubernetes supports multiple container runtimes to provide flexibility and enhanced security for different workload requirements. You can choose the appropriate runtime based on your security, performance, and isolation needs.

Overview

Container runtimes are responsible for running containers on your Kubernetes nodes. Thalassa Cloud offers three runtime options, each providing different levels of security isolation and performance characteristics:

Supported Runtimes

containerd (Default)

containerd is the default and recommended runtime for most workloads. It provides excellent performance and compatibility with standard container images.

Key Features:

• High performance and low overhead
• Full compatibility with OCI images
• Native support for all container features
• Optimized for production workloads

Best For:

• General-purpose applications
• Development and testing environments
• Workloads requiring maximum performance
• Applications with standard security requirements

gVisor

gVisor provides an additional security layer by running containers in a userspace kernel. It offers strong isolation while maintaining good performance.

Key Features:

• Strong security isolation through userspace kernel
• Protection against kernel exploits
• Compatible with most containerized applications
• Minimal performance overhead compared to VMs

Best For:

• Multi-tenant environments
• Untrusted workloads
• Applications requiring enhanced security isolation
• Compliance requirements for workload isolation

Kata Containers (Roadmap)

Kata Containers will provide the highest level of isolation by running each container in its own lightweight virtual machine.

Configuration

Available Runtime Classes

Thalassa Cloud provides the following runtime classes:

Using Runtime Classes

To specify a runtime for your pods, use the runtimeClassName field in your pod specification:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  runtimeClassName: gvisor # Leave empty for default containerd
  containers:
    - name: my-container
      image: nginx:latest
      resources:
        requests:
          memory: "64Mi"
          cpu: "250m"
        limits:
          memory: "128Mi"
          cpu: "500m"

Note: If you don’t specify a runtimeClassName (or leave it empty), pods will use the default containerd runtime.

Examples

Standard Workload with containerd

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
    spec:
      # runtimeClassName not specified - uses default containerd
      containers:
        - name: web
          image: nginx:latest
          ports:
            - containerPort: 80

Secure Workload with gVisor

apiVersion: apps/v1
kind: Deployment
metadata:
  name: secure-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: secure-app
  template:
    metadata:
      labels:
        app: secure-app
    spec:
      runtimeClassName: gvisor
      containers:
        - name: secure-container
          image: alpine:latest
          command: ["/bin/sh"]
          args:
            [
              "-c",
              "while true; do echo 'Secure workload running'; sleep 30; done",
            ]
          securityContext:
            runAsNonRoot: true
            runAsUser: 1000

Resource Requirements

Different runtimes have varying resource overheads that you should consider when planning your workloads: