From 6bf50a4e9a94e82d07fc27062f38d4a45415dd89 Mon Sep 17 00:00:00 2001
From: j-u-e-f <46194606+j-u-e-f@users.noreply.github.com>
Date: Tue, 8 Jan 2019 15:08:23 +0200
Subject: [PATCH] fix a typo (#11923)

---
 content/en/docs/concepts/workloads/pods/pod.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/en/docs/concepts/workloads/pods/pod.md b/content/en/docs/concepts/workloads/pods/pod.md
index 677971ac48..45783625fd 100644
--- a/content/en/docs/concepts/workloads/pods/pod.md
+++ b/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'`