whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs/getting-started/rkt/: Pick rktnetes docs forward from release-1.3 branch in #741

Browse Source
This commit is contained in:
Josh Wood
2016-07-06 16:53:25 -07:00
parent 700cecea80
commit c85c543a8e
2 changed files with 224 additions and 222 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/getting-started-guides/rkt/notes.md
+68 -69
View File
@@ -1,99 +1,98 @@
---
---
# Notes on Different UX with rkt container runtime
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.
### Doesn't support ENTRYPOINT + CMD feature
## Non-existent host volume paths
To run a Docker image, rkt will convert it into [App Container Image (ACI) format](https://github.com/appc/spec/blob/master/SPEC.md) first.
However, during the conversion, the `ENTRYPOINT` and `CMD` are concatentated to construct ACI's `Exec` field.
This means after the conversion, we are not able to replace only `ENTRYPOINT` or `CMD` without touching the other part.
So for now, users are recommended to specify the **executable path** in `Command` and **arguments** in `Args`.
(This has the same effect if users specify the **executable path + arguments** in `Command` or `Args` alone).
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.
For example:
An example of a pod which will error out:
```yaml
apiVersion: v1
kind: Pod
metadata:
name: nginx
labels:
name: nginx
name: mount-dne
name: mount-dne
spec:
volumes:
- name: does-not-exist
hostPath:
path: /does/not/exist
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
- name: exit
image: busybox
command: ["sh", "-c", "ls /test; sleep 60"]
volumeMounts:
- mountPath: /test
name: does-not-exist
```
The above pod yaml file is valid as it's not specifying `Command` or `Args`, so the default `ENTRYPOINT` and `CMD` of the image will be used.
## Kubectl attach
The `kubectl attach` command does not work under the rkt container runtime.
Because of this, some flags in `kubectl run` are not supported, including:
* `--attach=true`
* `--leave-stdin-open=true`
* `--rm=true`
## Port forwarding for kvm and fly stage1s
`kubectl port-forward` is not supported for pods that are executed with `stage1-kvm` or `stage1-fly`.
## Volume relabeling
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](https://github.com/kubernetes/kubernetes/issues/28187) has the details.
## kubectl get logs
Under rktnetes, `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.
## Init containers
The alpha [init container](https://github.com/kubernetes/kubernetes/blob/master/docs/proposals/container-init.md) feature is currently not supported.
## Container restart back-off
Exponential restart back-off for a failing container is currently not supported.
## Experimental NVIDIA GPU support
The `--experimental-nvidia-gpus` flag, and related [GPU features](https://github.com/kubernetes/kubernetes/blob/master/docs/proposals/gpu-support.md) are not supported.
## QoS Classes
Under rkt, QoS classes do not adjust the `OOM Score` of containers as occurs under Docker.
## HostPID and HostIPC namespaces
Setting the hostPID or hostIPC flags on a pod is not supported.
For example, the following pod will not run correctly:
```yaml
apiVersion: v1
kind: Pod
metadata:
name: busybox
labels:
name: busybox
name: host-ipc-pid
name: host-ipc-pid
spec:
hostIPC: true
hostPID: true
containers:
- name: busybox
image: busybox
command:
- /bin/sleep
- 1000
...
```
```yaml
apiVersion: v1
kind: Pod
metadata:
name: busybox
labels:
name: busybox
spec:
containers:
- name: busybox
image: busybox
command:
- /bin/sleep
args:
- 1000
```
On the other hand, when running the pod with [stage1-fly](https://coreos.com/rkt/docs/latest/running-fly-stage1.html), the pod will be run in the host namespace.
```yaml
apiVersion: v1
kind: Pod
metadata:
name: busybox
labels:
name: busybox
spec:
containers:
- name: busybox
image: busybox
args:
- /bin/sleep
- 1000
```
## Container image updates (patch)
All the three examples above are valid as they contain both the executable path and the arguments.
Patching a pod to change the image will result in the entire pod restarting, not just the container that was changed.
```yaml
apiVersion: v1
kind: Pod
metadata:
name: busybox
labels:
name: busybox
spec:
containers:
- name: busybox
image: busybox
args:
- 1000
```
## Volume mounts specifying a subPath
The last example is invalid, as we cannot override just the `CMD` of the image alone.
The [subPath](https://github.com/kubernetes/kubernetes/pull/22575) 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.