clarify from feedback

This commit is contained in:
Tim Allclair 2018-06-28 16:54:04 -07:00
parent b6a138d14b
commit b1f75bde90
No known key found for this signature in database
GPG Key ID: 434D16BCEF479EAB
1 changed files with 3 additions and 4 deletions

View File

@ -40,8 +40,7 @@ status: provisional
`RuntimeClass` is a new cluster-scoped resource that surfaces container runtime properties to the
control plane. RuntimeClasses are assigned to pods through a `runtimeClass` field on the
`PodSpec`. This provides a new mechanism for supporting multiple runtimes in the cluster and on the
nodes.
`PodSpec`. This provides a new mechanism for supporting multiple runtimes in a cluster and/or node.
## Motivation
@ -107,7 +106,7 @@ iteration:
- As a cluster operator, I want to provide multiple runtime options to support a wide variety of
workloads. Examples include native linux containers, "sandboxed" containers, and windows
containers.
- As a cluster operator, I want to provide stable rolling upgrades of nodes or runtimes. For
- As a cluster operator, I want to provide stable rolling upgrades or runtimes. For
example, rolling out an update with backwards incompatible changes or previously unsupported
features.
- As an application developer, I want to select the runtime that best fits my workload.
@ -355,7 +354,7 @@ Beta:
limited to linux. As we build out Windows container support, we'll need to add windows-specific
features as well.
- Host namespaces (Network,PID,IPC) may not be supported by virtualization-based runtimes
(e.g. Kata-containers & visor).
(e.g. Kata-containers & gVisor).
- Per-pod and Per-container resource overhead varies by runtime.
- Device support (e.g. GPUs) varies wildly by runtime & nodes.
- Supported volume types varies by node - it remains TBD whether this information belongs in