Merge branch 'master' of https://github.com/kubernetes/kubernetes.github.io into release-1.7

* 'master' of https://github.com/kubernetes/kubernetes.github.io:
  fix typo (#3895)
  add unit of --ttl duration (#3915)
  Fixes broken links
  Prototype of custom description meta tags. (#3928)
  Site URL for canonical URLs. (#3927)
  Warn about implications on selector updates
  grammar patch to #3922 (#3923)
  add calico to the table of solution
  Minor grammatical change

_config.yml

@@ -1,5 +1,6 @@
 name: Kubernetes
 title: Kubernetes
+url: https://kubernetes.io
 description: Production-Grade Container Orchestration
 markdown: kramdown
 kramdown:

_includes/feature-state-deprecated.md

@@ -1,6 +1,6 @@
 {% assign dialog_title = "deprecated" %}
 {% capture dialog_content %}
-This feature is *deprecated*. See [Deprecating parts of the API](/docs/reference/deprecation-policy/#deprecating-parts-of-the-api) for more information.
+This feature is *deprecated*. For more information on this state, see the [Kubernetes Deprecation Policy](/docs/reference/deprecation-policy/).
 {% endcapture %}
 
-**DEPRECATION NOTICE:** As of `Kubernetes {{ for_k8s_version | default: page.version }}` this feature is {% include feature-dialog.md %}
+**DEPRECATION NOTICE:** As of `Kubernetes {{ for_k8s_version | default: page.version }}`, this has been {% include feature-dialog.md %}

_includes/head.html

@@ -8,6 +8,13 @@
     <link rel="stylesheet" type="text/css" href="/css/jquery-ui.min.css">
     <link rel="stylesheet" type="text/css" href="/css/sweetalert.css">
     {% if page.class == "gridPage" %}<link rel="stylesheet" type="text/css" href="/css/gridpage.css">{% endif %}
+
+    {% if page.description %}
+    <meta name="description" content="{{ page.description }}" />
+    {% else %}
+    <meta name="description" content="{{ page.title }}" />
+    {% endif %}
+
     <script src="/js/jquery-2.2.0.min.js"></script>
     <script src="/js/jquery-ui.min.js"></script>
     <script src="/js/script.js"></script>

docs/admin/authorization/index.md

@@ -150,8 +150,8 @@ As of version 1.3, clusters created by kube-up.sh are configured so that the A
 
 {% endcapture %}
 {% capture whatsnext %}
-* To learn more about Authentication, see **Authentication** in [Controlling Access to the Kubernetes API](docs/admin/accessing-the-api/).
+* To learn more about Authentication, see **Authentication** in [Controlling Access to the Kubernetes API](/docs/admin/accessing-the-api/).
-* To learn more about Admission Control, see [Using Admission Controllers](docs/admin/admission-controllers/).
+* To learn more about Admission Control, see [Using Admission Controllers](/docs/admin/admission-controllers/).
 {% endcapture %}
 
 {% include templates/concept.md %}

docs/admin/kubeadm.md

@@ -331,7 +331,7 @@ commands.
 * `kubeadm token create` Creates a new token.
     * `--description` Set the description on the new token.
     * `--ttl duration` Set expiration time of the token as a delta from "now".
-      Default is 0 for no expiration.
+      Default is 0 for no expiration. The unit of the duration is seconds.
     * `--usages` Set the ways that the token can be used.  The default is
       `signing,authentication`.  These are the usages as described above.
 * `kubeadm token delete <token id>|<token id>.<token secret>` Delete a token.

docs/concepts/workloads/controllers/deployment.md

@@ -209,7 +209,7 @@ least 2 Pods were available and at most 4 Pods were created at all times. It the
 the new and the old ReplicaSet, with the same rolling update strategy. Finally, we'll have 3 available replicas
 in the new ReplicaSet, and the old ReplicaSet is scaled down to 0.
 
-### Rollover (multiple rollouts in-flight)
+### Rollover (aka multiple updates in-flight)
 
 Each time a new deployment object is observed by the deployment controller, a ReplicaSet is created to bring up
 the desired Pods if there is no existing ReplicaSet doing so. Existing ReplicaSet controlling Pods whose labels
@@ -227,6 +227,21 @@ killing the 3 `nginx:1.7.9` Pods that it had created, and will start creating
 `nginx:1.9.1` Pods. It will not wait for 5 replicas of `nginx:1.7.9` to be created
 before changing course.
 
+### Label selector updates
+
+It is generally discouraged to make label selector updates and it is suggested to plan your selectors up front.
+In any case, if you need to perform a label selector update, exercise great caution and make sure you have grasped
+all of the implications.
+
+* Selector additions require the pod template labels in the Deployment spec to be updated with the new label, too,
+otherwise a validation error is returned. This change is a non-overlapping one, meaning that the new selector does
+not select ReplicaSets and Pods created with the old selector, resulting in orphaning all old ReplicaSets and
+creating a new ReplicaSet.
+* Selector updates, i.e., changing the existing value in a selector key, result in the same behavior as additions.
+* Selector removals, i.e., removing an existing key from the Deployment selector, do not require any changes in the
+pod template labels, no existing ReplicaSet is orphaned, and a new ReplicaSet will not be created, but note that the
+removed label will still exist in any existing Pods and ReplicaSets.
+
 ## Rolling Back a Deployment
 
 Sometimes you may want to rollback a Deployment; for example, when the Deployment is not stable, such as crash looping.
@@ -807,7 +822,7 @@ the rolling update process.
 of Pods that can be unavailable during the update process. The value can be an absolute number (e.g. 5)
 or a percentage of desired Pods (e.g. 10%). The absolute number is calculated from percentage by
 rounding down. This can not be 0 if `.spec.strategy.rollingUpdate.maxSurge` is 0. By default, a
-value of 1 is used.
+value of 25% is used.
 
 For example, when this value is set to 30%, the old ReplicaSet can be scaled down to 70% of desired
 Pods immediately when the rolling update starts. Once new Pods are ready, old ReplicaSet can be scaled
@@ -819,7 +834,7 @@ at all times during the update is at least 70% of the desired Pods.
 `.spec.strategy.rollingUpdate.maxSurge` is an optional field that specifies the maximum number of Pods
 that can be created above the desired number of Pods. Value can be an absolute number (e.g. 5) or a
 percentage of desired Pods (e.g. 10%). This can not be 0 if `MaxUnavailable` is 0. The absolute number
-is calculated from percentage by rounding up. By default, a value of 1 is used.
+is calculated from percentage by rounding up. By default, a value of 25% is used.
 
 For example, when this value is set to 30%, the new ReplicaSet can be scaled up immediately when the
 rolling update starts, such that the total number of old and new Pods do not exceed 130% of desired

docs/concepts/workloads/pods/pod-overview.md

@@ -24,7 +24,7 @@ A Pod encapsulates an application container (or, in some cases, multiple contain
 
 > [Docker](https://www.docker.com) is the most common container runtime used in a Kubernetes Pod, but Pods support other container runtimes as well.
 
-Pods are employed a number of ways in a Kubernetes cluster, including:
+Pods are employed in a number of ways in a Kubernetes cluster, including:
 
 * **Pods that run a single container**. The "one-container-per-Pod" model is the most common Kubernetes use case; in this case, you can think of a Pod as a wrapper around a single container, and Kubernetes manages the Pods rather than the containers directly.
 * **Pods that run multiple containers that need to work together**. A Pod might encapsulate an application composed of multiple co-located containers that are tightly coupled and need to share resources. These co-located containers might form a single cohesive unit of service--one container serving files from a shared volume to the public, while a separate "sidecar" container refreshes or updates those files. The Pod wraps these containers and storage resources together as a single manageable entity.

docs/setup/pick-right-solution.md

@@ -185,6 +185,7 @@ oVirt                |              |        |             | [docs](/docs/gettin
 OpenStack Heat       | Saltstack    | CentOS | Neutron + flannel hostgw | [docs](/docs/getting-started-guides/openstack-heat)            |  Community ([@FujitsuEnablingSoftwareTechnologyGmbH](https://github.com/FujitsuEnablingSoftwareTechnologyGmbH))
 Rackspace            | CoreOS       | CoreOS | flannel     | [docs](/docs/getting-started-guides/rackspace)                              |  Community ([@doublerr](https://github.com/doublerr))
 any                  | any          | any    | any         | [docs](/docs/getting-started-guides/scratch)                                |  Community ([@erictune](https://github.com/erictune))
+any                  | any          | any    | any         | [docs](http://docs.projectcalico.org/v2.2/getting-started/kubernetes/installation/)                                |  Commercial and Community
 
 **Note**: The above table is ordered by version test/used in nodes, followed by support level.
 

docs/tasks/configure-pod-container/assign-cpu-ram-container.md

@@ -1,5 +1,6 @@
 ---
 title: Assigning CPU and RAM Resources to a Container
+description: When you create a Pod, you can request CPU and RAM resources for the containers that run in the Pod. You can also set limits for CPU and RAM use.
 ---
 
 {% capture overview %}