From e592fc15f563994761a6662d84fac9c97f854089 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Mon, 7 Sep 2020 20:50:06 +0800 Subject: [PATCH] [zh] fix links in setup section (3) --- .../on-premises-vm/ovirt.md | 40 ++--- .../tools/kubeadm/self-hosting.md | 47 +++--- .../tools/kubeadm/troubleshooting-kubeadm.md | 155 ++++++++++-------- .../windows/user-guide-windows-containers.md | 148 +++++++++-------- .../docs/setup/release/version-skew-policy.md | 66 ++++---- 5 files changed, 234 insertions(+), 222 deletions(-) diff --git a/content/zh/docs/setup/production-environment/on-premises-vm/ovirt.md b/content/zh/docs/setup/production-environment/on-premises-vm/ovirt.md index ea8790f452..5d9c3fdd10 100644 --- a/content/zh/docs/setup/production-environment/on-premises-vm/ovirt.md +++ b/content/zh/docs/setup/production-environment/on-premises-vm/ovirt.md @@ -3,13 +3,11 @@ title: oVirt content_type: concept --- @@ -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 主机上，以部署和管理您的虚拟数据中心。 - - -## oVirt 云驱动的部署 - +## 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 发行版也可能可行。 -必须在寄宿系统中 [安装 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。 一旦 Kubernetes 模版可用，就可以开始创建可由云驱动发现的 VM。 - -[导入]: 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/ - ## 使用 oVirt 云驱动 - 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)) diff --git a/content/zh/docs/setup/production-environment/tools/kubeadm/self-hosting.md b/content/zh/docs/setup/production-environment/tools/kubeadm/self-hosting.md index 66444b3101..d02d2b7a0c 100644 --- a/content/zh/docs/setup/production-environment/tools/kubeadm/self-hosting.md +++ b/content/zh/docs/setup/production-environment/tools/kubeadm/self-hosting.md @@ -1,18 +1,12 @@ --- -reviewers: -- sig-cluster-lifecycle title: 配置您的 kubernetes 集群以自托管控制平台 content_type: concept weight: 100 --- @@ -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/)。 -要创建自托管集群，请参见 [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) +命令。 @@ -47,11 +43,11 @@ To create a self-hosted cluster see the --> #### 警告 -{{< caution >}} +{{< 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. 默认情况下，自托管的控制平面 Pod 依赖于从 [`hostPath`](/docs/concepts/storage/volumes/#hostpath) 卷加载的凭据。 -除初始创建外，这些凭据不由 kubeadm 管理。 +2. 默认情况下，自托管的控制平面 Pod 依赖于从 + [`hostPath`](/zh/docs/concepts/storage/volumes/#hostpath) 卷加载的凭据。 + 除初始创建外，这些凭据不由 kubeadm 管理。 -1. 控制平面的自托管部分不包括 etcd，后者仍作为静态 Pod 运行。 +3. 控制平面的自托管部分不包括 etcd，后者仍作为静态 Pod 运行。 -#### 处理 - -自托管引导过程记录在 [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) 中。 -总而言之，`kubeadm alpha 自托管` 的工作原理如下： +总体而言，`kubeadm alpha 自托管` 的工作原理如下： - 1. 使用静态控制平面 Pod 清单来构造一组 DaemonSet 清单，这些清单将运行自托管的控制平面。 + 2. 使用静态控制平面 Pod 清单来构造一组 DaemonSet 清单，这些清单将运行自托管的控制平面。 它还会在必要时修改这些清单，例如添加新的秘密卷。 - 1. 在 `kube-system` 名称空间中创建 DaemonSets ，并等待生成的 Pod 运行。 + 3. 在 `kube-system` 名称空间中创建 DaemonSets ，并等待生成的 Pod 运行。 - 1. 自托管 Pod 运行后，将删除其关联的静态 Pod，然后 kubeadm 继续安装下一个组件。 - 这将触发 kubelet 停止那些静态 Pod 。 + 4. 自托管 Pod 运行后，将删除其关联的静态 Pod，然后 kubeadm 继续安装下一个组件。 + 这将触发 kubelet 停止那些静态 Pod 。 - 1. 当原始静态控制平面停止时，新的自托管控制平面能够绑定到侦听端口并变为活动状态。 - + 5. 当原始静态控制平面停止时，新的自托管控制平面能够绑定到侦听端口并变为活动状态。 diff --git a/content/zh/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md b/content/zh/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md index 43176afae3..a5cf846a30 100644 --- a/content/zh/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md +++ b/content/zh/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md @@ -5,11 +5,9 @@ weight: 20 --- @@ -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`，这样其他人可以帮助你。 @@ -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` 命令来检视每个容器的运行日志。 ## `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`。 ## 无法通过其服务 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 有 `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 >}} +{{< 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 + ``` ## 无法将以逗号分隔的值列表传递给 `--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)。 ## 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- + ``` diff --git a/content/zh/docs/setup/production-environment/windows/user-guide-windows-containers.md b/content/zh/docs/setup/production-environment/windows/user-guide-windows-containers.md index 314b0de627..80a470cfad 100644 --- a/content/zh/docs/setup/production-environment/windows/user-guide-windows-containers.md +++ b/content/zh/docs/setup/production-environment/windows/user-guide-windows-containers.md @@ -1,20 +1,15 @@ --- -reviewers: -- michmike -- patricklang title: Kubernetes 中调度 Windows 容器的指南 content_type: concept weight: 75 --- @@ -22,9 +17,8 @@ weight: 75 -Windows 应用程序构成了许多组织中运行的服务和应用程序的很大一部分。本指南将引导您完成在 Kubernetes 中配置和部署 Windows 容器的步骤。 - - +Windows 应用程序构成了许多组织中运行的服务和应用程序的很大一部分。 +本指南将引导您完成在 Kubernetes 中配置和部署 Windows 容器的步骤。 @@ -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 容器的使用体验。 ## 入门：部署 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 >}} +{{< 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 >}} +{{< 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/)可了解更多信息。 ## 使用组托管服务帐户管理工作负载身份 -从 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 的更多信息。 -目前，用户需要将 Linux 和 Windows 工作负载运行在各自特定的操作系统的节点上，因而需要结合使用污点和节点选择算符。这可能仅给 Windows 用户造成不便。推荐的方法概述如下，其主要目标之一是该方法不应破坏与现有 Linux 工作负载的兼容性。 +目前，用户需要将 Linux 和 Windows 工作负载运行在各自特定的操作系统的节点上， +因而需要结合使用污点和节点选择算符。 这可能仅给 Windows 用户造成不便。 +推荐的方法概述如下，其主要目标之一是该方法不应破坏与现有 Linux 工作负载的兼容性。 -如果 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。 -但是，我们了解到，在许多情况下，用户都有既存的大量的 Linux 容器部署，以及一个现成的配置生态系统，例如社区 Helm charts，以及程序化 Pod 生成案例，例如 Operators。在这些情况下，您可能会不愿意更改配置添加 nodeSelector。替代方法是使用污点。由于 kubelet 可以在注册期间设置污点，因此可以轻松修改它，使其仅在 Windows 上运行时自动添加污点。 +但是，我们了解到，在许多情况下，用户都有既存的大量的 Linux 容器部署，以及一个现成的配置生态系统， +例如社区 Helm charts，以及程序化 Pod 生成案例，例如 Operators。 +在这些情况下，您可能会不愿意更改配置添加 nodeSelector。替代方法是使用污点。 +由于 kubelet 可以在注册期间设置污点，因此可以轻松修改它，使其仅在 Windows 上运行时自动添加污点。 -向所有 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" ``` -Kubernetes 1.17 自动添加了一个新标签 `node.kubernetes.io/windows-build` 来简化此操作。 如果您运行的是旧版本，则建议手动将此标签添加到 Windows 节点。 +Kubernetes 1.17 自动添加了一个新标签 `node.kubernetes.io/windows-build` 来简化此操作。 +如果您运行的是旧版本，则建议手动将此标签添加到 Windows 节点。 此标签反映了需要兼容的 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] 可用于简化使用污点和容忍度的过程。集群管理员可以创建 `RuntimeClass` 对象，用于封装这些污点和容忍度。 - +[RuntimeClass](/zh/docs/concepts/containers/runtime-class/) 可用于简化使用污点和容忍度的过程。 +集群管理员可以创建 `RuntimeClass` 对象，用于封装这些污点和容忍度。 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. 集群管理员运行 `kubectl create -f runtimeClasses.yml` 操作 -1. 根据需要向 Pod 规约中添加 `runtimeClassName: windows-2019` +2. 集群管理员运行 `kubectl create -f runtimeClasses.yml` 操作 +3. 根据需要向 Pod 规约中添加 `runtimeClassName: windows-2019` -本文描述 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)。 一些 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)。 -## 版本倾斜策略 +## 版本偏差策略 ### kube-apiserver -在 [高可用（HA）集群](/docs/setup/production-environment/tools/kubeadm/high-availability/) 中， +在 [高可用（HA）集群](/zh/docs/setup/production-environment/tools/kubeadm/high-availability/) 中， 多个 `kube-apiserver` 实例小版本号最多差1。 如果 -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` 版本号可选范围也要减小。 {{}} 如果在 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. +--> +{{< 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 资源数据和新加的字段 跟据 [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 和 cloud-controller-manager +### kube-controller-manager、kube-scheduler 和 cloud-controller-manager 集群中 `kubelet` 版本号不建议比 `kube-apiserver` 低两个版本号： - -* 他们必须升级到与 `kube-apiserver` 相差不超过1个小版本，才可以升级其他控制面组件 -* 有可能使用低于3个在维护的小版本 +{{< warning >}} +集群中 `kubelet` 版本号不建议比 `kube-apiserver` 低两个版本号： + +* 它们必须升级到与 `kube-apiserver` 相差不超过 1 个小版本，才可以升级其他控制面组件 +* 有可能使用低于 3 个在维护的小版本 {{}}