Switch language name 'zh' to 'zh-cn'
This is the first step to rename 'zh' to 'zh-cn'. There are several reasons why we rename the language name.
- The upstream docsy theme changed the language name, leading to many warnings during site build;
The side-effect is that the i18n strings are no longer working.
- We believe renaming the language is the right thing to do, because this move can make room for other variants of Chinese language, such as 'zh-tw', 'zh-sg' etc.
There would be several follow-ups to this PR, such as fixing the intra-site links, adding redirects etc.
We will lock up changes to zh/zh-cn pages for the moment, until this one gets in.
This PR is based on commit cdad0a7342.
This commit is contained in:
Qiming Teng
@@ -0,0 +1,638 @@
|
||||
---
|
||||
title: 生产环境
|
||||
weight: 30
|
||||
no_list: true
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
A production-quality Kubernetes cluster requires planning and preparation.
|
||||
If your Kubernetes cluster is to run critical workloads, it must be configured to be resilient.
|
||||
This page explains steps you can take to set up a production-ready cluster,
|
||||
or to promote an existing cluster for production use.
|
||||
If you're already familiar with production setup and want the links, skip to
|
||||
[What's next](#what-s-next).
|
||||
-->
|
||||
生产质量的 Kubernetes 集群需要规划和准备。
|
||||
如果你的 Kubernetes 集群是用来运行关键负载的，该集群必须被配置为弹性的（Resilient）。
|
||||
本页面阐述你在安装生产就绪的集群或将现有集群升级为生产用途时可以遵循的步骤。
|
||||
如果你已经熟悉生产环境安装，因此只关注一些链接，则可以跳到[接下来](#what-s-next)节。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
## Production considerations
|
||||
|
||||
Typically, a production Kubernetes cluster environment has more requirements than a
|
||||
personal learning, development, or test environment Kubernetes. A production environment may require
|
||||
secure access by many users, consistent availability, and the resources to adapt
|
||||
to changing demands.
|
||||
-->
|
||||
## 生产环境考量 {#production-considerations}
|
||||
|
||||
通常，一个生产用 Kubernetes 集群环境与个人学习、开发或测试环境所使用的
|
||||
Kubernetes 相比有更多的需求。生产环境可能需要被很多用户安全地访问，需要
|
||||
提供一致的可用性，以及能够与需求变化相适配的资源。
|
||||
|
||||
<!--
|
||||
As you decide where you want your production Kubernetes environment to live
|
||||
(on premises or in a cloud) and the amount of management you want to take
|
||||
on or hand to others, consider how your requirements for a Kubernetes cluster
|
||||
are influenced by the following issues:
|
||||
-->
|
||||
在你决定在何处运行你的生产用 Kubernetes 环境（在本地或者在云端），以及
|
||||
你希望承担或交由他人承担的管理工作量时，需要考察以下因素如何影响你对
|
||||
Kubernetes 集群的需求：
|
||||
|
||||
<!--
|
||||
- *Availability*: A single-machine Kubernetes [learning environment](/docs/setup/#learning-environment)
|
||||
has a single point of failure. Creating a highly available cluster means considering:
|
||||
- Separating the control plane from the worker nodes.
|
||||
- Replicating the control plane components on multiple nodes.
|
||||
- Load balancing traffic to the cluster’s {{< glossary_tooltip term_id="kube-apiserver" text="API server" >}}.
|
||||
- Having enough worker nodes available, or able to quickly become available, as changing workloads warrant it.
|
||||
-->
|
||||
- *可用性*：一个单机的 Kubernetes [学习环境](/zh/docs/setup/#学习环境)
|
||||
具有单点失效特点。创建高可用的集群则意味着需要考虑：
|
||||
- 将控制面与工作节点分开
|
||||
- 在多个节点上提供控制面组件的副本
|
||||
- 为针对集群的 {{< glossary_tooltip term_id="kube-apiserver" text="API 服务器" >}}
|
||||
的流量提供负载均衡
|
||||
- 随着负载的合理需要，提供足够的可用的（或者能够迅速变为可用的）工作节点
|
||||
|
||||
<!--
|
||||
- *Scale*: If you expect your production Kubernetes environment to receive a stable amount of
|
||||
demand, you might be able to set up for the capacity you need and be done. However,
|
||||
if you expect demand to grow over time or change dramatically based on things like
|
||||
season or special events, you need to plan how to scale to relieve increased
|
||||
pressure from more requests to the control plane and worker nodes or scale down to reduce unused
|
||||
resources.
|
||||
-->
|
||||
- *规模*：如果你预期你的生产用 Kubernetes 环境要承受固定量的请求，
|
||||
你可能可以针对所需要的容量来一次性完成安装。
|
||||
不过，如果你预期服务请求会随着时间增长，或者因为类似季节或者特殊事件的
|
||||
原因而发生剧烈变化，你就需要规划如何处理请求上升时对控制面和工作节点
|
||||
的压力，或者如何缩减集群规模以减少未使用资源的消耗。
|
||||
|
||||
<!--
|
||||
- *Security and access management*: You have full admin privileges on your own
|
||||
Kubernetes learning cluster. But shared clusters with important workloads, and
|
||||
more than one or two users, require a more refined approach to who and what can
|
||||
access cluster resources. You can use role-based access control
|
||||
([RBAC](/docs/reference/access-authn-authz/rbac/)) and other
|
||||
security mechanisms to make sure that users and workloads can get access to the
|
||||
resources they need, while keeping workloads, and the cluster itself, secure.
|
||||
You can set limits on the resources that users and workloads can access
|
||||
by managing [policies](/docs/concepts/policy/) and
|
||||
[container resources](/docs/concepts/configuration/manage-resources-containers/).
|
||||
-->
|
||||
- *安全性与访问管理*：在你自己的学习环境 Kubernetes 集群上，你拥有完全的管理员特权。
|
||||
但是针对运行着重要工作负载的共享集群，用户账户不止一两个时，就需要更细粒度
|
||||
的方案来确定谁或者哪些主体可以访问集群资源。
|
||||
你可以使用基于角色的访问控制（[RBAC](/zh/docs/reference/access-authn-authz/rbac/)）
|
||||
和其他安全机制来确保用户和负载能够访问到所需要的资源，同时确保工作负载及集群
|
||||
自身仍然是安全的。
|
||||
你可以通过管理[策略](/zh/docs/concets/policy/)和
|
||||
[容器资源](/zh/docs/concepts/configuration/manage-resources-containers)来
|
||||
针对用户和工作负载所可访问的资源设置约束，
|
||||
|
||||
<!--
|
||||
Before building a Kubernetes production environment on your own, consider
|
||||
handing off some or all of this job to
|
||||
[Turnkey Cloud Solutions](/docs/setup/production-environment/turnkey-solutions/)
|
||||
providers or other [Kubernetes Partners](https://kubernetes.io/partners/).
|
||||
Options include:
|
||||
-->
|
||||
在自行构造 Kubernetes 生产环境之前，请考虑将这一任务的部分或者全部交给
|
||||
[云方案承包服务](/zh/docs/setup/production-environment/turnkey-solutions)
|
||||
提供商或者其他 [Kubernetes 合作伙伴](https://kubernetes.io/partners/)。
|
||||
选项有：
|
||||
|
||||
<!--
|
||||
- *Serverless*: Just run workloads on third-party equipment without managing
|
||||
a cluster at all. You will be charged for things like CPU usage, memory, and
|
||||
disk requests.
|
||||
- *Managed control plane*: Let the provider manage the scale and availability
|
||||
of the cluster's control plane, as well as handle patches and upgrades.
|
||||
- *Managed worker nodes*: Configure pools of nodes to meet your needs,
|
||||
then the provider makes sure those nodes are available and ready to implement
|
||||
upgrades when needed.
|
||||
- *Integration*: There are providers that integrate Kubernetes with other
|
||||
services you may need, such as storage, container registries, authentication
|
||||
methods, and development tools.
|
||||
-->
|
||||
- *无服务*：仅是在第三方设备上运行负载，完全不必管理集群本身。你需要为
|
||||
CPU 用量、内存和磁盘请求等付费。
|
||||
- *托管控制面*：让供应商决定集群控制面的规模和可用性，并负责打补丁和升级等操作。
|
||||
- *托管工作节点*：配置一个节点池来满足你的需要，由供应商来确保节点始终可用，
|
||||
并在需要的时候完成升级。
|
||||
- *集成*：有一些供应商能够将 Kubernetes 与一些你可能需要的其他服务集成，
|
||||
这类服务包括存储、容器镜像仓库、身份认证方法以及开发工具等。
|
||||
|
||||
<!--
|
||||
Whether you build a production Kubernetes cluster yourself or work with
|
||||
partners, review the following sections to evaluate your needs as they relate
|
||||
to your cluster’s *control plane*, *worker nodes*, *user access*, and
|
||||
*workload resources*.
|
||||
-->
|
||||
无论你是自行构造一个生产用 Kubernetes 集群还是与合作伙伴一起协作，请审阅
|
||||
下面章节以评估你的需求，因为这关系到你的集群的 *控制面*、*工作节点*、
|
||||
*用户访问* 以及 *负载资源*。
|
||||
|
||||
<!--
|
||||
## Production cluster setup
|
||||
|
||||
In a production-quality Kubernetes cluster, the control plane manages the
|
||||
cluster from services that can be spread across multiple computers
|
||||
in different ways. Each worker node, however, represents a single entity that
|
||||
is configured to run Kubernetes pods.
|
||||
-->
|
||||
## 生产用集群安装 {#production-cluster-setup}
|
||||
|
||||
在生产质量的 Kubernetes 集群中，控制面用不同的方式来管理集群和可以
|
||||
分布到多个计算机上的服务。每个工作节点则代表的是一个可配置来运行
|
||||
Kubernetes Pods 的实体。
|
||||
|
||||
<!--
|
||||
### Production control plane
|
||||
|
||||
The simplest Kubernetes cluster has the entire control plane and worker node
|
||||
services running on the same machine. You can grow that environment by adding
|
||||
worker nodes, as reflected in the diagram illustrated in
|
||||
[Kubernetes Components](/docs/concepts/overview/components/).
|
||||
If the cluster is meant to be available for a short period of time, or can be
|
||||
discarded if something goes seriously wrong, this might meet your needs.
|
||||
-->
|
||||
### 生产用控制面 {#production-control-plane}
|
||||
|
||||
最简单的 Kubernetes 集群中，整个控制面和工作节点服务都运行在同一台机器上。
|
||||
你可以通过添加工作节点来提升环境能力，正如
|
||||
[Kubernetes 组件](/zh/docs/concepts/overview/components/)示意图所示。
|
||||
如果只需要集群在很短的一段时间内可用，或者可以在某些事物出现严重问题时直接丢弃，
|
||||
这种配置可能符合你的需要。
|
||||
|
||||
<!--
|
||||
If you need a more permanent, highly available cluster, however, you should
|
||||
consider ways of extending the control plane. By design, one-machine control
|
||||
plane services running on a single machine are not highly available.
|
||||
If keeping the cluster up and running
|
||||
and ensuring that it can be repaired if something goes wrong is important,
|
||||
consider these steps:
|
||||
-->
|
||||
如果你需要一个更为持久的、高可用的集群，那么你就需要考虑扩展控制面的方式。
|
||||
根据设计，运行在一台机器上的单机控制面服务不是高可用的。
|
||||
如果保持集群处于运行状态并且需要确保在出现问题时能够被修复这点很重要，
|
||||
可以考虑以下步骤：
|
||||
|
||||
<!--
|
||||
- *Choose deployment tools*: You can deploy a control plane using tools such
|
||||
as kubeadm, kops, and kubespray. See
|
||||
[Installing Kubernetes with deployment tools](/docs/setup/production-environment/tools/)
|
||||
to learn tips for production-quality deployments using each of those deployment
|
||||
methods. Different [Container Runtimes](/docs/setup/production-environment/container-runtimes/)
|
||||
are available to use with your deployments.
|
||||
-->
|
||||
- *选择部署工具*：你可以使用类似 kubeadm、kops 和 kubespray 这类工具来部署控制面。
|
||||
参阅[使用部署工具安装 Kubernetes](/zh/docs/setup/production-environment/tools/)
|
||||
以了解使用这类部署方法来完成生产就绪部署的技巧。
|
||||
存在不同的[容器运行时](/zh/docs/setup/production-environment/container-runtimes/)
|
||||
可供你的部署采用。
|
||||
<!--
|
||||
- *Manage certificates*: Secure communications between control plane services
|
||||
are implemented using certificates. Certificates are automatically generated
|
||||
during deployment or you can generate them using your own certificate authority.
|
||||
See [PKI certificates and requirements](/docs/setup/best-practices/certificates/) for details.
|
||||
-->
|
||||
- *管理证书*：控制面服务之间的安全通信是通过证书来完成的。证书是在部署期间
|
||||
自动生成的，或者你也可以使用你自己的证书机构来生成它们。
|
||||
参阅 [PKI 证书和需求](/zh/docs/setup/best-practices/certificates/)了解细节。
|
||||
<!--
|
||||
- *Configure load balancer for apiserver*: Configure a load balancer
|
||||
to distribute external API requests to the apiserver service instances running on different nodes. See
|
||||
[Create an External Load Balancer](/docs/tasks/access-application-cluster/create-external-load-balancer/)
|
||||
for details.
|
||||
-->
|
||||
- *为 API 服务器配置负载均衡*：配置负载均衡器来将外部的 API 请求散布给运行在
|
||||
不同节点上的 API 服务实例。参阅
|
||||
[创建外部负载均衡器](/zh/docs/access-application-cluster/create-external-load-balancer/)
|
||||
了解细节。
|
||||
<!--
|
||||
- *Separate and backup etcd service*: The etcd services can either run on the
|
||||
same machines as other control plane services or run on separate machines, for
|
||||
extra security and availability. Because etcd stores cluster configuration data,
|
||||
backing up the etcd database should be done regularly to ensure that you can
|
||||
repair that database if needed.
|
||||
See the [etcd FAQ](https://etcd.io/docs/v3.4/faq/) for details on configuring and using etcd.
|
||||
See [Operating etcd clusters for Kubernetes](/docs/tasks/administer-cluster/configure-upgrade-etcd/)
|
||||
and [Set up a High Availability etcd cluster with kubeadm](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/)
|
||||
for details.
|
||||
-->
|
||||
- *分离并备份 etcd 服务*：etcd 服务可以运行于其他控制面服务所在的机器上，
|
||||
也可以运行在不同的机器上以获得更好的安全性和可用性。
|
||||
因为 etcd 存储着集群的配置数据，应该经常性地对 etcd 数据库进行备份，
|
||||
以确保在需要的时候你可以修复该数据库。与配置和使用 etcd 相关的细节可参阅
|
||||
[etcd FAQ](/https://etcd.io/docs/v3.4/faq/)。
|
||||
更多的细节可参阅[为 Kubernetes 运维 etcd 集群](/zh/docs/tasks/administer-cluster/configure-upgrade-etcd/)
|
||||
和[使用 kubeadm 配置高可用的 etcd 集群](/zh/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/)。
|
||||
<!--
|
||||
- *Create multiple control plane systems*: For high availability, the
|
||||
control plane should not be limited to a single machine. If the control plane
|
||||
services are run by an init service (such as systemd), each service should run on at
|
||||
least three machines. However, running control plane services as pods in
|
||||
Kubernetes ensures that the replicated number of services that you request
|
||||
will always be available.
|
||||
The scheduler should be fault tolerant,
|
||||
but not highly available. Some deployment tools set up [Raft](https://raft.github.io/)
|
||||
consensus algorithm to do leader election of Kubernetes services. If the
|
||||
primary goes away, another service elects itself and take over.
|
||||
-->
|
||||
- *创建多控制面系统*：为了实现高可用性，控制面不应被限制在一台机器上。
|
||||
如果控制面服务是使用某 init 服务（例如 systemd）来运行的，每个服务应该
|
||||
至少运行在三台机器上。不过，将控制面作为服务运行在 Kubernetes Pods
|
||||
中可以确保你所请求的个数的服务始终保持可用。
|
||||
调度器应该是可容错的，但不是高可用的。
|
||||
某些部署工具会安装 [Raft](https://raft.github.io/) 票选算法来对 Kubernetes
|
||||
服务执行领导者选举。如果主节点消失，另一个服务会被选中并接手相应服务。
|
||||
<!--
|
||||
- *Span multiple zones*: If keeping your cluster available at all times is
|
||||
critical, consider creating a cluster that runs across multiple data centers,
|
||||
referred to as zones in cloud environments. Groups of zones are referred to as regions.
|
||||
By spreading a cluster across
|
||||
multiple zones in the same region, it can improve the chances that your
|
||||
cluster will continue to function even if one zone becomes unavailable.
|
||||
See [Running in multiple zones](/docs/setup/best-practices/multiple-zones/) for details.
|
||||
-->
|
||||
- *跨多个可用区*：如果保持你的集群一直可用这点非常重要，可以考虑创建一个跨
|
||||
多个数据中心的集群；在云环境中，这些数据中心被视为可用区。
|
||||
若干个可用区在一起可构成地理区域。
|
||||
通过将集群分散到同一区域中的多个可用区内，即使某个可用区不可用，整个集群
|
||||
能够继续工作的机会也大大增加。
|
||||
更多的细节可参阅[跨多个可用区运行](/zh/docs/setup/best-practices/multiple-zones/)。
|
||||
<!--
|
||||
- *Manage on-going features*: If you plan to keep your cluster over time,
|
||||
there are tasks you need to do to maintain its health and security. For example,
|
||||
if you installed with kubeadm, there are instructions to help you with
|
||||
[Certificate Management](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/)
|
||||
and [Upgrading kubeadm clusters](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/).
|
||||
See [Administer a Cluster](/docs/tasks/administer-cluster/)
|
||||
for a longer list of Kubernetes administrative tasks.
|
||||
-->
|
||||
- *管理演进中的特性*：如果你计划长时间保留你的集群，就需要执行一些维护其
|
||||
健康和安全的任务。例如，如果你采用 kubeadm 安装的集群，则有一些可以帮助你完成
|
||||
[证书管理](/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/)
|
||||
和[升级 kubeadm 集群](/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade)
|
||||
的指令。
|
||||
参见[管理集群](/zh/docs/tasks/administer-cluster)了解一个 Kubernetes
|
||||
管理任务的较长列表。
|
||||
|
||||
<!--
|
||||
To learn about available options when you run control plane services, see
|
||||
[kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/),
|
||||
[kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/),
|
||||
and [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/)
|
||||
component pages. For highly available control plane examples, see
|
||||
[Options for Highly Available topology](/docs/setup/production-environment/tools/kubeadm/ha-topology/),
|
||||
[Creating Highly Available clusters with kubeadm](/docs/setup/production-environment/tools/kubeadm/high-availability/),
|
||||
and [Operating etcd clusters for Kubernetes](/docs/tasks/administer-cluster/configure-upgrade-etcd/).
|
||||
See [Backing up an etcd cluster](/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster)
|
||||
for information on making an etcd backup plan.
|
||||
-->
|
||||
要了解运行控制面服务时可使用的选项，可参阅
|
||||
[kube-apiserver](/zh/docs/reference/command-line-tools-reference/kube-apiserver/)、
|
||||
[kube-controller-manager](/zh/docs/reference/command-line-tools-reference/kube-controller-manager/) 和
|
||||
[kube-scheduler](/zh/docs/reference/command-line-tools-reference/kube-scheduler/)
|
||||
组件参考页面。
|
||||
如要了解高可用控制面的例子，可参阅
|
||||
[高可用拓扑结构选项](/zh/docs/setup/production-environment/tools/kubeadm/ha-topology/)、
|
||||
[使用 kubeadm 创建高可用集群](/zh/docs/setup/production-environment/tools/kubeadm/high-availability/) 以及[为 Kubernetes 运维 etcd 集群](/zh/docs/tasks/administer-cluster/configure-upgrade-etcd/)。
|
||||
关于制定 etcd 备份计划，可参阅
|
||||
[对 etcd 集群执行备份](/zh/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster)。
|
||||
|
||||
<!--
|
||||
### Production worker nodes
|
||||
|
||||
Production-quality workloads need to be resilient and anything they rely
|
||||
on needs to be resilient (such as CoreDNS). Whether you manage your own
|
||||
control plane or have a cloud provider do it for you, you still need to
|
||||
consider how you want to manage your worker nodes (also referred to
|
||||
simply as *nodes*).
|
||||
-->
|
||||
### 生产用工作节点
|
||||
|
||||
生产质量的工作负载需要是弹性的；它们所依赖的其他组件（例如 CoreDNS）也需要是弹性的。
|
||||
无论你是自行管理控制面还是让云供应商来管理，你都需要考虑如何管理工作节点
|
||||
（有时也简称为*节点*）。
|
||||
|
||||
<!--
|
||||
- *Configure nodes*: Nodes can be physical or virtual machines. If you want to
|
||||
create and manage your own nodes, you can install a supported operating system,
|
||||
then add and run the appropriate
|
||||
[Node services](/docs/concepts/overview/components/#node-components). Consider:
|
||||
-->
|
||||
- *配置节点*：节点可以是物理机或者虚拟机。如果你希望自行创建和管理节点，
|
||||
你可以安装一个受支持的操作系统，之后添加并运行合适的
|
||||
[节点服务](/zh/docs/concepts/overview/components/#node-components)。
|
||||
考虑：
|
||||
<!--
|
||||
- The demands of your workloads when you set up nodes by having appropriate memory, CPU, and disk speed and storage capacity available.
|
||||
- Whether generic computer systems will do or you have workloads that need GPU processors, Windows nodes, or VM isolation.
|
||||
-->
|
||||
- 在安装节点时要通过配置适当的内存、CPU 和磁盘速度、存储容量来满足
|
||||
你的负载的需求。
|
||||
- 是否通用的计算机系统即足够，还是你有负载需要使用 GPU 处理器、Windows 节点
|
||||
或者 VM 隔离。
|
||||
<!--
|
||||
- *Validate nodes*: See [Valid node setup](/docs/setup/best-practices/node-conformance/)
|
||||
for information on how to ensure that a node meets the requirements to join
|
||||
a Kubernetes cluster.
|
||||
-->
|
||||
- *验证节点*：参阅[验证节点配置](/zh/docs/setup/best-practices/node-conformance/)
|
||||
以了解如何确保节点满足加入到 Kubernetes 集群的需求。
|
||||
<!--
|
||||
- *Add nodes to the cluster*: If you are managing your own cluster you can
|
||||
add nodes by setting up your own machines and either adding them manually or
|
||||
having them register themselves to the cluster’s apiserver. See the
|
||||
[Nodes](/docs/concepts/architecture/nodes/) section for information on how to set up Kubernetes to add nodes in these ways.
|
||||
-->
|
||||
- *添加节点到集群中*：如果你自行管理你的集群，你可以通过安装配置你的机器，
|
||||
之后或者手动加入集群，或者让它们自动注册到集群的 API 服务器。参阅
|
||||
[节点](/zh/docs/concepts/architecture/nodes/)节，了解如何配置 Kubernetes
|
||||
以便以这些方式来添加节点。
|
||||
<!--
|
||||
- *Add Windows nodes to the cluster*: Kubernetes offers support for Windows
|
||||
worker nodes, allowing you to run workloads implemented in Windows containers. See
|
||||
[Windows in Kubernetes](/docs/setup/production-environment/windows/) for details.
|
||||
-->
|
||||
- *向集群中添加 Windows 节点*：Kubernetes 提供对 Windows 工作节点的支持；
|
||||
这使得你可以运行实现于 Windows 容器内的工作负载。参阅
|
||||
[Kubernetes 中的 Windows](/zh/docs/setup/production-environment/windows/)
|
||||
了解进一步的详细信息。
|
||||
<!--
|
||||
- *Scale nodes*: Have a plan for expanding the capacity your cluster will
|
||||
eventually need. See [Considerations for large clusters](/docs/setup/best-practices/cluster-large/)
|
||||
to help determine how many nodes you need, based on the number of pods and
|
||||
containers you need to run. If you are managing nodes yourself, this can mean
|
||||
purchasing and installing your own physical equipment.
|
||||
-->
|
||||
- *扩缩节点*：制定一个扩充集群容量的规划，你的集群最终会需要这一能力。
|
||||
参阅[大规模集群考察事项](/zh/docs/setup/best-practices/cluster-large/)
|
||||
以确定你所需要的节点数；这一规模是基于你要运行的 Pod 和容器个数来确定的。
|
||||
如果你自行管理集群节点，这可能意味着要购买和安装你自己的物理设备。
|
||||
<!--
|
||||
- *Autoscale nodes*: Most cloud providers support
|
||||
[Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#readme)
|
||||
to replace unhealthy nodes or grow and shrink the number of nodes as demand requires. See the
|
||||
[Frequently Asked Questions](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md)
|
||||
for how the autoscaler works and
|
||||
[Deployment](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#deployment)
|
||||
for how it is implemented by different cloud providers. For on-premises, there
|
||||
are some virtualization platforms that can be scripted to spin up new nodes
|
||||
based on demand.
|
||||
-->
|
||||
- *节点自动扩缩容*：大多数云供应商支持
|
||||
[集群自动扩缩器（Cluster Autoscaler）](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#readme)
|
||||
以便替换不健康的节点、根据需求来增加或缩减节点个数。参阅
|
||||
[常见问题](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md)
|
||||
了解自动扩缩器的工作方式，并参阅
|
||||
[Deployment](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#deployment)
|
||||
了解不同云供应商是如何实现集群自动扩缩器的。
|
||||
对于本地集群，有一些虚拟化平台可以通过脚本来控制按需启动新节点。
|
||||
<!--
|
||||
- *Set up node health checks*: For important workloads, you want to make sure
|
||||
that the nodes and pods running on those nodes are healthy. Using the
|
||||
[Node Problem Detector](/docs/tasks/debug/debug-cluster/monitor-node-health/)
|
||||
daemon, you can ensure your nodes are healthy.
|
||||
-->
|
||||
- *安装节点健康检查*：对于重要的工作负载，你会希望确保节点以及在节点上
|
||||
运行的 Pod 处于健康状态。通过使用
|
||||
[Node Problem Detector](/zh/docs/tasks/debug/debug-cluster/monitor-node-health/)，
|
||||
你可以确保你的节点是健康的。
|
||||
|
||||
<!--
|
||||
## Production user management
|
||||
|
||||
In production, you may be moving from a model where you or a small group of
|
||||
people are accessing the cluster to where there may potentially be dozens or
|
||||
hundreds of people. In a learning environment or platform prototype, you might have a single
|
||||
administrative account for everything you do. In production, you will want
|
||||
more accounts with different levels of access to different namespaces.
|
||||
-->
|
||||
### 生产级用户环境
|
||||
|
||||
在生产环境中，情况可能不再是你或者一小组人在访问集群，而是几十
|
||||
上百人需要访问集群。在学习环境或者平台原型环境中，你可能具有一个
|
||||
可以执行任何操作的管理账号。在生产环境中，你可需要对不同名字空间
|
||||
具有不同访问权限级别的很多账号。
|
||||
|
||||
<!--
|
||||
Taking on a production-quality cluster means deciding how you
|
||||
want to selectively allow access by other users. In particular, you need to
|
||||
select strategies for validating the identities of those who try to access your
|
||||
cluster (authentication) and deciding if they have permissions to do what they
|
||||
are asking (authorization):
|
||||
-->
|
||||
建立一个生产级别的集群意味着你需要决定如何有选择地允许其他用户访问集群。
|
||||
具体而言，你需要选择验证尝试访问集群的人的身份标识（身份认证），并确定
|
||||
他们是否被许可执行他们所请求的操作（鉴权）：
|
||||
|
||||
<!--
|
||||
- *Authentication*: The apiserver can authenticate users using client
|
||||
certificates, bearer tokens, an authenticating proxy, or HTTP basic auth.
|
||||
You can choose which authentication methods you want to use.
|
||||
Using plugins, the apiserver can leverage your organization’s existing
|
||||
authentication methods, such as LDAP or Kerberos. See
|
||||
[Authentication](/docs/reference/access-authn-authz/authentication/)
|
||||
for a description of these different methods of authenticating Kubernetes users.
|
||||
-->
|
||||
- *认证（Authentication）*：API 服务器可以使用客户端证书、持有者令牌、身份
|
||||
认证代理或者 HTTP 基本认证机制来完成身份认证操作。
|
||||
你可以选择你要使用的认证方法。通过使用插件，API 服务器可以充分利用你所在
|
||||
组织的现有身份认证方法，例如 LDAP 或者 Kerberos。
|
||||
关于认证 Kubernetes 用户身份的不同方法的描述，可参阅
|
||||
[身份认证](/zh/docs/reference/access-authn-authz/authentication/)。
|
||||
<!--
|
||||
- *Authorization*: When you set out to authorize your regular users, you will probably choose between RBAC and ABAC authorization. See [Authorization Overview](/docs/reference/access-authn-authz/authorization/) to review different modes for authorizing user accounts (as well as service account access to your cluster):
|
||||
-->
|
||||
- *鉴权（Authorization）*：当你准备为一般用户执行权限判定时，你可能会需要
|
||||
在 RBAC 和 ABAC 鉴权机制之间做出选择。参阅
|
||||
[鉴权概述](/zh/docs/reference/access-authn-authz/authorization/)，了解
|
||||
对用户账户（以及访问你的集群的服务账户）执行鉴权的不同模式。
|
||||
<!--
|
||||
- *Role-based access control* ([RBAC](/docs/reference/access-authn-authz/rbac/)): Lets you assign access to your cluster by allowing specific sets of permissions to authenticated users. Permissions can be assigned for a specific namespace (Role) or across the entire cluster (ClusterRole). Then using RoleBindings and ClusterRoleBindings, those permissions can be attached to particular users.
|
||||
-->
|
||||
- *基于角色的访问控制*（[RBAC](/zh/docs/reference/access-authn-authz/rbac/)）：
|
||||
让你通过为通过身份认证的用户授权特定的许可集合来控制集群访问。
|
||||
访问许可可以针对某特定名字空间（Role）或者针对整个集群（ClusterRole）。
|
||||
通过使用 RoleBinding 和 ClusterRoleBinding 对象，这些访问许可可以被
|
||||
关联到特定的用户身上。
|
||||
<!--
|
||||
- *Attribute-based access control* ([ABAC](/docs/reference/access-authn-authz/abac/)): Lets you create policies based on resource attributes in the cluster and will allow or deny access based on those attributes. Each line of a policy file identifies versioning properties (apiVersion and kind) and a map of spec properties to match the subject (user or group), resource property, non-resource property (/version or /apis), and readonly. See [Examples](/docs/reference/access-authn-authz/abac/#examples) for details.
|
||||
-->
|
||||
- *基于属性的访问控制*（[ABAC](/zh/docs/reference/access-authn-authz/abac/)）：
|
||||
让你能够基于集群中资源的属性来创建访问控制策略，基于对应的属性来决定
|
||||
允许还是拒绝访问。策略文件的每一行都给出版本属性（apiVersion 和 kind）
|
||||
以及一个规约属性的映射，用来匹配主体（用户或组）、资源属性、非资源属性
|
||||
（/version 或 /apis）和只读属性。
|
||||
参阅[示例](/zh/docs/reference/access-authn-authz/abac/#examples)以了解细节。
|
||||
|
||||
<!--
|
||||
As someone setting up authentication and authorization on your production Kubernetes cluster, here are some things to consider:
|
||||
-->
|
||||
作为在你的生产用 Kubernetes 集群中安装身份认证和鉴权机制的负责人，
|
||||
要考虑的事情如下：
|
||||
|
||||
<!--
|
||||
- *Set the authorization mode*: When the Kubernetes API server
|
||||
([kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/))
|
||||
starts, the supported authentication modes must be set using the *--authorization-mode*
|
||||
flag. For example, that flag in the *kube-adminserver.yaml* file (in */etc/kubernetes/manifests*)
|
||||
could be set to Node,RBAC. This would allow Node and RBAC authorization for authenticated requests.
|
||||
-->
|
||||
- *设置鉴权模式*：当 Kubernetes API 服务器
|
||||
（[kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/)）
|
||||
启动时，所支持的鉴权模式必须使用 `--authorization-mode` 标志配置。
|
||||
例如，`kube-apiserver.yaml`（位于 `/etc/kubernetes/manifests` 下）中对应的
|
||||
标志可以设置为 `Node,RBAC`。这样就会针对已完成身份认证的请求执行 Node 和 RBAC
|
||||
鉴权。
|
||||
<!--
|
||||
- *Create user certificates and role bindings (RBAC)*: If you are using RBAC
|
||||
authorization, users can create a CertificateSigningRequest (CSR) that can be
|
||||
signed by the cluster CA. Then you can bind Roles and ClusterRoles to each user.
|
||||
See [Certificate Signing Requests](/docs/reference/access-authn-authz/certificate-signing-requests/)
|
||||
for details.
|
||||
-->
|
||||
- *创建用户证书和角色绑定（RBAC）*：如果你在使用 RBAC 鉴权，用户可以创建
|
||||
由集群 CA 签名的 CertificateSigningRequest（CSR）。接下来你就可以将 Role
|
||||
和 ClusterRole 绑定到每个用户身上。
|
||||
参阅[证书签名请求](/zh/docs/reference/access-authn-authz/certificate-signing-requests/)
|
||||
了解细节。
|
||||
<!--
|
||||
- *Create policies that combine attributes (ABAC)*: If you are using ABAC
|
||||
authorization, you can assign combinations of attributes to form policies to
|
||||
authorize selected users or groups to access particular resources (such as a
|
||||
pod), namespace, or apiGroup. For more information, see
|
||||
[Examples](/docs/reference/access-authn-authz/abac/#examples).
|
||||
-->
|
||||
- *创建组合属性的策略（ABAC）*：如果你在使用 ABAC 鉴权，你可以设置属性组合
|
||||
以构造策略对所选用户或用户组执行鉴权，判定他们是否可访问特定的资源
|
||||
（例如 Pod）、名字空间或者 apiGroup。进一步的详细信息可参阅
|
||||
[示例](/zh/docs/reference/access-authn-authz/abac/#examples)。
|
||||
<!--
|
||||
- *Consider Admission Controllers*: Additional forms of authorization for
|
||||
requests that can come in through the API server include
|
||||
[Webhook Token Authentication](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication).
|
||||
Webhooks and other special authorization types need to be enabled by adding
|
||||
[Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/)
|
||||
to the API server.
|
||||
-->
|
||||
- *考虑准入控制器*：针对指向 API 服务器的请求的其他鉴权形式还包括
|
||||
[Webhook 令牌认证](/zh/docs/reference/access-authn-authz/authentication/#webhook-token-authentication)。
|
||||
Webhook 和其他特殊的鉴权类型需要通过向 API 服务器添加
|
||||
[准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/)
|
||||
来启用。
|
||||
|
||||
<!--
|
||||
## Set limits on workload resources
|
||||
|
||||
Demands from production workloads can cause pressure both inside and outside
|
||||
of the Kubernetes control plane. Consider these items when setting up for the
|
||||
needs of your cluster's workloads:
|
||||
-->
|
||||
## 为负载资源设置约束 {#set-limits-on-workload-resources}
|
||||
|
||||
生产环境负载的需求可能对 Kubernetes 的控制面内外造成压力。
|
||||
在针对你的集群的负载执行配置时，要考虑以下条目：
|
||||
|
||||
<!--
|
||||
- *Set namespace limits*: Set per-namespace quotas on things like memory and CPU. See
|
||||
[Manage Memory, CPU, and API Resources](/docs/tasks/administer-cluster/manage-resources/)
|
||||
for details. You can also set
|
||||
[Hierarchical Namespaces](/blog/2020/08/14/introducing-hierarchical-namespaces/)
|
||||
for inheriting limits.
|
||||
-->
|
||||
- *设置名字空间限制*：为每个名字空间的内存和 CPU 设置配额。
|
||||
参阅[管理内存、CPU 和 API 资源](/zh/docs/tasks/administer-cluster/manage-resources/)
|
||||
以了解细节。你也可以设置
|
||||
[层次化名字空间](/blog/2020/08/14/introducing-hierarchical-namespaces/)
|
||||
来继承这类约束。
|
||||
<!--
|
||||
- *Prepare for DNS demand*: If you expect workloads to massively scale up,
|
||||
your DNS service must be ready to scale up as well. See
|
||||
[Autoscale the DNS service in a Cluster](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/).
|
||||
-->
|
||||
- *为 DNS 请求做准备*：如果你希望工作负载能够完成大规模扩展，你的 DNS 服务
|
||||
也必须能够扩大规模。参阅
|
||||
[自动扩缩集群中 DNS 服务](/zh/docs/tasks/administer-cluster/dns-horizontal-autoscaling/)。
|
||||
<!--
|
||||
- *Create additional service accounts*: User accounts determine what users can
|
||||
do on a cluster, while a service account defines pod access within a particular
|
||||
namespace. By default, a pod takes on the default service account from its namespace.
|
||||
See [Managing Service Accounts](/docs/reference/access-authn-authz/service-accounts-admin/)
|
||||
for information on creating a new service account. For example, you might want to:
|
||||
-->
|
||||
- *创建额外的服务账户*：用户账户决定用户可以在集群上执行的操作，服务账号则定义的
|
||||
是在特定名字空间中 Pod 的访问权限。
|
||||
默认情况下，Pod 使用所在名字空间中的 default 服务账号。
|
||||
参阅[管理服务账号](/zh/docs/reference/access-authn-authz/service-accounts-admin/)
|
||||
以了解如何创建新的服务账号。例如，你可能需要：
|
||||
<!--
|
||||
- Add secrets that a pod could use to pull images from a particular container registry. See [Configure Service Accounts for Pods](/docs/tasks/configure-pod-container/configure-service-account/) for an example.
|
||||
- Assign RBAC permissions to a service account. See [ServiceAccount permissions](/docs/reference/access-authn-authz/rbac/#service-account-permissions) for details.
|
||||
-->
|
||||
- 为 Pod 添加 Secret，以便 Pod 能够从某特定的容器镜像仓库拉取镜像。
|
||||
参阅[为 Pod 配置服务账号](/zh/docs/tasks/configure-pod-container/configure-service-account/)
|
||||
以获得示例。
|
||||
- 为服务账号设置 RBAC 访问许可。参阅
|
||||
[服务账号访问许可](/zh/docs/reference/access-authn-authz/rbac/#service-account-permissions)
|
||||
了解细节。
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
<!--
|
||||
- Decide if you want to build your own production Kubernetes or obtain one from
|
||||
available [Turnkey Cloud Solutions](/docs/setup/production-environment/turnkey-solutions/)
|
||||
or [Kubernetes Partners](https://kubernetes.io/partners/).
|
||||
- If you choose to build your own cluster, plan how you want to
|
||||
handle [certificates](/docs/setup/best-practices/certificates/)
|
||||
and set up high availability for features such as
|
||||
[etcd](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/)
|
||||
and the
|
||||
[API server](/docs/setup/production-environment/tools/kubeadm/ha-topology/).
|
||||
-->
|
||||
- 决定你是想自行构造自己的生产用 Kubernetes 还是从某可用的
|
||||
[云服务外包厂商](/zh/docs/setup/production-environment/turnkey-solutions/)
|
||||
或 [Kubernetes 合作伙伴](https://kubernetes.io/partners/)获得集群。
|
||||
- 如果你决定自行构造集群，则需要规划如何处理
|
||||
[证书](/zh/docs/setup/best-practices/certificates/)
|
||||
并为类似
|
||||
[etcd](/zh/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/)
|
||||
和
|
||||
[API 服务器](/zh/docs/setup/production-environment/tools/kubeadm/ha-topology/)
|
||||
这些功能组件配置高可用能力。
|
||||
<!--
|
||||
- Choose from [kubeadm](/docs/setup/production-environment/tools/kubeadm/), [kops](/docs/setup/production-environment/tools/kops/) or [Kubespray](/docs/setup/production-environment/tools/kubespray/)
|
||||
deployment methods.
|
||||
-->
|
||||
- 选择使用 [kubeadm](/zh/docs/setup/production-environment/tools/kubeadm/)、
|
||||
[kops](/zh/docs/setup/production-environment/tools/kops/) 或
|
||||
[Kubespray](/zh/docs/setup/production-environment/tools/kubespray/)
|
||||
作为部署方法。
|
||||
<!--
|
||||
- Configure user management by determining your
|
||||
[Authentication](/docs/reference/access-authn-authz/authentication/) and
|
||||
[Authorization](/docs/reference/access-authn-authz/authorization/) methods.
|
||||
-->
|
||||
- 通过决定[身份认证](/zh/docs/reference/access-authn-authz/authentication/)和
|
||||
[鉴权](/zh/docs/reference/access-authn-authz/authorization/)方法来配置用户管理。
|
||||
<!--
|
||||
- Prepare for application workloads by setting up
|
||||
[resource limits](/docs/tasks/administer-cluster/manage-resources/),
|
||||
[DNS autoscaling](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/)
|
||||
and [service accounts](/docs/reference/access-authn-authz/service-accounts-admin/).
|
||||
-->
|
||||
- 通过配置[资源限制](/zh/docs/tasks/administer-cluster/manage-resources/)、
|
||||
[DNS 自动扩缩](/zh/docs/tasks/administer-cluster/dns-horizontal-autoscaling/)
|
||||
和[服务账号](/zh/docs/reference/access-authn-authz/service-accounts-admin/)
|
||||
来为应用负载作准备。
|
||||
|
||||
@@ -0,0 +1,500 @@
|
||||
---
|
||||
title: 容器运行时
|
||||
content_type: concept
|
||||
weight: 20
|
||||
---
|
||||
<!--
|
||||
reviewers:
|
||||
- vincepri
|
||||
- bart0sh
|
||||
title: Container Runtimes
|
||||
content_type: concept
|
||||
weight: 20
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
{{% dockershim-removal %}}
|
||||
|
||||
You need to install a
|
||||
{{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}
|
||||
into each node in the cluster so that Pods can run there. This page outlines
|
||||
what is involved and describes related tasks for setting up nodes.
|
||||
-->
|
||||
你需要在集群内每个节点上安装一个
|
||||
{{< glossary_tooltip text="容器运行时" term_id="container-runtime" >}}
|
||||
以使 Pod 可以运行在上面。本文概述了所涉及的内容并描述了与节点设置相关的任务。
|
||||
|
||||
|
||||
<!--
|
||||
Kubernetes {{< skew currentVersion >}} requires that you use a runtime that conforms with the {{< glossary_tooltip term_id="cri" text="Container Runtime Interface">}} (CRI).
|
||||
|
||||
See [CRI version support](#cri-versions) for more information.
|
||||
This page provides an outline of how to use several common container runtimes with Kubernetes.
|
||||
-->
|
||||
|
||||
Kubernetes {{< skew currentVersion >}} 要求你使用符合{{<glossary_tooltip term_id="cri" text="容器运行时接口">}} (CRI)的运行时。
|
||||
|
||||
有关详细信息，请参阅 [CRI 版本支持](#cri-versions)。
|
||||
本页简要介绍在 Kubernetes 中几个常见的容器运行时的用法。
|
||||
|
||||
- [containerd](#containerd)
|
||||
- [CRI-O](#cri-o)
|
||||
- [Docker Engine](#docker)
|
||||
- [Mirantis Container Runtime](#mcr)
|
||||
|
||||
<!--
|
||||
{{< note >}}
|
||||
Kubernetes releases before v1.24 included a direct integration with Docker Engine,
|
||||
using a component named _dockershim_. That special direct integration is no longer
|
||||
part of Kubernetes (this removal was
|
||||
[announced](/blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation)
|
||||
as part of the v1.20 release).
|
||||
You can read
|
||||
[Check whether Dockershim deprecation affects you](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/)
|
||||
to understand how this removal might
|
||||
affect you. To learn about migrating from using dockershim, see
|
||||
[Migrating from dockershim](/docs/tasks/administer-cluster/migrating-from-dockershim/).
|
||||
|
||||
If you are running a version of Kubernetes other than v{{< skew currentVersion >}},
|
||||
check the documentation for that version.
|
||||
{{< /note >}}
|
||||
|
||||
-->
|
||||
{{< note >}}
|
||||
提示：v1.24 之前的 Kubernetes 版本包括与 Docker Engine 的直接集成，使用名为 _dockershim_ 的组件。
|
||||
这种特殊的直接整合不再是 Kubernetes 的一部分
|
||||
（这次删除被作为 v1.20 发行版本的一部分[宣布](/zh/blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation)）。
|
||||
你可以阅读[检查 Dockershim 弃用是否会影响你](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/)
|
||||
以了解此删除可能会如何影响你。
|
||||
要了解如何使用 dockershim 进行迁移，请参阅[从 dockershim 迁移](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/)。
|
||||
|
||||
如果你正在运行 v{{< skew currentVersion >}} 以外的 Kubernetes 版本，检查该版本的文档。
|
||||
{{< /note >}}
|
||||
|
||||
<!-- body -->
|
||||
<!--
|
||||
## Install and configure prerequisites
|
||||
|
||||
The following steps apply common settings for Kubernetes nodes on Linux.
|
||||
|
||||
You can skip a particular setting if you're certain you don't need it.
|
||||
|
||||
For more information, see [Network Plugin Requirements](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#network-plugin-requirements) or the documentation for your specific container runtime.
|
||||
-->
|
||||
|
||||
## 安装和配置先决条件
|
||||
|
||||
以下步骤将通用设置应用于 Linux 上的 Kubernetes 节点。
|
||||
|
||||
如果你确定不需要某个特定设置，则可以跳过它。
|
||||
|
||||
有关更多信息，请参阅[网络插件要求](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#network-plugin-requirements)
|
||||
或特定容器运行时的文档。
|
||||
|
||||
<!--
|
||||
### Forwarding IPv4 and letting iptables see bridged traffic
|
||||
|
||||
Verify that the `br_netfilter` module is loaded by running `lsmod | grep br_netfilter`.
|
||||
|
||||
To load it explicitly, run `sudo modprobe br_netfilter`.
|
||||
|
||||
In order for a Linux node's iptables to correctly view bridged traffic, verify that `net.bridge.bridge-nf-call-iptables` is set to 1 in your `sysctl` config. For example:
|
||||
-->
|
||||
|
||||
### 转发 IPv4 并让 iptables 看到桥接流量
|
||||
|
||||
通过运行 `lsmod | grep br_netfilter` 来验证 `br_netfilter` 模块是否已加载。
|
||||
|
||||
若要显式加载此模块，请运行 `sudo modprobe br_netfilter`。
|
||||
|
||||
为了让 Linux 节点的 iptables 能够正确查看桥接流量，请确认 `sysctl` 配置中的
|
||||
`net.bridge.bridge-nf-call-iptables` 设置为 1。 例如：
|
||||
|
||||
<!--
|
||||
```bash
|
||||
cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
|
||||
overlay
|
||||
br_netfilter
|
||||
EOF
|
||||
|
||||
sudo modprobe overlay
|
||||
sudo modprobe br_netfilter
|
||||
|
||||
# sysctl params required by setup, params persist across reboots
|
||||
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
|
||||
net.bridge.bridge-nf-call-iptables = 1
|
||||
net.bridge.bridge-nf-call-ip6tables = 1
|
||||
net.ipv4.ip_forward = 1
|
||||
EOF
|
||||
|
||||
# Apply sysctl params without reboot
|
||||
sudo sysctl --system
|
||||
```
|
||||
-->
|
||||
|
||||
```bash
|
||||
cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
|
||||
overlay
|
||||
br_netfilter
|
||||
EOF
|
||||
|
||||
sudo modprobe overlay
|
||||
sudo modprobe br_netfilter
|
||||
|
||||
# 设置所需的 sysctl 参数，参数在重新启动后保持不变
|
||||
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
|
||||
net.bridge.bridge-nf-call-iptables = 1
|
||||
net.bridge.bridge-nf-call-ip6tables = 1
|
||||
net.ipv4.ip_forward = 1
|
||||
EOF
|
||||
|
||||
# 应用 sysctl 参数而不重新启动
|
||||
sudo sysctl --system
|
||||
```
|
||||
|
||||
<!--
|
||||
## Cgroup drivers
|
||||
-->
|
||||
## Cgroup 驱动程序
|
||||
|
||||
<!--
|
||||
On Linux, {{< glossary_tooltip text="control groups" term_id="cgroup" >}} are used to constrain resources that are allocated to processes.
|
||||
|
||||
When [systemd](https://www.freedesktop.org/wiki/Software/systemd/) is chosen as the init
|
||||
system for a Linux distribution, the init process generates and consumes a root control group
|
||||
(`cgroup`) and acts as a cgroup manager.
|
||||
Systemd has a tight integration with cgroups and allocates a cgroup per systemd unit. It's possible
|
||||
to configure your container runtime and the kubelet to use `cgroupfs`. Using `cgroupfs` alongside
|
||||
systemd means that there will be two different cgroup managers.
|
||||
-->
|
||||
在 Linux 上，{{<glossary_tooltip text="控制组（CGroup）" term_id="cgroup" >}}用于限制分配给进程的资源。
|
||||
|
||||
当某个 Linux 系统发行版使用 [systemd](https://www.freedesktop.org/wiki/Software/systemd/)
|
||||
作为其初始化系统时，初始化进程会生成并使用一个 root 控制组（`cgroup`），并充当 cgroup 管理器。
|
||||
Systemd 与 cgroup 集成紧密，并将为每个 systemd 单元分配一个 cgroup。
|
||||
你也可以配置容器运行时和 kubelet 使用 `cgroupfs`。
|
||||
连同 systemd 一起使用 `cgroupfs` 意味着将有两个不同的 cgroup 管理器。
|
||||
|
||||
<!--
|
||||
A single cgroup manager simplifies the view of what resources are being allocated
|
||||
and will by default have a more consistent view of the available and in-use resources.
|
||||
When there are two cgroup managers on a system, you end up with two views of those resources.
|
||||
In the field, people have reported cases where nodes that are configured to use `cgroupfs`
|
||||
for the kubelet and Docker, but `systemd` for the rest of the processes, become unstable under
|
||||
resource pressure.
|
||||
-->
|
||||
单个 cgroup 管理器将简化分配资源的视图，并且默认情况下将对可用资源和使用
|
||||
中的资源具有更一致的视图。
|
||||
当有两个管理器共存于一个系统中时，最终将对这些资源产生两种视图。
|
||||
在此领域人们已经报告过一些案例，某些节点配置让 kubelet 和 docker 使用
|
||||
`cgroupfs`，而节点上运行的其余进程则使用 systemd; 这类节点在资源压力下
|
||||
会变得不稳定。
|
||||
|
||||
<!--
|
||||
Changing the settings such that your container runtime and kubelet use `systemd` as the cgroup driver
|
||||
stabilized the system. To configure this for Docker, set `native.cgroupdriver=systemd`.
|
||||
-->
|
||||
更改设置，令容器运行时和 kubelet 使用 `systemd` 作为 cgroup 驱动，以此使系统更为稳定。
|
||||
对于 Docker, 设置 `native.cgroupdriver=systemd` 选项。
|
||||
|
||||
<!--
|
||||
{{< caution >}}
|
||||
Changing the cgroup driver of a Node that has joined a cluster is a sensitive operation.
|
||||
If the kubelet has created Pods using the semantics of one cgroup driver, changing the container
|
||||
runtime to another cgroup driver can cause errors when trying to re-create the Pod sandbox
|
||||
for such existing Pods. Restarting the kubelet may not solve such errors.
|
||||
|
||||
If you have automation that makes it feasible, replace the node with another using the updated
|
||||
configuration, or reinstall it using automation.
|
||||
{{< /caution >}}
|
||||
-->
|
||||
注意：更改已加入集群的节点的 cgroup 驱动是一项敏感的操作。
|
||||
如果 kubelet 已经使用某 cgroup 驱动的语义创建了 pod，更改运行时以使用
|
||||
别的 cgroup 驱动，当为现有 Pods 重新创建 PodSandbox 时会产生错误。
|
||||
重启 kubelet 也可能无法解决此类问题。
|
||||
如果你有切实可行的自动化方案，使用其他已更新配置的节点来替换该节点，
|
||||
或者使用自动化方案来重新安装。
|
||||
|
||||
<!--
|
||||
### Cgroup version 2 {#cgroup-v2}
|
||||
|
||||
Cgroup v2 is the next version of the cgroup Linux API. Differently than cgroup v1, there is a single
|
||||
hierarchy instead of a different one for each controller.
|
||||
-->
|
||||
### Cgroup v2 {#cgroup-v2}
|
||||
|
||||
Cgroup v2 是 cgroup Linux API 的下一个版本。与 cgroup v1 不同的是，
|
||||
Cgroup v2 只有一个层次结构，而不是每个控制器有一个不同的层次结构。
|
||||
|
||||
<!--
|
||||
The new version offers several improvements over cgroup v1, some of these improvements are:
|
||||
|
||||
- cleaner and easier to use API
|
||||
- safe sub-tree delegation to containers
|
||||
- newer features like Pressure Stall Information
|
||||
-->
|
||||
新版本对 cgroup v1 进行了多项改进，其中一些改进是：
|
||||
|
||||
- 更简洁、更易于使用的 API
|
||||
- 可将安全子树委派给容器
|
||||
- 更新的功能，如压力失速信息（Pressure Stall Information）
|
||||
|
||||
<!--
|
||||
Even if the kernel supports a hybrid configuration where some controllers are managed by cgroup v1
|
||||
and some others by cgroup v2, Kubernetes supports only the same cgroup version to manage all the
|
||||
controllers.
|
||||
|
||||
If systemd doesn't use cgroup v2 by default, you can configure the system to use it by adding
|
||||
`systemd.unified_cgroup_hierarchy=1` to the kernel command line.
|
||||
-->
|
||||
尽管内核支持混合配置，即其中一些控制器由 cgroup v1 管理，另一些由 cgroup v2 管理，
|
||||
Kubernetes 仅支持使用同一 cgroup 版本来管理所有控制器。
|
||||
|
||||
如果 systemd 默认不使用 cgroup v2，你可以通过在内核命令行中添加
|
||||
`systemd.unified_cgroup_hierarchy=1` 来配置系统去使用它。
|
||||
|
||||
<!--
|
||||
```shell
|
||||
# This example is for a Linux OS that uses the DNF package manager
|
||||
# Your system might use a different method for setting the command line
|
||||
# that the Linux kernel uses.
|
||||
sudo dnf install -y grubby && \
|
||||
sudo grubby \
|
||||
--update-kernel=ALL \
|
||||
--args="systemd.unified_cgroup_hierarchy=1"
|
||||
```
|
||||
-->
|
||||
|
||||
```shell
|
||||
# 此示例适用于使用 DNF 包管理器的 Linux 操作系统
|
||||
# 你的系统可能使用不同的方法来设置 Linux 内核使用的命令行。
|
||||
sudo dnf install -y grubby && \
|
||||
sudo grubby \
|
||||
--update-kernel=ALL \
|
||||
--args="systemd.unified_cgroup_hierarchy=1"
|
||||
```
|
||||
|
||||
<!--
|
||||
If you change the command line for the kernel, you must reboot the node before your change takes effect.
|
||||
|
||||
There should not be any noticeable difference in the user experience when switching to cgroup v2, unless
|
||||
users are accessing the cgroup file system directly, either on the node or from within the containers.
|
||||
|
||||
In order to use it, cgroup v2 must be supported by the CRI runtime as well.
|
||||
-->
|
||||
如果更改内核的命令行，则必须重新启动节点才能使更改生效。
|
||||
|
||||
切换到 cgroup v2 时，用户体验不应有任何明显差异，
|
||||
除非用户直接在节点上或在容器内访问 cgroup 文件系统。
|
||||
为了使用它，CRI 运行时也必须支持 cgroup v2。
|
||||
|
||||
<!--
|
||||
### Migrating to the `systemd` driver in kubeadm managed clusters
|
||||
-->
|
||||
### 将 kubeadm 托管的集群迁移到 `systemd` 驱动
|
||||
|
||||
<!--
|
||||
If you wish to migrate to the `systemd` cgroup driver in existing kubeadm managed clusters, follow [configuring a cgroup driver](/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/).
|
||||
|
||||
## CRI version support {#cri-versions}
|
||||
|
||||
Your container runtime must support at least v1alpha2 of the container runtime interface.
|
||||
|
||||
Kubernetes {{< skew currentVersion >}} defaults to using v1 of the CRI API.If a container runtime does not support the v1 API, the kubelet falls back to using the (deprecated) v1alpha2 API instead.
|
||||
-->
|
||||
如果你希望将现有的由 kubeadm 管理的集群迁移到 `systemd` cgroup 驱动程序，
|
||||
请按照[配置 cgroup 驱动程序](/zh/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/)操作。
|
||||
|
||||
## CRI 版本支持 {#cri-versions}
|
||||
|
||||
你的容器运行时必须至少支持容器运行时接口的 v1alpha2。
|
||||
|
||||
Kubernetes {{< skew currentVersion >}} 默认使用 v1 的 CRI API。如果容器运行时不支持 v1 API，
|
||||
则 kubelet 会回退到使用（已弃用的）v1alpha2 API。
|
||||
|
||||
<!--
|
||||
## Container runtimes
|
||||
-->
|
||||
## 容器运行时
|
||||
|
||||
{{% thirdparty-content %}}
|
||||
|
||||
### containerd
|
||||
|
||||
<!--
|
||||
This section outlines the necessary steps to use containerd as CRI runtime.
|
||||
|
||||
Use the following commands to install Containerd on your system:
|
||||
|
||||
-->
|
||||
本节概述了使用 containerd 作为 CRI 运行时的必要步骤。
|
||||
|
||||
使用以下命令在系统上安装 Containerd：
|
||||
|
||||
<!--
|
||||
Follow the instructions for [getting started with containerd](https://github.com/containerd/containerd/blob/main/docs getting-started.md). Return to this step once you've created a valid configuration file, `config.toml`.
|
||||
-->
|
||||
|
||||
按照[开始使用 containerd](https://github.com/containerd/containerd/blob/main/docs/getting-started.md) 的说明进行操作。
|
||||
创建有效的配置文件 `config.toml` 后返回此步骤。
|
||||
|
||||
{{< tabs name="Finding your config.toml file" >}}
|
||||
{{% tab name="Linux" %}}
|
||||
<!-- You can find this file under the path `/etc/containerd/config.toml`. -->
|
||||
你可以在路径 `/etc/containerd/config.toml` 下找到此文件。
|
||||
{{% /tab %}}
|
||||
{{< tab name="Windows" >}}
|
||||
<!-- You can find this file under the path `C:\Program Files\containerd\config.toml`. -->
|
||||
你可以在路径 `C:\Program Files\containerd\config.toml` 下找到此文件。
|
||||
{{< /tab >}}
|
||||
{{< /tabs >}}
|
||||
|
||||
<!--
|
||||
On Linux the default CRI socket for containerd is `/run/containerd/containerd.sock`.
|
||||
On Windows the default CRI endpoint is `npipe://./pipe/containerd-containerd`.
|
||||
|
||||
#### Configuring the `systemd` cgroup driver {#containerd-systemd}
|
||||
-->
|
||||
在 Linux 上，containerd 的默认 CRI 套接字是 `/run/containerd/containerd.sock`。
|
||||
在 Windows 上，默认 CRI 端点是 `npipe://./pipe/containerd-containerd`。
|
||||
|
||||
#### 配置 `systemd` cgroup 驱动程序 {#containerd-systemd}
|
||||
|
||||
<!--
|
||||
To use the `systemd` cgroup driver in `/etc/containerd/config.toml` with `runc`, set
|
||||
-->
|
||||
结合 `runc` 使用 `systemd` cgroup 驱动，在 `/etc/containerd/config.toml` 中设置
|
||||
|
||||
```
|
||||
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
|
||||
...
|
||||
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
|
||||
SystemdCgroup = true
|
||||
```
|
||||
|
||||
<!--
|
||||
If you apply this change, make sure to restart containerd:
|
||||
-->
|
||||
如果你应用此更改，请确保重新启动 containerd：
|
||||
|
||||
```shell
|
||||
sudo systemctl restart containerd
|
||||
```
|
||||
|
||||
<!--
|
||||
When using kubeadm, manually configure the
|
||||
[cgroup driver for kubelet](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-control-plane-node).
|
||||
-->
|
||||
当使用 kubeadm 时，请手动配置
|
||||
[kubelet 的 cgroup 驱动](/zh/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-control-plane-node).
|
||||
|
||||
### CRI-O
|
||||
|
||||
<!--
|
||||
This section contains the necessary steps to install CRI-O as a container runtime.
|
||||
|
||||
-->
|
||||
本节包含安装 CRI-O 作为容器运行时的必要步骤。
|
||||
|
||||
<!--
|
||||
To install CRI-O, follow [CRI-O Install Instructions](https://github.com/cri-o/cri-o/blob/main/install.md#readme).
|
||||
-->
|
||||
|
||||
要安装 CRI-O，请按照 [CRI-O 安装说明](https://github.com/cri-o/cri-o/blob/main/install.md#readme)执行操作。
|
||||
|
||||
<!-- #### cgroup driver -->
|
||||
|
||||
#### cgroup 驱动程序
|
||||
|
||||
<!--
|
||||
CRI-O uses the systemd cgroup driver per default, which is likely to work fine for you. To switch to the `cgroupfs` cgroup driver, either edit `/etc/crio/crio.conf` or place a drop-in configuration in `/etc/crio/crio.conf.d/02-cgroup-manager.conf`, for example:
|
||||
-->
|
||||
|
||||
CRI-O 默认使用 systemd cgroup 驱动程序，这对你来说可能工作得很好。要切换到 `cgroupfs` cgroup 驱动程序，
|
||||
请编辑 `/etc/crio/crio.conf` 或在 `/etc/crio/crio.conf.d/02-cgroup-manager.conf` 中放置一个插入式配置 ，例如：
|
||||
|
||||
|
||||
```toml
|
||||
[crio.runtime]
|
||||
conmon_cgroup = "pod"
|
||||
cgroup_manager = "cgroupfs"
|
||||
```
|
||||
|
||||
<!--
|
||||
You should also note the changed `conmon_cgroup`, which has to be set to the value `pod` when using CRI-O with `cgroupfs`. It is generally necessary to keep the cgroup driver configuration of the kubelet (usually done via kubeadm) and CRI-O in sync.
|
||||
-->
|
||||
|
||||
你还应该注意到 `conmon_cgroup` 被更改，当使用 CRI-O 和 `cgroupfs` 时，必须将其设置为值 `pod`。
|
||||
通常需要保持 kubelet 的 cgroup 驱动配置（通常通过 kubeadm 完成）和 CRI-O 同步。
|
||||
|
||||
<!--
|
||||
For CRI-O, the CRI socket is `/var/run/crio/crio.sock` by default.
|
||||
|
||||
### Docker Engine {#docker}
|
||||
|
||||
-->
|
||||
对于 CRI-O，CRI 套接字默认为 `/var/run/crio/crio.sock`。
|
||||
|
||||
### Docker Engine {#docker}
|
||||
|
||||
<!--
|
||||
{{< note >}}
|
||||
These instructions assume that you are using the [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd) adapter to integrate
|
||||
Docker Engine with Kubernetes.
|
||||
{{< /note >}}
|
||||
-->
|
||||
|
||||
{{< note >}}
|
||||
以下操作假设你使用 [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd) 适配器来将
|
||||
Docker Engine 与 Kubernetes 集成。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
1. On each of your nodes, install Docker for your Linux distribution as per [Install Docker Engine](https://docs.docker.com/engine/install/#server).
|
||||
-->
|
||||
|
||||
1. 在你的每个节点上，遵循[安装 Docker 引擎](https://docs.docker.com/engine/install/#server)指南为你的
|
||||
Linux 发行版安装 Docker。
|
||||
|
||||
<!--
|
||||
2. Install [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd), following the instructions in that source code repository.
|
||||
-->
|
||||
2. 按照源代码仓库中的说明安装 [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd)。
|
||||
|
||||
|
||||
<!--
|
||||
For `cri-dockerd`, the CRI socket is `/run/cri-dockerd.sock` by default.
|
||||
|
||||
### Mirantis Container Runtime {#mcr}
|
||||
-->
|
||||
对于 `cri-dockerd`，默认情况下，CRI 套接字是 `/run/cri-dockerd.sock`。
|
||||
|
||||
### Mirantis 容器运行时 {#mcr}
|
||||
|
||||
<!--
|
||||
[Mirantis Container Runtime](https://docs.mirantis.com/mcr/20.10/overview.html) (MCR) is a commercially available container runtime that was formerly known as Docker Enterprise Edition.
|
||||
You can use Mirantis Container Runtime with Kubernetes using the open source [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd) component, included with MCR.
|
||||
-->
|
||||
[Mirantis Container Runtime](https://docs.mirantis.com/mcr/20.10/overview.html) (MCR) 是一种商用容器运行时，以前称为 Docker 企业版。
|
||||
你可以使用 MCR 中包含的开源 [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd) 组件将 Mirantis Container Runtime 与 Kubernetes 一起使用。
|
||||
|
||||
<!--
|
||||
To learn more about how to install Mirantis Container Runtime, visit [MCR Deployment Guide](https://docs.mirantis.com/mcr/20.10/install.html).
|
||||
-->
|
||||
要了解有关如何安装 Mirantis Container Runtime 的更多信息，请访问 [MCR 部署指南](https://docs.mirantis.com/mcr/20.10/install.html)。
|
||||
<!--
|
||||
Check the systemd unit named `cri-docker.socket` to find out the path to the CRI socket.
|
||||
-->
|
||||
检查名为 `cri-docker.socket` 的 systemd 单元以找出 CRI 套接字的路径。
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
<!--
|
||||
As well as a container runtime, your cluster will need a working [network plugin](/docs/concepts/cluster-administration/networking/#how-to-implement-the-kubernetes-networking-model).
|
||||
-->
|
||||
|
||||
除了容器运行时，你的集群还需要有效的[网络插件](/zh/docs/concepts/cluster-administration/networking/#how-to-implement-the-kubernetes-networking-model)。
|
||||
|
||||
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: 使用部署工具安装 Kubernetes
|
||||
weight: 30
|
||||
---
|
||||
@@ -0,0 +1,422 @@
|
||||
---
|
||||
title: 使用 Kops 安装 Kubernetes
|
||||
content_type: concept
|
||||
weight: 20
|
||||
---
|
||||
<!--
|
||||
title: Installing Kubernetes with kops
|
||||
content_type: concept
|
||||
weight: 20
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
This quickstart shows you how to easily install a Kubernetes cluster on AWS.
|
||||
It uses a tool called [`kops`](https://github.com/kubernetes/kops).
|
||||
-->
|
||||
本篇快速入门介绍了如何在 AWS 上轻松安装 Kubernetes 集群。
|
||||
本篇使用了一个名为 [`kops`](https://github.com/kubernetes/kops) 的工具。
|
||||
|
||||
<!--
|
||||
kops is an automated provisioning system:
|
||||
-->
|
||||
kops 是一个自动化的制备系统：
|
||||
|
||||
<!--
|
||||
* Fully automated installation
|
||||
* Uses DNS to identify clusters
|
||||
* Self-healing: everything runs in Auto-Scaling Groups
|
||||
* Multiple OS support (Debian, Ubuntu 16.04 supported, CentOS & RHEL, Amazon Linux and CoreOS) - see the [images.md](https://github.com/kubernetes/kops/blob/master/docs/operations/images.md)
|
||||
* High-Availability support - see the [high_availability.md](https://github.com/kubernetes/kops/blob/master/docs/high_availability.md)
|
||||
* Can directly provision, or generate terraform manifests - see the [terraform.md](https://github.com/kubernetes/kops/blob/master/docs/terraform.md)
|
||||
-->
|
||||
* 全自动安装流程
|
||||
* 使用 DNS 识别集群
|
||||
* 自我修复：一切都在自动扩缩组中运行
|
||||
* 支持多种操作系统（如 Debian、Ubuntu 16.04、CentOS、RHEL、Amazon Linux 和 CoreOS） - 参考 [images.md](https://github.com/kubernetes/kops/blob/master/docs/operations/images.md)
|
||||
* 支持高可用 - 参考 [high_availability.md](https://github.com/kubernetes/kops/blob/master/docs/high_availability.md)
|
||||
* 可以直接提供或者生成 terraform 清单 - 参考 [terraform.md](https://github.com/kubernetes/kops/blob/master/docs/terraform.md)
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
<!--
|
||||
* You must have [kubectl](/docs/tasks/tools/) installed.
|
||||
|
||||
* You must [install](https://github.com/kubernetes/kops#installing) `kops` on a 64-bit (AMD64 and Intel 64) device architecture.
|
||||
|
||||
* You must have an [AWS account](https://docs.aws.amazon.com/polly/latest/dg/setting-up.html), generate [IAM keys](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#access-keys-and-secret-access-keys) and [configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html#cli-quick-configuration) them. The IAM user will need [adequate permissions](https://github.com/kubernetes/kops/blob/master/docs/getting_started/aws.md#setup-iam-user).
|
||||
-->
|
||||
* 你必须安装 [kubectl](/zh/docs/tasks/tools/)。
|
||||
* 你必须安装[安装](https://github.com/kubernetes/kops#installing) `kops`
|
||||
到 64 位的（AMD64 和 Intel 64）设备架构上。
|
||||
* 你必须拥有一个 [AWS 账户](https://docs.aws.amazon.com/polly/latest/dg/setting-up.html)，
|
||||
生成 [IAM 秘钥](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#access-keys-and-secret-access-keys)
|
||||
并[配置](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html#cli-quick-configuration)
|
||||
该秘钥。IAM 用户需要[足够的权限许可](https://github.com/kubernetes/kops/blob/master/docs/getting_started/aws.md#setup-iam-user)。
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
<!--
|
||||
## Creating a cluster
|
||||
|
||||
### (1/5) Install kops
|
||||
|
||||
#### Installation
|
||||
|
||||
Download kops from the [releases page](https://github.com/kubernetes/kops/releases) (it is also convenient to build from source):
|
||||
-->
|
||||
## 创建集群
|
||||
|
||||
### (1/5) 安装 kops
|
||||
|
||||
#### 安装
|
||||
|
||||
从[下载页面](https://github.com/kubernetes/kops/releases)下载 kops
|
||||
（从源代码构建也很方便）：
|
||||
|
||||
{{< tabs name="kops_installation" >}}
|
||||
{{% tab name="macOS" %}}
|
||||
|
||||
<!--
|
||||
Download the latest release with the command:
|
||||
-->
|
||||
使用下面的命令下载最新发布版本：
|
||||
|
||||
```shell
|
||||
curl -LO https://github.com/kubernetes/kops/releases/download/$(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4)/kops-darwin-amd64
|
||||
```
|
||||
|
||||
<!--
|
||||
To download a specific version, replace the following portion of the command with the specific kops version.
|
||||
-->
|
||||
要下载特定版本，使用特定的 kops 版本替换下面命令中的部分：
|
||||
|
||||
```shell
|
||||
$(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4)
|
||||
```
|
||||
|
||||
<!--
|
||||
For example, to download kops version v1.20.0 type:
|
||||
-->
|
||||
例如，要下载 kops v1.20.0，输入：
|
||||
|
||||
```shell
|
||||
curl -LO https://github.com/kubernetes/kops/releases/download/v1.20.0/kops-darwin-amd64
|
||||
```
|
||||
|
||||
<!--
|
||||
Make the kops binary executable.
|
||||
-->
|
||||
令 kops 二进制文件可执行：
|
||||
|
||||
```shell
|
||||
chmod +x kops-darwin-amd64
|
||||
```
|
||||
|
||||
<!--
|
||||
Move the kops binary in to your PATH.
|
||||
-->
|
||||
将 kops 二进制文件移到你的 PATH 下：
|
||||
|
||||
```shell
|
||||
sudo mv kops-darwin-amd64 /usr/local/bin/kops
|
||||
```
|
||||
|
||||
你也可以使用 [Homebrew](https://brew.sh/) 安装 kops：
|
||||
|
||||
```shell
|
||||
brew update && brew install kops
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{% tab name="Linux" %}}
|
||||
|
||||
<!--
|
||||
Download the latest release with the command:
|
||||
-->
|
||||
使用命令下载最新发布版本：
|
||||
|
||||
```shell
|
||||
curl -LO https://github.com/kubernetes/kops/releases/download/$(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4)/kops-linux-amd64
|
||||
```
|
||||
|
||||
<!--
|
||||
To download a specific version of kops, replace the following portion of the command with the specific kops version.
|
||||
-->
|
||||
要下载 kops 的特定版本，用特定的 kops 版本替换下面命令中的部分：
|
||||
|
||||
```shell
|
||||
$(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4)
|
||||
```
|
||||
|
||||
<!--
|
||||
For example, to download kops version v1.20.0 type:
|
||||
-->
|
||||
例如，要下载 kops v1.20 版本，输入：
|
||||
|
||||
```shell
|
||||
curl -LO https://github.com/kubernetes/kops/releases/download/v1.20.0/kops-linux-amd64
|
||||
```
|
||||
|
||||
<!--
|
||||
Make the kops binary executable
|
||||
-->
|
||||
令 kops 二进制文件可执行：
|
||||
|
||||
```shell
|
||||
chmod +x kops-linux-amd64
|
||||
```
|
||||
|
||||
<!--
|
||||
Move the kops binary in to your PATH.
|
||||
-->
|
||||
将 kops 二进制文件移到 PATH 下：
|
||||
|
||||
|
||||
```shell
|
||||
sudo mv kops-linux-amd64 /usr/local/bin/kops
|
||||
```
|
||||
|
||||
你也可以使用 [Homebrew](https://docs.brew.sh/Homebrew-on-Linux)
|
||||
来安装 kops：
|
||||
|
||||
```shell
|
||||
brew update && brew install kops
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
<!--
|
||||
### (2/5) Create a route53 domain for your cluster
|
||||
|
||||
kops uses DNS for discovery, both inside the cluster and outside, so that you can reach the kubernetes API server
|
||||
from clients.
|
||||
-->
|
||||
### (2/5) 为你的集群创建一个 route53 域名
|
||||
|
||||
kops 在集群内部和外部都使用 DNS 进行发现操作，这样你可以从客户端访问
|
||||
kubernetes API 服务器。
|
||||
|
||||
<!--
|
||||
kops has a strong opinion on the cluster name: it should be a valid DNS name. By doing so you will
|
||||
no longer get your clusters confused, you can share clusters with your colleagues unambiguously,
|
||||
and you can reach them without relying on remembering an IP address.
|
||||
-->
|
||||
kops 对集群名称有明显的要求：它应该是有效的 DNS 名称。这样一来，你就不会再使集群混乱，
|
||||
可以与同事明确共享集群，并且无需依赖记住 IP 地址即可访问集群。
|
||||
|
||||
<!--
|
||||
You can, and probably should, use subdomains to divide your clusters. As our example we will use
|
||||
`useast1.dev.example.com`. The API server endpoint will then be `api.useast1.dev.example.com`.
|
||||
-->
|
||||
你可以，或许应该使用子域名来划分集群。作为示例，我们将使用域名 `useast1.dev.example.com`。
|
||||
这样，API 服务器端点域名将为 `api.useast1.dev.example.com`。
|
||||
|
||||
<!--
|
||||
A Route53 hosted zone can serve subdomains. Your hosted zone could be `useast1.dev.example.com`,
|
||||
but also `dev.example.com` or even `example.com`. kops works with any of these, so typically
|
||||
you choose for organization reasons (e.g. you are allowed to create records under `dev.example.com`,
|
||||
but not under `example.com`).
|
||||
-->
|
||||
Route53 托管区域可以服务子域名。你的托管区域可能是 `useast1.dev.example.com`，还有 `dev.example.com` 甚至 `example.com`。
|
||||
kops 可以与以上任何一种配合使用，因此通常你出于组织原因选择不同的托管区域。
|
||||
例如，允许你在 `dev.example.com` 下创建记录，但不能在 `example.com` 下创建记录。
|
||||
|
||||
<!--
|
||||
Let's assume you're using `dev.example.com` as your hosted zone. You create that hosted zone using
|
||||
the [normal process](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingNewSubdomain.html), or
|
||||
with a command such as `aws route53 create-hosted-zone --name dev.example.com --caller-reference 1`.
|
||||
-->
|
||||
假设你使用 `dev.example.com` 作为托管区域。你可以使用
|
||||
[正常流程](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingNewSubdomain.html)
|
||||
或者使用诸如 `aws route53 create-hosted-zone --name dev.example.com --caller-reference 1`
|
||||
之类的命令来创建该托管区域。
|
||||
|
||||
<!--
|
||||
You must then set up your NS records in the parent domain, so that records in the domain will resolve. Here,
|
||||
you would create NS records in `example.com` for `dev`. If it is a root domain name you would configure the NS
|
||||
records at your domain registrar (e.g. `example.com` would need to be configured where you bought `example.com`).
|
||||
-->
|
||||
然后，你必须在父域名中设置你的 DNS 记录，以便该域名中的记录可以被解析。
|
||||
在这里，你将在 `example.com` 中为 `dev` 创建 DNS 记录。
|
||||
如果它是根域名，则可以在域名注册机构配置 DNS 记录。
|
||||
例如，你需要在购买 `example.com` 的地方配置 `example.com`。
|
||||
|
||||
<!--
|
||||
Verify your route53 domain setup (it is the #1 cause of problems!). You can double-check that
|
||||
your cluster is configured correctly if you have the dig tool by running:
|
||||
-->
|
||||
检查你的 route53 域已经被正确设置（这是导致问题的最常见原因！）。
|
||||
如果你安装了 dig 工具，则可以通过运行以下步骤再次检查集群是否配置正确：
|
||||
|
||||
```shell
|
||||
dig DNS dev.example.com
|
||||
```
|
||||
|
||||
<!--
|
||||
You should see the 4 NS records that Route53 assigned your hosted zone.
|
||||
-->
|
||||
你应该看到 Route53 分配了你的托管区域的 4 条 DNS 记录。
|
||||
|
||||
<!--
|
||||
### (3/5) Create an S3 bucket to store your clusters state
|
||||
|
||||
kops lets you manage your clusters even after installation. To do this, it must keep track of the clusters
|
||||
that you have created, along with their configuration, the keys they are using etc. This information is stored
|
||||
in an S3 bucket. S3 permissions are used to control access to the bucket.
|
||||
-->
|
||||
### (3/5) 创建一个 S3 存储桶来存储集群状态
|
||||
|
||||
kops 使你即使在安装后也可以管理集群。为此，它必须跟踪已创建的集群及其配置、所使用的密钥等。
|
||||
此信息存储在 S3 存储桶中。S3 权限用于控制对存储桶的访问。
|
||||
|
||||
<!--
|
||||
Multiple clusters can use the same S3 bucket, and you can share an S3 bucket between your colleagues that
|
||||
administer the same clusters - this is much easier than passing around kubecfg files. But anyone with access
|
||||
to the S3 bucket will have administrative access to all your clusters, so you don't want to share it beyond
|
||||
the operations team.
|
||||
-->
|
||||
多个集群可以使用同一 S3 存储桶，并且你可以在管理同一集群的同事之间共享一个
|
||||
S3 存储桶 - 这比传递 kubecfg 文件容易得多。
|
||||
但是有权访问 S3 存储桶的任何人都将拥有对所有集群的管理访问权限，
|
||||
因此你不想在运营团队之外共享它。
|
||||
|
||||
<!--
|
||||
So typically you have one S3 bucket for each ops team (and often the name will correspond
|
||||
to the name of the hosted zone above!)
|
||||
-->
|
||||
因此，通常每个运维团队都有一个 S3 存储桶（而且名称通常对应于上面托管区域的名称！）
|
||||
|
||||
<!--
|
||||
In our example, we chose `dev.example.com` as our hosted zone, so let's pick `clusters.dev.example.com` as
|
||||
the S3 bucket name.
|
||||
-->
|
||||
在我们的示例中，我们选择 `dev.example.com` 作为托管区域，因此我们选择
|
||||
`clusters.dev.example.com` 作为 S3 存储桶名称。
|
||||
|
||||
<!--
|
||||
* Export `AWS_PROFILE` (if you need to select a profile for the AWS CLI to work)
|
||||
* Create the S3 bucket using `aws s3 mb s3://clusters.dev.example.com`
|
||||
* You can `export KOPS_STATE_STORE=s3://clusters.dev.example.com` and then kops will use this location by default.
|
||||
We suggest putting this in your bash profile or similar.
|
||||
-->
|
||||
* 导出 `AWS_PROFILE` 文件（如果你需要选择一个配置文件用来使 AWS CLI 正常工作）
|
||||
* 使用 `aws s3 mb s3://clusters.dev.example.com` 创建 S3 存储桶
|
||||
* 你可以进行 `export KOPS_STATE_STORE=s3://clusters.dev.example.com` 操作，
|
||||
然后 kops 将默认使用此位置。
|
||||
我们建议将其放入你的 bash profile 文件或类似文件中。
|
||||
|
||||
<!--
|
||||
### (4/5) Build your cluster configuration
|
||||
|
||||
Run `kops create cluster` to create your cluster configuration:
|
||||
-->
|
||||
### (4/5) 建立你的集群配置
|
||||
|
||||
运行 `kops create cluster` 以创建你的集群配置：
|
||||
|
||||
`kops create cluster --zones=us-east-1c useast1.dev.example.com`
|
||||
|
||||
<!--
|
||||
kops will create the configuration for your cluster. Note that it _only_ creates the configuration, it does
|
||||
not actually create the cloud resources - you'll do that in the next step with a `kops update cluster`. This
|
||||
give you an opportunity to review the configuration or change it.
|
||||
-->
|
||||
kops 将为你的集群创建配置。请注意，它_仅_创建配置，实际上并没有创建云资源 -
|
||||
你将在下一步中使用 `kops update cluster` 进行配置。
|
||||
这使你有机会查看配置或进行更改。
|
||||
|
||||
<!--
|
||||
It prints commands you can use to explore further:
|
||||
-->
|
||||
它打印出可用于进一步探索的命令：
|
||||
|
||||
<!--
|
||||
* List your clusters with: `kops get cluster`
|
||||
* Edit this cluster with: `kops edit cluster useast1.dev.example.com`
|
||||
* Edit your node instance group: `kops edit ig --name=useast1.dev.example.com nodes`
|
||||
* Edit your master instance group: `kops edit ig --name=useast1.dev.example.com master-us-east-1c`
|
||||
-->
|
||||
* 使用以下命令列出集群：`kops get cluster`
|
||||
* 使用以下命令编辑该集群：`kops edit cluster useast1.dev.example.com`
|
||||
* 使用以下命令编辑你的节点实例组：`kops edit ig --name = useast1.dev.example.com nodes`
|
||||
* 使用以下命令编辑你的主实例组：`kops edit ig --name = useast1.dev.example.com master-us-east-1c`
|
||||
|
||||
<!--
|
||||
If this is your first time using kops, do spend a few minutes to try those out! An instance group is a
|
||||
set of instances, which will be registered as kubernetes nodes. On AWS this is implemented via auto-scaling-groups.
|
||||
You can have several instance groups, for example if you wanted nodes that are a mix of spot and on-demand instances, or
|
||||
GPU and non-GPU instances.
|
||||
-->
|
||||
如果这是你第一次使用 kops，请花几分钟尝试一下！ 实例组是一组实例，将被注册为 kubernetes 节点。
|
||||
在 AWS 上，这是通过 auto-scaling-groups 实现的。你可以有多个实例组。
|
||||
例如，如果你想要的是混合实例和按需实例的节点，或者 GPU 和非 GPU 实例。
|
||||
|
||||
<!--
|
||||
### (5/5) Create the cluster in AWS
|
||||
|
||||
Run "kops update cluster" to create your cluster in AWS:
|
||||
-->
|
||||
### (5/5) 在 AWS 中创建集群
|
||||
|
||||
运行 "kops update cluster" 以在 AWS 中创建集群：
|
||||
|
||||
```shell
|
||||
kops update cluster useast1.dev.example.com --yes
|
||||
```
|
||||
|
||||
<!--
|
||||
That takes a few seconds to run, but then your cluster will likely take a few minutes to actually be ready.
|
||||
`kops update cluster` will be the tool you'll use whenever you change the configuration of your cluster; it
|
||||
applies the changes you have made to the configuration to your cluster - reconfiguring AWS or kubernetes as needed.
|
||||
-->
|
||||
这需要几秒钟的时间才能运行，但实际上集群可能需要几分钟才能准备就绪。
|
||||
每当更改集群配置时，都会使用 `kops update cluster` 工具。
|
||||
它将对配置进行的更改应用于你的集群 - 根据需要重新配置 AWS 或者 kubernetes。
|
||||
|
||||
<!--
|
||||
For example, after you `kops edit ig nodes`, then `kops update cluster --yes` to apply your configuration, and
|
||||
sometimes you will also have to `kops rolling-update cluster` to roll out the configuration immediately.
|
||||
-->
|
||||
例如，在你运行 `kops edit ig nodes` 之后，然后运行 `kops update cluster --yes`
|
||||
应用你的配置，有时你还必须运行 `kops rolling-update cluster` 立即回滚更新配置。
|
||||
|
||||
<!--
|
||||
Without `--yes`, `kops update cluster` will show you a preview of what it is going to do. This is handy
|
||||
for production clusters!
|
||||
-->
|
||||
如果没有 `--yes` 参数，`kops update cluster` 操作将向你显示其操作的预览效果。这对于生产集群很方便！
|
||||
|
||||
<!--
|
||||
### Explore other add-ons
|
||||
|
||||
See the [list of add-ons](/docs/concepts/cluster-administration/addons/) to explore other add-ons, including tools for logging, monitoring, network policy, visualization & control of your Kubernetes cluster.
|
||||
-->
|
||||
### 探索其他附加组件
|
||||
|
||||
请参阅[附加组件列表](/zh/docs/concepts/cluster-administration/addons/)探索其他附加组件，
|
||||
包括用于 Kubernetes 集群的日志记录、监视、网络策略、可视化和控制的工具。
|
||||
|
||||
<!--
|
||||
## Cleanup
|
||||
|
||||
* To delete your cluster: `kops delete cluster useast1.dev.example.com --yes`
|
||||
-->
|
||||
## 清理
|
||||
|
||||
* 删除集群：`kops delete cluster useast1.dev.example.com --yes`
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
<!--
|
||||
* Learn more about Kubernetes [concepts](/docs/concepts/) and [`kubectl`](/docs/reference/kubectl/).
|
||||
* Learn about `kops` [advanced usage](https://github.com/kubernetes/kops)
|
||||
* See the `kops` [docs](https://github.com/kubernetes/kops) section for tutorials, best practices and advanced configuration options.
|
||||
-->
|
||||
* 了解有关 Kubernetes 的[概念](/zh/docs/concepts/) 和
|
||||
[`kubectl`](/zh/docs/reference/kubectl/) 有关的更多信息。
|
||||
* 了解 `kops` [高级用法](https://github.com/kubernetes/kops)。
|
||||
* 请参阅 `kops` [文档](https://github.com/kubernetes/kops) 获取教程、
|
||||
最佳做法和高级配置选项。
|
||||
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "使用 kubeadm 引导集群"
|
||||
weight: 10
|
||||
---
|
||||
@@ -0,0 +1,358 @@
|
||||
---
|
||||
title: 使用 kubeadm API 定制组件
|
||||
content_type: concept
|
||||
weight: 40
|
||||
---
|
||||
<!--
|
||||
---
|
||||
reviewers:
|
||||
- sig-cluster-lifecycle
|
||||
title: Customizing components with the kubeadm API
|
||||
content_type: concept
|
||||
weight: 40
|
||||
---
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
This page covers how to customize the components that kubeadm deploys. For control plane components
|
||||
you can use flags in the `ClusterConfiguration` structure or patches per-node. For the kubelet
|
||||
and kube-proxy you can use `KubeletConfiguration` and `KubeProxyConfiguration`, accordingly.
|
||||
|
||||
All of these options are possible via the kubeadm configuration API.
|
||||
For more details on each field in the configuration you can navigate to our
|
||||
[API reference pages](/docs/reference/config-api/kubeadm-config.v1beta3/).
|
||||
-->
|
||||
本页面介绍了如何自定义 kubeadm 部署的组件。
|
||||
你可以使用 `ClusterConfiguration` 结构中定义的参数，或者在每个节点上应用补丁来定制控制平面组件。
|
||||
你可以使用 `KubeletConfiguration` 和 `KubeProxyConfiguration` 结构分别定制 kubelet 和 kube-proxy 组件。
|
||||
|
||||
所有这些选项都可以通过 kubeadm 配置 API 实现。
|
||||
有关配置中的每个字段的详细信息，你可以导航到我们的
|
||||
[API 参考页面](/docs/reference/config-api/kubeadm-config.v1beta3/) 。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
Customizing the CoreDNS deployment of kubeadm is currently not supported. You must manually
|
||||
patch the `kube-system/coredns` {{< glossary_tooltip text="ConfigMap" term_id="configmap" >}}
|
||||
and recreate the CoreDNS {{< glossary_tooltip text="Pods" term_id="pod" >}} after that. Alternatively,
|
||||
you can skip the default CoreDNS deployment and deploy your own variant.
|
||||
For more details on that see [Using init phases with kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm-init/#init-phases).
|
||||
-->
|
||||
kubeadm 目前不支持对 CoreDNS 部署进行定制。
|
||||
你必须手动更新 `kube-system/coredns` {{< glossary_tooltip text="ConfigMap" term_id="configmap" >}}
|
||||
并在更新后重新创建 CoreDNS {{< glossary_tooltip text="Pods" term_id="pod" >}}。
|
||||
或者，你可以跳过默认的 CoreDNS 部署并部署你自己的 CoreDNS 变种。
|
||||
有关更多详细信息，请参阅[在 kubeadm 中使用 init phases](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init/#init-phases).
|
||||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
To reconfigure a cluster that has already been created see
|
||||
[Reconfiguring a kubeadm cluster](/docs/tasks/administer-cluster/kubeadm/kubeadm-reconfigure).
|
||||
-->
|
||||
|
||||
要重新配置已创建的集群，请参阅[重新配置 kubeadm 集群](/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-reconfigure)。
|
||||
{{< /note >}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
## Customizing the control plane with flags in `ClusterConfiguration`
|
||||
|
||||
The kubeadm `ClusterConfiguration` object exposes a way for users to override the default
|
||||
flags passed to control plane components such as the APIServer, ControllerManager, Scheduler and Etcd.
|
||||
The components are defined using the following structures:
|
||||
-->
|
||||
## 使用 `ClusterConfiguration` 中的标志自定义控制平面 {#customizing-the-control-plane-with-flags-in-clusterconfiguration}
|
||||
|
||||
kubeadm `ClusterConfiguration` 对象为用户提供了一种方法，
|
||||
用以覆盖传递给控制平面组件（如 APIServer、ControllerManager、Scheduler 和 Etcd）的默认参数。
|
||||
各组件配置使用如下字段定义：
|
||||
|
||||
- `apiServer`
|
||||
- `controllerManager`
|
||||
- `scheduler`
|
||||
- `etcd`
|
||||
|
||||
<!--
|
||||
These structures contain a common `extraArgs` field, that consists of `key: value` pairs.
|
||||
To override a flag for a control plane component:
|
||||
-->
|
||||
这些结构包含一个通用的 `extraArgs` 字段，该字段由 `key: value` 组成。
|
||||
要覆盖控制平面组件的参数：
|
||||
|
||||
<!--
|
||||
1. Add the appropriate `extraArgs` to your configuration.
|
||||
2. Add flags to the `extraArgs` field.
|
||||
3. Run `kubeadm init` with `--config <YOUR CONFIG YAML>`.
|
||||
-->
|
||||
1. 将适当的字段 `extraArgs` 添加到配置中。
|
||||
2. 向字段 `extraArgs` 添加要覆盖的参数值。
|
||||
3. 用 `--config <YOUR CONFIG YAML>` 运行 `kubeadm init`。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
You can generate a `ClusterConfiguration` object with default values by running `kubeadm config print init-defaults`
|
||||
and saving the output to a file of your choice.
|
||||
-->
|
||||
你可以通过运行 `kubeadm config print init-defaults` 并将输出保存到你所选的文件中，
|
||||
以默认值形式生成 `ClusterConfiguration` 对象。
|
||||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
The `ClusterConfiguration` object is currently global in kubeadm clusters. This means that any flags that you add,
|
||||
will apply to all instances of the same component on different nodes. To apply individual configuration per component
|
||||
on different nodes you can use [patches](#patches).
|
||||
-->
|
||||
`ClusterConfiguration` 对象目前在 kubeadm 集群中是全局的。
|
||||
这意味着你添加的任何标志都将应用于同一组件在不同节点上的所有实例。
|
||||
要在不同节点上为每个组件应用单独的配置，你可以使用[补丁](#patches)。
|
||||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
Duplicate flags (keys), or passing the same flag `--foo` multiple times, is currently not supported.
|
||||
To workaround that you must use [patches](#patches).
|
||||
-->
|
||||
当前不支持重复的参数（keys）或多次传递相同的参数 `--foo`。
|
||||
要解决此问题，你必须使用[补丁](#patches)。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
## APIServer flags
|
||||
-->
|
||||
### APIServer 参数 {#apiserver-flags}
|
||||
|
||||
<!--
|
||||
For details, see the [reference documentation for kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/).
|
||||
-->
|
||||
有关详细信息，请参阅 [kube-apiserver 参考文档](/docs/reference/command-line-tools-reference/kube-apiserver/)。
|
||||
|
||||
<!--
|
||||
Example usage:
|
||||
-->
|
||||
使用示例：
|
||||
```yaml
|
||||
apiVersion: kubeadm.k8s.io/v1beta3
|
||||
kind: ClusterConfiguration
|
||||
kubernetesVersion: v1.16.0
|
||||
apiServer:
|
||||
extraArgs:
|
||||
anonymous-auth: "false"
|
||||
enable-admission-plugins: AlwaysPullImages,DefaultStorageClass
|
||||
audit-log-path: /home/johndoe/audit.log
|
||||
```
|
||||
|
||||
<!--
|
||||
## ControllerManager flags
|
||||
-->
|
||||
### ControllerManager 参数 {#controllermanager-flags}
|
||||
|
||||
<!--
|
||||
For details, see the [reference documentation for kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/).
|
||||
-->
|
||||
有关详细信息，请参阅 [kube-controller-manager 参考文档](/docs/reference/command-line-tools-reference/kube-controller-manager/)。
|
||||
|
||||
<!--
|
||||
Example usage:
|
||||
-->
|
||||
使用示例：
|
||||
```yaml
|
||||
apiVersion: kubeadm.k8s.io/v1beta3
|
||||
kind: ClusterConfiguration
|
||||
kubernetesVersion: v1.16.0
|
||||
controllerManager:
|
||||
extraArgs:
|
||||
cluster-signing-key-file: /home/johndoe/keys/ca.key
|
||||
deployment-controller-sync-period: "50"
|
||||
```
|
||||
|
||||
<!--
|
||||
### Scheduler flags
|
||||
-->
|
||||
## Scheduler 参数 {#scheduler-flags}
|
||||
|
||||
<!--
|
||||
For details, see the [reference documentation for kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/).
|
||||
-->
|
||||
有关详细信息，请参阅 [kube-scheduler 参考文档](/docs/reference/command-line-tools-reference/kube-scheduler/)。
|
||||
|
||||
<!--
|
||||
Example usage:
|
||||
-->
|
||||
使用示例：
|
||||
```yaml
|
||||
apiVersion: kubeadm.k8s.io/v1beta3
|
||||
kind: ClusterConfiguration
|
||||
kubernetesVersion: v1.16.0
|
||||
scheduler:
|
||||
extraArgs:
|
||||
config: /etc/kubernetes/scheduler-config.yaml
|
||||
extraVolumes:
|
||||
- name: schedulerconfig
|
||||
hostPath: /home/johndoe/schedconfig.yaml
|
||||
mountPath: /etc/kubernetes/scheduler-config.yaml
|
||||
readOnly: true
|
||||
pathType: "File"
|
||||
```
|
||||
<!--
|
||||
### Etcd flags
|
||||
|
||||
For details, see the [etcd server documentation](https://etcd.io/docs/).
|
||||
|
||||
Example usage:
|
||||
-->
|
||||
### Etcd 参数 {#etcd-flags}
|
||||
|
||||
有关详细信息，请参阅 [etcd 服务文档](https://etcd.io/docs/).
|
||||
|
||||
使用示例：
|
||||
|
||||
```yaml
|
||||
apiVersion: kubeadm.k8s.io/v1beta3
|
||||
kind: ClusterConfiguration
|
||||
etcd:
|
||||
local:
|
||||
extraArgs:
|
||||
election-timeout: 1000
|
||||
```
|
||||
<!--
|
||||
## Customizing the control plane with patches {#patches}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.22" state="beta" >}}
|
||||
|
||||
Kubeadm allows you to pass a directory with patch files to `InitConfiguration` and `JoinConfiguration`
|
||||
on individual nodes. These patches can be used as the last customization step before the control
|
||||
plane component manifests are written to disk.
|
||||
|
||||
You can pass this file to `kubeadm init` with `--config <YOUR CONFIG YAML>`:
|
||||
-->
|
||||
## 使用补丁定制控制平面 {#patches}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.22" state="beta" >}}
|
||||
|
||||
Kubeadm 允许将包含补丁文件的目录传递给各个节点上的 `InitConfiguration` 和 `JoinConfiguration`。
|
||||
这些补丁可被用作控制平面组件清单写入磁盘之前的最后一个自定义步骤。
|
||||
|
||||
可以使用 `--config <你的 YAML 格式控制文件>` 将配置文件传递给 `kubeadm init`：
|
||||
|
||||
```yaml
|
||||
apiVersion: kubeadm.k8s.io/v1beta3
|
||||
kind: InitConfiguration
|
||||
patches:
|
||||
directory: /home/user/somedir
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
For `kubeadm init` you can pass a file containing both a `ClusterConfiguration` and `InitConfiguration`
|
||||
separated by `---`.
|
||||
-->
|
||||
对于 `kubeadm init`，你可以传递一个包含 `ClusterConfiguration` 和 `InitConfiguration` 的文件，以 `---` 分隔。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
You can pass this file to `kubeadm join` with `--config <YOUR CONFIG YAML>`:
|
||||
-->
|
||||
你可以使用 `--config <你的 YAML 格式配置文件>` 将配置文件传递给 `kubeadm join`：
|
||||
|
||||
```yaml
|
||||
apiVersion: kubeadm.k8s.io/v1beta3
|
||||
kind: JoinConfiguration
|
||||
patches:
|
||||
directory: /home/user/somedir
|
||||
```
|
||||
|
||||
<!--
|
||||
The directory must contain files named `target[suffix][+patchtype].extension`.
|
||||
For example, `kube-apiserver0+merge.yaml` or just `etcd.json`.
|
||||
-->
|
||||
补丁目录必须包含名为 `target[suffix][+patchtype].extension` 的文件。
|
||||
例如，`kube-apiserver0+merge.yaml` 或只是 `etcd.json`。
|
||||
|
||||
<!--
|
||||
- `target` can be one of `kube-apiserver`, `kube-controller-manager`, `kube-scheduler` and `etcd`.
|
||||
- `patchtype` can be one of `strategic`, `merge` or `json` and these must match the patching formats
|
||||
[supported by kubectl](/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch).
|
||||
The default `patchtype` is `strategic`.
|
||||
- `extension` must be either `json` or `yaml`.
|
||||
- `suffix` is an optional string that can be used to determine which patches are applied first
|
||||
alpha-numerically.
|
||||
-->
|
||||
- `target` 可以是 `kube-apiserver`、`kube-controller-manager`、`kube-scheduler` 和 `etcd` 之一。
|
||||
- `patchtype` 可以是 `strategy`、`merge` 或 `json` 之一，并且这些必须匹配
|
||||
[kubectl 支持](/zh/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch) 的补丁格式。
|
||||
默认补丁类型是 `strategic` 的。
|
||||
- `extension` 必须是 `json` 或 `yaml`。
|
||||
- `suffix` 是一个可选字符串，可用于确定首先按字母数字应用哪些补丁。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
If you are using `kubeadm upgrade` to upgrade your kubeadm nodes you must again provide the same
|
||||
patches, so that the customization is preserved after upgrade. To do that you can use the `--patches`
|
||||
flag, which must point to the same directory. `kubeadm upgrade` currently does not support a configuration
|
||||
API structure that can be used for the same purpose.
|
||||
-->
|
||||
如果你使用 `kubeadm upgrade` 升级 kubeadm 节点，你必须再次提供相同的补丁，以便在升级后保留自定义配置。
|
||||
为此，你可以使用 `--patches` 参数，该参数必须指向同一目录。 `kubeadm upgrade` 目前不支持用于相同目的的 API 结构配置。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
## Customizing the kubelet
|
||||
|
||||
To customize the kubelet you can add a `KubeletConfiguration` next to the `ClusterConfiguration` or
|
||||
`InitConfiguration` separated by `---` within the same configuration file. This file can then be passed to `kubeadm init`.
|
||||
-->
|
||||
## 自定义 kubelet {#customizing-the-kubelet}
|
||||
|
||||
要自定义 kubelet，你可以在同一配置文件中的 `ClusterConfiguration` 或 `InitConfiguration`
|
||||
之外添加一个 `KubeletConfiguration`，用 `---` 分隔。
|
||||
然后可以将此文件传递给 `kubeadm init`。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
kubeadm applies the same `KubeletConfiguration` to all nodes in the cluster. To apply node
|
||||
specific settings you can use kubelet flags as overrides by passing them in the `nodeRegistration.kubeletExtraArgs`
|
||||
field supported by both `InitConfiguration` and `JoinConfiguration`. Some kubelet flags are deprecated,
|
||||
so check their status in the [kubelet reference documentation](/docs/reference/command-line-tools-reference/kubelet)
|
||||
before using them.
|
||||
-->
|
||||
kubeadm 将相同的 `KubeletConfiguration` 配置应用于集群中的所有节点。
|
||||
要应用节点特定设置，你可以使用 `kubelet` 参数进行覆盖，方法是将它们传递到 `InitConfiguration` 和 `JoinConfiguration`
|
||||
支持的 `nodeRegistration.kubeletExtraArgs` 字段中。一些 kubelet 参数已被弃用，
|
||||
因此在使用这些参数之前，请在 [kubelet 参考文档](/zh/docs/reference/command-line-tools-reference/kubelet) 中检查它们的状态。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
For more details see [Configuring each kubelet in your cluster using kubeadm](/docs/setup/production-environment/tools/kubeadm/kubelet-integration)
|
||||
-->
|
||||
更多详情，请参阅[使用 kubeadm 配置集群中的每个 kubelet](/zh/docs/setup/production-environment/tools/kubeadm/kubelet-integration)
|
||||
|
||||
<!--
|
||||
## Customizing kube-proxy
|
||||
|
||||
To customize kube-proxy you can pass a `KubeProxyConfiguration` next your `ClusterConfiguration` or
|
||||
`InitConfiguration` to `kubeadm init` separated by `---`.
|
||||
|
||||
For more details you can navigate to our [API reference pages](/docs/reference/config-api/kubeadm-config.v1beta3/).
|
||||
-->
|
||||
## 自定义 kube-proxy {#customizing-kube-proxy}
|
||||
|
||||
要自定义 kube-proxy，你可以在 `ClusterConfiguration` 或 `InitConfiguration` 之外添加一个
|
||||
由 `---` 分隔的 `KubeProxyConfiguration`， 传递给 `kubeadm init`。
|
||||
|
||||
可以导航到 [API 参考页面](/docs/reference/config-api/kubeadm-config.v1beta3/) 查看更多详情，
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
kubeadm deploys kube-proxy as a {{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}}, which means
|
||||
that the `KubeProxyConfiguration` would apply to all instances of kube-proxy in the cluster.
|
||||
-->
|
||||
kubeadm 将 kube-proxy 部署为 {{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}}，
|
||||
这意味着 `KubeProxyConfiguration` 将应用于集群中的所有 kube-proxy 实例。
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
+1127
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,248 @@
|
||||
---
|
||||
title: 使用 kubeadm 支持双协议栈
|
||||
content_type: task
|
||||
weight: 110
|
||||
min-kubernetes-server-version: 1.21
|
||||
---
|
||||
|
||||
<!--
|
||||
title: Dual-stack support with kubeadm
|
||||
content_type: task
|
||||
weight: 110
|
||||
min-kubernetes-server-version: 1.21
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
{{< feature-state for_k8s_version="v1.23" state="stable" >}}
|
||||
|
||||
<!--
|
||||
Your Kubernetes cluster includes [dual-stack](/docs/concepts/services-networking/dual-stack/) networking, which means that cluster networking lets you use either address family. In a cluster, the control plane can assign both an IPv4 address and an IPv6 address to a single {{< glossary_tooltip text="Pod" term_id="pod" >}} or a {{< glossary_tooltip text="Service" term_id="service" >}}.
|
||||
-->
|
||||
你的集群包含[双协议栈](/zh/docs/concepts/services-networking/dual-stack/)组网支持，
|
||||
这意味着集群网络允许你在两种地址族间任选其一。在集群中，控制面可以为同一个
|
||||
{{< glossary_tooltip text="Pod" term_id="pod" >}} 或者 {{< glossary_tooltip text="Service" term_id="service" >}}
|
||||
同时赋予 IPv4 和 IPv6 地址。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
<!--
|
||||
You need to have installed the {{< glossary_tooltip text="kubeadm" term_id="kubeadm" >}} tool, following the steps from [Installing kubeadm](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/).
|
||||
-->
|
||||
你需要已经遵从[安装 kubeadm](/zh/docs/setup/production-environment/tools/kubeadm/install-kubeadm/)
|
||||
中所给的步骤安装了 {{< glossary_tooltip text="kubeadm" term_id="kubeadm" >}} 工具。
|
||||
|
||||
<!--
|
||||
For each server that you want to use as a {{< glossary_tooltip text="node" term_id="node" >}}, make sure it allows IPv6 forwarding. On Linux, you can set this by running run `sysctl -w net.ipv6.conf.all.forwarding=1` as the root user on each server.
|
||||
-->
|
||||
针对你要作为{{< glossary_tooltip text="节点" term_id="node" >}}使用的每台服务器，
|
||||
确保其允许 IPv6 转发。在 Linux 节点上，你可以通过以 root 用户在每台服务器上运行
|
||||
`sysctl -w net.ipv6.conf.all.forwarding=1` 来完成设置。
|
||||
|
||||
<!--
|
||||
You need to have an IPv4 and and IPv6 address range to use. Cluster operators typically
|
||||
use private address ranges for IPv4. For IPv6, a cluster operator typically chooses a global
|
||||
unicast address block from within `2000::/3`, using a range that is assigned to the operator.
|
||||
You don't have to route the cluster's IP address ranges to the public internet.
|
||||
|
||||
The size of the IP address allocations should be suitable for the number of Pods and
|
||||
Services that you are planning to run.
|
||||
-->
|
||||
你需要一个可以使用的 IPv4 和 IPv6 地址范围。集群操作人员通常为 IPv4 使用
|
||||
私有地址范围。对于 IPv6，集群操作人员通常会基于分配给该操作人员的地址范围，
|
||||
从 `2000::/3` 中选择一个全局的单播地址块。你不需要将集群的 IP 地址范围路由
|
||||
到公众互联网。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
If you are upgrading an existing cluster with the `kubeadm upgrade` command,
|
||||
`kubeadm` does not support making modifications to the pod IP address range
|
||||
(“cluster CIDR”) nor to the cluster's Service address range (“Service CIDR”).
|
||||
-->
|
||||
如果你在使用 `kubeadm upgrade` 命令升级现有的集群，`kubeadm` 不允许更改 Pod
|
||||
的 IP 地址范围（“集群 CIDR”），也不允许更改集群的服务地址范围（“Service CIDR”）。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
### Create a dual-stack cluster
|
||||
|
||||
To create a dual-stack cluster with `kubeadm init` you can pass command line arguments
|
||||
similar to the following example:
|
||||
-->
|
||||
### 创建双协议栈集群 {#create-a-dual-stack-cluster}
|
||||
|
||||
要使用 `kubeadm init` 创建一个双协议栈集群，你可以传递与下面的例子类似的命令行参数：
|
||||
|
||||
```shell
|
||||
# 这里的地址范围仅作示例使用
|
||||
kubeadm init --pod-network-cidr=10.244.0.0/16,2001:db8:42:0::/56 --service-cidr=10.96.0.0/16,2001:db8:42:1::/112
|
||||
```
|
||||
|
||||
<!--
|
||||
To make things clearer, here is an example kubeadm
|
||||
[configuration file](/docs/reference/config-api/kubeadm-config.v1beta3/)
|
||||
`kubeadm-config.yaml` for the primary dual-stack control plane node.
|
||||
-->
|
||||
为了更便于理解，参看下面的名为 `kubeadm-config.yaml` 的 kubeadm
|
||||
[配置文件](/zh/docs/reference/config-api/kubeadm-config.v1beta3/)，
|
||||
该文件用于双协议栈控制面的主控制节点。
|
||||
|
||||
```yaml
|
||||
---
|
||||
apiVersion: kubeadm.k8s.io/v1beta3
|
||||
kind: ClusterConfiguration
|
||||
networking:
|
||||
podSubnet: 10.244.0.0/16,2001:db8:42:0::/56
|
||||
serviceSubnet: 10.96.0.0/16,2001:db8:42:1::/112
|
||||
---
|
||||
apiVersion: kubeadm.k8s.io/v1beta3
|
||||
kind: InitConfiguration
|
||||
localAPIEndpoint:
|
||||
advertiseAddress: "10.100.0.1"
|
||||
bindPort: 6443
|
||||
nodeRegistration:
|
||||
kubeletExtraArgs:
|
||||
node-ip: 10.100.0.2,fd00:1:2:3::2
|
||||
```
|
||||
|
||||
<!--
|
||||
`advertiseAddress` in InitConfiguration specifies the IP address that the API Server will advertise it is listening on. The value of `advertiseAddress` equals the `--apiserver-advertise-address` flag of `kubeadm init`
|
||||
|
||||
Run kubeadm to initiate the dual-stack control plane node:
|
||||
-->
|
||||
InitConfiguration 中的 `advertiseAddress` 给出 API 服务器将公告自身要监听的
|
||||
IP 地址。`advertiseAddress` 的取值与 `kubeadm init` 的标志
|
||||
`--apiserver-advertise-address` 的取值相同。
|
||||
|
||||
运行 kubeadm 来实例化双协议栈控制面节点：
|
||||
|
||||
```shell
|
||||
kubeadm init --config=kubeadm-config.yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
The kube-controller-manager flags `--node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6` are set with default values. See [configure IPv4/IPv6 dual stack](/docs/concepts/services-networking/dual-stack#configure-ipv4-ipv6-dual-stack).
|
||||
-->
|
||||
kube-controller-manager 标志 `--node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6`
|
||||
是使用默认值来设置的。参见[配置 IPv4/IPv6 双协议栈](/zh/docs/concepts/services-networking/dual-stack#configure-ipv4-ipv6-dual-stack)。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
The `--apiserver-advertise-address` flag does not support dual-stack.
|
||||
-->
|
||||
标志 `--apiserver-advertise-address` 不支持双协议栈。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
### Join a node to dual-stack cluster
|
||||
|
||||
Before joining a node, make sure that the node has IPv6 routable network interface and allows IPv6 forwarding.
|
||||
|
||||
Here is an example kubeadm [configuration file](/docs/reference/config-api/kubeadm-config.v1beta3/)
|
||||
`kubeadm-config.yaml` for joining a worker node to the cluster.
|
||||
-->
|
||||
### 向双协议栈集群添加节点 {#join-a-node-to-dual-stack-cluster}
|
||||
|
||||
在添加节点之前，请确保该节点具有 IPv6 可路由的网络接口并且启用了 IPv6 转发。
|
||||
|
||||
下面的名为 `kubeadm-config.yaml` 的 kubeadm
|
||||
[配置文件](/zh/docs/reference/config-api/kubeadm-config.v1beta3/)
|
||||
示例用于向集群中添加工作节点。
|
||||
|
||||
```yaml
|
||||
apiVersion: kubeadm.k8s.io/v1beta3
|
||||
kind: JoinConfiguration
|
||||
discovery:
|
||||
bootstrapToken:
|
||||
apiServerEndpoint: 10.100.0.1:6443
|
||||
token: "clvldh.vjjwg16ucnhp94qr"
|
||||
caCertHashes:
|
||||
- "sha256:a4863cde706cfc580a439f842cc65d5ef112b7b2be31628513a9881cf0d9fe0e"
|
||||
# 请更改上面的认证信息，使之与你的集群中实际使用的令牌和 CA 证书匹配
|
||||
nodeRegistration:
|
||||
kubeletExtraArgs:
|
||||
node-ip: 10.100.0.3,fd00:1:2:3::3
|
||||
```
|
||||
|
||||
<!--
|
||||
Also, here is an example kubeadm [configuration file](/docs/reference/config-api/kubeadm-config.v1beta3/)
|
||||
`kubeadm-config.yaml` for joining another control plane node to the cluster.
|
||||
-->
|
||||
下面的名为 `kubeadm-config.yaml` 的 kubeadm
|
||||
[配置文件](/zh/docs/reference/config-api/kubeadm-config.v1beta3/)
|
||||
示例用于向集群中添加另一个控制面节点。
|
||||
|
||||
```yaml
|
||||
apiVersion: kubeadm.k8s.io/v1beta3
|
||||
kind: JoinConfiguration
|
||||
controlPlane:
|
||||
localAPIEndpoint:
|
||||
advertiseAddress: "10.100.0.2"
|
||||
bindPort: 6443
|
||||
discovery:
|
||||
bootstrapToken:
|
||||
apiServerEndpoint: 10.100.0.1:6443
|
||||
token: "clvldh.vjjwg16ucnhp94qr"
|
||||
caCertHashes:
|
||||
- "sha256:a4863cde706cfc580a439f842cc65d5ef112b7b2be31628513a9881cf0d9fe0e"
|
||||
# 请更改上面的认证信息，使之与你的集群中实际使用的令牌和 CA 证书匹配
|
||||
nodeRegistration:
|
||||
kubeletExtraArgs:
|
||||
node-ip: 10.100.0.4,fd00:1:2:3::4
|
||||
```
|
||||
|
||||
<!--
|
||||
`advertiseAddress` in JoinConfiguration.controlPlane specifies the IP address that the API Server will advertise it is listening on. The value of `advertiseAddress` equals the `--apiserver-advertise-address` flag of `kubeadm join`.
|
||||
-->
|
||||
JoinConfiguration.controlPlane 中的 `advertiseAddress` 设定 API 服务器将公告自身要监听的
|
||||
IP 地址。`advertiseAddress` 的取值与 `kubeadm join` 的标志
|
||||
`--apiserver-advertise-address` 的取值相同。
|
||||
|
||||
```shell
|
||||
kubeadm join --config=kubeadm-config.yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
### Create a single-stack cluster
|
||||
-->
|
||||
### 创建单协议栈集群 {#create-a-single-stack-cluster}
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
Dual-stack support doesn't mean that you need to use dual-stack addressing.
|
||||
You can deploy a single-stack cluster that has the dual-stack networking feature enabled.
|
||||
-->
|
||||
双协议栈支持并不意味着你需要使用双协议栈来寻址。
|
||||
你可以部署一个启用了双协议栈联网特性的单协议栈集群。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
To make things more clear, here is an example kubeadm
|
||||
[configuration file](/docs/reference/config-api/kubeadm-config.v1beta3/)
|
||||
`kubeadm-config.yaml` for the single-stack control plane node.
|
||||
-->
|
||||
为了更便于理解，参看下面的名为 `kubeadm-config.yaml` 的 kubeadm
|
||||
[配置文件](/zh/docs/reference/config-api/kubeadm-config.v1beta3/)示例，
|
||||
该文件用于单协议栈控制面节点。
|
||||
|
||||
```yaml
|
||||
apiVersion: kubeadm.k8s.io/v1beta3
|
||||
kind: ClusterConfiguration
|
||||
networking:
|
||||
podSubnet: 10.244.0.0/16
|
||||
serviceSubnet: 10.96.0.0/16
|
||||
```
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
<!--
|
||||
* [Validate IPv4/IPv6 dual-stack](/docs/tasks/network/validate-dual-stack) networking
|
||||
* Read about [Dual-stack](/docs/concepts/services-networking/dual-stack/) cluster networking
|
||||
* Learn more about the kubeadm [configuration format](/docs/reference/config-api/kubeadm-config.v1beta3/)
|
||||
-->
|
||||
* [验证 IPv4/IPv6 双协议栈](/zh/docs/tasks/network/validate-dual-stack)联网
|
||||
* 阅读[双协议栈](/zh/docs/concepts/services-networking/dual-stack/)集群网络
|
||||
* 进一步了解 kubeadm [配置格式](/docs/reference/config-api/kubeadm-config.v1beta3/)
|
||||
|
||||
@@ -0,0 +1,159 @@
|
||||
---
|
||||
title: 高可用拓扑选项
|
||||
content_type: concept
|
||||
weight: 50
|
||||
---
|
||||
<!--
|
||||
reviewers:
|
||||
- sig-cluster-lifecycle
|
||||
title: Options for Highly Available Topology
|
||||
content_type: concept
|
||||
weight: 50
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
This page explains the two options for configuring the topology of your highly available (HA) Kubernetes clusters.
|
||||
-->
|
||||
本页面介绍了配置高可用（HA）Kubernetes 集群拓扑的两个选项。
|
||||
|
||||
<!--
|
||||
You can set up an HA cluster:
|
||||
-->
|
||||
你可以设置 HA 集群：
|
||||
|
||||
<!--
|
||||
- With stacked control plane nodes, where etcd nodes are colocated with control plane nodes
|
||||
- With external etcd nodes, where etcd runs on separate nodes from the control plane
|
||||
-->
|
||||
- 使用堆叠（stacked）控制平面节点，其中 etcd 节点与控制平面节点共存
|
||||
- 使用外部 etcd 节点，其中 etcd 在与控制平面不同的节点上运行
|
||||
|
||||
<!--
|
||||
You should carefully consider the advantages and disadvantages of each topology before setting up an HA cluster.
|
||||
-->
|
||||
在设置 HA 集群之前，你应该仔细考虑每种拓扑的优缺点。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
kubeadm bootstraps the etcd cluster statically. Read the etcd [Clustering Guide](https://github.com/etcd-io/etcd/blob/release-3.4/Documentation/op-guide/clustering.md#static)
|
||||
for more details.
|
||||
-->
|
||||
kubeadm 静态引导 etcd 集群。
|
||||
阅读 etcd [集群指南](https://github.com/etcd-io/etcd/blob/release-3.4/Documentation/op-guide/clustering.md#static)以获得更多详细信息。
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
## Stacked etcd topology
|
||||
-->
|
||||
## 堆叠（Stacked）etcd 拓扑 {#stacked-etcd-topology}
|
||||
|
||||
<!--
|
||||
A stacked HA cluster is a [topology](https://en.wikipedia.org/wiki/Network_topology) where the distributed
|
||||
data storage cluster provided by etcd is stacked on top of the cluster formed by the nodes managed by
|
||||
kubeadm that run control plane components.
|
||||
-->
|
||||
堆叠（Stacked）HA 集群是一种这样的[拓扑](https://en.wikipedia.org/wiki/Network_topology)，
|
||||
其中 etcd 分布式数据存储集群堆叠在 kubeadm 管理的控制平面节点上，作为控制平面的一个组件运行。
|
||||
|
||||
<!--
|
||||
Each control plane node runs an instance of the `kube-apiserver`, `kube-scheduler`, and `kube-controller-manager`.
|
||||
-->
|
||||
每个控制平面节点运行 `kube-apiserver`、`kube-scheduler` 和 `kube-controller-manager` 实例。
|
||||
<!--
|
||||
The `kube-apiserver` is exposed to worker nodes using a load balancer.
|
||||
-->
|
||||
`kube-apiserver` 使用负载均衡器暴露给工作节点。
|
||||
|
||||
<!--
|
||||
Each control plane node creates a local etcd member and this etcd member communicates only with
|
||||
the `kube-apiserver` of this node. The same applies to the local `kube-controller-manager`
|
||||
and `kube-scheduler` instances.
|
||||
-->
|
||||
每个控制平面节点创建一个本地 etcd 成员（member），这个 etcd 成员只与该节点的 `kube-apiserver` 通信。
|
||||
这同样适用于本地 `kube-controller-manager` 和 `kube-scheduler` 实例。
|
||||
|
||||
<!--
|
||||
This topology couples the control planes and etcd members on the same nodes. It is simpler to set up than a cluster
|
||||
with external etcd nodes, and simpler to manage for replication.
|
||||
-->
|
||||
这种拓扑将控制平面和 etcd 成员耦合在同一节点上。相对使用外部 etcd 集群，
|
||||
设置起来更简单，而且更易于副本管理。
|
||||
|
||||
<!--
|
||||
However, a stacked cluster runs the risk of failed coupling. If one node goes down, both an etcd member and a control
|
||||
plane instance are lost, and redundancy is compromised. You can mitigate this risk by adding more control plane nodes.
|
||||
-->
|
||||
然而，堆叠集群存在耦合失败的风险。如果一个节点发生故障，则 etcd 成员和控制平面实例都将丢失，
|
||||
并且冗余会受到影响。你可以通过添加更多控制平面节点来降低此风险。
|
||||
|
||||
<!--
|
||||
You should therefore run a minimum of three stacked control plane nodes for an HA cluster.
|
||||
-->
|
||||
因此，你应该为 HA 集群运行至少三个堆叠的控制平面节点。
|
||||
|
||||
<!--
|
||||
This is the default topology in kubeadm. A local etcd member is created automatically
|
||||
on control plane nodes when using `kubeadm init` and `kubeadm join --control-plane`.
|
||||
-->
|
||||
这是 kubeadm 中的默认拓扑。当使用 `kubeadm init` 和 `kubeadm join --control-plane` 时，
|
||||
在控制平面节点上会自动创建本地 etcd 成员。
|
||||
|
||||
<!--
|
||||
|
||||
-->
|
||||
|
||||
|
||||
<!--
|
||||
## External etcd topology
|
||||
-->
|
||||
## 外部 etcd 拓扑 {#external-etcd-topology}
|
||||
|
||||
<!--
|
||||
An HA cluster with external etcd is a [topology](https://en.wikipedia.org/wiki/Network_topology) where the distributed data storage cluster provided by etcd is external to the cluster formed by the nodes that run control plane components.
|
||||
-->
|
||||
具有外部 etcd 的 HA 集群是一种这样的[拓扑](https://zh.wikipedia.org/wiki/%E7%BD%91%E7%BB%9C%E6%8B%93%E6%89%91)，
|
||||
其中 etcd 分布式数据存储集群在独立于控制平面节点的其他节点上运行。
|
||||
|
||||
<!--
|
||||
Like the stacked etcd topology, each control plane node in an external etcd topology runs an instance of the `kube-apiserver`, `kube-scheduler`, and `kube-controller-manager`. And the `kube-apiserver` is exposed to worker nodes using a load balancer. However, etcd members run on separate hosts, and each etcd host communicates with the `kube-apiserver` of each control plane node.
|
||||
-->
|
||||
就像堆叠的 etcd 拓扑一样，外部 etcd 拓扑中的每个控制平面节点都运行 `kube-apiserver`，`kube-scheduler` 和 `kube-controller-manager` 实例。
|
||||
同样，`kube-apiserver` 使用负载均衡器暴露给工作节点。但是 etcd 成员在不同的主机上运行，
|
||||
每个 etcd 主机与每个控制平面节点的 `kube-apiserver` 通信。
|
||||
|
||||
<!--
|
||||
This topology decouples the control plane and etcd member. It therefore provides an HA setup where
|
||||
losing a control plane instance or an etcd member has less impact and does not affect
|
||||
the cluster redundancy as much as the stacked HA topology.
|
||||
-->
|
||||
这种拓扑结构解耦了控制平面和 etcd 成员。因此它提供了一种 HA 设置，
|
||||
其中失去控制平面实例或者 etcd 成员的影响较小，并且不会像堆叠的 HA 拓扑那样影响集群冗余。
|
||||
|
||||
<!--
|
||||
However, this topology requires twice the number of hosts as the stacked HA topology.
|
||||
-->
|
||||
但此拓扑需要两倍于堆叠 HA 拓扑的主机数量。
|
||||
<!--
|
||||
A minimum of three hosts for control plane nodes and three hosts for etcd nodes are required for an HA cluster with this topology.
|
||||
-->
|
||||
具有此拓扑的 HA 集群至少需要三个用于控制平面节点的主机和三个用于 etcd 节点的主机。
|
||||
|
||||
<!--
|
||||
|
||||
-->
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
<!--
|
||||
- [Set up a highly available cluster with kubeadm](/docs/setup/production-environment/tools/kubeadm/high-availability/)
|
||||
-->
|
||||
- [使用 kubeadm 设置高可用集群](/zh/docs/setup/production-environment/tools/kubeadm/high-availability/)
|
||||
|
||||
|
||||
@@ -0,0 +1,755 @@
|
||||
---
|
||||
title: 利用 kubeadm 创建高可用集群
|
||||
content_type: task
|
||||
weight: 60
|
||||
---
|
||||
|
||||
<!--
|
||||
reviewers:
|
||||
- sig-cluster-lifecycle
|
||||
title: Creating Highly Available Clusters with kubeadm
|
||||
content_type: task
|
||||
weight: 60
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
This page explains two different approaches to setting up a highly available Kubernetes
|
||||
cluster using kubeadm:
|
||||
|
||||
- With stacked control plane nodes. This approach requires less infrastructure. The etcd members
|
||||
and control plane nodes are co-located.
|
||||
- With an external etcd cluster. This approach requires more infrastructure. The
|
||||
control plane nodes and etcd members are separated.
|
||||
|
||||
-->
|
||||
本文讲述了使用 kubeadm 设置一个高可用的 Kubernetes 集群的两种不同方式：
|
||||
|
||||
- 使用具有堆叠的控制平面节点。这种方法所需基础设施较少。etcd 成员和控制平面节点位于同一位置。
|
||||
- 使用外部集群。这种方法所需基础设施较多。控制平面的节点和 etcd 成员是分开的。
|
||||
|
||||
<!--
|
||||
Before proceeding, you should carefully consider which approach best meets the needs of your applications
|
||||
and environment. [Options for Highly Available topology](/docs/setup/production-environment/tools/kubeadm/ha-topology/) outlines the advantages and disadvantages of each.
|
||||
|
||||
If you encounter issues with setting up the HA cluster, please report these
|
||||
in the kubeadm [issue tracker](https://github.com/kubernetes/kubeadm/issues/new).
|
||||
|
||||
See also the [upgrade documentation](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-15).
|
||||
-->
|
||||
在下一步之前，你应该仔细考虑哪种方法更好的满足你的应用程序和环境的需求。
|
||||
[高可用拓扑选项](/zh/docs/setup/production-environment/tools/kubeadm/ha-topology/) 讲述了每种方法的优缺点。
|
||||
|
||||
如果你在安装 HA 集群时遇到问题，请在 kubeadm [问题跟踪](https://github.com/kubernetes/kubeadm/issues/new)里向我们提供反馈。
|
||||
|
||||
你也可以阅读[升级文档](/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
|
||||
<!--
|
||||
This page does not address running your cluster on a cloud provider. In a cloud
|
||||
environment, neither approach documented here works with Service objects of type
|
||||
LoadBalancer, or with dynamic PersistentVolumes.
|
||||
-->
|
||||
{{< caution >}}
|
||||
这篇文档没有讲述在云提供商上运行集群的问题。在云环境中，此处记录的方法不适用于类型为 LoadBalancer 的服务对象，或者具有动态的 PersistentVolumes。
|
||||
{{< /caution >}}
|
||||
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
<!--
|
||||
The prerequisites depend on which topology you have selected for your cluster's
|
||||
control plane:
|
||||
-->
|
||||
根据集群控制平面所选择的拓扑结构不同，准备工作也有所差异：
|
||||
|
||||
{{< tabs name="prerequisite_tabs" >}}
|
||||
{{% tab name="堆叠（Stacked） etcd 拓扑" %}}
|
||||
<!--
|
||||
note to reviewers: these prerequisites should match the start of the
|
||||
external etc tab
|
||||
-->
|
||||
<!--
|
||||
You need:
|
||||
|
||||
- Three or more machines that meet [kubeadm's minimum requirements](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#before-you-begin) for
|
||||
the control-plane nodes. Having an odd number of control plane nodes can help
|
||||
with leader selection in the case of machine or zone failure.
|
||||
- including a {{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}, already set up and working
|
||||
- Three or more machines that meet [kubeadm's minimum
|
||||
requirements](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#before-you-begin) for the workers
|
||||
- including a container runtime, already set up and working
|
||||
- Full network connectivity between all machines in the cluster (public or
|
||||
private network)
|
||||
- Superuser privileges on all machines using `sudo`
|
||||
- You can use a different tool; this guide uses `sudo` in the examples.
|
||||
- SSH access from one device to all nodes in the system
|
||||
- `kubeadm` and `kubelet` already installed on all machines.
|
||||
|
||||
_See [Stacked etcd topology](/docs/setup/production-environment/tools/kubeadm/ha-topology/#stacked-etcd-topology) for context._
|
||||
-->
|
||||
需要准备：
|
||||
|
||||
- 配置满足 [kubeadm 的最低要求](/zh/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#准备开始)
|
||||
的三台机器作为控制面节点。奇数台控制平面节点有利于机器故障或者网络分区时进行重新选主。
|
||||
- 机器已经安装好{{< glossary_tooltip text="容器运行时" term_id="container-runtime" >}}，并正常运行
|
||||
- 配置满足 [kubeadm 的最低要求](/zh/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#准备开始)
|
||||
的三台机器作为工作节点
|
||||
- 机器已经安装好{{< glossary_tooltip text="容器运行时" term_id="container-runtime" >}}，并正常运行
|
||||
- 在集群中，确保所有计算机之间存在全网络连接（公网或私网）
|
||||
- 在所有机器上具有 sudo 权限
|
||||
- 可以使用其他工具；本教程以 `sudo` 举例
|
||||
- 从某台设备通过 SSH 访问系统中所有节点的能力
|
||||
- 所有机器上已经安装 `kubeadm` 和 `kubelet`
|
||||
|
||||
_拓扑详情请参考[堆叠（Stacked）etcd 拓扑](/zh/docs/setup/production-environment/tools/kubeadm/ha-topology/#堆叠-stacked-etcd-拓扑)。_
|
||||
{{% /tab %}}
|
||||
{{% tab name="外部 etcd 拓扑" %}}
|
||||
<!--
|
||||
note to reviewers: these prerequisites should match the start of the
|
||||
stacked etc tab
|
||||
-->
|
||||
<!--
|
||||
You need:
|
||||
|
||||
- Three or more machines that meet [kubeadm's minimum requirements](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#before-you-begin) for
|
||||
the control-plane nodes. Having an odd number of control plane nodes can help
|
||||
with leader selection in the case of machine or zone failure.
|
||||
- including a {{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}, already set up and working
|
||||
- Three or more machines that meet [kubeadm's minimum
|
||||
requirements](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#before-you-begin) for the workers
|
||||
- including a container runtime, already set up and working
|
||||
- Full network connectivity between all machines in the cluster (public or
|
||||
private network)
|
||||
- Superuser privileges on all machines using `sudo`
|
||||
- You can use a different tool; this guide uses `sudo` in the examples.
|
||||
- SSH access from one device to all nodes in the system
|
||||
- `kubeadm` and `kubelet` already installed on all machines.
|
||||
-->
|
||||
需要准备：
|
||||
|
||||
- 配置满足 [kubeadm 的最低要求](/zh/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#准备开始)
|
||||
的三台机器作为控制面节点。奇数台控制平面节点有利于机器故障或者网络分区时进行重新选主。
|
||||
- 机器已经安装好{{< glossary_tooltip text="容器运行时" term_id="container-runtime" >}}，并正常运行
|
||||
- 配置满足 [kubeadm 的最低要求](/zh/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#准备开始)
|
||||
的三台机器作为工作节点
|
||||
- 机器已经安装好{{< glossary_tooltip text="容器运行时" term_id="container-runtime" >}}，并正常运行
|
||||
- 在集群中，确保所有计算机之间存在全网络连接（公网或私网）
|
||||
- 在所有机器上具有 sudo 权限
|
||||
- 可以使用其他工具；本教程以 `sudo` 举例
|
||||
- 从某台设备通过 SSH 访问系统中所有节点的能力
|
||||
- 所有机器上已经安装 `kubeadm` 和 `kubelet`
|
||||
<!-- end of shared prerequisites -->
|
||||
<!--
|
||||
And you also need:
|
||||
- Three or more additional machines, that will become etcd cluster members.
|
||||
Having an odd number of members in the etcd cluster is a requirement for achieving
|
||||
optimal voting quorum.
|
||||
- These machines again need to have `kubeadm` and `kubelet` installed.
|
||||
- These machines also require a container runtime, that is already set up and working.
|
||||
-->
|
||||
还需要准备：
|
||||
- 给 etcd 集群使用的另外三台及以上机器。为了分布式一致性算法达到更好的投票效果，集群必须由奇数个节点组成。
|
||||
- 机器上已经安装 `kubeadm` 和 `kubelet`。
|
||||
- 机器上同样需要安装好容器运行时，并能正常运行。
|
||||
<!--
|
||||
_See [External etcd topology](/docs/setup/production-environment/tools/kubeadm/ha-topology/#external-etcd-topology) for context._
|
||||
-->
|
||||
_拓扑详情请参考[外部 etcd 拓扑](/zh/docs/setup/production-environment/tools/kubeadm/ha-topology/#外部-etcd-拓扑)。_
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
<!-- ### Container images -->
|
||||
### 容器镜像
|
||||
|
||||
<!--
|
||||
Each host should have access read and fetch images from the Kubernetes container image registry, `k8s.gcr.io`.
|
||||
If you want to deploy a highly-available cluster where the hosts do not have access to pull images, this is possible. You must ensure by some other means that the correct container images are already available on the relevant hosts.
|
||||
-->
|
||||
每台主机需要能够从 Kubernetes 容器镜像仓库（ `k8s.gcr.io` ）读取和拉取镜像。
|
||||
想要在无法拉取 Kubernetes 仓库镜像的机器上部署高可用集群也是可行的。通过其他的手段保证主机上已经有对应的容器镜像即可。
|
||||
|
||||
<!-- ### Command line interface {#kubectl} -->
|
||||
### 命令行 {#kubectl}
|
||||
|
||||
<!--
|
||||
To manage Kubernetes once your cluster is set up, you should
|
||||
[install kubectl](/docs/tasks/tools/#kubectl) on your PC. It is also useful
|
||||
to install the `kubectl` tool on each control plane node, as this can be
|
||||
helpful for troubleshooting.
|
||||
-->
|
||||
一旦集群创建成功，需要在 PC 上[安装 kubectl](/zh/docs/tasks/tools/#kubectl) 用于管理 Kubernetes。为了方便故障排查，也可以在每个控制平面节点上安装 `kubectl`。
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
<!--
|
||||
## First steps for both methods
|
||||
|
||||
### Create load balancer for kube-apiserver
|
||||
-->
|
||||
## 这两种方法的第一步
|
||||
|
||||
### 为 kube-apiserver 创建负载均衡器
|
||||
|
||||
<!--
|
||||
There are many configurations for load balancers. The following example is only one
|
||||
option. Your cluster requirements may need a different configuration.
|
||||
-->
|
||||
{{< note >}}
|
||||
使用负载均衡器需要许多配置。你的集群搭建可能需要不同的配置。
|
||||
下面的例子只是其中的一方面配置。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
1. Create a kube-apiserver load balancer with a name that resolves to DNS.
|
||||
|
||||
- In a cloud environment you should place your control plane nodes behind a TCP
|
||||
forwarding load balancer. This load balancer distributes traffic to all
|
||||
healthy control plane nodes in its target list. The health check for
|
||||
an apiserver is a TCP check on the port the kube-apiserver listens on
|
||||
(default value `:6443`).
|
||||
|
||||
- It is not recommended to use an IP address directly in a cloud environment.
|
||||
|
||||
- The load balancer must be able to communicate with all control plane nodes
|
||||
on the apiserver port. It must also allow incoming traffic on its
|
||||
listening port.
|
||||
|
||||
- Make sure the address of the load balancer always matches
|
||||
the address of kubeadm's `ControlPlaneEndpoint`.
|
||||
|
||||
- Read the [Options for Software Load Balancing](https://git.k8s.io/kubeadm/docs/ha-considerations.md#options-for-software-load-balancing)
|
||||
guide for more details.
|
||||
-->
|
||||
1. 创建一个名为 kube-apiserver 的负载均衡器解析 DNS。
|
||||
|
||||
- 在云环境中，应该将控制平面节点放置在 TCP 转发负载平衡后面。
|
||||
该负载均衡器将流量分配给目标列表中所有运行状况良好的控制平面节点。
|
||||
API 服务器的健康检查是在 kube-apiserver 的监听端口（默认值 `:6443`）
|
||||
上进行的一个 TCP 检查。
|
||||
|
||||
- 不建议在云环境中直接使用 IP 地址。
|
||||
|
||||
- 负载均衡器必须能够在 API 服务器端口上与所有控制平面节点通信。
|
||||
它还必须允许其监听端口的入站流量。
|
||||
|
||||
- 确保负载均衡器的地址始终匹配 kubeadm 的 `ControlPlaneEndpoint` 地址。
|
||||
|
||||
- 阅读[软件负载平衡选项指南](https://git.k8s.io/kubeadm/docs/ha-considerations.md#options-for-software-load-balancing)
|
||||
以获取更多详细信息。
|
||||
|
||||
<!--
|
||||
1. Add the first control plane nodes to the load balancer and test the
|
||||
connection:
|
||||
|
||||
```sh
|
||||
nc -v LOAD_BALANCER_IP PORT
|
||||
```
|
||||
|
||||
- A connection refused error is expected because the apiserver is not yet
|
||||
running. A timeout, however, means the load balancer cannot communicate
|
||||
with the control plane node. If a timeout occurs, reconfigure the load
|
||||
balancer to communicate with the control plane node.
|
||||
|
||||
1. Add the remaining control plane nodes to the load balancer target group.
|
||||
-->
|
||||
2. 添加第一个控制平面节点到负载均衡器并测试连接：
|
||||
|
||||
```shell
|
||||
nc -v LOAD_BALANCER_IP PORT
|
||||
```
|
||||
|
||||
由于 apiserver 尚未运行，预期会出现一个连接拒绝错误。
|
||||
然而超时意味着负载均衡器不能和控制平面节点通信。
|
||||
如果发生超时，请重新配置负载均衡器与控制平面节点进行通信。
|
||||
|
||||
3. 将其余控制平面节点添加到负载均衡器目标组。
|
||||
|
||||
<!--
|
||||
## Stacked control plane and etcd nodes
|
||||
|
||||
### Steps for the first control plane node
|
||||
-->
|
||||
## 使用堆控制平面和 etcd 节点
|
||||
|
||||
### 控制平面节点的第一步
|
||||
|
||||
<!--
|
||||
1. Initialize the control plane:
|
||||
|
||||
```sh
|
||||
sudo kubeadm init --control-plane-endpoint "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" --upload-certs
|
||||
```
|
||||
- You can use the `--kubernetes-version` flag to set the Kubernetes version to use.
|
||||
It is recommended that the versions of kubeadm, kubelet, kubectl and Kubernetes match.
|
||||
- The `--control-plane-endpoint` flag should be set to the address or DNS and port of the load balancer.
|
||||
|
||||
- The `--upload-certs` flag is used to upload the certificates that should be shared
|
||||
across all the control-plane instances to the cluster. If instead, you prefer to copy certs across
|
||||
control-plane nodes manually or using automation tools, please remove this flag and refer to [Manual
|
||||
certificate distribution](#manual-certs) section bellow.
|
||||
-->
|
||||
1. 初始化控制平面：
|
||||
|
||||
```shell
|
||||
sudo kubeadm init --control-plane-endpoint "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" --upload-certs
|
||||
```
|
||||
|
||||
- 你可以使用 `--kubernetes-version` 标志来设置要使用的 Kubernetes 版本。
|
||||
建议将 kubeadm、kebelet、kubectl 和 Kubernetes 的版本匹配。
|
||||
- 这个 `--control-plane-endpoint` 标志应该被设置成负载均衡器的地址或 DNS 和端口。
|
||||
- 这个 `--upload-certs` 标志用来将在所有控制平面实例之间的共享证书上传到集群。
|
||||
如果正好相反，你更喜欢手动地通过控制平面节点或者使用自动化工具复制证书，
|
||||
请删除此标志并参考如下部分[证书分配手册](#manual-certs)。
|
||||
|
||||
<!--
|
||||
The `kubeadm init` flags `--config` and `--certificate-key` cannot be mixed, therefore if you want
|
||||
to use the [kubeadm configuration](/docs/reference/config-api/kubeadm-config.v1beta3/) you must add the `certificateKey` field in the appropriate config locations (under `InitConfiguration` and `JoinConfiguration: controlPlane`).
|
||||
-->
|
||||
{{< note >}}
|
||||
标志 `kubeadm init`、`--config` 和 `--certificate-key` 不能混合使用，
|
||||
因此如果你要使用
|
||||
[kubeadm 配置](/docs/reference/config-api/kubeadm-config.v1beta3/)，你必须在相应的配置结构
|
||||
（位于 `InitConfiguration` 和 `JoinConfiguration: controlPlane`）添加 `certificateKey` 字段。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
Some CNI network plugins like Calico require a CIDR such as `192.168.0.0/16` and
|
||||
some like Weave do not. See the [CNI network documentation](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network).
|
||||
To add a pod CIDR pass the flag `--pod-network-cidr`, or if you are using a kubeadm configuration file
|
||||
set the `podSubnet` field under the `networking` object of `ClusterConfiguration`.
|
||||
-->
|
||||
{{< note >}}
|
||||
一些 CNI 网络插件如 Calico 需要 CIDR 例如 `192.168.0.0/16` 和一些像 Weave 没有。参考
|
||||
[CNI 网络文档](/zh/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network)。
|
||||
通过传递 `--pod-network-cidr` 标志添加 pod CIDR，或者你可以使用 kubeadm
|
||||
配置文件，在 `ClusterConfiguration` 的 `networking` 对象下设置 `podSubnet` 字段。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
- The output looks similar to:
|
||||
-->
|
||||
- 输出类似于：
|
||||
|
||||
```sh
|
||||
...
|
||||
You can now join any number of control-plane node by running the following command on each as a root:
|
||||
kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 --control-plane --certificate-key f8902e114ef118304e561c3ecd4d0b543adc226b7a07f675f56564185ffe0c07
|
||||
|
||||
Please note that the certificate-key gives access to cluster sensitive data, keep it secret!
|
||||
As a safeguard, uploaded-certs will be deleted in two hours; If necessary, you can use kubeadm init phase upload-certs to reload certs afterward.
|
||||
|
||||
Then you can join any number of worker nodes by running the following on each as root:
|
||||
kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866
|
||||
```
|
||||
|
||||
<!--
|
||||
- Copy this output to a text file. You will need it later to join control plane and worker nodes to the cluster.
|
||||
- When `--upload-certs` is used with `kubeadm init`, the certificates of the primary control plane
|
||||
are encrypted and uploaded in the `kubeadm-certs` Secret.
|
||||
- To re-upload the certificates and generate a new decryption key, use the following command on a control plane
|
||||
node that is already joined to the cluster:
|
||||
-->
|
||||
- 将此输出复制到文本文件。 稍后你将需要它来将控制平面节点和工作节点加入集群。
|
||||
- 当使用 `--upload-certs` 调用 `kubeadm init` 时，主控制平面的证书被加密并上传到 `kubeadm-certs` Secret 中。
|
||||
- 要重新上传证书并生成新的解密密钥，请在已加入集群节点的控制平面上使用以下命令：
|
||||
|
||||
```shell
|
||||
sudo kubeadm init phase upload-certs --upload-certs
|
||||
```
|
||||
<!--
|
||||
- You can also specify a custom `--certificate-key` during `init` that can later be used by `join`.
|
||||
To generate such a key you can use the following command:
|
||||
-->
|
||||
- 你还可以在 `init` 期间指定自定义的 `--certificate-key`，以后可以由 `join` 使用。
|
||||
要生成这样的密钥，可以使用以下命令：
|
||||
|
||||
```shell
|
||||
kubeadm certs certificate-key
|
||||
```
|
||||
<!--
|
||||
The `kubeadm-certs` Secret and decryption key expire after two hours.
|
||||
-->
|
||||
{{< note >}}
|
||||
`kubeadm-certs` Secret 和解密密钥会在两个小时后失效。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
As stated in the command output, the certificate key gives access to cluster sensitive data, keep it secret!
|
||||
-->
|
||||
{{< caution >}}
|
||||
正如命令输出中所述，证书密钥可访问集群敏感数据。请妥善保管！
|
||||
{{< /caution >}}
|
||||
|
||||
<!--
|
||||
1. Apply the CNI plugin of your choice:
|
||||
[Follow these instructions](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network) to install the CNI provider. Make sure the configuration corresponds to the Pod CIDR specified in the kubeadm configuration file (if applicable).
|
||||
-->
|
||||
2. 应用你所选择的 CNI 插件：
|
||||
[请遵循以下指示](/zh/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network)
|
||||
安装 CNI 驱动。如果适用，请确保配置与 kubeadm 配置文件中指定的 Pod
|
||||
CIDR 相对应。
|
||||
<!--
|
||||
You must pick a network plugin that suits your use case and deploy it before you move on to next step.
|
||||
If you don't do this, you will not be able to launch your cluster properly.
|
||||
-->
|
||||
{{< note >}}
|
||||
在进行下一步之前，必须选择并部署合适的网络插件。
|
||||
否则集群不会正常运行。
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
<!--
|
||||
1. Type the following and watch the pods of the control plane components get started:
|
||||
-->
|
||||
3. 输入以下内容，并查看控制平面组件的 Pods 启动：
|
||||
|
||||
```shell
|
||||
kubectl get pod -n kube-system -w
|
||||
```
|
||||
|
||||
<!--
|
||||
### Steps for the rest of the control plane nodes
|
||||
-->
|
||||
### 其余控制平面节点的步骤
|
||||
|
||||
<!--
|
||||
Since kubeadm version 1.15 you can join multiple control-plane nodes in parallel.
|
||||
Prior to this version, you must join new control plane nodes sequentially, only after
|
||||
the first node has finished initializing.
|
||||
-->
|
||||
{{< note >}}
|
||||
从 kubeadm 1.15 版本开始，你可以并行加入多个控制平面节点。
|
||||
在此版本之前，你必须在第一个节点初始化后才能依序的增加新的控制平面节点。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
For each additional control plane node you should:
|
||||
|
||||
1. Execute the join command that was previously given to you by the `kubeadm init` output on the first node.
|
||||
It should look something like this:
|
||||
|
||||
```sh
|
||||
sudo kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 --control-plane --certificate-key f8902e114ef118304e561c3ecd4d0b543adc226b7a07f675f56564185ffe0c07
|
||||
```
|
||||
|
||||
- The `--control-plane` flag tells `kubeadm join` to create a new control plane.
|
||||
- The `--certificate-key ...` will cause the control plane certificates to be downloaded
|
||||
from the `kubeadm-certs` Secret in the cluster and be decrypted using the given key.
|
||||
|
||||
-->
|
||||
对于每个其他控制平面节点，你应该：
|
||||
|
||||
1. 执行先前由第一个节点上的 `kubeadm init` 输出提供给你的 join 命令。
|
||||
它看起来应该像这样：
|
||||
|
||||
```sh
|
||||
sudo kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 --control-plane --certificate-key f8902e114ef118304e561c3ecd4d0b543adc226b7a07f675f56564185ffe0c07
|
||||
```
|
||||
|
||||
- 这个 `--control-plane` 标志通知 `kubeadm join` 创建一个新的控制平面。
|
||||
- `--certificate-key ...` 将导致从集群中的 `kubeadm-certs` Secret
|
||||
下载控制平面证书并使用给定的密钥进行解密。
|
||||
|
||||
<!--
|
||||
## External etcd nodes
|
||||
|
||||
Setting up a cluster with external etcd nodes is similar to the procedure used for stacked etcd
|
||||
with the exception that you should setup etcd first, and you should pass the etcd information
|
||||
in the kubeadm config file.
|
||||
-->
|
||||
## 外部 etcd 节点
|
||||
|
||||
使用外部 etcd 节点设置集群类似于用于堆叠 etcd 的过程，
|
||||
不同之处在于你应该首先设置 etcd，并在 kubeadm 配置文件中传递 etcd 信息。
|
||||
|
||||
<!--
|
||||
### Set up the etcd cluster
|
||||
|
||||
1. Follow [these instructions](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/) to set up the etcd cluster.
|
||||
|
||||
1. Setup SSH as described [here](#manual-certs).
|
||||
|
||||
1. Copy the following files from any etcd node in the cluster to the first control plane node:
|
||||
|
||||
```sh
|
||||
export CONTROL_PLANE="ubuntu@10.0.0.7"
|
||||
scp /etc/kubernetes/pki/etcd/ca.crt "${CONTROL_PLANE}":
|
||||
scp /etc/kubernetes/pki/apiserver-etcd-client.crt "${CONTROL_PLANE}":
|
||||
scp /etc/kubernetes/pki/apiserver-etcd-client.key "${CONTROL_PLANE}":
|
||||
```
|
||||
|
||||
- Replace the value of `CONTROL_PLANE` with the `user@host` of the first control-plane machine.
|
||||
-->
|
||||
### 设置 ectd 集群
|
||||
|
||||
1. 按照[这些指示](/zh/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/)
|
||||
去设置 etcd 集群。
|
||||
|
||||
1. 根据[这里](#manual-certs) 的描述配置 SSH。
|
||||
|
||||
1. 将以下文件从集群中的任何 etcd 节点复制到第一个控制平面节点：
|
||||
|
||||
```shell
|
||||
export CONTROL_PLANE="ubuntu@10.0.0.7"
|
||||
scp /etc/kubernetes/pki/etcd/ca.crt "${CONTROL_PLANE}":
|
||||
scp /etc/kubernetes/pki/apiserver-etcd-client.crt "${CONTROL_PLANE}":
|
||||
scp /etc/kubernetes/pki/apiserver-etcd-client.key "${CONTROL_PLANE}":
|
||||
```
|
||||
|
||||
- 用第一台控制平面机的 `user@host` 替换 `CONTROL_PLANE` 的值。
|
||||
|
||||
<!--
|
||||
### Set up the first control plane node
|
||||
|
||||
1. Create a file called `kubeadm-config.yaml` with the following contents:
|
||||
|
||||
```yaml
|
||||
---
|
||||
apiVersion: kubeadm.k8s.io/v1beta3
|
||||
kind: ClusterConfiguration
|
||||
kubernetesVersion: stable
|
||||
controlPlaneEndpoint: "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" # change this (see below)
|
||||
etcd:
|
||||
external:
|
||||
endpoints:
|
||||
- https://ETCD_0_IP:2379 # change ETCD_0_IP appropriately
|
||||
- https://ETCD_1_IP:2379 # change ETCD_1_IP appropriately
|
||||
- https://ETCD_2_IP:2379 # change ETCD_2_IP appropriately
|
||||
caFile: /etc/kubernetes/pki/etcd/ca.crt
|
||||
certFile: /etc/kubernetes/pki/apiserver-etcd-client.crt
|
||||
keyFile: /etc/kubernetes/pki/apiserver-etcd-client.key
|
||||
```
|
||||
-->
|
||||
|
||||
### 设置第一个控制平面节点
|
||||
|
||||
1. 用以下内容创建一个名为 `kubeadm-config.yaml` 的文件：
|
||||
|
||||
```yaml
|
||||
---
|
||||
apiVersion: kubeadm.k8s.io/v1beta3
|
||||
kind: ClusterConfiguration
|
||||
kubernetesVersion: stable
|
||||
controlPlaneEndpoint: "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" # change this (see below)
|
||||
etcd:
|
||||
external:
|
||||
endpoints:
|
||||
- https://ETCD_0_IP:2379 # change ETCD_0_IP appropriately
|
||||
- https://ETCD_1_IP:2379 # change ETCD_1_IP appropriately
|
||||
- https://ETCD_2_IP:2379 # change ETCD_2_IP appropriately
|
||||
caFile: /etc/kubernetes/pki/etcd/ca.crt
|
||||
certFile: /etc/kubernetes/pki/apiserver-etcd-client.crt
|
||||
keyFile: /etc/kubernetes/pki/apiserver-etcd-client.key
|
||||
```
|
||||
<!--
|
||||
The difference between stacked etcd and external etcd here is that the external etcd setup requires
|
||||
a configuration file with the etcd endpoints under the `external` object for `etcd`.
|
||||
In the case of the stacked etcd topology this is managed automatically.
|
||||
-->
|
||||
{{< note >}}
|
||||
这里的堆叠（stacked）etcd 和外部 etcd 之前的区别在于设置外部 etcd
|
||||
需要一个 `etcd` 的 `external` 对象下带有 etcd 端点的配置文件。
|
||||
如果是内部 etcd，是自动管理的。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
- Replace the following variables in the config template with the appropriate values for your cluster:
|
||||
-->
|
||||
- 在你的集群中，将配置模板中的以下变量替换为适当值：
|
||||
|
||||
- `LOAD_BALANCER_DNS`
|
||||
- `LOAD_BALANCER_PORT`
|
||||
- `ETCD_0_IP`
|
||||
- `ETCD_1_IP`
|
||||
- `ETCD_2_IP`
|
||||
|
||||
<!--
|
||||
The following steps are similar to the stacked etcd setup:
|
||||
-->
|
||||
以下的步骤与设置内置 etcd 的集群是相似的：
|
||||
|
||||
<!--
|
||||
1. Run `sudo kubeadm init --config kubeadm-config.yaml --upload-certs` on this node.
|
||||
|
||||
1. Write the output join commands that are returned to a text file for later use.
|
||||
|
||||
1. Apply the CNI plugin of your choice.
|
||||
-->
|
||||
1. 在节点上运行 `sudo kubeadm init --config kubeadm-config.yaml --upload-certs` 命令。
|
||||
|
||||
1. 记下输出的 join 命令，这些命令将在以后使用。
|
||||
|
||||
1. 应用你选择的 CNI 插件。
|
||||
<!--
|
||||
You must pick a network plugin that suits your use case and deploy it before you move on to next step.
|
||||
If you don't do this, you will not be able to launch your cluster properly.
|
||||
-->
|
||||
{{< note >}}
|
||||
在进行下一步之前，必须选择并部署合适的网络插件。
|
||||
否则集群不会正常运行。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
### Steps for the rest of the control plane nodes
|
||||
|
||||
The steps are the same as for the stacked etcd setup:
|
||||
|
||||
- Make sure the first control plane node is fully initialized.
|
||||
- Join each control plane node with the join command you saved to a text file. It's recommended
|
||||
to join the control plane nodes one at a time.
|
||||
- Don't forget that the decryption key from `--certificate-key` expires after two hours, by default.
|
||||
-->
|
||||
### 其他控制平面节点的步骤
|
||||
|
||||
步骤与设置内置 etcd 相同：
|
||||
|
||||
- 确保第一个控制平面节点已完全初始化。
|
||||
- 使用保存到文本文件的 join 命令将每个控制平面节点连接在一起。
|
||||
建议一次加入一个控制平面节点。
|
||||
- 不要忘记默认情况下，`--certificate-key` 中的解密秘钥会在两个小时后过期。
|
||||
|
||||
<!--
|
||||
## Common tasks after bootstrapping control plane
|
||||
|
||||
### Install workers
|
||||
-->
|
||||
## 列举控制平面之后的常见任务
|
||||
|
||||
### 安装工作节点
|
||||
|
||||
<!--
|
||||
Worker nodes can be joined to the cluster with the command you stored previously
|
||||
as the output from the `kubeadm init` command:
|
||||
-->
|
||||
你可以使用之前存储的 `kubeadm init` 命令的输出将工作节点加入集群中：
|
||||
|
||||
```sh
|
||||
sudo kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866
|
||||
```
|
||||
|
||||
<!--
|
||||
## Manual certificate distribution {#manual-certs}
|
||||
|
||||
If you choose to not use `kubeadm init` with the `--upload-certs` flag this means that
|
||||
you are going to have to manually copy the certificates from the primary control plane node to the
|
||||
joining control plane nodes.
|
||||
|
||||
There are many ways to do this. In the following example we are using `ssh` and `scp`:
|
||||
|
||||
SSH is required if you want to control all nodes from a single machine.
|
||||
-->
|
||||
## 手动证书分发 {#manual-certs}
|
||||
|
||||
如果你选择不将 `kubeadm init` 与 `--upload-certs` 命令一起使用，
|
||||
则意味着你将必须手动将证书从主控制平面节点复制到
|
||||
将要加入的控制平面节点上。
|
||||
|
||||
有许多方法可以实现这种操作。在下面的例子中我们使用 `ssh` 和 `scp`：
|
||||
|
||||
如果要在单独的一台计算机控制所有节点，则需要 SSH。
|
||||
|
||||
<!--
|
||||
1. Enable ssh-agent on your main device that has access to all other nodes in
|
||||
the system:
|
||||
-->
|
||||
1. 在你的主设备上启用 ssh-agent，要求该设备能访问系统中的所有其他节点：
|
||||
|
||||
```shell
|
||||
eval $(ssh-agent)
|
||||
```
|
||||
|
||||
<!--
|
||||
1. Add your SSH identity to the session:
|
||||
-->
|
||||
2. 将 SSH 身份添加到会话中：
|
||||
|
||||
```shell
|
||||
ssh-add ~/.ssh/path_to_private_key
|
||||
```
|
||||
|
||||
<!--
|
||||
1. SSH between nodes to check that the connection is working correctly.
|
||||
-->
|
||||
3. 检查节点间的 SSH 以确保连接是正常运行的
|
||||
|
||||
<!--
|
||||
- When you SSH to any node, make sure to add the `-A` flag:
|
||||
-->
|
||||
- SSH 到任何节点时，请确保添加 `-A` 标志：
|
||||
|
||||
```shell
|
||||
ssh -A 10.0.0.7
|
||||
```
|
||||
|
||||
<!--
|
||||
- When using sudo on any node, make sure to preserve the environment so SSH
|
||||
forwarding works:
|
||||
-->
|
||||
- 当在任何节点上使用 sudo 时，请确保保持环境变量设置，以便 SSH
|
||||
转发能够正常工作：
|
||||
|
||||
```shell
|
||||
sudo -E -s
|
||||
```
|
||||
<!--
|
||||
1. After configuring SSH on all the nodes you should run the following script on the first control plane node after
|
||||
running `kubeadm init`. This script will copy the certificates from the first control plane node to the other
|
||||
control plane nodes:
|
||||
-->
|
||||
4. 在所有节点上配置 SSH 之后，你应该在运行过 `kubeadm init` 命令的第一个
|
||||
控制平面节点上运行以下脚本。
|
||||
该脚本会将证书从第一个控制平面节点复制到另一个控制平面节点：
|
||||
|
||||
<!--
|
||||
In the following example, replace `CONTROL_PLANE_IPS` with the IP addresses of the
|
||||
other control plane nodes.
|
||||
-->
|
||||
在以下示例中，用其他控制平面节点的 IP 地址替换 `CONTROL_PLANE_IPS`。
|
||||
|
||||
```sh
|
||||
USER=ubuntu # 可定制
|
||||
CONTROL_PLANE_IPS="10.0.0.7 10.0.0.8"
|
||||
for host in ${CONTROL_PLANE_IPS}; do
|
||||
scp /etc/kubernetes/pki/ca.crt "${USER}"@$host:
|
||||
scp /etc/kubernetes/pki/ca.key "${USER}"@$host:
|
||||
scp /etc/kubernetes/pki/sa.key "${USER}"@$host:
|
||||
scp /etc/kubernetes/pki/sa.pub "${USER}"@$host:
|
||||
scp /etc/kubernetes/pki/front-proxy-ca.crt "${USER}"@$host:
|
||||
scp /etc/kubernetes/pki/front-proxy-ca.key "${USER}"@$host:
|
||||
scp /etc/kubernetes/pki/etcd/ca.crt "${USER}"@$host:etcd-ca.crt
|
||||
scp /etc/kubernetes/pki/etcd/ca.key "${USER}"@$host:etcd-ca.key
|
||||
done
|
||||
```
|
||||
<!--
|
||||
Copy only the certificates in the above list. kubeadm will take care of generating the rest of the certificates
|
||||
with the required SANs for the joining control-plane instances. If you copy all the certificates by mistake,
|
||||
the creation of additional nodes could fail due to a lack of required SANs.
|
||||
-->
|
||||
{{< caution >}}
|
||||
只需要复制上面列表中的证书。kubeadm 将负责生成其余证书以及加入控制平面实例所需的 SAN。
|
||||
如果你错误地复制了所有证书，由于缺少所需的 SAN，创建其他节点可能会失败。
|
||||
{{< /caution >}}
|
||||
|
||||
<!--
|
||||
1. Then on each joining control plane node you have to run the following script before running `kubeadm join`.
|
||||
This script will move the previously copied certificates from the home directory to `/etc/kubernetes/pki`:
|
||||
-->
|
||||
5. 然后，在每个即将加入集群的控制平面节点上，你必须先运行以下脚本，然后
|
||||
再运行 `kubeadm join`。
|
||||
该脚本会将先前复制的证书从主目录移动到 `/etc/kubernetes/pki`：
|
||||
|
||||
```shell
|
||||
USER=ubuntu # 可定制
|
||||
mkdir -p /etc/kubernetes/pki/etcd
|
||||
mv /home/${USER}/ca.crt /etc/kubernetes/pki/
|
||||
mv /home/${USER}/ca.key /etc/kubernetes/pki/
|
||||
mv /home/${USER}/sa.pub /etc/kubernetes/pki/
|
||||
mv /home/${USER}/sa.key /etc/kubernetes/pki/
|
||||
mv /home/${USER}/front-proxy-ca.crt /etc/kubernetes/pki/
|
||||
mv /home/${USER}/front-proxy-ca.key /etc/kubernetes/pki/
|
||||
mv /home/${USER}/etcd-ca.crt /etc/kubernetes/pki/etcd/ca.crt
|
||||
mv /home/${USER}/etcd-ca.key /etc/kubernetes/pki/etcd/ca.key
|
||||
```
|
||||
|
||||
@@ -0,0 +1,524 @@
|
||||
---
|
||||
title: 安装 kubeadm
|
||||
content_type: task
|
||||
weight: 10
|
||||
card:
|
||||
name: setup
|
||||
weight: 20
|
||||
title: 安装 kubeadm 设置工具
|
||||
---
|
||||
<!--
|
||||
title: Installing kubeadm
|
||||
content_type: task
|
||||
weight: 10
|
||||
card:
|
||||
name: setup
|
||||
weight: 20
|
||||
title: Install the kubeadm setup tool
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
<img src="https://raw.githubusercontent.com/kubernetes/kubeadm/master/logos/stacked/color/kubeadm-stacked-color.png" align="right" width="150px">This page shows how to install the `kubeadm` toolbox.
|
||||
For information on how to create a cluster with kubeadm once you have performed this installation process, see the [Using kubeadm to Create a Cluster](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) page.
|
||||
-->
|
||||
<img src="/images/kubeadm-stacked-color.png" align="right" width="150px">本页面显示如何安装 `kubeadm` 工具箱。
|
||||
有关在执行此安装过程后如何使用 kubeadm 创建集群的信息，请参见
|
||||
[使用 kubeadm 创建集群](/zh/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) 页面。
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
<!--
|
||||
* A compatible Linux host. The Kubernetes project provides generic instructions for Linux distributions based on Debian and Red Hat, and those distributions without a package manager.
|
||||
* 2 GB or more of RAM per machine (any less will leave little room for your apps)
|
||||
* 2 CPUs or more
|
||||
* Full network connectivity between all machines in the cluster (public or private network is fine)
|
||||
* Unique hostname, MAC address, and product_uuid for every node. See [here](#verify-mac-address) for more details.
|
||||
* Certain ports are open on your machines. See [here](#check-required-ports) for more details.
|
||||
* Swap disabled. You **MUST** disable swap in order for the kubelet to work properly.
|
||||
-->
|
||||
* 一台兼容的 Linux 主机。Kubernetes 项目为基于 Debian 和 Red Hat 的 Linux
|
||||
发行版以及一些不提供包管理器的发行版提供通用的指令
|
||||
* 每台机器 2 GB 或更多的 RAM （如果少于这个数字将会影响你应用的运行内存)
|
||||
* 2 CPU 核或更多
|
||||
* 集群中的所有机器的网络彼此均能相互连接(公网和内网都可以)
|
||||
* 节点之中不可以有重复的主机名、MAC 地址或 product_uuid。请参见[这里](#verify-mac-address)了解更多详细信息。
|
||||
* 开启机器上的某些端口。请参见[这里](#check-required-ports) 了解更多详细信息。
|
||||
* 禁用交换分区。为了保证 kubelet 正常工作，你 **必须** 禁用交换分区。
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
<!--
|
||||
## Verify the MAC address and product_uuid are unique for every node
|
||||
|
||||
* You can get the MAC address of the network interfaces using the command `ip link` or `ifconfig -a`
|
||||
* The product_uuid can be checked by using the command `sudo cat /sys/class/dmi/id/product_uuid`
|
||||
|
||||
It is very likely that hardware devices will have unique addresses, although some virtual machines may have
|
||||
identical values. Kubernetes uses these values to uniquely identify the nodes in the cluster.
|
||||
If these values are not unique to each node, the installation process
|
||||
may [fail](https://github.com/kubernetes/kubeadm/issues/31).
|
||||
-->
|
||||
## 确保每个节点上 MAC 地址和 product_uuid 的唯一性 {#verify-mac-address}
|
||||
|
||||
* 你可以使用命令 `ip link` 或 `ifconfig -a` 来获取网络接口的 MAC 地址
|
||||
* 可以使用 `sudo cat /sys/class/dmi/id/product_uuid` 命令对 product_uuid 校验
|
||||
|
||||
一般来讲，硬件设备会拥有唯一的地址，但是有些虚拟机的地址可能会重复。
|
||||
Kubernetes 使用这些值来唯一确定集群中的节点。
|
||||
如果这些值在每个节点上不唯一，可能会导致安装
|
||||
[失败](https://github.com/kubernetes/kubeadm/issues/31)。
|
||||
|
||||
<!--
|
||||
## Check network adapters
|
||||
|
||||
If you have more than one network adapter, and your Kubernetes components are not reachable on the default
|
||||
route, we recommend you add IP route(s) so Kubernetes cluster addresses go via the appropriate adapter.
|
||||
-->
|
||||
## 检查网络适配器
|
||||
|
||||
如果你有一个以上的网络适配器，同时你的 Kubernetes 组件通过默认路由不可达，我们建议你预先添加 IP 路由规则，这样 Kubernetes 集群就可以通过对应的适配器完成连接。
|
||||
|
||||
<!--
|
||||
## Letting iptables see bridged traffic
|
||||
|
||||
Make sure that the `br_netfilter` module is loaded. This can be done by running `lsmod | grep br_netfilter`. To load it explicitly call `sudo modprobe br_netfilter`.
|
||||
|
||||
As a requirement for your Linux Node's iptables to correctly see bridged traffic, you should ensure `net.bridge.bridge-nf-call-iptables` is set to 1 in your `sysctl` config, e.g.
|
||||
-->
|
||||
## 允许 iptables 检查桥接流量
|
||||
|
||||
确保 `br_netfilter` 模块被加载。这一操作可以通过运行 `lsmod | grep br_netfilter`
|
||||
来完成。若要显式加载该模块，可执行 `sudo modprobe br_netfilter`。
|
||||
|
||||
为了让你的 Linux 节点上的 iptables 能够正确地查看桥接流量，你需要确保在你的
|
||||
`sysctl` 配置中将 `net.bridge.bridge-nf-call-iptables` 设置为 1。例如：
|
||||
|
||||
```bash
|
||||
cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
|
||||
br_netfilter
|
||||
EOF
|
||||
|
||||
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
|
||||
net.bridge.bridge-nf-call-ip6tables = 1
|
||||
net.bridge.bridge-nf-call-iptables = 1
|
||||
EOF
|
||||
sudo sysctl --system
|
||||
```
|
||||
|
||||
<!--
|
||||
For more details please see the [Network Plugin Requirements](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#network-plugin-requirements) page.
|
||||
-->
|
||||
更多的相关细节可查看[网络插件需求](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#network-plugin-requirements)页面。
|
||||
|
||||
<!--
|
||||
## Check required ports
|
||||
These
|
||||
[required ports](/docs/reference/ports-and-protocols/)
|
||||
need to be open in order for Kubernetes components to communicate with each other. You can use tools like netcat to check if a port is open. For example:
|
||||
-->
|
||||
|
||||
## 检查所需端口{#check-required-ports}
|
||||
|
||||
启用这些[必要的端口](/zh/docs/reference/ports-and-protocols/)后才能使 Kubernetes 的各组件相互通信。可以使用 netcat 之类的工具来检查端口是否启用，例如：
|
||||
|
||||
```shell
|
||||
nc 127.0.0.1 6443
|
||||
```
|
||||
|
||||
<!--
|
||||
The pod network plugin you use may also require certain ports to be
|
||||
open. Since this differs with each pod network plugin, please see the
|
||||
documentation for the plugins about what port(s) those need.
|
||||
-->
|
||||
你使用的 Pod 网络插件 (详见后续章节) 也可能需要开启某些特定端口。由于各个 Pod 网络插件的功能都有所不同，
|
||||
请参阅他们各自文档中对端口的要求。
|
||||
|
||||
<!--
|
||||
## Installing a container runtime {#installing-runtime}
|
||||
|
||||
To run containers in Pods, Kubernetes uses a
|
||||
{{< glossary_tooltip term_id="container-runtime" text="container runtime" >}}.
|
||||
-->
|
||||
## 安装容器运行时{#installing-runtime}
|
||||
|
||||
为了在 Pod 中运行容器，Kubernetes 使用
|
||||
{{< glossary_tooltip term_id="container-runtime" text="容器运行时（Container Runtime）" >}}。
|
||||
|
||||
<!--
|
||||
By default, Kubernetes uses the
|
||||
{{< glossary_tooltip term_id="cri" text="Container Runtime Interface">}} (CRI)
|
||||
to interface with your chosen container runtime.
|
||||
|
||||
If you don't specify a runtime, kubeadm automatically tries to detect an installed
|
||||
container runtime by scanning through a list of known endpoints.
|
||||
-->
|
||||
默认情况下，Kubernetes 使用
|
||||
{{< glossary_tooltip term_id="cri" text="容器运行时接口（Container Runtime Interface，CRI）" >}}
|
||||
来与你所选择的容器运行时交互。
|
||||
|
||||
如果你不指定运行时，kubeadm 会自动尝试通过扫描已知的端点列表来检测已安装的容器运行时。
|
||||
|
||||
<!--
|
||||
If multiple or no container runtimes are detected kubeadm will throw an error
|
||||
and will request that you specify which one you want to use.
|
||||
|
||||
See [container runtimes](/docs/setup/production-environment/container-runtimes/)
|
||||
for more information.
|
||||
-->
|
||||
如果检测到有多个或者没有容器运行时，kubeadm 将抛出一个错误并要求你指定一个想要使用的运行时。
|
||||
|
||||
参阅[容器运行时](/zh/docs/setup/production-environment/container-runtimes/)
|
||||
以了解更多信息。
|
||||
|
||||
<!--
|
||||
{{< note >}}
|
||||
Docker Engine does not implement the [CRI](/docs/concepts/architecture/cri/)
|
||||
which is a requirement for a container runtime to work with Kubernetes.
|
||||
For that reason, an additional service [cri-dockerd](https://github.com/Mirantis/cri-dockerd)
|
||||
has to be installed. cri-dockerd is a project based on the legacy built-in
|
||||
Docker Engine support that was [removed](/dockershim) from the kubelet in version 1.24.
|
||||
-->
|
||||
|
||||
{{< note >}}
|
||||
Docker Engine 没有实现 [CRI](/zh/docs/concepts/architecture/cri/)，而这是容器运行时在 Kubernetes 中工作所需要的。
|
||||
为此，必须安装一个额外的服务 [cri-dockerd](https://github.com/Mirantis/cri-dockerd)。
|
||||
cri-dockerd 是一个基于传统的内置Docker引擎支持的项目，它在 1.24 版本从 kubelet 中[移除](/zh/dockershim)。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
The tables below include the known endpoints for supported operating systems:
|
||||
|
||||
{{< tabs name="container_runtime" >}}
|
||||
{{% tab name="Linux" %}}
|
||||
-->
|
||||
下面的表格包括被支持的操作系统的已知端点。
|
||||
|
||||
{{< tabs name="container_runtime" >}}
|
||||
{{% tab name="Linux" %}}
|
||||
|
||||
<!--
|
||||
{{< table >}}
|
||||
| Runtime | Path to Unix domain socket |
|
||||
|------------------------------------|----------------------------------------------|
|
||||
| containerd | `unix:///var/run/containerd/containerd.sock` |
|
||||
| CRI-O | `unix:///var/run/crio/crio.sock` |
|
||||
| Docker Engine (using cri-dockerd) | `unix:///var/run/cri-dockerd.sock` |
|
||||
{{< /table >}}
|
||||
-->
|
||||
{{< table >}}
|
||||
| 运行时 | Unix 域套接字 |
|
||||
|------------------------------------|----------------------------------------------|
|
||||
| containerd | `unix:///var/run/containerd/containerd.sock` |
|
||||
| CRI-O | `unix:///var/run/crio/crio.sock` |
|
||||
| Docker Engine (使用 cri-dockerd) | `unix:///var/run/cri-dockerd.sock` |
|
||||
{{< /table >}}
|
||||
|
||||
<!--
|
||||
{{% tab name="Windows" %}}
|
||||
|
||||
{{< table >}}
|
||||
| Runtime | Path to Windows named pipe |
|
||||
|------------------------------------|----------------------------------------------|
|
||||
| containerd | `npipe:////./pipe/containerd-containerd` |
|
||||
| Docker Engine (using cri-dockerd) | `npipe:////./pipe/cri-dockerd` |
|
||||
{{< /table >}}
|
||||
-->
|
||||
{{% tab name="Windows" %}}
|
||||
|
||||
{{< table >}}
|
||||
| 运行时 | Windows 命名管道路径 |
|
||||
|------------------------------------|----------------------------------------------|
|
||||
| containerd | `npipe:////./pipe/containerd-containerd` |
|
||||
| Docker Engine (使用 cri-dockerd) | `npipe:////./pipe/cri-dockerd` |
|
||||
{{< /table >}}
|
||||
|
||||
<!--
|
||||
## Installing kubeadm, kubelet and kubectl
|
||||
|
||||
You will install these packages on all of your machines:
|
||||
|
||||
* `kubeadm`: the command to bootstrap the cluster.
|
||||
|
||||
* `kubelet`: the component that runs on all of the machines in your cluster
|
||||
and does things like starting pods and containers.
|
||||
|
||||
* `kubectl`: the command line util to talk to your cluster.
|
||||
|
||||
kubeadm **will not** install or manage `kubelet` or `kubectl` for you, so you will
|
||||
need to ensure they match the version of the Kubernetes control plane you want
|
||||
kubeadm to install for you. If you do not, there is a risk of a version skew occurring that
|
||||
can lead to unexpected, buggy behaviour. However, _one_ minor version skew between the
|
||||
kubelet and the control plane is supported, but the kubelet version may never exceed the API
|
||||
server version. For example, kubelets running 1.7.0 should be fully compatible with a 1.8.0 API server,
|
||||
but not vice versa.
|
||||
|
||||
For information about installing `kubectl`, see [Install and set up kubectl](/docs/tasks/tools/).
|
||||
-->
|
||||
## 安装 kubeadm、kubelet 和 kubectl
|
||||
|
||||
你需要在每台机器上安装以下的软件包：
|
||||
|
||||
* `kubeadm`：用来初始化集群的指令。
|
||||
|
||||
* `kubelet`：在集群中的每个节点上用来启动 Pod 和容器等。
|
||||
|
||||
* `kubectl`：用来与集群通信的命令行工具。
|
||||
|
||||
kubeadm **不能** 帮你安装或者管理 `kubelet` 或 `kubectl`，所以你需要
|
||||
确保它们与通过 kubeadm 安装的控制平面的版本相匹配。
|
||||
如果不这样做，则存在发生版本偏差的风险，可能会导致一些预料之外的错误和问题。
|
||||
然而，控制平面与 kubelet 间的相差一个次要版本不一致是支持的，但 kubelet
|
||||
的版本不可以超过 API 服务器的版本。
|
||||
例如，1.7.0 版本的 kubelet 可以完全兼容 1.8.0 版本的 API 服务器，反之则不可以。
|
||||
|
||||
有关安装 `kubectl` 的信息，请参阅[安装和设置 kubectl](/zh/docs/tasks/tools/)文档。
|
||||
|
||||
{{< warning >}}
|
||||
<!--
|
||||
These instructions exclude all Kubernetes packages from any system upgrades.
|
||||
This is because kubeadm and Kubernetes require
|
||||
[special attention to upgrade](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-14/).
|
||||
-->
|
||||
这些指南不包括系统升级时使用的所有 Kubernetes 程序包。这是因为 kubeadm 和 Kubernetes
|
||||
有[特殊的升级注意事项](/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)。
|
||||
{{</ warning >}}
|
||||
|
||||
<!--
|
||||
For more information on version skews, see:
|
||||
|
||||
* Kubernetes [version and version-skew policy](/docs/setup/release/version-skew-policy/)
|
||||
* Kubeadm-specific [version skew policy](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#version-skew-policy)
|
||||
-->
|
||||
关于版本偏差的更多信息，请参阅以下文档：
|
||||
|
||||
* Kubernetes [版本与版本间的偏差策略](/zh/docs/setup/release/version-skew-policy/)
|
||||
* Kubeadm 特定的[版本偏差策略](/zh/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#version-skew-policy)
|
||||
|
||||
{{< tabs name="k8s_install" >}}
|
||||
{{% tab name="基于 Debian 的发行版" %}}
|
||||
|
||||
<!--
|
||||
1. Update the `apt` package index and install packages needed to use the Kubernetes `apt` repository:
|
||||
-->
|
||||
1. 更新 `apt` 包索引并安装使用 Kubernetes `apt` 仓库所需要的包：
|
||||
|
||||
```shell
|
||||
sudo apt-get update
|
||||
sudo apt-get install -y apt-transport-https ca-certificates curl
|
||||
```
|
||||
|
||||
<!--
|
||||
2. Download the Google Cloud public signing key:
|
||||
-->
|
||||
2. 下载 Google Cloud 公开签名秘钥：
|
||||
|
||||
```shell
|
||||
sudo curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg
|
||||
```
|
||||
|
||||
<!--
|
||||
3. Add the Kubernetes `apt` repository:
|
||||
-->
|
||||
3. 添加 Kubernetes `apt` 仓库：
|
||||
|
||||
```shell
|
||||
echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list
|
||||
```
|
||||
|
||||
<!--
|
||||
4. Update `apt` package index, install kubelet, kubeadm and kubectl, and pin their version:
|
||||
-->
|
||||
4. 更新 `apt` 包索引，安装 kubelet、kubeadm 和 kubectl，并锁定其版本：
|
||||
|
||||
```shell
|
||||
sudo apt-get update
|
||||
sudo apt-get install -y kubelet kubeadm kubectl
|
||||
sudo apt-mark hold kubelet kubeadm kubectl
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
|
||||
{{% tab name="基于 Red Hat 的发行版" %}}
|
||||
|
||||
```bash
|
||||
cat <<EOF | sudo tee /etc/yum.repos.d/kubernetes.repo
|
||||
[kubernetes]
|
||||
name=Kubernetes
|
||||
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-\$basearch
|
||||
enabled=1
|
||||
gpgcheck=1
|
||||
repo_gpgcheck=1
|
||||
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
|
||||
exclude=kubelet kubeadm kubectl
|
||||
EOF
|
||||
|
||||
# 将 SELinux 设置为 permissive 模式（相当于将其禁用）
|
||||
sudo setenforce 0
|
||||
sudo sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config
|
||||
|
||||
sudo yum install -y kubelet kubeadm kubectl --disableexcludes=kubernetes
|
||||
|
||||
sudo systemctl enable --now kubelet
|
||||
```
|
||||
|
||||
<!--
|
||||
**Note:**
|
||||
|
||||
- Setting SELinux in permissive mode by running `setenforce 0` and `sed ...` effectively disables it.
|
||||
This is required to allow containers to access the host filesystem, which is needed by pod networks for example.
|
||||
You have to do this until SELinux support is improved in the kubelet.
|
||||
|
||||
- You can leave SELinux enabled if you know how to configure it but it may require settings that are not supported by kubeadm.
|
||||
- If the `baseurl` fails because your Red Hat-based distribution cannot interpret `basearch`, replace `\$basearch` with your computer's architecture.
|
||||
Type `uname -m` to see that value.
|
||||
For example, the `baseurl` URL for `x86_64` could be: `https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64`.
|
||||
-->
|
||||
**请注意：**
|
||||
|
||||
- 通过运行命令 `setenforce 0` 和 `sed ...` 将 SELinux 设置为 permissive 模式
|
||||
可以有效地将其禁用。
|
||||
这是允许容器访问主机文件系统所必需的，而这些操作时为了例如 Pod 网络工作正常。
|
||||
|
||||
你必须这么做，直到 kubelet 做出对 SELinux 的支持进行升级为止。
|
||||
|
||||
- 如果你知道如何配置 SELinux 则可以将其保持启用状态，但可能需要设定 kubeadm 不支持的部分配置
|
||||
- 如果由于该 Red Hat 的发行版无法解析 `basearch` 导致获取 `baseurl` 失败，请将 `\$basearch` 替换为你计算机的架构。
|
||||
输入 `uname -m` 以查看该值。
|
||||
例如，`x86_64` 的 `baseurl` URL 可以是：`https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64`。
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab name="无包管理器的情况" %}}
|
||||
|
||||
<!--
|
||||
Install CNI plugins (required for most pod network):
|
||||
-->
|
||||
安装 CNI 插件（大多数 Pod 网络都需要）：
|
||||
|
||||
```bash
|
||||
CNI_VERSION="v0.8.2"
|
||||
ARCH="amd64"
|
||||
sudo mkdir -p /opt/cni/bin
|
||||
curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/cni-plugins-linux-${ARCH}-${CNI_VERSION}.tgz" | sudo tar -C /opt/cni/bin -xz
|
||||
```
|
||||
|
||||
<!--
|
||||
Define the directory to download command files
|
||||
-->
|
||||
定义要下载命令文件的目录。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
The `DOWNLOAD_DIR` variable must be set to a writable directory.
|
||||
If you are running Flatcar Container Linux, set `DOWNLOAD_DIR=/opt/bin`.
|
||||
-->
|
||||
`DOWNLOAD_DIR` 变量必须被设置为一个可写入的目录。
|
||||
如果你在运行 Flatcar Container Linux，可将 `DOWNLOAD_DIR` 设置为 `/opt/bin`。
|
||||
{{< /note >}}
|
||||
|
||||
```bash
|
||||
DOWNLOAD_DIR=/usr/local/bin
|
||||
sudo mkdir -p $DOWNLOAD_DIR
|
||||
```
|
||||
|
||||
<!--
|
||||
Install crictl (required for kubeadm / Kubelet Container Runtime Interface (CRI))
|
||||
-->
|
||||
安装 crictl（kubeadm/kubelet 容器运行时接口（CRI）所需）
|
||||
|
||||
```bash
|
||||
CRICTL_VERSION="v1.22.0"
|
||||
ARCH="amd64"
|
||||
curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-${ARCH}.tar.gz" | sudo tar -C $DOWNLOAD_DIR -xz
|
||||
```
|
||||
|
||||
<!--
|
||||
Install `kubeadm`, `kubelet`, `kubectl` and add a `kubelet` systemd service:
|
||||
-->
|
||||
安装 `kubeadm`、`kubelet`、`kubectl` 并添加 `kubelet` 系统服务：
|
||||
|
||||
```bash
|
||||
RELEASE="$(curl -sSL https://dl.k8s.io/release/stable.txt)"
|
||||
ARCH="amd64"
|
||||
cd $DOWNLOAD_DIR
|
||||
sudo curl -L --remote-name-all https://storage.googleapis.com/kubernetes-release/release/${RELEASE}/bin/linux/${ARCH}/{kubeadm,kubelet,kubectl}
|
||||
sudo chmod +x {kubeadm,kubelet,kubectl}
|
||||
|
||||
RELEASE_VERSION="v0.4.0"
|
||||
curl -sSL "https://raw.githubusercontent.com/kubernetes/release/${RELEASE_VERSION}/cmd/kubepkg/templates/latest/deb/kubelet/lib/systemd/system/kubelet.service" | sed "s:/usr/bin:${DOWNLOAD_DIR}:g" | sudo tee /etc/systemd/system/kubelet.service
|
||||
sudo mkdir -p /etc/systemd/system/kubelet.service.d
|
||||
curl -sSL "https://raw.githubusercontent.com/kubernetes/release/${RELEASE_VERSION}/cmd/kubepkg/templates/latest/deb/kubeadm/10-kubeadm.conf" | sed "s:/usr/bin:${DOWNLOAD_DIR}:g" | sudo tee /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
|
||||
```
|
||||
|
||||
<!--
|
||||
Enable and start `kubelet`:
|
||||
-->
|
||||
激活并启动 `kubelet`：
|
||||
|
||||
```bash
|
||||
systemctl enable --now kubelet
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
The Flatcar Container Linux distribution mounts the `/usr` directory as a read-only filesystem.
|
||||
Before bootstrapping your cluster, you need to take additional steps to configure a writable directory.
|
||||
See the [Kubeadm Troubleshooting guide](/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/#usr-mounted-read-only/) to learn how to set up a writable directory.
|
||||
-->
|
||||
Flatcar Container Linux 发行版会将 `/usr/` 目录挂载为一个只读文件系统。
|
||||
在启动引导你的集群之前，你需要执行一些额外的操作来配置一个可写入的目录。
|
||||
参见 [kubeadm 故障排查指南](/zh/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/#usr-mounted-read-only/)
|
||||
以了解如何配置一个可写入的目录。
|
||||
{{< /note >}}
|
||||
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
<!--
|
||||
The kubelet is now restarting every few seconds, as it waits in a crashloop for
|
||||
kubeadm to tell it what to do.
|
||||
-->
|
||||
kubelet 现在每隔几秒就会重启，因为它陷入了一个等待 kubeadm 指令的死循环。
|
||||
|
||||
<!--
|
||||
## Configure cgroup driver
|
||||
|
||||
Both the container runtime and the kubelet have a property called
|
||||
["cgroup driver"](/docs/setup/production-environment/container-runtimes/), which is important
|
||||
for the management of cgroups on Linux machines.
|
||||
-->
|
||||
## 配置 cgroup 驱动程序 {#configure-cgroup-driver}
|
||||
|
||||
容器运行时和 kubelet 都具有名字为
|
||||
["cgroup driver"](/zh/docs/setup/production-environment/container-runtimes/)
|
||||
的属性，该属性对于在 Linux 机器上管理 CGroups 而言非常重要。
|
||||
|
||||
{{< warning >}}
|
||||
<!--
|
||||
Matching the container runtime and kubelet cgroup drivers is required or otherwise the kubelet process will fail.
|
||||
|
||||
See [Configuring a cgroup driver](/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/) for more details.
|
||||
-->
|
||||
你需要确保容器运行时和 kubelet 所使用的是相同的 cgroup 驱动，否则 kubelet
|
||||
进程会失败。
|
||||
|
||||
相关细节可参见[配置 cgroup 驱动](/zh/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/)。
|
||||
{{< /warning >}}
|
||||
|
||||
<!--
|
||||
## Troubleshooting
|
||||
|
||||
If you are running into difficulties with kubeadm, please consult our [troubleshooting docs](/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/).
|
||||
-->
|
||||
## 故障排查 {#troubleshooting}
|
||||
|
||||
如果你在使用 kubeadm 时遇到困难，请参阅我们的
|
||||
[故障排查文档](/zh/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/)。
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
<!--
|
||||
* [Using kubeadm to Create a Cluster](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)
|
||||
-->
|
||||
* [使用 kubeadm 创建集群](/zh/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)
|
||||
@@ -0,0 +1,398 @@
|
||||
---
|
||||
title: 使用 kubeadm 配置集群中的每个 kubelet
|
||||
content_type: concept
|
||||
weight: 80
|
||||
---
|
||||
<!--
|
||||
reviewers:
|
||||
- sig-cluster-lifecycle
|
||||
title: Configuring each kubelet in your cluster using kubeadm
|
||||
content_type: concept
|
||||
weight: 80
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
{{% dockershim-removal %}}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.11" state="stable" >}}
|
||||
|
||||
<!--
|
||||
The lifecycle of the kubeadm CLI tool is decoupled from the
|
||||
[kubelet](/docs/reference/command-line-tools-reference/kubelet), which is a daemon that runs
|
||||
on each node within the Kubernetes cluster. The kubeadm CLI tool is executed by the user when Kubernetes is
|
||||
initialized or upgraded, whereas the kubelet is always running in the background.
|
||||
|
||||
Since the kubelet is a daemon, it needs to be maintained by some kind of an init
|
||||
system or service manager. When the kubelet is installed using DEBs or RPMs,
|
||||
systemd is configured to manage the kubelet. You can use a different service
|
||||
manager instead, but you need to configure it manually.
|
||||
|
||||
Some kubelet configuration details need to be the same across all kubelets involved in the cluster, while
|
||||
other configuration aspects need to be set on a per-kubelet basis to accommodate the different
|
||||
characteristics of a given machine (such as OS, storage, and networking). You can manage the configuration
|
||||
of your kubelets manually, but kubeadm now provides a `KubeletConfiguration` API type for
|
||||
[managing your kubelet configurations centrally](#configure-kubelets-using-kubeadm).
|
||||
-->
|
||||
kubeadm CLI 工具的生命周期与 [kubelet](/zh/docs/reference/command-line-tools-reference/kubelet)
|
||||
解耦；kubelet 是一个守护程序，在 Kubernetes 集群中的每个节点上运行。
|
||||
当 Kubernetes 初始化或升级时，kubeadm CLI 工具由用户执行，而 kubelet 始终在后台运行。
|
||||
|
||||
由于kubelet是守护程序，因此需要通过某种初始化系统或服务管理器进行维护。
|
||||
当使用 DEB 或 RPM 安装 kubelet 时，配置系统去管理 kubelet。
|
||||
你可以改用其他服务管理器，但需要手动地配置。
|
||||
|
||||
集群中涉及的所有 kubelet 的一些配置细节都必须相同，
|
||||
而其他配置方面则需要基于每个 kubelet 进行设置，以适应给定机器的不同特性（例如操作系统、存储和网络）。
|
||||
你可以手动地管理 kubelet 的配置，但是 kubeadm 现在提供一种 `KubeletConfiguration` API 类型
|
||||
用于[集中管理 kubelet 的配置](#configure-kubelets-using-kubeadm)。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
## Kubelet configuration patterns
|
||||
-->
|
||||
## Kubelet 配置模式 {#kubelet-configuration-patterns}
|
||||
|
||||
<!--
|
||||
The following sections describe patterns to kubelet configuration that are simplified by
|
||||
using kubeadm, rather than managing the kubelet configuration for each Node manually.
|
||||
-->
|
||||
以下各节讲述了通过使用 kubeadm 简化 kubelet 配置模式，而不是在每个节点上手动地管理 kubelet 配置。
|
||||
|
||||
<!--
|
||||
### Propagating cluster-level configuration to each kubelet
|
||||
-->
|
||||
### 将集群级配置传播到每个 kubelet 中 {#propagating-cluster-level-configuration-to-each-kubelet}
|
||||
|
||||
<!--
|
||||
You can provide the kubelet with default values to be used by `kubeadm init` and `kubeadm join`
|
||||
commands. Interesting examples include using a different container runtime or setting the default subnet
|
||||
used by services.
|
||||
|
||||
If you want your services to use the subnet `10.96.0.0/12` as the default for services, you can pass
|
||||
the `--service-cidr` parameter to kubeadm:
|
||||
-->
|
||||
你可以通过 `kubeadm init` 和 `kubeadm join` 命令为 kubelet 提供默认值。
|
||||
有趣的示例包括使用其他容器运行时或通过服务器设置不同的默认子网。
|
||||
|
||||
如果你想使用子网 `10.96.0.0/12` 作为服务的默认网段，你可以给 kubeadm 传递 `--service-cidr` 参数：
|
||||
|
||||
```bash
|
||||
kubeadm init --service-cidr 10.96.0.0/12
|
||||
```
|
||||
|
||||
<!--
|
||||
Virtual IPs for services are now allocated from this subnet. You also need to set the DNS address used
|
||||
by the kubelet, using the `--cluster-dns` flag. This setting needs to be the same for every kubelet
|
||||
on every manager and Node in the cluster. The kubelet provides a versioned, structured API object
|
||||
that can configure most parameters in the kubelet and push out this configuration to each running
|
||||
kubelet in the cluster. This object is called
|
||||
[`KubeletConfiguration`](/docs/reference/config-api/kubelet-config.v1beta1/).
|
||||
The `KubeletConfiguration` allows the user to specify flags such as the cluster DNS IP addresses expressed as
|
||||
a list of values to a camelCased key, illustrated by the following example:
|
||||
-->
|
||||
现在，可以从该子网分配服务的虚拟 IP。
|
||||
你还需要通过 kubelet 使用 `--cluster-dns` 标志设置 DNS 地址。
|
||||
在集群中的每个管理器和节点上的 kubelet 的设置需要相同。
|
||||
kubelet 提供了一个版本化的结构化 API 对象，该对象可以配置 kubelet 中的大多数参数，并将此配置推送到集群中正在运行的每个 kubelet 上。
|
||||
此对象被称为 [`KubeletConfiguration`](/zh/docs/reference/config-api/kubelet-config.v1beta1/)。
|
||||
`KubeletConfiguration` 允许用户指定标志，例如用骆峰值代表集群的 DNS IP 地址，如下所示：
|
||||
|
||||
```yaml
|
||||
apiVersion: kubelet.config.k8s.io/v1beta1
|
||||
kind: KubeletConfiguration
|
||||
clusterDNS:
|
||||
- 10.96.0.10
|
||||
```
|
||||
|
||||
<!--
|
||||
For more details on the `KubeletConfiguration` have a look at [this section](#configure-kubelets-using-kubeadm).
|
||||
-->
|
||||
有关 `KubeletConfiguration` 的更多详细信息，请参阅[本节](#configure-kubelets-using-kubeadm)。
|
||||
|
||||
<!--
|
||||
### Providing instance-specific configuration details
|
||||
|
||||
Some hosts require specific kubelet configurations due to differences in hardware, operating system,
|
||||
networking, or other host-specific parameters. The following list provides a few examples.
|
||||
-->
|
||||
### 提供特定于某实例的配置细节 {#providing-instance-specific-configuration-details}
|
||||
|
||||
由于硬件、操作系统、网络或者其他主机特定参数的差异。某些主机需要特定的 kubelet 配置。
|
||||
以下列表提供了一些示例。
|
||||
|
||||
<!--
|
||||
- The path to the DNS resolution file, as specified by the `--resolv-conf` kubelet
|
||||
configuration flag, may differ among operating systems, or depending on whether you are using
|
||||
`systemd-resolved`. If this path is wrong, DNS resolution will fail on the Node whose kubelet
|
||||
is configured incorrectly.
|
||||
|
||||
- The Node API object `.metadata.name` is set to the machine's hostname by default,
|
||||
unless you are using a cloud provider. You can use the `--hostname-override` flag to override the
|
||||
default behavior if you need to specify a Node name different from the machine's hostname.
|
||||
|
||||
- Currently, the kubelet cannot automatically detect the cgroup driver used by the container runtime,
|
||||
but the value of `--cgroup-driver` must match the cgroup driver used by the container runtime to ensure
|
||||
the health of the kubelet.
|
||||
|
||||
- To specify the container runtime you must set its endpoint with the
|
||||
`--container-runtime-endpoint=<path>` flag.
|
||||
|
||||
You can specify these flags by configuring an individual kubelet's configuration in your service manager,
|
||||
such as systemd.
|
||||
-->
|
||||
- 由 kubelet 配置标志 `--resolv-conf` 指定的 DNS 解析文件的路径在操作系统之间可能有所不同，
|
||||
它取决于你是否使用 `systemd-resolved`。
|
||||
如果此路径错误，则在其 kubelet 配置错误的节点上 DNS 解析也将失败。
|
||||
|
||||
- 除非你使用云驱动，否则默认情况下 Node API 对象的 `.metadata.name` 会被设置为计算机的主机名。
|
||||
如果你需要指定一个与机器的主机名不同的节点名称，你可以使用 `--hostname-override` 标志覆盖默认值。
|
||||
|
||||
- 当前，kubelet 无法自动检测容器运行时使用的 cgroup 驱动程序，
|
||||
但是值 `--cgroup-driver` 必须与容器运行时使用的 cgroup 驱动程序匹配，以确保 kubelet 的健康运行状况。
|
||||
|
||||
- 要指定容器运行时，你必须用 `--container-runtime-endpoint=<path>` 标志来指定端点。
|
||||
|
||||
你可以在服务管理器（例如 systemd）中设定某个 kubelet 的配置来指定这些参数。
|
||||
|
||||
<!--
|
||||
## Configure kubelets using kubeadm
|
||||
|
||||
It is possible to configure the kubelet that kubeadm will start if a custom `KubeletConfiguration`
|
||||
API object is passed with a configuration file like so `kubeadm ... --config some-config-file.yaml`.
|
||||
|
||||
By calling `kubeadm config print init-defaults --component-configs KubeletConfiguration` you can
|
||||
see all the default values for this structure.
|
||||
|
||||
Also have a look at the
|
||||
[reference for the KubeletConfiguration](/docs/reference/config-api/kubelet-config.v1beta1/)
|
||||
for more information on the individual fields.
|
||||
-->
|
||||
## 使用 kubeadm 配置 kubelet {#configure-kubelets-using-kubeadm}
|
||||
|
||||
如果自定义的 `KubeletConfiguration` API 对象使用像 `kubeadm ... --config some-config-file.yaml` 这样的配置文件进行传递，则可以配置 kubeadm 启动的 kubelet。
|
||||
|
||||
通过调用 `kubeadm config print init-defaults --component-configs KubeletConfiguration`，
|
||||
你可以看到此结构中的所有默认值。
|
||||
|
||||
也可以阅读 [KubeletConfiguration 参考](/zh/docs/reference/config-api/kubelet-config.v1beta1/)
|
||||
来获取有关各个字段的更多信息。
|
||||
|
||||
<!--
|
||||
### Workflow when using `kubeadm init`
|
||||
-->
|
||||
### 使用 `kubeadm init` 时的工作流程 {#workflow-when-using-kubeadm-init}
|
||||
|
||||
<!--
|
||||
When you call `kubeadm init`, the kubelet configuration is marshalled to disk
|
||||
at `/var/lib/kubelet/config.yaml`, and also uploaded to a `kubelet-config` ConfigMap in the `kube-system`
|
||||
namespace of the cluster. A kubelet configuration file is also written to `/etc/kubernetes/kubelet.conf`
|
||||
with the baseline cluster-wide configuration for all kubelets in the cluster. This configuration file
|
||||
points to the client certificates that allow the kubelet to communicate with the API server. This
|
||||
addresses the need to
|
||||
[propagate cluster-level configuration to each kubelet](#propagating-cluster-level-configuration-to-each-kubelet).
|
||||
-->
|
||||
当调用 `kubeadm init` 时，kubelet 的配置会被写入磁盘 `/var/lib/kubelet/config.yaml`，
|
||||
并上传到集群 `kube-system` 命名空间的 `kubelet-config` ConfigMap。
|
||||
kubelet 配置信息也被写入 `/etc/kubernetes/kubelet.conf`，其中包含集群内所有 kubelet 的基线配置。
|
||||
此配置文件指向允许 kubelet 与 API 服务器通信的客户端证书。
|
||||
这解决了[将集群级配置传播到每个 kubelet](#propagating-cluster-level-configuration-to-each-kubelet) 的需求。
|
||||
|
||||
<!--
|
||||
To address the second pattern of
|
||||
[providing instance-specific configuration details](#providing-instance-specific-configuration-details),
|
||||
kubeadm writes an environment file to `/var/lib/kubelet/kubeadm-flags.env`, which contains a list of
|
||||
flags to pass to the kubelet when it starts. The flags are presented in the file like this:
|
||||
-->
|
||||
针对[为特定实例提供配置细节](#providing-instance-specific-configuration-details)的第二种模式，
|
||||
kubeadm 的解决方法是将环境文件写入 `/var/lib/kubelet/kubeadm-flags.env`，其中包含了一个标志列表，
|
||||
当 kubelet 启动时，该标志列表会传递给 kubelet 标志在文件中的显示方式如下：
|
||||
|
||||
```bash
|
||||
KUBELET_KUBEADM_ARGS="--flag1=value1 --flag2=value2 ..."
|
||||
```
|
||||
|
||||
<!--
|
||||
In addition to the flags used when starting the kubelet, the file also contains dynamic
|
||||
parameters such as the cgroup driver and whether to use a different container runtime socket
|
||||
(`--cri-socket`).
|
||||
-->
|
||||
除了启动 kubelet 时所使用的标志外，该文件还包含动态参数，例如 cgroup 驱动程序以及是否使用其他容器运行时套接字（`--cri-socket`）。
|
||||
|
||||
<!--
|
||||
After marshalling these two files to disk, kubeadm attempts to run the following two
|
||||
commands, if you are using systemd:
|
||||
-->
|
||||
将这两个文件编组到磁盘后，如果使用 systemd，则 kubeadm 尝试运行以下两个命令：
|
||||
|
||||
```bash
|
||||
systemctl daemon-reload && systemctl restart kubelet
|
||||
```
|
||||
|
||||
<!--
|
||||
If the reload and restart are successful, the normal `kubeadm init` workflow continues.
|
||||
-->
|
||||
如果重新加载和重新启动成功，则正常的 `kubeadm init` 工作流程将继续。
|
||||
|
||||
<!--
|
||||
### Workflow when using `kubeadm join`
|
||||
|
||||
When you run `kubeadm join`, kubeadm uses the Bootstrap Token credential to perform
|
||||
a TLS bootstrap, which fetches the credential needed to download the
|
||||
`kubelet-config` ConfigMap and writes it to `/var/lib/kubelet/config.yaml`. The dynamic
|
||||
environment file is generated in exactly the same way as `kubeadm init`.
|
||||
-->
|
||||
### 使用 `kubeadm join` 时的工作流程 {#workflow-when-using-kubeadm-join}
|
||||
|
||||
当运行 `kubeadm join` 时，kubeadm 使用 Bootstrap Token 证书执行 TLS 引导，该引导会获取一份证书，
|
||||
该证书需要下载 `kubelet-config` ConfigMap 并把它写入 `/var/lib/kubelet/config.yaml` 中。
|
||||
动态环境文件的生成方式恰好与 `kubeadm init` 完全相同。
|
||||
|
||||
<!--
|
||||
Next, `kubeadm` runs the following two commands to load the new configuration into the kubelet:
|
||||
-->
|
||||
接下来，`kubeadm` 运行以下两个命令将新配置加载到 kubelet 中：
|
||||
|
||||
```bash
|
||||
systemctl daemon-reload && systemctl restart kubelet
|
||||
```
|
||||
|
||||
<!--
|
||||
After the kubelet loads the new configuration, kubeadm writes the
|
||||
`/etc/kubernetes/bootstrap-kubelet.conf` KubeConfig file, which contains a CA certificate and Bootstrap
|
||||
Token. These are used by the kubelet to perform the TLS Bootstrap and obtain a unique
|
||||
credential, which is stored in `/etc/kubernetes/kubelet.conf`.
|
||||
-->
|
||||
在 kubelet 加载新配置后，kubeadm 将写入 `/etc/kubernetes/bootstrap-kubelet.conf` KubeConfig 文件中，
|
||||
该文件包含 CA 证书和引导程序令牌。
|
||||
kubelet 使用这些证书执行 TLS 引导程序并获取唯一的凭据，该凭据被存储在 `/etc/kubernetes/kubelet.conf` 中。
|
||||
|
||||
<!--
|
||||
When the `/etc/kubernetes/kubelet.conf` file is written, the kubelet has finished performing the TLS Bootstrap.
|
||||
Kubeadm deletes the `/etc/kubernetes/bootstrap-kubelet.conf` file after completing the TLS Bootstrap.
|
||||
-->
|
||||
当 `/etc/kubernetes/kubelet.conf` 文件被写入后，kubelet 就完成了 TLS 引导过程。
|
||||
Kubeadm 在完成 TLS 引导过程后将删除 `/etc/kubernetes/bootstrap-kubelet.conf` 文件。
|
||||
|
||||
<!--
|
||||
## The kubelet drop-in file for systemd
|
||||
-->
|
||||
## kubelet 的 systemd drop-in 文件 {#the-kubelet-drop-in-file-for-systemd}
|
||||
|
||||
<!--
|
||||
`kubeadm` ships with configuration for how systemd should run the kubelet.
|
||||
Note that the kubeadm CLI command never touches this drop-in file.
|
||||
-->
|
||||
`kubeadm` 中附带了有关系统如何运行 kubelet 的 systemd 配置文件。
|
||||
请注意 kubeadm CLI 命令不会修改此文件。
|
||||
|
||||
<!--
|
||||
This configuration file installed by the `kubeadm`
|
||||
[DEB](https://github.com/kubernetes/release/blob/master/cmd/kubepkg/templates/latest/deb/kubeadm/10-kubeadm.conf) or
|
||||
[RPM package](https://github.com/kubernetes/release/blob/master/cmd/kubepkg/templates/latest/rpm/kubeadm/10-kubeadm.conf) is written to
|
||||
`/etc/systemd/system/kubelet.service.d/10-kubeadm.conf` and is used by systemd.
|
||||
It augments the basic
|
||||
[`kubelet.service` for RPM](https://github.com/kubernetes/release/blob/master/cmd/kubepkg/templates/latest/rpm/kubelet/kubelet.service) or
|
||||
[`kubelet.service` for DEB](https://github.com/kubernetes/release/blob/master/cmd/kubepkg/templates/latest/deb/kubelet/lib/systemd/system/kubelet.service):
|
||||
-->
|
||||
通过 `kubeadm` [DEB 包](https://github.com/kubernetes/release/blob/master/cmd/kubepkg/templates/latest/deb/kubeadm/10-kubeadm.conf)
|
||||
或者 [RPM 包](https://github.com/kubernetes/release/blob/master/cmd/kubepkg/templates/latest/rpm/kubeadm/10-kubeadm.conf)
|
||||
安装的配置文件被写入 `/etc/systemd/system/kubelet.service.d/10-kubeadm.conf` 并由 systemd 使用。
|
||||
它对原来的 [RPM 版本 `kubelet.service`](https://github.com/kubernetes/release/blob/master/cmd/kubepkg/templates/latest/rpm/kubelet/kubelet.service)
|
||||
或者 [DEB 版本 `kubelet.service`](https://github.com/kubernetes/release/blob/master/cmd/kubepkg/templates/latest/deb/kubelet/lib/systemd/system/kubelet.service)
|
||||
作了增强：
|
||||
|
||||
<!--
|
||||
{{< note >}}
|
||||
The contents below are just an example. If you don't want to use a package manager
|
||||
follow the guide outlined in the [Without a package manager](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#k8s-install-2))
|
||||
section.
|
||||
{{< /note >}}
|
||||
-->
|
||||
{{< note >}}
|
||||
下面的内容只是一个例子。如果你不想使用包管理器，
|
||||
请遵循[没有包管理器](/zh/docs/setup/productionenvironment/tools/kubeadm/install-kubeadm/#k8s-install-2))
|
||||
章节的指南。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
```none
|
||||
[Service]
|
||||
Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf"
|
||||
Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml"
|
||||
# This is a file that "kubeadm init" and "kubeadm join" generate at runtime, populating
|
||||
the KUBELET_KUBEADM_ARGS variable dynamically
|
||||
EnvironmentFile=-/var/lib/kubelet/kubeadm-flags.env
|
||||
# This is a file that the user can use for overrides of the kubelet args as a last resort. Preferably,
|
||||
# the user should use the .NodeRegistration.KubeletExtraArgs object in the configuration files instead.
|
||||
# KUBELET_EXTRA_ARGS should be sourced from this file.
|
||||
EnvironmentFile=-/etc/default/kubelet
|
||||
ExecStart=
|
||||
ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS
|
||||
```
|
||||
-->
|
||||
```none
|
||||
[Service]
|
||||
Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf"
|
||||
Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml"
|
||||
# 这是 "kubeadm init" 和 "kubeadm join" 运行时生成的文件，动态地填充 KUBELET_KUBEADM_ARGS 变量
|
||||
EnvironmentFile=-/var/lib/kubelet/kubeadm-flags.env
|
||||
# 这是一个文件，用户在不得已下可以将其用作替代 kubelet args。
|
||||
# 用户最好使用 .NodeRegistration.KubeletExtraArgs 对象在配置文件中替代。
|
||||
# KUBELET_EXTRA_ARGS 应该从此文件中获取。
|
||||
EnvironmentFile=-/etc/default/kubelet
|
||||
ExecStart=
|
||||
ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS
|
||||
```
|
||||
|
||||
<!--
|
||||
This file specifies the default locations for all of the files managed by kubeadm for the kubelet.
|
||||
-->
|
||||
此文件指定由 kubeadm 为 kubelet 管理的所有文件的默认位置。
|
||||
|
||||
<!--
|
||||
- The KubeConfig file to use for the TLS Bootstrap is `/etc/kubernetes/bootstrap-kubelet.conf`,
|
||||
but it is only used if `/etc/kubernetes/kubelet.conf` does not exist.
|
||||
- The KubeConfig file with the unique kubelet identity is `/etc/kubernetes/kubelet.conf`.
|
||||
- The file containing the kubelet's ComponentConfig is `/var/lib/kubelet/config.yaml`.
|
||||
- The dynamic environment file that contains `KUBELET_KUBEADM_ARGS` is sourced from `/var/lib/kubelet/kubeadm-flags.env`.
|
||||
- The file that can contain user-specified flag overrides with `KUBELET_EXTRA_ARGS` is sourced from
|
||||
`/etc/default/kubelet` (for DEBs), or `/etc/sysconfig/kubelet` (for RPMs). `KUBELET_EXTRA_ARGS`
|
||||
is last in the flag chain and has the highest priority in the event of conflicting settings.
|
||||
-->
|
||||
- 用于 TLS 引导程序的 KubeConfig 文件为 `/etc/kubernetes/bootstrap-kubelet.conf`，
|
||||
但仅当 `/etc/kubernetes/kubelet.conf` 不存在时才能使用。
|
||||
- 具有唯一 kubelet 标识的 KubeConfig 文件为 `/etc/kubernetes/kubelet.conf`。
|
||||
- 包含 kubelet 的组件配置的文件为 `/var/lib/kubelet/config.yaml`。
|
||||
- 包含的动态环境的文件 `KUBELET_KUBEADM_ARGS` 是来源于 `/var/lib/kubelet/kubeadm-flags.env`。
|
||||
- 包含用户指定标志替代的文件 `KUBELET_EXTRA_ARGS` 是来源于
|
||||
`/etc/default/kubelet`（对于 DEB），或者 `/etc/sysconfig/kubelet`（对于 RPM）。
|
||||
`KUBELET_EXTRA_ARGS` 在标志链中排在最后，并且在设置冲突时具有最高优先级。
|
||||
|
||||
<!--
|
||||
## Kubernetes binaries and package contents
|
||||
-->
|
||||
## Kubernetes 可执行文件和软件包内容 {#kubernetes-binaries-and-package-contents}
|
||||
|
||||
<!--
|
||||
The DEB and RPM packages shipped with the Kubernetes releases are:
|
||||
-->
|
||||
Kubernetes 版本对应的 DEB 和 RPM 软件包是：
|
||||
|
||||
<!--
|
||||
| Package name | Description |
|
||||
|--------------|-------------|
|
||||
| `kubeadm` | Installs the `/usr/bin/kubeadm` CLI tool and the [kubelet drop-in file](#the-kubelet-drop-in-file-for-systemd) for the kubelet. |
|
||||
| `kubelet` | Installs the `/usr/bin/kubelet` binary. |
|
||||
| `kubectl` | Installs the `/usr/bin/kubectl` binary. |
|
||||
| `cri-tools` | Installs the `/usr/bin/crictl` binary from the [cri-tools git repository](https://github.com/kubernetes-sigs/cri-tools). |
|
||||
| `kubernetes-cni` | Installs the `/opt/cni/bin` binaries from the [plugins git repository](https://github.com/containernetworking/plugins). |
|
||||
-->
|
||||
| 软件包名称 | 描述 |
|
||||
|--------------|-------------|
|
||||
| `kubeadm` | 给 kubelet 安装 `/usr/bin/kubeadm` CLI 工具和 [kubelet 的 systemd drop-in 文件](#the-kubelet-drop-in-file-for-systemd)。 |
|
||||
| `kubelet` | 安装 `/usr/bin/kubelet` 可执行文件。 |
|
||||
| `kubectl` | 安装 `/usr/bin/kubectl` 可执行文件。 |
|
||||
| `cri-tools` | 从 [cri-tools git 仓库](https://github.com/kubernetes-sigs/cri-tools)中安装 `/usr/bin/crictl` 可执行文件。 |
|
||||
| `kubernetes-cni` | 从 [plugins git 仓库](https://github.com/containernetworking/plugins)中安装 `/opt/cni/bin` 可执行文件。|
|
||||
+404
@@ -0,0 +1,404 @@
|
||||
---
|
||||
title: 使用 kubeadm 创建一个高可用 etcd 集群
|
||||
content_type: task
|
||||
weight: 70
|
||||
---
|
||||
|
||||
<!--
|
||||
reviewers:
|
||||
- sig-cluster-lifecycle
|
||||
title: Set up a High Availability etcd Cluster with kubeadm
|
||||
content_type: task
|
||||
weight: 70
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
While kubeadm is being used as the management tool for external etcd nodes
|
||||
in this guide, please note that kubeadm does not plan to support certificate rotation
|
||||
or upgrades for such nodes. The long term plan is to empower the tool
|
||||
[etcdadm](https://github.com/kubernetes-sigs/etcdadm) to manage these
|
||||
aspects.
|
||||
-->
|
||||
在本指南中，使用 kubeadm 作为外部 etcd 节点管理工具，请注意 kubeadm 不计划支持此类节点的证书更换或升级。
|
||||
对于长期规划是使用 [etcdadm](https://github.com/kubernetes-sigs/etcdadm) 增强工具来管理这些方面。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
By default, kubeadm runs a local etcd instance on each control plane node.
|
||||
It is also possible to treat the etcd cluster as external and provision
|
||||
etcd instances on separate hosts. The differences between the two approaches are covered in the
|
||||
[Options for Highly Available topology](/docs/setup/production-environment/tools/kubeadm/ha-topology) page.
|
||||
-->
|
||||
|
||||
默认情况下，kubeadm 在每个控制平面节点上运行一个本地 etcd 实例。也可以使用外部的 etcd 集群，并在不同的主机上提供 etcd 实例。
|
||||
这两种方法的区别在 [高可用拓扑的选项](/zh/docs/setup/production-environment/tools/kubeadm/ha-topology) 页面中阐述。
|
||||
|
||||
<!--
|
||||
This task walks through the process of creating a high availability external
|
||||
etcd cluster of three members that can be used by kubeadm during cluster creation.
|
||||
-->
|
||||
|
||||
这个任务将指导你创建一个由三个成员组成的高可用外部 etcd 集群，该集群在创建过程中可被 kubeadm 使用。
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
<!--
|
||||
* Three hosts that can talk to each other over TCP ports 2379 and 2380. This document assumes these default ports. However, they are configurable through the kubeadm config file.
|
||||
-->
|
||||
* 三个可以通过 2379 和 2380 端口相互通信的主机。本文档使用这些作为默认端口。不过，它们可以通过 kubeadm 的配置文件进行自定义。
|
||||
|
||||
<!--
|
||||
* Each host must have systemd and a bash compatible shell installed.
|
||||
* Each host must [have a container runtime, kubelet, and kubeadm installed](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/).
|
||||
-->
|
||||
* 每个主机必须安装 systemd 和 bash 兼容的 shell。
|
||||
* 每台主机必须[安装有容器运行时、kubelet 和 kubeadm](/zh/docs/setup/production-environment/tools/kubeadm/install-kubeadm/)。
|
||||
|
||||
<!--
|
||||
* Some infrastructure to copy files between hosts. For example `ssh` and `scp` can satisfy this requirement.
|
||||
-->
|
||||
* 一些可以用来在主机间复制文件的基础设施。例如 `ssh` 和 `scp` 就可以满足需求。
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
<!--
|
||||
## Setting up the cluster
|
||||
-->
|
||||
## 建立集群
|
||||
|
||||
<!--
|
||||
The general approach is to generate all certs on one node and only distribute the *necessary* files to the other nodes.
|
||||
-->
|
||||
一般来说，是在一个节点上生成所有证书并且只分发这些*必要*的文件到其它节点上。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
kubeadm contains all the necessary crytographic machinery to generate the certificates described below; no other cryptographic tooling is required for this example.
|
||||
-->
|
||||
kubeadm 包含生成下述证书所需的所有必要的密码学工具；在这个例子中，不需要其他加密工具。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
{{< note >}}
|
||||
The examples below use IPv4 addresses but you can also configure kubeadm, the kubelet and etcd
|
||||
to use IPv6 addresses. Dual-stack is supported by some Kubernetes options, but not by etcd. For more details
|
||||
on Kubernetes dual-stack support see [Dual-stack support with kubeadm](/docs/setup/production-environment/tools/kubeadm/dual-stack-support/).
|
||||
{{< /note >}}
|
||||
-->
|
||||
|
||||
{{< note >}}
|
||||
下面的例子使用 IPv4 地址，但是你也可以使用 IPv6 地址配置 kubeadm、kubelet 和 etcd。一些 Kubernetes 选项支持双协议栈，但是 etcd 不支持。
|
||||
关于 Kubernetes 双协议栈支持的更多细节，请参见 [kubeadm 的双栈支持](/zh/docs/setup/production-environment/tools/kubeadm/dual-stack-support/)。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
1. Configure the kubelet to be a service manager for etcd.
|
||||
|
||||
{{< note >}}You must do this on every host where etcd should be running.{{< /note >}}
|
||||
Since etcd was created first, you must override the service priority by creating a new unit file
|
||||
that has higher precedence than the kubeadm-provided kubelet unit file.
|
||||
-->
|
||||
1. 将 kubelet 配置为 etcd 的服务管理器。
|
||||
|
||||
{{< note >}}
|
||||
你必须在要运行 etcd 的所有主机上执行此操作。
|
||||
{{< /note >}}
|
||||
由于 etcd 是首先创建的，因此你必须通过创建具有更高优先级的新文件来覆盖
|
||||
kubeadm 提供的 kubelet 单元文件。
|
||||
|
||||
```sh
|
||||
cat << EOF > /etc/systemd/system/kubelet.service.d/20-etcd-service-manager.conf
|
||||
[Service]
|
||||
ExecStart=
|
||||
# 将下面的 "systemd" 替换为你的容器运行时所使用的 cgroup 驱动。
|
||||
# kubelet 的默认值为 "cgroupfs"。
|
||||
# 如果需要的话，将 "--container-runtime-endpoint " 的值替换为一个不同的容器运行时。
|
||||
ExecStart=/usr/bin/kubelet --address=127.0.0.1 --pod-manifest-path=/etc/kubernetes/manifests --cgroup-driver=systemd
|
||||
Restart=always
|
||||
EOF
|
||||
|
||||
systemctl daemon-reload
|
||||
systemctl restart kubelet
|
||||
```
|
||||
|
||||
<!--
|
||||
Check the kubelet status to ensure it is running.
|
||||
-->
|
||||
|
||||
检查 kubelet 的状态以确保其处于运行状态：
|
||||
|
||||
```shell
|
||||
systemctl status kubelet
|
||||
```
|
||||
|
||||
<!--
|
||||
1. Create configuration files for kubeadm.
|
||||
|
||||
Generate one kubeadm configuration file for each host that will have an etcd
|
||||
member running on it using the following script.
|
||||
-->
|
||||
2. 为 kubeadm 创建配置文件。
|
||||
|
||||
使用以下脚本为每个将要运行 etcd 成员的主机生成一个 kubeadm 配置文件。
|
||||
|
||||
```sh
|
||||
# 使用你的主机 IP 替换 HOST0、HOST1 和 HOST2 的 IP 地址
|
||||
export HOST0=10.0.0.6
|
||||
export HOST1=10.0.0.7
|
||||
export HOST2=10.0.0.8
|
||||
|
||||
# 使用你的主机名更新 NAME0, NAME1 和 NAME2
|
||||
export NAME0="infra0"
|
||||
export NAME1="infra1"
|
||||
export NAME2="infra2"
|
||||
|
||||
# 创建临时目录来存储将被分发到其它主机上的文件
|
||||
mkdir -p /tmp/${HOST0}/ /tmp/${HOST1}/ /tmp/${HOST2}/
|
||||
|
||||
HOSTS=(${HOST0} ${HOST1} ${HOST2})
|
||||
NAMES=(${NAME0} ${NAME1} ${NAME2})
|
||||
|
||||
for i in "${!HOSTS[@]}"; do
|
||||
HOST=${HOSTS[$i]}
|
||||
NAME=${NAMES[$i]}
|
||||
cat << EOF > /tmp/${HOST}/kubeadmcfg.yaml
|
||||
---
|
||||
apiVersion: "kubeadm.k8s.io/v1beta3"
|
||||
kind: InitConfiguration
|
||||
nodeRegistration:
|
||||
name: ${NAME}
|
||||
localAPIEndpoint:
|
||||
advertiseAddress: ${HOST}
|
||||
---
|
||||
apiVersion: "kubeadm.k8s.io/v1beta3"
|
||||
kind: ClusterConfiguration
|
||||
etcd:
|
||||
local:
|
||||
serverCertSANs:
|
||||
- "${HOST}"
|
||||
peerCertSANs:
|
||||
- "${HOST}"
|
||||
extraArgs:
|
||||
initial-cluster: ${NAMES[0]}=https://${HOSTS[0]}:2380,${NAMES[1]}=https://${HOSTS[1]}:2380,${NAMES[2]}=https://${HOSTS[2]}:2380
|
||||
initial-cluster-state: new
|
||||
name: ${NAME}
|
||||
listen-peer-urls: https://${HOST}:2380
|
||||
listen-client-urls: https://${HOST}:2379
|
||||
advertise-client-urls: https://${HOST}:2379
|
||||
initial-advertise-peer-urls: https://${HOST}:2380
|
||||
EOF
|
||||
done
|
||||
```
|
||||
|
||||
<!--
|
||||
1. Generate the certificate authority
|
||||
|
||||
If you already have a CA then the only action that is copying the CA's `crt` and
|
||||
`key` file to `/etc/kubernetes/pki/etcd/ca.crt` and
|
||||
`/etc/kubernetes/pki/etcd/ca.key`. After those files have been copied,
|
||||
proceed to the next step, "Create certificates for each member".
|
||||
-->
|
||||
3. 生成证书颁发机构
|
||||
|
||||
如果你已经拥有 CA，那么唯一的操作是复制 CA 的 `crt` 和 `key` 文件到
|
||||
`etc/kubernetes/pki/etcd/ca.crt` 和 `/etc/kubernetes/pki/etcd/ca.key`。
|
||||
复制完这些文件后继续下一步，“为每个成员创建证书”。
|
||||
|
||||
<!--
|
||||
If you do not already have a CA then run this command on `$HOST0` (where you generated the configuration files for kubeadm).
|
||||
-->
|
||||
如果你还没有 CA，则在 `$HOST0`（你为 kubeadm 生成配置文件的位置）上运行此命令。
|
||||
|
||||
```shell
|
||||
kubeadm init phase certs etcd-ca
|
||||
```
|
||||
|
||||
<!--
|
||||
This creates two files
|
||||
-->
|
||||
这一操作创建如下两个文件
|
||||
|
||||
- `/etc/kubernetes/pki/etcd/ca.crt`
|
||||
- `/etc/kubernetes/pki/etcd/ca.key`
|
||||
|
||||
<!--
|
||||
1. Create certificates for each member
|
||||
-->
|
||||
4. 为每个成员创建证书
|
||||
|
||||
```shell
|
||||
kubeadm init phase certs etcd-server --config=/tmp/${HOST2}/kubeadmcfg.yaml
|
||||
kubeadm init phase certs etcd-peer --config=/tmp/${HOST2}/kubeadmcfg.yaml
|
||||
kubeadm init phase certs etcd-healthcheck-client --config=/tmp/${HOST2}/kubeadmcfg.yaml
|
||||
kubeadm init phase certs apiserver-etcd-client --config=/tmp/${HOST2}/kubeadmcfg.yaml
|
||||
cp -R /etc/kubernetes/pki /tmp/${HOST2}/
|
||||
# 清理不可重复使用的证书
|
||||
find /etc/kubernetes/pki -not -name ca.crt -not -name ca.key -type f -delete
|
||||
|
||||
kubeadm init phase certs etcd-server --config=/tmp/${HOST1}/kubeadmcfg.yaml
|
||||
kubeadm init phase certs etcd-peer --config=/tmp/${HOST1}/kubeadmcfg.yaml
|
||||
kubeadm init phase certs etcd-healthcheck-client --config=/tmp/${HOST1}/kubeadmcfg.yaml
|
||||
kubeadm init phase certs apiserver-etcd-client --config=/tmp/${HOST1}/kubeadmcfg.yaml
|
||||
cp -R /etc/kubernetes/pki /tmp/${HOST1}/
|
||||
find /etc/kubernetes/pki -not -name ca.crt -not -name ca.key -type f -delete
|
||||
|
||||
kubeadm init phase certs etcd-server --config=/tmp/${HOST0}/kubeadmcfg.yaml
|
||||
kubeadm init phase certs etcd-peer --config=/tmp/${HOST0}/kubeadmcfg.yaml
|
||||
kubeadm init phase certs etcd-healthcheck-client --config=/tmp/${HOST0}/kubeadmcfg.yaml
|
||||
kubeadm init phase certs apiserver-etcd-client --config=/tmp/${HOST0}/kubeadmcfg.yaml
|
||||
# 不需要移动 certs 因为它们是给 HOST0 使用的
|
||||
|
||||
# 清理不应从此主机复制的证书
|
||||
find /tmp/${HOST2} -name ca.key -type f -delete
|
||||
find /tmp/${HOST1} -name ca.key -type f -delete
|
||||
```
|
||||
|
||||
<!--
|
||||
1. Copy certificates and kubeadm configs
|
||||
The certificates have been generated and now they must be moved to their
|
||||
respective hosts.
|
||||
-->
|
||||
5. 复制证书和 kubeadm 配置
|
||||
|
||||
证书已生成，现在必须将它们移动到对应的主机。
|
||||
|
||||
```shell
|
||||
USER=ubuntu
|
||||
HOST=${HOST1}
|
||||
scp -r /tmp/${HOST}/* ${USER}@${HOST}:
|
||||
ssh ${USER}@${HOST}
|
||||
USER@HOST $ sudo -Es
|
||||
root@HOST $ chown -R root:root pki
|
||||
root@HOST $ mv pki /etc/kubernetes/
|
||||
```
|
||||
|
||||
<!--
|
||||
1. Ensure all expected files exist
|
||||
|
||||
The complete list of required files on `$HOST0` is:
|
||||
-->
|
||||
6. 确保已经所有预期的文件都存在
|
||||
|
||||
`$HOST0` 所需文件的完整列表如下：
|
||||
|
||||
```none
|
||||
/tmp/${HOST0}
|
||||
└── kubeadmcfg.yaml
|
||||
---
|
||||
/etc/kubernetes/pki
|
||||
├── apiserver-etcd-client.crt
|
||||
├── apiserver-etcd-client.key
|
||||
└── etcd
|
||||
├── ca.crt
|
||||
├── ca.key
|
||||
├── healthcheck-client.crt
|
||||
├── healthcheck-client.key
|
||||
├── peer.crt
|
||||
├── peer.key
|
||||
├── server.crt
|
||||
└── server.key
|
||||
```
|
||||
|
||||
<!--
|
||||
On `$HOST1`:
|
||||
-->
|
||||
在 `$HOST1` 上：
|
||||
|
||||
```console
|
||||
$HOME
|
||||
└── kubeadmcfg.yaml
|
||||
---
|
||||
/etc/kubernetes/pki
|
||||
├── apiserver-etcd-client.crt
|
||||
├── apiserver-etcd-client.key
|
||||
└── etcd
|
||||
├── ca.crt
|
||||
├── healthcheck-client.crt
|
||||
├── healthcheck-client.key
|
||||
├── peer.crt
|
||||
├── peer.key
|
||||
├── server.crt
|
||||
└── server.key
|
||||
```
|
||||
|
||||
<!--
|
||||
On `$HOST2`
|
||||
-->
|
||||
在 `$HOST2` 上：
|
||||
|
||||
```console
|
||||
$HOME
|
||||
└── kubeadmcfg.yaml
|
||||
---
|
||||
/etc/kubernetes/pki
|
||||
├── apiserver-etcd-client.crt
|
||||
├── apiserver-etcd-client.key
|
||||
└── etcd
|
||||
├── ca.crt
|
||||
├── healthcheck-client.crt
|
||||
├── healthcheck-client.key
|
||||
├── peer.crt
|
||||
├── peer.key
|
||||
├── server.crt
|
||||
└── server.key
|
||||
```
|
||||
|
||||
<!--
|
||||
1. Create the static pod manifests
|
||||
|
||||
Now that the certificates and configs are in place it's time to create the
|
||||
manifests. On each host run the `kubeadm` command to generate a static manifest
|
||||
for etcd.
|
||||
-->
|
||||
7. 创建静态 Pod 清单
|
||||
|
||||
既然证书和配置已经就绪，是时候去创建清单了。
|
||||
在每台主机上运行 `kubeadm` 命令来生成 etcd 使用的静态清单。
|
||||
|
||||
```shell
|
||||
root@HOST0 $ kubeadm init phase etcd local --config=/tmp/${HOST0}/kubeadmcfg.yaml
|
||||
root@HOST1 $ kubeadm init phase etcd local --config=$HOME/kubeadmcfg.yaml
|
||||
root@HOST2 $ kubeadm init phase etcd local --config=$HOME/kubeadmcfg.yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
1. Optional: Check the cluster health
|
||||
-->
|
||||
8. 可选：检查集群运行状况
|
||||
|
||||
```shell
|
||||
docker run --rm -it \
|
||||
--net host \
|
||||
-v /etc/kubernetes:/etc/kubernetes k8s.gcr.io/etcd:${ETCD_TAG} etcdctl \
|
||||
--cert /etc/kubernetes/pki/etcd/peer.crt \
|
||||
--key /etc/kubernetes/pki/etcd/peer.key \
|
||||
--cacert /etc/kubernetes/pki/etcd/ca.crt \
|
||||
--endpoints https://${HOST0}:2379 endpoint health --cluster
|
||||
...
|
||||
https://[HOST0 IP]:2379 is healthy: successfully committed proposal: took = 16.283339ms
|
||||
https://[HOST1 IP]:2379 is healthy: successfully committed proposal: took = 19.44402ms
|
||||
https://[HOST2 IP]:2379 is healthy: successfully committed proposal: took = 35.926451ms
|
||||
```
|
||||
<!--
|
||||
Set ${ETCD_TAG} to the version tag of your etcd image. For example 3.4.3-0. To see the etcd image and tag that kubeadm uses execute kubeadm config images list --kubernetes-version ${K8S_VERSION}, where ${K8S_VERSION} is for example v1.17.0
|
||||
Set ${HOST0}to the IP address of the host you are testing.
|
||||
-->
|
||||
- 将 `${ETCD_TAG}` 设置为你的 etcd 镜像的版本标签，例如 `3.4.3-0`。
|
||||
要查看 kubeadm 使用的 etcd 镜像和标签，请执行
|
||||
`kubeadm config images list --kubernetes-version ${K8S_VERSION}`，
|
||||
例如，其中的 `${K8S_VERSION}` 可以是 `v1.17.0`。
|
||||
- 将 `${HOST0}` 设置为要测试的主机的 IP 地址。
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
<!--
|
||||
Once your have a working 3 member etcd cluster, you can continue setting up a
|
||||
highly available control plane using the [external etcd method with
|
||||
kubeadm](/docs/setup/independent/high-availability/).
|
||||
-->
|
||||
一旦拥有了一个正常工作的 3 成员的 etcd 集群，你就可以基于
|
||||
[使用 kubeadm 外部 etcd 的方法](/zh/docs/setup/production-environment/tools/kubeadm/high-availability/)，
|
||||
继续部署一个高可用的控制平面。
|
||||
+846
@@ -0,0 +1,846 @@
|
||||
---
|
||||
title: 对 kubeadm 进行故障排查
|
||||
content_type: concept
|
||||
weight: 20
|
||||
---
|
||||
|
||||
<!--
|
||||
title: Troubleshooting kubeadm
|
||||
content_type: concept
|
||||
weight: 20
|
||||
-->
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
As with any program, you might run into an error installing or running kubeadm.
|
||||
This page lists some common failure scenarios and have provided steps that can help you understand and fix the problem.
|
||||
|
||||
If your problem is not listed below, please follow the following steps:
|
||||
|
||||
- If you think your problem is a bug with kubeadm:
|
||||
- Go to [github.com/kubernetes/kubeadm](https://github.com/kubernetes/kubeadm/issues) and search for existing issues.
|
||||
- If no issue exists, please [open one](https://github.com/kubernetes/kubeadm/issues/new) and follow the issue template.
|
||||
|
||||
- If you are unsure about how kubeadm works, you can ask on [Slack](https://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 的错误：
|
||||
- 转到 [github.com/kubernetes/kubeadm](https://github.com/kubernetes/kubeadm/issues) 并搜索存在的问题。
|
||||
- 如果没有问题，请 [打开](https://github.com/kubernetes/kubeadm/issues/new) 并遵循问题模板。
|
||||
|
||||
- 如果你对 kubeadm 的工作方式有疑问，可以在 [Slack](https://slack.k8s.io/) 上的 `#kubeadm` 频道提问，
|
||||
或者在 [StackOverflow](https://stackoverflow.com/questions/tagged/kubernetes) 上提问。
|
||||
请加入相关标签，例如 `#kubernetes` 和 `#kubeadm`，这样其他人可以帮助你。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
## Not possible to join a v1.18 Node to a v1.17 cluster due to missing RBAC
|
||||
-->
|
||||
## 由于缺少 RBAC，无法将 v1.18 Node 加入 v1.17 集群
|
||||
|
||||
<!--
|
||||
In v1.18 kubeadm added prevention for joining a Node in the cluster if a Node with the same name already exists.
|
||||
This required adding RBAC for the bootstrap-token user to be able to GET a Node object.
|
||||
|
||||
However this causes an issue where `kubeadm join` from v1.18 cannot join a cluster created by kubeadm v1.17.
|
||||
-->
|
||||
自从 v1.18 后，如果集群中已存在同名 Node，kubeadm 将禁止 Node 加入集群。
|
||||
这需要为 bootstrap-token 用户添加 RBAC 才能 GET Node 对象。
|
||||
|
||||
但这会导致一个问题，v1.18 的 `kubeadm join` 无法加入由 kubeadm v1.17 创建的集群。
|
||||
|
||||
<!--
|
||||
To workaround the issue you have two options:
|
||||
|
||||
Execute `kubeadm init phase bootstrap-token` on a control-plane node using kubeadm v1.18.
|
||||
Note that this enables the rest of the bootstrap-token permissions as well.
|
||||
|
||||
or
|
||||
|
||||
Apply the following RBAC manually using `kubectl apply -f ...`:
|
||||
-->
|
||||
要解决此问题，你有两种选择：
|
||||
|
||||
使用 kubeadm v1.18 在控制平面节点上执行 `kubeadm init phase bootstrap-token`。
|
||||
请注意，这也会启用 bootstrap-token 的其余权限。
|
||||
|
||||
或者，也可以使用 `kubectl apply -f ...` 手动应用以下 RBAC：
|
||||
|
||||
|
||||
```yaml
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRole
|
||||
metadata:
|
||||
name: kubeadm:get-nodes
|
||||
rules:
|
||||
- apiGroups:
|
||||
- ""
|
||||
resources:
|
||||
- nodes
|
||||
verbs:
|
||||
- get
|
||||
---
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRoleBinding
|
||||
metadata:
|
||||
name: kubeadm:get-nodes
|
||||
roleRef:
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
kind: ClusterRole
|
||||
name: kubeadm:get-nodes
|
||||
subjects:
|
||||
- apiGroup: rbac.authorization.k8s.io
|
||||
kind: Group
|
||||
name: system:bootstrappers:kubeadm:default-node-token
|
||||
```
|
||||
|
||||
<!--
|
||||
## `ebtables` or some similar executable not found during installation
|
||||
|
||||
If you see the following warnings while running `kubeadm init`
|
||||
|
||||
```sh
|
||||
[preflight] WARNING: ebtables not found in system path
|
||||
[preflight] WARNING: ethtool not found in system path
|
||||
```
|
||||
|
||||
Then you may be missing `ebtables`, `ethtool` or a similar executable on your node. You can install them with the following commands:
|
||||
|
||||
- For Ubuntu/Debian users, run `apt install ebtables ethtool`.
|
||||
- For CentOS/Fedora users, run `yum install ebtables ethtool`.
|
||||
-->
|
||||
## 在安装过程中没有找到 `ebtables` 或者其他类似的可执行文件
|
||||
|
||||
如果在运行 `kubeadm init` 命令时，遇到以下的警告
|
||||
|
||||
```sh
|
||||
[preflight] WARNING: ebtables not found in system path
|
||||
[preflight] WARNING: ethtool not found in system path
|
||||
```
|
||||
|
||||
那么或许在你的节点上缺失 `ebtables`、`ethtool` 或者类似的可执行文件。
|
||||
你可以使用以下命令安装它们：
|
||||
|
||||
- 对于 Ubuntu/Debian 用户，运行 `apt install ebtables ethtool` 命令。
|
||||
- 对于 CentOS/Fedora 用户，运行 `yum install ebtables ethtool` 命令。
|
||||
|
||||
<!--
|
||||
## kubeadm blocks waiting for control plane during installation
|
||||
|
||||
If you notice that `kubeadm init` hangs after printing out the following line:
|
||||
|
||||
```sh
|
||||
[apiclient] Created API client, waiting for the control plane to become ready
|
||||
```
|
||||
-->
|
||||
## 在安装过程中，kubeadm 一直等待控制平面就绪
|
||||
|
||||
如果你注意到 `kubeadm init` 在打印以下行后挂起：
|
||||
|
||||
```sh
|
||||
[apiclient] Created API client, waiting for the control plane to become ready
|
||||
```
|
||||
|
||||
<!--
|
||||
This may be caused by a number of problems. The most common are:
|
||||
|
||||
- network connection problems. Check that your machine has full network connectivity before continuing.
|
||||
- the cgroup driver of the container runtime differs from that of the kubelet. To understand how to
|
||||
configure it properly see [Configuring a cgroup driver](/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/).
|
||||
- control plane containers are crashlooping or hanging. You can check this by running `docker ps`
|
||||
and investigating each container by running `docker logs`. For other container runtime see
|
||||
[Debugging Kubernetes nodes with crictl](/docs/tasks/debug/debug-cluster/crictl/).
|
||||
-->
|
||||
这可能是由许多问题引起的。最常见的是：
|
||||
|
||||
- 网络连接问题。在继续之前，请检查你的计算机是否具有全部联通的网络连接。
|
||||
- 容器运行时的 cgroup 驱动不同于 kubelet 使用的 cgroup 驱动。要了解如何正确配置 cgroup 驱动，
|
||||
请参阅[配置 cgroup 驱动](/zh/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/)。
|
||||
- 控制平面上的 Docker 容器持续进入崩溃状态或（因其他原因）挂起。你可以运行 `docker ps` 命令来检查以及 `docker logs` 命令来检视每个容器的运行日志。
|
||||
对于其他容器运行时，请参阅[使用 crictl 对 Kubernetes 节点进行调试](/zh/docs/tasks/debug/debug-cluster/crictl/)。
|
||||
|
||||
<!--
|
||||
## kubeadm blocks when removing managed containers
|
||||
|
||||
The following could happen if the container runtime halts and does not remove
|
||||
any Kubernetes-managed containers:
|
||||
|
||||
```shell
|
||||
sudo kubeadm reset
|
||||
```
|
||||
|
||||
```console
|
||||
[preflight] Running pre-flight checks
|
||||
[reset] Stopping the kubelet service
|
||||
[reset] Unmounting mounted directories in "/var/lib/kubelet"
|
||||
[reset] Removing kubernetes-managed containers
|
||||
(block)
|
||||
```
|
||||
|
||||
A possible solution is to restart the container runtime and then re-run `kubeadm reset`.
|
||||
You can also use `crictl` to debug the state of the container runtime. See
|
||||
[Debugging Kubernetes nodes with crictl](/docs/tasks/debug/debug-cluster/crictl/).
|
||||
-->
|
||||
## 当删除托管容器时 kubeadm 阻塞
|
||||
|
||||
如果容器运行时停止并且未删除 Kubernetes 所管理的容器，可能发生以下情况：
|
||||
|
||||
```shell
|
||||
sudo kubeadm reset
|
||||
```
|
||||
|
||||
```none
|
||||
[preflight] Running pre-flight checks
|
||||
[reset] Stopping the kubelet service
|
||||
[reset] Unmounting mounted directories in "/var/lib/kubelet"
|
||||
[reset] Removing kubernetes-managed containers
|
||||
(block)
|
||||
```
|
||||
|
||||
一个可行的解决方案是重新启动 Docker 服务，然后重新运行 `kubeadm reset`：
|
||||
你也可以使用 `crictl` 来调试容器运行时的状态。
|
||||
参见[使用 CRICTL 调试 Kubernetes 节点](/zh/docs/tasks/debug/debug-cluster/crictl/)。
|
||||
|
||||
<!--
|
||||
## Pods in `RunContainerError`, `CrashLoopBackOff` or `Error` state
|
||||
|
||||
Right after `kubeadm init` there should not be any pods in these states.
|
||||
|
||||
- If there are pods in one of these states _right after_ `kubeadm init`, please open an
|
||||
issue in the kubeadm repo. `coredns` (or `kube-dns`) should be in the `Pending` state
|
||||
until you have deployed the network add-on.
|
||||
- If you see Pods in the `RunContainerError`, `CrashLoopBackOff` or `Error` state
|
||||
after deploying the network add-on and nothing happens to `coredns` (or `kube-dns`),
|
||||
it's very likely that the Pod Network add-on that you installed is somehow broken.
|
||||
You might have to grant it more RBAC privileges or use a newer version. Please file
|
||||
an issue in the Pod Network providers' issue tracker and get the issue triaged there.
|
||||
-->
|
||||
## Pods 处于 `RunContainerError`、`CrashLoopBackOff` 或者 `Error` 状态
|
||||
|
||||
在 `kubeadm init` 命令运行后，系统中不应该有 pods 处于这类状态。
|
||||
|
||||
- 在 `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` 时，
|
||||
删除 `MountFlags=slave` 选项。
|
||||
你可以在 `/usr/lib/systemd/system/docker.service` 中看到 MountFlags。
|
||||
MountFlags 可能会干扰 Kubernetes 挂载的卷，并使 Pods 处于 `CrashLoopBackOff` 状态。
|
||||
当 Kubernetes 不能找到 `var/run/secrets/kubernetes.io/serviceaccount` 文件时会发生错误。
|
||||
|
||||
<!--
|
||||
## `coredns` is stuck in the `Pending` state
|
||||
|
||||
This is **expected** and part of the design. kubeadm is network provider-agnostic, so the admin
|
||||
should [install the pod network add-on](/docs/concepts/cluster-administration/addons/)
|
||||
of choice. You have to install a Pod Network
|
||||
before CoreDNS may be deployed fully. Hence the `Pending` state before the network is set up.
|
||||
-->
|
||||
## `coredns` 停滞在 `Pending` 状态
|
||||
|
||||
这一行为是 **预期之中** 的，因为系统就是这么设计的。
|
||||
kubeadm 的网络供应商是中立的，因此管理员应该选择
|
||||
[安装 pod 的网络插件](/zh/docs/concepts/cluster-administration/addons/)。
|
||||
你必须完成 Pod 的网络配置，然后才能完全部署 CoreDNS。
|
||||
在网络被配置好之前，DNS 组件会一直处于 `Pending` 状态。
|
||||
|
||||
<!--
|
||||
## `HostPort` services do not work
|
||||
|
||||
The `HostPort` and `HostIP` functionality is available depending on your Pod Network
|
||||
provider. Please contact the author of the Pod Network add-on to find out whether
|
||||
`HostPort` and `HostIP` functionality are available.
|
||||
|
||||
Calico, Canal, and Flannel CNI providers are verified to support HostPort.
|
||||
|
||||
For more information, see the [CNI portmap documentation](https://github.com/containernetworking/plugins/blob/master/plugins/meta/portmap/README.md).
|
||||
|
||||
If your network provider does not support the portmap CNI plugin, you may need to use the [NodePort feature of
|
||||
services](/docs/concepts/services-networking/service/#type-nodeport) or use `HostNetwork=true`.
|
||||
-->
|
||||
## `HostPort` 服务无法工作
|
||||
|
||||
此 `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 服务的功能](/zh/docs/concepts/services-networking/service/#type-nodeport)
|
||||
或者使用 `HostNetwork=true`。
|
||||
|
||||
<!--
|
||||
## Pods are not accessible via their Service IP
|
||||
|
||||
- Many network add-ons do not yet enable [hairpin mode](/docs/tasks/debug/debug-application/debug-service/#a-pod-fails-to-reach-itself-via-the-service-ip)
|
||||
which allows pods to access themselves via their Service IP. This is an issue related to
|
||||
[CNI](https://github.com/containernetworking/cni/issues/476). Please contact the network
|
||||
add-on provider to get the latest status of their support for hairpin mode.
|
||||
|
||||
- If you are using VirtualBox (directly or via Vagrant), you will need to
|
||||
ensure that `hostname -i` returns a routable IP address. By default the first
|
||||
interface is connected to a non-routable host-only network. A work around
|
||||
is to modify `/etc/hosts`, see this [Vagrantfile](https://github.com/errordeveloper/k8s-playground/blob/22dd39dfc06111235620e6c4404a96ae146f26fd/Vagrantfile#L11)
|
||||
for an example.
|
||||
-->
|
||||
## 无法通过其服务 IP 访问 Pod
|
||||
|
||||
- 许多网络附加组件尚未启用 [hairpin 模式](/zh/docs/tasks/debug/debug-application/debug-service/#a-pod-fails-to-reach-itself-via-the-service-ip)
|
||||
该模式允许 Pod 通过其服务 IP 进行访问。这是与 [CNI](https://github.com/containernetworking/cni/issues/476) 有关的问题。
|
||||
请与网络附加组件提供商联系，以获取他们所提供的 hairpin 模式的最新状态。
|
||||
|
||||
- 如果你正在使用 VirtualBox (直接使用或者通过 Vagrant 使用)，你需要
|
||||
确保 `hostname -i` 返回一个可路由的 IP 地址。默认情况下，第一个接口连接不能路由的仅主机网络。
|
||||
解决方法是修改 `/etc/hosts`，请参考示例 [Vagrantfile](https://github.com/errordeveloper/k8s-playground/blob/22dd39dfc06111235620e6c4404a96ae146f26fd/Vagrantfile#L11)。
|
||||
|
||||
<!--
|
||||
## TLS certificate errors
|
||||
|
||||
The following error indicates a possible certificate mismatch.
|
||||
|
||||
```none
|
||||
# kubectl get pods
|
||||
Unable to connect to the server: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "kubernetes")
|
||||
```
|
||||
|
||||
- Verify that the `$HOME/.kube/config` file contains a valid certificate, and
|
||||
regenerate a certificate if necessary. The certificates in a kubeconfig file
|
||||
are base64 encoded. The `base64 --decode` command can be used to decode the certificate
|
||||
and `openssl x509 -text -noout` can be used for viewing the certificate information.
|
||||
- Unset the `KUBECONFIG` environment variable using:
|
||||
|
||||
```sh
|
||||
unset KUBECONFIG
|
||||
```
|
||||
|
||||
Or set it to the default `KUBECONFIG` location:
|
||||
|
||||
```sh
|
||||
export KUBECONFIG=/etc/kubernetes/admin.conf
|
||||
```
|
||||
|
||||
- Another workaround is to overwrite the existing `kubeconfig` for the "admin" user:
|
||||
|
||||
```sh
|
||||
mv $HOME/.kube $HOME/.kube.bak
|
||||
mkdir $HOME/.kube
|
||||
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
|
||||
sudo chown $(id -u):$(id -g) $HOME/.kube/config
|
||||
```
|
||||
-->
|
||||
## TLS 证书错误
|
||||
|
||||
以下错误指出证书可能不匹配。
|
||||
|
||||
```none
|
||||
# kubectl get pods
|
||||
Unable to connect to the server: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "kubernetes")
|
||||
```
|
||||
|
||||
- 验证 `$HOME/.kube/config` 文件是否包含有效证书，并
|
||||
在必要时重新生成证书。在 kubeconfig 文件中的证书是 base64 编码的。
|
||||
该 `base64 --decode` 命令可以用来解码证书，`openssl x509 -text -noout` 命令
|
||||
可以用于查看证书信息。
|
||||
- 使用如下方法取消设置 `KUBECONFIG` 环境变量的值：
|
||||
|
||||
```shell
|
||||
unset KUBECONFIG
|
||||
```
|
||||
|
||||
或者将其设置为默认的 `KUBECONFIG` 位置：
|
||||
|
||||
```shell
|
||||
export KUBECONFIG=/etc/kubernetes/admin.conf
|
||||
```
|
||||
|
||||
- 另一个方法是覆盖 `kubeconfig` 的现有用户 "管理员"：
|
||||
|
||||
```shell
|
||||
mv $HOME/.kube $HOME/.kube.bak
|
||||
mkdir $HOME/.kube
|
||||
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
|
||||
sudo chown $(id -u):$(id -g) $HOME/.kube/config
|
||||
```
|
||||
|
||||
<!--
|
||||
## Kubelet client certificate rotation fails {#kubelet-client-cert}
|
||||
|
||||
By default, kubeadm configures a kubelet with automatic rotation of client certificates by using the `/var/lib/kubelet/pki/kubelet-client-current.pem` symlink specified in `/etc/kubernetes/kubelet.conf`.
|
||||
If this rotation process fails you might see errors such as `x509: certificate has expired or is not yet valid`
|
||||
in kube-apiserver logs. To fix the issue you must follow these steps:
|
||||
-->
|
||||
## Kubelet 客户端证书轮换失败 {#kubelet-client-cert}
|
||||
|
||||
默认情况下，kubeadm 使用 `/etc/kubernetes/kubelet.conf` 中指定的 `/var/lib/kubelet/pki/kubelet-client-current.pem` 符号链接
|
||||
来配置 kubelet 自动轮换客户端证书。如果此轮换过程失败，你可能会在 kube-apiserver 日志中看到
|
||||
诸如 `x509: certificate has expired or is not yet valid` 之类的错误。要解决此问题，你必须执行以下步骤：
|
||||
<!--
|
||||
1. Backup and delete `/etc/kubernetes/kubelet.conf` and `/var/lib/kubelet/pki/kubelet-client*` from the failed node.
|
||||
1. From a working control plane node in the cluster that has `/etc/kubernetes/pki/ca.key` execute
|
||||
`kubeadm kubeconfig user --org system:nodes --client-name system:node:$NODE > kubelet.conf`.
|
||||
`$NODE` must be set to the name of the existing failed node in the cluster.
|
||||
Modify the resulted `kubelet.conf` manually to adjust the cluster name and server endpoint,
|
||||
or pass `kubeconfig user --config` (it accepts `InitConfiguration`). If your cluster does not have
|
||||
the `ca.key` you must sign the embedded certificates in the `kubelet.conf` externally.
|
||||
-->
|
||||
1. 从故障节点备份和删除 `/etc/kubernetes/kubelet.conf` 和 `/var/lib/kubelet/pki/kubelet-client*`。
|
||||
2. 在集群中具有 `/etc/kubernetes/pki/ca.key` 的、正常工作的控制平面节点上
|
||||
执行 `kubeadm kubeconfig user --org system:nodes --client-name system:node:$NODE > kubelet.conf`。
|
||||
`$NODE` 必须设置为集群中现有故障节点的名称。
|
||||
手动修改生成的 `kubelet.conf` 以调整集群名称和服务器端点，
|
||||
或传递 `kubeconfig user --config`（此命令接受 `InitConfiguration`）。
|
||||
如果你的集群没有 `ca.key`，你必须在外部对 `kubelet.conf` 中的嵌入式证书进行签名。
|
||||
<!--
|
||||
1. Copy this resulted `kubelet.conf` to `/etc/kubernetes/kubelet.conf` on the failed node.
|
||||
1. Restart the kubelet (`systemctl restart kubelet`) on the failed node and wait for
|
||||
`/var/lib/kubelet/pki/kubelet-client-current.pem` to be recreated.
|
||||
-->
|
||||
3. 将得到的 `kubelet.conf` 文件复制到故障节点上，作为 `/etc/kubernetes/kubelet.conf`。
|
||||
4. 在故障节点上重启 kubelet（`systemctl restart kubelet`），等待 `/var/lib/kubelet/pki/kubelet-client-current.pem` 重新创建。
|
||||
<!--
|
||||
1. Manually edit the `kubelet.conf` to point to the rotated kubelet client certificates, by replacing
|
||||
`client-certificate-data` and `client-key-data` with:
|
||||
-->
|
||||
5. 手动编辑 `kubelet.conf` 指向轮换的 kubelet 客户端证书，方法是将 `client-certificate-data` 和 `client-key-data` 替换为：
|
||||
|
||||
```yaml
|
||||
client-certificate: /var/lib/kubelet/pki/kubelet-client-current.pem
|
||||
client-key: /var/lib/kubelet/pki/kubelet-client-current.pem
|
||||
```
|
||||
|
||||
<!--
|
||||
1. Restart the kubelet.
|
||||
1. Make sure the node becomes `Ready`.
|
||||
-->
|
||||
6. 重新启动 kubelet。
|
||||
7. 确保节点状况变为 `Ready`。
|
||||
|
||||
<!--
|
||||
## Default NIC When using flannel as the pod network in Vagrant
|
||||
|
||||
The following error might indicate that something was wrong in the pod network:
|
||||
|
||||
```sh
|
||||
Error from server (NotFound): the server could not find the requested resource
|
||||
```
|
||||
|
||||
- If you're using flannel as the pod network inside Vagrant, then you will have to specify the default interface name for flannel.
|
||||
|
||||
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.
|
||||
-->
|
||||
|
||||
## 在 Vagrant 中使用 flannel 作为 pod 网络时的默认 NIC
|
||||
|
||||
以下错误可能表明 Pod 网络中出现问题：
|
||||
|
||||
```sh
|
||||
Error from server (NotFound): the server could not find the requested resource
|
||||
```
|
||||
|
||||
- 如果你正在 Vagrant 中使用 flannel 作为 pod 网络，则必须指定 flannel 的默认接口名称。
|
||||
|
||||
Vagrant 通常为所有 VM 分配两个接口。第一个为所有主机分配了 IP 地址 `10.0.2.15`，用于获得 NATed 的外部流量。
|
||||
|
||||
这可能会导致 flannel 出现问题，它默认为主机上的第一个接口。这导致所有主机认为它们具有
|
||||
相同的公共 IP 地址。为防止这种情况，传递 `--iface eth1` 标志给 flannel 以便选择第二个接口。
|
||||
|
||||
<!--
|
||||
## Non-public IP used for containers
|
||||
|
||||
In some situations `kubectl logs` and `kubectl run` commands may return with the following errors in an otherwise functional cluster:
|
||||
|
||||
```sh
|
||||
Error from server: Get https://10.19.0.41:10250/containerLogs/default/mysql-ddc65b868-glc5m/mysql: dial tcp 10.19.0.41:10250: getsockopt: no route to host
|
||||
```
|
||||
|
||||
- This may be due to Kubernetes using an IP that can not communicate with other IPs on the seemingly same subnet, possibly by policy of the machine provider.
|
||||
- DigitalOcean assigns a public IP to `eth0` as well as a private one to be used internally as anchor for their floating IP feature, yet `kubelet` will pick the latter as the node's `InternalIP` instead of the public one.
|
||||
|
||||
Use `ip addr show` to check for this scenario instead of `ifconfig` because `ifconfig` will not display the offending alias IP address. Alternatively an API endpoint specific to DigitalOcean allows to query for the anchor IP from the droplet:
|
||||
|
||||
```sh
|
||||
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 DigitalOcean, 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](/docs/reference/config-api/kubeadm-config.v1beta3/#kubeadm-k8s-io-v1beta3-NodeRegistrationOptions)
|
||||
can be used for this.
|
||||
|
||||
Then restart `kubelet`:
|
||||
|
||||
```sh
|
||||
systemctl daemon-reload
|
||||
systemctl restart kubelet
|
||||
```
|
||||
-->
|
||||
## 容器使用的非公共 IP
|
||||
|
||||
在某些情况下 `kubectl logs` 和 `kubectl run` 命令或许会返回以下错误，即便除此之外集群一切功能正常：
|
||||
|
||||
```sh
|
||||
Error from server: Get https://10.19.0.41:10250/containerLogs/default/mysql-ddc65b868-glc5m/mysql: dial tcp 10.19.0.41:10250: getsockopt: no route to host
|
||||
```
|
||||
|
||||
- 这或许是由于 Kubernetes 使用的 IP 无法与看似相同的子网上的其他 IP 进行通信的缘故，
|
||||
可能是由机器提供商的政策所导致的。
|
||||
- DigitalOcean 既分配一个共有 IP 给 `eth0`，也分配一个私有 IP 在内部用作其浮动 IP 功能的锚点，
|
||||
然而 `kubelet` 将选择后者作为节点的 `InternalIP` 而不是公共 IP
|
||||
|
||||
使用 `ip addr show` 命令代替 `ifconfig` 命令去检查这种情况，因为 `ifconfig` 命令
|
||||
不会显示有问题的别名 IP 地址。或者指定的 DigitalOcean 的 API 端口允许从 droplet 中
|
||||
查询 anchor IP：
|
||||
|
||||
```sh
|
||||
curl http://169.254.169.254/metadata/v1/interfaces/public/0/anchor_ipv4/address
|
||||
```
|
||||
|
||||
解决方法是通知 `kubelet` 使用哪个 `--node-ip`。当使用 DigitalOcean 时，可以是公网IP（分配给 `eth0` 的），
|
||||
或者是私网IP（分配给 `eth1` 的）。私网 IP 是可选的。
|
||||
[kubadm `NodeRegistrationOptions` 结构](/zh/docs/reference/config-api/kubeadm-config.v1beta3/#kubeadm-k8s-io-v1beta3-NodeRegistrationOptions)
|
||||
的 `KubeletExtraArgs` 部分被用来处理这种情况。
|
||||
|
||||
然后重启 `kubelet`：
|
||||
|
||||
```shell
|
||||
systemctl daemon-reload
|
||||
systemctl restart kubelet
|
||||
```
|
||||
|
||||
<!--
|
||||
## `coredns` pods have `CrashLoopBackOff` or `Error` state
|
||||
|
||||
If you have nodes that are running SELinux with an older version of Docker you might experience a scenario
|
||||
where the `coredns` pods are not starting. To solve that you can try one of the following options:
|
||||
|
||||
- Upgrade to a [newer version of Docker](/docs/setup/production-environment/container-runtimes/#docker).
|
||||
|
||||
- [Disable 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).
|
||||
- Modify the `coredns` deployment to set `allowPrivilegeEscalation` to `true`:
|
||||
|
||||
```bash
|
||||
kubectl -n kube-system get deployment coredns -o yaml | \
|
||||
sed 's/allowPrivilegeEscalation: false/allowPrivilegeEscalation: true/g' | \
|
||||
kubectl apply -f -
|
||||
```
|
||||
|
||||
Another cause for CoreDNS to have `CrashLoopBackOff` is when a CoreDNS Pod deployed in Kubernetes detects a loop. [A number of workarounds](https://github.com/coredns/coredns/tree/master/plugin/loop#troubleshooting-loops-in-kubernetes-clusters)
|
||||
are available to avoid Kubernetes trying to restart the CoreDNS Pod every time CoreDNS detects the loop and exits.
|
||||
-->
|
||||
## `coredns` pods 有 `CrashLoopBackOff` 或者 `Error` 状态
|
||||
|
||||
如果有些节点运行的是旧版本的 Docker，同时启用了 SELinux，你或许会遇到 `coredns` pods 无法启动的情况。
|
||||
要解决此问题，你可以尝试以下选项之一：
|
||||
|
||||
- 升级到 [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`：
|
||||
|
||||
```shell
|
||||
kubectl -n kube-system get deployment coredns -o yaml | \
|
||||
sed 's/allowPrivilegeEscalation: false/allowPrivilegeEscalation: true/g' | \
|
||||
kubectl apply -f -
|
||||
```
|
||||
|
||||
CoreDNS 处于 `CrashLoopBackOff` 时的另一个原因是当 Kubernetes 中部署的 CoreDNS Pod 检测
|
||||
到环路时。[有许多解决方法](https://github.com/coredns/coredns/tree/master/plugin/loop#troubleshooting-loops-in-kubernetes-clusters)
|
||||
可以避免在每次 CoreDNS 监测到循环并退出时，Kubernetes 尝试重启 CoreDNS Pod 的情况。
|
||||
|
||||
<!--
|
||||
Disabling SELinux or setting `allowPrivilegeEscalation` to `true` can compromise
|
||||
the security of your cluster.
|
||||
-->
|
||||
{{< warning >}}
|
||||
禁用 SELinux 或设置 `allowPrivilegeEscalation` 为 `true` 可能会损害集群的安全性。
|
||||
{{< /warning >}}
|
||||
|
||||
<!--
|
||||
## etcd pods restart continually
|
||||
|
||||
If you encounter the following error:
|
||||
|
||||
```
|
||||
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\""
|
||||
```
|
||||
|
||||
this issue appears if you run CentOS 7 with Docker 1.13.1.84.
|
||||
This version of Docker can prevent the kubelet from executing into the etcd container.
|
||||
|
||||
To work around the issue, choose one of these options:
|
||||
|
||||
- Roll back to an earlier version of Docker, such as 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
|
||||
```
|
||||
|
||||
- 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
|
||||
yum install docker-ce-18.06.1.ce-3.el7.x86_64
|
||||
```
|
||||
-->
|
||||
## etcd pods 持续重启
|
||||
|
||||
如果你遇到以下错误：
|
||||
|
||||
```console
|
||||
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 会阻止 kubelet 在 etcd 容器中执行。
|
||||
|
||||
为解决此问题，请选择以下选项之一：
|
||||
|
||||
- 回滚到早期版本的 Docker，例如 1.13.1-75
|
||||
|
||||
```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:
|
||||
|
||||
```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
|
||||
|
||||
`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
|
||||
`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
|
||||
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"`
|
||||
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/reference/config-api/kubeadm-config.v1beta3/).
|
||||
-->
|
||||
## 无法将以逗号分隔的值列表传递给 `--component-extra-args` 标志内的参数
|
||||
|
||||
`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` 被误认为是缺少取值的键名。
|
||||
|
||||
一种解决方法是尝试分离 `key=value` 对，像这样：
|
||||
`--apiserver-extra-args "enable-admission-plugins=LimitRanger,enable-admission-plugins=NamespaceExists"`
|
||||
但这将导致键 `enable-admission-plugins` 仅有值 `NamespaceExists`。
|
||||
|
||||
已知的解决方法是使用 kubeadm
|
||||
[配置文件](/zh/docs/reference/config-api/kubeadm-config.v1beta3/)。
|
||||
|
||||
<!--
|
||||
## kube-proxy scheduled before node is initialized by cloud-controller-manager
|
||||
|
||||
In cloud provider scenarios, kube-proxy can end up being scheduled on new worker nodes before
|
||||
the cloud-controller-manager has initialized the node addresses. This causes kube-proxy to fail
|
||||
to pick up the node's IP address properly and has knock-on effects to the proxy function managing
|
||||
load balancers.
|
||||
|
||||
The following error can be seen in kube-proxy Pods:
|
||||
```
|
||||
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
|
||||
```
|
||||
|
||||
A known solution is to patch the kube-proxy DaemonSet to allow scheduling it on control-plane
|
||||
nodes regardless of their conditions, keeping it off of other nodes until their initial guarding
|
||||
conditions abate:
|
||||
```
|
||||
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" }, { "effect": "NoSchedule", "key": "node-role.kubernetes.io/control-plane" } ] } } } }'
|
||||
```
|
||||
|
||||
The tracking issue for this problem is [here](https://github.com/kubernetes/kubeadm/issues/1027).
|
||||
-->
|
||||
## 在节点被云控制管理器初始化之前，kube-proxy 就被调度了
|
||||
|
||||
在云环境场景中，可能出现在云控制管理器完成节点地址初始化之前，kube-proxy 就被调度到新节点了。
|
||||
这会导致 kube-proxy 无法正确获取节点的 IP 地址，并对管理负载平衡器的代理功能产生连锁反应。
|
||||
|
||||
在 kube-proxy Pod 中可以看到以下错误：
|
||||
|
||||
```console
|
||||
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，以允许在控制平面节点上调度它，
|
||||
而不管它们的条件如何，将其与其他节点保持隔离，直到它们的初始保护条件消除：
|
||||
|
||||
```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" }, { "effect": "NoSchedule", "key": "node-role.kubernetes.io/control-plane" } ] } } } }'
|
||||
```
|
||||
|
||||
此问题的跟踪[在这里](https://github.com/kubernetes/kubeadm/issues/1027)。
|
||||
|
||||
<!--
|
||||
## `/usr` is mounted read-only on nodes {#usr-mounted-read-only}
|
||||
|
||||
On Linux distributions such as Fedora CoreOS or Flatcar Container Linux, the directory `/usr` is mounted as a read-only filesystem.
|
||||
For [flex-volume support](https://github.com/kubernetes/community/blob/ab55d85/contributors/devel/sig-storage/flexvolume.md),
|
||||
Kubernetes components like the kubelet and kube-controller-manager use the default path of
|
||||
`/usr/libexec/kubernetes/kubelet-plugins/volume/exec/`, yet the flex-volume directory _must be writeable_
|
||||
for the feature to work.
|
||||
(**Note**: FlexVolume was deprecated in the Kubernetes v1.23 release)
|
||||
-->
|
||||
## 节点上的 `/usr` 被以只读方式挂载 {#usr-mounted-read-only}
|
||||
|
||||
在类似 Fedora CoreOS 或者 Flatcar Container Linux 这类 Linux 发行版本中，
|
||||
目录 `/usr` 是以只读文件系统的形式挂载的。
|
||||
在支持 [FlexVolume](https://github.com/kubernetes/community/blob/ab55d85/contributors/devel/sig-storage/flexvolume.md)时，
|
||||
类似 kubelet 和 kube-controller-manager 这类 Kubernetes 组件使用默认路径
|
||||
`/usr/libexec/kubernetes/kubelet-plugins/volume/exec/`，
|
||||
而 FlexVolume 的目录 _必须是可写入的_，该功能特性才能正常工作。
|
||||
（**注意**：FlexVolume 在 Kubernetes v1.23 版本中已被弃用）
|
||||
|
||||
<!--
|
||||
To workaround this issue you can configure the flex-volume directory using the kubeadm
|
||||
[configuration file](/docs/reference/config-api/kubeadm-config.v1beta3/).
|
||||
|
||||
On the primary control-plane Node (created using `kubeadm init`) pass the following
|
||||
file using `--config`:
|
||||
-->
|
||||
为了解决这个问题，你可以使用 kubeadm 的[配置文件](/zh/docs/reference/config-api/kubeadm-config.v1beta3/) 来配置 FlexVolume 的目录。
|
||||
|
||||
在（使用 `kubeadm init` 创建的）主控制节点上，使用 `--config`
|
||||
参数传入如下文件：
|
||||
|
||||
```yaml
|
||||
apiVersion: kubeadm.k8s.io/v1beta3
|
||||
kind: InitConfiguration
|
||||
nodeRegistration:
|
||||
kubeletExtraArgs:
|
||||
volume-plugin-dir: "/opt/libexec/kubernetes/kubelet-plugins/volume/exec/"
|
||||
---
|
||||
apiVersion: kubeadm.k8s.io/v1beta3
|
||||
kind: ClusterConfiguration
|
||||
controllerManager:
|
||||
extraArgs:
|
||||
flex-volume-plugin-dir: "/opt/libexec/kubernetes/kubelet-plugins/volume/exec/"
|
||||
```
|
||||
|
||||
<!--
|
||||
On joining Nodes:
|
||||
-->
|
||||
在加入到集群中的节点上，使用下面的文件：
|
||||
|
||||
```yaml
|
||||
apiVersion: kubeadm.k8s.io/v1beta3
|
||||
kind: JoinConfiguration
|
||||
nodeRegistration:
|
||||
kubeletExtraArgs:
|
||||
volume-plugin-dir: "/opt/libexec/kubernetes/kubelet-plugins/volume/exec/"
|
||||
```
|
||||
|
||||
<!--
|
||||
Alternatively, you can modify `/etc/fstab` to make the `/usr` mount writeable, but please
|
||||
be advised that this is modifying a design principle of the Linux distribution.
|
||||
-->
|
||||
或者，你要可以更改 `/etc/fstab` 使得 `/usr` 目录能够以可写入的方式挂载，不过
|
||||
请注意这样做本质上是在更改 Linux 发行版的某种设计原则。
|
||||
|
||||
<!--
|
||||
## `kubeadm upgrade plan` prints out `context deadline exceeded` error message
|
||||
|
||||
This error message is shown when upgrading a Kubernetes cluster with `kubeadm` in the case of running an external etcd. This is not a critical bug and happens because older versions of kubeadm perform a version check on the external etcd cluster. You can proceed with `kubeadm upgrade apply ...`.
|
||||
|
||||
This issue is fixed as of version 1.19.
|
||||
-->
|
||||
## `kubeadm upgrade plan` 输出错误信息 `context deadline exceeded`
|
||||
|
||||
在使用 `kubeadm` 来升级某运行外部 etcd 的 Kubernetes 集群时可能显示这一错误信息。
|
||||
这并不是一个非常严重的一个缺陷，之所以出现此错误信息，原因是老的 kubeadm
|
||||
版本会对外部 etcd 集群执行版本检查。你可以继续执行 `kubeadm upgrade apply ...`。
|
||||
|
||||
这一问题已经在 1.19 版本中得到修复。
|
||||
|
||||
<!--
|
||||
## `kubeadm reset` unmounts `/var/lib/kubelet`
|
||||
|
||||
If `/var/lib/kubelet` is being mounted, performing a `kubeadm reset` will effectively unmount it.
|
||||
|
||||
To workaround the issue, re-mount the `/var/lib/kubelet` directory after performing the `kubeadm reset` operation.
|
||||
|
||||
This is a regression introduced in kubeadm 1.15. The issue is fixed in 1.20.
|
||||
-->
|
||||
## `kubeadm reset` 会卸载 `/var/lib/kubelet`
|
||||
|
||||
如果已经挂载了 `/var/lib/kubelet` 目录，执行 `kubeadm reset` 操作的时候
|
||||
会将其卸载。
|
||||
|
||||
要解决这一问题，可以在执行了 `kubeadm reset` 操作之后重新挂载
|
||||
`/var/lib/kubelet` 目录。
|
||||
|
||||
这是一个在 1.15 中引入的故障，已经在 1.20 版本中修复。
|
||||
|
||||
<!--
|
||||
## Cannot use the metrics-server securely in a kubeadm cluster
|
||||
|
||||
In a kubeadm cluster, the [metrics-server](https://github.com/kubernetes-sigs/metrics-server)
|
||||
can be used insecurely by passing the `--kubelet-insecure-tls` to it. This is not recommended for production clusters.
|
||||
-->
|
||||
## 无法在 kubeadm 集群中安全地使用 metrics-server
|
||||
|
||||
在 kubeadm 集群中可以通过为 [metrics-server](https://github.com/kubernetes-sigs/metrics-server)
|
||||
设置 `--kubelet-insecure-tls` 来以不安全的形式使用该服务。
|
||||
建议不要在生产环境集群中这样使用。
|
||||
|
||||
<!--
|
||||
If you want to use TLS between the metrics-server and the kubelet there is a problem,
|
||||
since kubeadm deploys a self-signed serving certificate for the kubelet. This can cause the following errors
|
||||
on the side of the metrics-server:
|
||||
-->
|
||||
如果你需要在 metrics-server 和 kubelet 之间使用 TLS，会有一个问题，
|
||||
kubeadm 为 kubelet 部署的是自签名的服务证书。这可能会导致 metrics-server
|
||||
端报告下面的错误信息：
|
||||
|
||||
```console
|
||||
x509: certificate signed by unknown authority
|
||||
x509: certificate is valid for IP-foo not IP-bar
|
||||
```
|
||||
|
||||
<!--
|
||||
See [Enabling signed kubelet serving certificates](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/#kubelet-serving-certs)
|
||||
to understand how to configure the kubelets in a kubeadm cluster to have properly signed serving certificates.
|
||||
|
||||
Also see [How to run the metrics-server securely](https://github.com/kubernetes-sigs/metrics-server/blob/master/FAQ.md#how-to-run-metrics-server-securely).
|
||||
-->
|
||||
参见[为 kubelet 启用签名的服务证书](/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/#kubelet-serving-certs)
|
||||
以进一步了解如何在 kubeadm 集群中配置 kubelet 使用正确签名了的服务证书。
|
||||
|
||||
另请参阅 [How to run the metrics-server securely](https://github.com/kubernetes-sigs/metrics-server/blob/master/FAQ.md#how-to-run-metrics-server-securely)。
|
||||
@@ -0,0 +1,271 @@
|
||||
---
|
||||
title: 使用 Kubespray 安装 Kubernetes
|
||||
content_type: concept
|
||||
weight: 30
|
||||
---
|
||||
<!--
|
||||
title: Installing Kubernetes with Kubespray
|
||||
content_type: concept
|
||||
weight: 30
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
This quickstart helps to install a Kubernetes cluster hosted on GCE, Azure, OpenStack, AWS, vSphere, Packet (bare metal), Oracle Cloud Infrastructure (Experimental) or Baremetal with [Kubespray](https://github.com/kubernetes-sigs/kubespray).
|
||||
-->
|
||||
此快速入门有助于使用 [Kubespray](https://github.com/kubernetes-sigs/kubespray)
|
||||
安装在 GCE、Azure、OpenStack、AWS、vSphere、Packet（裸机）、Oracle Cloud
|
||||
Infrastructure（实验性）或 Baremetal 上托管的 Kubernetes 集群。
|
||||
|
||||
<!--
|
||||
Kubespray is a composition of [Ansible](https://docs.ansible.com/) playbooks, [inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/ansible.md), provisioning tools, and domain knowledge for generic OS/Kubernetes clusters configuration management tasks. Kubespray provides:
|
||||
-->
|
||||
Kubespray 是一个由 [Ansible](https://docs.ansible.com/) playbooks、
|
||||
[清单（inventory）](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/ansible.md)、
|
||||
制备工具和通用 OS/Kubernetes 集群配置管理任务的领域知识组成的。
|
||||
Kubespray 提供：
|
||||
|
||||
<!--
|
||||
* a highly available cluster
|
||||
* composable attributes
|
||||
* support for most popular Linux distributions
|
||||
* Ubuntu 16.04, 18.04, 20.04
|
||||
* CentOS/RHEL/Oracle Linux 7, 8
|
||||
* Debian Buster, Jessie, Stretch, Wheezy
|
||||
* Fedora 31, 32
|
||||
* Fedora CoreOS
|
||||
* openSUSE Leap 15
|
||||
* Flatcar Container Linux by Kinvolk
|
||||
* continuous integration tests
|
||||
-->
|
||||
* 高可用性集群
|
||||
* 可组合属性
|
||||
* 支持大多数流行的 Linux 发行版
|
||||
* Ubuntu 16.04、18.04、20.04
|
||||
* CentOS / RHEL / Oracle Linux 7、8
|
||||
* Debian Buster、Jessie、Stretch、Wheezy
|
||||
* Fedora 31、32
|
||||
* Fedora CoreOS
|
||||
* openSUSE Leap 15
|
||||
* Kinvolk 的 Flatcar Container Linux
|
||||
* 持续集成测试
|
||||
|
||||
<!--
|
||||
To choose a tool which best fits your use case, read [this comparison](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/comparisons.md) to
|
||||
[kubeadm](/docs/reference/setup-tools/kubeadm/) and [kops](/docs/setup/production-environment/tools/kops/).
|
||||
-->
|
||||
要选择最适合你的用例的工具，请阅读
|
||||
[kubeadm](/zh/docs/reference/setup-tools/kubeadm/) 和
|
||||
[kops](/zh/docs/setup/production-environment/tools/kops/) 之间的
|
||||
[这份比较](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/comparisons.md)。
|
||||
。
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
## Creating a cluster
|
||||
|
||||
### (1/5) Meet the underlay requirements
|
||||
-->
|
||||
## 创建集群
|
||||
|
||||
### （1/5）满足下层设施要求
|
||||
|
||||
<!--
|
||||
Provision servers with the following [requirements](https://github.com/kubernetes-sigs/kubespray#requirements):
|
||||
-->
|
||||
按以下[要求](https://github.com/kubernetes-sigs/kubespray#requirements)来配置服务器：
|
||||
|
||||
<!--
|
||||
* **Ansible v2.9 and python-netaddr are installed on the machine that will run Ansible commands**
|
||||
* **Jinja 2.11 (or newer) is required to run the Ansible Playbooks**
|
||||
* The target servers must have access to the Internet in order to pull docker images. Otherwise, additional configuration is required ([See Offline Environment](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/offline-environment.md))
|
||||
* The target servers are configured to allow **IPv4 forwarding**
|
||||
* **Your ssh key must be copied** to all the servers in your inventory
|
||||
* **Firewalls are not managed by kubespray**. You'll need to implement appropriate rules as needed. You should disable your firewall in order to avoid any issues during deployment
|
||||
* If kubespray is run from a non-root user account, correct privilege escalation method should be configured in the target servers and the `ansible_become` flag or command parameters `--become` or `-b` should be specified
|
||||
-->
|
||||
* 在将运行 Ansible 命令的计算机上安装 Ansible v2.9 和 python-netaddr
|
||||
* **运行 Ansible Playbook 需要 Jinja 2.11（或更高版本）**
|
||||
* 目标服务器必须有权访问 Internet 才能拉取 Docker 镜像。否则，
|
||||
需要其他配置（[请参见离线环境](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/offline-environment.md)）
|
||||
* 目标服务器配置为允许 IPv4 转发
|
||||
* **你的 SSH 密钥必须复制**到部署集群的所有服务器中
|
||||
* **防火墙不是由 kubespray 管理的**。你需要根据需求设置适当的规则策略。为了避免部署过程中出现问题，可以禁用防火墙。
|
||||
* 如果从非 root 用户帐户运行 kubespray，则应在目标服务器中配置正确的特权升级方法
|
||||
并指定 `ansible_become` 标志或命令参数 `--become` 或 `-b`
|
||||
|
||||
<!--
|
||||
Kubespray provides the following utilities to help provision your environment:
|
||||
|
||||
* [Terraform](https://www.terraform.io/) scripts for the following cloud providers:
|
||||
* [AWS](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/aws)
|
||||
* [OpenStack](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/openstack)
|
||||
* [Packet](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/packet)
|
||||
-->
|
||||
Kubespray 提供以下实用程序来帮助你设置环境：
|
||||
|
||||
* 为以下云驱动提供的 [Terraform](https://www.terraform.io/) 脚本：
|
||||
* [AWS](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/aws)
|
||||
* [OpenStack](http://sitebeskuethree/contrigetbernform/contribeskubernform/contribeskupernform/https/sitebesku/master/)
|
||||
* [Packet](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/packet)
|
||||
|
||||
<!--
|
||||
### (2/5) Compose an inventory file
|
||||
|
||||
After you provision your servers, create an [inventory file for Ansible](https://docs.ansible.com/ansible/latest/network/getting_started/first_inventory.html). You can do this manually or via a dynamic inventory script. For more information, see "[Building your own inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#building-your-own-inventory)".
|
||||
|
||||
### (3/5) Plan your cluster deployment
|
||||
|
||||
Kubespray provides the ability to customize many aspects of the deployment:
|
||||
-->
|
||||
### （2/5）编写清单文件
|
||||
|
||||
设置服务器后，请创建一个
|
||||
[Ansible 的清单文件](https://docs.ansible.com/ansible/latest/network/getting_started/first_inventory.html)。
|
||||
你可以手动执行此操作，也可以通过动态清单脚本执行此操作。有关更多信息，请参阅
|
||||
“[建立你自己的清单](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#building-your-own-inventory)”。
|
||||
|
||||
### （3/5）规划集群部署
|
||||
|
||||
Kubespray 能够自定义部署的许多方面：
|
||||
|
||||
<!--
|
||||
* Choice deployment mode: kubeadm or non-kubeadm
|
||||
* CNI (networking) plugins
|
||||
* DNS configuration
|
||||
* Choice of control plane: native/binary or containerized
|
||||
* Component versions
|
||||
* Calico route reflectors
|
||||
* Component runtime options
|
||||
* {{< glossary_tooltip term_id="docker" >}}
|
||||
* {{< glossary_tooltip term_id="containerd" >}}
|
||||
* {{< glossary_tooltip term_id="cri-o" >}}
|
||||
* Certificate generation methods
|
||||
-->
|
||||
* 选择部署模式： kubeadm 或非 kubeadm
|
||||
* CNI（网络）插件
|
||||
* DNS 配置
|
||||
* 控制平面的选择：本机/可执行文件或容器化
|
||||
* 组件版本
|
||||
* Calico 路由反射器
|
||||
* 组件运行时选项
|
||||
* {{< glossary_tooltip term_id="docker" >}}
|
||||
* {{< glossary_tooltip term_id="containerd" >}}
|
||||
* {{< glossary_tooltip term_id="cri-o" >}}
|
||||
* 证书生成方式
|
||||
|
||||
<!--
|
||||
Kubespray customizations can be made to a [variable file](https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html). If you are getting started with Kubespray, consider using the Kubespray defaults to deploy your cluster and explore Kubernetes.
|
||||
-->
|
||||
可以修改[变量文件](https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html)
|
||||
以进行 Kubespray 定制。
|
||||
如果你刚刚开始使用 Kubespray，请考虑使用 Kubespray 默认设置来部署你的集群
|
||||
并探索 Kubernetes 。
|
||||
<!--
|
||||
### (4/5) Deploy a Cluster
|
||||
|
||||
Next, deploy your cluster:
|
||||
|
||||
Cluster deployment using [ansible-playbook](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#starting-custom-deployment).
|
||||
-->
|
||||
### （4/5）部署集群
|
||||
|
||||
接下来，部署你的集群：
|
||||
|
||||
使用 [ansible-playbook](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#starting-custom-deployment)
|
||||
进行集群部署。
|
||||
|
||||
```shell
|
||||
ansible-playbook -i your/inventory/inventory.ini cluster.yml -b -v \
|
||||
--private-key=~/.ssh/private_key
|
||||
```
|
||||
<!--
|
||||
Large deployments (100+ nodes) may require [specific adjustments](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/large-deployments.md) for best results.
|
||||
-->
|
||||
大型部署（超过 100 个节点）可能需要
|
||||
[特定的调整](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/large-deployments.md)，
|
||||
以获得最佳效果。
|
||||
|
||||
<!--
|
||||
### (5/5) Verify the deployment
|
||||
|
||||
Kubespray provides a way to verify inter-pod connectivity and DNS resolve with [Netchecker](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/netcheck.md). Netchecker ensures the netchecker-agents pods can resolve DNS requests and ping each over within the default namespace. Those pods mimic similar behavior as the rest of the workloads and serve as cluster health indicators.
|
||||
-->
|
||||
### （5/5）验证部署
|
||||
|
||||
Kubespray 提供了一种使用
|
||||
[Netchecker](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/netcheck.md)
|
||||
验证 Pod 间连接和 DNS 解析的方法。
|
||||
Netchecker 确保 netchecker-agents Pods 可以解析 DNS 请求，
|
||||
并在默认命名空间内对每个请求执行 ping 操作。
|
||||
这些 Pod 模仿其他工作负载类似的行为，并用作集群运行状况指示器。
|
||||
<!--
|
||||
## Cluster operations
|
||||
|
||||
Kubespray provides additional playbooks to manage your cluster: _scale_ and _upgrade_.
|
||||
-->
|
||||
## 集群操作
|
||||
|
||||
Kubespray 提供了其他 Playbooks 来管理集群： _scale_ 和 _upgrade_。
|
||||
<!--
|
||||
### Scale your cluster
|
||||
|
||||
You can add worker nodes from your cluster by running the scale playbook. For more information, see "[Adding nodes](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#adding-nodes)".
|
||||
You can remove worker nodes from your cluster by running the remove-node playbook. For more information, see "[Remove nodes](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#remove-nodes)".
|
||||
-->
|
||||
### 扩展集群
|
||||
|
||||
你可以通过运行 scale playbook 向集群中添加工作节点。有关更多信息，
|
||||
请参见 “[添加节点](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#adding-nodes)”。
|
||||
你可以通过运行 remove-node playbook 来从集群中删除工作节点。有关更多信息，
|
||||
请参见 “[删除节点](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#remove-nodes)”。
|
||||
<!--
|
||||
### Upgrade your cluster
|
||||
|
||||
You can upgrade your cluster by running the upgrade-cluster playbook. For more information, see "[Upgrades](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/upgrades.md)".
|
||||
-->
|
||||
### 升级集群
|
||||
|
||||
你可以通过运行 upgrade-cluster Playbook 来升级集群。有关更多信息，请参见
|
||||
“[升级](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/upgrades.md)”。
|
||||
<!--
|
||||
## Cleanup
|
||||
|
||||
You can reset your nodes and wipe out all components installed with Kubespray via the [reset playbook](https://github.com/kubernetes-sigs/kubespray/blob/master/reset.yml).
|
||||
|
||||
{{< caution >}}
|
||||
When running the reset playbook, be sure not to accidentally target your production cluster!
|
||||
{{< /caution >}}
|
||||
-->
|
||||
## 清理
|
||||
|
||||
你可以通过 [reset](https://github.com/kubernetes-sigs/kubespray/blob/master/reset.yml) Playbook
|
||||
重置节点并清除所有与 Kubespray 一起安装的组件。
|
||||
|
||||
{{< caution >}}
|
||||
运行 reset playbook 时，请确保不要意外地将生产集群作为目标！
|
||||
{{< /caution >}}
|
||||
|
||||
<!--
|
||||
## Feedback
|
||||
|
||||
* Slack Channel: [#kubespray](https://kubernetes.slack.com/messages/kubespray/) (You can get your invite [here](https://slack.k8s.io/))
|
||||
* [GitHub Issues](https://github.com/kubernetes-sigs/kubespray/issues)
|
||||
-->
|
||||
## 反馈
|
||||
|
||||
* Slack 频道：[#kubespray](https://kubernetes.slack.com/messages/kubespray/)
|
||||
（你可以在[此处](https://slack.k8s.io/)获得邀请）
|
||||
* [GitHub 问题](https://github.com/kubernetes-sigs/kubespray/issues)
|
||||
|
||||
<!--
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
Check out planned work on Kubespray's [roadmap](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/roadmap.md).
|
||||
-->
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
查看有关 Kubespray 的
|
||||
[路线图](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/roadmap.md)
|
||||
的计划工作。
|
||||
@@ -0,0 +1,25 @@
|
||||
---
|
||||
title: Turnkey 云解决方案
|
||||
content_type: concept
|
||||
weight: 30
|
||||
---
|
||||
<!--
|
||||
---
|
||||
title: Turnkey Cloud Solutions
|
||||
content_type: concept
|
||||
weight: 30
|
||||
---
|
||||
-->
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
This page provides a list of Kubernetes certified solution providers. From each
|
||||
provider page, you can learn how to install and setup production
|
||||
ready clusters.
|
||||
-->
|
||||
本页列示 Kubernetes 认证解决方案供应商。
|
||||
在每一个供应商分页，你可以学习如何安装和设置生产就绪的集群。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
{{< cncf-landscape helpers=true category="certified-kubernetes-hosted" >}}
|
||||
Reference in New Issue
Block a user