对开源商业化的思考 & 全球流量大会(GTC)学习以及总结

引言:深圳福田会展中心的全球视野 2023年12月6日,在深圳福田会展中心,GTC 2023 全球流量大会如火如荼地展开。这场盛会汇集了来自全球的技术精英,共同探索互联网行业的前沿动态和未来发展趋势。身为参与者,我有幸深入这场融合科技与商业的交流盛会,特别是“聚焦开源,扩展出海新领航”这一议题,让我收获颇丰,印象深刻。 大会聚焦于全球化的多元话题,包括出海市场的选择、广告推广策略等,与我此前参加的专注于日本市场出海活动的公司非常相似。然而,这次大会让我首次深入接触开源社区,不仅结识了众多开源界的领袖和布道者,也与许多杰出的开发者交流了心得。通过这些交流,我不仅学习到了许多新知识,还在思想上得到了升华。 在这篇博客中,我将对这次独特的经历进行深入的反思和总结,分享我在开源和全球化交汇中的洞见和学习。 对于 OpenIM 来说,我们现阶段正在全力准备奔向海外市场,希望打开国界,将 OpenIM 好用而且免费的开源核心功能贡献给全世界开发者。 开源项目天生就是分布式协作的,这是一种松散的结构。以 OpenIM 的开发者为例,我们现在有很多贡献者,开发者,虽然社区有双周会,但是还是很难和人或者同事有深层次的交流。 但对于开源商业公司而言,并不能简单的使用这种远程工作模式。在商业公司中,协作会更加的密切,而且对时效性的要求更高,当面沟通更能保证信息传递的完整性,这是远程工作难以替代的。当然,远程工作也有自己的优势,那就是吸引全球的人才。 所以,开源商业公司采用远程协作并没有问题,但一定要保证沟通的足够充分,拉平信息: 要视频沟通,文字只作为最终的记录。视频是沟通过程中信息丢失比较少的方式,是远程工作交流的首选方式。千万不要用文字来讨论非技术问题,这会带来巨大的信息差和误解。 保证沟通的尊重和善意。在开源项目中,大家因为没有雇佣关系,都是无偿做贡献,所以在异步沟通时特别强调尊重和善意;而在商业公司的远程办公时,因为缺少同事之间的沟通、吐槽和心理按摩,就更要注意沟通的尊重。 定期线下见面,增加相互之间的了解和信任。 另外一点,长期的远程协作,对于参与的工程师来说,除了需要很高的自律和自我管理的要求外,也要注意工作和生活的隔离,保持正常的社交活动和运动健身,否则很容易与社会脱节。 之前和 Apache APISIX 的某个小姐姐聊天,她说的一句话感触很深。也有很多适应不了远程工作的同事一一离去,这也是一个适者生存的达尔文法则。 关于 OpenIM 的远程工作,以及企业的文化,强烈推荐阅读下面的博客: Englist Version 中文版本 出海挑战:中国互联网企业的全球化之旅 中国互联网企业在全球化道路上的探索充满挑战与机遇。从初涉海外市场的尝试到在竞争激烈的国际环境中求生存,它们不断在新的市场环境中寻找增长点。这一过程中,企业需要超越传统的商业模式,适应多元文化和不同的市场需求。 首先,来到了第一个话题,为什么要去做海外社区? 和很多的开源社区的布道者和专家沟通交流,然后反思,我深信建立一个活跃的海外社区是开源项目成功的关键。在全球化的今天,开源不仅是关于代码的分享,更是一种文化和思想的交流。通过建立海外社区,我们不仅能将技术带到世界的每个角落,还能促进不同文化背景下的思想碰撞和创新。 人性化地讲,建立海外社区意味着建立更广泛的连接和共鸣。每一位开源贡献者,不论身处何地,都希望他们的声音被听见,他们的贡献被认可。海外社区提供了一个平台,让来自世界各地的开发者能够参与到项目中来,分享他们独特的视角和经验。这种多元化的参与不仅丰富了项目本身,还激发了更多创新的火花。 同时,海外社区的建立也是对开源精神的一种致敬。开源精神强调的是开放、协作和共享,而这些价值观在全球范围内都是通用的。当我们向海外扩展时,我们不仅在分享代码,更在传播这种包容和合作的精神。 此外,对于开源项目而言,海外社区的建立还意味着更广阔的市场和使用场景。不同的地区和文化背景下,用户对技术的需求和应用方式可能截然不同。这些多样性的输入是项目发展不可或缺的,它们有助于项目更全面地成长,更好地服务于全球用户。 我从大一开始接触 Github ,这个成功打开我通往未来的钥匙。 从2020年左右我开始接触开源,觉得开源比业务代码更有意义。因为开源不仅有技术积累,而且能把你学到的东西分享给其他人,一起成长,所以开源对程序员来说是一个双赢的事。 最开始的时候,我通过学习做笔记,分享笔记到 GitHub ,到后面做项目,参与到一些顶级的开源项目中来,然后慢慢的追求精益。整个过程,我很清晰的看到自己的成长。 甚至我的代码,就像 Git 或者 区块链的默克尔树结构,一步步的串起来记录,每当一个时间段,看到以前的 PR ,满满的都是回忆和尴尬 … 同样,我也是一个云原生的爱好者。 在如今这个时代,开源已经成为了一个不可逆的潮流,尤其是在云原生的领域。以微软为例,他们在 Github 上的开源项目贡献位居全球前列,这充分体现了他们对开源的全面拥抱。在云原生时代,如果你不拥抱开源,不利用开源组件去构建和优化你的核心系统,很可能会在激烈的市场竞争中落后。云原生技术的迅猛发展要求企业和开发者必须快速适应新技术和方法论,而开源社区正是这种创新和合作的孵化器。在这个时代,开源不仅仅是技术选择,更是一种必要的战略思维。 开源社区国际化选择:第一站,启航 美国:开源发展的领头羊 美国仍然是全球最大的开发者社区,拥有超过2000万的开发者,过去一年增长了21%。美国的开源社区历史悠久且成熟,是全球开源活动的重要推动者。 亚太地区:快速增长的新星 亚太地区,尤其是印度、日本和新加坡,正经历着显著的开源社区增长。印度的开发者社区增长尤为显著,预计到2027年将超过美国,成为全球最大的开源社区。 非洲:充满潜力的新兴市场 非洲各地区,尤其是尼日利亚、加纳和肯尼亚,也在迅速发展成为技术公司的新兴枢纽。这些地区的开发者数量每年都在显著增长。 南美洲:稳健增长的活跃区域 南美洲的开发者社区,特别是在阿根廷和巴西,也在持续增长,与亚太和非洲的增长速度相仿。 欧洲:稳定增长的成熟市场 欧洲的开源社区虽然增长速度较美国慢,但在西班牙、德国和英国等国家仍保持稳定增长。...

