[zh-cn] Resync tasks/

pull/48396/head
Mengjiao Liu 2024-10-17 10:57:44 +08:00
parent 5eb233b701
commit bafadd28b4
7 changed files with 56 additions and 35 deletions

View File

@ -1,12 +1,12 @@
---
title: 更改 Kubernetes 软件包仓库
content_type: task
weight: 120
weight: 150
---
<!--
title: Changing The Kubernetes Package Repository
content_type: task
weight: 120
weight: 150
-->
<!-- overview -->

View File

@ -1,12 +1,12 @@
---
title: 配置 cgroup 驱动
content_type: task
weight: 20
weight: 50
---
<!--
title: Configuring a cgroup driver
content_type: task
weight: 10
weight: 50
-->
<!-- overview -->

View File

@ -1,14 +1,14 @@
---
title: 重新配置 kubeadm 集群
content_type: task
weight: 30
weight: 90
---
<!--
reviewers:
- sig-cluster-lifecycle
title: Reconfiguring a kubeadm cluster
content_type: task
weight: 30
weight: 90
-->
<!-- overview -->

View File

@ -1,12 +1,12 @@
---
title: 升级 Linux 节点
content_type: task
weight: 100
weight: 40
---
<!--
title: Upgrading Linux nodes
content_type: task
weight: 100
weight: 40
-->
<!-- overview -->

View File

@ -2,13 +2,13 @@
title: 升级 Windows 节点
min-kubernetes-server-version: 1.17
content_type: task
weight: 110
weight: 41
---
<!--
title: Upgrading Windows nodes
min-kubernetes-server-version: 1.17
content_type: task
weight: 110
weight: 41
-->
<!-- overview -->

View File

