第 2 章 大规模运行 Red Hat OpenShift Dev Spaces
尽管 Kubernetes 已经成为大规模部署和管理容器化工作负载的强大基础,通过云开发环境(CDE)实现规模,尤其是在数以千计的并发工作区中,这带来了显著的挑战。
这种规模会带来高的基础架构需求,并带来可能会影响整个系统的性能和稳定性的潜在瓶颈。解决这些挑战需要满足各种规划、战略架构选择、监控和持续优化,以确保为大量用户提供无缝且高效的开发体验。
CDE 工作负载主要比较复杂,因为 Visual Studio Code - Open Source ("Code - OSS") 或 JetBrains 网关 等底层 IDE 解决方案被设计为单用户应用程序,而不是多租户服务。
资源数量和对象最大值
虽然 Kubernetes 集群中资源数量没有严格的限制,但 大型集群需要记住的某些注意事项
在 Kubernetes Podcast 的 Wojciech Tyczynski 中了解更多有关"可扩展性 "的信息。
OpenShift Container Platform 是 Kubernetes 的认证发行版本,还为各种资源提供一组经过测试的最大值,可作为规划环境的初始指南:
资源类型 | 测试的最大值 |
---|---|
节点数 | 2000 |
pod 数量 | 150000 |
每个节点的 pod 数量 | 2500 |
命名空间数量 | 10000 |
服务数 | 10000 |
secret 的数量 | 80000 |
配置映射数量 | 90000 |
表 1:OpenShift Container Platform 为各种资源测试的集群最大值。
您可以在 官方文档 中找到有关 OpenShift Container Platform 测试的对象最大值的更多详细信息。
例如,由于潜在的性能和管理开销,通常不建议具有 10,000 多个命名空间。在 Red Hat OpenShift Dev Spaces 中,每个用户都分配一个命名空间。如果您希望用户数量较大,请考虑将工作负载分散到多个 "fit-for-purpose" 集群,并可能利用解决方案进行多集群编配。
资源要求
在 Kubernetes 上部署 Red Hat OpenShift Dev Spaces 时,务必要准确计算资源要求,并确定每个 CDE 的内存和 CPU / GPU 需求,以满足集群的正确大小。通常,CDE 大小受限制,且不能超过 worker 节点大小。CDE 的资源要求可能会因特定工作负载和配置而异。例如,简单的 CDE 可能需要几百兆字节的内存,而更复杂的内存需要几GB 的内存和多个 CPU 内核。
您可以在 官方文档 中找到有关计算资源要求的更多详细信息。
使用 etcd
Kubernetes 集群配置的主要数据存储,状态是 etcd。它保存集群状态和配置,包括节点、Pod、服务和自定义资源的信息。作为分布式键值存储,etcd 不会像 etcd 的增长而扩展,且随着 etcd 的大小增长,因此对集群的负载会面临其稳定性。
默认 etcd 大小为 2 GB,建议的最大值为 8 GB。超过最大限制可能会导致 Kubernetes 集群不稳定且无响应。
对象大小作为一个因素
不仅总体数量,也不是 etcd 中存储的对象大小是一个关键因素,它可能会影响其性能和稳定性。etcd 中存储的每个对象都会消耗空间,当对象数量增加时,etcd 的总大小也会增加。对象越大是,它在 etcd 中占用的空间越多。例如,可以使用几个相对大型 Kubernetes 对象来超载 etcd。
虽然 ConfigMap
中存储的数据无法通过设计超过 1 MiB,但一些相对大型的 ConfigMap
对象可能会超载 etcd 存储。
在 Red Hat OpenShift Dev Spaces 的上下文中,Operator 会创建和管理 'ca-certs-merged' ConfigMap,其中包含每个用户命名空间中的证书颁发机构(CA)捆绑包。集群中有大量 TLS 证书时,这会导致额外的 etcd 使用量。
要使用 /etc/pki/ca-trust/extracted/pem
路径下的 ConfigMap
来禁用挂载 CA 捆绑包,请通过将 disableWorkspaceCaBundleMount
属性设置为 true
来配置 CheCluster
自定义资源。使用这个配置,只有自定义证书将挂载到路径 /public-certs
下:
spec: devEnvironments: trustedCerts: disableWorkspaceCaBundleMount: true
spec:
devEnvironments:
trustedCerts:
disableWorkspaceCaBundleMount: true
dev Workspace 对象
对于大型 Kubernetes 部署,特别是涉及大量自定义资源(如 DevWorkspace
对象)(代表 CDE)的大型 Kubernetes 部署,etcd 可能会带来显著的性能瓶颈。
根据 6,000 DevWorkspace
对象的负载测试,etcd 的存储消耗大约为 2.5GB。
从 Dev Workspace Operator 版本 0.34.0 开始,您可以配置一个修剪器,以自动清理在一定时间段内不使用的 DevWorkspace
对象。要设置修剪器,请按如下所示配置 DevWorkspaceOperatorConfig
对象:
OLMConfig
当 Operator Lifecycle Manager (OLM) 安装 Operator 时,会在 Operator 配置为监视的每个命名空间中创建其 CSV 的精简副本。这些剥离的 CSV 称为"Copied CSV",并告知用户控制器在给定命名空间中主动协调资源事件。在特定的大型集群中,带有命名空间和安装的 Operator 倾向于数百个或数千个 CSV,Copied CSV 会消耗大量资源,如 OLM 内存用量、集群 etcd 限制、网络等。要取消复制到每个命名空间的 CSV,请相应地配置 OLMConfig
对象:
有关 disableCopiedCSVs
功能的附加信息,请参考其原始 增强建议。
disableCopiedCSVs
属性对 etcd 的主要影响与资源消耗相关。在有大量命名空间和多个集群范围的 Operator 的集群中,创建和维护大量 Copied CSV 可能会导致 etcd 存储使用和内存消耗增加。禁用 Copied CSV,etcd 中存储的数据量会显著降低,这有助于提高集群整体性能和稳定性。
对于命名空间数量和操作员可以快速添加到大量数据的大型集群,这尤其重要。禁用 Copied CSV 可帮助减少 etcd 的负载,从而提高了性能和对集群的响应。另外,它可以帮助减少 OLM 的内存占用,因为它不再需要维护和管理这些其他资源。
您可以在 官方文档 中找到有关"禁用 Copied CSV"的更多详细信息。
Cluster Autoscaling
虽然集群自动扩展是一个强大的 Kubernetes 功能,但您无法始终回退到它。您应该始终通过分析环境中的负载数据来检测日常或每周使用模式来考虑预测扩展。如果您的工作负载遵循一种模式,且每天都存在高峰,您应该考虑相应地置备 worker 节点。例如,如果您有一个可预测的负载模式,其中工作区的数量会在工作时间内增加,并在停机期间减少,您可以使用预测扩展来根据预期的负载调整 worker 节点数量。这有助于确保您有足够的资源来处理峰值负载,同时在非高峰期最小化成本。
考虑利用开源解决方案(如 Karpenter )来配置和 worker 节点的生命周期管理。Karpenter 可以根据工作负载的特定要求动态置备和优化 worker 节点,有助于提高资源利用率并降低成本。
多集群
按照设计,Red Hat OpenShift Dev Spaces 不是多集群的了解,每个集群只能有一个实例。但是,您可以通过在多集群环境中运行 Red Hat OpenShift Dev Spaces,方法是在每个不同的集群中部署 Red Hat OpenShift Dev Spaces,并使用负载均衡器或基于 DNS 的路由根据用户的位置或其他标准将流量定向到适当的实例。这种方法可以帮助提高性能和可靠性,方法是将工作负载分散到多个集群中,并在集群失败时提供冗余功能。
图 2.1. 多集群环境的方案
您可以使用 Developer Sandbox 测试在多集群中运行 OpenShift Dev Spaces 的免费试用环境,并带有一个预先配置的工具和服务。从基础架构的角度来看,Developer Sandbox 由多个 ROSA 集群组成。在每个集群中,使用 Argo CD 安装和配置 Red Hat OpenShift Dev Spaces 的 Productized 版本。由于用户基础分散在多个集群中,因此 workspaces.openshift.com 用作产品化 Red Hat OpenShift Dev Spaces 实例的单个入口点。您可以在以下 GitHub 仓库 中找到有关多集群重定向器的实施详情。
Workspaces.openshift.com 的多集群架构是 Developer Sandbox 的一部分。这是一个开发者特定于 Sandbox 的解决方案,无法在其他环境中重复使用。但是,您可以使用它作为实施类似解决方案的引用,并符合您的特定多集群需求。