diff --git a/content/zh/docs/tasks/manage-daemon/update-daemon-set.md b/content/zh/docs/tasks/manage-daemon/update-daemon-set.md index ee8bc83eaf..7b6b45772e 100644 --- a/content/zh/docs/tasks/manage-daemon/update-daemon-set.md +++ b/content/zh/docs/tasks/manage-daemon/update-daemon-set.md @@ -12,6 +12,7 @@ content_type: task --> + @@ -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`。 -### 创建带有 `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 ``` -### 监视滚动更新状态 +### 监视滚动更新状态 {#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} -#### 不完整的滚动更新 +#### 不完整的滚动更新 {#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： diff --git a/content/zh/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch.md b/content/zh/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch.md index af9c187e4d..3acc52f7c8 100644 --- a/content/zh/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch.md +++ b/content/zh/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch.md @@ -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 --> @@ -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 ``` -创建一个名为 `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 ``` -### 策略性合并类的 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` 参数，你可以将其设置为以下值之一: - + - +
参数值合并类型
jsonJSON Patch, RFC 6902
mergeJSON Merge Patch, RFC 7386
strategic策略合并 patch
@@ -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" >}} - + 创建 Deployment： ```shell @@ -445,11 +451,13 @@ spec: type: Recreate ``` - + 修补你的 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 ``` + 检查 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)。