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

Merge pull request #39799 from Zhuzhenghao/deployment 

[zh] sync pages in concepts/workloads/controllers/
pull/39874/head
Kubernetes Prow Robot 2023-03-08 23:42:01 -08:00 committed by GitHub
parent 1290b02fd3 48c6be119c
commit 58484d9e03
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 54 additions and 49 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

98
content/zh-cn/docs/concepts/workloads/controllers/deployment.md
View File

@ -8,6 +8,8 @@ content_type: concept
weight: 10
---
<!--
reviewers:
- janetkuo
title: Deployments
feature:
title: Automated rollouts and rollbacks
@ -80,7 +82,7 @@ The following are typical use cases for Deployments:
* [清理较旧的不再需要的 ReplicaSet](#clean-up-policy) 。
<!--
## Creating a Deployment
## Creating a Deployment
The following is an example of a Deployment. It creates a ReplicaSet to bring up three `nginx` Pods:
-->
@ -97,8 +99,8 @@ In this example:
<!--
* A Deployment named `nginx-deployment` is created, indicated by the
`.metadata.name` field. This name will become the basis for the ReplicaSets
and Pods which are created later. See [Writing a Deployment Spec](#writing-a-deployment-spec)
`.metadata.name` field. This name will become the basis for the ReplicaSets
and Pods which are created later. See [Writing a Deployment Spec](#writing-a-deployment-spec)
for more details.
* The Deployment creates a ReplicaSet that creates three replicated Pods, indicated by the `.spec.replicas` field.
* The `.spec.selector` field defines how the created ReplicaSet finds which Pods to manage.
@ -116,12 +118,12 @@ In this example:
{{< note >}}
<!--
The `spec.selector.matchLabels` field is a map of {key,value} pairs.
The `.spec.selector.matchLabels` field is a map of {key,value} pairs.
A single {key,value} in the `matchLabels` map is equivalent to an element of `matchExpressions`,
whose `key` field is "key", the `operator` is "In", and the `values` array contains only "value".
All of the requirements, from both `matchLabels` and `matchExpressions`, must be satisfied in order to match.
-->
`spec.selector.matchLabels` 字段是 `{key,value}` 键值对映射。
`.spec.selector.matchLabels` 字段是 `{key,value}` 键值对映射。
在 `matchLabels` 映射中的每个 `{key,value}` 映射等效于 `matchExpressions` 中的一个元素，
即其 `key` 字段是 “key”，`operator` 为 “In”，`values` 数组仅包含 “value”。
在 `matchLabels` 和 `matchExpressions` 中给出的所有条件都必须满足才能匹配。
@ -158,9 +160,9 @@ Follow the steps given below to create the above Deployment:
```
<!--
2. Run `kubectl get deployments` to check if the Deployment was created.
2. Run `kubectl get deployments` to check if the Deployment was created.
If the Deployment is still being created, the output is similar to the following:
If the Deployment is still being created, the output is similar to the following:
-->
2. 运行 `kubectl get deployments` 检查 Deployment 是否已创建。
如果仍在创建 Deployment，则输出类似于：
@ -208,7 +210,7 @@ Follow the steps given below to create the above Deployment:
```
<!--
4. Run the `kubectl get deployments` again a few seconds later.
4. Run the `kubectl get deployments` again a few seconds later.
The output is similar to this:
-->
4. 几秒钟后再次运行 `kubectl get deployments`。输出类似于：
@ -255,7 +257,7 @@ Follow the steps given below to create the above Deployment:
<!--
Notice that the name of the ReplicaSet is always formatted as
`[DEPLOYMENT-NAME]-[HASH]`. This name will become the basis for the Pods
`[DEPLOYMENT-NAME]-[HASH]`. This name will become the basis for the Pods
which are created.
The `HASH` string is the same as the `pod-template-hash` label on the ReplicaSet.
-->
@ -296,7 +298,7 @@ Kubernetes 不会阻止你这样做，但是如果多个控制器具有重叠的
{{< /note >}}
<!--
### Pod-template-hash label
### Pod-template-hash label
-->
### Pod-template-hash 标签
@ -323,13 +325,13 @@ and in any existing Pods that the ReplicaSet might have.
可能拥有的任何现有 Pod 中。
<!--
## Updating a Deployment
## Updating a Deployment
-->
## 更新 Deployment {#updating-a-deployment}
{{< note >}}
<!--
A Deployment's rollout is triggered if and only if the Deployment's Pod template (that is, `.spec.template`)
A Deployment's rollout is triggered if and only if the Deployment's Pod template (that is, `.spec.template`)
is changed, for example if the labels or container images of the template are updated. Other updates, such as scaling the Deployment, do not trigger a rollout.
-->
仅当 Deployment Pod 模板（即 `.spec.template`）发生改变时，例如模板的标签或容器镜像被更新，
@ -353,7 +355,7 @@ Follow the steps given below to update your Deployment:
or use the following command:
-->
或者使用下面的命令：
```shell
kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1
```
@ -492,7 +494,7 @@ up to 3 replicas, as well as scaling down the old ReplicaSet to 0 replicas.
then deletes an old Pod, and creates another new one. It does not kill old Pods until a sufficient number of
new Pods have come up, and does not create new Pods until a sufficient number of old Pods have been killed.
It makes sure that at least 3 Pods are available and that at max 4 Pods in total are available. In case of
a Deployment with 4 replicas, the number of Pods would be between 3 and 5.
a Deployment with 4 replicas, the number of Pods would be between 3 and 5.
-->
例如，如果仔细查看上述 Deployment ，将看到它首先创建了一个新的 Pod，然后删除旧的 Pod，
并创建了新的 Pod。它不会杀死旧 Pod，直到有足够数量的新 Pod 已经出现。
@ -559,8 +561,7 @@ up to 3 replicas, as well as scaling down the old ReplicaSet to 0 replicas.
(nginx-deployment-1564180365) and scaled it up to 1 and waited for it to come up. Then it scaled down the old ReplicaSet
to 2 and scaled up the new ReplicaSet to 2 so that at least 3 Pods were available and at most 4 Pods were created at all times.
It then continued scaling up and down the new and the old ReplicaSet, with the same rolling update strategy.
Finally, you'll have 3 available replicas
in the new ReplicaSet, and the old ReplicaSet is scaled down to 0.
Finally, you'll have 3 available replicas in the new ReplicaSet, and the old ReplicaSet is scaled down to 0.
-->
可以看到，当第一次创建 Deployment 时，它创建了一个 ReplicaSet（`nginx-deployment-2035384211`）
并将其直接扩容至 3 个副本。更新 Deployment 时，它创建了一个新的 ReplicaSet
@ -624,7 +625,7 @@ 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.
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.
-->
@ -665,7 +666,7 @@ removed label still exists in any existing Pods and ReplicaSets.
## 回滚 Deployment {#rolling-back-a-deployment}
<!--
Sometimes, you may want to rollback a Deployment; for example, when the Deployment is not stable, such as crash looping.
Sometimes, you may want to rollback a Deployment; for example, when the Deployment is not stable, such as crash looping.
By default, all of the Deployment's rollout history is kept in the system so that you can rollback anytime you want
(you can change that by modifying revision history limit).
-->
@ -697,7 +698,7 @@ Deployment 被触发上线时，系统就会创建 Deployment 的新的修订版
`nginx:1.161` 而不是 `nginx:1.16.1`：
```shell
kubectl set image deployment/nginx-deployment nginx=nginx:1.161
kubectl set image deployment/nginx-deployment nginx=nginx:1.161
```
<!--
@ -734,7 +735,7 @@ Deployment 被触发上线时，系统就会创建 Deployment 的新的修订版
* 按 Ctrl-C 停止上述上线状态观测。有关上线停滞的详细信息，[参考这里](#deployment-status)。
<!--
* You see that the number of old replicas (`nginx-deployment-1564180365` and `nginx-deployment-2035384211`) is 2, and new replicas (nginx-deployment-3066724191) is 1.
* You see that the number of old replicas (`nginx-deployment-1564180365` and `nginx-deployment-2035384211`) is 2, and new replicas (nginx-deployment-3066724191) is 1.
-->
* 你可以看到旧的副本有两个（`nginx-deployment-1564180365` 和 `nginx-deployment-2035384211`），
新的副本有 1 个（`nginx-deployment-3066724191`）：
@ -748,7 +749,7 @@ Deployment 被触发上线时，系统就会创建 Deployment 的新的修订版
-->
输出类似于：
```shell
```
NAME DESIRED CURRENT READY AGE
nginx-deployment-1564180365 3 3 3 25s
nginx-deployment-2035384211 0 0 0 36s
@ -769,7 +770,7 @@ Deployment 被触发上线时，系统就会创建 Deployment 的新的修订版
-->
输出类似于：
```shell
```
NAME READY STATUS RESTARTS AGE
nginx-deployment-1564180365-70iae 1/1 Running 0 25s
nginx-deployment-1564180365-jbqqo 1/1 Running 0 25s
@ -828,7 +829,7 @@ Deployment 被触发上线时，系统就会创建 Deployment 的新的修订版
OldReplicaSets: nginx-deployment-1564180365 (3/3 replicas created)
NewReplicaSet: nginx-deployment-3066724191 (1/1 replicas created)
Events:
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
FirstSeen LastSeen Count From SubObjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
1m 1m 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-2035384211 to 3
22s 22s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 1
@ -855,7 +856,7 @@ Follow the steps given below to check the rollout history:
按照如下步骤检查回滚历史：
<!--
1. First, check the revisions of this Deployment:
1. First, check the revisions of this Deployment:
-->
1. 首先，检查 Deployment 修订历史：
@ -929,7 +930,7 @@ Follow the steps given below to rollback the Deployment from the current version
按照下面给出的步骤将 Deployment 从当前版本回滚到以前的版本（即版本 2）。
<!--
1. Now you've decided to undo the current rollout and rollback to the previous revision:
1. Now you've decided to undo the current rollout and rollback to the previous revision:
-->
1. 假定现在你已决定撤消当前上线并回滚到以前的修订版本：
@ -1229,7 +1230,7 @@ The output is similar to this:
-->
输出类似于：
```shell
```
NAME DESIRED CURRENT READY AGE
nginx-deployment-1989198191 7 7 0 7m
nginx-deployment-618515232 11 11 11 7m
@ -1307,7 +1308,7 @@ apply multiple fixes in between pausing and resuming without triggering unnecess
-->
输出类似于：
```shell
```
deployment.apps/nginx-deployment paused
```
@ -1363,7 +1364,7 @@ apply multiple fixes in between pausing and resuming without triggering unnecess
-->
输出类似于：
```shell
```
NAME DESIRED CURRENT READY AGE
nginx-2142116321 3 3 3 2m
```
@ -1388,7 +1389,8 @@ apply multiple fixes in between pausing and resuming without triggering unnecess
<!--
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 is paused.
the Deployment will not have any effect as long as the Deployment rollout is paused.
-->
暂停 Deployment 上线之前的初始状态将继续发挥作用，但新的更新在 Deployment
上线被暂停期间不会产生任何效果。
@ -1573,7 +1575,7 @@ The output is similar to this:
-->
输出类似于：
```shell
```
Waiting for rollout to finish: 2 of 3 updated replicas are available...
deployment "nginx-deployment" successfully rolled out
```
@ -1584,7 +1586,7 @@ and the exit status from `kubectl rollout` is 0 (success):
从 `kubectl rollout` 命令获得的返回状态为 0（成功）：
```shell
$ echo $?
echo $?
```
```
0
@ -1603,7 +1605,7 @@ due to some of the following factors:
造成此情况一些可能因素如下：
<!--
* Insufficient quota
* Insufficient quota
* Readiness probe failures
* Image pull errors
* Insufficient permissions
@ -1676,7 +1678,7 @@ See the [Kubernetes API conventions](https://git.k8s.io/community/contributors/d
{{< note >}}
<!--
Kubernetes takes no action on a stalled Deployment other than to report a status condition with
Kubernetes takes no action on a stalled Deployment other than to report a status condition with
`reason: ProgressDeadlineExceeded`. Higher level orchestrators can take advantage of it and act accordingly, for
example, rollback the Deployment to its previous version.
-->
@ -1687,8 +1689,8 @@ Deployment 不执行任何操作。更高级别的编排器可以利用这一设
{{< note >}}
<!--
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
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.
-->
如果你暂停了某个 Deployment 上线，Kubernetes 不再根据指定的截止时间检查 Deployment 上线的进展。
@ -1831,7 +1833,7 @@ and the exit status from `kubectl rollout` is 1 (indicating an error):
`kubectl rollout` 命令的退出状态为 1（表明发生了错误）：
```shell
$ echo $?
echo $?
```
```
1
@ -1899,9 +1901,9 @@ configuring containers, and [using kubectl to manage resources](/docs/concepts/o
<!--
When the control plane creates new Pods for a Deployment, the `.metadata.name` of the
Deployment is part of the basis for naming those Pods. The name of a Deployment must be a valid
Deployment is part of the basis for naming those Pods. The name of a Deployment must be a valid
[DNS subdomain](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)
value, but this can produce unexpected results for the Pod hostnames. For best compatibility,
value, but this can produce unexpected results for the Pod hostnames. For best compatibility,
the name should follow the more restrictive rules for a
[DNS label](/docs/concepts/overview/working-with-objects/names#dns-label-names).
@ -2056,11 +2058,11 @@ All existing Pods are killed before new ones are created when `.spec.strategy.ty
{{< note >}}
<!--
This will only guarantee Pod termination previous to creation for upgrades. If you upgrade a Deployment, all Pods
of the old revision will be terminated immediately. Successful removal is awaited before any Pod of the new
revision is created. If you manually delete a Pod, the lifecycle is controlled by the ReplicaSet and the
replacement will be created immediately (even if the old Pod is still in a Terminating state). If you need an
"at most" guarantee for your Pods, you should consider using a
This will only guarantee Pod termination previous to creation for upgrades. If you upgrade a Deployment, all Pods
of the old revision will be terminated immediately. Successful removal is awaited before any Pod of the new
revision is created. If you manually delete a Pod, the lifecycle is controlled by the ReplicaSet and the
replacement will be created immediately (even if the old Pod is still in a Terminating state). If you need an
"at most" guarantee for your Pods, you should consider using a
[StatefulSet](/docs/concepts/workloads/controllers/statefulset/).
-->
这只会确保为了升级而创建新 Pod 之前其他 Pod 都已终止。如果你升级一个 Deployment，
@ -2114,7 +2116,7 @@ at all times during the update is at least 70% of the desired Pods.
<!--
##### Max Surge
`.spec.strategy.rollingUpdate.maxSurge` is an optional field that specifies the maximum number of Pods
`.spec.strategy.rollingUpdate.maxSurge` is an optional field that specifies the maximum number of Pods
that can be created over the desired number of Pods. The value can be an absolute number (for example, 5) or a
percentage of desired Pods (for example, 10%). The value cannot be 0 if `MaxUnavailable` is 0. The absolute number
is calculated from the percentage by rounding up. The default value is 25%.
@ -2137,11 +2139,11 @@ total number of Pods running at any time during the update is at most 130% of de
同时确保更新期间的任何时候运行中的 Pod 总数最多为所需 Pod 总数的 130%。
<!--
### Progress Deadline Seconds
### Progress Deadline Seconds
`.spec.progressDeadlineSeconds` is an optional field that specifies the number of seconds you want
`.spec.progressDeadlineSeconds` is an optional field that specifies the number of seconds you want
to wait for your Deployment to progress before the system reports back that the Deployment has
[failed progressing](#failed-deployment) - surfaced as a condition with `type: Progressing`, `status: False`.
[failed progressing](#failed-deployment) - surfaced as a condition with `type: Progressing`, `status: "False"`.
and `reason: ProgressDeadlineExceeded` in the status of the resource. The Deployment controller will keep
retrying the Deployment. This defaults to 600. In the future, once automatic rollback will be implemented, the Deployment
controller will roll back a Deployment as soon as it observes such a condition.
@ -2162,7 +2164,7 @@ If specified, this field needs to be greater than `.spec.minReadySeconds`.
<!--
### Min Ready Seconds
`.spec.minReadySeconds` is an optional field that specifies the minimum number of seconds for which a newly
`.spec.minReadySeconds` is an optional field that specifies the minimum number of seconds for which a newly
created Pod should be ready without any of its containers crashing, for it to be considered available.
This defaults to 0 (the Pod will be considered available as soon as it is ready). To learn more about when
a Pod is considered ready, see [Container Probes](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes).

5
content/zh-cn/docs/concepts/workloads/controllers/replicaset.md
View File

@ -574,6 +574,9 @@ prioritize scaling down pods based on the following general algorithm:
（当 `LogarithmicScaleDown` 这一[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)
被启用时，创建时间是按整数幂级来分组的）。
<!--
If all of the above match, then selection is random.
-->
如果以上比较结果都相同，则随机选择。
<!--
@ -688,7 +691,7 @@ kubectl autoscale rs frontend --max=10 --min=3 --cpu-percent=50
[`Deployment`](/docs/concepts/workloads/controllers/deployment/) is an object which can own ReplicaSets and update
them and their Pods via declarative, server-side rolling updates.
While ReplicaSets can be used independently, today they're mainly used by Deployments as a mechanism to orchestrate Pod
While ReplicaSets can be used independently, today they're mainly used by Deployments as a mechanism to orchestrate Pod
creation, deletion and updates. When you use Deployments you don't have to worry about managing the ReplicaSets that
they create. Deployments own and manage their ReplicaSets.
As such, it is recommended to use Deployments when you want ReplicaSets.