生产环境

生产质量的 Kubernetes 集群需要规划和准备。 如果你的 Kubernetes 集群是用来运行关键负载的，该集群必须被配置为弹性的（Resilient）。

生产环境考量

需要考虑的因数

• 可用性：一个单机的 Kubernetes 学习环境 具有单点失效特点。创建高可用的集群则意味着需要考虑：

1. 将控制面与工作节点分开
2. 在多个节点上提供控制面组件的副本
3. 为针对集群的 API 服务器 的流量提供负载均衡
4. 随着负载的合理需要，提供足够的可用的（或者能够迅速变为可用的）工作节点

• 规模：如果你预期你的生产用 Kubernetes 环境要承受固定量的请求， 你可能可以针对所需要的容量来一次性完成安装。 不过，如果你预期服务请求会随着时间增长，或者因为类似季节或者特殊事件的原因而发生剧烈变化， 你就需要规划如何处理请求上升时对控制面和工作节点的压力，或者如何缩减集群规模以减少未使用资源的消耗。

• 安全性与访问管理：在你自己的学习环境 Kubernetes 集群上，你拥有完全的管理员特权。 但是针对运行着重要工作负载的共享集群，用户账户不止一两个时， 就需要更细粒度的方案来确定谁或者哪些主体可以访问集群资源。 你可以使用基于角色的访问控制（RBAC） 和其他安全机制来确保用户和负载能够访问到所需要的资源， 同时确保工作负载及集群自身仍然是安全的。 你可以通过管理策略和 容器资源 来针对用户和工作负载所可访问的资源设置约束。

在自行构建 Kubernetes 生产环境之前， 请考虑将这一任务的部分或者全部交给云方案承包服务提供商或者其他 Kubernetes 合作伙伴。选项有：

• 无服务：仅是在第三方设备上运行负载，完全不必管理集群本身。 你需要为 CPU 用量、内存和磁盘请求等付费。
• 托管控制面：让供应商决定集群控制面的规模和可用性，并负责打补丁和升级等操作。
• 托管工作节点：配置一个节点池来满足你的需要，由供应商来确保节点始终可用，并在需要的时候完成升级。
• 集成：有一些供应商能够将 Kubernetes 与一些你可能需要的其他服务集成， 这类服务包括存储、容器镜像仓库、身份认证方法以及开发工具等。

无论你是自行构造一个生产用 Kubernetes 集群还是与合作伙伴一起协作， 请审阅下面章节以评估你的需求，因为这关系到你的集群的控制面、工作节点、用户访问以及负载资源。

生产用集群安装

在生产质量的 Kubernetes 集群中，控制面用不同的方式来管理集群和可以分布到多个计算机上的服务。 每个工作节点则代表的是一个可配置来运行 Kubernetes Pod 的实体。

生产用控制面

• 选择部署工具:你可以使用类似 kubeadm、kops 和 kubespray 这类工具来部署控制面。
• 管理证书：控制面服务之间的安全通信是通过证书来完成的。
• 为 API 服务器配置负载均衡：配置负载均衡器来将外部的 API 请求散布给运行在不同节点上的 API 服务实例.
• 分离并备份 etcd 服务：etcd 服务可以运行于其他控制面服务所在的机器上， 也可以运行在不同的机器上以获得更好的安全性和可用性。
• 创建多控制面系统：为了实现高可用性，控制面不应被限制在一台机器上。
• 跨多个可用区：如果保持你的集群一直可用这点非常重要，可以考虑创建一个跨多个数据中心的集群； 在云环境中，这些数据中心被视为可用区。
• 管理演进中的特性：如果你计划长时间保留你的集群，就需要执行一些维护其健康和安全的任务。

生产用工作节点

• 配置节点：节点可以是物理机或者虚拟机。

• 验证节点：参阅验证节点配置以了解如何确保节点满足加入到 Kubernetes 集群的需求。

• 添加节点到集群中：如果你自行管理你的集群，你可以通过安装配置你的机器， 之后或者手动加入集群，或者让它们自动注册到集群的 API 服务器。

• 扩缩节点：制定一个扩充集群容量的规划，你的集群最终会需要这一能力。

• 节点自动扩缩容：查阅集群自动扩缩容， 了解可以自动管理节点的工具及其提供的能力。

• 安装节点健康检查：对于重要的工作负载，你会希望确保节点以及在节点上运行的 Pod 处于健康状态。 通过使用 Node Problem Detector， 你可以确保你的节点是健康的。

生产级用户环境

建立一个生产级别的集群意味着你需要决定如何有选择地允许其他用户访问集群。 具体而言，你需要选择验证尝试访问集群的人的身份标识（身份认证）， 并确定他们是否被许可执行他们所请求的操作（鉴权）

• 认证（Authentication）：API 服务器可以使用客户端证书、持有者令牌、 身份认证代理或者 HTTP 基本认证机制来完成身份认证操作。

• 鉴权（Authorization）：当你准备为一般用户执行权限判定时， 你可能会需要在 RBAC 和 ABAC 鉴权机制之间做出选择。

基于角色的访问控制（RBAC）： 让你通过为通过身份认证的用户授权特定的许可集合来控制集群访问。

基于属性的访问控制（ABAC）： 让你能够基于集群中资源的属性来创建访问控制策略，基于对应的属性来决定允许还是拒绝访问。

作为在你的生产用 Kubernetes 集群中安装身份认证和鉴权机制的负责人，要考虑的事情如下：

• 设置鉴权模式：当 Kubernetes API 服务器（kube-apiserver）启动时， 所支持的鉴权模式必须使用 --authorization-mode 标志配置。

• 创建用户证书和角色绑定（RBAC）：如果你在使用 RBAC 鉴权，用户可以创建由集群 CA 签名的 CertificateSigningRequest（CSR）。

• 创建组合属性的策略（ABAC）：如果你在使用 ABAC 鉴权， 你可以设置属性组合以构造策略对所选用户或用户组执行鉴权， 判定他们是否可访问特定的资源（例如 Pod）、名字空间或者 apiGroup。

• 考虑准入控制器：针对指向 API 服务器的请求的其他鉴权形式还包括 Webhook 令牌认证。

为负载资源设置约束

• 设置名字空间限制：为每个名字空间的内存和 CPU 设置配额

• 为 DNS 请求做准备：如果你希望工作负载能够完成大规模扩展，你的 DNS 服务也必须能够扩大规模。

• 创建额外的服务账户：用户账户决定用户可以在集群上执行的操作，服务账号则定义的是在特定名字空间中 Pod 的访问权限。