diff --git a/_config.yml b/_config.yml index cd335720a2..a116b737be 100644 --- a/_config.yml +++ b/_config.yml @@ -1,5 +1,6 @@ name: Kubernetes title: Kubernetes +url: https://kubernetes.io description: Production-Grade Container Orchestration markdown: kramdown kramdown: diff --git a/_includes/feature-state-deprecated.md b/_includes/feature-state-deprecated.md index 08d85d0b16..4379da5b7f 100644 --- a/_includes/feature-state-deprecated.md +++ b/_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 %} diff --git a/_includes/head.html b/_includes/head.html index 25b363308d..37b7bfaab4 100644 --- a/_includes/head.html +++ b/_includes/head.html @@ -8,6 +8,13 @@ {% if page.class == "gridPage" %}{% endif %} + + {% if page.description %} + + {% else %} + + {% endif %} + diff --git a/docs/admin/authorization/index.md b/docs/admin/authorization/index.md index 0d9df2a99c..89ac68cdd3 100644 --- a/docs/admin/authorization/index.md +++ b/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 Admission Control, see [Using Admission Controllers](docs/admin/admission-controllers/). +* 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/). {% endcapture %} {% include templates/concept.md %} diff --git a/docs/admin/kubeadm.md b/docs/admin/kubeadm.md index ba978d3c5c..50c9f08a5d 100644 --- a/docs/admin/kubeadm.md +++ b/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 |.` Delete a token. diff --git a/docs/concepts/workloads/controllers/deployment.md b/docs/concepts/workloads/controllers/deployment.md index cec5802ff3..0da744574b 100644 --- a/docs/concepts/workloads/controllers/deployment.md +++ b/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 diff --git a/docs/concepts/workloads/pods/pod-overview.md b/docs/concepts/workloads/pods/pod-overview.md index eb3a44b562..73bc80c17c 100644 --- a/docs/concepts/workloads/pods/pod-overview.md +++ b/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. diff --git a/docs/setup/pick-right-solution.md b/docs/setup/pick-right-solution.md index 294824432d..1313cdc3ab 100644 --- a/docs/setup/pick-right-solution.md +++ b/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. diff --git a/docs/tasks/configure-pod-container/assign-cpu-ram-container.md b/docs/tasks/configure-pod-container/assign-cpu-ram-container.md index b036ef9c9e..ae585e7085 100644 --- a/docs/tasks/configure-pod-container/assign-cpu-ram-container.md +++ b/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 %}