Merge pull request #23730 from tengqm/zh-links-setup-3
[zh] fix links in setup section (3)
This commit is contained in:
Kubernetes Prow Robot
GitHub
commit
2e834dfa69
|
|
@ -3,13 +3,11 @@ title: oVirt
|
|||
content_type: concept
|
||||
---
|
||||
<!--
|
||||
---
|
||||
reviewers:
|
||||
- caesarxuchao
|
||||
- erictune
|
||||
title: oVirt
|
||||
content_type: concept
|
||||
---
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
|
@ -20,52 +18,44 @@ oVirt is a virtual datacenter manager that delivers powerful management of multi
|
|||
oVirt 是一个虚拟数据中心管理器，可以对多个主机上的多个虚拟机进行强大的管理。
|
||||
使用 KVM 和 libvirt ，可以将 oVirt 安装在 Fedora、CentOS 或者 Red Hat Enterprise Linux 主机上，以部署和管理您的虚拟数据中心。
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
## oVirt Cloud Provider Deployment
|
||||
-->
|
||||
## oVirt 云驱动的部署
|
||||
|
||||
<!--
|
||||
The oVirt cloud provider allows to easily discover and automatically add new VM instances as nodes to your Kubernetes cluster.
|
||||
At the moment there are no community-supported or pre-loaded VM images including Kubernetes but it is possible to [import] or [install] Project Atomic (or Fedora) in a VM to [generate a template]. Any other distribution that includes Kubernetes may work as well.
|
||||
-->
|
||||
## oVirt 云驱动的部署
|
||||
|
||||
oVirt 云驱动可以轻松发现新 VM 实例并自动将其添加为 Kubernetes 集群的节点。
|
||||
目前，包括 Kubernetes 在内，尚无社区支持或预加载的 VM 镜像，但可以在 VM 中 [导入] 或 [安装] Project Atomic（或 Fedora）来 [生成模版]。
|
||||
目前，包括 Kubernetes 在内，尚无社区支持或预加载的 VM 镜像，但可以在 VM 中
|
||||
[导入](https://ovedou.blogspot.it/2014/03/importing-glance-images-as-ovirt.html) 或
|
||||
[安装](https://www.ovirt.org/documentation/quickstart/quickstart-guide/#create-virtual-machines)
|
||||
Project Atomic（或 Fedora）来
|
||||
[生成模版](https://www.ovirt.org/documentation/quickstart/quickstart-guide/#using-templates)。
|
||||
包括 Kubernetes 的任何其他 Linux 发行版也可能可行。
|
||||
|
||||
<!--
|
||||
It is mandatory to [install the ovirt-guest-agent] in the guests for the VM ip address and hostname to be reported to ovirt-engine and ultimately to Kubernetes.
|
||||
-->
|
||||
必须在寄宿系统中 [安装 ovirt-guest-agent]，才能将 VM 的 IP 地址和主机名报给 ovirt-engine 并最终报告给 Kubernetes。
|
||||
必须在寄宿系统中
|
||||
[安装 ovirt-guest-agent](https://www.ovirt.org/documentation/how-to/guest-agent/install-the-guest-agent-in-fedora/)，
|
||||
才能将 VM 的 IP 地址和主机名报给 ovirt-engine 并最终报告给 Kubernetes。
|
||||
|
||||
<!--
|
||||
Once the Kubernetes template is available it is possible to start instantiating VMs that can be discovered by the cloud provider.
|
||||
-->
|
||||
一旦 Kubernetes 模版可用，就可以开始创建可由云驱动发现的 VM。
|
||||
|
||||
<!--
|
||||
[import]: https://ovedou.blogspot.it/2014/03/importing-glance-images-as-ovirt.html
|
||||
[install]: https://www.ovirt.org/documentation/quickstart/quickstart-guide/#create-virtual-machines
|
||||
[generate a template]: https://www.ovirt.org/documentation/quickstart/quickstart-guide/#using-templates
|
||||
[install the ovirt-guest-agent]: https://www.ovirt.org/documentation/how-to/guest-agent/install-the-guest-agent-in-fedora/
|
||||
-->
|
||||
[导入]: https://ovedou.blogspot.it/2014/03/importing-glance-images-as-ovirt.html
|
||||
[安装]: https://www.ovirt.org/documentation/quickstart/quickstart-guide/#create-virtual-machines
|
||||
[生成模版]: https://www.ovirt.org/documentation/quickstart/quickstart-guide/#using-templates
|
||||
[安装 ovirt-guest-agent]: https://www.ovirt.org/documentation/how-to/guest-agent/install-the-guest-agent-in-fedora/
|
||||
|
||||
<!--
|
||||
## Using the oVirt Cloud Provider
|
||||
|
||||
The oVirt Cloud Provider requires access to the oVirt REST-API to gather the proper information,
|
||||
the required credential should be specified in the `ovirt-cloud.conf` file:
|
||||
-->
|
||||
## 使用 oVirt 云驱动
|
||||
|
||||
<!--
|
||||
The oVirt Cloud Provider requires access to the oVirt REST-API to gather the proper information, the required credential should be specified in the `ovirt-cloud.conf` file:
|
||||
-->
|
||||
oVirt 云驱动需要访问 oVirt REST-API 来收集正确的信息，所需的凭据应在 `ovirt-cloud.conf` 文件中设定：
|
||||
|
||||
```none
|
||||
|
|
@ -128,8 +118,6 @@ oVirt | | | | [docs](/docs/setup/
|
|||
-->
|
||||
IaaS 提供商 | 配置管理 | OS | 联网 | 文件 | 遵从性 | 支持级别
|
||||
----------------- | ------- | ------ | ---- | ------------------------------------------------- |------| ---------------
|
||||
oVirt | | | | [文件](/docs/setup/production-environment/on-premises-vm/ovirt/) | | 社区 ([@simon3z](https://github.com/simon3z))
|
||||
|
||||
|
||||
oVirt | | | | [文件](/zh/docs/setup/production-environment/on-premises-vm/ovirt/) | | 社区 ([@simon3z](https://github.com/simon3z))
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -1,18 +1,12 @@
|
|||
---
|
||||
reviewers:
|
||||
- sig-cluster-lifecycle
|
||||
title: 配置您的 kubernetes 集群以自托管控制平台
|
||||
content_type: concept
|
||||
weight: 100
|
||||
---
|
||||
<!--
|
||||
---
|
||||
reviewers:
|
||||
- sig-cluster-lifecycle
|
||||
title: Configuring your kubernetes cluster to self-host the control plane
|
||||
content_type: concept
|
||||
weight: 100
|
||||
---
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
|
@ -30,15 +24,17 @@ configured via the Kubernetes API instead of [static pods](/docs/tasks/administe
|
|||
configured in the kubelet via static files.
|
||||
-->
|
||||
kubeadm 允许您实验性地创建 _self-hosted_ Kubernetes 控制平面。
|
||||
这意味着 API 服务器，控制管理器和调度程序之类的关键组件将通过配置 Kubernetes API 以 [DaemonSet pods](/docs/concepts/workloads/controllers/daemonset/) 的身份运行，而不是通过静态文件将 [static pods](/docs/tasks/administer-cluster/static-pod/) 在 kubelet 中配置。
|
||||
这意味着 API 服务器，控制管理器和调度程序之类的关键组件将通过配置 Kubernetes API 以
|
||||
[DaemonSet Pods](/zh/docs/concepts/workloads/controllers/daemonset/) 的身份运行，
|
||||
而不是通过静态文件在 kubelet 中配置[静态 Pods](/zh/docs/tasks/configure-pod-container/static-pod/)。
|
||||
|
||||
<!--
|
||||
To create a self-hosted cluster see the
|
||||
[kubeadm alpha selfhosting pivot](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-selfhosting) command.
|
||||
-->
|
||||
要创建自托管集群，请参见 [kubeadm alpha 自托管枢纽](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-selfhosting) 命令。
|
||||
|
||||
|
||||
要创建自托管集群，请参见
|
||||
[kubeadm alpha selfhosting pivot](/zh/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-selfhosting)
|
||||
命令。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
|
|
@ -47,11 +43,11 @@ To create a self-hosted cluster see the
|
|||
-->
|
||||
#### 警告
|
||||
|
||||
{{< caution >}}
|
||||
<!--
|
||||
This feature pivots your cluster into an unsupported state, rendering kubeadm unable
|
||||
to manage you cluster any longer. This includes `kubeadm upgrade`.
|
||||
-->
|
||||
{{< caution >}}
|
||||
此功能将您的集群设置为不受支持的状态，从而使 kubeadm 无法再管理您的集群。
|
||||
这包括 `kubeadm 升级` 。
|
||||
{{< /caution >}}
|
||||
|
|
@ -62,7 +58,7 @@ to manage you cluster any longer. This includes `kubeadm upgrade`.
|
|||
without manual intervention.
|
||||
-->
|
||||
1. 1.8及更高版本中的自托管功能有一些重要限制。
|
||||
特别是，自托管集群在没有人工干预的情况下_无法从控制平面节点的重新启动中恢复_ 。
|
||||
特别是，自托管集群在没有人工干预的情况下_无法从控制平面节点的重新启动中恢复_ 。
|
||||
|
||||
<!--
|
||||
1. By default, self-hosted control plane Pods rely on credentials loaded from
|
||||
|
|
@ -70,30 +66,30 @@ to manage you cluster any longer. This includes `kubeadm upgrade`.
|
|||
volumes. Except for initial creation, these credentials are not managed by
|
||||
kubeadm.
|
||||
-->
|
||||
1. 默认情况下，自托管的控制平面 Pod 依赖于从 [`hostPath`](/docs/concepts/storage/volumes/#hostpath) 卷加载的凭据。
|
||||
除初始创建外，这些凭据不由 kubeadm 管理。
|
||||
2. 默认情况下，自托管的控制平面 Pod 依赖于从
|
||||
[`hostPath`](/zh/docs/concepts/storage/volumes/#hostpath) 卷加载的凭据。
|
||||
除初始创建外，这些凭据不由 kubeadm 管理。
|
||||
|
||||
<!--
|
||||
1. The self-hosted portion of the control plane does not include etcd,
|
||||
which still runs as a static Pod.
|
||||
-->
|
||||
1. 控制平面的自托管部分不包括 etcd，后者仍作为静态 Pod 运行。
|
||||
3. 控制平面的自托管部分不包括 etcd，后者仍作为静态 Pod 运行。
|
||||
|
||||
<!--
|
||||
#### Process
|
||||
-->
|
||||
#### 处理
|
||||
|
||||
<!--
|
||||
The self-hosting bootstrap process is documented in the [kubeadm design
|
||||
document](https://github.com/kubernetes/kubeadm/blob/master/docs/design/design_v1.9.md#optional-self-hosting).
|
||||
-->
|
||||
自托管引导过程记录在 [kubeadm 设计文档](https://github.com/kubernetes/kubeadm/blob/master/docs/design/design_v1.9.md#optional-self-hosting) 中。
|
||||
#### 过程
|
||||
|
||||
自托管引导过程描述于 [kubeadm 设计文档](https://github.com/kubernetes/kubeadm/blob/master/docs/design/design_v1.9.md#optional-self-hosting) 中。
|
||||
|
||||
<!--
|
||||
In summary, `kubeadm alpha selfhosting` works as follows:
|
||||
-->
|
||||
总而言之，`kubeadm alpha 自托管` 的工作原理如下：
|
||||
总体而言，`kubeadm alpha 自托管` 的工作原理如下：
|
||||
|
||||
<!--
|
||||
1. Waits for this bootstrap static control plane to be running and
|
||||
|
|
@ -107,28 +103,27 @@ In summary, `kubeadm alpha selfhosting` works as follows:
|
|||
It also modifies these manifests where necessary, for example adding new volumes
|
||||
for secrets.
|
||||
-->
|
||||
1. 使用静态控制平面 Pod 清单来构造一组 DaemonSet 清单，这些清单将运行自托管的控制平面。
|
||||
2. 使用静态控制平面 Pod 清单来构造一组 DaemonSet 清单，这些清单将运行自托管的控制平面。
|
||||
它还会在必要时修改这些清单，例如添加新的秘密卷。
|
||||
|
||||
<!--
|
||||
1. Creates DaemonSets in the `kube-system` namespace and waits for the
|
||||
resulting Pods to be running.
|
||||
-->
|
||||
1. 在 `kube-system` 名称空间中创建 DaemonSets ，并等待生成的 Pod 运行。
|
||||
3. 在 `kube-system` 名称空间中创建 DaemonSets ，并等待生成的 Pod 运行。
|
||||
|
||||
<!--
|
||||
1. Once self-hosted Pods are operational, their associated static Pods are deleted
|
||||
and kubeadm moves on to install the next component. This triggers kubelet to
|
||||
stop those static Pods.
|
||||
-->
|
||||
1. 自托管 Pod 运行后，将删除其关联的静态 Pod，然后 kubeadm 继续安装下一个组件。
|
||||
这将触发 kubelet 停止那些静态 Pod 。
|
||||
4. 自托管 Pod 运行后，将删除其关联的静态 Pod，然后 kubeadm 继续安装下一个组件。
|
||||
这将触发 kubelet 停止那些静态 Pod 。
|
||||
|
||||
<!--
|
||||
1. When the original static control plane stops, the new self-hosted control
|
||||
plane is able to bind to listening ports and become active.
|
||||
-->
|
||||
1. 当原始静态控制平面停止时，新的自托管控制平面能够绑定到侦听端口并变为活动状态。
|
||||
|
||||
5. 当原始静态控制平面停止时，新的自托管控制平面能够绑定到侦听端口并变为活动状态。
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -5,11 +5,9 @@ weight: 20
|
|||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
title: Troubleshooting kubeadm
|
||||
content_type: concept
|
||||
weight: 20
|
||||
---
|
||||
-->
|
||||
<!-- overview -->
|
||||
|
||||
|
|
@ -26,19 +24,18 @@ If your problem is not listed below, please follow the following steps:
|
|||
- If you are unsure about how kubeadm works, you can ask on [Slack](http://slack.k8s.io/) in #kubeadm, or open a question on [StackOverflow](https://stackoverflow.com/questions/tagged/kubernetes). Please include
|
||||
relevant tags like `#kubernetes` and `#kubeadm` so folks can help you.
|
||||
-->
|
||||
与任何程序一样，您可能会在安装或者运行 kubeadm 时遇到错误。
|
||||
本文列举了一些常见的故障场景，并提供可帮助您理解和解决这些问题的步骤。
|
||||
与任何程序一样，你可能会在安装或者运行 kubeadm 时遇到错误。
|
||||
本文列举了一些常见的故障场景，并提供可帮助你理解和解决这些问题的步骤。
|
||||
|
||||
如果您的问题未在下面列出，请执行以下步骤：
|
||||
如果你的问题未在下面列出，请执行以下步骤：
|
||||
|
||||
- 如果您认为问题是 kubeadm 的错误：
|
||||
- 如果你认为问题是 kubeadm 的错误：
|
||||
- 转到 [github.com/kubernetes/kubeadm](https://github.com/kubernetes/kubeadm/issues) 并搜索存在的问题。
|
||||
- 如果没有问题，请 [打开](https://github.com/kubernetes/kubeadm/issues/new) 并遵循问题模板。
|
||||
|
||||
- 如果您对 kubeadm 的工作方式有疑问，可以在 [Slack](http://slack.k8s.io/) 上的 #kubeadm 频道提问，
|
||||
- 如果你对 kubeadm 的工作方式有疑问，可以在 [Slack](https://slack.k8s.io/) 上的 #kubeadm 频道提问，
|
||||
或者在 [StackOverflow](https://stackoverflow.com/questions/tagged/kubernetes) 上提问。
|
||||
请加入相关标签，例如 `#kubernetes` 和 `#kubeadm`，这样其他人可以帮助您。
|
||||
|
||||
请加入相关标签，例如 `#kubernetes` 和 `#kubeadm`，这样其他人可以帮助你。
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
|
@ -67,8 +64,8 @@ Then you may be missing `ebtables`, `ethtool` or a similar executable on your no
|
|||
[preflight] WARNING: ethtool not found in system path
|
||||
```
|
||||
|
||||
那么或许在您的节点上缺失 `ebtables`、`ethtool` 或者类似的可执行文件。
|
||||
您可以使用以下命令安装它们：
|
||||
那么或许在你的节点上缺失 `ebtables`、`ethtool` 或者类似的可执行文件。
|
||||
你可以使用以下命令安装它们：
|
||||
|
||||
- 对于 Ubuntu/Debian 用户，运行 `apt install ebtables ethtool` 命令。
|
||||
- 对于 CentOS/Fedora 用户，运行 `yum install ebtables ethtool` 命令。
|
||||
|
|
@ -84,7 +81,7 @@ If you notice that `kubeadm init` hangs after printing out the following line:
|
|||
-->
|
||||
## 在安装过程中，kubeadm 一直等待控制平面就绪
|
||||
|
||||
如果您注意到 `kubeadm init` 在打印以下行后挂起：
|
||||
如果你注意到 `kubeadm init` 在打印以下行后挂起：
|
||||
|
||||
```sh
|
||||
[apiclient] Created API client, waiting for the control plane to become ready
|
||||
|
|
@ -114,9 +111,9 @@ This may be caused by a number of problems. The most common are:
|
|||
-->
|
||||
这可能是由许多问题引起的。最常见的是：
|
||||
|
||||
- 网络连接问题。在继续之前，请检查您的计算机是否具有全部联通的网络连接。
|
||||
- 网络连接问题。在继续之前，请检查你的计算机是否具有全部联通的网络连接。
|
||||
- kubelet 的默认 cgroup 驱动程序配置不同于 Docker 使用的配置。
|
||||
检查系统日志文件 (例如 `/var/log/message`) 或检查 `journalctl -u kubelet` 的输出。 如果您看见以下内容：
|
||||
检查系统日志文件 (例如 `/var/log/message`) 或检查 `journalctl -u kubelet` 的输出。 如果你看见以下内容：
|
||||
|
||||
```shell
|
||||
error: failed to run Kubelet: failed to create kubelet:
|
||||
|
|
@ -125,12 +122,12 @@ This may be caused by a number of problems. The most common are:
|
|||
|
||||
有两种常见方法可解决 cgroup 驱动程序问题：
|
||||
|
||||
1. 按照 [此处](/docs/setup/production-environment/container-runtimes/#docker) 的说明再次安装 Docker。
|
||||
1. 按照 [此处](/zh/docs/setup/production-environment/container-runtimes/#docker) 的说明再次安装 Docker。
|
||||
|
||||
1. 更改 kubelet 配置以手动匹配 Docker cgroup 驱动程序，您可以参考
|
||||
[在主节点上配置 kubelet 要使用的 cgroup 驱动程序](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-master-node)
|
||||
1. 更改 kubelet 配置以手动匹配 Docker cgroup 驱动程序，你可以参考
|
||||
[在主节点上配置 kubelet 要使用的 cgroup 驱动程序](/zh/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-master-node)
|
||||
|
||||
- 控制平面上的 Docker 容器持续进入崩溃状态或（因其他原因）挂起。您可以运行 `docker ps` 命令来检查以及 `docker logs` 命令来检视每个容器的运行日志。
|
||||
- 控制平面上的 Docker 容器持续进入崩溃状态或（因其他原因）挂起。你可以运行 `docker ps` 命令来检查以及 `docker logs` 命令来检视每个容器的运行日志。
|
||||
|
||||
<!--
|
||||
## kubeadm blocks when removing managed containers
|
||||
|
|
@ -181,7 +178,7 @@ sudo kubeadm reset
|
|||
|
||||
检查 docker 的日志也可能有用：
|
||||
|
||||
```sh
|
||||
```shell
|
||||
journalctl -ul docker
|
||||
```
|
||||
|
||||
|
|
@ -209,15 +206,17 @@ Right after `kubeadm init` there should not be any pods in these states.
|
|||
|
||||
- 在 `kubeadm init` 命令执行完后，如果有 pods 处于这些状态之一，请在 kubeadm
|
||||
仓库提起一个 issue。`coredns` (或者 `kube-dns`) 应该处于 `Pending` 状态，
|
||||
直到您部署了网络解决方案为止。
|
||||
直到你部署了网络解决方案为止。
|
||||
|
||||
- 如果在部署完网络解决方案之后，有 Pods 处于 `RunContainerError`、`CrashLoopBackOff`
|
||||
或 `Error` 状态之一，并且`coredns` （或者 `kube-dns`）仍处于 `Pending` 状态，
|
||||
那很可能是您安装的网络解决方案由于某种原因无法工作。您或许需要授予它更多的
|
||||
那很可能是你安装的网络解决方案由于某种原因无法工作。你或许需要授予它更多的
|
||||
RBAC 特权或使用较新的版本。请在 Pod Network 提供商的问题跟踪器中提交问题，
|
||||
然后在此处分类问题。
|
||||
- 如果您安装的 Docker 版本早于 1.12.1，请在使用 `systemd` 来启动 `dockerd` 和重启 `docker` 时，
|
||||
|
||||
- 如果你安装的 Docker 版本早于 1.12.1，请在使用 `systemd` 来启动 `dockerd` 和重启 `docker` 时，
|
||||
删除 `MountFlags=slave` 选项。
|
||||
您可以在 `/usr/lib/systemd/system/docker.service` 中看到 MountFlags。
|
||||
你可以在 `/usr/lib/systemd/system/docker.service` 中看到 MountFlags。
|
||||
MountFlags 可能会干扰 Kubernetes 挂载的卷， 并使 Pods 处于 `CrashLoopBackOff` 状态。
|
||||
当 Kubernetes 不能找到 `var/run/secrets/kubernetes.io/serviceaccount` 文件时会发生错误。
|
||||
|
||||
|
|
@ -232,8 +231,8 @@ before CoreDNS may be deployed fully. Hence the `Pending` state before the netwo
|
|||
## `coredns` （或 `kube-dns`）停滞在 `Pending` 状态
|
||||
|
||||
这一行为是 **预期之中** 的，因为系统就是这么设计的。
|
||||
kubeadm 的网络供应商是中立的，因此管理员应该选择 [安装 pod 的网络解决方案](/docs/concepts/cluster-administration/addons/)。
|
||||
您必须完成 Pod 的网络配置，然后才能完全部署 CoreDNS。
|
||||
kubeadm 的网络供应商是中立的，因此管理员应该选择 [安装 pod 的网络解决方案](/zh/docs/concepts/cluster-administration/addons/)。
|
||||
你必须完成 Pod 的网络配置，然后才能完全部署 CoreDNS。
|
||||
在网络被配置好之前，DNS 组件会一直处于 `Pending` 状态。
|
||||
|
||||
<!--
|
||||
|
|
@ -252,14 +251,16 @@ services](/docs/concepts/services-networking/service/#nodeport) or use `HostNetw
|
|||
-->
|
||||
## `HostPort` 服务无法工作
|
||||
|
||||
此 `HostPort` 和 `HostIP` 功能是否可用取决于您的 Pod 网络配置。请联系 Pod 解决方案的作者，
|
||||
此 `HostPort` 和 `HostIP` 功能是否可用取决于你的 Pod 网络配置。请联系 Pod 解决方案的作者，
|
||||
以确认 `HostPort` 和 `HostIP` 功能是否可用。
|
||||
|
||||
已验证 Calico、Canal 和 Flannel CNI 驱动程序支持 HostPort。
|
||||
|
||||
有关更多信息，请参考 [CNI portmap 文档](https://github.com/containernetworking/plugins/blob/master/plugins/meta/portmap/README.md).
|
||||
|
||||
如果您的网络提供商不支持 portmap CNI 插件，您或许需要使用 [NodePort 服务的功能](/docs/concepts/services-networking/service/#nodeport) 或者使用 `HostNetwork=true`。
|
||||
如果你的网络提供商不支持 portmap CNI 插件，你或许需要使用
|
||||
[NodePort 服务的功能](/zh/docs/concepts/services-networking/service/#nodeport)
|
||||
或者使用 `HostNetwork=true`。
|
||||
|
||||
<!--
|
||||
## Pods are not accessible via their Service IP
|
||||
|
|
@ -277,10 +278,11 @@ services](/docs/concepts/services-networking/service/#nodeport) or use `HostNetw
|
|||
-->
|
||||
## 无法通过其服务 IP 访问 Pod
|
||||
|
||||
- 许多网络附加组件尚未启用 [hairpin 模式](/docs/tasks/debug-application-cluster/debug-service/#a-pod-cannot-reach-itself-via-service-ip)
|
||||
该模式允许 Pod 通过其服务 IP 进行访问。这是与 [CNI](https://github.com/containernetworking/cni/issues/476) 有关的问题。请与网络附加组件提供商联系，以获取他们所提供的 hairpin 模式的最新状态。
|
||||
- 许多网络附加组件尚未启用 [hairpin 模式](/zh/docs/tasks/debug-application-cluster/debug-service/#a-pod-cannot-reach-itself-via-service-ip)
|
||||
该模式允许 Pod 通过其服务 IP 进行访问。这是与 [CNI](https://github.com/containernetworking/cni/issues/476) 有关的问题。
|
||||
请与网络附加组件提供商联系，以获取他们所提供的 hairpin 模式的最新状态。
|
||||
|
||||
- 如果您正在使用 VirtualBox (直接使用或者通过 Vagrant 使用)，您需要
|
||||
- 如果你正在使用 VirtualBox (直接使用或者通过 Vagrant 使用)，你需要
|
||||
确保 `hostname -i` 返回一个可路由的 IP 地址。默认情况下，第一个接口连接不能路由的仅主机网络。
|
||||
解决方法是修改 `/etc/hosts`，请参考示例 [Vagrantfile](https://github.com/errordeveloper/k8s-playground/blob/22dd39dfc06111235620e6c4404a96ae146f26fd/Vagrantfile#L11)。
|
||||
|
||||
|
|
@ -334,19 +336,19 @@ Unable to connect to the server: x509: certificate signed by unknown authority (
|
|||
可以用于查看证书信息。
|
||||
- 使用如下方法取消设置 `KUBECONFIG` 环境变量的值：
|
||||
|
||||
```sh
|
||||
```shell
|
||||
unset KUBECONFIG
|
||||
```
|
||||
|
||||
或者将其设置为默认的 `KUBECONFIG` 位置：
|
||||
|
||||
```sh
|
||||
```shell
|
||||
export KUBECONFIG=/etc/kubernetes/admin.conf
|
||||
```
|
||||
|
||||
- 另一个方法是覆盖 `kubeconfig` 的现有用户 "管理员" ：
|
||||
|
||||
```sh
|
||||
```shell
|
||||
mv $HOME/.kube $HOME/.kube.bak
|
||||
mkdir $HOME/.kube
|
||||
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
|
||||
|
|
@ -366,7 +368,7 @@ Error from server (NotFound): the server could not find the requested resource
|
|||
|
||||
Vagrant typically assigns two interfaces to all VMs. The first, for which all hosts are assigned the IP address `10.0.2.15`, is for external traffic that gets NATed.
|
||||
|
||||
This may lead to problems with flannel, which defaults to the first interface on a host. This leads to all hosts thinking they have the same public IP address. To prevent this, pass the `--iface eth1` flag to flannel so that the second interface is chosen.
|
||||
This may lead to problems with flannel, which defaults to the first interface on a host. This leads to all hosts thinking they have the same public IP address. To prevent this, pass the `-iface eth1` flag to flannel so that the second interface is chosen.
|
||||
-->
|
||||
## 在 Vagrant 中使用 flannel 作为 pod 网络时的默认 NIC
|
||||
|
||||
|
|
@ -401,7 +403,7 @@ Error from server: Get https://10.19.0.41:10250/containerLogs/default/mysql-ddc6
|
|||
curl http://169.254.169.254/metadata/v1/interfaces/public/0/anchor_ipv4/address
|
||||
```
|
||||
|
||||
The workaround is to tell `kubelet` which IP to use using `--node-ip`. When using Digital Ocean, it can be the public one (assigned to `eth0`) or the private one (assigned to `eth1`) should you want to use the optional private network. The [`KubeletExtraArgs` section of the kubeadm `NodeRegistrationOptions` structure](https://github.com/kubernetes/kubernetes/blob/release-1.13/cmd/kubeadm/app/apis/kubeadm/v1beta1/types.go) can be used for this.
|
||||
The workaround is to tell `kubelet` which IP to use using `-node-ip`. When using Digital Ocean, it can be the public one (assigned to `eth0`) or the private one (assigned to `eth1`) should you want to use the optional private network. The [`KubeletExtraArgs` section of the kubeadm `NodeRegistrationOptions` structure](https://github.com/kubernetes/kubernetes/blob/release-1.13/cmd/kubeadm/app/apis/kubeadm/v1beta1/types.go) can be used for this.
|
||||
|
||||
Then restart `kubelet`:
|
||||
|
||||
|
|
@ -433,14 +435,15 @@ Error from server: Get https://10.19.0.41:10250/containerLogs/default/mysql-ddc6
|
|||
|
||||
解决方法是通知 `kubelet` 使用哪个 `--node-ip`。当使用 Digital Ocean 时，可以是公网IP（分配给 `eth0`的），
|
||||
或者是私网IP（分配给 `eth1` 的）。私网 IP 是可选的。
|
||||
这个 [`KubeletExtraArgs` section of the kubeadm `NodeRegistrationOptions` structure](https://github.com/kubernetes/kubernetes/blob/release-1.13/cmd/kubeadm/app/apis/kubeadm/v1beta1/types.go) 被用来处理这种情况。
|
||||
[kubadm `NodeRegistrationOptions` 结构的 `KubeletExtraArgs` 部分](https://github.com/kubernetes/kubernetes/blob/release-1.13/cmd/kubeadm/app/apis/kubeadm/v1beta1/types.go) 被用来处理这种情况。
|
||||
|
||||
然后重启 `kubelet`：
|
||||
|
||||
```sh
|
||||
```shell
|
||||
systemctl daemon-reload
|
||||
systemctl restart kubelet
|
||||
```
|
||||
|
||||
<!--
|
||||
## `coredns` pods have `CrashLoopBackOff` or `Error` state
|
||||
|
||||
|
|
@ -463,15 +466,16 @@ are available to avoid Kubernetes trying to restart the CoreDNS Pod every time C
|
|||
-->
|
||||
## `coredns` pods 有 `CrashLoopBackOff` 或者 `Error` 状态
|
||||
|
||||
如果有些节点运行的是旧版本的 Docker，同时启用了 SELinux，您或许会遇到 `coredns` pods 无法启动的情况。
|
||||
要解决此问题，您可以尝试以下选项之一：
|
||||
如果有些节点运行的是旧版本的 Docker，同时启用了 SELinux，你或许会遇到 `coredns` pods 无法启动的情况。
|
||||
要解决此问题，你可以尝试以下选项之一：
|
||||
|
||||
- 升级到 [Docker 的较新版本](/docs/setup/production-environment/container-runtimes/#docker)。
|
||||
- 升级到 [Docker 的较新版本](/zh/docs/setup/production-environment/container-runtimes/#docker)。
|
||||
|
||||
- [禁用 SELinux](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/security-enhanced_linux/sect-security-enhanced_linux-enabling_and_disabling_selinux-disabling_selinux).
|
||||
|
||||
- 修改 `coredns` 部署以设置 `allowPrivilegeEscalation` 为 `true`：
|
||||
|
||||
```bash
|
||||
```shell
|
||||
kubectl -n kube-system get deployment coredns -o yaml | \
|
||||
sed 's/allowPrivilegeEscalation: false/allowPrivilegeEscalation: true/g' | \
|
||||
kubectl apply -f -
|
||||
|
|
@ -481,11 +485,11 @@ CoreDNS 处于 `CrashLoopBackOff` 时的另一个原因是当 Kubernetes 中部
|
|||
到环路时。[有许多解决方法](https://github.com/coredns/coredns/tree/master/plugin/loop#troubleshooting-loops-in-kubernetes-clusters)
|
||||
可以避免在每次 CoreDNS 监测到循环并退出时，Kubernetes 尝试重启 CoreDNS Pod 的情况。
|
||||
|
||||
{{< warning >}}
|
||||
<!--
|
||||
Disabling SELinux or setting `allowPrivilegeEscalation` to `true` can compromise
|
||||
the security of your cluster.
|
||||
-->
|
||||
{{< warning >}}
|
||||
禁用 SELinux 或设置 `allowPrivilegeEscalation` 为 `true` 可能会损害集群的安全性。
|
||||
{{< /warning >}}
|
||||
|
||||
|
|
@ -510,65 +514,72 @@ yum downgrade docker-1.13.1-75.git8633870.el7.centos.x86_64 docker-client-1.13.1
|
|||
|
||||
- Install one of the more recent recommended versions, such as 18.06:
|
||||
```bash
|
||||
sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
|
||||
sudo yum-config-manager -add-repo https://download.docker.com/linux/centos/docker-ce.repo
|
||||
yum install docker-ce-18.06.1.ce-3.el7.x86_64
|
||||
```
|
||||
-->
|
||||
## etcd pods 持续重启
|
||||
|
||||
如果您遇到以下错误：
|
||||
如果你遇到以下错误：
|
||||
|
||||
```
|
||||
rpc error: code = 2 desc = oci runtime error: exec failed: container_linux.go:247: starting container process caused "process_linux.go:110: decoding init error from pipe caused \"read parent: connection reset by peer\""
|
||||
```
|
||||
|
||||
如果您使用 Docker 1.13.1.84 运行 CentOS 7 就会出现这种问题。
|
||||
如果你使用 Docker 1.13.1.84 运行 CentOS 7 就会出现这种问题。
|
||||
此版本的 Docker 会阻止 kubelet 在 etcd 容器中执行。
|
||||
|
||||
为解决此问题，请选择以下选项之一：
|
||||
|
||||
- 回滚到早期版本的 Docker，例如 1.13.1-75
|
||||
```
|
||||
yum downgrade docker-1.13.1-75.git8633870.el7.centos.x86_64 docker-client-1.13.1-75.git8633870.el7.centos.x86_64 docker-common-1.13.1-75.git8633870.el7.centos.x86_64
|
||||
```
|
||||
|
||||
```shell
|
||||
yum downgrade docker-1.13.1-75.git8633870.el7.centos.x86_64 docker-client-1.13.1-75.git8633870.el7.centos.x86_64 docker-common-1.13.1-75.git8633870.el7.centos.x86_64
|
||||
```
|
||||
|
||||
- 安装较新的推荐版本之一，例如 18.06:
|
||||
```bash
|
||||
sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
|
||||
yum install docker-ce-18.06.1.ce-3.el7.x86_64
|
||||
```
|
||||
|
||||
```shell
|
||||
sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
|
||||
yum install docker-ce-18.06.1.ce-3.el7.x86_64
|
||||
```
|
||||
|
||||
<!--
|
||||
## Not possible to pass a comma separated list of values to arguments inside a `--component-extra-args` flag
|
||||
## Not possible to pass a comma separated list of values to arguments inside a `-component-extra-args` flag
|
||||
|
||||
`kubeadm init` flags such as `--component-extra-args` allow you to pass custom arguments to a control-plane
|
||||
`kubeadm init` flags such as `-component-extra-args` allow you to pass custom arguments to a control-plane
|
||||
component like the kube-apiserver. However, this mechanism is limited due to the underlying type used for parsing
|
||||
the values (`mapStringString`).
|
||||
|
||||
If you decide to pass an argument that supports multiple, comma-separated values such as
|
||||
`--apiserver-extra-args "enable-admission-plugins=LimitRanger,NamespaceExists"` this flag will fail with
|
||||
`-apiserver-extra-args "enable-admission-plugins=LimitRanger,NamespaceExists"` this flag will fail with
|
||||
`flag: malformed pair, expect string=string`. This happens because the list of arguments for
|
||||
`--apiserver-extra-args` expects `key=value` pairs and in this case `NamespacesExists` is considered
|
||||
`-apiserver-extra-args` expects `key=value` pairs and in this case `NamespacesExists` is considered
|
||||
as a key that is missing a value.
|
||||
|
||||
Alternatively, you can try separating the `key=value` pairs like so:
|
||||
`--apiserver-extra-args "enable-admission-plugins=LimitRanger,enable-admission-plugins=NamespaceExists"`
|
||||
`-apiserver-extra-args "enable-admission-plugins=LimitRanger,enable-admission-plugins=NamespaceExists"`
|
||||
but this will result in the key `enable-admission-plugins` only having the value of `NamespaceExists`.
|
||||
|
||||
A known workaround is to use the kubeadm [configuration file](/docs/setup/production-environment/tools/kubeadm/control-plane-flags/#apiserver-flags).
|
||||
-->
|
||||
## 无法将以逗号分隔的值列表传递给 `--component-extra-args` 标志内的参数
|
||||
|
||||
`kubeadm init` 标志例如 `--component-extra-args` 允许您将自定义参数传递给像 kube-apiserver 这样的控制平面组件。然而，由于解析 (`mapStringString`) 的基础类型值，此机制将受到限制。
|
||||
`kubeadm init` 标志例如 `--component-extra-args` 允许你将自定义参数传递给像
|
||||
kube-apiserver 这样的控制平面组件。然而，由于解析 (`mapStringString`) 的基础类型值，此机制将受到限制。
|
||||
|
||||
如果您决定传递一个支持多个逗号分隔值（例如 `--apiserver-extra-args "enable-admission-plugins=LimitRanger,NamespaceExists"`）参数，将出现 `flag: malformed pair, expect string=string` 错误。
|
||||
发生这种问题是因为参数列表 `--apiserver-extra-args` 预期的是 `key=value` 形式，而这里的 `NamespacesExists` 被误认为是缺少取值的键名。
|
||||
如果你决定传递一个支持多个逗号分隔值（例如
|
||||
`--apiserver-extra-args "enable-admission-plugins=LimitRanger,NamespaceExists"`）参数，
|
||||
将出现 `flag: malformed pair, expect string=string` 错误。
|
||||
发生这种问题是因为参数列表 `--apiserver-extra-args` 预期的是 `key=value` 形式，
|
||||
而这里的 `NamespacesExists` 被误认为是缺少取值的键名。
|
||||
|
||||
一种解决方法是尝试分离 `key=value` 对，像这样：
|
||||
`--apiserver-extra-args "enable-admission-plugins=LimitRanger,enable-admission-plugins=NamespaceExists"`
|
||||
但这将导致键 `enable-admission-plugins` 仅有值 `NamespaceExists`。
|
||||
|
||||
已知的解决方法是使用 kubeadm [配置文件](/docs/setup/production-environment/tools/kubeadm/control-plane-flags/#apiserver-flags)。
|
||||
已知的解决方法是使用 kubeadm
|
||||
[配置文件](/zh/docs/setup/production-environment/tools/kubeadm/control-plane-flags/#apiserver-flags)。
|
||||
|
||||
<!--
|
||||
## kube-proxy scheduled before node is initialized by cloud-controller-manager
|
||||
|
|
@ -599,17 +610,20 @@ The tracking issue for this problem is [here](https://github.com/kubernetes/kube
|
|||
这会导致 kube-proxy 无法正确获取节点的 IP 地址，并对管理负载平衡器的代理功能产生连锁反应。
|
||||
|
||||
在 kube-proxy Pod 中可以看到以下错误：
|
||||
|
||||
```
|
||||
server.go:610] Failed to retrieve node IP: host IP unknown; known addresses: []
|
||||
proxier.go:340] invalid nodeIP, initializing kube-proxy with 127.0.0.1 as nodeIP
|
||||
```
|
||||
|
||||
一种已知的解决方案是修补 kube-proxy DaemonSet，以允许在控制平面节点上调度它，而不管它们的条件如何，将其与其他节点保持隔离，直到它们的初始保护条件消除：
|
||||
```
|
||||
一种已知的解决方案是修补 kube-proxy DaemonSet，以允许在控制平面节点上调度它，
|
||||
而不管它们的条件如何，将其与其他节点保持隔离，直到它们的初始保护条件消除：
|
||||
|
||||
```shell
|
||||
kubectl -n kube-system patch ds kube-proxy -p='{ "spec": { "template": { "spec": { "tolerations": [ { "key": "CriticalAddonsOnly", "operator": "Exists" }, { "effect": "NoSchedule", "key": "node-role.kubernetes.io/master" } ] } } } }'
|
||||
```
|
||||
|
||||
此问题的跟踪 [在这里](https://github.com/kubernetes/kubeadm/issues/1027)。
|
||||
此问题的跟踪[在这里](https://github.com/kubernetes/kubeadm/issues/1027)。
|
||||
|
||||
<!--
|
||||
## The NodeRegistration.Taints field is omitted when marshalling kubeadm configuration
|
||||
|
|
@ -631,20 +645,21 @@ kubectl taint nodes NODE_NAME node-role.kubernetes.io/master:NoSchedule-
|
|||
-->
|
||||
## NodeRegistration.Taints 字段在编组 kubeadm 配置时丢失
|
||||
|
||||
*注意：这个 [问题](https://github.com/kubernetes/kubeadm/issues/1358) 仅适用于操控 kubeadm 数据类型的工具（例如，YAML 配置文件）。它将在 kubeadm API v1beta2 修复。*
|
||||
*注意：这个 [问题](https://github.com/kubernetes/kubeadm/issues/1358)
|
||||
仅适用于操控 kubeadm 数据类型的工具（例如，YAML 配置文件）。它将在 kubeadm API v1beta2 修复。*
|
||||
|
||||
默认情况下，kubeadm 将 `node-role.kubernetes.io/master:NoSchedule` 污点应用于控制平面节点。
|
||||
如果您希望 kubeadm 不污染控制平面节点，并将 `InitConfiguration.NodeRegistration.Taints` 设置成空切片，则应在编组时省略该字段。
|
||||
如果你希望 kubeadm 不污染控制平面节点，并将 `InitConfiguration.NodeRegistration.Taints` 设置成空切片，则应在编组时省略该字段。
|
||||
如果省略该字段，则 kubeadm 将应用默认污点。
|
||||
|
||||
至少有两种解决方法：
|
||||
|
||||
1. 使用 `node-role.kubernetes.io/master:PreferNoSchedule` 污点代替空切片。
|
||||
除非其他节点具有容量，[否则将在主节点上调度 Pods](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/)。
|
||||
除非其他节点具有容量，[否则将在主节点上调度 Pods](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)。
|
||||
|
||||
2. 在 kubeadm init 退出后删除污点：
|
||||
```bash
|
||||
kubectl taint nodes NODE_NAME node-role.kubernetes.io/master:NoSchedule-
|
||||
```
|
||||
|
||||
```shell
|
||||
kubectl taint nodes NODE_NAME node-role.kubernetes.io/master:NoSchedule-
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -1,20 +1,15 @@
|
|||
---
|
||||
reviewers:
|
||||
- michmike
|
||||
- patricklang
|
||||
title: Kubernetes 中调度 Windows 容器的指南
|
||||
content_type: concept
|
||||
weight: 75
|
||||
---
|
||||
<!--
|
||||
---
|
||||
reviewers:
|
||||
- michmike
|
||||
- patricklang
|
||||
title: Guide for scheduling Windows containers in Kubernetes
|
||||
content_type: concept
|
||||
weight: 75
|
||||
---
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
|
@ -22,9 +17,8 @@ weight: 75
|
|||
<!--
|
||||
Windows applications constitute a large portion of the services and applications that run in many organizations. This guide walks you through the steps to configure and deploy a Windows container in Kubernetes.
|
||||
-->
|
||||
Windows 应用程序构成了许多组织中运行的服务和应用程序的很大一部分。本指南将引导您完成在 Kubernetes 中配置和部署 Windows 容器的步骤。
|
||||
|
||||
|
||||
Windows 应用程序构成了许多组织中运行的服务和应用程序的很大一部分。
|
||||
本指南将引导您完成在 Kubernetes 中配置和部署 Windows 容器的步骤。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
|
|
@ -47,8 +41,10 @@ Windows 应用程序构成了许多组织中运行的服务和应用程序的很
|
|||
-->
|
||||
## 在你开始之前
|
||||
|
||||
* 创建一个 Kubernetes 集群，其中包括一个[运行 Windows Server 的主节点和工作节点](../user-guide-windows-nodes)
|
||||
* 重要的是要注意，对于 Linux 和 Windows 容器，在 Kubernetes 上创建和部署服务和工作负载的行为几乎相同。与集群接口的 [Kubectl 命令](/docs/reference/kubectl/overview/)相同。提供以下部分中的示例只是为了快速启动 Windows 容器的使用体验。
|
||||
* 创建一个 Kubernetes 集群，其中包括一个
|
||||
[运行 Windows 服务器的主节点和工作节点](/zh/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/)
|
||||
* 重要的是要注意，对于 Linux 和 Windows 容器，在 Kubernetes 上创建和部署服务和工作负载的行为几乎相同。
|
||||
与集群接口的 [Kubectl 命令](/zh/docs/reference/kubectl/overview/)相同。提供以下部分中的示例只是为了快速启动 Windows 容器的使用体验。
|
||||
|
||||
<!--
|
||||
## Getting Started: Deploying a Windows container
|
||||
|
|
@ -57,7 +53,9 @@ To deploy a Windows container on Kubernetes, you must first create an example ap
|
|||
-->
|
||||
## 入门：部署 Windows 容器
|
||||
|
||||
要在 Kubernetes 上部署 Windows 容器，您必须首先创建一个示例应用程序。下面的示例 YAML 文件创建了一个简单的 Web 服务器应用程序。创建一个名为 `win-webserver.yaml` 的服务规约，其内容如下：
|
||||
要在 Kubernetes 上部署 Windows 容器，您必须首先创建一个示例应用程序。
|
||||
下面的示例 YAML 文件创建了一个简单的 Web 服务器应用程序。
|
||||
创建一个名为 `win-webserver.yaml` 的服务规约，其内容如下：
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
|
|
@ -103,10 +101,10 @@ spec:
|
|||
kubernetes.io/os: windows
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
Port mapping is also supported, but for simplicity in this example the container port 80 is exposed directly to the service.
|
||||
-->
|
||||
{{< note >}}
|
||||
端口映射也是支持的，但为简单起见，在此示例中容器端口 80 直接暴露给服务。
|
||||
{{< /note >}}
|
||||
|
||||
|
|
@ -139,34 +137,34 @@ Port mapping is also supported, but for simplicity in this example the container
|
|||
-->
|
||||
1. 检查所有节点是否健康：
|
||||
|
||||
```bash
|
||||
kubectl get nodes
|
||||
```
|
||||
```bash
|
||||
kubectl get nodes
|
||||
```
|
||||
|
||||
1. 部署服务并观察 pod 更新：
|
||||
|
||||
```bash
|
||||
kubectl apply -f win-webserver.yaml
|
||||
kubectl get pods -o wide -w
|
||||
```
|
||||
```bash
|
||||
kubectl apply -f win-webserver.yaml
|
||||
kubectl get pods -o wide -w
|
||||
```
|
||||
|
||||
正确部署服务后，两个 Pod 都标记为“Ready”。要退出 watch 命令，请按 Ctrl + C。
|
||||
正确部署服务后，两个 Pod 都标记为“Ready”。要退出 watch 命令，请按 Ctrl + C。
|
||||
|
||||
1. 检查部署是否成功。验证：
|
||||
|
||||
* Windows 节点上每个 Pod 有两个容器，使用 `docker ps`
|
||||
* Linux 主机列出两个 Pod，使用 `kubectl get pods`
|
||||
* 跨网络的节点到 Pod 通信，从 Linux 主服务器 `curl` 您的 pod IPs 的端口80，以检查 Web 服务器响应
|
||||
* Pod 到 Pod 的通信，使用 docker exec 或 kubectl exec 在 pod 之间（以及跨主机，如果您有多个 Windows 节点）进行 ping 操作
|
||||
* 服务到 Pod 的通信，从 Linux 主服务器和各个 Pod 中 `curl` 虚拟服务 IP（在 `kubectl get services` 下可见）
|
||||
* 服务发现，使用 Kubernetes `curl` 服务名称[默认 DNS 后缀](/docs/concepts/services-networking/dns-pod-service/#services)
|
||||
* 入站连接，从 Linux 主服务器或集群外部的计算机 `curl` NodePort
|
||||
* 出站连接，使用 kubectl exec 从 Pod 内部 curl 外部 IP
|
||||
* Windows 节点上每个 Pod 有两个容器，使用 `docker ps`
|
||||
* Linux 主机列出两个 Pod，使用 `kubectl get pods`
|
||||
* 跨网络的节点到 Pod 通信，从 Linux 主服务器 `curl` 您的 pod IPs 的端口80，以检查 Web 服务器响应
|
||||
* Pod 到 Pod 的通信，使用 docker exec 或 kubectl exec 在 pod 之间（以及跨主机，如果您有多个 Windows 节点）进行 ping 操作
|
||||
* 服务到 Pod 的通信，从 Linux 主服务器和各个 Pod 中 `curl` 虚拟服务 IP（在 `kubectl get services` 下可见）
|
||||
* 服务发现，使用 Kubernetes `curl` 服务名称[默认 DNS 后缀](/zh/docs/concepts/services-networking/dns-pod-service/#services)
|
||||
* 入站连接，从 Linux 主服务器或集群外部的计算机 `curl` NodePort
|
||||
* 出站连接，使用 kubectl exec 从 Pod 内部 curl 外部 IP
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
Windows container hosts are not able to access the IP of services scheduled on them due to current platform limitations of the Windows networking stack. Only Windows pods are able to access service IPs.
|
||||
-->
|
||||
{{< note >}}
|
||||
由于当前平台对 Windows 网络堆栈的限制，Windows 容器主机无法访问在其上调度的服务的 IP。只有 Windows pods 才能访问服务 IP。
|
||||
{{< /note >}}
|
||||
|
||||
|
|
@ -177,7 +175,9 @@ Starting with Kubernetes v1.16, Windows containers can be configured to run thei
|
|||
-->
|
||||
## 使用可配置的容器用户名
|
||||
|
||||
从 Kubernetes v1.16 开始，可以为 Windows 容器配置与其镜像默认值不同的用户名来运行其入口点和进程。此能力的实现方式和 Linux 容器有些不同。在[此处](/docs/tasks/configure-pod-container/configure-runasusername/)可了解更多信息。
|
||||
从 Kubernetes v1.16 开始，可以为 Windows 容器配置与其镜像默认值不同的用户名来运行其入口点和进程。
|
||||
此能力的实现方式和 Linux 容器有些不同。
|
||||
在[此处](/zh/docs/tasks/configure-pod-container/configure-runasusername/)可了解更多信息。
|
||||
|
||||
<!--
|
||||
## Managing Workload Identity with Group Managed Service Accounts
|
||||
|
|
@ -186,7 +186,11 @@ Starting with Kubernetes v1.14, Windows container workloads can be configured to
|
|||
-->
|
||||
## 使用组托管服务帐户管理工作负载身份
|
||||
|
||||
从 Kubernetes v1.14 开始，可以将 Windows 容器工作负载配置为使用组托管服务帐户（GMSA）。组托管服务帐户是 Active Directory 帐户的一种特定类型，它提供自动密码管理，简化的服务主体名称（SPN）管理以及将管理委派给跨多台服务器的其他管理员的功能。配置了 GMSA 的容器可以访问外部 Active Directory 域资源，同时携带通过 GMSA 配置的身份。在[此处](/docs/tasks/configure-pod-container/configure-gmsa/)了解有关为 Windows 容器配置和使用 GMSA 的更多信息。
|
||||
从 Kubernetes v1.14 开始，可以将 Windows 容器工作负载配置为使用组托管服务帐户（GMSA）。
|
||||
组托管服务帐户是 Active Directory 帐户的一种特定类型，它提供自动密码管理，
|
||||
简化的服务主体名称（SPN）管理以及将管理委派给跨多台服务器的其他管理员的功能。
|
||||
配置了 GMSA 的容器可以访问外部 Active Directory 域资源，同时携带通过 GMSA 配置的身份。
|
||||
在[此处](/zh/docs/tasks/configure-pod-container/configure-gmsa/)了解有关为 Windows 容器配置和使用 GMSA 的更多信息。
|
||||
|
||||
<!--
|
||||
## Taints and Tolerations
|
||||
|
|
@ -196,7 +200,9 @@ Starting with Kubernetes v1.14, Windows container workloads can be configured to
|
|||
<!--
|
||||
Users today need to use some combination of taints and node selectors in order to keep Linux and Windows workloads on their respective OS-specific nodes. This likely imposes a burden only on Windows users. The recommended approach is outlined below, with one of its main goals being that this approach should not break compatibility for existing Linux workloads.
|
||||
-->
|
||||
目前，用户需要将 Linux 和 Windows 工作负载运行在各自特定的操作系统的节点上，因而需要结合使用污点和节点选择算符。这可能仅给 Windows 用户造成不便。推荐的方法概述如下，其主要目标之一是该方法不应破坏与现有 Linux 工作负载的兼容性。
|
||||
目前，用户需要将 Linux 和 Windows 工作负载运行在各自特定的操作系统的节点上，
|
||||
因而需要结合使用污点和节点选择算符。 这可能仅给 Windows 用户造成不便。
|
||||
推荐的方法概述如下，其主要目标之一是该方法不应破坏与现有 Linux 工作负载的兼容性。
|
||||
|
||||
<!--
|
||||
### Ensuring OS-specific workloads land on the appropriate container host
|
||||
|
|
@ -214,12 +220,18 @@ Users can ensure Windows containers can be scheduled on the appropriate host usi
|
|||
<!--
|
||||
If a Pod specification does not specify a nodeSelector like `"kubernetes.io/os": windows`, it is possible the Pod can be scheduled on any host, Windows or Linux. This can be problematic since a Windows container can only run on Windows and a Linux container can only run on Linux. The best practice is to use a nodeSelector.
|
||||
-->
|
||||
如果 Pod 规范未指定诸如 `"kubernetes.io/os": windows` 之类的 nodeSelector，则该 Pod 可能会被调度到任何主机（Windows 或 Linux）上。这是有问题的，因为 Windows 容器只能在 Windows 上运行，而 Linux 容器只能在 Linux 上运行。最佳实践是使用 nodeSelector。
|
||||
如果 Pod 规范未指定诸如 `"kubernetes.io/os": windows` 之类的 nodeSelector，则该 Pod
|
||||
可能会被调度到任何主机（Windows 或 Linux）上。
|
||||
这是有问题的，因为 Windows 容器只能在 Windows 上运行，而 Linux 容器只能在 Linux 上运行。
|
||||
最佳实践是使用 nodeSelector。
|
||||
|
||||
<!--
|
||||
However, we understand that in many cases users have a pre-existing large number of deployments for Linux containers, as well as an ecosystem of off-the-shelf configurations, such as community Helm charts, and programmatic Pod generation cases, such as with Operators. In those situations, you may be hesitant to make the configuration change to add nodeSelectors. The alternative is to use Taints. Because the kubelet can set Taints during registration, it could easily be modified to automatically add a taint when running on Windows only.
|
||||
-->
|
||||
但是，我们了解到，在许多情况下，用户都有既存的大量的 Linux 容器部署，以及一个现成的配置生态系统，例如社区 Helm charts，以及程序化 Pod 生成案例，例如 Operators。在这些情况下，您可能会不愿意更改配置添加 nodeSelector。替代方法是使用污点。由于 kubelet 可以在注册期间设置污点，因此可以轻松修改它，使其仅在 Windows 上运行时自动添加污点。
|
||||
但是，我们了解到，在许多情况下，用户都有既存的大量的 Linux 容器部署，以及一个现成的配置生态系统，
|
||||
例如社区 Helm charts，以及程序化 Pod 生成案例，例如 Operators。
|
||||
在这些情况下，您可能会不愿意更改配置添加 nodeSelector。替代方法是使用污点。
|
||||
由于 kubelet 可以在注册期间设置污点，因此可以轻松修改它，使其仅在 Windows 上运行时自动添加污点。
|
||||
|
||||
<!--
|
||||
For example: `--register-with-taints='os=windows:NoSchedule'`
|
||||
|
|
@ -229,17 +241,19 @@ For example: `--register-with-taints='os=windows:NoSchedule'`
|
|||
<!--
|
||||
By adding a taint to all Windows nodes, nothing will be scheduled on them (that includes existing Linux Pods). In order for a Windows Pod to be scheduled on a Windows node, it would need both the nodeSelector to choose Windows, and the appropriate matching toleration.
|
||||
-->
|
||||
向所有 Windows 节点添加污点后，Kubernetes 将不会在它们上调度任何负载（包括现有的 Linux Pod）。为了使某 Windows Pod 调度到 Windows 节点上，该 Pod 既需要 nodeSelector 选择 Windows，也需要合适的匹配的容忍度设置。
|
||||
向所有 Windows 节点添加污点后，Kubernetes 将不会在它们上调度任何负载（包括现有的 Linux Pod）。
|
||||
为了使某 Windows Pod 调度到 Windows 节点上，该 Pod 既需要 nodeSelector 选择 Windows，
|
||||
也需要合适的匹配的容忍度设置。
|
||||
|
||||
```yaml
|
||||
nodeSelector:
|
||||
kubernetes.io/os: windows
|
||||
node.kubernetes.io/windows-build: '10.0.17763'
|
||||
kubernetes.io/os: windows
|
||||
node.kubernetes.io/windows-build: '10.0.17763'
|
||||
tolerations:
|
||||
- key: "os"
|
||||
operator: "Equal"
|
||||
value: "windows"
|
||||
effect: "NoSchedule"
|
||||
- key: "os"
|
||||
operator: "Equal"
|
||||
value: "windows"
|
||||
effect: "NoSchedule"
|
||||
```
|
||||
|
||||
<!--
|
||||
|
|
@ -257,14 +271,15 @@ Server versions in the same cluster, then you should set additional node labels
|
|||
<!--
|
||||
Kubernetes 1.17 automatically adds a new label `node.kubernetes.io/windows-build` to simplify this. If you're running an older version, then it's recommended to add this label manually to Windows nodes.
|
||||
-->
|
||||
Kubernetes 1.17 自动添加了一个新标签 `node.kubernetes.io/windows-build` 来简化此操作。 如果您运行的是旧版本，则建议手动将此标签添加到 Windows 节点。
|
||||
Kubernetes 1.17 自动添加了一个新标签 `node.kubernetes.io/windows-build` 来简化此操作。
|
||||
如果您运行的是旧版本，则建议手动将此标签添加到 Windows 节点。
|
||||
|
||||
<!--
|
||||
This label reflects the Windows major, minor, and build number that need to match for compatibility. Here are values used today for each Windows Server version.
|
||||
-->
|
||||
此标签反映了需要兼容的 Windows 主要、次要和内部版本号。以下是当前每个 Windows Server 版本使用的值。
|
||||
|
||||
| 产品名称 | 内部编号 |
|
||||
| 产品名称 | 内部编号 |
|
||||
|--------------------------------------|------------------------|
|
||||
| Windows Server 2019 | 10.0.17763 |
|
||||
| Windows Server version 1809 | 10.0.17763 |
|
||||
|
|
@ -279,38 +294,38 @@ This label reflects the Windows major, minor, and build number that need to matc
|
|||
<!--
|
||||
[RuntimeClass] can be used to simplify the process of using taints and tolerations. A cluster administrator can create a `RuntimeClass` object which is used to encapsulate these taints and tolerations.
|
||||
-->
|
||||
[RuntimeClass] 可用于简化使用污点和容忍度的过程。集群管理员可以创建 `RuntimeClass` 对象，用于封装这些污点和容忍度。
|
||||
|
||||
[RuntimeClass](/zh/docs/concepts/containers/runtime-class/) 可用于简化使用污点和容忍度的过程。
|
||||
集群管理员可以创建 `RuntimeClass` 对象，用于封装这些污点和容忍度。
|
||||
|
||||
<!--
|
||||
1. Save this file to `runtimeClasses.yml`. It includes the appropriate `nodeSelector` for the Windows OS, architecture, and version.
|
||||
-->
|
||||
1. 将此文件保存到 `runtimeClasses.yml` 文件。它包括适用于 Windows 操作系统、体系结构和版本的 `nodeSelector`。
|
||||
|
||||
```yaml
|
||||
apiVersion: node.k8s.io/v1beta1
|
||||
kind: RuntimeClass
|
||||
metadata:
|
||||
name: windows-2019
|
||||
handler: 'docker'
|
||||
scheduling:
|
||||
nodeSelector:
|
||||
kubernetes.io/os: 'windows'
|
||||
kubernetes.io/arch: 'amd64'
|
||||
node.kubernetes.io/windows-build: '10.0.17763'
|
||||
tolerations:
|
||||
- effect: NoSchedule
|
||||
key: os
|
||||
operator: Equal
|
||||
value: "windows"
|
||||
```
|
||||
```yaml
|
||||
apiVersion: node.k8s.io/v1beta1
|
||||
kind: RuntimeClass
|
||||
metadata:
|
||||
name: windows-2019
|
||||
handler: 'docker'
|
||||
scheduling:
|
||||
nodeSelector:
|
||||
kubernetes.io/os: 'windows'
|
||||
kubernetes.io/arch: 'amd64'
|
||||
node.kubernetes.io/windows-build: '10.0.17763'
|
||||
tolerations:
|
||||
- effect: NoSchedule
|
||||
key: os
|
||||
operator: Equal
|
||||
value: "windows"
|
||||
```
|
||||
|
||||
<!--
|
||||
1. Run `kubectl create -f runtimeClasses.yml` using as a cluster administrator
|
||||
1. Add `runtimeClassName: windows-2019` as appropriate to Pod specs
|
||||
-->
|
||||
1. 集群管理员运行 `kubectl create -f runtimeClasses.yml` 操作
|
||||
1. 根据需要向 Pod 规约中添加 `runtimeClassName: windows-2019`
|
||||
2. 集群管理员运行 `kubectl create -f runtimeClasses.yml` 操作
|
||||
3. 根据需要向 Pod 规约中添加 `runtimeClassName: windows-2019`
|
||||
|
||||
<!--
|
||||
For example:
|
||||
|
|
@ -361,8 +376,3 @@ spec:
|
|||
selector:
|
||||
app: iis-2019
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
[RuntimeClass]: https://kubernetes.io/docs/concepts/containers/runtime-class/
|
||||
|
|
|
|||
|
|
@ -1,12 +1,5 @@
|
|||
---
|
||||
reviewers:
|
||||
- sig-api-machinery
|
||||
- sig-architecture
|
||||
- sig-cli
|
||||
- sig-cluster-lifecycle
|
||||
- sig-node
|
||||
- sig-release
|
||||
title: Kubernetes 版本及版本倾斜支持策略
|
||||
title: Kubernetes 版本及版本偏差支持策略
|
||||
content_type: concept
|
||||
weight: 30
|
||||
---
|
||||
|
|
@ -16,7 +9,7 @@ weight: 30
|
|||
This document describes the maximum version skew supported between various Kubernetes components.
|
||||
Specific cluster deployment tools may place additional restrictions on version skew.
|
||||
-->
|
||||
本文描述 Kubernetes 各组件之间版本倾斜支持策略。
|
||||
本文描述 Kubernetes 各组件之间版本偏差支持策略。
|
||||
特定的集群部署工具可能会有额外的限制。
|
||||
|
||||
|
||||
|
|
@ -34,7 +27,7 @@ For more information, see [Kubernetes Release Versioning](https://github.com/kub
|
|||
-->
|
||||
Kubernetes 版本号格式为 **x.y.z**，其中 **x** 为大版本号，**y** 为小版本号，**z** 为补丁版本号。
|
||||
版本号格式遵循 [Semantic Versioning](https://semver.org/) 规则。
|
||||
更多信息，请参阅 [Kubernetes Release Versioning](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/release/versioning.md#kubernetes-release-versioning)。
|
||||
更多信息，请参阅 [Kubernetes 发布版本](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/release/versioning.md#kubernetes-release-versioning)。
|
||||
|
||||
<!--
|
||||
The Kubernetes project maintains release branches for the most recent three minor releases.
|
||||
|
|
@ -48,9 +41,11 @@ This decision is owned by the [patch release manager](https://github.com/kuberne
|
|||
The patch release manager is a member of the [release team for each release](https://github.com/kubernetes/sig-release/tree/master/release-team).
|
||||
-->
|
||||
一些 bug 修复，包括安全修复，根据其安全性和可用性，有可能会回合到这些分支。
|
||||
补丁版本会定期或根据需要从这些分支中发布。
|
||||
最终是否发布是由[patch release team](https://github.com/kubernetes/sig-release/blob/master/release-engineering/role-handbooks/patch-release-manager.md#release-timing)
|
||||
来决定的。Patch release team同时也是[release managers](https://github.com/kubernetes/sig-release/blob/master/release-managers.md). 如需了解更多信息，请查看 [Kubernetes Patch releases](https://github.com/kubernetes/sig-release/blob/master/releases/patch-releases.md).
|
||||
补丁版本会定期或根据需要从这些分支中发布。 最终是否发布是由
|
||||
[补丁发布团队](https://github.com/kubernetes/sig-release/blob/master/release-engineering/role-handbooks/patch-release-manager.md#release-timing)
|
||||
来决定的。补丁发布团队同时也是
|
||||
[发布管理者](https://github.com/kubernetes/sig-release/blob/master/release-managers.md)。
|
||||
如需了解更多信息，请查看 [Kubernetes 补丁发布](https://github.com/kubernetes/sig-release/blob/master/releases/patch-releases.md)。
|
||||
|
||||
<!--
|
||||
Minor releases occur approximately every 3 months, so each minor release branch is maintained for approximately 9 months.
|
||||
|
|
@ -60,14 +55,14 @@ Minor releases occur approximately every 3 months, so each minor release branch
|
|||
<!--
|
||||
## Supported version skew
|
||||
-->
|
||||
## 版本倾斜策略
|
||||
## 版本偏差策略
|
||||
|
||||
### kube-apiserver
|
||||
|
||||
<!--
|
||||
In [highly-available (HA) clusters](/docs/setup/production-environment/tools/kubeadm/high-availability/), the newest and oldest `kube-apiserver` instances must be within one minor version.
|
||||
-->
|
||||
在 [高可用（HA）集群](/docs/setup/production-environment/tools/kubeadm/high-availability/) 中，
|
||||
在 [高可用（HA）集群](/zh/docs/setup/production-environment/tools/kubeadm/high-availability/) 中，
|
||||
多个 `kube-apiserver` 实例小版本号最多差1。
|
||||
|
||||
<!--
|
||||
|
|
@ -100,10 +95,11 @@ Example:
|
|||
* `kube-apiserver` 版本号如果是 **1.13**
|
||||
* `kubelet` 只能是 **1.13** 、 **1.12** 和 **1.11**
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
If version skew exists between `kube-apiserver` instances in an HA cluster, this narrows the allowed `kubelet` versions.-->如果
|
||||
HA集群中多个 `kube-apiserver` 实例版本号不一致，相应的 `kubelet` 版本号可选范围也要减小。
|
||||
If version skew exists between `kube-apiserver` instances in an HA cluster, this narrows the allowed `kubelet` versions.
|
||||
-->
|
||||
{{< note >}}
|
||||
如果 HA 集群中多个 `kube-apiserver` 实例版本号不一致，相应的 `kubelet` 版本号可选范围也要减小。
|
||||
{{</ note >}}
|
||||
|
||||
<!--
|
||||
|
|
@ -139,9 +135,11 @@ Example:
|
|||
* 如果 `kube-apiserver` 版本号为 **1.13**
|
||||
* `kube-controller-manager`、`kube-scheduler` 和 `cloud-controller-manager` 版本支持 **1.13** 和 **1.12**
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
If version skew exists between `kube-apiserver` instances in an HA cluster, and these components can communicate with any `kube-apiserver` instance in the cluster (for example, via a load balancer), this narrows the allowed versions of these components.-->如果在 HA 集群中，多个 `kube-apiserver` 实例版本号不一致，他们也可以跟任意一个 `kube-apiserver` 实例通信（例如，通过 load balancer），
|
||||
If version skew exists between `kube-apiserver` instances in an HA cluster, and these components can communicate with any `kube-apiserver` instance in the cluster (for example, via a load balancer), this narrows the allowed versions of these components.
|
||||
-->
|
||||
{{< note >}}
|
||||
如果在 HA 集群中，多个 `kube-apiserver` 实例版本号不一致，他们也可以跟任意一个 `kube-apiserver` 实例通信（例如，通过 load balancer），
|
||||
但 `kube-controller-manager`、`kube-scheduler` 和 `cloud-controller-manager` 版本可用范围会相应的减小。
|
||||
{{< /note >}}
|
||||
|
||||
|
|
@ -176,9 +174,10 @@ Example:
|
|||
* 如果 `kube-apiserver` 当前是 **1.13** 版本
|
||||
* `kubectl` 则支持 **1.14** 、**1.13** 和 **1.12**
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
If version skew exists between `kube-apiserver` instances in an HA cluster, this narrows the supported `kubectl` versions.-->
|
||||
If version skew exists between `kube-apiserver` instances in an HA cluster, this narrows the supported `kubectl` versions.
|
||||
-->
|
||||
{{< note >}}
|
||||
如果 HA 集群中的多个 `kube-apiserver` 实例版本号不一致，相应的 `kubectl` 可用版本范围也会减小。
|
||||
{{< /note >}}
|
||||
|
||||
|
|
@ -202,7 +201,7 @@ Example:
|
|||
The supported version skew between components has implications on the order in which components must be upgraded.
|
||||
This section describes the order in which components must be upgraded to transition an existing cluster from version **1.n** to version **1.(n+1)**.
|
||||
-->
|
||||
组件之间支持的版本倾斜会影响组件升级的顺序。
|
||||
组件之间支持的版本偏差会影响组件升级的顺序。
|
||||
本节描述组件从版本 **1.n** 到 **1.(n+1)** 的升级次序。
|
||||
|
||||
### kube-apiserver
|
||||
|
|
@ -226,7 +225,9 @@ Pre-requisites:
|
|||
* `kube-controller-manager`、`kube-scheduler` 和 `cloud-controller-manager` 版本号必须为 **1.n**（确保不高于 API server 的版本，且版本号相差不大于1）
|
||||
* `kubelet` 实例版本号必须是 **1.n** 或 **1.(n-1)**（确保版本号不高于 API server，且版本号相差不大于2）
|
||||
* 注册的 admission 插件必须能够处理新的 `kube-apiserver` 实例发送过来的数据：
|
||||
* `ValidatingWebhookConfiguration` 和 `MutatingWebhookConfiguration` 对象必须升级到可以处理 **1.(n+1)** 版本新加的 REST 资源(或使用1.15版本提供的 [`matchPolicy: Equivalent` 选项](/docs/reference/access-authn-authz/extensible-admission-controllers/#matching-requests-matchpolicy))
|
||||
* `ValidatingWebhookConfiguration` 和 `MutatingWebhookConfiguration` 对象必须升级到可以处理
|
||||
**1.(n+1)** 版本新加的 REST 资源（或使用 1.15 版本提供的
|
||||
[`matchPolicy: Equivalent` 选项](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#matching-requests-matchpolicy)）
|
||||
* 插件可以处理任何 **1.(n+1)** 版本新的 REST 资源数据和新加的字段
|
||||
|
||||
<!--
|
||||
|
|
@ -238,7 +239,10 @@ Upgrade `kube-apiserver` to **1.(n+1)**
|
|||
<!--
|
||||
Project policies for [API deprecation](/docs/reference/using-api/deprecation-policy/) and
|
||||
[API change guidelines](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api_changes.md)
|
||||
require `kube-apiserver` to not skip minor versions when upgrading, even in single-instance clusters.-->跟据 [API deprecation](/docs/reference/using-api/deprecation-policy/) 和 [API change guidelines](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api_changes.md) 规则，
|
||||
require `kube-apiserver` to not skip minor versions when upgrading, even in single-instance clusters.
|
||||
-->
|
||||
跟据 [API 弃用策略](/zh/docs/reference/using-api/deprecation-policy/) 和
|
||||
[API 变更指南](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api_changes.md)，
|
||||
`kube-apiserver` 不能跨小版本号升级，即使是单实例集群也不可以。
|
||||
|
||||
{{< /note >}}
|
||||
|
|
@ -246,7 +250,7 @@ require `kube-apiserver` to not skip minor versions when upgrading, even in sing
|
|||
<!--
|
||||
### kube-controller-manager, kube-scheduler, and cloud-controller-manager
|
||||
-->
|
||||
### kube-controller-manager、 kube-scheduler 和 cloud-controller-manager
|
||||
### kube-controller-manager、kube-scheduler 和 cloud-controller-manager
|
||||
|
||||
<!--
|
||||
Pre-requisites:
|
||||
|
|
@ -277,15 +281,15 @@ Optionally upgrade `kubelet` instances to **1.(n+1)** (or they can be left at **
|
|||
|
||||
`kubelet` 可以升级到 **1.(n+1)**（或者停留在 **1.n** 或 **1.(n-1)**）
|
||||
|
||||
{{< warning >}}
|
||||
<!--
|
||||
Running a cluster with `kubelet` instances that are persistently two minor versions behind `kube-apiserver` is not recommended:
|
||||
-->集群中 `kubelet` 版本号不建议比 `kube-apiserver` 低两个版本号：
|
||||
|
||||
<!--
|
||||
* they must be upgraded within one minor version of `kube-apiserver` before the control plane can be upgraded
|
||||
* it increases the likelihood of running `kubelet` versions older than the three maintained minor releases
|
||||
-->
|
||||
* 他们必须升级到与 `kube-apiserver` 相差不超过1个小版本，才可以升级其他控制面组件
|
||||
* 有可能使用低于3个在维护的小版本
|
||||
{{< warning >}}
|
||||
集群中 `kubelet` 版本号不建议比 `kube-apiserver` 低两个版本号：
|
||||
|
||||
* 它们必须升级到与 `kube-apiserver` 相差不超过 1 个小版本，才可以升级其他控制面组件
|
||||
* 有可能使用低于 3 个在维护的小版本
|
||||
{{</ warning >}}
|
||||
|
|
|
|||
Loading…
Reference in New Issue