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

简介

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

多操作系统引导模型

像其前身 托管 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 安装或升级到所需的版本；启动 2 个 docker 守护进程（引导和主守护进程）、创建 etcd K/V 存储、建立 flannel 网络层、启动 kubelet 以及运行 Kubernetes，这适用于该节点的角色（主节点 vs. 工作节点）。下图显示了完全形成的集群的组件布局。

容器化的 kubelet？

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

克服网络障碍

PMK 的 Beta 版本目前使用 带有 UDP 后端的 flannel 作为网络层。在 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 控制器）失败，应用程序服务将开始失败。我们检测此类故障的一种方法是使用 Kubernetes API 本身来监控组件，该 API 被代理到 SaaS 控制器中，从而使 PMK 支持团队能够监控任何集群资源。为了检测服务故障，我们关注的一个指标是pod 重启。较高的重启计数表示服务持续失败。

未来主题

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

结论

Platform9 托管 Kubernetes 使用 SaaS 管理模式，试图隐藏在客户数据中心部署、运营和维护裸机 Kubernetes 集群的复杂性。这些要求导致了独特的集群部署和管理架构的发展，而这反过来又带来了独特的技术挑战。本文概述了其中一些挑战以及我们如何解决这些挑战。有关 PMK 背后的动机的更多信息，请随时查看 Madhura Maskasky 的 博客文章。

• ←上一篇
下一篇→