Move Commands and Capabilities out of User Guide.
This commit is contained in:
steveperry-53
@@ -0,0 +1,12 @@
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: command-demo
|
||||
labels:
|
||||
purpose: demonstrate-command
|
||||
spec:
|
||||
containers:
|
||||
- name: command-demo-container
|
||||
image: debian
|
||||
command: ["printenv"]
|
||||
args: ["HOSTNAME", "KUBERNETES_PORT"]
|
||||
@@ -0,0 +1,84 @@
|
||||
---
|
||||
title: Container Command and Arguments
|
||||
---
|
||||
|
||||
{% capture overview %}
|
||||
|
||||
In the configuration file for a Container, you can set the `command` and `args`
|
||||
fields to override the default Entrypoint and Cmd of the the Container's image.
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
{% capture body %}
|
||||
|
||||
## Container entry points and arguments
|
||||
|
||||
The configuration file for a Container has an `image` field that specifies the
|
||||
the Docker image to be run in the Container. A Docker image has metadata that includes
|
||||
a default Entrypoint and a default Cmd.
|
||||
|
||||
When Kubernetes starts a Container, it runs the image's default Entrypoint and
|
||||
passes the image's default Cmd as arguments.
|
||||
|
||||
If you want override the image's default Entrypoint and Cmd, you can use the
|
||||
`command` and `args` fields in the Container's configuration.
|
||||
|
||||
* The `command` field specifies the actual command run by the Container.
|
||||
* The `args` field specifies the arguments passed to the command.
|
||||
|
||||
This table summarizes the field names used by Docker and Kubernetes.
|
||||
|
||||
| Description | Docker field name | Kubernetes field name |
|
||||
|----------------------------------------|------------------------|-----------------------|
|
||||
| The command run by the container | Entrypoint | command |
|
||||
| The arguments passed to the command | Cmd | args |
|
||||
|
||||
Here's an example of a configuration file for a Pod that has one Container.
|
||||
|
||||
{% include code.html language="yaml" file="commands.yaml" ghlink="/docs/concepts/configuration/commands.yaml" %}
|
||||
|
||||
When Kubernetes starts the Container, it runs this command:
|
||||
|
||||
```shell
|
||||
printenv HOSTNAME KUBERNETES_PORT
|
||||
```
|
||||
|
||||
When you override the default Entrypoint and Cmd, these rules apply:
|
||||
|
||||
* If you do not supply `command` or `args` for a Container, the defaults defined
|
||||
in the Docker image are used.
|
||||
|
||||
* If you supply a `command` but no `args` for a Container, only the supplied
|
||||
`command` is used. The default EntryPoint and the default Cmd defined in the Docker
|
||||
image are ignored.
|
||||
|
||||
* If you supply only `args` for a Container, the default Entrypoint defined in
|
||||
the Docker image is run with the `args` that you supplied.
|
||||
|
||||
* If you supply a `command` and `args`, the default Entrypoint and the default
|
||||
Cmd defined in the Docker image are ignored. Your `command` is run with your
|
||||
`args`.
|
||||
|
||||
Here are some examples:
|
||||
|
||||
| Image Entrypoint | Image Cmd | Container command | Container args | Command run |
|
||||
|--------------------|------------------|---------------------|--------------------|------------------|
|
||||
| `[/ep-1]` | `[foo bar]` | <not set> | <not set> | `[ep-1 foo bar]` |
|
||||
| `[/ep-1]` | `[foo bar]` | `[/ep-2]` | <not set> | `[ep-2]` |
|
||||
| `[/ep-1]` | `[foo bar]` | <not set> | `[zoo boo]` | `[ep-1 zoo boo]` |
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
{% capture whatsnext %}
|
||||
|
||||
* [Defining a Command and Arguments for a Container](/docs/tasks/configure-pod-container/define-command-argument-container/)
|
||||
|
||||
* [Running Commands in a Container with kubectl exec](/docs/user-guide/getting-into-containers/)
|
||||
|
||||
* [Container](/docs/api-reference/v1/definitions/#_v1_container)
|
||||
|
||||
* [Docker Entrypoint field](https://docs.docker.com/engine/reference/builder/)
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
{% include templates/concept.md %}
|
||||
@@ -0,0 +1,102 @@
|
||||
---
|
||||
title: Container Capabilities
|
||||
---
|
||||
|
||||
{% capture overview %}
|
||||
|
||||
You can specify Container capabilities by using the `securityContext` field of a
|
||||
Container's configuration.
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
{% capture body %}
|
||||
|
||||
## Capabilities
|
||||
|
||||
By default, Docker containers are unprivileged. For example, in the default case,
|
||||
you cannot run a Docker daemon inside a Docker container. To give you control
|
||||
over a container's capabilities, Docker supports `cap-add`
|
||||
and `cap-drop`. For more details, see
|
||||
[Runtime privilege and Linux capabilities](https://docs.docker.com/engine/reference/run/#/runtime-privilege-and-linux-capabilities).
|
||||
|
||||
This table shows the relationship between Docker capabilities and
|
||||
[Linux capabilities](http://man7.org/linux/man-pages/man7/capabilities.7.html):
|
||||
|
||||
| Docker's capabilities | Linux capabilities |
|
||||
| ---- | ---- |
|
||||
| SETPCAP | CAP_SETPCAP |
|
||||
| SYS_MODULE | CAP_SYS_MODULE |
|
||||
| SYS_RAWIO | CAP_SYS_RAWIO |
|
||||
| SYS_PACCT | CAP_SYS_PACCT |
|
||||
| SYS_ADMIN | CAP_SYS_ADMIN |
|
||||
| SYS_NICE | CAP_SYS_NICE |
|
||||
| SYS_RESOURCE | CAP_SYS_RESOURCE |
|
||||
| SYS_TIME | CAP_SYS_TIME |
|
||||
| SYS_TTY_CONFIG | CAP_SYS_TTY_CONFIG |
|
||||
| MKNOD | CAP_MKNOD |
|
||||
| AUDIT_WRITE | CAP_AUDIT_WRITE |
|
||||
| AUDIT_CONTROL | CAP_AUDIT_CONTROL |
|
||||
| MAC_OVERRIDE | CAP_MAC_OVERRIDE |
|
||||
| MAC_ADMIN | CAP_MAC_ADMIN |
|
||||
| NET_ADMIN | CAP_NET_ADMIN |
|
||||
| SYSLOG | CAP_SYSLOG |
|
||||
| CHOWN | CAP_CHOWN |
|
||||
| NET_RAW | CAP_NET_RAW |
|
||||
| DAC_OVERRIDE | CAP_DAC_OVERRIDE |
|
||||
| FOWNER | CAP_FOWNER |
|
||||
| DAC_READ_SEARCH | CAP_DAC_READ_SEARCH |
|
||||
| FSETID | CAP_FSETID |
|
||||
| KILL | CAP_KILL |
|
||||
| SETGID | CAP_SETGID |
|
||||
| SETUID | CAP_SETUID |
|
||||
| LINUX_IMMUTABLE | CAP_LINUX_IMMUTABLE |
|
||||
| NET_BIND_SERVICE | CAP_NET_BIND_SERVICE |
|
||||
| NET_BROADCAST | CAP_NET_BROADCAST |
|
||||
| IPC_LOCK | CAP_IPC_LOCK |
|
||||
| IPC_OWNER | CAP_IPC_OWNER |
|
||||
| SYS_CHROOT | CAP_SYS_CHROOT |
|
||||
| SYS_PTRACE | CAP_SYS_PTRACE |
|
||||
| SYS_BOOT | CAP_SYS_BOOT |
|
||||
| LEASE | CAP_LEASE |
|
||||
| SETFCAP | CAP_SETFCAP |
|
||||
| WAKE_ALARM | CAP_WAKE_ALARM |
|
||||
| BLOCK_SUSPEND | CAP_BLOCK_SUSPEND |
|
||||
|
||||
In Kubernetes, you can add or drop capabilities in the
|
||||
[`SecurityContext`](/docs/resources-reference/v1.5/#securitycontext-v1)
|
||||
field of a Container:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: hello-world
|
||||
spec:
|
||||
containers:
|
||||
- name: friendly-container
|
||||
image: "alpine:3.4"
|
||||
command: ["/bin/echo", "hello", "world"]
|
||||
securityContext:
|
||||
capabilities:
|
||||
add:
|
||||
- SYS_NICE
|
||||
drop:
|
||||
- KILL
|
||||
```
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
{% capture whatsnext %}
|
||||
|
||||
* [Security Context](/docs/user-guide/security-context/)
|
||||
|
||||
* [Pod Security Policy](/docs/user-guide/pod-security-policy/)
|
||||
|
||||
* [SecurityContext](/docs/resources-reference/v1.5/#securitycontext-v1)
|
||||
|
||||
* [Container](/docs/api-reference/v1/definitions/#_v1_container)
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
{% include templates/concept.md %}
|
||||
|
||||
Reference in New Issue
Block a user