December 7, 2023 · 3 分钟 · 477 字 · 熊鑫伟,我

GitOps 实践理论:Kubernetes 部署策略深入解析

今天我们来看看 kubernetes 和 gitops 的理论实践 命令介绍 首先我们来看看 kubectl 支持的子命名,方便我们使用: kubectl apply - 应用一个或多个资源的定义。通常用于部署应用程序或更新资源。 kubectl get - 显示一个或多个资源的信息。这是查看 Kubernetes 集群中资源状态的常用命令。 kubectl describe - 显示一个或多个资源的详细信息,如事件、状态和配置。 kubectl delete - 删除 Kubernetes 集群中的资源。 kubectl exec - 在集群中的容器里执行命令。 kubectl logs - 打印容器的日志。 kubectl create - 从文件或标准输入中创建一个或多个资源。 kubectl edit - 编辑集群中的资源。这将打开一个编辑器来修改资源的配置。 kubectl port-forward - 将本地端口转发到集群中的 Pod。 kubectl run - 在集群中运行一个指定的镜像。 kubectl scale - 调整资源(如 Deployment、ReplicaSet)的副本数量。 kubectl rollout - 管理资源的部署,如查看状态、暂停、恢复或回滚更新。 除了上面的命令,Kubernetes 中的 kubectl 还支持注解: kubectl annotate 命令用于给 Kubernetes 集群中的资源添加或更新注解(annotations)。注解是一种附加信息,可以用于存储非识别性的元数据。它们通常用于管理工具、库和客户端以存储辅助信息,例如描述、版本信息等。...

November 25, 2023 · 10 分钟 · 2034 字 · 熊鑫伟,我

管理后台和监控的部署与设计

