The following features either are not supported or have large caveats when using the rkt container runtime. Increasing support for these items and others, including reasonable feature parity with the default container engine, is planned through future releases.
When mounting a host volume path that does not exist, rkt will error out. Under the Docker runtime, an empty directory will be created at the referenced path.
An example of a pod which will error out:
- name: does-not-exist
- name: exit
command: ["sh", "-c", "ls /test; sleep 60"]
- mountPath: /test
kubectl attach command does not work under the rkt container runtime.
Because of this, some flags in
kubectl run are not supported, including:
kubectl port-forward is not supported for pods that are executed with
Currently rkt supports only per-pod volume relabeling. After relabeling, the mounted volume is shared by all containers in the pod. There is not yet a way to make the relabeled volume accessible to only one, or some subset, of containers in the pod. Kubernetes issue # 28187 has the details.
kubectl get logs currently cannot get logs from applications that write them to directly to
/dev/stdout. Currently such log messages are printed on the node’s console.
The alpha init container feature is currently not supported.
Exponential restart back-off for a failing container is currently not supported.
--experimental-nvidia-gpus flag, and related GPU features are not supported.
Under rkt, QoS classes do not adjust the
OOM Score of containers as occurs under Docker.
Setting the hostPID or hostIPC flags on a pod is not supported.
For example, the following pod will not run correctly:
On the other hand, when running the pod with stage1-fly, the pod will be run in the host namespace.
Patching a pod to change the image will result in the entire pod restarting, not just the container that was changed.
The subPath feature does not work correctly under rkt. In addition, the issue of non-existent host volume paths being invalid, mentioned above, would cause many common use cases for subPaths to fail in the same way. In some cases, this issue can be worked around by creating and using subdirectories from within the container, rather than relying on Kubernetes to do so.