[Do Not Merge] Release 1.12

config.toml

@@ -63,10 +63,10 @@ time_format_blog = "Monday, January 02, 2006"
 description = "Production-Grade Container Orchestration"
 showedit = true
 
-latest = "v1.11"
+latest = "v1.12"
 
-fullversion = "v1.11.0"
-version = "v1.11"
+fullversion = "v1.12.0"
+version = "v1.12"
 githubbranch = "master"
 docsbranch = "master"
 deprecated = false
@@ -76,10 +76,10 @@ githubWebsiteRepo = "github.com/kubernetes/website"
 githubWebsiteRaw = "raw.githubusercontent.com/kubernetes/website"
 
 [[params.versions]]
-fullversion = "v1.11.0"
-version = "v1.11"
-githubbranch = "v1.11.0"
-docsbranch = "release-1.11"
+fullversion = "v1.12.0"
+version = "v1.12"
+githubbranch = "v1.12.0"
+docsbranch = "release-1.12"
 url = "https://kubernetes.io"
 
 [params.pushAssets]
@@ -93,6 +93,13 @@ js = [
   "script"
 ]
 
+[[params.versions]]
+fullversion = "v1.11.3"
+version = "v1.11"
+githubbranch = "v1.11.3"
+docsbranch = "release-1.11"
+url = "https://v1-11.docs.kubernetes.io"
+
 [[params.versions]]
 fullversion = "v1.10.3"
 version = "v1.10"
@@ -114,12 +121,6 @@ githubbranch = "v1.8.4"
 docsbranch = "release-1.8"
 url = "https://v1-8.docs.kubernetes.io"
 
-[[params.versions]]
-fullversion = "v1.7.6"
-version = "v1.7"
-githubbranch = "v1.7.6"
-docsbranch = "release-1.7"
-url = "https://v1-7.docs.kubernetes.io"
 
 # Language definitions.
 

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

@@ -76,11 +76,9 @@ the `Terminating` or `Unknown` state. In cases where Kubernetes cannot deduce fr
 permanently left a cluster, the cluster administrator may need to delete the node object by hand.  Deleting the node object from
 Kubernetes causes all the Pod objects running on the node to be deleted from the apiserver, and frees up their names.
 
-Version 1.8 introduced an alpha feature that automatically creates
+In version 1.12, `TaintNodesByCondition` feature is promoted to beta，so node lifecycle controller automatically creates 
 [taints](/docs/concepts/configuration/taint-and-toleration/) that represent conditions.
-To enable this behavior, pass an additional feature gate flag `--feature-gates=...,TaintNodesByCondition=true`
-to the API server, controller manager, and scheduler.
-When `TaintNodesByCondition` is enabled, the scheduler ignores conditions when considering a Node; instead
+Similarly the scheduler ignores conditions when considering a Node; instead
 it looks at the Node's taints and a Pod's tolerations.
 
 Now users can choose between the old scheduling model and a new, more flexible scheduling model.

content/en/docs/concepts/cluster-administration/cloud-providers.md

@@ -9,7 +9,47 @@ This page explains how to manage Kubernetes running on a specific
 cloud provider.
 {{% /capture %}}
 
+{{< toc >}}
+
 {{% capture body %}}
+### kubeadm
+[kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) is a popular option for creating kubernetes clusters. 
+kubeadm has configuration options to specify configuration information for cloud providers. For example a typical 
+in-tree cloud provider can be configured using kubeadm as shown below:
+
+```yaml
+apiVersion: kubeadm.k8s.io/v1alpha3
+kind: InitConfiguration
+nodeRegistration:
+  kubeletExtraArgs:
+    cloud-provider: "openstack"
+    cloud-config: "/etc/kubernetes/cloud.conf"
+---
+kind: ClusterConfiguration
+apiVersion: kubeadm.k8s.io/v1alpha3
+kubernetesVersion: v1.12.0
+apiServerExtraArgs:
+  cloud-provider: "openstack"
+  cloud-config: "/etc/kubernetes/cloud.conf"
+apiServerExtraVolumes:
+- name: cloud
+  hostPath: "/etc/kubernetes/cloud.conf"
+  mountPath: "/etc/kubernetes/cloud.conf"
+controllerManagerExtraArgs:
+  cloud-provider: "openstack"
+  cloud-config: "/etc/kubernetes/cloud.conf"
+controllerManagerExtraVolumes:
+- name: cloud
+  hostPath: "/etc/kubernetes/cloud.conf"
+  mountPath: "/etc/kubernetes/cloud.conf"
+```
+
+The in-tree cloud providers typically need both `--cloud-provider` and `--cloud-config` specified in the command lines
+for the [kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/) and the
+[kubelet](/docs/admin/kubelet/). The contents of the file specified in `--cloud-config` for each provider is documented below as well.
+
+For all external cloud providers, please follow the instructions on the individual repositories.
+
 ## AWS
 This section describes all the possible configurations which can
 be used when running Kubernetes on Amazon Web Services.

