问卷调查网站建设,河北建设官方网站,wordpress第一篇文章id,沈阳最新消息发布原文#xff1a;Christian Weichel - 2024.10.31
Kubernetes 似乎是构建远程、标准化和自动化开发环境的显而易见选择。我们也曾这样认为#xff0c;并且花费了六年时间#xff0c;致力于打造最受欢迎的云开发环境平台#xff0c;并达到了互联网级的规模。我们的用户数量达…
原文Christian Weichel - 2024.10.31
Kubernetes 似乎是构建远程、标准化和自动化开发环境的显而易见选择。我们也曾这样认为并且花费了六年时间致力于打造最受欢迎的云开发环境平台并达到了互联网级的规模。我们的用户数量达到了 150 万每天都有成千上万的开发环境使用 Kubernetes。然而在这个过程中我们发现 Kubernetes 并不是构建开发环境的最佳选择。
这是我们在 Kubernetes 上构建开发环境时的一系列实验、失败和走入死胡同的故事。多年来我们尝试了涉及 SSD、PVC、eBPF、seccomp 通知、TC 和 io_uring、shiftfs、FUSE 和 idmapped 挂载 的各种想法从 microVMs、kubevirt 到 vCluster。
我们一直在追求最优的基础设施平衡安全性、性能和互操作性。与此同时我们还要应对一个独特的挑战即建立一个可扩展的系统在处理任意代码执行时保持安全并足够稳定以便开发人员在其中工作。
这不是关于是否使用 Kubernetes 进行生产工作负载的讨论那是一个完全不同的话题。也不是关于如何在 Kubernetes 上构建一整套开发者体验以交付应用程序的讨论。
这是关于如何不要在云中构建开发环境的故事。
为什么开发环境是独特的
在深入探讨之前了解开发环境与生产工作负载相比有何独特之处至关重要
它们极其有状态且具有交互性这意味着它们无法从一个节点移动到另一个节点。大量的源代码、构建缓存、Docker 容器和测试数据的变化率很高迁移成本很高。与许多生产服务不同开发者与其环境是 1 比 1 的交互。开发者对自己的源代码和更改投入甚深开发者非常在意代码的任何更改且不容忍任何系统导致的阻碍。因此开发环境对故障有极低的容忍度。它们的资源使用模式不可预测开发环境有特定且不可预测的资源使用模式。大部分时间它们不需要太多的 CPU 带宽但在某些时刻它们需要在几百毫秒内使用多个核心。任何比这更慢的响应都会表现为不可接受的延迟和无响应。它们需要广泛的权限和能力与生产工作负载不同开发环境经常需要 root 访问权限并且能够下载和安装软件包。对于生产工作负载来说是安全问题的行为在开发环境中却是常态获取 root 权限、扩展网络能力并控制系统例如挂载额外的文件系统。
这些特性使开发环境与典型的应用工作负载截然不同并显著影响了我们在基础设施方面做出的决策。 当前的系统显然是 Kubernetes
当我们开始 Gitpod 项目时Kubernetes 似乎是我们基础设施的理想选择。它的可扩展性、容器编排能力以及丰富的生态系统与我们对云开发环境的愿景完美契合。然而随着我们的扩展和用户规模的增长我们遇到了与安全性和状态管理相关的诸多挑战这些挑战将 Kubernetes 推向了极限。从根本上讲Kubernetes 是为运行可控的应用工作负载而设计的而不是无序的开发环境。
在大规模管理 Kubernetes 颇具复杂性。尽管 GKE 和 EKS 等托管服务在某些方面缓解了痛点但它们也带来了自身的一系列限制和局限性。我们发现许多团队在运营 CDE云开发环境时低估了 Kubernetes 的复杂性这也导致了我们之前自托管 Gitpod 服务的支持负担显著增加。
资源管理的困境
我们面临的最重大挑战之一是资源管理特别是每个环境的 CPU 和内存分配。乍一看在一个节点上运行多个环境以共享资源如 CPU、内存、IO 和网络带宽似乎是一个很有吸引力的选择。但实际上这会引发显著的「邻居噪声效应noisy neighbor」从而严重影响用户体验。
CPU 挑战
CPU 时间看起来像是环境之间共享的最简单候选资源。大多数时候开发环境并不需要太多的 CPU 时间但当它们需要时它们需要得很快。当语言服务器开始延迟或终端变得卡顿时用户会立刻感受到延迟。这种 CPU 需求的峰值特性非活跃时期之后紧接着是密集的构建任务使得很难预测何时需要 CPU 时间。
为了解决这个问题我们尝试了基于 完全公平调度器CFS的各种方案使用 DaemonSet 实现了自定义控制器。一个核心问题是我们无法预测何时需要 CPU 带宽而只能通过观察 cgroup 的 cpu_stats 中的 nr_throttled 来了解何时曾经需要。
即便采用静态 CPU 资源限制也会出现挑战因为与应用工作负载不同一个开发环境将在同一个容器中运行多个进程。这些进程会竞争同样的 CPU 带宽可能导致 VS Code 断开连接因为 VS Code 服务器分配不到 CPU 时间而“饿”死了。
我们尝试通过调整各个进程的优先级来解决这一问题例如提高 bash 或 vscode-server 的优先级。然而这些进程优先级会应用于整个进程组取决于内核的 autogroup 调度配置因此也会影响 VS Code 终端中启动的资源密集型编译器。使用进程优先级来解决终端卡顿问题需要一个精心编写的控制循环才能有效。
我们基于 cgroupv1 引入了自定义的 CFS 和进程优先级控制循环并在 1.24 版 Kubernetes 托管平台上更容易获得 cgroupsv2 后将其转移到了 cgroupsv2 上。Kubernetes 1.26 引入的动态资源分配意味着不再需要部署 DaemonSet 并直接修改 cgroup尽管这可能会以控制循环速度和效果为代价。上述所有方案都依赖于每秒对 CFS 限制和优先级值进行调整。
内存管理
内存管理也带来了自己的一系列挑战。为每个环境分配固定的内存量以便在最大占用时每个环境都能获得其固定份额这种方式简单直接但非常受限。在云中内存RAM是相对昂贵的资源因此我们希望能够超额预定内存。
在 Kubernetes 1.22 引入交换空间 之前内存超额预定几乎是不可能的因为回收内存不可避免地意味着杀死进程。随着交换空间的加入内存超额预定的需求有所减少因为交换空间在托管开发环境时运行良好。
存储性能优化
存储性能对于开发环境的启动性能和体验至关重要。我们发现IOPS 和延迟尤其影响环境中的体验。而 IO 带宽直接影响工作空间的启动性能特别是在创建/恢复备份或提取大型工作空间镜像时。
我们尝试了各种设置以找到速度与可靠性、成本与性能之间的最佳平衡。
SSD RAID 0这提供了高 IOPS 和带宽但将数据绑定到特定节点。任何单个磁盘的故障都会导致数据完全丢失。这是 gitpod.io 今天的操作方式我们尚未遇到过此类磁盘故障。这个设置的简化版本是使用单个附加到节点的 SSD。该方法提供了较低的 IOPS 和带宽但仍然将数据绑定到单个节点。块存储如 EBS 卷或 Google 持久磁盘永久附加到节点上可以显著扩大可使用的不同实例或可用区。尽管仍然绑定到单个节点并且提供的吞吐量/带宽远低于本地 SSD但它们在可用性上更具优势。在使用 Kubernetes 时持久卷声明PVC似乎是显而易见的选择。作为不同存储实现的抽象层它们提供了很大的灵活性但也带来了新的挑战 不可预测的挂载和卸载时间导致工作空间启动时间不可预测。再加上调度复杂性的增加它们使得实现有效的调度策略变得更加困难。可靠性问题导致工作空间故障特别是在启动期间。这在 Google Cloud2022 年上尤为明显使得我们尝试使用 PVC 的做法无法实践。每个实例可附加的磁盘数量有限给调度程序和每个节点的工作空间数量带来了额外的限制。可用区本地性约束使得在可用区之间平衡工作空间变得更加困难。
备份和恢复本地磁盘被证明是一项昂贵的操作。我们使用 daemonSet 实现了一种解决方案它可以上传和下载未压缩的 tar 存档到 S3 或从 S3 下载。 这种方法需要在 I/O、网络带宽和 CPU 使用之间进行仔细的平衡例如解压缩存档会消耗节点上几乎所有可用的 CPU而未压缩备份产生的额外流量通常不会消耗所有可用的网络带宽如果同时启动/停止工作空间的数量得到仔细控制。
节点上的 IO 带宽在工作空间之间共享。我们发现除非我们限制每个工作空间可用的 IO 带宽否则其他工作空间可能会因 IO 带宽不足而停止运行尤其是在内容备份/恢复期间会出现这种问题。为了解决这个问题我们实现了基于 cgroup 的 IO 限制器为每个环境设置了固定的 IO 带宽限制。
自动扩展和启动时间优化
我们的主要目标是尽可能减少启动时间。不可预测的等待时间会显著影响生产力和用户满意度。然而这一目标通常与我们希望密集部署工作空间以最大化机器利用率的愿望相冲突。
我们最初认为在一个节点上运行多个工作空间可以改善启动时间因为它们可以共享缓存。然而现实情况并非如此。Kubernetes 的启动时间受限于下层操作因为内容需要移动到位这需要时间。
在不保持工作空间热备这将非常昂贵的情况下我们必须寻找其他方法来优化启动时间。
提前扩展我们的方法演变
为了尽量减少启动时间我们探索了多种扩展方法
Ghost 工作空间在集群扩展插件可用之前我们尝试了“Ghost 工作空间”。这些是占用空间的可抢占 Pod用来自行扩展。我们通过自定义调度器实现了这一点。然而这种方法在替换时既慢又不可靠。Ballast PodGhost 工作空间的进化版Ballast Pod 填满了整个节点。与 Ghost 工作空间相比这减少了替换成本并加快了替换时间。扩展插件2022 年 6 月我们转向使用集群自动扩展插件。这些插件允许我们直接影响扩展的方式而不再需要“欺骗”自动扩展器。这极大地改善了我们的扩展策略。
峰值负载的比例扩展
为了更有效地处理峰值负载我们实施了比例扩展系统。此方法根据开发环境启动的速度控制扩展速度。它通过使用暂停镜像启动空 Pod使我们能够快速增加容量以应对需求激增。
镜像拉取优化多次尝试的故事
启动时间优化的另一个关键方面是提高镜像拉取速度。工作空间容器镜像即开发者可用的所有工具可能会超过 10 GB 未压缩数据。为每个工作空间下载和解压缩这么多数据会大大消耗节点资源。我们探索了多种加速镜像拉取的策略
DaemonSet 预拉取我们尝试通过 DaemonSet 预拉取常用镜像。然而在扩展操作期间当节点上线且工作空间启动时镜像仍然不会出现在节点上。此外预拉取现在还会与启动中的工作空间争夺 IO 和 CPU 带宽。最大化层复用我们使用自定义构建器 dazzle 构建镜像旨在最大化层的复用。然而我们发现由于 OCI manifest 中的高基数和间接性层复用很难观察到。Pre-baked 镜像我们尝试将镜像预先写入节点磁盘镜像。虽然这改善了启动时间但也有显著弊端。镜像很快过时这种方法对自托管安装无效。Stargazer 和延迟拉取这种方法要求将所有镜像转换这增加了复杂性、成本和操作时间。此外在我们 2022 年尝试时并非所有注册表都支持此方法。Registry-facade IPFS这种解决方案在实践中效果良好提供了不错的性能和分发。我们在 2022 年的 KubeCon 介绍了这种方法。然而它给我们的系统增加了很大的复杂性。
镜像缓存并没有一个适用于所有场景的解决方案而是一组在复杂性、成本和对用户施加的限制即他们可以使用的镜像之间的权衡。我们发现工作空间镜像的同质性是优化启动时间的最简单方法。
网络复杂性
Kubernetes 的网络引入了一系列挑战特别是 开发环境访问控制默认情况下开发环境之间的网络需要完全隔离即一个环境无法访问另一个。同样用户访问工作空间的方式也需要隔离。网络策略 在确保环境之间正确断开连接方面发挥了重要作用。 最初我们使用 Kubernetes 服务控制各个环境端口的访问例如 IDE 或工作空间中运行的服务并配合 Ingress 代理将流量转发到相应服务通过 DNS 解析。然而由于服务数量庞大名称解析开始频繁失败。如果不小心例如未设置 enableServiceLinks: false整个工作空间可能会崩溃。 网络带宽共享节点上的网络带宽是另一个需要在单个节点上的多个工作空间之间共享的资源。一些 CNI 提供 network shaping 支持例如 Cilium 的 带宽管理器。这又为我们增加了一个需要控制和在环境之间共享的资源。
安全与隔离在灵活性和保护之间寻找平衡
在我们基于 Kubernetes 的基础设施中提供安全环境的同时赋予用户开发所需的灵活性是面临的最大挑战之一。用户希望能够安装额外的工具例如使用 apt-get install运行 Docker甚至在开发环境中设置 Kubernetes 集群。如何在实施强有力的安全措施的同时满足这些需求是一个复杂的问题。
简单方法root 权限
最简单的解决方案是给用户他们容器的 root 权限。然而这种方法很快暴露了它的缺陷
给用户 root 权限实际上等于给他们节点本身的 root 权限允许他们访问开发环境平台和该节点上运行的其他开发环境。这消除了用户与主机系统之间的任何有效安全边界意味着开发者可以意外或故意干扰并破坏开发环境平台本身甚至访问其他开发者的开发环境。此外它还暴露了基础设施可能被滥用和面临安全风险。这样也无法实施真正的访问控制模型并且架构无法做到零信任。无法确保系统中执行操作的某个行为者是可以验证的。
显然我们需要一种更复杂的方法。
用户命名空间更细致的解决方案
为了解决这些问题我们转向了用户命名空间这是一种 Linux 内核功能提供了对容器内用户和组 ID 映射的细粒度控制。这种方法允许我们在不影响主机系统安全性的情况下给予用户容器内的“类似 root 权限”。
虽然 Kubernetes 在 1.25 版本中引入了对用户命名空间的支持但我们从 Kubernetes 1.22 开始就已经实现了自己的解决方案。我们的实现涉及多个复杂的组件 文件系统 UID 转换这是为了确保容器内创建的文件能够正确映射到主机系统上的 UID。我们尝试了几种方法 我们仍然使用 shiftfs 进行文件系统 UID 转换。尽管在某些上下文中已被弃用但 shiftfs 仍为我们提供了我们所需的功能并具有可接受的性能特征。我们还尝试了 fuse-overlayfs它提供了所需的功能但性能有限。虽然 idmapped 挂载具有潜在优势但由于兼容性和实施方面的考虑我们尚未转向它们。 挂载屏蔽的 proc容器启动时通常希望挂载 /proc。然而在我们的安全模型中出于安全原因 /proc 会被屏蔽。解决这一限制需要一个复杂的解决方案 我们构建了一个屏蔽的 proc 文件系统。然后将这个屏蔽的 proc 移动到正确的挂载命名空间中。我们使用 seccomp 通知实现这一点它允许我们拦截和修改某些系统调用。 FUSE 支持添加 FUSEFilesystem in Userspace支持对许多开发工作流至关重要这需要实现自定义设备策略。这涉及修改容器的 eBPF 设备过滤器这是一种允许我们对设备访问做出细粒度决策的低级编程能力。 网络能力作为真正的 root用户拥有 CAP_NET_ADMIN 和 CAP_NET_RAW 权限赋予了广泛的网络配置特权。容器运行时例如 Docker/runc广泛使用这些权限。将这些权限授予开发环境容器会干扰 CNI 并破坏安全隔离。 为了提供这些能力我们最终在 Kubernetes 容器内创建了另一个网络命名空间首先通过 slirp4netns 连接到外部网络后来使用 veth 成对和自定义 nftables 规则。 启用 Docker为 Docker 本身实现了一些特定的 hacks。我们注册了自定义的 runc-facade它修改了 Docker 生成的 OCI 运行时规范。这使我们能够移除例如 OOMScoreAdj仍不允许因为这需要节点上的 CAP_SYS_ADMIN 权限。
实现此安全模型带来了许多挑战
性能影响我们的某些解决方案尤其是早期的 fuse-overlayfs具有显著的性能影响。我们一直在努力优化这些解决方案。兼容性并非所有工具和工作流都与这种受限环境兼容。我们必须在安全性和可用性之间仔细平衡。复杂性最终系统比简单的容器化环境复杂得多这对开发和运营都带来了影响。跟上 Kubernetes 的发展随着 Kubernetes 的发展我们不得不调整我们的自定义实现以利用新功能同时保持向后兼容。
微型虚拟机micro-VM实验
当我们在应对 Kubernetes 的挑战时我们开始探索微型虚拟机技术例如 Firecracker、Cloud Hypervisor 和 QEMU以寻找一种中间方案。这种探索的驱动力来自于 micro-VM 在资源隔离、与其他工作负载如 Kubernetes的兼容性和安全性方面的承诺同时有可能保持容器化的一些优势。
微型虚拟机的承诺
微型虚拟机提供了几个与我们云开发环境目标高度契合的诱人优势
增强的资源隔离micro-VM 提供了比容器更好的资源隔离尽管这需要牺牲某些超额预订功能。使用 micro-VM 后我们不再需要处理共享内核资源的问题这可能会为每个开发环境带来更可预测的性能。内存快照与快速恢复尤其是 Firecracker 使用 userfaultfd 提供的内存快照功能令人兴奋这项技术承诺几乎可以实现完整的机器恢复包括运行中的进程。对于开发者来说这意味着显著缩短环境启动时间并能精确恢复到上次离开的状态。改进的安全边界micro-VM 有潜力成为一个强大的安全边界可能不再需要我们在 Kubernetes 设置中实现的复杂用户命名空间机制。这可以确保与更广泛的工作负载包括在开发环境中运行 Docker 甚至 Kubernetes完全兼容。
微型虚拟机的挑战
然而我们在 micro-VM 上的实验也暴露了几个重要的挑战
开销尽管是轻量级虚拟机micro-VM 仍引入了比容器更大的开销。这影响了性能和资源利用率这对于云开发环境平台来说都是关键考虑因素。镜像转换将 OCI开放容器倡议镜像转换为 micro-VM 可用的文件系统需要定制解决方案。这为我们的镜像管理流程增加了复杂性并可能影响启动时间。特定技术的限制 Firecracker 缺乏 GPU 支持这对某些开发工作流越来越重要。在我们实验时2023 年中期不支持 virtiofs限制了我们高效文件系统共享的选择。 Cloud Hypervisor 由于缺乏 userfaultfd 支持快照和恢复过程较慢抵消了我们希望从 micro-VM 中获得的关键优势之一。 数据传输挑战使用 micro-VM 后处理大规模内存快照变得更加复杂这影响了调度和启动时间这两个因素对用户体验至关重要。存储考虑我们在将 EBS 卷附加到微型虚拟机的实验中发现了新的可能性但也提出了一些新的问题 持久存储将工作空间内容保存在附加卷上减少了从 S3 反复拉取数据的需求可能改善启动时间并减少网络使用。性能考量在工作空间之间共享高吞吐量卷有助于提高 I/O 性能但也带来了实施有效配额、管理延迟和确保可扩展性的问题。
微型虚拟机实验的经验教训
尽管微型虚拟机最终没有成为我们的主要基础设施解决方案但这次实验提供了宝贵的见解
我们非常喜欢完整工作空间备份和运行时状态挂起/恢复的体验这为开发环境提供了极大的便利。我们第一次认真考虑是否要放弃 Kubernetes。将 KVM 和微型虚拟机集成到 pods 中的努力让我们探索了 Kubernetes 之外的选项。我们再次意识到存储是提供可靠启动性能、可靠工作空间不要丢失数据和优化机器利用率的关键要素。
Kubernetes 作为开发环境平台面临的巨大挑战
正如我在开头提到的开发环境需要一个系统该系统既能尊重开发环境的独特状态性又能为开发者提供必要的权限以保持高效同时确保安全边界。而且我们需要在不牺牲安全的前提下将运营开销降到最低。
今天使用 Kubernetes 完全可以实现上述目标——但代价巨大。我们通过艰难的实践了解到应用工作负载和系统工作负载之间的区别。
Kubernetes 确实很了不起。它有一个充满热情的社区构建了一个真正丰富的生态系统。如果你运行的是应用工作负载Kubernetes 依然是一个不错的选择。然而对于像开发环境这样的系统工作负载Kubernetes 在安全性和运营开销方面呈现出巨大的挑战。微型虚拟机和明确的资源预算能有所帮助但成本会成为一个更加突出的因素。
因此在多年逆向工程并将开发环境强行适配到 Kubernetes 平台上之后我们退后一步重新思考未来的开发架构应该是什么样子。2024 年 1 月我们开始构建它。到了 10 月我们发布了它Gitpod Flex。
这背后是超过六年艰苦的经验教训旨在安全地运行互联网规模的开发环境并形成了其架构基础。
开发环境的未来
在 Gitpod Flex 中我们继承了 Kubernetes 的基础理念例如广泛应用控制理论和声明式 API同时简化了架构并改进了安全基础。
我们采用了受 Kubernetes 启发的控制平面来编排开发环境。我们引入了一些特定于开发环境的必要抽象层同时抛弃了许多不需要的基础设施复杂性——这一切都是在 将零信任安全放在首位 的前提下实现的。 图注Gitpod Flex 的安全边界。
这种新架构使我们能够 无缝集成 devcontainer。我们还解锁了 在桌面上运行开发环境 的能力。现在摆脱了 Kubernetes 平台的繁重负担Gitpod Flex 可以在不到三分钟内自托管部署并且可以在任意数量的区域内部署这为合规性提供了更细粒度的控制并在组织边界和域建模时增加灵活性。
我们将在未来几周或几个月内发布更多关于 Gitpod Flex 架构的内容。我诚邀您在 11 月 6 日参加一个虚拟活动届时我将展示 Gitpod Flex并深入探讨其架构和安全模型。您可以 在这里报名。
在构建一个标准化、自动化且安全的开发环境平台时选择一个系统是因为它改善了您的开发者体验、减轻了您的运营负担并提升了您的收益。这并不是在选择 Kubernetes 或其他什么而是在选择一个能改善您支持的团队体验的系统。