OpenIM 提供了多种灵活的部署选项,适用于不同的环境和需求。以下是这些部署方案的简化和优化描述: 源码部署: 普通源码部署:使用 nohup 方式进行部署。这是一种基础的部署方法,适合于开发和测试环境。详情参见:普通源码部署指南。 生产级部署:采用 system 方式,更适合于生产环境。这种方法提供了更高的稳定性和可靠性。详情参见:生产级部署指南。 集群部署: Kubernetes 部署:提供两种方式,包括通过 helm 和 sealos 进行部署。这适用于需要高可用性和可扩展性的环境。具体方法请参考:Kubernetes 部署指南。 Docker 部署: 普通 Docker 方式:适用于快速部署和小型项目。详细信息请见:Docker 部署指南。 Docker Compose 方式:提供了更便捷的服务管理和配置,适合于复杂的多容器应用。 接下来,我们将逐一介绍这些部署方法的具体步骤、监控和管理后台的配置,以及使用技巧,帮助您根据自己的需求选择最合适的部署方案。 源码 & Docker 部署 源码部署 openim-server 和 openim-chat ,其他的组件都是通过 Docker 部署。 docker 部署则通过 https://github.com/openimsdk/openim-docker 仓库一键部署所有的组件。 部署的配置文件,可以阅读 https://github.com/openimsdk/open-im-server/blob/main/scripts/install/environment.sh 文档了解如何学习以及熟悉各个环境变量。 对于 Prometheus 来说,默认是没有开启 Prometheus 的,如果需要开启的话,需要在 make init 之前设置环境变量: export PROMETHEUS_ENABLE=true # 默认是 false 然后执行:...

November 15, 2023 · 3 分钟 · 453 字 · 熊新伟,我

Hugo 的高级教程

来到进阶部分,就需要深度学习一些 Hugo 的高级技巧。 模块 Hugo 模块是 Hugo 的核心构建块。模块可以是您的主项目或较小的模块,提供 Hugo 中定义的 7种组件类型中的一种或多种:static、content、layouts、data、assets、i18n和archetypes。 您可以按照您喜欢的任何组合来组合模块,甚至可以挂载非 Hugo 项目的目录,形成一个大型的虚拟联合文件系统。 Hugo 模块由 Go 模块提供支持。有关 Go 模块的更多信息,请参阅: https://github.com/golang/go/wiki/Modules https://go.dev/blog/using-go-modules 一些示例项目: https://github.com/bep/docuapi是一个在测试此功能时已移植到 Hugo Modules 的主题。这是将非 Hugo 项目安装到 Hugo 文件夹结构中的一个很好的示例。它甚至展示了常规 Go 模板中的 JS Bundler 实现。 https://github.com/bep/my-modular-site是一个非常简单的用于测试的网站。 模块配置: top level 💡简单的一个案例如下: module:noProxy:nonenoVendor:""private:'*.*'proxy:directreplacements:""workspace:"off"noVendor 一个可选的Glob模式匹配模块路径,当自动售货时跳过,例如 github.com/** vendorClosest 启用后,我们将选择与使用它的模块最近的供应商模块。默认行为是选择第一个。请注意,给定的模块路径仍然只能有一个依赖项,因此一旦使用它,就不能重新定义它。 proxy 定义用于下载远程模块的代理服务器。默认值是 direct ,意思是“git clone”或类似的。 noproxy 逗号分隔的glob列表匹配不应使用上面配置的代理的路径。 private 逗号分隔的glob列表匹配应被视为私有的路径。 workspaces 要使用的工作区文件。这将启用Go工作区模式。请注意,这也可以通过OS env设置,例如 export HUGO_MODULE_WORKSPACE=/my/hugo.work 这只适用于Go 1.18+。在Hugo v0.109.0 中,我们将默认值更改为 off ,现在我们可以解析相对于工作目录的任何相对工作文件名。...

November 6, 2023 · 15 分钟 · 3095 字 · 熊鑫伟,我

Kubernetes Kustomize 学习指南