content/en/docs/concepts/cluster-administration/proxies.md

@@ -36,7 +36,7 @@ There are several different proxies you may encounter when using Kubernetes:
 1.  The [kube proxy](/docs/concepts/services-networking/service/#ips-and-vips):
 
     - runs on each node
-    - proxies UDP and TCP
+    - proxies UDP, TCP and SCTP
     - does not understand HTTP
     - provides load balancing
     - is just used to reach services
@@ -51,7 +51,8 @@ There are several different proxies you may encounter when using Kubernetes:
 
     - are provided by some cloud providers (e.g. AWS ELB, Google Cloud Load Balancer)
     - are created automatically when the Kubernetes service has type `LoadBalancer`
-    - use UDP/TCP only
+    - usually supports UDP/TCP only
+    - SCTP support is up to the load balancer implementation of the cloud provider
     - implementation varies by cloud provider.
 
 Kubernetes users will typically not need to worry about anything other than the first two types.  The cluster admin

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

@@ -42,7 +42,7 @@ other pods to be evicted/not get scheduled. To resolve this issue,
 [ResourceQuota](https://kubernetes.io/docs/concepts/policy/resource-quotas/) is
 augmented to support Pod priority. An admin can create ResourceQuota for users
 at specific priority levels, preventing them from creating pods at high
-priorities. However, this feature is in alpha as of Kubernetes 1.11.
+priorities. This feature is in beta since Kubernetes 1.12.
 {{< /warning >}}
 
 {{% /capture %}}

content/en/docs/concepts/configuration/scheduler-perf-tuning.md

@@ -0,0 +1,112 @@
+---
+reviewers:
+- bsalamat
+title: Scheduler Performance Tuning
+content_template: templates/concept
+weight: 70
+---
+
+{{% capture overview %}}
+
+{{< feature-state for_k8s_version="1.12" >}}
+
+Kube-scheduler is the Kubernetes default scheduler. It is responsible for
+placement of Pods on Nodes in a cluster. Nodes in a cluster that meet the
+scheduling requirements of a Pod are called "feasible" Nodes for the Pod. The
+scheduler finds feasible Nodes for a Pod and then runs a set of functions to
+score the feasible Nodes and picks a Node with the highest score among the
+feasible ones to run the Pod. The scheduler then notifies the API server about this
+decision in a process called "Binding".
+
+{{% /capture %}}
+
+{{% capture body %}}
+
+## Percentage of Nodes to Score
+
+Before Kubernetes 1.12, Kube-scheduler used to check the feasibility of all the
+nodes in a cluster and then scored the feasible ones. Kubernetes 1.12 has a new
+feature that allows the scheduler to stop looking for more feasible nodes once
+it finds a certain number of them. This improves the scheduler's performance in
+large clusters. The number is specified as a percentage of the cluster size and
+is controlled by a configuration option called `percentageOfNodesToScore`. The
+range should be between 1 and 100. Other values are considered as 100%. The
+default value of this option is 50%. A cluster administrator can change this value by providing a
+different value in the scheduler configuration. However, it may not be necessary to change this value.
+
+```yaml
+apiVersion: componentconfig/v1alpha1
+kind: KubeSchedulerConfiguration
+algorithmSource:
+  provider: DefaultProvider
+
+...
+
+percentageOfNodesToScore: 50
+```
+
+{{< note >}} **Note**: In clusters with zero or less than 50 feasible nodes, the
+scheduler still checks all the nodes, simply because there are not enough
+feasible nodes to stop the scheduler's search early. {{< /note >}}
+
+**To disable this feature**, you can set `percentageOfNodesToScore` to 100.
+
+### Tuning percentageOfNodesToScore
+
+`percentageOfNodesToScore` must be a value between 1 and 100
+with the default value of 50. There is also a hardcoded minimum value of 50
+nodes which is applied internally. The scheduler tries to find at
+least 50 nodes regardless of the value of `percentageOfNodesToScore`. This means
+that changing this option to lower values in clusters with several hundred nodes
+will not have much impact on the number of feasible nodes that the scheduler
+tries to find. This is intentional as this option is unlikely to improve
+performance noticeably in smaller clusters. In large clusters with over a 1000
+nodes setting this value to lower numbers may show a noticeable performance
+improvement.
+
+An important note to consider when setting this value is that when a smaller
+number of nodes in a cluster are checked for feasibility, some nodes are not
+sent to be scored for a given Pod. As a result, a Node which could possibly
+score a higher value for running the given Pod might not even be passed to the
+scoring phase. This would result in a less than ideal placement of the Pod. For
+this reason, the value should not be set to very low percentages. A general rule
+of thumb is to never set the value to anything lower than 30. Lower values
+should be used only when the scheduler's throughput is critical for your
+application and the score of nodes is not important. In other words, you prefer
+to run the Pod on any Node as long as it is feasible.
+
+It is not recommended to lower this value from its default if your cluster has
+only several hundred Nodes. It is unlikely to improve the scheduler's
+performance significantly.
+
+### How the scheduler iterates over Nodes
+
+This section is intended for those who want to understand the internal details
+of this feature.
+
+In order to give all the Nodes in a cluster a fair chance of being considered
+for running Pods, the scheduler iterates over the nodes in a round robin
+fashion. You can imagine that Nodes are in an array. The scheduler starts from
+the start of the array and checks feasibility of the nodes until it finds enough
+Nodes as specified by `percentageOfNodesToScore`. For the next Pod, the
+scheduler continues from the point in the Node array that it stopped at when checking
+feasibility of Nodes for the previous Pod.
+
+If Nodes are in multiple zones, the scheduler iterates over Nodes in various
+zones to ensure that Nodes from different zones are considered in the
+feasibility checks. As an example, consider six nodes in two zones:
+
+```
+Zone 1: Node 1, Node 2, Node 3, Node 4
+Zone 2: Node 5, Node 6
+```
+
+The Scheduler evaluates feasibility of the nodes in this order:
+
+```
+Node 1, Node 5, Node 2, Node 6, Node 3, Node 4
+```
+
+After going over all the Nodes, it goes back to Node 1.
+
+{{% /capture %}}

content/en/docs/concepts/configuration/secret.md

@@ -343,9 +343,15 @@ files.
 
 When a secret being already consumed in a volume is updated, projected keys are eventually updated as well.
 Kubelet is checking whether the mounted secret is fresh on every periodic sync.
-However, it is using its local ttl-based cache for getting the current value of the secret.
-As a result, the total delay from the moment when the secret is updated to the moment when new keys are
-projected to the pod can be as long as kubelet sync period + ttl of secrets cache in kubelet.
+However, it is using its local cache for getting the current value of the Secret.
+The type of the cache is configurable using the  (`ConfigMapAndSecretChangeDetectionStrategy` field in
+[KubeletConfiguration struct](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/pkg/kubelet/apis/kubeletconfig/v1beta1/types.go)).
+It can be either propagated via watch (default), ttl-based, or simply redirecting
+all requests to directly kube-apiserver.
+As a result, the total delay from the moment when the Secret is updated to the moment
+when new keys are projected to the Pod can be as long as kubelet sync period + cache
+propagation delay, where cache propagation delay depends on the chosen cache type
+(it equals to watch propagation delay, ttl of cache, or zero corespondingly).
 
 {{< note >}}
 **Note:** A container using a Secret as a

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

@@ -279,9 +279,10 @@ which matches the behavior when this feature is disabled.
 
 ## Taint Nodes by Condition
 
-Version 1.8 introduces an alpha feature that causes the node controller to create taints corresponding to
-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.
+In version 1.12, `TaintNodesByCondition` feature is promoted to beta, so node lifecycle controller automatically creates taints corresponding to
+Node conditions.
+Similarly 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.
+Note that `TaintNodesByCondition` only taints nodes with `NoSchedule` effect. `NoExecute` effect is controlled by `TaintBasedEviction` which is an alpha feature and disabled by default.
 
 Starting in Kubernetes 1.8, the DaemonSet controller automatically adds the
 following `NoSchedule` tolerations to all daemons, to prevent DaemonSets from

content/en/docs/concepts/containers/images.md

@@ -32,6 +32,26 @@ you can do one of the following:
 
 Note that you should avoid using `:latest` tag, see [Best Practices for Configuration](/docs/concepts/configuration/overview/#container-images) for more information.
 
+## Building Multi-architecture Images with Manifests
+
+Docker CLI now supports the following command `docker manifest` with sub commands like `create`, `annotate` and `push`. These commands can be used to build and push the manifests. You can use `docker manifest inspect` to view the manifest.
+
+Please see docker documentation here:
+https://docs.docker.com/edge/engine/reference/commandline/manifest/
+
+See examples on how we use this in our build harness:
+https://cs.k8s.io/?q=docker%20manifest%20(create%7Cpush%7Cannotate)&i=nope&files=&repos=
+
+These commands rely on and are implemented purely on the Docker CLI. You will need to either edit the `$HOME/.docker/config.json` and set `experimental` key to `enabled` or you can just set `DOCKER_CLI_EXPERIMENTAL` environment variable to `enabled` when you call the CLI commands.
+
+{{< note >}}
+**Note:** Please use Docker *18.06 or above*, versions below that either have bugs or do not support the experimental command line option. Example https://github.com/docker/cli/issues/1135 causes problems under containerd.
+{{< /note >}}
+
+If you run into trouble with uploading stale manifests, just clean up the older manifests in `$HOME/.docker/manifests` to start fresh.
+
+For Kubernetes, we have typically used images with suffix `-$(ARCH)`. For backward compatability, please generate the older images with suffixes. The idea is to generate say `pause` image which has the manifest for all the arch(es) and say `pause-amd64` which is backwards compatible for older configurations or YAML files which may have hard coded the images with suffixes.
+
 ## Using a Private Registry
 
 Private registries may require keys to read images from them.