Merge remote-tracking branch 'upstream/master' into kubeadm

Author: yujunz

OWNERS_ALIASES

@@ -62,15 +62,10 @@ aliases:
     - soltysh
     - sttts
   sig-cluster-lifecycle: #GH: sig-cluster-lifecycle-pr-reviews
-    - jbeda
     - timothysc
-    - lukemarsden
-    - pipejakob
-    - dmmcquay
-    - mattmoyer
     - luxas
     - roberthbailey
-    - medinatiger
+    - fabriziopandini 
   sig-cluster-ops:
     - zehicle
     - jdumars

content/en/case-studies/pearson.html

@@ -10,11 +10,15 @@ cloud provider.
 {{% /capture %}}
 
 {{% capture body %}}
-# AWS
+## AWS
 This section describes all the possible configurations which can
 be used when running Kubernetes on Amazon Web Services.
 
-## Load Balancers
+### Node Name
+
+The AWS cloud provider uses the private DNS name of the AWS instance as the name of the Kubernetes Node object.
+
+### Load Balancers
 You can setup [external load balancers](/docs/tasks/access-application-cluster/create-external-load-balancer/)
 to use specific features in AWS by configuring the annotations as shown below.
 
@@ -58,9 +62,39 @@ Different settings can be applied to a load balancer service in AWS using _annot
 
 The information for the annotations for AWS is taken from the comments on [aws.go](https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/providers/aws/aws.go)
 
-# OpenStack
+## Azure
+
+### Node Name
+
+The Azure cloud provider uses the hostname of the node (as determined by the kubelet or overridden with `--hostname-override`) as the name of the Kubernetes Node object.
+Note that the Kubernetes Node name must match the Azure VM name.
+
+## CloudStack
+
+### Node Name
+
+The CloudStack cloud provider uses the hostname of the node (as determined by the kubelet or overridden with `--hostname-override`) as the name of the Kubernetes Node object.
+Note that the Kubernetes Node name must match the CloudStack VM name.
+
+## GCE
+
+### Node Name
+
+The GCE cloud provider uses the hostname of the node (as determined by the kubelet or overridden with `--hostname-override`) as the name of the Kubernetes Node object.
+Note that the first segment of the Kubernetes Node name must match the GCE instance name (e.g. a Node named `kubernetes-node-2.c.my-proj.internal` must correspond to an instance named `kubernetes-node-2`).
+
+## OpenStack
 This section describes all the possible configurations which can
-be used when using OpenStack with Kubernetes. The OpenStack cloud provider
+be used when using OpenStack with Kubernetes.
+
+### Node Name
+
+The OpenStack cloud provider uses the instance name (as determined from OpenStack metadata) as the name of the Kubernetes Node object.
+Note that the instance name must be a valid Kubernetes Node name in order for the kubelet to successfully register its Node object.
+
+### Services
+
+The OpenStack cloud provider
 implementation for Kubernetes supports the use of these OpenStack services from
 the underlying cloud, where available:
 
@@ -88,12 +122,12 @@ OpenStack services other than Keystone are not available and simply disclaim
 support for impacted features. Certain features are also enabled or disabled
 based on the list of extensions published by Neutron in the underlying cloud.
 
-## cloud.conf
+### cloud.conf
 Kubernetes knows how to interact with OpenStack via the file cloud.conf. It is
 the file that will provide Kubernetes with credentials and location for the OpenStack auth endpoint.
 You can create a cloud.conf file by specifying the following details in it
 
-### Typical configuration
+#### Typical configuration
 This is an example of a typical configuration that touches the values that most
 often need to be set. It points the provider at the OpenStack cloud's Keystone
 endpoint, provides details for how to authenticate with it, and configures the
@@ -111,7 +145,7 @@ domain-id=2a73b8f597c04551a0fdc8e95544be8a
 subnet-id=6937f8fa-858d-4bc9-a3a5-18d2c957166a
 ```
 
-#### Global
+##### Global
 These configuration options for the OpenStack provider pertain to its global
 configuration and should appear in the `[Global]` section of the `cloud.conf`
 file:
@@ -146,7 +180,7 @@ file:
 When using Keystone V3 - which changes tenant to project - the `tenant-id` value
 is automatically mapped to the project construct in the API.
 
-####  Load Balancer
+#####  Load Balancer
 These configuration options for the OpenStack provider pertain to the load
 balancer and should appear in the `[LoadBalancer]` section of the `cloud.conf`
 file:
@@ -190,7 +224,7 @@ file:
   `node-security-group` must also be supplied.
 * `node-security-group` (Optional): ID of the security group to manage.
 
-#### Block Storage
+##### Block Storage
 These configuration options for the OpenStack provider pertain to block storage
 and should appear in the `[BlockStorage]` section of the `cloud.conf` file:
 
@@ -228,7 +262,7 @@ provider configuration:
 bs-version=v2
 ```
 