@ -41,9 +41,12 @@ is observed as not-ready for some period of time before it is hard killed.
<!--
The kubelet uses readiness probes to know when a container is ready to start
accepting traffic. A Pod is considered ready when all of its containers are ready.
One use of this signal is to control which Pods are used as backends for Services.
When a Pod is not ready, it is removed from Service load balancers.
accepting traffic. One use of this signal is to control which Pods are used as
backends for Services. A Pod is considered ready when its `Ready` [condition](/docs/concepts/workloads/pods/pod-lifecycle/#pod-conditions)
is true. When a Pod is not ready, it is removed from Service load balancers.
A Pod's `Ready` condition is false when its Node's `Ready` condition is not true,
when one of the Pod's `readinessGates` is false, or when at least one of its containers
is not ready.
The kubelet uses startup probes to know when a container application has started.
If such a probe is configured, liveness and readiness probes do not start until
@ -51,10 +54,12 @@ it succeeds, making sure those probes don't interfere with the application start
This can be used to adopt liveness checks on slow starting containers, avoiding them
getting killed by the kubelet before they are up and running.
-->
kubelet 使用就绪探针可以知道容器何时准备好接受请求流量,当一个 Pod
内的所有容器都就绪时,才能认为该 Pod 就绪。
kubelet 使用就绪探针可以知道容器何时准备好接受请求流量。
这种信号的一个用途就是控制哪个 Pod 作为 Service 的后端。
若 Pod 尚未就绪,会被从 Service 的负载均衡器中剔除。
当 Pod 的 `Ready` [状况](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#pod-conditions) 为
true 时Pod 被认为是就绪的。若 Pod 未就绪,会被从 Service 的负载均衡器中剔除。
当 Pod 所在节点的 `Ready` 状况不为 true 时、当 Pod 的某个 `readinessGates` 为 false
时,或者当 Pod 中有任何一个容器未就绪时Pod 的 `Ready` 状况为 false。
kubelet 使用启动探针来了解应用容器何时启动。
如果配置了这类探针,存活探针和就绪探针在启动探针成功之前不会启动,从而确保存活探针或就绪探针不会影响应用的启动。

View File

@ -15,8 +15,10 @@ content_type: task
<!-- overview -->
<!--
This guide demonstrates how to install and write extensions for [kubectl](/docs/reference/kubectl/kubectl/). By thinking of core `kubectl` commands as essential building blocks for interacting with a Kubernetes cluster, a cluster administrator can think
of plugins as a means of utilizing these building blocks to create more complex behavior. Plugins extend `kubectl` with new sub-commands, allowing for new and custom features not included in the main distribution of `kubectl`.
This guide demonstrates how to install and write extensions for [kubectl](/docs/reference/kubectl/kubectl/).
By thinking of core `kubectl` commands as essential building blocks for interacting with a Kubernetes cluster,
a cluster administrator can think of plugins as a means of utilizing these building blocks to create more complex behavior.
Plugins extend `kubectl` with new sub-commands, allowing for new and custom features not included in the main distribution of `kubectl`.
-->
本指南演示了如何为 [kubectl](/zh-cn/docs/reference/kubectl/kubectl/) 安装和编写扩展。
通过将核心 `kubectl` 命令看作与 Kubernetes 集群交互的基本构建块,
@ -37,7 +39,7 @@ You need to have a working `kubectl` binary installed.
A plugin is a standalone executable file, whose name begins with `kubectl-`. To install a plugin, move its executable file to anywhere on your `PATH`.
-->
## 安装 kubectl 插件
## 安装 kubectl 插件 {#installing-kubectl-plugins}
插件是一个独立的可执行文件,名称以 `kubectl-` 开头。
要安装插件,将其可执行文件移动到 `PATH` 中的任何位置。
@ -65,7 +67,8 @@ Krew [插件索引](https://krew.sigs.k8s.io/plugins/) 所维护的 kubectl 插
### Discovering plugins
`kubectl` provides a command `kubectl plugin list` that searches your `PATH` for valid plugin executables.
Executing this command causes a traversal of all files in your `PATH`. Any files that are executable, and begin with `kubectl-` will show up *in the order in which they are present in your `PATH`* in this command's output.
Executing this command causes a traversal of all files in your `PATH`. Any files that are executable, and
begin with `kubectl-` will show up *in the order in which they are present in your `PATH`* in this command's output.
A warning will be included for any files beginning with `kubectl-` that are *not* executable.
A warning will also be included for any valid plugin files that overlap each other's name.
@ -73,7 +76,7 @@ You can use [Krew](https://krew.dev/) to discover and install `kubectl`
plugins from a community-curated
[plugin index](https://krew.sigs.k8s.io/plugins/).
-->
### 发现插件
### 发现插件 {#discovering-plugins}
`kubectl` 提供一个命令 `kubectl plugin list`,用于搜索 `PATH` 查找有效的插件可执行文件。
执行此命令将遍历 `PATH` 中的所有文件。任何以 `kubectl-` 开头的可执行文件都将在这个命令的输出中**以它们在
@ -84,20 +87,33 @@ plugins from a community-curated
你可以使用 [Krew](https://krew.dev/) 从社区策划的[插件索引](https://krew.sigs.k8s.io/plugins/)
中发现和安装 `kubectl` 插件。
<!--
#### Create plugins
`kubectl` allows plugins to add custom create commands of the shape `kubectl create something` by providing a `kubectl-create-something` binary in the `PATH`.
-->
#### 创建插件 {#create-plugins}
通过在 `PATH` 中提供一个 `kubectl-create-something` 二进制文件,`kubectl` 允许插件添加形如 `kubectl create something` 的自定义创建命令。
<!--
#### Limitations
It is currently not possible to create plugins that overwrite existing `kubectl` commands. For example, creating a plugin `kubectl-version` will cause that plugin to never be executed, as the existing `kubectl version` command will always take precedence over it. Due to this limitation, it is also *not* possible to use plugins to add new subcommands to existing `kubectl` commands. For example, adding a subcommand `kubectl create foo` by naming your plugin `kubectl-create-foo` will cause that plugin to be ignored.
It is currently not possible to create plugins that overwrite existing `kubectl` commands or extend commands other than `create`.
For example, creating a plugin `kubectl-version` will cause that plugin to never be executed, as the existing `kubectl version`
command will always take precedence over it.
Due to this limitation, it is also *not* possible to use plugins to add new subcommands to existing `kubectl` commands.
For example, adding a subcommand `kubectl attach vm` by naming your plugin `kubectl-attach-vm` will cause that plugin to be ignored.
`kubectl plugin list` shows warnings for any valid plugins that attempt to do this.
-->
#### 限制
#### 限制 {#limitations}
目前无法创建覆盖现有 `kubectl` 命令的插件。
目前无法创建覆盖现有 `kubectl` 命令或扩展除 `create` 命令之外的插件。
例如,创建一个插件 `kubectl-version` 将导致该插件永远不会被执行,
因为现有的 `kubectl version` 命令总是优先于它执行。
由于这个限制,也不可能使用插件将新的子命令添加到现有的 `kubectl` 命令中。
例如,通过将插件命名为 `kubectl-create-foo` 来添加子命令 `kubectl create foo` 将导致该插件被忽略。
例如,通过将插件命名为 `kubectl-attach-vm` 来添加子命令 `kubectl attach vm` 将导致该插件被忽略。
对于任何试图这样做的有效插件 `kubectl plugin list` 的输出中将显示警告。
@ -106,7 +122,7 @@ It is currently not possible to create plugins that overwrite existing `kubectl`
You can write a plugin in any programming language or script that allows you to write command-line commands.
-->
## 编写 kubectl 插件
## 编写 kubectl 插件 {#writing-kubectl-plugins}
你可以用任何编程语言或脚本编写插件,允许你编写命令行命令。
@ -125,7 +141,7 @@ install the plugin executable somewhere in your `PATH`.
<!--
### Example plugin
-->
### 示例插件
### 示例插件 {#example-plugin}
```
#!/bin/bash
@ -150,7 +166,7 @@ echo "I am a plugin named kubectl-foo"
<!--
### Using a plugin
-->
### 使用插件
### 使用插件 {#using-a-plugin}
<!--
To use a plugin, make the plugin executable:
@ -229,7 +245,7 @@ Additionally, the first argument that is passed to a plugin will always be the f
As seen in the example above, a plugin determines the command path that it will implement based on its filename. Every sub-command in the command path that a plugin targets, is separated by a dash (`-`).
For example, a plugin that wishes to be invoked whenever the command `kubectl foo bar baz` is invoked by the user, would have the filename of `kubectl-foo-bar-baz`.
-->
### 命名插件
### 命名插件 {#naming-a-plugin}
如上面的例子所示,插件根据文件名确定要实现的命令路径,插件所针对的命令路径中的每个子命令都由破折号(`-`)分隔。
例如,当用户调用命令 `kubectl foo bar baz` 时,希望调用该命令的插件的文件名为 `kubectl-foo-bar-baz`
@ -237,7 +253,7 @@ For example, a plugin that wishes to be invoked whenever the command `kubectl fo
<!--
#### Flags and argument handling
-->
#### 参数和标记处理
#### 参数和标记处理 {#flags-and-argument-handling}
<!--
The plugin mechanism does _not_ create any custom, plugin-specific values or environment variables for a plugin process.
@ -318,7 +334,7 @@ As you can see, your plugin was found based on the `kubectl` command specified b
Although the `kubectl` plugin mechanism uses the dash (`-`) in plugin filenames to separate the sequence of sub-commands processed by the plugin, it is still possible to create a plugin
command containing dashes in its commandline invocation by using underscores (`_`) in its filename.
-->
#### 带有破折号和下划线的名称
#### 带有破折号和下划线的名称 {#names-with-dashes-and-underscores}
虽然 `kubectl` 插件机制在插件文件名中使用破折号(`-`)分隔插件处理的子命令序列,
但是仍然可以通过在文件名中使用下划线(`_`)来创建命令行中包含破折号的插件命令。
@ -373,7 +389,7 @@ It is possible to have multiple plugins with the same filename in different loca
For example, given a `PATH` with the following value: `PATH=/usr/local/bin/plugins:/usr/local/bin/moreplugins`, a copy of plugin `kubectl-foo` could exist in `/usr/local/bin/plugins` and `/usr/local/bin/moreplugins`,
such that the output of the `kubectl plugin list` command is:
-->
#### 命名冲突和弊端
#### 命名冲突和弊端 {#name-conflicts-and-overshadowing}
可以在 `PATH` 的不同位置提供多个文件名相同的插件,
例如,给定一个 `PATH` 为: `PATH=/usr/local/bin/plugins:/usr/local/bin/moreplugins`
@ -413,7 +429,7 @@ A way to resolve this issue is to ensure that the location of the plugin that yo
There is another kind of overshadowing that can occur with plugin filenames. Given two plugins present in a user's `PATH`: `kubectl-foo-bar` and `kubectl-foo-bar-baz`, the `kubectl` plugin mechanism will always choose the longest possible plugin name for a given user command. Some examples below, clarify this further:
-->
#### 调用最长的可执行文件名
#### 调用最长的可执行文件名 {#invocation-of-the-longest-executable-filename}
对于插件文件名而言还有另一种弊端,给定用户 `PATH` 中的两个插件 `kubectl-foo-bar``kubectl-foo-bar-baz`
`kubectl` 插件机制总是为给定的用户命令选择尽可能长的插件名称。下面的一些例子进一步的说明了这一点:
@ -471,7 +487,7 @@ kubectl-parent-subcommand-subsubcommand
You can use the aforementioned `kubectl plugin list` command to ensure that your plugin is visible by `kubectl`, and verify that there are no warnings preventing it from being called as a `kubectl` command.
-->
### 检查插件警告
### 检查插件警告 {#checking-for-plugin-warnings}
你可以使用前面提到的 `kubectl plugin list` 命令来确保你的插件可以被 `kubectl` 看到,
并且验证没有警告防止它被称为 `kubectl` 命令。
@ -526,7 +542,7 @@ an example usage of the tools provided in the CLI Runtime repo.
If you have developed a plugin for others to use, you should consider how you
package it, distribute it and deliver updates to your users.
-->
## 分发 kubectl 插件
## 分发 kubectl 插件 {#distributing-kubectl-plugins}
如果你开发了一个插件给别人使用,你应该考虑如何为其封装打包、如何分发软件
以及将来的更新到用户。