[zh-cn] Improve workloads/controllers/replicaset.md

This commit is contained in:
Michael 2022-07-03 22:26:53 +08:00 committed by windsonsea
parent 4d808c9616
commit 1c8f1b4a15
1 changed files with 39 additions and 43 deletions

View File

@ -38,7 +38,7 @@ template.
ReplicaSet 是通过一组字段来定义的,包括一个用来识别可获得的 Pod
的集合的选择算符、一个用来标明应该维护的副本个数的数值、一个用来指定应该创建新 Pod
以满足副本个数条件时要使用的 Pod 模板等等。
每个 ReplicaSet 都通过根据需要创建和 删除 Pod 以使得副本个数达到期望值,
每个 ReplicaSet 都通过根据需要创建和删除 Pod 以使得副本个数达到期望值,
进而实现其存在价值。当 ReplicaSet 需要创建新的 Pod 时,会使用所提供的 Pod 模板。
<!--
@ -60,9 +60,8 @@ OwnerReference is not a {{< glossary_tooltip term_id="controller" >}} and it mat
ReplicaSet.
-->
ReplicaSet 使用其选择算符来辨识要获得的 Pod 集合。如果某个 Pod 没有
OwnerReference 或者其 OwnerReference 不是一个
{{< glossary_tooltip text="控制器" term_id="controller" >}},且其匹配到
某 ReplicaSet 的选择算符,则该 Pod 立即被此 ReplicaSet 获得。
OwnerReference 或者其 OwnerReference 不是一个{{< glossary_tooltip text="控制器" term_id="controller" >}}
且其匹配到某 ReplicaSet 的选择算符,则该 Pod 立即被此 ReplicaSet 获得。
<!--
## When to use a ReplicaSet
@ -81,8 +80,8 @@ use a Deployment instead, and define your application in the spec section.
ReplicaSet 确保任何时间都有指定数量的 Pod 副本在运行。
然而Deployment 是一个更高级的概念,它管理 ReplicaSet并向 Pod
提供声明式的更新以及许多其他有用的功能。
因此,我们建议使用 Deployment 而不是直接使用 ReplicaSet除非
你需要自定义更新业务流程或根本不需要更新。
因此,我们建议使用 Deployment 而不是直接使用 ReplicaSet
除非你需要自定义更新业务流程或根本不需要更新。
这实际上意味着,你可能永远不需要操作 ReplicaSet 对象:而是使用
Deployment并在 spec 部分定义你的应用。
@ -169,7 +168,7 @@ Events:
<!--
And lastly you can check for the Pods brought up:
-->
最后可以查看启动了的 Pods
最后可以查看启动了的 Pod 集合
```shell
kubectl get pods
@ -191,8 +190,8 @@ frontend-wtsmm 1/1 Running 0 6m36s
You can also verify that the owner reference of these pods is set to the frontend ReplicaSet.
To do this, get the yaml of one of the Pods running:
-->
你也可以查看 Pods 的属主引用被设置为前端的 ReplicaSet。
要实现这点,可取回运行中的 Pods 之一的 YAML
你也可以查看 Pod 的属主引用被设置为前端的 ReplicaSet。
要实现这点,可取回运行中的某个 Pod 的 YAML
```shell
kubectl get pods frontend-b2zdv -o yaml
@ -268,7 +267,7 @@ Fetching the Pods:
新的 Pod 会被该 ReplicaSet 获取,并立即被 ReplicaSet 终止,
因为它们的存在会使得 ReplicaSet 中 Pod 个数超出其期望值。
取回 Pods
取回 Pod
```shell
@ -292,7 +291,7 @@ pod2 0/1 Terminating 0 1s
<!--
If you create the Pods first:
-->
如果你先行创建 Pods
如果你先行创建 Pod
```shell
kubectl apply -f https://kubernetes.io/examples/pods/pod-rs.yaml
@ -334,7 +333,7 @@ pod2 1/1 Running 0 36s
<!--
In this manner, a ReplicaSet can own a non-homogenous set of Pods
-->
采用这种方式,一个 ReplicaSet 中可以包含异质的 Pods 集合。
采用这种方式,一个 ReplicaSet 中可以包含异质的 Pod 集合。
<!--
## Writing a ReplicaSet manifest
@ -350,7 +349,7 @@ A ReplicaSet also needs a [`.spec` section](https://git.k8s.io/community/contrib
## 编写 ReplicaSet 的清单 {#writing-a-replicaset-manifest}
与所有其他 Kubernetes API 对象一样ReplicaSet 也需要 `apiVersion`、`kind`、和 `metadata` 字段。
对于 ReplicaSets 而言,其 `kind` 始终是 ReplicaSet。
对于 ReplicaSet 而言,其 `kind` 始终是 ReplicaSet。
ReplicaSet 对象的名称必须是合法的
[DNS 子域名](/zh-cn/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
@ -369,9 +368,9 @@ Be careful not to overlap with the selectors of other controllers, lest they try
For the template's [restart policy](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) field,
`.spec.template.spec.restartPolicy`, the only allowed value is `Always`, which is the default.
-->
### Pod 模 {#pod-template}
### Pod 模 {#pod-template}
`.spec.template` 是一个 [Pod 模](/zh-cn/docs/concepts/workloads/pods/#pod-templates)
`.spec.template` 是一个 [Pod 模](/zh-cn/docs/concepts/workloads/pods/#pod-templates)
要求设置标签。在 `frontend.yaml` 示例中,我们指定了标签 `tier: frontend`
注意不要将标签与其他控制器的选择算符重叠,否则那些控制器会尝试收养此 Pod。
@ -396,7 +395,7 @@ be rejected by the API.
### Pod 选择算符 {#pod-selector}
`.spec.selector` 字段是一个[标签选择算符](/zh-cn/docs/concepts/overview/working-with-objects/labels/)。
如前文中[所讨论的](#how-a-replicaset-works),这些是用来标识要被获取的 Pods
如前文中[所讨论的](#how-a-replicaset-works),这些是用来标识要被获取的 Pod
的标签。在签名的 `frontend.yaml` 示例中,选择算符为:
```yaml
@ -413,7 +412,7 @@ For 2 ReplicaSets specifying the same `.spec.selector` but different `.spec.temp
-->
对于设置了相同的 `.spec.selector`,但
`.spec.template.metadata.labels``.spec.template.spec` 字段不同的两个
ReplicaSet 而言,每个 ReplicaSet 都会忽略被另一个 ReplicaSet 所创建的 Pods
ReplicaSet 而言,每个 ReplicaSet 都会忽略被另一个 ReplicaSet 所创建的 Pod。
{{< /note >}}
<!--
@ -427,7 +426,7 @@ If you do not specify `.spec.replicas`, then it defaults to 1.
### Replicas
你可以通过设置 `.spec.replicas` 来指定要同时运行的 Pod 个数。
ReplicaSet 创建、删除 Pods 以与此值匹配。
ReplicaSet 创建、删除 Pod 以与此值匹配。
如果你没有指定 `.spec.replicas`,那么默认值为 1。
@ -442,7 +441,7 @@ When using the REST API or the `client-go` library, you must set `propagationPol
the -d option.
For example:
-->
## 使用 ReplicaSets {#working-with-replicasets}
## 使用 ReplicaSet {#working-with-replicasets}
### 删除 ReplicaSet 和它的 Pod {#deleting-a-replicaset-and-its-pods}
@ -470,7 +469,7 @@ For example:
-->
### 只删除 ReplicaSet {#deleting-just-a-replicaset}
你可以只删除 ReplicaSet 而不影响它的 Pods,方法是使用
你可以只删除 ReplicaSet 而不影响它的各个 Pod方法是使用
[`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)
命令并设置 `--cascade=orphan` 选项。
@ -517,17 +516,17 @@ assuming that the number of replicas is not also changed).
A ReplicaSet can be easily scaled up or down by simply updating the `.spec.replicas` field. The ReplicaSet controller
ensures that a desired number of Pods with a matching label selector are available and operational.
-->
### 缩 RepliaSet {#scaling-a-replicaset}
### 缩 RepliaSet {#scaling-a-replicaset}
通过更新 `.spec.replicas` 字段ReplicaSet 可以被轻松的进行缩放。ReplicaSet
通过更新 `.spec.replicas` 字段ReplicaSet 可以被轻松地进行扩缩。ReplicaSet
控制器能确保匹配标签选择器的数量的 Pod 是可用的和可操作的。
<!--
When scaling down, the ReplicaSet controller chooses which pods to delete by sorting the available pods to
prioritize scaling down pods based on the following general algorithm:
-->
在降低集合规模时ReplicaSet 控制器通过对可用的 Pods 进行排序来优先选择
要被删除的 Pods。其一般性算法如下:
在降低集合规模时ReplicaSet 控制器通过对可用的所有 Pod 进行排序来优先选择要被删除的那些 Pod。
其一般性算法如下:
<!--
1. Pending (and unschedulable) pods are scaled down first
@ -538,9 +537,8 @@ prioritize scaling down pods based on the following general algorithm:
comes before the older pod (the creation times are bucketed on an integer log scale
when the `LogarithmicScaleDown` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled)
-->
1. 首先选择剔除悬决Pending且不可调度的 Pods
2. 如果设置了 `controller.kubernetes.io/pod-deletion-cost` 注解,则注解值
较小的优先被裁减掉
1. 首先选择剔除悬决Pending且不可调度的各个 Pod
2. 如果设置了 `controller.kubernetes.io/pod-deletion-cost` 注解,则注解值较小的优先被裁减掉
3. 所处节点上副本个数较多的 Pod 优先于所处节点上副本较少者
4. 如果 Pod 的创建时间不同,最近创建的 Pod 优先于早前创建的 Pod 被裁减。
(当 `LogarithmicScaleDown` 这一[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)
@ -560,7 +558,7 @@ Using the [`controller.kubernetes.io/pod-deletion-cost`](/docs/reference/labels-
annotation, users can set a preference regarding which pods to remove first when downscaling a ReplicaSet.
-->
通过使用 [`controller.kubernetes.io/pod-deletion-cost`](/zh-cn/docs/reference/labels-annotations-taints/#pod-deletion-cost)
注解,用户可以对 ReplicaSet 缩容时要先删除哪些 Pods 设置偏好。
注解,用户可以对 ReplicaSet 缩容时要先删除哪些 Pod 设置偏好。
<!--
The annotation should be set on the pod, the range is [-2147483647, 2147483647]. It represents the cost of
@ -568,14 +566,14 @@ deleting a pod compared to other pods belonging to the same ReplicaSet. Pods wit
cost are preferred to be deleted before pods with higher deletion cost.
-->
此注解要设置到 Pod 上,取值范围为 [-2147483647, 2147483647]。
所代表的是删除同一 ReplicaSet 中其他 Pod 相比较而言的开销。
删除开销较小的 Pods 比删除开销较高的 Pods 更容易被删除。
所代表的是删除同一 ReplicaSet 中其他 Pod 相比较而言的开销。
删除开销较小的 Pod 比删除开销较高的 Pod 更容易被删除。
<!--
The implicit value for this annotation for pods that don't set it is 0; negative values are permitted.
Invalid values will be rejected by the API server.
-->
Pods 如果未设置此注解,则隐含的设置值为 0。负值也是可接受的。
Pod 如果未设置此注解,则隐含的设置值为 0。负值也是可接受的。
如果注解值非法API 服务器会拒绝对应的 Pod。
<!--
@ -609,12 +607,11 @@ the down scaling; for example, the driver pod of a Spark deployment.
-->
#### 使用场景示例 {#example-use-case}
同一应用的不同 Pods 可能其利用率是不同的。在对应用执行缩容操作时,可能
希望移除利用率较低的 Pods。为了避免频繁更新 Pods,应用应该在执行缩容
操作之前更新一次 `controller.kubernetes.io/pod-deletion-cost` 注解值
同一应用的不同 Pod 可能其利用率是不同的。在对应用执行缩容操作时,
可能希望移除利用率较低的 Pod。为了避免频繁更新 Pod应用应该在执行缩容操作之前更新一次
`controller.kubernetes.io/pod-deletion-cost` 注解值
(将注解值设置为一个与其 Pod 利用率对应的值)。
如果应用自身控制器缩容操作时(例如 Spark 部署的驱动 Pod这种机制
是可以起作用的。
如果应用自身控制器缩容操作时(例如 Spark 部署的驱动 Pod这种机制是可以起作用的。
<!--
### ReplicaSet as a Horizontal Pod Autoscaler Target
@ -624,10 +621,10 @@ A ReplicaSet can also be a target for
a ReplicaSet can be auto-scaled by an HPA. Here is an example HPA targeting
the ReplicaSet we created in the previous example.
-->
### ReplicaSet 作为水平的 Pod 自动缩器目标 {#replicaset-as-a-horizontal-pod-autoscaler-target}
### ReplicaSet 作为水平的 Pod 自动缩器目标 {#replicaset-as-a-horizontal-pod-autoscaler-target}
ReplicaSet 也可以作为[水平的 Pod 缩器 (HPA)](/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale/)
的目标。也就是说ReplicaSet 可以被 HPA 自动缩
ReplicaSet 也可以作为[水平的 Pod 缩器 (HPA)](/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale/)
的目标。也就是说ReplicaSet 可以被 HPA 自动缩。
以下是 HPA 以我们在前一个示例中创建的副本集为目标的示例。
{{< codenew file="controllers/hpa-rs.yaml" >}}
@ -638,7 +635,7 @@ create the defined HPA that autoscales the target ReplicaSet depending on the CP
of the replicated Pods.
-->
将这个列表保存到 `hpa-rs.yaml` 并提交到 Kubernetes 集群,就能创建它所定义的
HPA进而就能根据复制的 Pod 的 CPU 利用率对目标 ReplicaSet进行自动缩
HPA进而就能根据复制的 Pod 的 CPU 利用率对目标 ReplicaSet 进行自动缩。
```shell
kubectl apply -f https://k8s.io/examples/controllers/hpa-rs.yaml
@ -648,7 +645,7 @@ kubectl apply -f https://k8s.io/examples/controllers/hpa-rs.yaml
Alternatively, you can use the `kubectl autoscale` command to accomplish the same
(and it's easier!)
-->
或者,可以使用 `kubectl autoscale` 命令完成相同的操作(而且它更简单!)
或者,可以使用 `kubectl autoscale` 命令完成相同的操作(而且它更简单!)
```shell
kubectl autoscale rs frontend --max=10 --min=3 --cpu-percent=50
@ -671,7 +668,7 @@ As such, it is recommended to use Deployments when you want ReplicaSets.
### Deployment推荐 {#deployment-recommended}
[`Deployment`](/zh-cn/docs/concepts/workloads/controllers/deployment/) 是一个可以拥有
ReplicaSet 并使用声明式方式在服务器端完成对 Pods 滚动更新的对象。
ReplicaSet 并使用声明式方式在服务器端完成对 Pod 滚动更新的对象。
尽管 ReplicaSet 可以独立使用,目前它们的主要用途是提供给 Deployment 作为编排
Pod 创建、删除和更新的一种机制。当使用 Deployment 时,你不必关心如何管理它所创建的
ReplicaSetDeployment 拥有并管理其 ReplicaSet。
@ -754,4 +751,3 @@ ReplicaSet 是 [ReplicationController](/zh-cn/docs/concepts/workloads/controller
对象定义理解关于该资源的 API。
* 阅读 [Pod 干扰预算Disruption Budget](/zh-cn/docs/concepts/workloads/pods/disruptions/)
了解如何在干扰下运行高度可用的应用。