whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge remote-tracking branch 'upstream/main' into dev-1.23

Browse Source
This commit is contained in:
Jesse Butler
2021-12-06 08:55:54 -05:00
parent 3d07786e5d b904695d10
commit 584421fe11
152 changed files with 1691 additions and 942 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/concepts/workloads/controllers/deployment.md
+23 -8
View File
@@ -32,7 +32,7 @@ The following are typical use cases for Deployments:
* [Declare the new state of the Pods](#updating-a-deployment) by updating the PodTemplateSpec of the Deployment. A new ReplicaSet is created and the Deployment manages moving the Pods from the old ReplicaSet to the new one at a controlled rate. Each new ReplicaSet updates the revision of the Deployment.
* [Rollback to an earlier Deployment revision](#rolling-back-a-deployment) if the current state of the Deployment is not stable. Each rollback updates the revision of the Deployment.
* [Scale up the Deployment to facilitate more load](#scaling-a-deployment).
* [Pause the Deployment](#pausing-and-resuming-a-deployment) to apply multiple fixes to its PodTemplateSpec and then resume it to start a new rollout.
* [Pause the rollout of a Deployment](#pausing-and-resuming-a-deployment) to apply multiple fixes to its PodTemplateSpec and then resume it to start a new rollout.
* [Use the status of the Deployment](#deployment-status) as an indicator that a rollout has stuck.
* [Clean up older ReplicaSets](#clean-up-policy) that you don't need anymore.
@@ -697,9 +697,12 @@ nginx-deployment-1989198191 7 7 0 7m
nginx-deployment-618515232 11 11 11 7m
```
## Pausing and Resuming a Deployment
## Pausing and Resuming a rollout of a Deployment {#pausing-and-resuming-a-deployment}
You can pause a Deployment before triggering one or more updates and then resume it. This allows you to
When you update a Deployment, or plan to, you can pause rollouts
for that Deployment before you trigger one or more updates. When
you're ready to apply those changes, you resume rollouts for the
Deployment. This approach allows you to
apply multiple fixes in between pausing and resuming without triggering unnecessary rollouts.
* For example, with a Deployment that was created:
@@ -775,10 +778,10 @@ apply multiple fixes in between pausing and resuming without triggering unnecess
deployment.apps/nginx-deployment resource requirements updated
```
The initial state of the Deployment prior to pausing it will continue its function, but new updates to
the Deployment will not have any effect as long as the Deployment is paused.
The initial state of the Deployment prior to pausing its rollout will continue its function, but new updates to
the Deployment will not have any effect as long as the Deployment rollout is paused.
* Eventually, resume the Deployment and observe a new ReplicaSet coming up with all the new updates:
* Eventually, resume the Deployment rollout and observe a new ReplicaSet coming up with all the new updates:
```shell
kubectl rollout resume deployment/nginx-deployment
```
@@ -912,8 +915,8 @@ example, rollback the Deployment to its previous version.
{{< /note >}}
{{< note >}}
If you pause a Deployment, Kubernetes does not check progress against your specified deadline.
You can safely pause a Deployment in the middle of a rollout and resume without triggering
If you pause a Deployment rollout, Kubernetes does not check progress against your specified deadline.
You can safely pause a Deployment rollout in the middle of a rollout and resume without triggering
the condition for exceeding the deadline.
{{< /note >}}
@@ -1065,6 +1068,18 @@ allowed, which is the default if not specified.
`.spec.replicas` is an optional field that specifies the number of desired Pods. It defaults to 1.
Should you manually scale a Deployment, example via `kubectl scale deployment
deployment --replicas=X`, and then you update that Deployment based on a manifest
(for example: by running `kubectl apply -f deployment.yaml`),
then applying that manifest overwrites the manual scaling that you previously did.
If a [HorizontalPodAutoscaler](/docs/tasks/run-application/horizontal-pod-autoscale/) (or any
similar API for horizontal scaling) is managing scaling for a Deployment, don't set `.spec.replicas`.
Instead, allow the Kubernetes
{{< glossary_tooltip text="control plane" term_id="control-plane" >}} to manage the
`.spec.replicas` field automatically.
### Selector
`.spec.selector` is a required field that specifies a [label selector](/docs/concepts/overview/working-with-objects/labels/)
content/en/docs/concepts/workloads/controllers/statefulset.md
+16
View File
@@ -379,6 +379,22 @@ which will verify owner references before terminating Pods. If that is not possi
operator should verify the owner references on PVCs to ensure the expected objects are
deleted when Pods are force-deleted.
### Replicas
`.spec.replicas` is an optional field that specifies the number of desired Pods. It defaults to 1.
Should you manually scale a deployment, example via `kubectl scale
statefulset statefulset --replicas=X`, and then you update that StatefulSet
based on a manifest (for example: by running `kubectl apply -f
statefulset.yaml`), then applying that manifest overwrites the manual scaling
that you previously did.
If a [HorizontalPodAutoscaler](/docs/tasks/run-application/horizontal-pod-autoscale/)
(or any similar API for horizontal scaling) is managing scaling for a
Statefulset, don't set `.spec.replicas`. Instead, allow the Kubernetes
{{<glossary_tooltip text="control plane" term_id="control-plane" >}} to manage
the `.spec.replicas` field automatically.
## {{% heading "whatsnext" %}}
* Learn about [Pods](/docs/concepts/workloads/pods).
content/en/docs/concepts/workloads/pods/pod-lifecycle.md
+1 -1
View File
@@ -159,7 +159,7 @@ through which the Pod has or has not passed:
* `PodScheduled`: the Pod has been scheduled to a node.
* `ContainersReady`: all containers in the Pod are ready.
* `Initialized`: all [init containers](/docs/concepts/workloads/pods/init-containers/)
have started successfully.
have completed successfully.
* `Ready`: the Pod is able to serve requests and should be added to the load
balancing pools of all matching Services.
content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
+9 -5
View File
@@ -85,7 +85,7 @@ You can define one or multiple `topologySpreadConstraint` to instruct the kube-s
It must be greater than zero. Its semantics differs according to the value of `whenUnsatisfiable`:
- when `whenUnsatisfiable` equals to "DoNotSchedule", `maxSkew` is the maximum
permitted difference between the number of matching pods in the target
topology and the global minimum
topology and the global minimum
(the minimum number of pods that match the label selector in a topology domain. For example, if you have 3 zones with 0, 2 and 3 matching pods respectively, The global minimum is 0).
- when `whenUnsatisfiable` equals to "ScheduleAnyway", scheduler gives higher
precedence to topologies that would help reduce the skew.
@@ -234,6 +234,8 @@ To overcome this situation, you can either increase the `maxSkew` or modify one
The scheduler will skip the non-matching nodes from the skew calculations if the incoming Pod has `spec.nodeSelector` or `spec.affinity.nodeAffinity` defined.
### Example: TopologySpreadConstraints with NodeAffinity
Suppose you have a 5-node cluster ranging from zoneA to zoneC:
{{<mermaid>}}
@@ -349,12 +351,14 @@ Also, the legacy `SelectorSpread` plugin, which provides an equivalent behavior,
is disabled.
{{< note >}}
The `PodTopologySpread` plugin does not score the nodes that don't have
the topology keys specified in the spreading constraints. This might result
in a different default behavior compared to the legacy `SelectorSpread` plugin when
using the default topology constraints.
If your nodes are not expected to have **both** `kubernetes.io/hostname` and
`topology.kubernetes.io/zone` labels set, define your own constraints
instead of using the Kubernetes defaults.
The `PodTopologySpread` plugin does not score the nodes that don't have
the topology keys specified in the spreading constraints.
{{< /note >}}
If you don't want to use the default Pod spreading constraints for your cluster,
@@ -392,7 +396,7 @@ for more details.
## Known Limitations
- There's no guarantee that the constraints remain satisfied when Pods are removed. For example, scaling down a Deployment may result in imbalanced Pods distribution.
- There's no guarantee that the constraints remain satisfied when Pods are removed. For example, scaling down a Deployment may result in imbalanced Pods distribution.
You can use [Descheduler](https://github.com/kubernetes-sigs/descheduler) to rebalance the Pods distribution.
- Pods matched on tainted nodes are respected. See [Issue 80921](https://github.com/kubernetes/kubernetes/issues/80921)