远程管理、本地部署、裸机 Kubernetes 集群的挑战

引言

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

多操作系统引导模型

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

节点管理

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

集群创建和节点附加/分离操作通过REST API、名为qb的CLI实用程序和基于SaaS的Web UI向管理员公开。以下屏幕截图显示了Web UI，其中显示了一个名为clus100的3节点集群、一个空集群clus101以及三个节点。

集群初始化

首次将一个或多个节点连接到集群时，PMK会配置这些节点以形成完整的Kubernetes集群。目前，PMK会自动决定主节点和工作节点的数量和位置。未来，PMK将为管理员提供“高级模式”选项，允许他们覆盖和自定义这些决策。然后，通过CM服务器，PMK会向每个节点发送配置和一组脚本，以根据配置初始化每个节点。这包括安装或升级Docker到所需版本；启动两个Docker守护程序（引导和主程序），创建etcd K/V存储，建立flannel网络层，启动kubelet，以及运行适合节点角色（主节点或工作节点）的Kubernetes组件。下图显示了完全形成的集群的组件布局。

容器化的kubelet？

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

克服网络障碍

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

监控

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

未来主题

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

结论

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

• ←上一篇
• 下一篇→