Permalink
Browse files

fix a typo (#11923)

  • Loading branch information...
j-u-e-f authored and k8s-ci-robot committed Jan 8, 2019
1 parent 0a0655c commit 6bf50a4e9a94e82d07fc27062f38d4a45415dd89
Showing with 1 addition and 1 deletion.
  1. +1 −1 content/en/docs/concepts/workloads/pods/pod.md
@@ -191,7 +191,7 @@ Force deletions can be potentially dangerous for some pods and should be perform

From Kubernetes v1.1, any container in a pod can enable privileged mode, using the `privileged` flag on the `SecurityContext` of the container spec. This is useful for containers that want to use linux capabilities like manipulating the network stack and accessing devices. Processes within the container get almost the same privileges that are available to processes outside a container. With privileged mode, it should be easier to write network and volume plugins as separate pods that don't need to be compiled into the kubelet.

If the master is running Kubernetes v1.1 or higher, and the nodes are running a version lower than v1.1, then new privileged pods will be accepted by api-server, but will not be launched. They will be pending state.
If the master is running Kubernetes v1.1 or higher, and the nodes are running a version lower than v1.1, then new privileged pods will be accepted by api-server, but will not be launched. They will be in pending state.
If user calls `kubectl describe pod FooPodName`, user can see the reason why the pod is in pending state. The events table in the describe command output will say:
`Error validating pod "FooPodName"."FooPodNamespace" from api, ignoring: spec.containers[0].securityContext.privileged: forbidden '<*>(0xc2089d3248)true'`

0 comments on commit 6bf50a4

Please sign in to comment.