/dev/bytemap.cc #

Kubernetes: 运行在生产环境的准备工作

Posted on Feb 21, 2025
Table of contents:

准备工作

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

不同于开发、测试等环境的Kubernetes集群，生产环境的Kubernetes集群一般需要更强的稳定性和可靠性:

  • 生产环境可能需要被很多用户安全地访问，需要提供一致的可用性，以及能够与需求变化相适配的资源。

生产环境的Kubernetes集群需要考虑以下几点因素：

  1. 可用性：单节点的Kubernetes集群会存在单点故障, 所以需要多个节点组成高可用集群：

    1. 将控制面与工作节点分开
    2. 在多个节点上运行控制面组件
    3. 为kube-apiServer提供负载均衡
    4. 提供足够的可用的（或者能够迅速变为可用的）工作节点

  2. 规模：需要规划如何处理请求上升时对控制面和工作节点的压力，或者如何缩减集群规模以减少未使用资源的消耗。

  3. 安全性与访问管理: 需要更细粒度的方案(RBAC)来确定谁或者哪些主体可以访问集群资源。 通过管理策略和容器资源来针对用户和工作负载所可访问的资源设置约束。

生产环境的控制面

一个更为持久的、高可用的集群需要考虑控制面的扩展性。 运行在一台机器上的单机控制面服务不是高可用的。 保持集群的正常运行并需要确保它在出错时可以被修复是很重要的。生产环境的控制面需要考虑以下方面：o

  1. 选择部署工具: 你可以使用类似 kubeadm、kops 和 kubespray 这类工具来部署控制面。

  2. 管理证书: 控制面服务之间的安全通信是通过证书来完成的, 证书是在部署期间自动生成的。

  3. 为 API 服务器配置负载均衡: 配置负载均衡器来将外部的 API 请求散布给运行在不同节点上的 API 服务实例。

  4. 分离并备份 etcd 服务: etcd 服务可以运行于其他控制面服务所在的机器上， 也可以运行在不同的机器上以获得更好的安全性和可用性。 因为 etcd 存储着集群的配置数据，应该经常性地对 etcd 数据库进行备份， 以确保在需要的时候你可以修复该数据库。

  5. 创建多控制面系统: 为了实现高可用性，控制面不应被限制在一台机器上。 如果控制面服务是使用某 init 服务（例如 systemd）来运行的，每个服务应该至少运行在三台机器上。 不过，将控制面作为服务运行在 Kubernetes Pod 中可以确保你所请求的个数的服务始终保持可用。 调度器应该是可容错的，但不是高可用的。

  6. 跨多个可用区: 如果保持你的集群一直可用这点非常重要，可以考虑创建一个跨多个数据中心的集群； 在云环境中，这些数据中心被视为可用区。若干个可用区在一起可构成地理区域。 通过将集群分散到同一区域中的多个可用区内，即使某个可用区不可用，整个集群能够继续工作的机会也大大增加。

  7. 管理演进中的特性: 一些维护其健康和安全的任务, 如：证书管理，版本升级。

生产环境的工作节点

生产环境的工作负载需要是弹性的；它们所依赖的其他组件（例如 CoreDNS）也需要是弹性的。 无论你是自行管理控制面还是让云供应商来管理，你都需要考虑如何管理工作节点:

  1. 配置节点：节点可以是物理机或者虚拟机。如果你希望自行创建和管理节点， 你可以安装一个受支持的操作系统，之后添加并运行合适的节点服务。考虑：
    1. 在安装节点时要通过配置适当的内存、CPU 和磁盘读写速率、存储容量来满足你的负载的需求。
    2. 是否通用的计算机系统即足够，还是你有负载需要使用 GPU 处理器、Windows 节点或者 VM 隔离。
  2. 验证节点: 确保节点满足加入到 Kubernetes 集群的需求。
  3. 添加节点到集群中: 如果你自行管理你的集群，你可以通过安装配置你的机器， 之后或者手动加入集群，或者让它们自动注册到集群的 API 服务器。
  4. 扩缩节点: 基于你要运行的 Pod 和容器个数来确定扩充集群容量的规划。
  5. 节点自动扩缩容： 了解可以自动o管理节点的工具及其提供的能力。
  6. 安装节点健康检查: 确保节点以及在节点上运行的 Pod 处于健康状态。

生产级用户环境

在生产环境中，不再是一个人或者一小组人在访问集群，而是几十上百人需要访问集群。 在生产环境中，你会需要对不同名字空间具有不同访问权限级别的很多账号，生产环境的用户鉴权需要考虑：

  1. 认证（Authentication）: API 服务器可以使用客户端证书、持有者令牌、 身份认证代理或者 HTTP 基本认证机制来完成身份认证操作。
  2. 鉴权（Authorization）：
    • 基于角色的访问控制（RBAC）：通过身份认证的用户授权特定的许可集合来控制集群访问。 访问许可可以针对某特定名字空间（Role）或者针对整个集群（ClusterRole）。 通过使用 RoleBinding 和 ClusterRoleBinding 对象，这些访问许可可以被关联到特定的用户身上。
    • 基于属性的访问控制（ABAC）：基于集群中资源的属性来创建访问控制策略，基于对应的属性来决定允许还是拒绝访问。 策略文件的每一行都给出版本属性（apiVersion 和 kind）以及一个规约属性的映射， 用来匹配主体（用户或组）、资源属性、非资源属性（/version 或 /apis）和只读属性。

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

  • 设置鉴权模式： 当 Kubernetes API 服务器（kube-apiserver）启动时， 所支持的鉴权模式必须使用 *–authorization-config 文件或 –authorization-mode 标志配置。
  • 创建用户证书和角色绑定（RBAC）：如果你在使用 RBAC 鉴权，用户可以创建由集群 CA 签名的 CertificateSigningRequest（CSR）。接下来你就可以将 Role 和 ClusterRole 绑定到每个用户身上。
  • 创建组合属性的策略（ABAC）：如果你在使用 ABAC 鉴权， 你可以设置属性组合以构造策略对所选用户或用户组执行鉴权， 判定他们是否可访问特定的资源（例如 Pod）、名字空间或者 apiGroup。
  • 考虑准入控制器: 针对指向 API 服务器的请求的其他鉴权形式还包括 Webhook 令牌认证。

为负载资源设置约束

生产环境负载的需求可能对 Kubernetes 的控制面内外造成压力。 在针对你的集群的负载执行配置时，要考虑以下条目：

  • 设置名字空间限制：为每个名字空间的内存和 CPU 设置配额。
  • 为 DNS 请求做准备：如果你希望工作负载能够完成大规模扩展，你的 DNS 服务也必须能够扩大规模。
  • 创建额外的服务账户: 用户账户决定用户可以在集群上执行的操作，服务账号则定义的是在特定名字空间中 Pod 的访问权限。