WIP for 1.12 Cinder now supports raw block volume

config.toml

@@ -45,17 +45,24 @@ time_format_blog = "Monday, January 02, 2006"
 description = "Production-Grade Container Orchestration"
 showedit = true
 
-latest = "v1.10"
+latest = "v1.11"
 
-fullversion = "v1.10.3"
-version = "v1.10"
+fullversion = "v1.11.0"
+version = "v1.11"
 githubbranch = "master"
-docsbranch = "master"
+docsbranch = "release-1.11"
 deprecated = false
 currentUrl = "https://kubernetes.io/docs/home/"
 nextUrl = "http://kubernetes-io-vnext-staging.netlify.com/"
 githubWebsiteRepo = "github.com/kubernetes/website"
 
+[[params.versions]]
+fullversion = "v1.11.0"
+version = "v1.11"
+githubbranch = "v1.11.0"
+docsbranch = "release-1.11"
+url = "https://kubernetes.io"
+
 [[params.versions]]
 fullversion = "v1.10.3"
 version = "v1.10"

content/en/docs/concepts/architecture/nodes.md

@@ -46,6 +46,7 @@ The `conditions` field describes the status of all `Running` nodes.
 | `OutOfDisk`    | `True` if there is insufficient free space on the node for adding new pods, otherwise `False` |
 | `Ready`        | `True` if the node is healthy and ready to accept pods, `False` if the node is not healthy and is not accepting pods, and `Unknown` if the node controller has not heard from the node in the last `node-monitor-grace-period` (default is 40 seconds) |
 | `MemoryPressure`    | `True` if pressure exists on the node memory -- that is, if the node memory is low; otherwise `False` |
+| `PIDPressure`    | `True` if pressure exists on the processes -- that is, if there are too many processes on the node; otherwise `False` |
 | `DiskPressure`    | `True` if pressure exists on the disk size -- that is, if the disk capacity is low; otherwise `False` |
 | `NetworkUnavailable`    | `True` if the network for the node is not correctly configured, otherwise `False` |
 | `ConfigOK`    | `True` if the kubelet is correctly configured, otherwise `False` |

content/en/docs/concepts/configuration/manage-compute-resources-container.md

@@ -144,9 +144,7 @@ When using Docker:
   multiplied by 100. The resulting value is the total amount of CPU time that a container can use
   every 100ms. A container cannot use more than its share of CPU time during this interval.
 