-#### Metadata
+##### Metadata
 These configuration options for the OpenStack provider pertain to metadata and
 should appear in the `[Metadata]` section of the `cloud.conf` file:
 
@@ -250,7 +284,7 @@ should appear in the `[Metadata]` section of the `cloud.conf` file:
   both configuration drive and metadata service though and only one or the other
   may be available which is why the default is to check both.
 
-#### Router
+##### Router
 
 These configuration options for the OpenStack provider pertain to the [kubenet]
 Kubernetes network plugin and should appear in the `[Router]` section of the
@@ -267,4 +301,22 @@ Kubernetes network plugin and should appear in the `[Router]` section of the
 
 {{% /capture %}}
 
+## OVirt
+
+### Node Name
+
+The OVirt cloud provider uses the hostname of the node (as determined by the kubelet or overridden with `--hostname-override`) as the name of the Kubernetes Node object.
+Note that the Kubernetes Node name must match the VM FQDN (reported by OVirt under `<vm><guest_info><fqdn>...</fqdn></guest_info></vm>`)
+
+## Photon
+
+### Node Name
+
+The Photon cloud provider uses the hostname of the node (as determined by the kubelet or overridden with `--hostname-override`) as the name of the Kubernetes Node object.
+Note that the Kubernetes Node name must match the Photon VM name (or if `overrideIP` is set to true in the `--cloud-config`, the Kubernetes Node name must match the Photon VM IP address).
+
+## VSphere
+
+### Node Name
 
+The VSphere cloud provider uses the hostname of the node (as determined by the kubelet or overridden with `--hostname-override`) as the name of the Kubernetes Node object.

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

@@ -94,7 +94,7 @@ very niche operation.  In this case a port will be allocated on the host `Node`
 and traffic will be forwarded to the `Pod`.  The `Pod` itself is blind to the
 existence or non-existence of host ports.
 
-## How to achieve this
+## How to implement the Kubernetes networking model
 
 There are a number of ways that this network model can be implemented.  This
 document is not an exhaustive study of the various methods, but hopefully serves
@@ -121,11 +121,11 @@ Details on how the AOS system works can be accessed here: http://www.apstra.com/
 
 ### Big Cloud Fabric from Big Switch Networks
 
