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

Merge pull request #34014 from Sea-n/zh-code-output-manage 

[zh] Sync manage-daemon
pull/34031/head
Kubernetes Prow Robot 2022-05-29 18:16:53 -07:00 committed by GitHub
parent b608cc1066 dd34014f77
commit e92477b00f
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 69 additions and 59 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

53
content/zh/docs/tasks/manage-daemon/update-daemon-set.md
View File

@ -12,6 +12,7 @@ content_type: task
-->
<!-- overview -->
<!--
This page shows how to perform a rolling update on a DaemonSet.
-->
@ -28,7 +29,7 @@ This page shows how to perform a rolling update on a DaemonSet.
DaemonSet has two update strategy types:
-->
## DaemonSet 更新策略
## DaemonSet 更新策略 {#daemonset-update-strategy}
DaemonSet 有两种更新策略：
@ -40,8 +41,8 @@ DaemonSet 有两种更新策略：
* `RollingUpdate`: This is the default update strategy.
With `RollingUpdate` update strategy, after you update a
DaemonSet template, old DaemonSet pods will be killed, and new DaemonSet pods
will be created automatically, in a controlled fashion.
At most one pod of the DaemonSet will be running on each node during the whole update process.
will be created automatically, in a controlled fashion. At most one pod of
the DaemonSet will be running on each node during the whole update process.
-->
* `OnDelete`: 使用 `OnDelete` 更新策略时，在更新 DaemonSet 模板后，只有当你手动删除老的
@ -56,16 +57,16 @@ DaemonSet 有两种更新策略：
To enable the rolling update feature of a DaemonSet, you must set its
`.spec.updateStrategy.type` to `RollingUpdate`.
-->
## 执行滚动更新
## 执行滚动更新 {#performing-a-rolling-update}
要启用 DaemonSet 的滚动更新功能，必须设置 `.spec.updateStrategy.type` 为 `RollingUpdate`。
<!--
You may want to set
You may want to set
[`.spec.updateStrategy.rollingUpdate.maxUnavailable`](/docs/reference/kubernetes-api/workload-resources/daemon-set-v1/#DaemonSetSpec)
(default to 1),
[`.spec.minReadySeconds`](/docs/reference/kubernetes-api/workload-resources/daemon-set-v1/#DaemonSetSpec)
(default to 0) and
[`.spec.minReadySeconds`](/docs/reference/kubernetes-api/workload-resources/daemon-set-v1/#DaemonSetSpec)
(default to 0) and
[`.spec.updateStrategy.rollingUpdate.maxSurge`](/docs/reference/kubernetes-api/workload-resources/daemon-set-v1/#DaemonSetSpec)
(a beta feature and defaults to 0) as well.
@ -74,14 +75,14 @@ You may want to set
[`.spec.updateStrategy.rollingUpdate.maxUnavailable`](/zh/docs/reference/kubernetes-api/workload-resources/daemon-set-v1/#DaemonSetSpec) (默认为 1)，
[`.spec.minReadySeconds`](/zh/docs/reference/kubernetes-api/workload-resources/daemon-set-v1/#DaemonSetSpec) (默认为 0) 和
[`.spec.updateStrategy.rollingUpdate.maxSurge`](/zh/docs/reference/kubernetes-api/workload-resources/daemon-set-v1/#DaemonSetSpec)
（一种 Beta 阶段的特性，默认为 0）。
（一种 Beta 阶段的特性，默认为 0）。
<!--
### Creating a DaemonSet with `RollingUpdate` update strategy
This YAML file specifies a DaemonSet with an update strategy as 'RollingUpdate'
-->
### 创建带有 `RollingUpdate` 更新策略的 DaemonSet
### 创建带有 `RollingUpdate` 更新策略的 DaemonSet {#creating-a-daemonset-with-rollingupdate-update-strategy}
下面的 YAML 包含一个 DaemonSet，其更新策略为 'RollingUpdate'：
@ -113,7 +114,7 @@ kubectl apply -f https://k8s.io/examples/controllers/fluentd-daemonset.yaml
Check the update strategy of your DaemonSet, and make sure it's set to
`RollingUpdate`:
-->
### 检查 DaemonSet 的滚动更新策略
### 检查 DaemonSet 的滚动更新策略 {#checking-daemonset-rollingupdate-update-strategy}
首先，检查 DaemonSet 的更新策略，确保已经将其设置为 `RollingUpdate`:
@ -152,7 +153,7 @@ manifest accordingly.
Any updates to a `RollingUpdate` DaemonSet `.spec.template` will trigger a rolling
update. Let's update the DaemonSet by applying a new YAML file. This can be done with several different `kubectl` commands.
-->
### 更新 DaemonSet 模板
### 更新 DaemonSet 模板 {#updating-a-daemonset-template}
对 `RollingUpdate` DaemonSet 的 `.spec.template` 的任何更新都将触发滚动更新。
这可以通过几个不同的 `kubectl` 命令来完成。
@ -166,7 +167,7 @@ If you update DaemonSets using
[configuration files](/docs/tasks/manage-kubernetes-objects/declarative-config/),
use `kubectl apply`:
-->
#### 声明式命令
#### 声明式命令 {#declarative-commands}
如果你使用
[配置文件](/zh/docs/tasks/manage-kubernetes-objects/declarative-config/)
@ -180,14 +181,14 @@ kubectl apply -f https://k8s.io/examples/controllers/fluentd-daemonset-update.ya
#### Imperative commands
If you update DaemonSets using
[imperative commands](/docs/concepts/overview/object-management-kubectl/imperative-command/),
[imperative commands](/docs/tasks/manage-kubernetes-objects/imperative-command/),
use `kubectl edit`:
-->
#### 指令式命令
#### 指令式命令 {#imperative-commands}
如果你使用
[指令式命令](/zh/docs/tasks/manage-kubernetes-objects/imperative-command/)
来更新 DaemonSets，请使用`kubectl edit`：
来更新 DaemonSets，请使用 `kubectl edit`：
```shell
kubectl edit ds/fluentd-elasticsearch -n kube-system
@ -199,21 +200,21 @@ kubectl edit ds/fluentd-elasticsearch -n kube-system
If you only need to update the container image in the DaemonSet template, i.e.
`.spec.template.spec.containers[*].image`, use `kubectl set image`:
--->
##### 只更新容器镜像
##### 只更新容器镜像 {#updating-only-the-container-image}
如果你只需要更新 DaemonSet 模板里的容器镜像，比如，`.spec.template.spec.containers[*].image`,
请使用 `kubectl set image`:
如果你只需要更新 DaemonSet 模板里的容器镜像，比如 `.spec.template.spec.containers[*].image`，
请使用 `kubectl set image`：
```shell
kubectl set image ds/fluentd-elasticsearch fluentd-elasticsearch=quay.io/fluentd_elasticsearch/fluentd:v2.6.0 -n kube-system
```
<!--
### Step 4: Watching the rolling update status
### Watching the rolling update status
Finally, watch the rollout status of the latest DaemonSet rolling update:
-->
### 监视滚动更新状态
### 监视滚动更新状态 {#watching-the-rolling-update-status}
最后，观察 DaemonSet 最新滚动更新的进度：
@ -235,9 +236,9 @@ daemonset "fluentd-elasticsearch" successfully rolled out
### DaemonSet rolling update is stuck
-->
## 故障排查
## 故障排查 {#troubleshooting}
### DaemonSet 滚动更新卡住
### DaemonSet 滚动更新卡住 {#daemonset-rolling-update-is-stuck}
<!--
Sometimes, a DaemonSet rolling update may be stuck. Here are some possible
@ -248,7 +249,7 @@ causes:
有时，DaemonSet 滚动更新可能卡住，以下是一些可能的原因：
#### 一些节点可用资源耗尽
#### 一些节点可用资源耗尽 {#some-nodes-run-out-of-resources}
<!--
The rollout is stuck because new DaemonSet pods can't be scheduled on at least one
@ -294,7 +295,7 @@ If the recent DaemonSet template update is broken, for example, the container is
crash looping, or the container image doesn't exist (often due to a typo),
DaemonSet rollout won't progress.
-->
#### 不完整的滚动更新
#### 不完整的滚动更新 {#broken-rollout}
如果最近的 DaemonSet 模板更新被破坏了，比如，容器处于崩溃循环状态或者容器镜像不存在
（通常由于拼写错误），就会发生 DaemonSet 滚动更新中断。
@ -312,7 +313,7 @@ If `.spec.minReadySeconds` is specified in the DaemonSet, clock skew between
master and nodes will make DaemonSet unable to detect the right rollout
progress.
-->
#### 时钟偏差
#### 时钟偏差 {#clock-skew}
如果在 DaemonSet 中指定了 `.spec.minReadySeconds`，主控节点和工作节点之间的时钟偏差会使
DaemonSet 无法检测到正确的滚动更新进度。
@ -322,7 +323,7 @@ DaemonSet 无法检测到正确的滚动更新进度。
Delete DaemonSet from a namespace :
-->
## 清理
## 清理 {#clean-up}
从名字空间中删除 DaemonSet：

75
content/zh/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch.md
View File

@ -9,7 +9,7 @@ weight: 50
title: Update API Objects in Place Using kubectl patch
description: Use kubectl patch to update Kubernetes API objects in place. Do a strategic merge patch or a JSON merge patch.
content_type: task
weight: 40
weight: 50
-->
<!-- overview -->
@ -34,7 +34,7 @@ in this task demonstrate a strategic merge patch and a JSON merge patch.
Here's the configuration file for a Deployment that has two replicas. Each replica
is a Pod that has one container:
-->
## 使用策略合并 patch 更新 Deployment
## 使用策略合并 patch 更新 Deployment {#use-a-strategic-merge-patch-to-update-a-deployment}
下面是具有两个副本的 Deployment 的配置文件。每个副本是一个 Pod，有一个容器：
@ -46,7 +46,7 @@ Create the Deployment:
创建 Deployment：
```shell
kubectl create -f https://k8s.io/examples/application/deployment-patch.yaml
kubectl apply -f https://k8s.io/examples/application/deployment-patch.yaml
```
<!--
@ -83,9 +83,9 @@ you want each Pod to have two containers: one that runs nginx and one that runs
此时，每个 Pod 都有一个运行 nginx 镜像的容器。现在假设你希望每个 Pod 有两个容器：一个运行 nginx，另一个运行 redis。
<!--
Create a file named `patch-file-containers.yaml` that has this content:
Create a file named `patch-file.yaml` that has this content:
-->
创建一个名为 `patch-file-containers.yaml` 的文件。内容如下:
创建一个名为 `patch-file.yaml` 的文件。内容如下:
```yaml
spec:
@ -102,7 +102,7 @@ Patch your Deployment:
修补你的 Deployment：
```shell
kubectl patch deployment patch-demo --patch "$(cat patch-file-containers.yaml)"
kubectl patch deployment patch-demo --patch-file patch-file.yaml
```
<!--
View the patched Deployment:
@ -185,10 +185,10 @@ Container to the list. In other words, the list in the patch was merged with the
existing list. This is not always what happens when you use a strategic merge patch on a list.
In some cases, the list is replaced, not merged.
-->
### 策略性合并类的 patch 的说明
### 策略性合并类的 patch 的说明 {#notes-on-the-strategic-merge-patch}
你在前面的练习中所做的 patch 称为`策略性合并 patch（Strategic Merge Patch)`。
请注意，patch 没有替换`containers` 列表。相反，它向列表中添加了一个新 Container。换句话说，
你在前面的练习中所做的 patch 称为 `策略性合并 patch（Strategic Merge Patch）`。
请注意，patch 没有替换 `containers` 列表。相反，它向列表中添加了一个新 Container。换句话说，
patch 中的列表与现有列表合并。当你在列表中使用策略性合并 patch 时，并不总是这样。
在某些情况下，列表是替换的，而不是合并的。
@ -295,7 +295,7 @@ Notice that the `tolerations` list in the PodSpec was replaced, not merged. This
the Tolerations field of PodSpec does not have a `patchStrategy` key in its field tag. So the
strategic merge patch uses the default patch strategy, which is `replace`.
-->
请注意，PodSpec 中的 `tolerations` 列表被替换，而不是合并。这是因为 PodSpec 的 `tolerations`
请注意，PodSpec 中的 `tolerations` 列表被替换，而不是合并。这是因为 PodSpec 的 `tolerations`
的字段标签中没有 `patchStrategy` 键。所以策略合并 patch 操作使用默认的 patch 策略，也就是 `replace`。
```go
@ -313,7 +313,7 @@ With a JSON merge patch, if you
want to update a list, you have to specify the entire new list. And the new list completely
replaces the existing list.
-->
## 使用 JSON 合并 patch 更新 Deployment
## 使用 JSON 合并 patch 更新 Deployment {#use-a-json-merge-patch-to-update-a-deployment}
策略性合并 patch 不同于 [JSON 合并 patch](https://tools.ietf.org/html/rfc7386)。
使用 JSON 合并 patch，如果你想更新列表，你必须指定整个新列表。新的列表完全取代现有的列表。
@ -324,11 +324,15 @@ The `kubectl patch` command has a `type` parameter that you can set to one of th
`kubectl patch` 命令有一个 `type` 参数，你可以将其设置为以下值之一:
<table>
<!-- tr><th>Parameter value</th><th>Merge type</th></tr -->
<!--
<tr><th>Parameter value</th><th>Merge type</th></tr>
-->
<tr><th>参数值</th><th>合并类型</th></tr>
<tr><td>json</td><td><a href="https://tools.ietf.org/html/rfc6902">JSON Patch, RFC 6902</a></td></tr>
<tr><td>merge</td><td><a href="https://tools.ietf.org/html/rfc7386">JSON Merge Patch, RFC 7386</a></td></tr>
<!-- tr><td>strategic</td><td>Strategic merge patch</td></tr -->
<!--
<tr><td>strategic</td><td>Strategic merge patch</td></tr>
-->
<tr><td>strategic</td><td>策略合并 patch</td></tr>
</table>
@ -382,7 +386,7 @@ kubectl get deployment patch-demo --output yaml
The `containers` list that you specified in the patch has only one Container.
The output shows that your list of one Container replaced the existing `containers` list.
-->
patch 中指定的`containers`列表只有一个 Container。
patch 中指定的 `containers` 列表只有一个 Container。
输出显示你所给出的 Contaier 列表替换了现有的 `containers` 列表。
```yaml
@ -406,7 +410,7 @@ kubectl get pods
In the output, you can see that the existing Pods were terminated, and new Pods
were created. The `1/1` indicates that each new Pod is running only one Container.
-->
在输出中，你可以看到已经终止了现有的 Pod，并创建了新的 Pod。`1/1` 表示每个新 Pod只运行一个容器。
在输出中，你可以看到已经终止了现有的 Pod，并创建了新的 Pod。`1/1` 表示每个新 Pod 只运行一个容器。
```shell
NAME READY STATUS RESTARTS AGE
@ -419,11 +423,13 @@ patch-demo-1307768864-c86dc 1/1 Running 0 1m
Here's the configuration file for a Deployment that uses the `RollingUpdate` strategy:
-->
## 使用带 retainKeys 策略的策略合并 patch 更新 Deployment
## 使用带 retainKeys 策略的策略合并 patch 更新 Deployment {#use-strategic-merge-patch-to-update-a-deployment-using-the-retainkeys-strategy}
{{< codenew file="application/deployment-retainkeys.yaml" >}}
<!-- Create the deployment: -->
<!--
Create the deployment:
-->
创建 Deployment：
```shell
@ -445,11 +451,13 @@ spec:
type: Recreate
```
<!-- Patch your Deployment: -->
<!--
Patch your Deployment:
-->
修补你的 Deployment:
```shell
kubectl patch deployment patch-demo --patch-file patch-file.yaml
kubectl patch deployment retainkeys-demo --type merge --patch-file patch-file-no-retainkeys.yaml
```
<!--
@ -458,7 +466,7 @@ In the output, you can see that it is not possible to set `type` as `Recreate` w
在输出中，你可以看到，当 `spec.strategy.rollingUpdate` 已经拥有取值定义时，
将其 `type` 设置为 `Recreate` 是不可能的。
```shell
```
The Deployment "retainkeys-demo" is invalid: spec.strategy.rollingUpdate: Forbidden: may not be specified when strategy `type` is 'Recreate'
```
@ -491,10 +499,12 @@ Patch your Deployment again with this new patch:
使用新的 patch 重新修补 Deployment：
```shell
kubectl patch deployment retainkeys-demo --type merge --patch-file patch-file-no-retainkeys.yaml
kubectl patch deployment retainkeys-demo --type merge --patch-file patch-file-retainkeys.yaml
```
<!-- Examine the content of the Deployment: -->
<!--
Examine the content of the Deployment:
-->
检查 Deployment 的内容：
```shell
@ -506,7 +516,7 @@ The output shows that the strategy object in the Deployment does not contain the
-->
输出显示 Deployment 中的 `strategy` 对象不再包含 `rollingUpdate` 键：
```shell
```yaml
spec:
strategy:
type: Recreate
@ -524,11 +534,11 @@ The patch you did in the preceding exercise is called a *strategic merge patch w
- All of the missing fields will be cleared when patching.
- All fields in the `$retainKeys` list must be a superset or the same as the fields present in the patch.
-->
### 关于使用 retainKeys 策略的策略合并 patch 操作的说明
### 关于使用 retainKeys 策略的策略合并 patch 操作的说明 {#notes-on-the-strategic-merge-patch-using-the-retainkeys-strategy}
在前文练习中所执行的称作 *带 `retainKeys` 策略的策略合并 patch（Strategic Merge
Patch with retainKeys Strategy）*。
这种方法引入了一种新的 `$retainKey` 指令，具有如下策略：
这种方法引入了一种新的 `$retainKey` 指令，具有如下策略：
- 其中包含一个字符串列表；
- 所有需要被保留的字段必须在 `$retainKeys` 列表中给出；
@ -542,7 +552,7 @@ The `retainKeys` strategy does not work for all objects. It only works when the
策略 `retainKeys` 并不能对所有对象都起作用。它仅对那些 Kubernetes 源码中
`patchStrategy` 字段标志值包含 `retainKeys` 的字段有用。
例如 `DeploymentSpec` 结构的 `Strategy` 字段就包含了 `patchStrategy` 为
`retainKeys` 的标志。
`retainKeys` 的标志。
```go
type DeploymentSpec struct {
@ -580,7 +590,7 @@ And you can see the `retainKeys` strategy in the
The `kubectl patch` command takes YAML or JSON. It can take the patch as a file or
directly on the command line.
-->
## kubectl patch 命令的其他形式
## kubectl patch 命令的其他形式 {#alternate-forms-of-the-kubectl-patch-command}
`kubectl patch` 命令使用 YAML 或 JSON。它可以接受以文件形式提供的补丁，也可以
接受直接在命令行中给出的补丁。
@ -633,16 +643,15 @@ create the Deployment object. Other commands for updating API objects include
and
[kubectl apply](/docs/reference/generated/kubectl/kubectl-commands/#apply).
-->
## 总结
## 总结 {#summary}
在本练习中，你使用 `kubectl patch` 更改了 Deployment 对象的当前配置。
你没有更改最初用于创建 Deployment 对象的配置文件。
用于更新 API 对象的其他命令包括
[`kubectl annotate`](/docs/reference/generated/kubectl/kubectl-commands/#annotate)，
[`kubectl edit`](/docs/reference/generated/kubectl/kubectl-commands/#edit)，
[`kubectl replace`](/docs/reference/generated/kubectl/kubectl-commands/#replace)，
[`kubectl scale`](/docs/reference/generated/kubectl/kubectl-commands/#scale)，
和
[`kubectl annotate`](/docs/reference/generated/kubectl/kubectl-commands/#annotate)、
[`kubectl edit`](/docs/reference/generated/kubectl/kubectl-commands/#edit)、
[`kubectl replace`](/docs/reference/generated/kubectl/kubectl-commands/#replace)、
[`kubectl scale`](/docs/reference/generated/kubectl/kubectl-commands/#scale) 和
[`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands/#apply)。