Skip to content

Commit

Permalink
blog: add runtimeclassnames post
Browse files Browse the repository at this point in the history
WIP
  • Loading branch information
BobyMCbobs committed Nov 17, 2024
1 parent 421c8e4 commit 16644ea
Show file tree
Hide file tree
Showing 2 changed files with 66 additions and 0 deletions.
1 change: 1 addition & 0 deletions blog/config/nav.yml
Original file line number Diff line number Diff line change
Expand Up @@ -49,6 +49,7 @@ nav:
- releases/announcing-knative-v0-3-release.md
- releases/announcing-knative-v0-2-release.md
- Articles:
- articles/configurable-runtimeclassnames.md
- articles/consuming_sqs_data_with_integrationsource.md
- articles/knative-backstage-security.md
- articles/Knative-Serving-WebSockets.md
Expand Down
65 changes: 65 additions & 0 deletions blog/docs/articles/configurable-runtimeclassnames.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,65 @@
# Configurable RuntimeClassNames

**Author: Caleb Woodbine**

Starting in Knative Serving v1.15, administrators are now able to configure the default the RuntimeClassName field for deployments as default and via a Knative Service label selector.

## Runtime Classes

**What is a Runtime Class?**

A Runtime Class for configuring the handler program installed on the node that runs a container, such as `runc`, `crun`, `runsc`, `nvidia` or `kata`.

See documentation at the [Kubernetes docs here](https://kubernetes.io/docs/concepts/containers/runtime-class/).

## Existing configuration options

There are several feature flags in Knative Serving, one of which is enabling the field `.spec.template.spec.runtimeClassName` in Knative Service.

This may be useful for self-service and is a helpful feature flag.

See the documentation [here](https://knative.dev/docs/serving/configuration/feature-flags/#kubernetes-runtime-class).

## Configuring Knative

Knative is able to be configured with either the ConfigMaps if deployed with plain manifests or the KnativeServing resource if deployed with the operator. The following examples will be using just the plain manifests.

See this example where Knative will configure deployments managed by Knative through Services to use Kata by default or gVisor when the Knative Service has a label matching `my-label=selector`:

```yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: config-deployment
namespace: knative-serving
data:
runtime-class-name: |
kata: {}
gvisor:
selector:
my-label: selector
```
The keys, like `kata` and `gvisor` must match existing Kubernetes RuntimeClasses.

(For the above config, it may not necessarily make sense for real world use but does display how it can be configured)

For Knative docs, [see here](https://knative.dev/docs/serving/configuration/deployment/#configuring-selectable-runtimeclassname).

## Why is this important?

RuntimeClasses enable several things, including:

- security
- isolation such as through Kata or gVisor
- functionality
- such as enabling GPU or WASM support

For example, a cluster administrator or cloud provider may wish to configure Knative to specificly not use `runc` to run untrusted workloads that would be deployed by users on their platform.

## Closing

Runtime Classes are an important piece in container platform infrastructure.
Whether you're setting up a platform for production or just playing around, Runtime Classes can enhance or lockdown your workloads.

Now with the Knative Serving deployment configuration settings for RuntimeClass, there's even more ability to configure Knative Services in a locked down and specific manner.

0 comments on commit 16644ea

Please sign in to comment.