远程管理、本地裸金属 Kubernetes 集群的挑战

引言

最近宣布的 Platform9 Managed Kubernetes (PMK) 是一个本地企业级 Kubernetes 解决方案，其独特之处在于：集群运行在用户的内部硬件上，而其配置、监控、故障排除和整体生命周期则由 Platform9 SaaS 应用进行远程管理。尽管用户喜爱这种部署模型的直观体验和易用性，但这种方法也带来了有趣的技术挑战。在本文中，我们将首先描述 PMK 的动机和部署架构，然后概述我们面临的技术挑战以及我们的工程团队如何解决这些挑战。

多操作系统引导模型

与其前身 Managed OpenStack 一样，PMK 旨在让企业客户尽可能轻松地部署和操作“私有云”，在当前上下文中，这意味着一个或多个 Kubernetes 集群。为了适应那些采用特定 Linux 发行版的客户，我们的安装过程采用了“裸 OS”或“自带 OS”模型，这意味着管理员可以通过在他们偏好的 OS（Ubuntu-14、CentOS-7 或 RHEL-7）上安装一个简单的 RPM 或 Deb 包来将 PMK 部署到现有的 Linux 节点。管理员从其 Platform9 SaaS 门户下载的软件包会启动一个代理，该代理预配置了安全连接到客户运行在 WAN 上的 Platform9 SaaS 控制器并向其注册所需的所有信息和凭据。

节点管理

我们遇到的第一个挑战是在没有裸金属云 API 和节点 SSH 访问的情况下配置 Kubernetes 节点。我们使用 *node pool* 概念和配置管理技术解决了这个问题。每个运行代理的节点都会自动显示在 SaaS 门户中，允许用户*授权*该节点用于 Kubernetes。新*授权*的节点会自动进入 *node pool*，表示它可用但未在任何集群中使用。管理员可以独立创建或多个 Kubernetes 集群，这些集群初始为空。在任何后续时间，他或她可以请求将一个或多个节点附加到任何集群。PMK 通过将指定数量的节点从池中转移到集群来满足请求。当节点获得授权时，其代理成为配置管理代理，从 SaaS 应用中运行的 CM 服务器轮询指令，并能够下载和配置软件。

集群创建和节点附加/分离操作通过 REST API、名为 *qb* 的 CLI 工具和基于 SaaS 的 Web UI 提供给管理员。以下截图显示了 Web UI 中一个名为 clus100 的 3 节点集群、一个空集群 clus101 以及这三个节点。

集群初始化

首次将一个或多个节点附加到集群时，PMK 会配置这些节点以形成一个完整的 Kubernetes 集群。目前，PMK 自动决定 Master 和 Worker 节点的数量和放置位置。将来，PMK 将提供“高级模式”选项，允许管理员覆盖和自定义这些决定。通过 CM 服务器，PMK 然后向每个节点发送配置和一组脚本，根据配置初始化每个节点。这包括安装或升级 Docker 到所需版本；启动 2 个 Docker 守护进程（bootstrap 和 main），创建 etcd K/V 存储，建立 flannel 网络层，启动 kubelet，并根据节点角色（master vs. worker）运行相应的 Kubernetes 组件。以下图表显示了一个完全形成的集群的组件布局。

容器化的 kubelet？

我们遇到的另一个障碍源于我们最初决定按照 Multi-node Docker 部署指南 的建议运行 kubelet。我们发现这种方法引入了复杂性，导致许多难以调试的错误，这些错误对 Kubernetes、Docker 和节点 OS 的组合版本很敏感。例如：kubelet 需要将包含 secrets 的目录挂载到容器中，以支持 Service Accounts 机制。事实证明，在容器内部执行此操作很棘手，需要一系列复杂的步骤，结果证明这些步骤很脆弱。在修复了不断出现的各种问题后，我们最终决定将 kubelet 作为原生程序在主机 OS 上运行，从而显著提高了稳定性。

克服网络障碍

PMK 的 Beta 版本目前使用 flannel 的 UDP 后端作为网络层。在 Kubernetes 集群中，许多基础设施服务需要跨节点通信，使用各种 端口（443、4001 等）和协议（TCP 和 UDP）。通常，客户节点有意或无意地阻止部分或全部流量，或者运行现有服务与所需端口冲突，导致不明显的故障。为了解决这个问题，我们尝试尽早检测配置问题并立即通知管理员。PMK 在安装 Kubernetes 软件之前，对参与集群的所有节点运行“预检”检查。这意味着在每个节点上运行小型测试程序，以验证 (1) 所需端口是否可用于绑定和监听；以及 (2) 节点是否可以使用所有必需的端口和协议相互连接。这些检查并行运行，并在集群初始化之前花费不到几秒钟。

监控

SaaS 管理的私有云的一个价值在于由 SaaS 团队进行持续监控和早期问题检测。无需客户干预即可解决的问题会自动处理，而其他问题则通过 UI 警报、电子邮件或实时渠道主动与客户沟通。Kubernetes 监控是一个巨大话题，值得单独撰写博客文章，因此我们只简单提及。我们将问题大致分为几个层：(1) 硬件和操作系统，(2) Kubernetes 核心（例如 API 服务器、控制器和 kubelets），(3) 附加组件（例如 SkyDNS 和 ServiceLoadbalancer）和 (4) 应用。我们目前主要关注层 1-3。我们看到的一个主要问题来源是附加组件故障。如果 DNS 或 ServiceLoadbalancer 反向 HTTP 代理（即将升级为 Ingress Controller）发生故障，应用服务将开始失败。检测此类故障的一种方法是使用 Kubernetes API 本身监控组件，该 API 被代理到 SaaS 控制器，允许 PMK 支持团队监控任何集群资源。为了检测服务故障，我们关注的一个指标是 *pod 重启*。高重启计数表明服务正在持续失败。

未来主题

我们在其他领域也面临着复杂挑战，值得单独撰写文章：(1) *与 Keystone 进行身份验证和授权*，Keystone 是 Platform9 产品使用的身份管理器；(2) *软件升级*，即如何使其简短且不中断应用；以及 (3) *与客户外部负载均衡器的集成*（在缺乏良好自动化 API 的情况下）。

结论

Platform9 Managed Kubernetes 使用 SaaS 管理模型，试图隐藏在客户数据中心部署、操作和维护裸金属 Kubernetes 集群的复杂性。这些要求催生了独特的集群部署和管理架构，进而带来了独特的技术挑战。本文概述了其中一些挑战以及我们如何解决了它们。有关 PMK 动机的更多信息，请参阅 Madhura Maskasky 的博客文章。

• ←上一篇
• 下一篇→