-[Big Cloud Fabric](https://www.bigswitch.com/container-network-automation) is a cloud native networking architecture, designed to run Kubernetes in private cloud/on-premise environments. Using unified physical & virtual SDN, Big Cloud Fabric tackles inherent container networking problems such as load balancing, visibility, troubleshooting, security policies & container traffic monitoring. 
+[Big Cloud Fabric](https://www.bigswitch.com/container-network-automation) is a cloud native networking architecture, designed to run Kubernetes in private cloud/on-premises environments. Using unified physical & virtual SDN, Big Cloud Fabric tackles inherent container networking problems such as load balancing, visibility, troubleshooting, security policies & container traffic monitoring. 
 
 With the help of the Big Cloud Fabric's virtual pod multi-tenant architecture, container orchestration systems such as Kubernetes, RedHat Openshift, Mesosphere DC/OS & Docker Swarm will be natively integrated along side with VM orchestration systems such as VMware, OpenStack & Nutanix. Customers will be able to securely inter-connect any number of these clusters and enable inter-tenant communication between them if needed. 
 
-BCF was recognized by Gartner as a visionary in the latest [Magic Quadrant](http://go.bigswitch.com/17GatedDocuments-MagicQuadrantforDataCenterNetworking_Reg.html). One of the BCF Kubernetes on premise deployments (which includes Kubernetes, DC/OS & VMware running on multiple DCs across different geographic regions) is also referenced [here](https://portworx.com/architects-corner-kubernetes-satya-komala-nio/).
+BCF was recognized by Gartner as a visionary in the latest [Magic Quadrant](http://go.bigswitch.com/17GatedDocuments-MagicQuadrantforDataCenterNetworking_Reg.html). One of the BCF Kubernetes on-premises deployments (which includes Kubernetes, DC/OS & VMware running on multiple DCs across different geographic regions) is also referenced [here](https://portworx.com/architects-corner-kubernetes-satya-komala-nio/).
 
 ### Cilium
 

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

@@ -4,9 +4,14 @@ reviewers:
 - kevin-wangzefeng
 - bsalamat
 title: Assigning Pods to Nodes
+content_template: templates/concept
 weight: 30
 ---
 
+{{< toc >}}
+
+{{% capture overview %}}
+
 You can constrain a [pod](/docs/concepts/workloads/pods/pod/) to only be able to run on particular [nodes](/docs/concepts/architecture/nodes/) or to prefer to
 run on particular nodes. There are several ways to do this, and they all use
 [label selectors](/docs/concepts/overview/working-with-objects/labels/) to make the selection.
@@ -19,7 +24,9 @@ services that communicate a lot into the same availability zone.
 You can find all the files for these examples [in our docs
 repo here](https://github.com/kubernetes/website/tree/{{< param "docsbranch" >}}/docs/concepts/configuration/).
 
-{{< toc >}}
+{{% /capture %}}
+
+{{% capture body %}}
 
 ## nodeSelector
 
@@ -332,3 +339,9 @@ For more information on inter-pod affinity/anti-affinity, see the
 
 You may want to check [Taints](/docs/concepts/configuration/taint-and-toleration/)
 as well, which allow a *node* to *repel* a set of pods.
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+
+{{% /capture %}}

content/en/docs/concepts/configuration/assign-pod-node.md

@@ -390,7 +390,7 @@ Node-level extended resources are tied to nodes.
 
 ##### Device plugin managed resources
 See [Device
-Plugin](https://kubernetes.io/docs/concepts/cluster-administration/device-plugins/)
+Plugin](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)
 for how to advertise device plugin managed resources on each node.
 
 ##### Other resources

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

@@ -2,15 +2,22 @@
 reviewers:
 - mikedanese
 title: Secrets
+content_template: templates/concept
 weight: 50
 ---
 
+{{< toc >}}
+
+{{% capture overview %}}
+
 Objects of type `secret` are intended to hold sensitive information, such as
 passwords, OAuth tokens, and ssh keys.  Putting this information in a `secret`
 is safer and more flexible than putting it verbatim in a `pod` definition or in
 a docker image. See [Secrets design document](https://git.k8s.io/community/contributors/design-proposals/auth/secrets.md) for more information.
 
-{{< toc >}}
+{{% /capture %}}
+
+{{% capture body %}}
 
 ## Overview of Secrets
 
@@ -525,6 +532,14 @@ secret "prod-db-secret" created
 $ kubectl create secret generic test-db-secret --from-literal=username=testuser --from-literal=password=iluvtests
 secret "test-db-secret" created
 ```
+{{< note >}}
+**Note:** Special characters such as `$`, `\*`, and `!` require escaping.
+If the password you are using has special characters, you need to escape them using the `\\` character. For example, if your actual password is `S!B\*d$zDsb`, you should execute the command this way: 
+
+    kubectl create secret generic dev-db-secret --from-literal=username=devuser --from-literal=password=S\\!B\\\*d\\$zDsb
+    
+You do not need to escape special characters in passwords from files (`--from-file`).
+{{< /note >}}
 
 Now make the pods:
 
@@ -638,11 +653,10 @@ The `secret-volume` will contain a single file, called `.secret-file`, and
 the `dotfile-test-container` will have this file present at the path
 `/etc/secret-volume/.secret-file`.
 
-**NOTE**
-
-Files beginning with dot characters are hidden from the output of  `ls -l`;
+{{< note >}}
+**Note**: Files beginning with dot characters are hidden from the output of  `ls -l`;
 you must use `ls -la` to see them when listing directory contents.
-
+{{< /note >}}
 
 ### Use-case: Secret visible to one container in a pod
 
@@ -751,3 +765,7 @@ Pod level](#use-case-secret-visible-to-one-container-in-a-pod).
 {{< note >}}
 **Note:** As of 1.7 [encryption of secret data at rest is supported](/docs/tasks/administer-cluster/encrypt-data/).
 {{< /note >}}
+
+{{% capture whatsnext %}}
+
+{{% /capture %}}

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

@@ -4,9 +4,13 @@ reviewers:
 - kevin-wangzefeng
 - bsalamat
 title: Taints and Tolerations
+content_template: templates/concept
 weight: 40
 ---
 
+{{< toc >}}
+
+{{% capture overview %}}
 Node affinity, described [here](/docs/concepts/configuration/assign-pod-node/#node-affinity-beta-feature),
 is a property of *pods* that *attracts* them to a set of nodes (either as a
 preference or a hard requirement). Taints are the opposite -- they allow a
@@ -18,7 +22,9 @@ marks that the node should not accept any pods that do not tolerate the taints.
 Tolerations are applied to pods, and allow (but do not require) the pods to schedule
 onto nodes with matching taints.
 
-{{< toc >}}
+{{% /capture %}}
+
+{{% capture body %}}
 
 ## Concepts
 
@@ -279,3 +285,9 @@ To make sure that turning on this feature doesn't break DaemonSets, starting in
 
 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 %}}

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

@@ -4,18 +4,26 @@ reviewers:
 - freehan
 - thockin
 title: Network Plugins
+content_template: templates/concept
 weight: 10
 ---
 
 {{< toc >}}
 
-__Disclaimer__: Network plugins are in alpha. Its contents will change rapidly.
+{{% capture overview %}}
+
+{{< feature-state state="alpha" >}}
+{{< warning >}}Alpha features change rapidly. {{< /warning >}}
 
 Network plugins in Kubernetes come in a few flavors:
 
 * CNI plugins: adhere to the appc/CNI specification, designed for interoperability.
 * Kubenet plugin: implements basic `cbr0` using the `bridge` and `host-local` CNI plugins
 
+{{% /capture %}}
+
+{{% capture body %}}
+
 ## Installation
 
 The kubelet has a single default network plugin, and a default network common to the entire cluster. It probes for plugins when it starts up, remembers what it found, and executes the selected plugin at appropriate times in the pod lifecycle (this is only true for Docker, as rkt manages its own CNI plugins). There are two Kubelet command line parameters to keep in mind when using plugins:
@@ -71,3 +79,9 @@ This option is provided to the network-plugin; currently **only kubenet supports
 * `--network-plugin=cni` specifies that we use the `cni` network plugin with actual CNI plugin binaries located in `--cni-bin-dir` (default `/opt/cni/bin`) and CNI plugin configuration located in `--cni-conf-dir` (default `/etc/cni/net.d`).
 * `--network-plugin=kubenet` specifies that we use the `kubenet` network plugin with CNI `bridge` and `host-local` plugins placed in `/opt/cni/bin` or `cni-bin-dir`.
 * `--network-plugin-mtu=9001` specifies the MTU to use, currently only used by the `kubenet` network plugin.
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+
+{{% /capture %}}

content/en/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md

@@ -3,14 +3,19 @@ reviewers:
 - rickypai
 - thockin
 title: Adding entries to Pod /etc/hosts with HostAliases
+content_template: templates/concept
 weight: 60
 ---
 
 {{< toc >}}
 
+{{% capture overview %}}
 Adding entries to a Pod's /etc/hosts file provides Pod-level override of hostname resolution when DNS and other options are not applicable. In 1.7, users can add these custom entries with the HostAliases field in PodSpec.
 
 Modification not using HostAliases is not suggested because the file is managed by Kubelet and can be overwritten on during Pod creation/restart.
+{{% /capture %}}
+
+{{% capture body %}}
 
 ## Default Hosts File Content
 
@@ -91,3 +96,9 @@ In 1.8, HostAlias is supported for all Pods regardless of network configuration.
 Kubelet [manages](https://github.com/kubernetes/kubernetes/issues/14633) the hosts file for each container of the Pod to prevent Docker from [modifying](https://github.com/moby/moby/issues/17190) the file after the containers have already been started.
 
 Because of the managed-nature of the file, any user-written content will be overwritten whenever the hosts file is remounted by Kubelet in the event of a container restart or a Pod reschedule. Thus, it is not suggested to modify the contents of the file.
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+
+{{% /capture %}}