Switch language name 'zh' to 'zh-cn'
This is the first step to rename 'zh' to 'zh-cn'. There are several reasons why we rename the language name.
- The upstream docsy theme changed the language name, leading to many warnings during site build;
The side-effect is that the i18n strings are no longer working.
- We believe renaming the language is the right thing to do, because this move can make room for other variants of Chinese language, such as 'zh-tw', 'zh-sg' etc.
There would be several follow-ups to this PR, such as fixing the intra-site links, adding redirects etc.
We will lock up changes to zh/zh-cn pages for the moment, until this one gets in.
This PR is based on commit cdad0a7342.
This commit is contained in:
Qiming Teng
@@ -0,0 +1,5 @@
|
||||
---
|
||||
title: "管理 Kubernetes 对象"
|
||||
weight: 25
|
||||
description: 用声明式和命令式范型与 Kubernetes API 交互。
|
||||
---
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,295 @@
|
||||
---
|
||||
title: 使用指令式命令管理 Kubernetes 对象
|
||||
content_type: task
|
||||
weight: 30
|
||||
---
|
||||
<!--
|
||||
title: Managing Kubernetes Objects Using Imperative Commands
|
||||
content_type: task
|
||||
weight: 30
|
||||
-->
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
Kubernetes objects can quickly be created, updated, and deleted directly using
|
||||
imperative commands built into the `kubectl` command-line tool. This document
|
||||
explains how those commands are organized and how to use them to manage live objects.
|
||||
-->
|
||||
使用构建在 `kubectl` 命令行工具中的指令式命令可以直接快速创建、更新和删除
|
||||
Kubernetes 对象。本文档解释这些命令的组织方式以及如何使用它们来管理现时对象。
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
<!--
|
||||
Install [`kubectl`](/docs/tasks/tools/).
|
||||
-->
|
||||
安装[`kubectl`](/zh/docs/tasks/tools/)。
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
<!--
|
||||
## Trade-offs
|
||||
|
||||
The `kubectl` tool supports three kinds of object management:
|
||||
|
||||
* Imperative commands
|
||||
* Imperative object configuration
|
||||
* Declarative object configuration
|
||||
|
||||
See [Kubernetes Object Management](/docs/concepts/overview/working-with-objects/object-management/)
|
||||
for a discussion of the advantages and disadvantage of each kind of object management.
|
||||
-->
|
||||
## 权衡取舍 {#trade-offs}
|
||||
|
||||
`kubectl` 工具能够支持三种对象管理方式：
|
||||
|
||||
* 指令式命令
|
||||
* 指令式对象配置
|
||||
* 声明式对象配置
|
||||
|
||||
关于每种对象管理的优缺点的讨论，可参见
|
||||
[Kubernetes 对象管理](/zh/docs/concepts/overview/working-with-objects/object-management/)。
|
||||
|
||||
<!--
|
||||
## How to create objects
|
||||
|
||||
The `kubectl` tool supports verb-driven commands for creating some of the most common
|
||||
object types. The commands are named to be recognizable to users unfamiliar with
|
||||
the Kubernetes object types.
|
||||
|
||||
- `run`: Create a new Pod to run a Container.
|
||||
- `expose`: Create a new Service object to load balance traffic across Pods.
|
||||
- `autoscale`: Create a new Autoscaler object to automatically horizontally scale a controller, such as a Deployment.
|
||||
-->
|
||||
## 如何创建对象 {#how-to-create-objects}
|
||||
|
||||
`kubectl` 工具支持动词驱动的命令，用来创建一些最常见的对象类别。
|
||||
命令的名称设计使得不熟悉 Kubernetes 对象类型的用户也能做出判断。
|
||||
|
||||
- `run`：创建一个新的 Pod 来运行一个容器。
|
||||
- `expose`：创建一个新的 Service 对象为若干 Pod 提供流量负载均衡。
|
||||
- `autoscale`：创建一个新的 Autoscaler 对象来自动对某控制器（如 Deployment）
|
||||
执行水平扩缩。
|
||||
|
||||
<!--
|
||||
The `kubectl` tool also supports creation commands driven by object type.
|
||||
These commands support more object types and are more explicit about
|
||||
their intent, but require users to know the type of objects they intend
|
||||
to create.
|
||||
|
||||
- `create <objecttype> [<subtype>] <instancename>`
|
||||
-->
|
||||
`kubectl` 命令也支持一些对象类型驱动的创建命令。
|
||||
这些命令可以支持更多的对象类别，并且在其动机上体现得更为明显，不过要求
|
||||
用户了解它们所要创建的对象的类别。
|
||||
|
||||
- `create <对象类别> [<子类别>] <实例名称>`
|
||||
|
||||
<!--
|
||||
Some objects types have subtypes that you can specify in the `create` command.
|
||||
For example, the Service object has several subtypes including ClusterIP,
|
||||
LoadBalancer, and NodePort. Here's an example that creates a Service with
|
||||
subtype NodePort:
|
||||
|
||||
```shell
|
||||
kubectl create service nodeport <myservicename>
|
||||
```
|
||||
-->
|
||||
某些对象类别拥有自己的子类别，可以在 `create` 命令中设置。
|
||||
例如，Service 对象有 ClusterIP、LoadBalancer 和 NodePort 三种子类别。
|
||||
下面是一个创建 NodePort 子类别的 Service 的示例：
|
||||
|
||||
```shell
|
||||
kubectl create service nodeport <服务名称>
|
||||
```
|
||||
|
||||
<!--
|
||||
In the preceding example, the `create service nodeport` command is called
|
||||
a subcommand of the `create service` command.
|
||||
|
||||
You can use the `-h` flag to find the arguments and flags supported by
|
||||
a subcommand:
|
||||
-->
|
||||
在前述示例中，`create service nodeport` 命令也称作 `create service`
|
||||
命令的子命令。
|
||||
可以使用 `-h` 标志找到一个子命令所支持的参数和标志。
|
||||
|
||||
```shell
|
||||
kubectl create service nodeport -h
|
||||
```
|
||||
|
||||
<!--
|
||||
## How to update objects
|
||||
|
||||
The `kubectl` command supports verb-driven commands for some common update operations.
|
||||
These commands are named to enable users unfamiliar with Kubernetes
|
||||
objects to perform updates without knowing the specific fields
|
||||
that must be set:
|
||||
|
||||
- `scale`: Horizontally scale a controller to add or remove Pods by updating the replica count of the controller.
|
||||
- `annotate`: Add or remove an annotation from an object.
|
||||
- `label`: Add or remove a label from an object.
|
||||
-->
|
||||
## 如何更新对象 {#how-to-update-objects}
|
||||
|
||||
`kubectl` 命令也支持一些动词驱动的命令，用来执行一些常见的更新操作。
|
||||
这些命令的设计是为了让一些不了解 Kubernetes 对象的用户也能执行更新操作，
|
||||
但不需要了解哪些字段必须设置：
|
||||
|
||||
- `scale`：对某控制器进行水平扩缩以便通过更新控制器的副本个数来添加或删除 Pod。
|
||||
- `annotate`：为对象添加或删除注解。
|
||||
- `label`：为对象添加或删除标签。
|
||||
|
||||
<!--
|
||||
The `kubectl` command also supports update commands driven by an aspect of the object.
|
||||
Setting this aspect may set different fields for different object types:
|
||||
|
||||
- `set` `<field>`: Set an aspect of an object.
|
||||
-->
|
||||
`kubectl` 命令也支持由对象的某一方面来驱动的更新命令。
|
||||
设置对象的这一方面可能对不同类别的对象意味着不同的字段：
|
||||
|
||||
- `set <字段>`：设置对象的某一方面。
|
||||
|
||||
<!--
|
||||
In Kubernetes version 1.5, not every verb-driven command has an associated aspect-driven command.
|
||||
-->
|
||||
{{< note >}}
|
||||
在 Kubernetes 1.5 版本中，并非所有动词驱动的命令都有对应的方面驱动的命令。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
The `kubectl` tool supports these additional ways to update a live object directly,
|
||||
however they require a better understanding of the Kubernetes object schema.
|
||||
|
||||
- `edit`: Directly edit the raw configuration of a live object by opening its configuration in an editor.
|
||||
- `patch`: Directly modify specific fields of a live object by using a patch string.
|
||||
For more details on patch strings, see the patch section in
|
||||
[API Conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#patch-operations).
|
||||
-->
|
||||
`kubectl` 工具支持以下额外的方式用来直接更新现时对象，不过这些操作要求
|
||||
用户对 Kubernetes 对象的模式定义有很好的了解：
|
||||
|
||||
- `edit`：通过在编辑器中打开现时对象的配置，直接编辑其原始配置。
|
||||
- `patch`：通过使用补丁字符串（Patch String）直接更改某现时对象的的特定字段。
|
||||
关于补丁字符串的更详细信息，参见
|
||||
[API 约定](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#patch-operations)
|
||||
的 patch 节。
|
||||
|
||||
<!--
|
||||
## How to delete objects
|
||||
|
||||
You can use the `delete` command to delete an object from a cluster:
|
||||
|
||||
- `delete <type>/<name>`
|
||||
-->
|
||||
## 如何删除对象 {#how-to-delete-objects}
|
||||
|
||||
你可以使用 `delete` 命令从集群中删除一个对象：
|
||||
|
||||
- `delete <类别>/<名称>`
|
||||
|
||||
<!--
|
||||
You can use `kubectl delete` for both imperative commands and imperative object
|
||||
configuration. The difference is in the arguments passed to the command. To use
|
||||
`kubectl delete` as an imperative command, pass the object to be deleted as
|
||||
an argument. Here's an example that passes a Deployment object named nginx:
|
||||
-->
|
||||
你可以使用 `kubectl delete` 来执行指令式命令或者指令式对象配置。不同之处在于
|
||||
传递给命令的参数。要将 `kubectl delete` 作为指令式命令使用，将要删除的对象作为
|
||||
参数传递给它。下面是一个删除名为 `nginx` 的 Deployment 对象的命令：
|
||||
|
||||
```shell
|
||||
kubectl delete deployment/nginx
|
||||
```
|
||||
|
||||
<!--
|
||||
## How to view an object
|
||||
|
||||
{{< comment >}}
|
||||
TODO(pwittrock): Uncomment this when implemented.
|
||||
|
||||
You can use `kubectl view` to print specific fields of an object.
|
||||
|
||||
- `view`: Prints the value of a specific field of an object.
|
||||
|
||||
{{< /comment >}}
|
||||
-->
|
||||
## 如何查看对象 {#how-to-view-an-object}
|
||||
|
||||
用来打印对象信息的命令有好几个：
|
||||
|
||||
- `get`：打印匹配到的对象的基本信息。使用 `get -h` 可以查看选项列表。
|
||||
- `describe`：打印匹配到的对象的详细信息的汇集版本。
|
||||
- `logs`：打印 Pod 中运行的容器的 stdout 和 stderr 输出。
|
||||
|
||||
<!--
|
||||
## Using `set` commands to modify objects before creation
|
||||
|
||||
There are some object fields that don't have a flag you can use
|
||||
in a `create` command. In some of those cases, you can use a combination of
|
||||
`set` and `create` to specify a value for the field before object
|
||||
creation. This is done by piping the output of the `create` command to the
|
||||
`set` command, and then back to the `create` command. Here's an example:
|
||||
-->
|
||||
## 使用 `set` 命令在创建对象之前修改对象
|
||||
|
||||
有些对象字段在 `create` 命令中没有对应的标志。在这些场景中，
|
||||
你可以使用 `set` 和 `create` 命令的组合来在对象创建之前设置字段值。
|
||||
这是通过将 `create` 命令的输出用管道方式传递给 `set` 命令来实现的，
|
||||
最后执行 `create` 命令来创建对象。下面是一个例子：
|
||||
|
||||
```sh
|
||||
kubectl create service clusterip my-svc --clusterip="None" -o yaml --dry-run=client | kubectl set selector --local -f - 'environment=qa' -o yaml | kubectl create -f -
|
||||
```
|
||||
|
||||
<!--
|
||||
1. The `kubectl create service -o yaml --dry-run=client` command creates the configuration for the Service, but prints it to stdout as YAML instead of sending it to the Kubernetes API server.
|
||||
1. The `kubectl set selector --local -f - -o yaml` command reads the configuration from stdin, and writes the updated configuration to stdout as YAML.
|
||||
1. The `kubectl create -f -` command creates the object using the configuration provided via stdin.
|
||||
-->
|
||||
1. 命令 `kubectl create service -o yaml --dry-run=client` 创建 Service 的配置，但
|
||||
将其以 YAML 格式在标准输出上打印而不是发送给 API 服务器。
|
||||
1. 命令 `kubectl set selector --local -f - -o yaml` 从标准输入读入配置，并将更新后的
|
||||
配置以 YAML 格式输出到标准输出。
|
||||
1. 命令 `kubectl create -f -` 使用标准输入上获得的配置创建对象。
|
||||
|
||||
<!--
|
||||
## Using `--edit` to modify objects before creation
|
||||
|
||||
You can use `kubectl create --edit` to make arbitrary changes to an object
|
||||
before it is created. Here's an example:
|
||||
-->
|
||||
## 在创建之前使用 `--edit` 更改对象
|
||||
|
||||
你可以用 `kubectl create --edit` 来在对象被创建之前执行任意的变更。
|
||||
下面是一个例子：
|
||||
|
||||
```sh
|
||||
kubectl create service clusterip my-svc --clusterip="None" -o yaml --dry-run=client > /tmp/srv.yaml
|
||||
kubectl create --edit -f /tmp/srv.yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
1. The `kubectl create service` command creates the configuration for the Service and saves it to `/tmp/srv.yaml`.
|
||||
1. The `kubectl create --edit` command opens the configuration file for editing before it creates the object.
|
||||
-->
|
||||
1. 命令 `kubectl create service` 创建 Service 的配置并将其保存到
|
||||
`/tmp/srv.yaml` 文件。
|
||||
1. 命令 `kubectl create --edit` 在创建 Service 对象打开其配置文件进行编辑。
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
<!--
|
||||
* [Managing Kubernetes Objects Using Object Configuration (Imperative)](/docs/tasks/manage-kubernetes-objects/imperative-config/)
|
||||
* [Managing Kubernetes Objects Using Object Configuration (Declarative)](/docs/tasks/manage-kubernetes-objects/declarative-config/)
|
||||
* [Kubectl Command Reference](/docs/reference/generated/kubectl/kubectl-commands/)
|
||||
* [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
|
||||
-->
|
||||
* [使用指令式对象配置管理 Kubernetes 对象](/zh/docs/tasks/manage-kubernetes-objects/imperative-config/)
|
||||
* [使用声明式对象配置管理 Kubernetes 对象](/zh/docs/tasks/manage-kubernetes-objects/declarative-config/)
|
||||
* [Kubectl 命令参考](/docs/reference/generated/kubectl/kubectl-commands/)
|
||||
* [Kubernetes API 参考](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
|
||||
|
||||
@@ -0,0 +1,281 @@
|
||||
---
|
||||
title: 使用配置文件对 Kubernetes 对象进行命令式管理
|
||||
content_type: task
|
||||
weight: 40
|
||||
---
|
||||
<!--
|
||||
title: Imperative Management of Kubernetes Objects Using Configuration Files
|
||||
content_type: task
|
||||
weight: 40
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
<!--
|
||||
Kubernetes objects can be created, updated, and deleted by using the `kubectl`
|
||||
command-line tool along with an object configuration file written in YAML or JSON.
|
||||
This document explains how to define and manage objects using configuration files.
|
||||
-->
|
||||
可以使用 `kubectl` 命令行工具以及用 YAML 或 JSON 编写的对象配置文件来创建、更新和删除 Kubernetes 对象。
|
||||
本文档说明了如何使用配置文件定义和管理对象。
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
<!--
|
||||
Install [`kubectl`](/docs/tasks/tools/).
|
||||
-->
|
||||
安装 [`kubectl`](/zh/docs/tasks/tools/) 。
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
<!--
|
||||
## Trade-offs
|
||||
|
||||
The `kubectl` tool supports three kinds of object management:
|
||||
-->
|
||||
## 权衡
|
||||
|
||||
`kubectl` 工具支持三种对象管理：
|
||||
|
||||
<!--
|
||||
* Imperative commands
|
||||
* Imperative object configuration
|
||||
* Declarative object configuration
|
||||
-->
|
||||
* 命令式命令
|
||||
* 命令式对象配置
|
||||
* 声明式对象配置
|
||||
|
||||
<!--
|
||||
See [Kubernetes Object Management](/docs/concepts/overview/working-with-objects/object-management/)
|
||||
for a discussion of the advantages and disadvantage of each kind of object management.
|
||||
-->
|
||||
参看 [Kubernetes 对象管理](/zh/docs/concepts/overview/working-with-objects/object-management/)
|
||||
中关于每种对象管理的优缺点的讨论。
|
||||
|
||||
<!--
|
||||
## How to create objects
|
||||
|
||||
You can use `kubectl create -f` to create an object from a configuration file.
|
||||
Refer to the [kubernetes API reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
|
||||
for details.
|
||||
-->
|
||||
## 如何创建对象
|
||||
|
||||
你可以使用 `kubectl create -f` 从配置文件创建一个对象。
|
||||
请参考 [kubernetes API 参考](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) 有关详细信息。
|
||||
|
||||
* `kubectl create -f <filename|url>`
|
||||
|
||||
<!--
|
||||
## How to update objects
|
||||
|
||||
Updating objects with the `replace` command drops all
|
||||
parts of the spec not specified in the configuration file. This
|
||||
should not be used with objects whose specs are partially managed
|
||||
by the cluster, such as Services of type `LoadBalancer`, where
|
||||
the `externalIPs` field is managed independently from the configuration
|
||||
file. Independently managed fields must be copied to the configuration
|
||||
file to prevent `replace` from dropping them.
|
||||
-->
|
||||
## 如何更新对象
|
||||
|
||||
{{< warning >}}
|
||||
使用 `replace` 命令更新对象会删除所有未在配置文件中指定的规范的某些部分。
|
||||
不应将其规范由集群部分管理的对象使用，比如类型为 `LoadBalancer` 的服务，
|
||||
其中 `externalIPs` 字段独立于配置文件进行管理。
|
||||
必须将独立管理的字段复制到配置文件中，以防止 `replace` 删除它们。
|
||||
{{< /warning >}}
|
||||
|
||||
<!--
|
||||
You can use `kubectl replace -f` to update a live object according to a
|
||||
configuration file.
|
||||
-->
|
||||
你可以使用 `kubectl replace -f` 根据配置文件更新活动对象。
|
||||
|
||||
* `kubectl replace -f <filename|url>`
|
||||
|
||||
<!--
|
||||
## How to delete objects
|
||||
|
||||
You can use `kubectl delete -f` to delete an object that is described in a
|
||||
configuration file.
|
||||
-->
|
||||
## 如何删除对象
|
||||
|
||||
你可以使用 `kubectl delete -f` 删除配置文件中描述的对象。
|
||||
|
||||
* `kubectl delete -f <filename|url>`
|
||||
|
||||
<!-- note
|
||||
If configuration file has specified the `generateName` field in the `metadata`
|
||||
section instead of the `name` field, you cannot delete the object using
|
||||
`kubectl delete -f <filename|url>`.
|
||||
You will have to use other flags for deleting the object. For example:
|
||||
|
||||
```shell
|
||||
kubectl delete <type> <name>
|
||||
kubectl delete <type> -l <label>
|
||||
```
|
||||
-->
|
||||
{{< note >}}
|
||||
如果配置文件在 `metadata` 节中设置了 `generateName` 字段而非 `name` 字段，
|
||||
你无法使用 `kubectl delete -f <filename|url>` 来删除该对象。
|
||||
你必须使用其他标志才能删除对象。例如：
|
||||
|
||||
```shell
|
||||
kubectl delete <type> <name>
|
||||
kubectl delete <type> -l <label>
|
||||
```
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
## How to view an object
|
||||
|
||||
You can use `kubectl get -f` to view information about an object that is
|
||||
described in a configuration file.
|
||||
-->
|
||||
## 如何查看对象
|
||||
|
||||
你可以使用 `kubectl get -f` 查看有关配置文件中描述的对象的信息。
|
||||
|
||||
* `kubectl get -f <filename|url> -o yaml`
|
||||
|
||||
<!--
|
||||
The `-o yaml` flag specifies that the full object configuration is printed.
|
||||
Use `kubectl get -h` to see a list of options.
|
||||
-->
|
||||
`-o yaml` 标志指定打印完整的对象配置。
|
||||
使用 `kubectl get -h` 查看选项列表。
|
||||
|
||||
<!--
|
||||
## Limitations
|
||||
|
||||
The `create`, `replace`, and `delete` commands work well when each object's
|
||||
configuration is fully defined and recorded in its configuration
|
||||
file. However when a live object is updated, and the updates are not merged
|
||||
into its configuration file, the updates will be lost the next time a `replace`
|
||||
is executed. This can happen if a controller, such as
|
||||
a HorizontalPodAutoscaler, makes updates directly to a live object. Here's
|
||||
an example:
|
||||
-->
|
||||
## 局限性
|
||||
|
||||
当完全定义每个对象的配置并将其记录在其配置文件中时，`create`、 `replace` 和`delete` 命令会很好的工作。
|
||||
但是，当更新一个活动对象，并且更新没有合并到其配置文件中时，下一次执行 `replace` 时，更新将丢失。
|
||||
如果控制器,例如 HorizontalPodAutoscaler ,直接对活动对象进行更新，则会发生这种情况。
|
||||
这有一个例子：
|
||||
|
||||
<!--
|
||||
1. You create an object from a configuration file.
|
||||
1. Another source updates the object by changing some field.
|
||||
1. You replace the object from the configuration file. Changes made by
|
||||
the other source in step 2 are lost.
|
||||
-->
|
||||
1. 从配置文件创建一个对象。
|
||||
1. 另一个源通过更改某些字段来更新对象。
|
||||
1. 从配置文件中替换对象。在步骤2中所做的其他源的更改将丢失。
|
||||
|
||||
<!--
|
||||
If you need to support multiple writers to the same object, you can use
|
||||
`kubectl apply` to manage the object.
|
||||
-->
|
||||
如果需要支持同一对象的多个编写器，则可以使用 `kubectl apply` 来管理该对象。
|
||||
|
||||
<!--
|
||||
## Creating and editing an object from a URL without saving the configuration
|
||||
|
||||
Suppose you have the URL of an object configuration file. You can use
|
||||
`kubectl create --edit` to make changes to the configuration before the
|
||||
object is created. This is particularly useful for tutorials and tasks
|
||||
that point to a configuration file that could be modified by the reader.
|
||||
-->
|
||||
## 从 URL 创建和编辑对象而不保存配置
|
||||
|
||||
假设你具有对象配置文件的 URL。
|
||||
你可以在创建对象之前使用 `kubectl create --edit` 对配置进行更改。
|
||||
这对于指向可以由读者修改的配置文件的教程和任务特别有用。
|
||||
|
||||
```shell
|
||||
kubectl create -f <url> --edit
|
||||
```
|
||||
|
||||
<!--
|
||||
## Migrating from imperative commands to imperative object configuration
|
||||
|
||||
Migrating from imperative commands to imperative object configuration involves
|
||||
several manual steps.
|
||||
-->
|
||||
## 从命令式命令迁移到命令式对象配置
|
||||
|
||||
从命令式命令迁移到命令式对象配置涉及几个手动步骤。
|
||||
|
||||
<!--
|
||||
1. Export the live object to a local object configuration file:
|
||||
-->
|
||||
1. 将活动对象导出到本地对象配置文件：
|
||||
|
||||
```shell
|
||||
kubectl get <kind>/<name> -o yaml > <kind>_<name>.yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
1. Manually remove the status field from the object configuration file.
|
||||
-->
|
||||
2. 从对象配置文件中手动删除状态字段。
|
||||
|
||||
<!--
|
||||
1. For subsequent object management, use `replace` exclusively.
|
||||
-->
|
||||
3. 对于后续的对象管理，只能使用 `replace` 。
|
||||
|
||||
```shell
|
||||
kubectl replace -f <kind>_<name>.yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
## Defining controller selectors and PodTemplate labels
|
||||
-->
|
||||
## 定义控制器选择器和 PodTemplate 标签
|
||||
|
||||
<!--
|
||||
Updating selectors on controllers is strongly discouraged.
|
||||
-->
|
||||
{{< warning >}}
|
||||
不建议在控制器上更新选择器。
|
||||
{{< /warning >}}
|
||||
|
||||
<!--
|
||||
The recommended approach is to define a single, immutable PodTemplate label
|
||||
used only by the controller selector with no other semantic meaning.
|
||||
-->
|
||||
推荐的方法是定义单个不变的 PodTemplate 标签，该标签仅由控制器选择器使用，而没有其他语义。
|
||||
|
||||
<!-- Example label: -->
|
||||
标签示例：
|
||||
|
||||
```yaml
|
||||
selector:
|
||||
matchLabels:
|
||||
controller-selector: "apps/v1/deployment/nginx"
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
controller-selector: "apps/v1/deployment/nginx"
|
||||
```
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
<!--
|
||||
* [Managing Kubernetes Objects Using Imperative Commands](/docs/tasks/manage-kubernetes-objects/imperative-command/)
|
||||
* [Managing Kubernetes Objects Using Object Configuration (Declarative)](/docs/tasks/manage-kubernetes-objects/declarative-config/)
|
||||
* [Kubectl Command Reference](/docs/reference/generated/kubectl/kubectl/)
|
||||
* [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
|
||||
-->
|
||||
* [使用命令式命令管理 Kubernetes 对象](/zh/docs/tasks/manage-kubernetes-objects/imperative-command/)
|
||||
* [使用对象配置管理 Kubernetes 对象 (声明式)](/zh/docs/tasks/manage-kubernetes-objects/declarative-config/)
|
||||
* [Kubectl 命令参考](/docs/reference/generated/kubectl/kubectl-commands/)
|
||||
* [Kubernetes API 参考](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
|
||||
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
+680
@@ -0,0 +1,680 @@
|
||||
---
|
||||
title: 使用 kubectl patch 更新 API 对象
|
||||
description: 使用 kubectl patch 更新 Kubernetes API 对象。做一个策略性的合并 patch 或 JSON 合并 patch。
|
||||
content_type: task
|
||||
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: 50
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
This task shows how to use `kubectl patch` to update an API object in place. The exercises
|
||||
in this task demonstrate a strategic merge patch and a JSON merge patch.
|
||||
-->
|
||||
这个任务展示如何使用 `kubectl patch` 就地更新 API 对象。
|
||||
这个任务中的练习演示了一个策略性合并 patch 和一个 JSON 合并 patch。
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
<!--
|
||||
## Use a strategic merge patch to update a Deployment
|
||||
|
||||
Here's the configuration file for a Deployment that has two replicas. Each replica
|
||||
is a Pod that has one container:
|
||||
-->
|
||||
## 使用策略合并 patch 更新 Deployment {#use-a-strategic-merge-patch-to-update-a-deployment}
|
||||
|
||||
下面是具有两个副本的 Deployment 的配置文件。每个副本是一个 Pod，有一个容器：
|
||||
|
||||
{{< codenew file="application/deployment-patch.yaml" >}}
|
||||
|
||||
<!--
|
||||
Create the Deployment:
|
||||
-->
|
||||
创建 Deployment：
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/application/deployment-patch.yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
View the Pods associated with your Deployment:
|
||||
-->
|
||||
查看与 Deployment 相关的 Pod：
|
||||
|
||||
```shell
|
||||
kubectl get pods
|
||||
```
|
||||
|
||||
<!--
|
||||
The output shows that the Deployment has two Pods. The `1/1` indicates that
|
||||
each Pod has one container:
|
||||
-->
|
||||
输出显示 Deployment 有两个 Pod。`1/1` 表示每个 Pod 有一个容器:
|
||||
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
patch-demo-28633765-670qr 1/1 Running 0 23s
|
||||
patch-demo-28633765-j5qs3 1/1 Running 0 23s
|
||||
```
|
||||
|
||||
<!--
|
||||
Make a note of the names of the running Pods. Later, you will see that these Pods
|
||||
get terminated and replaced by new ones.
|
||||
-->
|
||||
把运行的 Pod 的名字记下来。稍后，你将看到这些 Pod 被终止并被新的 Pod 替换。
|
||||
|
||||
<!--
|
||||
At this point, each Pod has one Container that runs the nginx image. Now suppose
|
||||
you want each Pod to have two containers: one that runs nginx and one that runs redis.
|
||||
-->
|
||||
此时，每个 Pod 都有一个运行 nginx 镜像的容器。现在假设你希望每个 Pod 有两个容器：一个运行 nginx，另一个运行 redis。
|
||||
|
||||
<!--
|
||||
Create a file named `patch-file.yaml` that has this content:
|
||||
-->
|
||||
创建一个名为 `patch-file.yaml` 的文件。内容如下:
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
template:
|
||||
spec:
|
||||
containers:
|
||||
- name: patch-demo-ctr-2
|
||||
image: redis
|
||||
```
|
||||
|
||||
<!--
|
||||
Patch your Deployment:
|
||||
-->
|
||||
修补你的 Deployment：
|
||||
|
||||
```shell
|
||||
kubectl patch deployment patch-demo --patch-file patch-file.yaml
|
||||
```
|
||||
<!--
|
||||
View the patched Deployment:
|
||||
-->
|
||||
查看修补后的 Deployment：
|
||||
|
||||
```shell
|
||||
kubectl get deployment patch-demo --output yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
The output shows that the PodSpec in the Deployment has two Containers:
|
||||
-->
|
||||
输出显示 Deployment 中的 PodSpec 有两个容器:
|
||||
|
||||
```yaml
|
||||
containers:
|
||||
- image: redis
|
||||
imagePullPolicy: Always
|
||||
name: patch-demo-ctr-2
|
||||
...
|
||||
- image: nginx
|
||||
imagePullPolicy: Always
|
||||
name: patch-demo-ctr
|
||||
...
|
||||
```
|
||||
|
||||
<!--
|
||||
View the Pods associated with your patched Deployment:
|
||||
-->
|
||||
查看与 patch Deployment 相关的 Pod:
|
||||
|
||||
```shell
|
||||
kubectl get pods
|
||||
```
|
||||
|
||||
<!--
|
||||
The output shows that the running Pods have different names from the Pods that
|
||||
were running previously. The Deployment terminated the old Pods and created two
|
||||
new Pods that comply with the updated Deployment spec. The `2/2` indicates that
|
||||
each Pod has two Containers:
|
||||
-->
|
||||
输出显示正在运行的 Pod 与以前运行的 Pod 有不同的名称。Deployment 终止了旧的 Pod，并创建了两个
|
||||
符合更新的部署规范的新 Pod。`2/2` 表示每个 Pod 有两个容器:
|
||||
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
patch-demo-1081991389-2wrn5 2/2 Running 0 1m
|
||||
patch-demo-1081991389-jmg7b 2/2 Running 0 1m
|
||||
```
|
||||
|
||||
<!--
|
||||
Take a closer look at one of the patch-demo Pods:
|
||||
-->
|
||||
仔细查看其中一个 patch-demo Pod:
|
||||
|
||||
```shell
|
||||
kubectl get pod <your-pod-name> --output yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
The output shows that the Pod has two Containers: one running nginx and one running redis:
|
||||
-->
|
||||
输出显示 Pod 有两个容器:一个运行 nginx，一个运行 redis:
|
||||
|
||||
```
|
||||
containers:
|
||||
- image: redis
|
||||
...
|
||||
- image: nginx
|
||||
...
|
||||
```
|
||||
|
||||
<!--
|
||||
### Notes on the strategic merge patch
|
||||
|
||||
The patch you did in the preceding exercise is called a *strategic merge patch*.
|
||||
Notice that the patch did not replace the `containers` list. Instead it added a new
|
||||
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 的说明 {#notes-on-the-strategic-merge-patch}
|
||||
|
||||
你在前面的练习中所做的 patch 称为 `策略性合并 patch（Strategic Merge Patch）`。
|
||||
请注意，patch 没有替换 `containers` 列表。相反，它向列表中添加了一个新 Container。换句话说，
|
||||
patch 中的列表与现有列表合并。当你在列表中使用策略性合并 patch 时，并不总是这样。
|
||||
在某些情况下，列表是替换的，而不是合并的。
|
||||
|
||||
<!--
|
||||
With a strategic merge patch, a list is either replaced or merged depending on its
|
||||
patch strategy. The patch strategy is specified by the value of the `patchStrategy` key
|
||||
in a field tag in the Kubernetes source code. For example, the `Containers` field of `PodSpec`
|
||||
struct has a `patchStrategy` of `merge`:
|
||||
-->
|
||||
对于策略性合并 patch，列表可以根据其 patch 策略进行替换或合并。
|
||||
patch 策略由 Kubernetes 源代码中字段标记中的 `patchStrategy` 键的值指定。
|
||||
例如，`PodSpec` 结构体的 `Containers` 字段的 `patchStrategy` 为 `merge`：
|
||||
|
||||
```go
|
||||
type PodSpec struct {
|
||||
...
|
||||
Containers []Container `json:"containers" patchStrategy:"merge" patchMergeKey:"name" ...`
|
||||
```
|
||||
|
||||
<!--
|
||||
You can also see the patch strategy in the
|
||||
[OpenApi spec](https://raw.githubusercontent.com/kubernetes/kubernetes/master/api/openapi-spec/swagger.json):
|
||||
-->
|
||||
你还可以在 [OpenApi spec](https://raw.githubusercontent.com/kubernetes/kubernetes/master/api/openapi-spec/swagger.json)
|
||||
规范中看到 patch 策略：
|
||||
|
||||
```json
|
||||
"io.k8s.api.core.v1.PodSpec": {
|
||||
...
|
||||
"containers": {
|
||||
"description": "List of containers belonging to the pod. ...
|
||||
},
|
||||
"x-kubernetes-patch-merge-key": "name",
|
||||
"x-kubernetes-patch-strategy": "merge"
|
||||
},
|
||||
```
|
||||
|
||||
<!--
|
||||
And you can see the patch strategy in the
|
||||
[Kubernetes API documentation](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core).
|
||||
-->
|
||||
你可以在 [Kubernetes API 文档](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)
|
||||
中看到 patch 策略。
|
||||
|
||||
<!--
|
||||
Create a file named `patch-file-tolerations.yaml` that has this content:
|
||||
-->
|
||||
创建一个名为 `patch-file-tolerations.yaml` 的文件。内容如下:
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
template:
|
||||
spec:
|
||||
tolerations:
|
||||
- effect: NoSchedule
|
||||
key: disktype
|
||||
value: ssd
|
||||
```
|
||||
|
||||
<!--
|
||||
Patch your Deployment:
|
||||
-->
|
||||
对 Deployment 执行 patch 操作：
|
||||
|
||||
```
|
||||
kubectl patch deployment patch-demo --patch-file patch-file-tolerations.yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
View the patched Deployment:
|
||||
-->
|
||||
查看修补后的 Deployment：
|
||||
|
||||
```shell
|
||||
kubectl get deployment patch-demo --output yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
The output shows that the PodSpec in the Deployment has only one Toleration:
|
||||
-->
|
||||
输出结果显示 Deployment 中的 PodSpec 只有一个容忍度设置：
|
||||
|
||||
```shell
|
||||
|
||||
containers:
|
||||
- image: redis
|
||||
imagePullPolicy: Always
|
||||
name: patch-demo-ctr-2
|
||||
...
|
||||
- image: nginx
|
||||
imagePullPolicy: Always
|
||||
name: patch-demo-ctr
|
||||
...
|
||||
```
|
||||
```yaml
|
||||
tolerations:
|
||||
- effect: NoSchedule
|
||||
key: disktype
|
||||
value: ssd
|
||||
```
|
||||
|
||||
<!--
|
||||
Notice that the `tolerations` list in the PodSpec was replaced, not merged. This is because
|
||||
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`
|
||||
的字段标签中没有 `patchStrategy` 键。所以策略合并 patch 操作使用默认的 patch 策略，也就是 `replace`。
|
||||
|
||||
```go
|
||||
type PodSpec struct {
|
||||
...
|
||||
Tolerations []Toleration `json:"tolerations,omitempty" protobuf:"bytes,22,opt,name=tolerations"`
|
||||
```
|
||||
|
||||
<!--
|
||||
## Use a JSON merge patch to update a Deployment
|
||||
|
||||
A strategic merge patch is different from a
|
||||
[JSON merge patch](https://tools.ietf.org/html/rfc7386).
|
||||
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 {#use-a-json-merge-patch-to-update-a-deployment}
|
||||
|
||||
策略性合并 patch 不同于 [JSON 合并 patch](https://tools.ietf.org/html/rfc7386)。
|
||||
使用 JSON 合并 patch，如果你想更新列表，你必须指定整个新列表。新的列表完全取代现有的列表。
|
||||
|
||||
<!--
|
||||
The `kubectl patch` command has a `type` parameter that you can set to one of these values:
|
||||
-->
|
||||
`kubectl patch` 命令有一个 `type` 参数，你可以将其设置为以下值之一:
|
||||
|
||||
<table>
|
||||
<!--
|
||||
<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>策略合并 patch</td></tr>
|
||||
</table>
|
||||
|
||||
<!--
|
||||
For a comparison of JSON patch and JSON merge patch, see
|
||||
[JSON Patch and JSON Merge Patch](https://erosb.github.io/post/json-patch-vs-merge-patch/).
|
||||
-->
|
||||
有关 JSON patch 和 JSON 合并 patch 的比较，查看
|
||||
[JSON patch 和 JSON 合并 patch](https://erosb.github.io/post/json-patch-vs-merge-patch/)。
|
||||
|
||||
<!--
|
||||
The default value for the `type` parameter is `strategic`. So in the preceding exercise, you
|
||||
did a strategic merge patch.
|
||||
-->
|
||||
`type` 参数的默认值是 `strategic`。在前面的练习中，我们做了一个策略性的合并 patch。
|
||||
|
||||
<!--
|
||||
Next, do a JSON merge patch on your same Deployment. Create a file named `patch-file-2.yaml`
|
||||
that has this content:
|
||||
-->
|
||||
下一步，在相同的 Deployment 上执行 JSON 合并 patch。创建一个名为 `patch-file-2` 的文件。内容如下:
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
template:
|
||||
spec:
|
||||
containers:
|
||||
- name: patch-demo-ctr-3
|
||||
image: gcr.io/google-samples/node-hello:1.0
|
||||
```
|
||||
|
||||
<!--
|
||||
In your patch command, set `type` to `merge`:
|
||||
-->
|
||||
在 patch 命令中，将 `type` 设置为 `merge`：
|
||||
|
||||
```shell
|
||||
kubectl patch deployment patch-demo --type merge --patch-file patch-file-2.yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
View the patched Deployment:
|
||||
-->
|
||||
查看修补后的 Deployment：
|
||||
|
||||
```shell
|
||||
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。
|
||||
输出显示你所给出的 Contaier 列表替换了现有的 `containers` 列表。
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
containers:
|
||||
- image: gcr.io/google-samples/node-hello:1.0
|
||||
...
|
||||
name: patch-demo-ctr-3
|
||||
```
|
||||
|
||||
<!--
|
||||
List the running Pods:
|
||||
-->
|
||||
列表中运行的 Pod：
|
||||
|
||||
```shell
|
||||
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 只运行一个容器。
|
||||
|
||||
```shell
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
patch-demo-1307768864-69308 1/1 Running 0 1m
|
||||
patch-demo-1307768864-c86dc 1/1 Running 0 1m
|
||||
```
|
||||
|
||||
<!--
|
||||
## Use strategic merge patch to update a Deployment using the retainKeys strategy
|
||||
|
||||
Here's the configuration file for a Deployment that uses the `RollingUpdate` strategy:
|
||||
-->
|
||||
## 使用带 retainKeys 策略的策略合并 patch 更新 Deployment {#use-strategic-merge-patch-to-update-a-deployment-using-the-retainkeys-strategy}
|
||||
|
||||
{{< codenew file="application/deployment-retainkeys.yaml" >}}
|
||||
|
||||
<!--
|
||||
Create the deployment:
|
||||
-->
|
||||
创建 Deployment：
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/application/deployment-retainkeys.yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
At this point, the deployment is created and is using the `RollingUpdate` strategy.
|
||||
|
||||
Create a file named `patch-file-no-retainkeys.yaml` that has this content:
|
||||
-->
|
||||
这时，Deployment 被创建，并使用 `RollingUpdate` 策略。
|
||||
|
||||
创建一个名为 `patch-file-no-retainkeys.yaml` 的文件，内容如下：
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
strategy:
|
||||
type: Recreate
|
||||
```
|
||||
|
||||
<!--
|
||||
Patch your Deployment:
|
||||
-->
|
||||
修补你的 Deployment:
|
||||
|
||||
```shell
|
||||
kubectl patch deployment retainkeys-demo --type merge --patch-file patch-file-no-retainkeys.yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
In the output, you can see that it is not possible to set `type` as `Recreate` when a value is defined for `spec.strategy.rollingUpdate`:
|
||||
-->
|
||||
在输出中，你可以看到，当 `spec.strategy.rollingUpdate` 已经拥有取值定义时，
|
||||
将其 `type` 设置为 `Recreate` 是不可能的。
|
||||
|
||||
```
|
||||
The Deployment "retainkeys-demo" is invalid: spec.strategy.rollingUpdate: Forbidden: may not be specified when strategy `type` is 'Recreate'
|
||||
```
|
||||
|
||||
<!--
|
||||
The way to remove the value for `spec.strategy.rollingUpdate` when updating the value for `type` is to use the `retainKeys` strategy for the strategic merge.
|
||||
|
||||
Create another file named `patch-file-retainkeys.yaml` that has this content:
|
||||
-->
|
||||
更新 `type` 取值的同时移除 `spec.strategy.rollingUpdate` 现有值的方法是
|
||||
为策略性合并操作设置 `retainKeys` 策略：
|
||||
|
||||
创建另一个名为 `patch-file-retainkeys.yaml` 的文件，内容如下：
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
strategy:
|
||||
$retainKeys:
|
||||
- type
|
||||
type: Recreate
|
||||
```
|
||||
|
||||
<!--
|
||||
With this patch, we indicate that we want to retain only the `type` key of the `strategy` object. Thus, the `rollingUpdate` will be removed during the patch operation.
|
||||
|
||||
Patch your Deployment again with this new patch:
|
||||
-->
|
||||
使用此 patch，我们表达了希望只保留 `strategy` 对象的 `type` 键。
|
||||
这样，在 patch 操作期间 `rollingUpdate` 会被删除。
|
||||
|
||||
使用新的 patch 重新修补 Deployment：
|
||||
|
||||
```shell
|
||||
kubectl patch deployment retainkeys-demo --type merge --patch-file patch-file-retainkeys.yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
Examine the content of the Deployment:
|
||||
-->
|
||||
检查 Deployment 的内容：
|
||||
|
||||
```shell
|
||||
kubectl get deployment retainkeys-demo --output yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
The output shows that the strategy object in the Deployment does not contain the `rollingUpdate` key anymore:
|
||||
-->
|
||||
输出显示 Deployment 中的 `strategy` 对象不再包含 `rollingUpdate` 键：
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
strategy:
|
||||
type: Recreate
|
||||
template:
|
||||
```
|
||||
|
||||
<!--
|
||||
### Notes on the strategic merge patch using the retainKeys strategy
|
||||
|
||||
The patch you did in the preceding exercise is called a *strategic merge patch with retainKeys strategy*. This method introduces a new directive `$retainKeys` that has the following strategies:
|
||||
|
||||
- It contains a list of strings.
|
||||
- All fields needing to be preserved must be present in the `$retainKeys` list.
|
||||
- The fields that are present will be merged with live object.
|
||||
- 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 操作的说明 {#notes-on-the-strategic-merge-patch-using-the-retainkeys-strategy}
|
||||
|
||||
在前文练习中所执行的称作 *带 `retainKeys` 策略的策略合并 patch（Strategic Merge
|
||||
Patch with retainKeys Strategy）*。
|
||||
这种方法引入了一种新的 `$retainKey` 指令，具有如下策略：
|
||||
|
||||
- 其中包含一个字符串列表；
|
||||
- 所有需要被保留的字段必须在 `$retainKeys` 列表中给出；
|
||||
- 对于已有的字段，会和对象上对应的内容合并；
|
||||
- 在修补操作期间，未找到的字段都会被清除；
|
||||
- 列表 `$retainKeys` 中的所有字段必须 patch 操作所给字段的超集，或者与之完全一致。
|
||||
|
||||
<!--
|
||||
The `retainKeys` strategy does not work for all objects. It only works when the value of the `patchStrategy` key in a field tag in the Kubernetes source code contains `retainKeys`. For example, the `Strategy` field of the `DeploymentSpec` struct has a `patchStrategy` of `retainKeys`:
|
||||
-->
|
||||
策略 `retainKeys` 并不能对所有对象都起作用。它仅对那些 Kubernetes 源码中
|
||||
`patchStrategy` 字段标志值包含 `retainKeys` 的字段有用。
|
||||
例如 `DeploymentSpec` 结构的 `Strategy` 字段就包含了 `patchStrategy` 为
|
||||
`retainKeys` 的标志。
|
||||
|
||||
```go
|
||||
type DeploymentSpec struct {
|
||||
...
|
||||
// +patchStrategy=retainKeys
|
||||
Strategy DeploymentStrategy `json:"strategy,omitempty" patchStrategy:"retainKeys" ...`
|
||||
```
|
||||
|
||||
<!--
|
||||
You can also see the `retainKeys` strategy in the [OpenApi spec](https://raw.githubusercontent.com/kubernetes/kubernetes/master/api/openapi-spec/swagger.json):
|
||||
-->
|
||||
你也可以查看 [OpenAPI 规范](https://raw.githubusercontent.com/kubernetes/kubernetes/master/api/openapi-spec/swagger.json)中的 `retainKeys` 策略：
|
||||
|
||||
```json
|
||||
"io.k8s.api.apps.v1.DeploymentSpec": {
|
||||
...
|
||||
"strategy": {
|
||||
"$ref": "#/definitions/io.k8s.api.apps.v1.DeploymentStrategy",
|
||||
"description": "The deployment strategy to use to replace existing pods with new ones.",
|
||||
"x-kubernetes-patch-strategy": "retainKeys"
|
||||
},
|
||||
```
|
||||
|
||||
<!--
|
||||
And you can see the `retainKeys` strategy in the
|
||||
[Kubernetes API documentation](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps).
|
||||
-->
|
||||
而且你也可以在
|
||||
[Kubernetes API 文档](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps).
|
||||
中看到 `retainKey` 策略。
|
||||
|
||||
<!--
|
||||
## Alternate forms of the kubectl patch command
|
||||
|
||||
The `kubectl patch` command takes YAML or JSON. It can take the patch as a file or
|
||||
directly on the command line.
|
||||
-->
|
||||
## kubectl patch 命令的其他形式 {#alternate-forms-of-the-kubectl-patch-command}
|
||||
|
||||
`kubectl patch` 命令使用 YAML 或 JSON。它可以接受以文件形式提供的补丁，也可以
|
||||
接受直接在命令行中给出的补丁。
|
||||
|
||||
<!--
|
||||
Create a file named `patch-file.json` that has this content:
|
||||
-->
|
||||
创建一个文件名称是 `patch-file.json` 内容如下：
|
||||
|
||||
```json
|
||||
{
|
||||
"spec": {
|
||||
"template": {
|
||||
"spec": {
|
||||
"containers": [
|
||||
{
|
||||
"name": "patch-demo-ctr-2",
|
||||
"image": "redis"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
<!--
|
||||
The following commands are equivalent:
|
||||
-->
|
||||
以下命令是等价的：
|
||||
|
||||
```shell
|
||||
kubectl patch deployment patch-demo --patch-file patch-file.yaml
|
||||
kubectl patch deployment patch-demo --patch 'spec:\n template:\n spec:\n containers:\n - name: patch-demo-ctr-2\n image: redis'
|
||||
|
||||
kubectl patch deployment patch-demo --patch-file patch-file.json
|
||||
kubectl patch deployment patch-demo --patch '{"spec": {"template": {"spec": {"containers": [{"name": "patch-demo-ctr-2","image": "redis"}]}}}}'
|
||||
```
|
||||
|
||||
<!--
|
||||
## Summary
|
||||
|
||||
In this exercise, you used `kubectl patch` to change the live configuration
|
||||
of a Deployment object. You did not change the configuration file that you originally used to
|
||||
create the Deployment object. Other commands for updating API objects include
|
||||
[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),
|
||||
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 apply`](/docs/reference/generated/kubectl/kubectl-commands/#apply)。
|
||||
|
||||
|
||||
<!--
|
||||
{{< note >}}
|
||||
Strategic merge patch is not supported for custom resources.
|
||||
{{< /note >}}
|
||||
-->
|
||||
{{< note >}}
|
||||
定制资源不支持策略性合并 patch。
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
<!--
|
||||
* [Kubernetes Object Management](/docs/concepts/overview/working-with-objects/object-management/)
|
||||
* [Managing Kubernetes Objects Using Imperative Commands](/docs/tasks/manage-kubernetes-objects/imperative-command/)
|
||||
* [Imperative Management of Kubernetes Objects Using Configuration Files](/docs/tasks/manage-kubernetes-objects/imperative-config/)
|
||||
* [Declarative Management of Kubernetes Objects Using Configuration Files](/docs/tasks/manage-kubernetes-objects/declarative-config/)
|
||||
-->
|
||||
* [Kubernetes 对象管理](/zh/docs/concepts/overview/working-with-objects/object-management/)
|
||||
* [使用指令式命令管理 Kubernetes 对象](/zh/docs/tasks/manage-kubernetes-objects/imperative-command/)
|
||||
* [使用配置文件执行 Kubernetes 对象的指令式管理](/zh/docs/tasks/manage-kubernetes-objects/imperative-config)
|
||||
* [使用配置文件对 Kubernetes 对象进行声明式管理](/zh/docs/tasks/manage-kubernetes-objects/declarative-config/)
|
||||
|
||||
Reference in New Issue
Block a user