Merge pull request #47561 from my-git9/pp-26629
[zh-cn] sync kubeadm/* pod-failure-policy.md
This commit is contained in:
commit
1bb484eb47
|
|
@ -435,18 +435,20 @@ Kubernetes 证书颁发机构不是开箱即用。你可以配置外部签名者
|
|||
|
||||
<!--
|
||||
If you're creating a new cluster, you can use a kubeadm
|
||||
[configuration file](/docs/reference/config-api/kubeadm-config.v1beta3/):
|
||||
[configuration file](/docs/reference/config-api/kubeadm-config.v1beta4/):
|
||||
-->
|
||||
如果你正在创建一个新的集群,你可以使用 kubeadm
|
||||
的[配置文件](/zh-cn/docs/reference/config-api/kubeadm-config.v1beta3/)。
|
||||
的[配置文件](/zh-cn/docs/reference/config-api/kubeadm-config.v1beta4/)。
|
||||
|
||||
```yaml
|
||||
apiVersion: kubeadm.k8s.io/v1beta3
|
||||
apiVersion: kubeadm.k8s.io/v1beta4
|
||||
kind: ClusterConfiguration
|
||||
controllerManager:
|
||||
extraArgs:
|
||||
cluster-signing-cert-file: /etc/kubernetes/pki/ca.crt
|
||||
cluster-signing-key-file: /etc/kubernetes/pki/ca.key
|
||||
- name: "cluster-signing-cert-file"
|
||||
value: "/etc/kubernetes/pki/ca.crt"
|
||||
- name: "cluster-signing-key-file"
|
||||
value: "/etc/kubernetes/pki/ca.key"
|
||||
```
|
||||
|
||||
<!--
|
||||
|
|
@ -527,7 +529,7 @@ certificates you must pass the following minimal configuration to `kubeadm init`
|
|||
你必须向 `kubeadm init` 传递如下最小配置数据:
|
||||
|
||||
```yaml
|
||||
apiVersion: kubeadm.k8s.io/v1beta3
|
||||
apiVersion: kubeadm.k8s.io/v1beta4
|
||||
kind: ClusterConfiguration
|
||||
---
|
||||
apiVersion: kubelet.config.k8s.io/v1beta1
|
||||
|
|
@ -658,13 +660,13 @@ Sharing the `admin.conf` with additional users is **not recommended**!
|
|||
Instead, you can use the [`kubeadm kubeconfig user`](/docs/reference/setup-tools/kubeadm/kubeadm-kubeconfig)
|
||||
command to generate kubeconfig files for additional users.
|
||||
The command accepts a mixture of command line flags and
|
||||
[kubeadm configuration](/docs/reference/config-api/kubeadm-config.v1beta3/) options.
|
||||
[kubeadm configuration](/docs/reference/config-api/kubeadm-config.v1beta4/) options.
|
||||
The generated kubeconfig will be written to stdout and can be piped to a file using
|
||||
`kubeadm kubeconfig user ... > somefile.conf`.
|
||||
-->
|
||||
你要使用 [`kubeadm kubeconfig user`](/zh-cn/docs/reference/setup-tools/kubeadm/kubeadm-kubeconfig)
|
||||
命令为其他用户生成 kubeconfig 文件,这个命令支持命令行参数和
|
||||
[kubeadm 配置结构](/zh-cn/docs/reference/config-api/kubeadm-config.v1beta3/)。
|
||||
[kubeadm 配置结构](/zh-cn/docs/reference/config-api/kubeadm-config.v1beta4/)。
|
||||
以上命令会将 kubeconfig 打印到终端上,也可以使用 `kubeadm kubeconfig user ... > somefile.conf`
|
||||
输出到一个文件中。
|
||||
|
||||
|
|
@ -673,9 +675,22 @@ Example configuration file that can be used with `--config`:
|
|||
-->
|
||||
如下 kubeadm 可以在 `--config` 后加的配置文件示例:
|
||||
|
||||
<!--
|
||||
```yaml
|
||||
# example.yaml
|
||||
apiVersion: kubeadm.k8s.io/v1beta3
|
||||
apiVersion: kubeadm.k8s.io/v1beta4
|
||||
kind: ClusterConfiguration
|
||||
# Will be used as the target "cluster" in the kubeconfig
|
||||
clusterName: "kubernetes"
|
||||
# Will be used as the "server" (IP or DNS name) of this cluster in the kubeconfig
|
||||
controlPlaneEndpoint: "some-dns-address:6443"
|
||||
# The cluster CA key and certificate will be loaded from this local directory
|
||||
certificatesDir: "/etc/kubernetes/pki"
|
||||
```
|
||||
-->
|
||||
```yaml
|
||||
# example.yaml
|
||||
apiVersion: kubeadm.k8s.io/v1beta4
|
||||
kind: ClusterConfiguration
|
||||
# kubernetes 将作为 kubeconfig 中集群名称
|
||||
clusterName: "kubernetes"
|
||||
|
|
|
|||
|
|
@ -102,7 +102,7 @@ ConfigMap 的内容时不会执行验证。 你必须小心遵循特定组件配
|
|||
#### Updating the `ClusterConfiguration`
|
||||
|
||||
During cluster creation and upgrade, kubeadm writes its
|
||||
[`ClusterConfiguration`](/docs/reference/config-api/kubeadm-config.v1beta3/)
|
||||
[`ClusterConfiguration`](/docs/reference/config-api/kubeadm-config.v1beta4/)
|
||||
in a ConfigMap called `kubeadm-config` in the `kube-system` namespace.
|
||||
|
||||
To change a particular option in the `ClusterConfiguration` you can edit the ConfigMap with this command:
|
||||
|
|
|
|||
|
|
@ -98,16 +98,18 @@ The upgrade workflow at high level is the following:
|
|||
<!--
|
||||
- To verify that the kubelet service has successfully restarted after the kubelet has been upgraded,
|
||||
you can execute `systemctl status kubelet` or view the service logs with `journalctl -xeu kubelet`.
|
||||
- Usage of the `--config` flag of `kubeadm upgrade` with
|
||||
[kubeadm configuration API types](/docs/reference/config-api/kubeadm-config.v1beta3)
|
||||
with the purpose of reconfiguring the cluster is not recommended and can have unexpected results. Follow the steps in
|
||||
- `kubeadm upgrade` supports `--config` with a
|
||||
[`UpgradeConfiguration` API type](/docs/reference/config-api/kubeadm-config.v1beta4) which can
|
||||
be used to configure the upgrade process.
|
||||
- `kubeadm upgrade` does not support reconfiguration of an existing cluster. Follow the steps in
|
||||
[Reconfiguring a kubeadm cluster](/docs/tasks/administer-cluster/kubeadm/kubeadm-reconfigure) instead.
|
||||
-->
|
||||
- 要验证 kubelet 服务在升级后是否成功重启,可以执行 `systemctl status kubelet`
|
||||
或 `journalctl -xeu kubelet` 查看服务日志。
|
||||
- 不建议使用 `kubeadm upgrade` 的 `--config` 参数和
|
||||
[kubeadm 配置 API 类型](/zh-cn/docs/reference/config-api/kubeadm-config.v1beta3)来重新配置集群,
|
||||
这样会产生意想不到的结果。
|
||||
- `kubeadm upgrade` 支持 `--config` 和
|
||||
[`UpgradeConfiguration` API 类型](/zh-cn/docs/reference/config-api/kubeadm-config.v1beta4)
|
||||
可用于配置升级过程。
|
||||
- `kubeadm upgrade` 不支持重新配置现有集群。
|
||||
请按照[重新配置 kubeadm 集群](/zh-cn/docs/tasks/administer-cluster/kubeadm/kubeadm-reconfigure)中的步骤来进行。
|
||||
|
||||
<!--
|
||||
|
|
@ -306,17 +308,6 @@ Pick a control plane node that you wish to upgrade first. It must have the `/etc
|
|||
更多的信息,可参阅[证书管理指南](/zh-cn/docs/tasks/administer-cluster/kubeadm/kubeadm-certs)。
|
||||
{{</ note >}}
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
If `kubeadm upgrade plan` shows any component configs that require manual upgrade, users must provide
|
||||
a config file with replacement configs to `kubeadm upgrade apply` via the `--config` command line flag.
|
||||
Failing to do so will cause `kubeadm upgrade apply` to exit with an error and not perform an upgrade.
|
||||
-->
|
||||
如果 `kubeadm upgrade plan` 给出任何需要手动升级的组件配置,
|
||||
用户必须通过 `--config` 命令行标志向 `kubeadm upgrade apply` 命令提供替代的配置文件。
|
||||
如果不这样做,`kubeadm upgrade apply` 会出错并退出,不再执行升级操作。
|
||||
{{</ note >}}
|
||||
|
||||
<!--
|
||||
1. Choose a version to upgrade to, and run the appropriate command. For example:
|
||||
-->
|
||||
|
|
@ -353,23 +344,14 @@ Pick a control plane node that you wish to upgrade first. It must have the `/etc
|
|||
the control plane instances have been upgraded before starting to upgrade the addons. You must perform control plane
|
||||
instances upgrade sequentially or at least ensure that the last control plane instance upgrade is not started until all
|
||||
the other control plane instances have been upgraded completely, and the addons upgrade will be performed after the last
|
||||
control plane instance is upgraded. If you want to keep the old upgrade behavior, please enable the `UpgradeAddonsBeforeControlPlane`
|
||||
feature gate by `kubeadm upgrade apply --feature-gates=UpgradeAddonsBeforeControlPlane=true`. The Kubernetes project does
|
||||
not in general recommend enabling this feature gate, you should instead change your upgrade process or cluster addons so
|
||||
that you do not need to enable the legacy behavior. The `UpgradeAddonsBeforeControlPlane` feature gate will be removed in
|
||||
a future release.
|
||||
control plane instance is upgraded.
|
||||
-->
|
||||
对于 v1.28 之前的版本,kubeadm 默认采用这样一种模式:在 `kubeadm upgrade apply`
|
||||
期间立即升级插件(包括 CoreDNS 和 kube-proxy),而不管是否还有其他尚未升级的控制平面实例。
|
||||
这可能会导致兼容性问题。从 v1.28 开始,kubeadm 默认采用这样一种模式:
|
||||
在开始升级插件之前,先检查是否已经升级所有的控制平面实例。
|
||||
你必须按顺序执行控制平面实例的升级,或者至少确保在所有其他控制平面实例已完成升级之前不启动最后一个控制平面实例的升级,
|
||||
并且在最后一个控制平面实例完成升级之后才执行插件的升级。如果你要保留旧的升级行为,可以通过
|
||||
`kubeadm upgrade apply --feature-gates=UpgradeAddonsBeforeControlPlane=true` 启用
|
||||
`UpgradeAddonsBeforeControlPlane` 特性门控。Kubernetes 项目通常不建议启用此特性门控,
|
||||
你应该转为更改你的升级过程或集群插件,这样你就不需要启用旧的行为。
|
||||
`UpgradeAddonsBeforeControlPlane` 特性门控将在后续的版本中被移除。
|
||||
|
||||
并且在最后一个控制平面实例完成升级之后才执行插件的升级。
|
||||
{{</ note >}}
|
||||
|
||||
<!--
|
||||
|
|
|
|||
|
|
@ -49,13 +49,6 @@ You should already be familiar with the basic use of [Job](/docs/concepts/worklo
|
|||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
<!--
|
||||
Ensure that the [feature gates](/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
`PodDisruptionConditions` and `JobPodFailurePolicy` are both enabled in your cluster.
|
||||
-->
|
||||
确保[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
`PodDisruptionConditions` 和 `JobPodFailurePolicy` 在你的集群中均已启用。
|
||||
|
||||
<!--
|
||||
## Using Pod failure policy to avoid unnecessary Pod retries
|
||||
|
||||
|
|
@ -93,18 +86,30 @@ kubectl get jobs -l job-name=job-pod-failure-policy-failjob -o yaml
|
|||
```
|
||||
|
||||
<!--
|
||||
In the Job status, see a job `Failed` condition with the field `reason`
|
||||
equal `PodFailurePolicy`. Additionally, the `message` field contains a
|
||||
more detailed information about the Job termination, such as:
|
||||
`Container main for pod default/job-pod-failure-policy-failjob-8ckj8 failed with exit code 42 matching FailJob rule at index 0`.
|
||||
In the Job status, the following conditions display:
|
||||
- `FailureTarget` condition: has a `reason` field set to `PodFailurePolicy` and
|
||||
a `message` field with more information about the termination, like
|
||||
`Container main for pod default/job-pod-failure-policy-failjob-8ckj8 failed with exit code 42 matching FailJob rule at index 0`.
|
||||
The Job controller adds this condition as soon as the Job is considered a failure.
|
||||
For details, see [Termination of Job Pods](/docs/concepts/workloads/controllers/job/#termination-of-job-pods).
|
||||
- `Failed` condition: same `reason` and `message` as the `FailureTarget`
|
||||
condition. The Job controller adds this condition after all of the Job's Pods
|
||||
are terminated.
|
||||
-->
|
||||
在 Job 状态中,显示以下情况:
|
||||
|
||||
- `FailureTarget` 状况:有一个设置为 `PodFailurePolicy` 的 `reason`
|
||||
字段和一个包含更多有关终止信息的 `message` 字段,例如
|
||||
`Container main for pod default/job-pod-failure-policy-failjob-8ckj8 failed with exit code 42 matching FailJob rule at index 0`。
|
||||
一旦 Job 被视为失败,Job 控制器就会添加此状况。有关详细信息,请参阅
|
||||
[Job Pod 的终止](/zh-cn/docs/concepts/workloads/controllers/job/#termination-of-job-pods)。
|
||||
- `Failed`:与 `FailureTarget` 状况相同的 `reason` 和 `message`。
|
||||
Job 控制器会在 Job 的所有 Pod 终止后添加此状况。
|
||||
|
||||
<!--
|
||||
For comparison, if the Pod failure policy was disabled it would take 6 retries
|
||||
of the Pod, taking at least 2 minutes.
|
||||
-->
|
||||
在 Job 状态中,看到一个任务状况为 `Failed`,其 `reason` 字段等于 `PodFailurePolicy`。
|
||||
此外,`message` 字段包含有关 Job 终止更详细的信息,例如:
|
||||
`Container main for pod default/job-pod-failure-policy-failjob-8ckj8 failed with exit code 42 matching FailJob rule at index 0`。
|
||||
|
||||
为了比较,如果 Pod 失效策略被禁用,将会让 Pod 重试 6 次,用时至少 2 分钟。
|
||||
|
||||
<!--
|
||||
|
|
|
|||
Loading…
Reference in New Issue