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

Tune links in tasks section (1/2)

Browse Source
This commit is contained in:
Qiming Teng
2020-08-07 16:46:52 +08:00
parent fcd8af988c
commit b8541d2127
24 changed files with 107 additions and 117 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/tasks/run-application/force-delete-stateful-set-pod.md
+15 -5
View File
@@ -37,13 +37,23 @@ You can perform a graceful pod deletion with the following command:
kubectl delete pods <pod>
```
For the above to lead to graceful termination, the Pod **must not** specify a `pod.Spec.TerminationGracePeriodSeconds` of 0. The practice of setting a `pod.Spec.TerminationGracePeriodSeconds` of 0 seconds is unsafe and strongly discouraged for StatefulSet Pods. Graceful deletion is safe and will ensure that the Pod [shuts down gracefully](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination) before the kubelet deletes the name from the apiserver.
For the above to lead to graceful termination, the Pod **must not** specify a
`pod.Spec.TerminationGracePeriodSeconds` of 0. The practice of setting a
`pod.Spec.TerminationGracePeriodSeconds` of 0 seconds is unsafe and strongly discouraged
for StatefulSet Pods. Graceful deletion is safe and will ensure that the Pod
[shuts down gracefully](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)
before the kubelet deletes the name from the apiserver.
Kubernetes (versions 1.5 or newer) will not delete Pods just because a Node is unreachable. The Pods running on an unreachable Node enter the 'Terminating' or 'Unknown' state after a [timeout](/docs/admin/node/#node-condition). Pods may also enter these states when the user attempts graceful deletion of a Pod on an unreachable Node. The only ways in which a Pod in such a state can be removed from the apiserver are as follows:
Kubernetes (versions 1.5 or newer) will not delete Pods just because a Node is unreachable.
The Pods running on an unreachable Node enter the 'Terminating' or 'Unknown' state after a
[timeout](/docs/concepts/architecture/nodes/#node-condition).
Pods may also enter these states when the user attempts graceful deletion of a Pod
on an unreachable Node.
The only ways in which a Pod in such a state can be removed from the apiserver are as follows:
* The Node object is deleted (either by you, or by the [Node Controller](/docs/admin/node)).<br/>
* The kubelet on the unresponsive Node starts responding, kills the Pod and removes the entry from the apiserver.<br/>
* Force deletion of the Pod by the user.
* The Node object is deleted (either by you, or by the [Node Controller](/docs/concepts/architecture/nodes/)).
* The kubelet on the unresponsive Node starts responding, kills the Pod and removes the entry from the apiserver.
* Force deletion of the Pod by the user.
The recommended best practice is to use the first or second approach. If a Node is confirmed to be dead (e.g. permanently disconnected from the network, powered down, etc), then delete the Node object. If the Node is suffering from a network partition, then try to resolve this or wait for it to resolve. When the partition heals, the kubelet will complete the deletion of the Pod and free up its name in the apiserver.
content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
+6 -8
View File
@@ -15,11 +15,9 @@ Horizontal Pod Autoscaler automatically scales the number of pods
in a replication controller, deployment, replica set or stateful set based on observed CPU utilization
(or, with beta support, on some other, application-provided metrics).
This document walks you through an example of enabling Horizontal Pod Autoscaler for the php-apache server. For more information on how Horizontal Pod Autoscaler behaves, see the [Horizontal Pod Autoscaler user guide](/docs/tasks/run-application/horizontal-pod-autoscale/).
This document walks you through an example of enabling Horizontal Pod Autoscaler for the php-apache server.
For more information on how Horizontal Pod Autoscaler behaves, see the
[Horizontal Pod Autoscaler user guide](/docs/tasks/run-application/horizontal-pod-autoscale/).
## {{% heading "prerequisites" %}}
@@ -459,12 +457,12 @@ HorizontalPodAutoscaler.
## Appendix: Quantities
All metrics in the HorizontalPodAutoscaler and metrics APIs are specified using
a special whole-number notation known in Kubernetes as a *quantity*. For example,
a special whole-number notation known in Kubernetes as a
{{< glossary_tooltip term_id="quantity" text="quantity">}}. For example,
the quantity `10500m` would be written as `10.5` in decimal notation. The metrics APIs
will return whole numbers without a suffix when possible, and will generally return
quantities in milli-units otherwise. This means you might see your metric value fluctuate
between `1` and `1500m`, or `1` and `1.5` when written in decimal notation. See the
[glossary entry on quantities](/docs/reference/glossary?core-object=true#term-quantity) for more information.
between `1` and `1500m`, or `1` and `1.5` when written in decimal notation.
## Appendix: Other possible scenarios
content/en/docs/tasks/run-application/run-replicated-stateful-application.md
+2 -2
View File
@@ -33,7 +33,7 @@ on general patterns for running stateful applications in Kubernetes.
* This tutorial assumes you are familiar with
[PersistentVolumes](/docs/concepts/storage/persistent-volumes/)
and [StatefulSets](/docs/concepts/workloads/controllers/statefulset/),
as well as other core concepts like [Pods](/docs/concepts/workloads/pods/pod/),
as well as other core concepts like [Pods](/docs/concepts/workloads/pods/),
[Services](/docs/concepts/services-networking/service/), and
[ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/).
* Some familiarity with MySQL helps, but this tutorial aims to present
@@ -297,7 +297,7 @@ running while you force a Pod out of the Ready state.
### Break the Readiness Probe
The [readiness probe](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#define-readiness-probes)
The [readiness probe](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-readiness-probes)
for the `mysql` container runs the command `mysql -h 127.0.0.1 -e 'SELECT 1'`
to make sure the server is up and able to execute queries.