介绍 关于 kustomize github 地址 Get Started Kustomize 是一个专为 Kubernetes 设计的开源配置管理工具,它能帮助用户定制 Kubernetes 对象,并以声明式的方式管理这些对象,而无需修改原始的 YAML 文件1。这意味着你可以保留应用和组件的基本设置,同时通过应用名为“补丁”的声明式 YAML 文档来覆盖默认设置,而不会更改原始文件。Kustomize 提供了一种声明式的方法,符合 Kubernetes 的哲学,并且能够以一种可重用、快速生成、易于调试和可伸缩的方式定制 Kubernetes 配置。 Kustomize 的主要功能包括: 声明式配置: 允许你以声明式的方式定义和管理 Kubernetes 对象,例如部署、Daemonsets、服务、ConfigMaps 等,为多个环境提供支持,而无需修改原始的 YAML 文件 配置层叠: 通过利用层叠来保留应用和组件的基本设置,并通过覆盖声明式的 YAML 文档(称为补丁)来选择性地覆盖默认设置 集成与独立使用: Kustomize 可以作为一个独立的工具使用,或者与 kubectl 结合使用。从 Kubernetes 1.14 版本开始,kubectl 也开始支持使用 kustomization 文件来管理 Kubernetes 对象 Kustomize 提供了一种自定义 Kubernetes 资源配置的解决方案,该方案摆脱了模板和 DSL。 版本关系 & kubectl 集成 要查找kubectl最新版本中嵌入的kustomize版本,请运行 kubectl version : $ kubectl version --short --client Client Version: v1....

October 31, 2023 · 5 分钟 · 1004 字 · 熊鑫伟,我

设计 OpenIM 使用 Harbor 构建企业镜像仓库

需求 OpenIM 提供了多种公共的镜像注册地址,比如说 aliyun, github, Docker hub ~ 阅读 https://github.com/openimsdk/open-im-server/blob/main/docs/conversions/images.md 获取更多的镜像构建指南。 大部分企业都会选择自己做镜像仓库,使用 Harbor 来搭建企业级的镜像仓库,将它集成 CICD Pipeline 流程中,最终替换 Docker Hub,进一步降低镜像存储的成本。 此外,在生产环境下,Harbor 一般都会开启 TLS,所以你还需要准备一个可用的域名。 中国的服务器使用域名,需要对域名进行备案 安装 Helm Helm,以及 集群的部署参考 https://github.com/openimsdk/open-im-server/tree/main/deployments 安装 Cert-manager 接下来我们安装 Cert-manager,它会为我们自动签发免费的 Let’s Encrypt HTTPS 证书,并在过期前自动续期。 首先,运行 helm repo add 命令添加官方 Helm 仓库。 $ helm repo add jetstack https://charts.jetstack.io 然后,运行 helm repo update 更新本地缓存。 $ helm repo update 接下来,运行 helm install 来安装 Cert-manager。 $ helm install cert-manager jetstack/cert-manager \ --namespace cert-manager \ --create-namespace \ --version v1....

October 25, 2023 · 2 分钟 · 350 字 · 熊鑫伟,我

自动化测试的学习(一)

