kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Merge pull request #39664 from Zhuzhenghao/run-single-instance-stateful-application.md 

[zh] sync run-single-instance-stateful-application and horizontal-pod-autoscale
pull/39663/head^2
Kubernetes Prow Robot 2023-02-25 22:20:17 -08:00 committed by GitHub
parent dbde7cfe27 12d9b2c315
commit f6d41d2959
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 62 additions and 55 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

56
content/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale.md
View File

@ -129,7 +129,7 @@ Kubernetes 将水平 Pod 自动扩缩实现为一个间歇运行的控制回路
<!--
Once during each period, the controller manager queries the resource utilization against the
metrics specified in each HorizontalPodAutoscaler definition. The controller manager
metrics specified in each HorizontalPodAutoscaler definition. The controller manager
finds the target resource defined by the `scaleTargetRef`,
then selects the pods based on the target resource's `.spec.selector` labels, and obtains the metrics from either the resource metrics API (for per-pod resource metrics),
or the custom metrics API (for all other metrics).
@ -144,7 +144,7 @@ or the custom metrics API (for all other metrics).
Then, if a target utilization value is set, the controller calculates the utilization
value as a percentage of the equivalent
[resource request](/docs/concepts/configuration/manage-resources-containers/#requests-and-limits)
on the containers in each Pod. If a target raw value is set, the raw metric values are used directly.
on the containers in each Pod. If a target raw value is set, the raw metric values are used directly.
The controller then takes the mean of the utilization or the raw value (depending on the type
of target specified) across all targeted Pods, and produces a ratio used to scale
the number of desired replicas.
@ -184,7 +184,7 @@ or the custom metrics API (for all other metrics).
<!--
The common use for HorizontalPodAutoscaler is to configure it to fetch metrics from
{{< glossary_tooltip text="aggregated APIs" term_id="aggregation-layer" >}}
(`metrics.k8s.io`, `custom.metrics.k8s.io`, or `external.metrics.k8s.io`). The `metrics.k8s.io` API is
(`metrics.k8s.io`, `custom.metrics.k8s.io`, or `external.metrics.k8s.io`). The `metrics.k8s.io` API is
usually provided by an add-on named Metrics Server, which needs to be launched separately.
For more information about resource metrics, see
[Metrics Server](/docs/tasks/debug/debug-cluster/resource-metrics-pipeline/#metrics-server).
@ -235,7 +235,7 @@ desiredReplicas = ceil[currentReplicas * ( currentMetricValue / desiredMetricVal
For example, if the current metric value is `200m`, and the desired value
is `100m`, the number of replicas will be doubled, since `200.0 / 100.0 ==
2.0` If the current value is instead `50m`, you'll halve the number of
replicas, since `50.0 / 100.0 == 0.5`. The control plane skips any scaling
replicas, since `50.0 / 100.0 == 0.5`. The control plane skips any scaling
action if the ratio is sufficiently close to 1.0 (within a globally-configurable
tolerance, 0.1 by default).
-->
@ -274,7 +274,7 @@ with missing metrics will be used to adjust the final scaling amount.
<!--
When scaling on CPU, if any pod has yet to become ready (it's still
initializing, or possibly is unhealthy) *or* the most recent metric point for
initializing, or possibly is unhealthy) _or_ the most recent metric point for
the pod was before it became ready, that pod is set aside as well.
-->
当使用 CPU 指标来扩缩时，任何还未就绪（还在初始化，或者可能是不健康的）状态的 Pod **或**
@ -287,7 +287,7 @@ determining whether to set aside certain CPU metrics. Instead, it
considers a Pod "not yet ready" if it's unready and transitioned to
ready within a short, configurable window of time since it started.
This value is configured with the `--horizontal-pod-autoscaler-initial-readiness-delay` flag, and its default is 30
seconds. Once a pod has become ready, it considers any transition to
seconds. Once a pod has become ready, it considers any transition to
ready to be the first if it occurred within a longer, configurable time
since it started. This value is configured with the `--horizontal-pod-autoscaler-cpu-initialization-period` flag, and its
default is 5 minutes.
@ -308,7 +308,7 @@ calculated using the remaining pods not set aside or discarded from above.
<!--
If there were any missing metrics, the control plane recomputes the average more
conservatively, assuming those pods were consuming 100% of the desired
value in case of a scale down, and 0% in case of a scale up. This dampens
value in case of a scale down, and 0% in case of a scale up. This dampens
the magnitude of any potential scale.
-->
如果缺失某些度量值，控制平面会更保守地重新计算平均值，在需要缩小时假设这些 Pod 消耗了目标值的 100%，
@ -325,7 +325,7 @@ of the desired metric, further dampening the magnitude of a scale up.
<!--
After factoring in the not-yet-ready pods and missing metrics, the
controller recalculates the usage ratio. If the new ratio reverses the scale
controller recalculates the usage ratio. If the new ratio reverses the scale
direction, or is within the tolerance, the controller doesn't take any scaling
action. In other cases, the new ratio is used to decide any change to the
number of Pods.
@ -335,7 +335,7 @@ number of Pods.
在其他情况下，新比率用于决定对 Pod 数量的任何更改。
<!--
Note that the *original* value for the average utilization is reported
Note that the _original_ value for the average utilization is reported
back via the HorizontalPodAutoscaler status, without factoring in the
not-yet-ready pods or missing metrics, even when the new usage ratio is
used.
@ -360,7 +360,7 @@ the current value.
这表示，如果一个或多个指标给出的 `desiredReplicas` 值大于当前值，HPA 仍然能实现扩容。
<!--
Finally, right before HPA scales the target, the scale recommendation is recorded. The
Finally, right before HPA scales the target, the scale recommendation is recorded. The
controller considers all recommendations within a configurable window choosing the
highest recommendation from within that window. This value can be configured using the `--horizontal-pod-autoscaler-downscale-stabilization` flag, which defaults to 5 minutes.
This means that scaledowns will occur gradually, smoothing out the impact of rapidly
@ -377,7 +377,7 @@ fluctuating metric values.
## API Object
The Horizontal Pod Autoscaler is an API resource in the Kubernetes
`autoscaling` API group. The current stable version can be found in
`autoscaling` API group. The current stable version can be found in
the `autoscaling/v2` API version which includes support for scaling on
memory and custom metrics. The new fields introduced in
`autoscaling/v2` are preserved as annotations when working with
@ -405,8 +405,8 @@ More details about the API object can be found at
When managing the scale of a group of replicas using the HorizontalPodAutoscaler,
it is possible that the number of replicas keeps fluctuating frequently due to the
dynamic nature of the metrics evaluated. This is sometimes referred to as *thrashing*,
or *flapping*. It's similar to the concept of *hysteresis* in cybernetics.
dynamic nature of the metrics evaluated. This is sometimes referred to as _thrashing_,
or _flapping_. It's similar to the concept of _hysteresis_ in cybernetics.
-->
## 工作量规模的稳定性 {#flapping}
@ -614,7 +614,7 @@ HorizontalPodAutoscaler 采用为每个指标推荐的最大比例，
<!--
## Support for metrics APIs
By default, the HorizontalPodAutoscaler controller retrieves metrics from a series of APIs. In order for it to access these
By default, the HorizontalPodAutoscaler controller retrieves metrics from a series of APIs. In order for it to access these
APIs, cluster administrators must ensure that:
-->
## 对 Metrics API 的支持 {#support-for-metrics-apis}
@ -628,10 +628,10 @@ APIs, cluster administrators must ensure that:
* The corresponding APIs are registered:
* For resource metrics, this is the `metrics.k8s.io` API, generally provided by [metrics-server](https://github.com/kubernetes-sigs/metrics-server).
It can be launched as a cluster add-on.
It can be launched as a cluster add-on.
* For custom metrics, this is the `custom.metrics.k8s.io` API. It's provided by "adapter" API servers provided by metrics solution vendors.
Check with your metrics pipeline to see if there is a Kubernetes metrics adapter available.
Check with your metrics pipeline to see if there is a Kubernetes metrics adapter available.
* For external metrics, this is the `external.metrics.k8s.io` API. It may be provided by the custom metrics adapters provided above.
-->
@ -639,14 +639,14 @@ APIs, cluster administrators must ensure that:
* 相应的 API 已注册：
* 对于资源指标，将使用 `metrics.k8s.io` API，一般由 [metrics-server](https://github.com/kubernetes-incubator/metrics-server) 提供。
* 对于资源指标，将使用 `metrics.k8s.io` API，一般由 [metrics-server](https://github.com/kubernetes-incubator/metrics-server) 提供。
它可以作为集群插件启动。
* 对于自定义指标，将使用 `custom.metrics.k8s.io` API。
* 对于自定义指标，将使用 `custom.metrics.k8s.io` API。
它由其他度量指标方案厂商的“适配器（Adapter）” API 服务器提供。
检查你的指标管道以查看是否有可用的 Kubernetes 指标适配器。
* 对于外部指标，将使用 `external.metrics.k8s.io` API。可能由上面的自定义指标适配器提供。
* 对于外部指标，将使用 `external.metrics.k8s.io` API。可能由上面的自定义指标适配器提供。
<!--
For more information on these different metrics paths and how they differ please see the relevant design proposals for
@ -918,6 +918,7 @@ behavior:
scaleDown:
selectPolicy: Disabled
```
<!--
## Support for HorizontalPodAutoscaler in kubectl
@ -936,7 +937,7 @@ Finally, you can delete an autoscaler using `kubectl delete hpa`.
<!--
In addition, there is a special `kubectl autoscale` command for creating a HorizontalPodAutoscaler object.
For instance, executing `kubectl autoscale rs foo --min=2 --max=5 --cpu-percent=80`
will create an autoscaler for ReplicaSet *foo*, with target CPU utilization set to `80%`
will create an autoscaler for ReplicaSet _foo_, with target CPU utilization set to `80%`
and the number of replicas between 2 and 5.
-->
此外，还有一个特殊的 `kubectl autoscale` 命令用于创建 HorizontalPodAutoscaler 对象。
@ -948,7 +949,7 @@ and the number of replicas between 2 and 5.
You can implicitly deactivate the HPA for a target without the
need to change the HPA configuration itself. If the target's desired replica count
is set to 0, and the HPA's minimum replica count is greater than 0, the HPA
is set to 0, and the HPA's minimum replica count is greater than 0, the HPA
stops adjusting the target (and sets the `ScalingActive` Condition on itself
to `false`) until you reactivate it by manually adjusting the target's desired
replica count or HPA's minimum replica count.
@ -965,7 +966,7 @@ replica count or HPA's minimum replica count.
When an HPA is enabled, it is recommended that the value of `spec.replicas` of
the Deployment and / or StatefulSet be removed from their
{{< glossary_tooltip text="manifest(s)" term_id="manifest" >}}. If this isn't done, any time
{{< glossary_tooltip text="manifest(s)" term_id="manifest" >}}. If this isn't done, any time
a change to that object is applied, for example via `kubectl apply -f
deployment.yaml`, this will instruct Kubernetes to scale the current number of Pods
to the value of the `spec.replicas` key. This may not be
@ -984,9 +985,9 @@ Deployment 和/或 StatefulSet 的 `spec.replicas` 的值。
Keep in mind that the removal of `spec.replicas` may incur a one-time
degradation of Pod counts as the default value of this key is 1 (reference
[Deployment Replicas](/docs/concepts/workloads/controllers/deployment#replicas)).
Upon the update, all Pods except 1 will begin their termination procedures. Any
Upon the update, all Pods except 1 will begin their termination procedures. Any
deployment application afterwards will behave as normal and respect a rolling
update configuration as desired. You can avoid this degradation by choosing one of the following two
update configuration as desired. You can avoid this degradation by choosing one of the following two
methods based on how you are modifying your deployments:
-->
请记住，删除 `spec.replicas` 可能会导致 Pod 计数一次性降级，因为此键的默认值为 1
@ -1000,10 +1001,10 @@ methods based on how you are modifying your deployments:
<!--
1. `kubectl apply edit-last-applied deployment/<deployment_name>`
2. In the editor, remove `spec.replicas`. When you save and exit the editor, `kubectl`
applies the update. No changes to Pod counts happen at this step.
applies the update. No changes to Pod counts happen at this step.
3. You can now remove `spec.replicas` from the manifest. If you use source code management,
also commit your changes or take whatever other steps for revising the source code
are appropriate for how you track updates.
also commit your changes or take whatever other steps for revising the source code
are appropriate for how you track updates.
4. From here on out you can run `kubectl apply -f deployment.yaml`
-->
1. `kubectl apply edit-last-applied deployment/<Deployment 名称>`
@ -1053,4 +1054,3 @@ For more information on HorizontalPodAutoscaler:
* 如果你想编写自己的自定义指标适配器，
请查看 [boilerplate](https://github.com/kubernetes-sigs/custom-metrics-apiserver) 以开始使用。
* 阅读 [API 参考](/zh-cn/docs/reference/kubernetes-api/workload-resources/horizontal-pod-autoscaler-v2/)。

61
content/zh-cn/docs/tasks/run-application/run-single-instance-stateful-application.md
View File

@ -36,7 +36,7 @@ application is MySQL.
<!--
You can run a stateful application by creating a Kubernetes Deployment
and connecting it to an existing PersistentVolume using a
PersistentVolumeClaim. For example, this YAML file describes a
PersistentVolumeClaim. For example, this YAML file describes a
Deployment that runs MySQL and references the PersistentVolumeClaim. The file
defines a volume mount for /var/lib/mysql, and then creates a
PersistentVolumeClaim that looks for a 20G volume. This claim is
@ -60,22 +60,28 @@ for a secure solution.
{{< codenew file="application/mysql/mysql-deployment.yaml" >}}
{{< codenew file="application/mysql/mysql-pv.yaml" >}}
1. <!--Deploy the PV and PVC of the YAML file-->
部署 YAML 文件中定义的 PV 和 PVC：
<!--
1. Deploy the PV and PVC of the YAML file:
-->
1. 部署 YAML 文件中定义的 PV 和 PVC：
```shell
kubectl apply -f https://k8s.io/examples/application/mysql/mysql-pv.yaml
```
1. <!-- Deploy the contents of the YAML file -->
部署 YAML 文件中定义的 Deployment：
<!--
1. Deploy the contents of the YAML file:
-->
2. 部署 YAML 文件中定义的 Deployment：
```shell
kubectl apply -f https://k8s.io/examples/application/mysql/mysql-deployment.yaml
```
1. <!-- Display information about the Deployment -->
展示 Deployment 相关信息:
<!--
1. Display information about the Deployment:
-->
3. 展示 Deployment 相关信息:
```shell
kubectl describe deployment mysql
@ -111,21 +117,23 @@ for a secure solution.
Type: PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
ClaimName: mysql-pv-claim
ReadOnly: false
Conditions:
Type Status Reason
---- ------ ------
Available False MinimumReplicasUnavailable
Progressing True ReplicaSetUpdated
OldReplicaSets: <none>
NewReplicaSet: mysql-63082529 (1/1 replicas created)
Events:
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
33s 33s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set mysql-63082529 to 1
Conditions:
Type Status Reason
---- ------ ------
Available False MinimumReplicasUnavailable
Progressing True ReplicaSetUpdated
OldReplicaSets: <none>
NewReplicaSet: mysql-63082529 (1/1 replicas created)
Events:
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
33s 33s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set mysql-63082529 to 1
```
1. <!-- List the pods created by the Deployment -->
列举出 Deployment 创建的 pods:
<!--
1. List the pods created by the Deployment:
-->
4. 列举出 Deployment 创建的 pods:
```shell
kubectl get pods -l app=mysql
@ -141,8 +149,10 @@ for a secure solution.
mysql-63082529-2z3ki 1/1 Running 0 3m
```
1. <!-- Inspect the PersistentVolumeClaim -->
查看 PersistentVolumeClaim：
<!--
1. Inspect the PersistentVolumeClaim:
-->
5. 查看 PersistentVolumeClaim：
```shell
kubectl describe pvc mysql-pv-claim
@ -180,14 +190,13 @@ Run a MySQL client to connect to the server:
-->
## 访问 MySQL 实例 {#accessing-the-mysql-instance}
前面 YAML 文件中创建了一个允许集群内其他 Pod 访问的数据库服务。该服务中选项
`clusterIP: None` 让服务 DNS 名称直接解析为 Pod 的 IP 地址。
当在一个服务下只有一个 Pod 并且不打算增加 Pod 的数量这是最好的.
运行 MySQL 客户端以连接到服务器:
```
```shell
kubectl run -it --rm --image=mysql:5.6 --restart=Never mysql-client -- mysql -h mysql -ppassword
```
@ -246,7 +255,7 @@ Delete the deployed objects by name:
通过名称删除部署的对象:
```
```shell
kubectl delete deployment,svc mysql
kubectl delete pvc mysql-pv-claim
kubectl delete pv mysql-pv-volume
@ -282,5 +291,3 @@ PersistentVolume 将被自动删除。
* 参阅 [kubectl run 文档](/docs/reference/generated/kubectl/kubectl-commands/#run)
* 参阅[卷](/zh-cn/docs/concepts/storage/volumes/)和[持久卷](/zh-cn/docs/concepts/storage/persistent-volumes/)