-  {{< note >}}
-  **Note**: The default quota period is 100ms. The minimum resolution of CPU quota is 1ms.
-  {{< /note >}}
+  {{< note >}}**Note**: The default quota period is 100ms. The minimum resolution of CPU quota is 1ms.{{ {{</ note >}}}
 
 - The `spec.containers[].resources.limits.memory` is converted to an integer, and
   used as the value of the
@@ -209,12 +207,10 @@ $ kubectl describe nodes e2e-test-minion-group-4lw4
 Name:            e2e-test-minion-group-4lw4
 [ ... lines removed for clarity ...]
 Capacity:
- alpha.kubernetes.io/nvidia-gpu:    0
  cpu:                               2
  memory:                            7679792Ki
  pods:                              110
 Allocatable:
- alpha.kubernetes.io/nvidia-gpu:    0
  cpu:                               1800m
  memory:                            7474992Ki
  pods:                              110
@@ -300,10 +296,10 @@ Container in the Pod was terminated and restarted five times.
 You can call `kubectl get pod` with the `-o go-template=...` option to fetch the status
 of previously terminated Containers:
 
-```shell
+```shell{% raw %}
 [13:59:01] $ kubectl get pod -o go-template='{{range.status.containerStatuses}}{{"Container Name: "}}{{.name}}{{"\r\nLastState: "}}{{.lastState}}{{end}}'  simmemleak-hra99
 Container Name: simmemleak
-LastState: map[terminated:map[exitCode:137 reason:OOM Killed startedAt:2015-07-07T20:58:43Z finishedAt:2015-07-07T20:58:43Z containerID:docker://0e4095bba1feccdfe7ef9fb6ebffe972b4b14285d5acdec6f0d3ae8a22fad8b2]]
+LastState: map[terminated:map[exitCode:137 reason:OOM Killed startedAt:2015-07-07T20:58:43Z finishedAt:2015-07-07T20:58:43Z containerID:docker://0e4095bba1feccdfe7ef9fb6ebffe972b4b14285d5acdec6f0d3ae8a22fad8b2]]{% endraw %}
 ```
 
 You can see that the Container was terminated because of `reason:OOM Killed`,
@@ -545,6 +541,4 @@ consistency across providers and platforms.
 
 * [ResourceRequirements](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcerequirements-v1-core)
 
-{{% /capture %}}
-
-
+{{% /capture %}}

content/en/docs/concepts/configuration/pod-priority-preemption.md

@@ -59,6 +59,26 @@ scheduler. After the feature is disabled, the existing Pods keep their priority
 fields, but preemption is disabled, and priority fields are ignored, and you
 cannot set `priorityClassName` in new Pods.
 
+## How to disable preemption
+
+In Kubernetes 1.11 and later, preemption is controlled by a kube-scheduler flag `disablePreemption`, which is set to `false` by default.
+
+If you want to disable preemption, just set `disablePreemption` to true. This will keep pod priority enabled while preemption is disabled. Here is a sample configuration:
+
+```yaml
+apiVersion: componentconfig/v1alpha1
+kind: KubeSchedulerConfiguration
+algorithmSource:
+  provider: DefaultProvider
+
+...
+
+disablePreemption: true
+
+```
+
+Please note: although preemption of scheduler is enabled by default, preemption will not happen if `PodPriority` feature is not available.
+
 ## PriorityClass
 
 A PriorityClass is a non-namespaced object that defines a mapping from a priority

content/en/docs/concepts/configuration/taint-and-toleration.md

@@ -204,23 +204,23 @@ running on the node as follows
  * pods that tolerate the taint with a specified `tolerationSeconds` remain
    bound for the specified amount of time
 
-In addition, Kubernetes 1.6 has alpha
-support for representing node problems. In other words, the node controller
-automatically taints a node when certain condition is true. The built-in taints
-currently include:
+In addition, Kubernetes 1.6 introduced alpha support for representing node
+problems. In other words, the node controller automatically taints a node when
+certain condition is true. The following taints are built in:
 
  * `node.kubernetes.io/not-ready`: Node is not ready. This corresponds to
    the NodeCondition `Ready` being "`False`".
- * `node.alpha.kubernetes.io/unreachable`: Node is unreachable from the node
+ * `node.kubernetes.io/unreachable`: Node is unreachable from the node
    controller. This corresponds to the NodeCondition `Ready` being "`Unknown`".
  * `node.kubernetes.io/out-of-disk`: Node becomes out of disk.
  * `node.kubernetes.io/memory-pressure`: Node has memory pressure.
  * `node.kubernetes.io/disk-pressure`: Node has disk pressure.
  * `node.kubernetes.io/network-unavailable`: Node's network is unavailable.
- * `node.cloudprovider.kubernetes.io/uninitialized`: When kubelet is started
-   with "external" cloud provider, it sets this taint on a node to mark it
-   as unusable. When a controller from the cloud-controller-manager initializes
-   this node, kubelet removes this taint.
+ * `node.kubernetes.io/unschedulable`: Node is unschedulable.
+ * `node.cloudprovider.kubernetes.io/uninitialized`: When the kubelet is started
+    with "external" cloud provider, this taint is set on a node to mark it
+    as unusable. After a controller from the cloud-controller-manager initializes
+    this node, the kubelet removes this taint.
 
 When the `TaintBasedEvictions` alpha feature is enabled (you can do this by
 including `TaintBasedEvictions=true` in `--feature-gates` for Kubernetes controller manager,
@@ -277,17 +277,15 @@ Version 1.8 introduces an alpha feature that causes the node controller to creat
 Node conditions. When this feature is enabled (you can do this by including `TaintNodesByCondition=true` in the `--feature-gates` command line flag to the scheduler, such as
 `--feature-gates=FooBar=true,TaintNodesByCondition=true`), the scheduler does not check Node conditions; instead the scheduler checks taints. This assures that Node conditions don't affect what's scheduled onto the Node. The user can choose to ignore some of the Node's problems (represented as Node conditions) by adding appropriate Pod tolerations.
 
-To make sure that turning on this feature doesn't break DaemonSets, starting in version 1.8, the  DaemonSet controller automatically adds the following `NoSchedule` tolerations to all daemons:
+Starting in Kubernetes 1.8, the DaemonSet controller automatically adds the
+following `NoSchedule` tolerations to all daemons, to prevent DaemonSets from
+breaking.
 
   * `node.kubernetes.io/memory-pressure`
   * `node.kubernetes.io/disk-pressure`
   * `node.kubernetes.io/out-of-disk` (*only for critical pods*)
+  * `node.kubernetes.io/unschedulable` (1.10 or later)
+  * `node.kubernetes.io/network-unavailable` (*host network only*)
 
-The above settings ensure backward compatibility, but we understand they may not fit all user's needs, which is why
-cluster admin may choose to add arbitrary tolerations to DaemonSets.
-
-{{% /capture %}}
-
-{{% capture whatsnext %}}
-
-{{% /capture %}}
+Adding these tolerations ensures backward compatibility. You can also add
+arbitrary tolerations to DaemonSets.

content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md

@@ -8,7 +8,11 @@ weight: 20
 ---
 
 {{% capture overview %}}
-This page explains [*custom resources*](/docs/concepts/api-extension/custom-resources/), which are extensions of the Kubernetes API. This page explains when to add a custom resource to your Kubernetes cluster and when to use a standalone service. It describes the two methods for adding custom resources and how to choose between them.
+
+This page explains *custom resources*, which are extensions of the Kubernetes
+API, including when to add a custom resource to your Kubernetes cluster and when
+to use a standalone service. It describes the two methods for adding custom
+resources and how to choose between them.
 
 {{% /capture %}}
 
@@ -103,20 +107,20 @@ Use a custom resource (CRD or Aggregated API) if most of the following apply:
 
 Kubernetes provides two ways to add custom resources to your cluster:
 
-- [Custom Resource Definitions](/docs/concepts/api-extension/custom-resources/) (CRDs) are easier to use: they do not require any programming in some cases.
+- CRDs are simple and can be created without any programming.
 - [API Aggregation](/docs/concepts/api-extension/apiserver-aggregation/) requires programming, but allows more control over API behaviors like how data is stored and conversion between API versions.
 
 Kubernetes provides these two options to meet the needs of different users, so that neither ease of use nor flexibility are compromised.
 
 Aggregated APIs are subordinate APIServers that sit behind the primary API server, which acts as a proxy. This arrangement is called [API Aggregation](/docs/concepts/api-extension/apiserver-aggregation/) (AA). To users, it simply appears that the Kubernetes API is extended.
 
-Custom Resource Definitions (CRDS) allow users to create new types of resources without adding another APIserver. You do not need to understand API Aggregation to use CRDs.
+CRDs allow users to create new types of resources without adding another APIserver. You do not need to understand API Aggregation to use CRDs.
 
-Regardless of whether they are installed via CRDs or AA, the new resources are called Custom Resources to distinguish them from built-in Kubernetes resources (like pods).
+Regardless of how they are installed, the new resources are referred to as Custom Resources to distinguish them from built-in Kubernetes resources (like pods).
 
 ## CustomResourceDefinitions
 
-The [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/) (CRD) API resource allows you to define custom resources. Defining a CRD object creates a new custom resource with a name and schema that you specify. The Kubernetes API serves and handles the storage of your custom resource.
+The [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/) API resource allows you to define custom resources. Defining a CRD object creates a new custom resource with a name and schema that you specify. The Kubernetes API serves and handles the storage of your custom resource.
 
 This frees you from writing your own API server to handle the custom resource,
 but the generic nature of the implementation means you have less flexibility than with
@@ -132,7 +136,7 @@ and setup a controller to handle events.
 
 ## API server aggregation
 
-Usually, each resource in the Kubernetes API requires code that handles REST requests and manages persistent storage of objects. The main Kubernetes API server handles built-in resources like *pods* and *services*, and can also handle custom resources in a generic way through [CustomResourceDefinitions](#customresourcedefinitions).
+Usually, each resource in the Kubernetes API requires code that handles REST requests and manages persistent storage of objects. The main Kubernetes API server handles built-in resources like *pods* and *services*, and can also handle custom resources in a generic way through [CRDs](#customresourcedefinitions).
 
 The [aggregation layer](/docs/concepts/api-extension/apiserver-aggregation/) allows you to provide specialized
 implementations for your custom resources by writing and deploying your own standalone API server.
@@ -152,7 +156,7 @@ Typically, CRDs are a good fit if:
 
 CRDs are easier to create than Aggregated APIs.
 
-| Custom Resource Definitions | Aggregated API |
+| CRDs                        | Aggregated API |
 | --------------------------- | -------------- |
 | Do not require programming. Users can choose any language for a CRD controller. | Requires programming in Go and building binary and image. Users can choose any language for a CRD controller. |
 | No additional service to run; CRs are handled by API Server. | An additional service to create and that could fail. |

content/en/docs/concepts/policy/pod-security-policy.md

@@ -414,19 +414,27 @@ minimum value of the first range as the default. Validates against all ranges.
 to be used by hostPath volumes. An empty list means there is no restriction on
 host paths used. This is defined as a list of objects with a single `pathPrefix`
 field, which allows hostPath volumes to mount a path that begins with an
-allowed prefix. For example:
+allowed prefix, and a `readOnly` field indicating it must be mounted read-only.
+For example:
 
 ```yaml
 allowedHostPaths:
   # This allows "/foo", "/foo/", "/foo/bar" etc., but
   # disallows "/fool", "/etc/foo" etc.
   # "/foo/../" is never valid.
   - pathPrefix: "/foo"
+    readOnly: true # only allow read-only mounts
 ```
 
-_Note: There are many ways a container with unrestricted access to the host
+{{< warning >}}**Warning:** There are many ways a container with unrestricted access to the host 
 filesystem can escalate privileges, including reading data from other
-containers, and abusing the credentials of system services, such as Kubelet._
+containers, and abusing the credentials of system services, such as Kubelet.
+
+Writeable hostPath directory volumes allow containers to write 
+to the filesystem in ways that let them traverse the host filesystem outside the `pathPrefix`.
+`readOnly: true`, available in Kubernetes 1.11+, must be used on **all** `allowedHostPaths`
+to effectively limit access to the specified `pathPrefix`.
+{{< /warning >}}
 
 **ReadOnlyRootFilesystem** - Requires that containers must run with a read-only
 root filesystem (i.e. no writable layer).