云原生领域中GitHub开源Go项目的自动化测试实践与策略 介绍 作为 Github 上的 热门项目 OpenIM,如何在云原生时代中创造出价值,这是非常重要的,OpenIM 是一个优质的小团队,我们在自动化中并没有特别深入的见解。 使用 GitHub Actions 进行持续集成和持续交付 (CI/CD): GitHub Actions 提供了一个平台,可以自动构建和测试 Go 语言项目。通过配置 GitHub Actions 工作流,你可以在代码更改时自动运行测试,确保代码的质量和功能。 KubeVela 项目实践: KubeVela 是一个 Go 语言的云原生和开源项目,它展示了如何在云原生环境中组织 CI/CD 过程,包括自动化测试。KubeVela 使用声明性工作流来协调 CI/CD 过程,你可以参考 KubeVela 的 GitHub 仓库来理解和应用这些实践34[5](https://github.com/kubevela/workflow#:~:text=KubeVela Workflow is an open,engine in your own repository)。 云原生测试框架与工具: 在云原生开发中,合约测试(Contract Testing)是一种常见的测试实践,它确保服务间的通信符合预定义的 API 协议。例如,Cloud-Native Toolkit 中使用 Pact 进行合约测试。通过编写和集成测试,你可以验证服务间的通信是否符合预期6。 代码覆盖率检查: 在进行自动化测试时,检查代码覆盖率是一个好的实践。许多测试框架内置了代码覆盖率检查功能,可以配置它们来报告测试的代码覆盖率。例如,使用 SonarQube 工具来读取和报告代码覆盖率信息6。 利用开源工具和框架: 你可以利用开源工具和框架来进行测试,例如使用 Cypress 进行云原生应用的测试[7](https://dev....

October 14, 2023 · 17 分钟 · 3593 字 · 熊鑫伟,我

Kubernetes 控制平面 - Kubectl 详细讲解

Kubelet组件解析 理解 kubelet Kubelet组件运行在Node节点上,维持运行中的Pods以及提供kuberntes运行时环境,主要完成以下使命: 1.监视分配给该Node节点的pods 2.挂载pod所需要的volumes 3.下载pod的secret 4.通过docker/rkt来运行pod中的容器 5.周期的执行pod中为容器定义的liveness探针 6.上报pod的状态给系统的其他组件 7.上报Node的状态 kubelet 管理Pod的核心流程主要包括三个步骤。首先,kubelet获取Pod清单,可以通过文件、HTTP endpoint、API Server和HTTP server等方式获取。其次,节点管理主要是节点自注册和节点状态更新,Kubelet在启动时通过API Server注册节点信息,并定时向API Server发送节点新消息,API Server在接收到新消息后,将信息写入etcd。最后,Pod启动流程主要包括镜像拉取、容器启动、探针监控以及状态汇报等步骤。 kubelet是Kubernetes中的一个节点代理程序,负责维护本节点上Pod的生命周期。kubelet是Kubernetes中非常重要的组件之一,它在Kubernetes集群中扮演着非常重要的角色。kubelet可以在每个节点上运行,它监视分配给该Node节点的pods,并执行各种管理容器的操作,如挂载pod所需要的volumes、下载pod的secret等。 kubelet的核心流程主要包括获取Pod清单、节点管理和Pod启动流程。其中,获取Pod清单的方式包括文件、HTTP endpoint、API Server和HTTP server等方式。节点管理主要包括节点自注册和节点状态更新,而Pod启动流程主要包括镜像拉取、容器启动、探针监控以及状态汇报等步骤。 在节点管理方面,kubelet可以通过设置启动参数-register-node来确定是否向API Server注册自己。如果kubelet没有选择自注册模式,则需要用户自己配置Node资源信息,同时需要告知kubelet集群上的API Server的位置。在启动时,kubelet会通过API Server注册节点信息,并定时向API Server发送节点新消息,API Server在接收到新消息后,将信息写入etcd。 在Pod管理方面,kubelet可以通过文件、HTTP endpoint、API Server和HTTP server等方式获取Pod清单。文件方式主要用于static pod,而HTTP和API Server方式则是Kubernetes中常用的方式。HTTP server主要用于kubelet侦听HTTP请求,并响应简单的API以提交新的Pod清单。 在Pod启动流程方面,kubelet会执行各种管理容器的操作,包括镜像拉取、容器启动、探针监控以及状态汇报等步骤。镜像拉取是Pod启动过程中的一项重要工作,kubelet可以通过imageManager模块来管理镜像。容器启动是Pod启动过程的下一步,kubelet通过container runtime来启动容器。探针监控是Pod启动过程中一项非常重要的工作,kubelet会周期性地执行pod中为容器定义的liveness探针,并将结果上报给系统的其他组件。状态汇报是kubelet的一个重要功能,它会上报pod和Node的状态给系统的其他组件,以及上报节点自身的状态和资源使用情况给API Server。 总之,kubelet是Kubernetes中非常重要的组件之一,它负责维护本节点上Pod的生命周期,并执行各种管理容器的操作。kubelet的核心流程包括获取Pod清单、节点管理和Pod启动流程。在节点管理方面,kubelet通过设置启动参数-register-node来确定是否向API Server注册自己。在Pod管理方面,kubelet可以通过文件、HTTP endpoint、API Server和HTTP server等方式获取Pod清单。在Pod启动流程方面,kubelet会执行各种管理容器的操作,包括镜像拉取、容器启动、探针监控以及状态汇报等步骤。 kubelet 架构 每个节点上都运行一一个 kubelet 服务进程,默认监听 10250 端口。 接收并执行 master 发来的指令; 管理 Pod 及 Pod 中的容器; 每个 kubelet 进程会在 API Server上注册节点自身信息,定期向 master 节点汇报节点的资源使用情况,并通过 cAdvisor 监控节点和容器的资源。 kubelet 架构如下图所示:...

September 28, 2023 · 2 分钟 · 421 字 · Xinwei Xiong, Me

Kubernetes 控制平面 - 调度器

调度器 kube-scheduler 负责分配调度 Pod 到集群内的节点上,它监听 kube-apiserver,查询还未分配 Node 的 Pod,然后根据调度策略为这些 Pod 分配节点(更新 Pod 的 NodeName 字段)。 调度器需要充分考虑诸多的因素: 公平调度; 资源高效利用; QoS; affinity 和 anti-affinity; 数据本地化(data locality) ; 内部负载干扰(inter-workload interference) ; deadlines。 kube-scheduler 调度分为两个阶段, predicate 和 priority: predicate: 过滤不符合条件的节点; priority:优先级排序,选择优先级最高的节点。. predicate 策略 PodFitsHostPorts:检查是否有 Host Ports 冲突。 PodFitsPorts:同P odFitsHostPorts。 PodFitsResources:检查 Node 的资源是否充足,包括允许的Pod数量、CPU、内存、GPU个数以及其他的OpaqueIntResources。 HostName:检查 pod.Spec.NodeName 是否与候选节点一致。 MatchNodeSelector:检查候选节点的 pod.Spec.NodeSelector 是否匹配 NoVolumeZoneConflict:检查 volume zone 是否冲突。 MatchInterPodAffinity:检查是否匹配 Pod 的亲和性要求。 NoDiskConflict:检查是否存在 Volume 冲突,仅限于 GCE PD、AWS EBS、Ceph RBD以及 iSCSI。 PodToleratesNodeTaints:检查 Pod 是否容忍 Node Taints。 CheckNodeMemoryPressure:检查 Pod 是否可以调度到 MemoryPressure 的节点上。 CheckNodeDiskPressure:检查 Pod 是否可以调度到 DiskPressure 的节点上。 NoVolumeNodeConflict:检查节点是否满足 Pod 所引用的 Volume 的条件。 priority 策略 SelectorSpreadPriority:优先减少节点上属于同一个 Service 或 Replication Controller 的 Pod 数量。 尽量将同一个 rc 下的多个副本分散到不同节点,增加可用性 InterPodAffinityPriority:优先将Pod调度到相同的拓扑上(如同一个节点、Rack、Zone等)。 LeastRequestedPriority:优先调度到请求资源少的节点上。 BalancedResourceAllocation:优先平衡各节点的资源使用。 NodePreferAvoidPodsPriority:alpha....

September 28, 2023 · 4 分钟 · 668 字 · 熊鑫伟,我

Kubernetes 的 CNI,CRI,CSI 详解

容器运行时 容器运行时(Container Runtime),运行于Kubernetes (k8s)集群的每个节点中,负责容器的整 个生命周期。其中Docker是目前应用最广的。随着容器云的发展,越来越多的容器运行时涌现。为了 解决这些容器运行时和Kubernetes的集成问题,在Kubernetes 1.5版本中,社区推出了CRI ( Container Runtime Interface,容器运行时接口)以支持更多的容器运行时。 什么是 CRI CRI 是 Kubernetes 定义的一组 gRPC 服务。 kubelet 作为客户端,基于 gRPC 框架,通过 Socket 和容器运行时通信。它包括两类服务: 镜像服务(Image Service):提供下载、检查和删除镜像的远程程序调用; 运行时服务(Runtime Service):包含用于管理容器生命周期,以及与容器交互的调用(exec/ attach / port-forward)的远程程序调用。 运行时的层级 容器运行时可以分为高层和低层的运行时: Dockershime,containerd 和 CRI-O 都是遵循 CRI 的容器运行时,我们称之为 高级运行时。 OCI 定义了创建容器的格式和运行时的开源行业标准,包括 镜像规范(Image Specification) 和 容器运行时规范 (runtime specification) 镜像规范定义了 OCI 镜像标准,高层级运行时 将会下载一个 OCI 镜像,并且将它解压为 OCI 运行时文件系统包(file system bundle) 运行时规范描述了如何从 OCI 运行时文件系统包运行容器程序。并且定义它的配置,运行环境和生命周期。如何为新的容器设置命名空间(namespace)和控制组(cgroup) ,以及挂载根文件系统(rootfs)等等操作,都是在这里定义的。它的一个参考实现是 runc,我们称其为 低层级运行时(Low-level Runtime) 高层级运行时(High-level Runtime):主要包括 Docker,containerd 和 CRI-O 低层级运行时(Low-level Runtime):包含了 runc, kata,以及 gVisor。 低层运行时 kata 和 gVisor 都还处于小规模落地或者实验阶段,其生态成熟度和使用案例都比较欠缺,所以除非有特殊的需求,否则 runc 几乎是必然的选择。因此在对容器运行时的选择上,主要是聚焦于上层运行时的选择。...

September 28, 2023 · 11 分钟 · 2200 字 · 熊鑫伟,我