生产环境
生产级 Kubernetes 集群需要规划和准备。如果你的 Kubernetes 集群将运行关键工作负载，则必须将其配置为具有弹性。本页面介绍如何设置生产就绪的集群，或将现有集群升级为生产用途。如果你已经熟悉生产环境设置并希望直接获取相关链接，请跳至下一步。
生产环境注意事项
通常，生产级 Kubernetes 集群环境比个人学习、开发或测试环境有更多要求。生产环境可能需要许多用户安全访问、持续可用性以及根据不断变化的需求进行调整的资源。
当你决定在何处部署生产级 Kubernetes 环境（本地或云中），以及你希望承担或委托给他人多少管理工作时，请考虑以下问题如何影响你对 Kubernetes 集群的要求：
可用性：单机版 Kubernetes 学习环境存在单点故障。创建一个高可用集群意味着要考虑：
- 将控制平面与工作节点分离。
- 在多个节点上复制控制平面组件。
- 将流量负载均衡到集群的API 服务器。
- 随着工作负载的变化，有足够的工作节点可用，或能快速变得可用。
规模：如果你预计生产级 Kubernetes 环境的需求稳定，你可能只需要配置所需的容量即可。但是，如果你预计需求会随时间增长或因季节或特殊事件而剧烈变化，则需要计划如何扩缩容，以减轻控制平面和工作节点上的请求压力，或缩减规模以减少未使用的资源。
安全和访问管理：在你的 Kubernetes 学习集群上，你拥有完整的管理员权限。但是，共享集群承载着重要工作负载，且用户可能不止一两人，因此需要更精细地控制谁以及什么可以访问集群资源。你可以使用基于角色的访问控制（RBAC）和其他安全机制，确保用户和工作负载能够访问其所需资源，同时保障工作负载和集群本身的安全。你可以通过管理策略和容器资源来限制用户和工作负载可以访问的资源。
在自行构建 Kubernetes 生产环境之前，可以考虑将部分或全部工作交给统包式云解决方案提供商或其他Kubernetes 合作伙伴。选项包括：
- 无服务器：仅在第三方设备上运行工作负载，完全无需管理集群。你将根据 CPU 使用量、内存和磁盘请求等计费。
- 托管控制平面：让提供商管理集群控制平面的规模和可用性，并处理补丁和升级。
- 托管工作节点：配置节点池以满足你的需求，然后提供商确保这些节点可用并在需要时随时准备进行升级。
- 集成：有些提供商将 Kubernetes 与你可能需要的其他服务集成，例如存储、容器镜像仓库、认证方法和开发工具。
无论你是自行构建生产级 Kubernetes 集群，还是与合作伙伴协作，都请回顾以下部分，以评估你与集群的控制平面、工作节点、用户访问和工作负载资源相关的需求。
生产集群设置
在生产级 Kubernetes 集群中，控制平面通过可以以不同方式分布在多台计算机上的服务来管理集群。然而，每个工作节点都代表一个配置为运行 Kubernetes Pod 的独立实体。
生产控制平面
最简单的 Kubernetes 集群将整个控制平面和工作节点服务运行在同一台机器上。你可以通过添加工作节点来扩展该环境，如Kubernetes 组件图所示。如果集群仅需短期可用，或者在发生严重问题时可以丢弃，这种配置可能满足你的需求。
然而，如果你需要更永久、高可用的集群，则应考虑扩展控制平面的方法。按照设计，运行在单台机器上的单机控制平面服务并非高可用。如果保持集群正常运行并在发生问题时确保能够修复非常重要，请考虑以下步骤：
- 选择部署工具：你可以使用 kubeadm、kops 和 kubespray 等工具部署控制平面。参阅使用部署工具安装 Kubernetes，了解使用这些部署方法进行生产级部署的技巧。你的部署可以与不同的容器运行时一起使用。
- 管理证书：控制平面服务之间的安全通信通过证书实现。证书可以在部署过程中自动生成，或者你可以使用自己的证书颁发机构生成。详情请参阅PKI 证书和要求。
- 配置 apiserver 的负载均衡器：配置负载均衡器以将外部 API 请求分发到运行在不同节点上的 apiserver 服务实例。详情请参阅创建外部负载均衡器。
- 分离和备份 etcd 服务：etcd 服务可以与其他控制平面服务运行在同一台机器上，也可以为了额外的安全性和可用性而运行在单独的机器上。由于 etcd 存储集群配置数据，应定期备份 etcd 数据库，以确保在需要时可以修复该数据库。有关配置和使用 etcd 的详细信息，请参阅etcd FAQ。详情请参阅运维 Kubernetes 的 etcd 集群和使用 kubeadm 设置高可用 etcd 集群。
- 创建多个控制平面系统：为了实现高可用性，控制平面不应仅限于一台机器。如果控制平面服务由 init 服务（例如 systemd）运行，则每个服务应至少运行在三台机器上。然而，在 Kubernetes 中将控制平面服务作为 Pod 运行可以确保你请求的副本服务数量始终可用。调度器应是容错的，但不是高可用的。一些部署工具设置了 Raft 一致性算法来执行 Kubernetes 服务的领导者选举。如果主服务失效，另一个服务会选举自己并接管。
- 跨多个区域部署：如果保持集群始终可用至关重要，请考虑创建一个跨多个数据中心（在云环境中称为区域 Zone）运行的集群。区域组称为 Region。通过将集群分布在同一 Region 中的多个 Zone，可以提高即使某个 Zone 不可用时你的集群仍能继续运行的可能性。详情请参阅在多个区域中运行。
- 管理持续特性：如果你计划长期保留集群，需要执行一些任务来维护其健康和安全。例如，如果你使用 kubeadm 安装，可以参考证书管理和升级 kubeadm 集群的说明。有关更多 Kubernetes 管理任务列表，请参阅管理集群。
要了解运行控制平面服务时的可用选项，请参阅 kube-apiserver、kube-controller-manager 和 kube-scheduler 组件页面。有关高可用控制平面示例，请参阅 高可用拓扑选项、使用 kubeadm 创建高可用集群 和 运维 Kubernetes 的 etcd 集群。关于制定 etcd 备份计划的信息，请参阅备份 etcd 集群。
生产工作节点
生产级工作负载需要具有弹性，并且其依赖的任何事物也需要具有弹性（例如 CoreDNS）。无论你是自行管理控制平面还是由云提供商管理，你仍然需要考虑如何管理你的工作节点（也简称为 node）。
- 配置节点：节点可以是物理机或虚拟机。如果你想创建和管理自己的节点，可以安装受支持的操作系统，然后添加并运行相应的节点服务。考虑：
- 根据工作负载需求设置节点，确保有足够的内存、CPU、磁盘速度和存储容量可用。
- 普通计算机系统是否满足需求，或者你是否有需要 GPU 处理器、Windows 节点或 VM 隔离的工作负载。
- 验证节点：有关如何确保节点满足加入 Kubernetes 集群的要求的信息，请参阅有效的节点设置。
- 将节点添加到集群：如果你正在管理自己的集群，可以通过设置自己的机器并将它们手动添加到集群中，或让它们自行向集群的 apiserver 注册来添加节点。有关如何通过这些方式设置 Kubernetes 来添加节点的信息，请参阅节点部分。
- 扩缩节点：制定计划以扩展集群最终所需的容量。参阅大型集群考量，根据你需要运行的 Pod 和容器数量来帮助确定所需的节点数量。如果你自行管理节点，这可能意味着购买和安装自己的物理设备。
- 节点自动扩缩：阅读节点自动扩缩，了解可用于自动管理节点及其所提供容量的工具。
- 设置节点健康检查：对于重要的工作负载，你需要确保节点以及运行在这些节点上的 Pod 是健康的。使用 Node Problem Detector 守护进程，可以确保你的节点是健康的。
生产用户管理
在生产环境中，你可能会从你或一小群人访问集群的模型，转变为可能有几十或数百人访问的模型。在学习环境或平台原型中，你可能只有一个管理员账号来完成所有工作。但在生产环境中，你会希望有更多拥有不同命名空间、不同访问级别权限的账号。
负责一个生产级集群意味着决定如何选择性地允许其他用户访问。特别是，你需要选择用于验证尝试访问集群的人员身份（认证）并决定他们是否有权限执行其请求的操作（授权）的策略。
- 认证：apiserver 可以使用客户端证书、持有者令牌、认证代理或 HTTP 基本认证来认证用户。你可以选择要使用的认证方法。通过插件，apiserver 可以利用你组织现有的认证方法，例如 LDAP 或 Kerberos。有关这些不同的 Kubernetes 用户认证方法的描述，请参阅认证。
- 授权：当你着手授权你的普通用户时，你可能会在 RBAC 和 ABAC 授权之间进行选择。参阅授权概览，了解用于授权用户账号（以及服务账号访问你的集群）的不同模式。
- 基于角色的访问控制 (RBAC)：允许你通过授予经过认证的用户特定权限集来分配对集群的访问权限。权限可以针对特定的命名空间（Role）或整个集群（ClusterRole）进行分配。然后，使用 RoleBindings 和 ClusterRoleBindings，可以将这些权限绑定到特定用户。
- 基于属性的访问控制 (ABAC)：允许你根据集群中的资源属性创建策略，并根据这些属性允许或拒绝访问。策略文件中的每一行都标识了版本属性 (apiVersion 和 kind) 以及一个 spec 属性映射，用于匹配主体（用户或组）、资源属性、非资源属性（/version 或 /apis）以及只读属性。详情请参阅示例。
作为在生产级 Kubernetes 集群上设置认证和授权的人员，以下是一些需要考虑的事项：
- 设置授权模式：Kubernetes API 服务器 (kube-apiserver) 启动时，必须使用 --authorization-config 文件或 --authorization-mode 标志设置支持的授权模式。例如，在 kube-adminserver.yaml 文件（位于 /etc/kubernetes/manifests）中的该标志可以设置为 Node,RBAC。这将允许对经过认证的请求进行 Node 和 RBAC 授权。
- 创建用户证书和角色绑定 (RBAC)：如果你使用 RBAC 授权，用户可以创建 CertificateSigningRequest (CSR)，该请求可以由集群 CA 签名。然后，你可以将 Role 和 ClusterRole 绑定到每个用户。详情请参阅证书签名请求。
- 创建组合属性的策略 (ABAC)：如果你使用 ABAC 授权，可以组合属性来形成策略，以授权选定的用户或组访问特定资源（例如 Pod）、命名空间或 apiGroup。更多信息请参阅示例。
- 考虑准入控制器：通过 API 服务器进入的请求的其他授权形式包括Webhook 令牌认证。Webhook 和其他特殊的授权类型需要通过向 API 服务器添加准入控制器来启用。
设置工作负载资源限制
生产工作负载的需求可能在 Kubernetes 控制平面内部和外部造成压力。为集群工作负载的需求进行设置时，请考虑以下事项：
- 设置命名空间限制：对内存和 CPU 等设置每个命名空间的配额。详情请参阅管理内存、CPU 和 API 资源。
- 准备应对 DNS 需求：如果你预计工作负载将大规模扩容，你的 DNS 服务也必须准备好随之扩容。参阅在集群中对 DNS 服务进行自动扩缩。
- 创建额外的服务账号：用户账号决定了用户在集群上可以做什么，而服务账号则定义了 Pod 在特定命名空间内的访问权限。默认情况下，Pod 继承其命名空间的默认服务账号。有关创建新服务账号的信息，请参阅管理服务账号。例如，你可能希望：
- 添加 Pod 可以用来从特定容器镜像仓库拉取镜像的 Secret。参阅为 Pod 配置服务账号以获取示例。
- 为服务账号分配 RBAC 权限。详情请参阅服务账号权限。