首页 文章 精选 留言 我的

精选列表

搜索[字节级]，共10000篇文章
优秀的个人博客,低调大师

Rancher Prime 2.7：向企业级容器管理平台深度进化

一直以来，在众多Kubernetes开源管理平台选项中，Rancher深受社区用户的青睐。 SUSE在确保开源产品持续灵活演进的同时，也致力于满足企业用户的使用场景，为此SUSE正式推出Rancher Prime。Rancher Prime是Rancher的一种分发版，核心功能代码均来自Rancher社区版，但更加重视安全方面的建设，并面向企业用户强化了相关功能和服务。 Rancher Prime为企业用户提供可信的镜像仓库，以获取核心安装介质。SUSE不仅优化加速了国内的下载链路，还将持续治理各个依赖组件镜像的CVE，从容器镜像角度提升软件供应链安全。这得益于SUSE在Linux和容器领域长期的工程化积累，几乎所有的Rancher Prime组件都基于SUSE BCI（Base Container Image）进行构建。BCI提供了标准的Linux Container Image和Language Container Image，并在镜像源头进行安全治理。在容器运行时方面，更有SUSE NeuVector进行产品级的整合，进一步提升Rancher Prime的综合安全能力。 Rancher Prime引入了UI Extension功能，提供了灵活的UI扩展方式。企业用户通常会有一些UI扩展需求，但又不希望影响其跟随Rancher主线版本进行演进，UI Extension机制可以很好地解决这一问题。 用户可以更新Extension的版本，并应用在不同阶段的Rancher Prime版本上，让Kubernetes管理平台和其他内部服务更好地融合，统一核心功能与扩展功能的操作体验。 SUSE中国一直奉行产品本地化的治理原则，面向国内企业的应用场景，Rancher Prime也更具优势。不仅增加了高性能容器网络、审计日志、GPU管理、Harbor对接等功能，在生态兼容方面也有很多增强。 对Native Cloud的支持。海外用户主要聚焦于AWS、Azure、GCP的整合使用，而Rancher Prime除了扩展这些公有云的中国区域支持外，还会额外对阿里云、腾讯云以及华为云进行支持。这并非简单的导入管理，而是对公有云托管集群的全生命周期支持。用户可以在Rancher Prime的UI上，统一管理来自不同云厂商的Kubernetes，包括集群的创建和销毁，以及节点组编辑和集群升级等操作。 对国产OS的支持。SUSE中国团队与欧拉开源社区建立了长期合作关系，并积极进行产品落地。在操作系统的支持矩阵上，Rancher Prime 引入了对openEuler Linux的支持，并将其列入长期支持列表中。Rancher Prime 2.7已完成了对openEuler 22.03和22.03 SP1版本的验证。 对ARM体系的支持。ARM在全球的部署比例正在攀升，公有云的ARM化趋势非常明显，这些变化逐步推动企业的部署环境向ARM转变。Rancher Prime 已经将 ARM适配作为持续工程化的一部分，并对国内主流ARM平台进行兼容，包括Kunpeng、Yitian、Ampera等处理器。
2023-02-08
优秀的个人博客,低调大师

iDempiere 企业级 ERP/CRM/MFG/SCM/POS 10 Peace 发布

iDempiere 10 Peace于 2022 年 12 月 26 日发布。 从2012年10月31日发布1.0a至今，iDempiere已经陪伴我们走过了整整10个年头，在这个重要的里程碑上，官方把版本10命名为和平。感谢如此多元化的国际社区，感谢那些为iDempiere的强大、倾情奉献的人们。 具体请参看官方通知：https://www.idempiere.org/2022/12/26/idempiere-10-peace/ 这里罗列几个相对重要的更新： 仪表盘的重大改进，让我们的桌面更加现代化 使用拖拽方式上传文件 – 这是一个简单的功能，但却是一个痛点，如今终于对应好了 日期范围选择组件的更新 其他更新 笔者比较喜欢的更新是数据库连接池由c3p0更新为HikariCP 具体的功能更新内容 https://wiki.idempiere.org/en/Category:New_Features_w10 软件发布履历 2021 年 12 月 27 日发布了 9 Horizon 2020 年 12 月 23 日发布了 8.2 Phong 2019 年 11 月 22 日发布了 7.1 2019 年 01 月 05 日发布了 6.2 2018 年 11 月 04 日发布了 6.1 2017 年 10 月 31 日发布了 5.1 2016 年 10 月 31 日发布了 4.1 2015 年 10 月 31 日发布了 3.1 2014 年 10 月 31 日发布了 2.1 2013 年 10 月 31 日发布了 2.0 2013 年 06 月 27 日发布了 1.0c 2013 年 04 月 24 日发布了 1.0b 2012 年 10 月 31 日发布了 1.0a
2022-12-28
优秀的个人博客,低调大师

Easy-Es —— 傻瓜级 ElasticSearch 搜索引擎 ORM 框架

为简化开发工作、提高生产效率而生 Easy-Es是一款简化 ElasticSearch 搜索引擎操作的开源框架，全自动智能索引托管。 目前功能丰富度和易用度及性能已全面领先SpringData-Elasticsearch. 简化CRUD及其它高阶操作,可以更好的帮助开发者减轻开发负担 底层采用Es官方提供的RestHighLevelClient,保证其原生性能及拓展性. 项目推广初期,还望大家能够不吝点点三连:⭐Star,👀Watch,fork📌 支持一下国产开源,让更多人看到和使用本项目,非常感谢! 优点 | Advantages 全自动索引托管:全球开源首创的索引托管模式,开发者无需关心索引的创建更新及数据迁移等繁琐步骤,索引全生命周期皆可托管给框架,由框架自动完成,过程零停机,用户无感知,彻底解放开发者 屏蔽语言差异:开发者只需要会MySQL语法即可使用Es 代码量极少:与直接使用RestHighLevelClient相比,相同的查询平均可以节3-8倍左右的代码量 零魔法值:字段名称直接从实体中获取,无需输入字段名称字符串这种魔法值 零额外学习成本:开发者只要会国内最受欢迎的Mybatis-Plus语法,即可无缝迁移至Easy-Es 降低开发者门槛:即便是只了解ES基础的初学者也可以轻松驾驭ES完成绝大多数需求的开发 功能强大:支持MySQL的几乎全部功能,且对ES特有的分词,权重,高亮,嵌套,地理位置Geo,Ip地址查询等功能都支持 安全可靠:墨菲安全扫描零风险,且代码单元测试综合覆盖率高达95%以上. 完善的中英文文档:提供了中英文双语操作文档,文档全面可靠,帮助您节省更多时间 ... 对比 | Compare 需求:查询出文档标题为 "传统功夫"且作者为"码保国"的所有文档 //使用Easy-Es仅需1行代码即可完成查询 List<Document>documents=documentMapper.selectList(EsWrappers.lambdaQuery(Document.class).eq(Document::getTitle,"传统功夫").eq(Document::getCreator,"码保国")); //传统方式,直接用RestHighLevelClient进行查询需要19行代码,还不包含下划线转驼峰,自定义字段处理及_id处理等代码 StringindexName="document"; SearchRequestsearchRequest=newSearchRequest(indexName); BoolQueryBuilderboolQueryBuilder=QueryBuilders.boolQuery(); TermQueryBuildertitleTerm=QueryBuilders.termQuery("title","传统功夫"); TermsQueryBuildercreatorTerm=QueryBuilders.termsQuery("creator","码保国"); boolQueryBuilder.must(titleTerm); boolQueryBuilder.must(creatorTerm); SearchSourceBuildersearchSourceBuilder=newSearchSourceBuilder(); searchSourceBuilder.query(boolQueryBuilder); searchRequest.source(searchSourceBuilder); try{ SearchResponsesearchResponse=restHighLevelClient.search(searchRequest,RequestOptions.DEFAULT); List<Document>documents=Optional.ofNullable(searchResponse) .map(SearchResponse::getHits) .map(SearchHits::getHits) .map(hit->Documentdocument=JSON.parseObject(hit.getSourceAsString(),Document.class)) .collect(Collectors.toList()); }catch(IOExceptione){ e.printStackTrace(); } 以上只是简单查询演示,实际使用场景越复杂,效果就越好,平均可节省至少3-8倍代码量 传统功夫,点到为止! 上述功能仅供演示,仅为Easy-Es支持功能的冰山一角,Easy-Es就是这么Easy到不讲武德💪,不用的请耗子尾汁. 官网地址 | Official website easy-es官网https://easy-es.cn/ 开源社区dromarahttps://dromara.org/ 开源社区码云首页https://gitee.com/dromara/ Tip:官网是vue单页面应用，首次访问加载可能比较慢🐢，主公们请耐心等待一下，后续会很快🏹，如偶遇打不开可刷新多尝试几次. 架构 | Architecture 相关链接 | Links Switch To English 功能示例 Springboot集成Demo Latest Version: Maven: <dependency> <groupId>cn.easy-es</groupId> <artifactId>easy-es-boot-starter</artifactId> <version>Latest Version</version> </dependency> Gradle: compile group: 'cn.easy-es', name: 'easy-es-boot-starter', version: 'Latest Version' 其他开源项目 | Other Project 健身计划一键生成系统 期望 | Futures 欢迎提出更好的意见，帮助完善 Easy-Es 版权 | License Apache License 2.0 捐赠 | Donate 捐赠记录,感谢你们的支持！ 您的支持是鼓励我们前行的动力，无论金额多少都足够表达您这份心意。 如果您愿意捐赠本项目,推荐直接在右下方通过Gitee直接捐赠. 关注我 | About Me CSDN博客
2022-09-02
优秀的个人博客,低调大师

支持生产级共享文件存储，Curve v2.3.0 版本发布！

为了能让用户使用到稳定可靠的 Curve 存储系统，我们在 v2.2.0 版本的基础上，进行了全方位的常规功能测试、混沌测试、性能测试、压力测试、长期稳定性测试等工作，并且将 CurveFS 文件存储上线到网易内部业务生产环境，经过一段时间的稳定运行考验后，我们发布了 v2.3.0 版本。 版本地址： https://github.com/opencurve/curve/releases/tag/v2.3.0-rc0 版本部署手册： https://github.com/opencurve/curveadm/wiki‍ Curve 是云原生计算基金会 (CNCF) Sandbox 项目，是网易主导自研和开源的高性能、易运维、云原生的分布式存储系统，由块存储 CurveBS 和文件系统 CurveFS 两部分组成。 重点增强 v2.3.0 版本相比上个版本主要新增了共享文件存储服务能力，另外块存储服务方面也有如下增强： io路径上去掉一次io落盘，提升io性能，在4k随机写场景下有100%性能提升①； 在块设备层面支持卷的读写权限控制②； 与 CurveFS-v0.1.0 版比较，v2.3.0 在共享文件存储服务方面新增了如下重要能力： 功能 支持多挂载 支持 close-to-open 数据一致性 支持 CurveBS 后端 支持元数据 rocksdb 持久化 支持 rename 事务化 支持元数据集群自动化调度 性能 open、du、stat、ls 等元数据操作性能优化 s3 后端缓存满的情况下数据性能优化 当前版本数据性能③ 当前版本元数据性能④ 监控 全链路 metric 完善 提供 grafana+promethues 一件部署脚本 📢release Notes： https://github.com/opencurve/curve/blob/master/CHANGELOG-2.3.md 适用场景 我们基于 v2.3.0 版本在网易内部与多个业务团队进行了联合测试，也与竞品进行了对比测试，Curve 表现较好，已有部分业务在生产环境落地使用，下面简单介绍下相关业务的测试场景和 Curve 表现，同时也欢迎广大 Curve 社区小伙伴探索更多适用场景。 AI 训练 场景简述：受限于硬件条件，我们基于 CPU 做了简单的单训练节点对比测试。使用 ImageNet-2012 数据集，resnet50 模型，商汤的训练框架⑤进行训练，分别在本地盘，CurveFS，CephFS 上做了对比测试。 测试对比数据：取第一个 epoch 中1000轮 iter 的训练时间做对比，数据如下： 文件系统 本地文件系统ext4 CurveFS CephFS 1000轮iter的训练时间 37mins 54mins 127mins CurveFS 得益于缓存盘的优势，性能优于 CephFS，但由于当前的 lru 缓存策略，CurveFS 的性能低于本地盘。 下一步计划：AI 场景用户涉及到的 IO 流程主要体现在：数据集制作（数据导入）、数据集元数据信息提取（ls -R获取元数据信息）、数据集训练（写少读多）。后续 CurveFS 会在这几个方面做针对性的优化： 提高小文件并发写的吞吐； 优化元数据操作 ls-R 的性能； 支持目录、文件的预读功能； 数据备份 场景简述：网易内部有大量的 GitLab 代码库、数据库等的数据备份需求，此类场景的需求非常简单，业务最关注的是单位存储成本，对 IOPS、时延等性能要求不高，对大文件写入读取的吞吐带宽比较关注，对数据可靠性要求比较高。 对象存储通常有标准、低频、归档、冷归档等存储类型，费用依次降低，但归档和冷归档存储中的数据需要先解冻才能访问。因此我们将业务备份的数据保存到对象存储系统的低频存储中，进一步节省备份数据的存储成本。 测试对比数据：原有的备份系统通常是 RAID10 + 运维自建 NFS 服务方案，RAID10 是2倍的数据冗余，低频存储通常使用 EC 纠删码存储数据，可以将备份数据的冗余度从2倍降低到1.2倍左右，使用 Curve 共享文件存储系统可节省40%的存储空间，同时也免去了业务自行运维 NFS 的麻烦。 下一步计划： 继续优化大文件吞吐； 集团内部业务推广； 支持将访问频次极低的数据存储到归档存储中，进一步降低备份数据的存储成本； ES 冷数据存储 场景简述：据了解，由于 ES 的历史数据量通常很大，占用存储资源较多，为了节约存储成本，原有的 ES 冷数存储方案有2种： 将n月以上的冷数据导出备份到 RAID 盘上（一般数据冗余比例为2）；历史数据查询流程很长，要先将备份数据读取上来进行恢复后才能查询； 另外一种方案是 ES 计算节点和存储节点混部，ES 应用层利用数据生命周期管理功能对冷数据进行不同的存储介质和副本数配置，但一般存储容量是瓶颈导致服务器浪费严重； 而使用 Curve 共享文件存储作为保存 elastic search 的冷数据，数据存储在集团内部对象存储服务中，使用的是低频存储形态（冗余副本比例为1.2）以便进一步降低单位存储成本。ES 节点上使用 curve-fuse 挂载文件系统（也可配置一块本地缓存盘进一步提升吞吐）即可开箱即用，不再需要考虑备份数据的恢复、本地文件系统容量问题和运维问题，只需要最小规模的计算节点即可（并且可以随时弹性伸缩），非常的方便。 测试对比数据：性能指标完全可以满足冷数据需求，因此重点关注成本对比情况，经测算，第一种部署方案情况下可以节省40%的存储空间，同时也免去了业务自行运维存储系统的麻烦；第二种方案则可以节省大量的服务器资源和运维人力，成本节省更明显，以我们对接的业务为例，共800TB冷数据，2副本，单盘8T，每台服务器10块盘，考虑到集群水位和硬盘实际可用空间，共需要28台服务器，而使用Curve共享存储系统后，可以节约成本超100万（包含所有Curve所需资源和ES冷数据所需计算节点资源）。 下一步计划： 继续优化小文件吞吐 性能测试 性能测试数据 通过测试数据⑥可以看出，Curve 共享文件存储+对象存储数据后端场景下的性能已经处于开源存储系统领先水平，后续版本我们还会继续优化，为 Curve 社区提供更高性能的云原生存储系统。 性能相关参数配置 配置项 所属配置文件/进程 说明 fuseClient.enableMultiMountPointRename curve-fuse 进程 curvefs/conf/client.conf 在不需要对同一文件系统多挂载并发rename场景可以设置该配置项为false来提高元数据性能，默认为false。 braft.raft_sync curvefs-metaserver 进程 curvefs/conf/metaserver.conf 每次写raft wal 是否sync，默认为false，只在close时sync，用于保证更高的元数据性能。但在三副本同时掉电的情况下存在数据丢失的可能，若要保证该情况下的数据可靠性则需要设置为true。 s3.async_thread_num;s3.max_connections； curve-fuse 进程 curvefs/conf/client.conf AWS S3 C++ SDK使用这两个参数来实现多线程，但是线程是同步的，如果每个请求后端处理时间为10ms，那么一个线程1秒最多可以处理100个请求，n个线程最多可处理100*n个请求，调大这两个参数可以提升吞吐带宽（两个参数值配置为相同值即可） 其他重要配置 配置项 所属配置文件/进程 说明 fuseClient.cto curve-fuse 进程 curvefs/conf/client.conf 在多挂载情况下，默认为false。请根据业务需要确定是否开启cto。 diskCache.maxUsableSpaceBytes curve-fuse 进程 curvefs/conf/client.conf 缓存盘大小，默认200GB。请根据缓存盘的实际大小进行配置。 enableSumInDir curvefs 工具 curvefs/conf/tools.conf 统计xattr中的信息，可以加速du。该选项打开后不支持硬链接。 致谢 感谢以下 Curve 开源社区同伴为 Curve v2系列版本作出的贡献（按字母序排列）： baijiaruo chengyi01 cw123 SiKu fan h0hmj Hanqing,Wu hzwuhongsong ilixiaocui locallocal wanghai01 Wangpan Wine93 xuchaojie yfxu YunhuiChen yuxubinchen wavemomo YhhHaa 我们将为以上小伙伴提供 Curve 社区周边大礼包～也欢迎更多小伙伴参与到 Curve 开源社区，不仅是提交代码，还可以讨论需求、交流建议、反馈问题、完善文档、分享落地实践等。 后续版本规划 后续版本我们将持续提升 Curve 块存储和共享文件存储性能，并增强 Curve 共享文件存储的功能，下个大版本规划的主要功能有： 块存储：支持 NVMe 场景下的 SPDK 能力，升级替换块存储的 ext4 引擎； 共享文件存储： 支持数据预热功能； 支持使用 Curve 块存储集群作为高性能数据存储后端并支持生产环境使用； 支持冷热数据分层存储和数据生命周期管理； 支持文件回收站、文件系统配额功能； 参考①： https://github.com/opencurve/curve/blob/master/docs/cn/CurveBS%E5%86%99%E6%97%B6%E5%BB%B6%E4%BC%98%E5%8C%96.md 参考②： https://github.com/opencurve/curve/commit/5f5220c618aa726c777dddf94a32bef8fd5f0dcd 参考③： https://github.com/opencurve/curve/blob/master/CHANGELOG-2.3.md#data-performance 参考④： https://github.com/opencurve/curve/blob/master/CHANGELOG-2.3.md#metadata-performance 参考⑤： https://github.com/open-mmlab/mmclassification 参考⑥： https://github.com/opencurve/curve/blob/master/CHANGELOG-2.3.md GitHub：https://github.com/opencurve/curve 官网：https://opencurve.io/ 用户论坛：https://ask.opencurve.io/
2022-07-22
优秀的个人博客,低调大师

ShopXO 企业级免费开源商城 v2.2.7 正式发布

更新日志 1. 新增地址信息智能识别和地理位置选择识别（智能工具插件） 2. 新增系统类型，不同终端独立用户，可辨别客户端类型 3. 页面设计支持下载、导入、同步首页、商店在线安装 4. 导航添加支持选择页面设计 5. 移除老版本小程序源代码 6. 支付及售后优化 7. 支付日志记录，输入参数使用原始参数 8. 支付配置读取优化，统一方法 9. 小程序一键获取手机和地址导入增加可单独选择 10. web端联动地址初始化分离 11. 门店插件仓库逻辑优化、新增自动脚本 12. 多商户插件细节优化、页面设计支持同步首页 13. uniapp主题细节优化+bug修复 14. 客服插件细节优化+bug修复 15. 主题切换插件支持参数自动识别 16. 新增分身插件、独立小程序和支付配置、用户端商品数据限制 17. 地区数据库更新 效果图片（内置多种配色） 可视化DIY拖拽装修展示 PC端展示 后台管理展示
2022-04-25
优秀的个人博客,低调大师

ShopXO 企业级免费开源商城 v2.2.6 正式发布

更新日志 1. 用户管理新增邀请人信息 2. 新增公共jshttp变量 3. 积分赠送脚本优化 4. url生成优化、新增站点域名配置 5. 短信和邮箱驱动优化 6. 下单0元校验逻辑优化 7. 订单售后审核钩子新增数据id 8. 购物车列表数据处理分离+css细节优化 9. 新增小程序订阅消息发送方法 10. 用户地址新增距离显示字段和订单发货售后提醒 11. 新增客服插件 12. 多商户适配客服插件+细节优化 13. 门店新增下单距离限制及细节优化 效果图片（内置多种配色） 可视化DIY拖拽装修展示 PC端展示 后台管理展示
2022-04-07
优秀的个人博客,低调大师

ShopXO 企业级免费开源商城 v2.2.5 正式发布

更新日志 1. 物流插件新增菜鸟调试接口 2. 系统购买商品赠送积分优化、增加脚本按周期发放 3. 用户管理新增锁定积分修改 4. 分页组件新增提示信息 5. 下单支付优化 6. 可视化拖拽设计模块新增门店和博客 7. 新增挂账支付方式 8. 删除插件会删除附件修复 9. 动态列表组件支持模块引入单独配置 10. 去除微信圈子组件 11. 图片验证码精度优化 12. 多商户插件商家中心UI全新优化、独立后台、独立登录页 13. 门店支持独立登录页、扫描录单、新增扩展模块（货物寄存、挂账支付） 14. 智能工具插件新增商品详情信息提示 15. 支付宝+百度支付插件方法更新适配php8 效果图片（内置多种配色） 可视化DIY拖拽装修展示 PC端展示 后台管理展示
2022-03-10
优秀的个人博客,低调大师

Next.js 12.1 正式发布，企业级 Web 应用框架

Next.js 12.1 已正式发布。 新特性概览 按需使用的 ISR (Beta)：支持即时使用getStaticProps重新验证页面 扩展对 SWC 的支持：引入styled-components和 Relay 等功能 引入next/jest插件：使用 SWC 实现零配置支持 Jest 通过 SWC (RC) 提供更快的压缩：比 Terser 快 7 倍的压缩速度 优化自托管功能：减小 Docker 镜像体积约 80% React 18 & Server Components (Alpha)：优化稳定性和支持情况 按需使用的 ISR (Beta) ISR 是 Next.js 9.5 引入的功能，本次的更新提供了按需使用的特性，开发者可按需手动清除特定页面的 Next.js 缓存。 // pages/api/revalidate.js export default async function handler(req, res) { // Check for secret to confirm this is a valid request if (req.query.secret !== process.env.MY_SECRET_TOKEN) { return res.status(401).json({ message: 'Invalid token' }) } try { await res.unstable_revalidate('/path-to-revalidate') return res.json({ revalidated: true }) } catch (err) { // If there was an error, Next.js will continue // to show the last successfully generated page return res.status(500).send('Error revalidating') } } 零配置 Jest 插件 Next.js 现已支持自动配置 Jest，使用基于 Rust 的 Next.js 编译器来转换文件，包括： 自动模拟样式表（.css,.module.css和.scss变体），以及图像导入 将.env加载到process.env 忽略测试解析和转换的node_modules 忽略测试解析的.next Loadingnext.config.jsfor flags that enable Next.js compiler transforms 优化自托管功能 Next.js 现在支持自动创建standalone文件夹，该文件夹仅复制生产部署所需的文件。这使得自托管 Next.js 应用程序的Docker 映像缩小了约 80% 。 详情查看 release note。
2022-02-18
优秀的个人博客,低调大师

ShopXO 企业级免费开源商城 v2.2.4 正式发布

更新日志 1. 商品url地址优化 2. 商品购买类型判断优化 3. 用户管理列表新增邀请人id 4. 后台用户新增及更新调用统一方法 5. 优化0元订单无需选择支付方式 6. 底层js类库更新+框架底层更新 7. 小程序商品详情页支持返回指定操作 8. 后台统计数据优化 9. 商品保存规格判断错误修复 10. 文章优化 11. 分页组件xss修复 12. excel库更新为Spreadsheet库支持更高版本、效率更高、更稳定 13. 动态数据列表处理模块优化+支持Ym年月选择条件 14. 订单商品类型校验错误修复 15. 日历组件更新到最新版本 16. 表单验证器优化 17. 浏览文件库存配置添加提示、下单商品新增扩展内容 18. 订单售后商品异常影响优化 19. 新增支付宝和微信付款码支付（一般用于线下扫用户付款码进行支付） 20. 新增插件权限单独配置管理 21. 新增电子营业执照亮证 22. 新增web端PC访问关闭开关 23. 新增json头信息系统出错输出 24. 门店2.0.0版本开发支持大多数O2O实体店运营、线上线下完美结合 效果图片（内置多种配色） 可视化DIY拖拽装修展示 PC端展示 后台管理展示
2022-02-16
优秀的个人博客,低调大师

Cilium 1.11 发布，带来内核级服务网格、拓扑感知路由....

Cilium 项目已逐渐成为万众瞩目之星，我们很自豪能够成为该项目的核心人员。几天前，我们发布了具有诸多新功能的 Cilium 1.11 版本，这是一个令人兴奋的版本。诸多新功能中也包括了万众期待的 Cilium Service Mesh 的 Beta 版本。在本篇文章中，我们将深入探讨其中的部分新功能。 Service Mesh 测试版本（Beta） 在探讨 1.11 版本之前，让我们先了解一下 Cilium 社区宣布的 Service Mesh 的新功能。 基于 eBPF 技术的 Service Mesh （Beta）版本： 定义了新的服务网格能力，这包括 L7 流量管理和负载均衡、TLS 终止、金丝雀发布、追踪等诸多能力。 集成了 Kubernetes Ingress (Beta) 功能： 通过将 eBPF 和 Envoy 的强势联合，实现了对 Kubernetes Ingress 的支持。 Cilium 网站的一篇文章详细介绍了 Service Mesh Beta 版本[1]，其中也包括了如何参与到该功能的开发。当前，这些 Beta 功能是 Cilium 项目中的一部分，在单独分支[2]进行开发，可独立进行测试、反馈和修改，我们期待在 2022 年初 Cilium 1.12 版本发布之前合入到 Cilium 主分支。 Cilium 1.11 Cilium 1.11 版本包括了 Kubernetes 额外功能，及单独部署的负载均衡器。 OpenTelemetry 支持：Hubble L3-L7 可观测性数据支持 OpenTelemetry 跟踪和度量（Metrics）格式的导出。 (更多详情[3]) Kubernetes APIServer 策略匹配：新的策略实体用于简单方便地创建进出 Kubernetes API Server 流量的策略模型。 (更多详情[4]) 拓扑感知的路由：增强负载均衡能力，基于拓扑感知将流量路由到最近的端点，或保持在同一个地区（Region）内。 (更多详情[5]) BGP 宣告 Pod CIDR：使用 BGP 在网络中宣告 Pod CIDR 的 IP 路由。（更多详情[6]) 服务后端流量的优雅终止：支持优雅的连接终止，通过负载均衡向终止的 Pod 发送的流量可以正常处理后终止。(更多详情[7]) 主机防火墙稳定版：主机防火墙功能已升级为生产可用的稳定版本。（更多详情[8]） 提高负载均衡器扩展性：Cilium 负载均衡支持超过 64K 的后端端点。(更多详情[9]) 提高负载均衡器设备支持：负载均衡的加速 XDP 快速路径现在支持 bond 设备（更多详情[10]) 同时，可更普遍地用于多设备设置。 (更多详情[11])。 Kube-Proxy-replacement 支持 istio：Cilium 的 kube-proxy 替代模式与 Istio sidecar 部署模式兼容。 (更多详情[12]) Egress 出口网关的优化：Egress 网关能力增强，支持其他数据路径模式。 (更多详情[13]) 托管 IPv4/IPv6 邻居发现：对 Linux 内核和 Cilium 负载均衡器进行了扩展，删除了其内部 ARP 库，将 IPv4 的下一跳发现以及现在的 IPv6 节点委托给内核管理。 (更多详情[14]) 基于路由的设备检测：外部网络设备基于路由的自动检测，以提高 Cilium 多设备设置的用户体验。 (更多详情[15]) Kubernetes Cgroup 增强：在 cgroup v2 模式下集成了 Cilium 的 kube-proxy-replacement 功能，同时，对 cgroup v1/v2 混合模式下的 Linux 内核进行了增强。 (更多详情[16]) Cilium Endpoint Slices：Cilium 基于 CRD 模式能够更加高效地与 Kubernetes 的控制平面交互，并且不需要专有 ETCD 实例，节点也可扩展到 1000+。 (更多详情[17]) 集成 Mirantis Kubernetes 引擎：支持 Mirantis Kubernetes 引擎。 (更多详情[18]) 什么是 Cilium ？ Cilium 是一个开源软件，为基于 Kubernetes 的 Linux 容器管理平台上部署的服务，透明地提供服务间的网络和 API 连接及安全。 Cilium 底层是基于 Linux 内核的新技术 eBPF，可以在 Linux 系统中动态注入强大的安全性、可见性和网络控制逻辑。 Cilium 基于 eBPF 提供了多集群路由、替代 kube-proxy 实现负载均衡、透明加密以及网络和服务安全等诸多功能。除了提供传统的网络安全之外，eBPF 的灵活性还支持应用协议和 DNS 请求 / 响应安全。同时，Cilium 与 Envoy 紧密集成，提供了基于 Go 的扩展框架。因为 eBPF 运行在 Linux 内核中，所以应用所有 Cilium 功能，无需对应用程序代码或容器配置进行任何更改。 请参阅 [Cilium 简介] 部分，了解 Cilium 更详细的介绍。 OpenTelemetry 支持 Jaeger UI 显示 Hubble 数据流 新版本增加了对 OpenTelemetry[19] 的支持。 OpenTelemetry 是一个 CNCF 项目，定义了遥测协议和数据格式，涵盖了分布式跟踪、指标和日志。该项目提供了 SDK 和运行在 Kubernetes 上的收集器。通常，应用程序直接检测暴露 OpenTelemetry 数据，这种检测最常使用 OpenTelemetry SDK 在应用程序内实现。OpenTelemetry 收集器用于从集群中的各种应用程序收集数据，并将其发送到一个或多个后端。CNCF 项目 Jaeger[20] 是可用于存储和呈现跟踪数据的后端之一。 支持 OpenTelemetry 的 Hubble 适配器[21]是一个附加组件，可以部署到运行 Cilium 的集群上（Cilium 版本最好是 1.11，当然也应该适用于旧版本）。该适配器是一个嵌入了 Hubble 接收器的 OpenTelemetry 收集器，我们推荐使用 OpenTelemetry Operator[22] 进行部署（详见用户指南[23]）。Hubble 适配器从 Hubble 读取流量数据，并将其转换为跟踪和日志数据。 Hubble 适配器添加到支持 OpenTelemetry 的集群中，可对网络事件和应用级别遥测提供有价值的可观测性。当前版本通过 OpenTelemetry SDK 提供了 HTTP 流量和 spans 的关联。 感知拓扑的负载均衡 感知拓扑的负载均衡 Kubernetes 集群在跨多数据中心或可用区部署是很常见的。这不仅带来了高可用性好处，而且也带来了一些操作上的复杂性。 目前为止，Kubernetes 还没有一个内置的结构，可以基于拓扑级别描述 Kubernetes service 端点的位置。这意味着，Kubernetes 节点基于服务负载均衡决策选择的 service 端点，可能与请求服务的客户在不同的可用区。 这种场景下会带来诸多副作用，可能是云服务费用增加，通常由于流量跨越多个可用区，云提供商会额外收取费用，或请求延迟增加。更广泛地说，我们需要根据拓扑结构定义 service 端点的位置， 例如，服务流量应该在同一节点（node）、同一机架（rack）、同一故障分区（zone）、同一故障地区（region）、同云提供商的端点之间进行负载均衡。 Kubernetes v1.21 引入了一个称为拓扑感知路由[24]的功能来解决这个限制。通过将 service.kubernetes.io/topology-aware-hints 注解被设置为 auto ，在 service 的 EndpointSlice 对象中设置端点提示，提示端点运行的分区。分区名从节点的 topology.kubernetes.io/zone 标签获取。 如果两个节点的分区标签值相同，则被认为处于同一拓扑级别。 该提示会被 Cilium 的 kube-proxy 替代来处理，并会根据 EndpointSlice 控制器设置的提示来过滤路由的端点，让负载均衡器优先选择同一分区的端点。 该 Kubernetes 功能目前处于 Alpha 阶段，因此需要使用 –feature-gate 启用。更多信息请参考官方文档[25]。 Kubernetes APIServer 策略匹配 Hubble UI 显示 apiserver 网络策略 托管 Kubernetes 环境，如 GKE、EKS 和 AKS 上，kube-apiserver 的 IP 地址是不透明的。在以前的 Cilium 版本中，没有提供正规的方式来编写 Cilium 网络策略，定义对 kube-apiserver 的访问控制。这涉及一些实现细节，如：Cilium 安全身份分配，kube-apiserver 是部署在集群内，还是部署在集群外。 为了解决这个问题，Cilium 1.11 增加了新功能，为用户提供一种方法，允许使用专用策略对象定义进出 apiserver 流量的访问控制。该功能的底层是实体选择器，能够解析预留的 kube-apiserver 标签含义， 并可自动应用在与 kube-apiserver 关联的 IP 地址上。 安全团队将对这个新功能特别感兴趣，因为它提供了一个简单的方法来定义对 pod 的 Cilium 网络策略，允许或禁止访问 kube-apiserver。下面 CiliumNetworkPolicy 策略片段定义了 kube-system 命名空间内的所有 Cilium 端点允许访问 kube-apiserver， 除此之外的所有 Cilium 端点禁止访问 kube-apiserver。 apiVersion: cilium.io/v2 kind: CiliumNetworkPolicy metadata: name: allow-to-apiserver namespace: kube-system spec: endpointSelector: {} egress: - toEntities: - kube-apiserver BGP 宣告 Pod CIDR BGP 宣告 Pod CIDR 的示意图 随着私有 Kubernetes 环境的日益关注，我们希望与现存的数据中心网络基础设施很好地集成，它们通常是基于 BGP 协议进行路由分发的。 在上一个版本中，Cilium agent 已经开始集成了 BGP 协议, 可以通过 BGP 向 BGP 路由器发布负载均衡器的 service 的 VIP[26]。 现在，Cilium 1.11 版本还引入了通过 BGP 宣告 Kubernetes Pod 子网的能力。Cilium 可与任何下游互联的 BGP 基础设施创建一个 BGP 对等体，并通告分配的 Pod IP 地址的子网。这样下游基础设施就可以按照合适方式来分发这些路由，以使数据中心能够通过各种私有 / 公共下一跳路由到 Pod 子网。 要开始使用此功能，运行 Cilium 的 Kubernetes 节点需要读取 BGP 的 ConfigMap 设置： apiVersion: v1 kind: ConfigMap metadata: name: bgp-config namespace: kube-system data: config.yaml: | peers: - peer-address: 192.168.1.11 peer-asn: 64512 my-asn: 64512 同时，Cilium 应该使用以下参数进行安装 ： $ cilium install \ --config="bgp-announce-pod-cidr=true" Cilium 安装完后，它将会向 BGP 路由器发布 Pod CIDR 范围，即 192.168.1.11。 下面是最近的 Cilium eCHO episode[27] 完整演示视频。 https://www.youtube.com/watch?v=nsfbFUO8eu4 如果想了解更多，如：如何为 Kubernetes service 配置 LoadBalancer IP 宣告，如何通过 BGP 发布节点的 Pod CIDR 范围，请参见 docs.cilium.io[28]。 托管 IPv4/IPv6 邻居发现 托管邻居发现的示意图 当 Cilium 启用 eBPF 替代 kube-proxy 时，Cilium 会执行集群节点的邻居发现，以收集网络中直接邻居或下一跳的 L2 地址。这是服务负载平衡所必需的，eXpress Data Path[29] (XDP) 快速路径支持每秒数百万数据包的可靠高流量速率。在这种模式下，在技术上按需动态解析是不可能的，因为它需要等待相邻的后端被解析。 在 Cilium 1.10 及更早版本中，cilium agent 本身包含一个 ARP 解析库，其控制器触发发现和定期刷新新增集群节点。手动解析的邻居条目被推送到内核并刷新为 PERMANENT 条目，eBPF 负载均衡器检索这些条目，将流量定向到后端。cilium agent 的 ARP 解析库缺乏对 IPv6 邻居解析支持，并且，PERMANENT 邻居条目还有许多问题：举个例子，条目可能变得陈旧，内核拒绝学习地址更新，因为它们本质上是静态的，在某些情况下导致数据包在节点间被丢弃。此外，将邻居解析紧密耦合到 cilium agent 也有一个缺点，在 agent 启停周期时，不会发生地址更新的学习。 在 Cilium 1.11 中，邻居发现功能已被完全重新设计，Cilium 内部的 ARP 解析库已从 agent 中完全移除。现在 agent 依赖于 Linux 内核来发现下一跳或同一 L2 域中的主机。Cilium 现在可同时支持 IPv4 和 IPv6 邻居发现。对于 v5.16 或更新的内核，我们已经将今年 Linux Plumbers 会议期间共同组织的 BPF & Networking Summit[30] 上，提出的 “管理” 邻居条目工作提交到上游（part1[31], part2[32], part3[33]）。在这种情况下，agent 将新增集群节点的 L3 地址下推，并触发内核定期自动解析它们对应的 L2 地址。 这些邻居条目作为 “外部学习” 和“管理”邻居属性，基于 netlink 被推送到内核中。虽然旧属性确保在压力下这些邻居条目不会被内核的垃圾收集器处理，但是 “管理” 邻居属性会，在可行的情况下, 内核需要自动将这些邻居属性保持在 REACHABLE 状态。这意思是，如果节点的上层堆栈没有主动向后端节点发送或接收流量，内核可以重新学习，将邻居属性保持在 REACHABLE 状态，然后通过内部内核工作队列定期触发显式邻居解析。对于没有 “管理” 邻居属性功能的旧内核，如果需要，agent controller 将定期督促内核触发新的解决方案。因此，Cilium 不再有 PERMANENT 邻居条目，并且在升级时，agent 将自动将旧条目迁移到动态邻居条目中，以使内核能够在其中学习地址更新。 此外，在多路径路由的情况下，agent 的负载均衡现在还会在路由查找中查看失败的下一跳。这意味着，不是替代所有的路由，而是通过查看相邻子系统信息来避免失败的路径。总的来说，对于 Cilium agent 来说，这项工作显着促进了邻居管理，并且在网络中的节点或下一跳的邻居地址发生变化时，数据路径更易变化。 XDP 对多设备负载均衡器的支持 XDP 支持多设备负载均衡器的示意图 在此版本前，基于 XDP 的负载均衡器加速只能在单个网络设备上启用，以便负载均衡器以发夹方式（hair-pinning）运行，即数据包转发离开的设备与数据包到达的设备相同。这个最初的限制是在基于 XDP 层的 kube-proxy 替代[34]加速中加入的，原因是在 XDP（XDP_REDIRECT）下对多设备转发的驱动支持有限，而同设备转发（XDP_TX）是 Linux 内核中每个驱动的 XDP 都支持的。 这意味着多网络设备的环境下，我们需要使用 tc eBPF 机制，所以必须使用 Cilium 的常规 kube-proxy 替代。这种环境的一个典型例子是有两个网络设备的主机，其中一个是公网，接受来自外部对 Kubernetes service 的请求，而另一个是私有网络，用于 Kubernetes 节点之间的集群内通信。 由于在现代 LTS Linux 内核上，绝大多数 40G 和 100G 以上的上游网卡驱动都支持开箱即用的 XDP_REDIRECT，这种限制终于可以解除，因此，这个版本在 Cilium 的 kube-proxy 替代，及 Cilium 的独立负载均衡器上，实现了 XDP 层的多网络设备的负载均衡，这使得在更复杂的环境中也能保持数据包处理性能。 XDP 透明支持 bond 设备 XDP 透明支持 bond 设备 在很多企业内部或云环境中，节点通常使用 bond 设备，设置外部流量的双端口网卡。随着最近 Cilium 版本的优化，如在 XDP 层的 kube-proxy 替代[35] 或独立负载均衡器[36]，我们从用户那里经常收到的一个问题是 XDP 加速是否可以与 bond 网络设备结合使用。虽然 Linux 内核绝大多数 10/40/100Gbit/s 网络驱动程序支持 XDP，但它缺乏在 bond（和 802.3ad）模式下透明操作 XDP 的能力。 其中的一个选择是在用户空间实现 802.3ad，并在 XDP 程序实现 bond 负载均衡，但这对 bond 设备管理是一个相当颇为繁琐努力，例如：对 netlink 链路事件的观测，另外还需要为编排器的本地和 bond 分别提供单独的程序。相反，本地内核实现解决了这些问题，提供了更多的灵活性，并且能够处理 eBPF 程序，而不需要改变或重新编译它们。内核负责管理 bond 设备组，可以自动传播 eBPF 程序。对于 v5.15 或更新的内核，我们已经在上游（part1[37], part2[38]）实现了 XDP 对 bond 设备的支持。 当 XDP 程序连接到 bond 设备时，XDP_TX 的语义等同于 tc eBPF 程序附加到 bond 设备，这意味着从 bond 设备传输数据包使用 bond 配置的传输方法来选择从属设备。故障转移和链路聚合模式均可以在 XDP 操作下使用。对于通过 XDP_TX 将数据包从 bond 设备上回传，我们实现了轮循、主动备份、802.3ad 以及哈希设备选择。这种情况对于像 Cilium 这样的发夹式负载均衡器来说特别有意义。 基于路由的设备检测 1.11 版本显着的提升了设备的自动检测，可用于 使用 eBPF 替代 kube-proxy[39]、带宽管理器[40]和主机防火墙[41]。 在早期版本中，Cilium 自动检测的设备需要有默认路由的设备，和有 Kubernetes NodeIP 的设备。展望未来，现在设备检测是根据主机命名空间的所有路由表的条目来进行的。也就是说，所有非桥接的、非 bond 的和有全局单播路由的非虚拟的设备，现在都能被检测到。 通过这项改进，Cilium 现在应该能够在更复杂的网络设置中自动检测正确的设备，而无需使用 devices 选项手动指定设备。使用后一个选项时，无法对设备名称进行一致性的命名规范，例如：无法使用共同前缀正则表达式对设备命名。 服务后端流量的优雅终止 优雅终止的示意图 Kubernetes 可以出于多种原因终止 Pod，如滚动更新、缩容或用户发起的删除。在这种情况下，重要的是要优雅地终止与 Pod 的活跃连接，让应用程序有时间完成请求以最大程度地减少中断。异常连接终止会导致数据丢失，或延迟应用程序的恢复。 Cilium agent 通过 “EndpointSlice” API 监听 service 端点更新。当一个 service 端点被终止时，Kubernetes 为该端点设置 terminating 状态。然后，Cilium agent 删除该端点的数据路径状态，这样端点就不会被选择用于新的请求，但该端点正在服务的当前连接，可以在用户定义的宽限期内被终止。 同时，Kubernetes 告知容器运行时向服务的 Pod 容器发送 SIGTERM 信号，并等待终止宽限期的到来。然后，容器应用程序可以启动活跃连接的优雅终止，例如，关闭 TCP 套接字。一旦宽限期结束，Kubernetes 最终通过 SIGKILL 信号对仍在 Pod 容器中运行的进程触发强制关闭。这时，agent 也会收到端点的删除事件，然后完全删除端点的数据路径状态。但是，如果应用 Pod 在宽限期结束前退出，Kubernetes 将立即发送删除事件，而不管宽限期设置。 更多细节请关注 docs.cilium.io[42] 中的指南。 Egress 出口网关的优化 Egress 出口网关的优化 简单的场景中，Kubernetes 应用只与其他 Kubernetes 应用进行通信，因此流量可通过网络策略等机制进行控制。但现实世界情况并非总是如此，例如：私有部署的一些应用程序没有被容器化，Kubernetes 应用程序需要与集群外的服务进行通信。这些传统服务通常配置的是静态 IP，并受到防火墙规则的保护。那么在此种情况下，应该如何对流量控制和审计呢？ Egress 出口 IP 网关功能在 Cilium 1.10[43] 中被引入，通过 Kubernetes 节点充当网关用于集群出口流量来解决这类问题。用户使用策略来指定哪些流量应该被转发到网关节点，以及如何转发流量。这种情况下，网关节点将使用静态出口 IP 对流量进行伪装，因此可以在传统防火墙建立规则。 apiVersion: cilium.io/v2alpha1 kind: CiliumEgressNATPolicy metadata: name: egress-sample spec: egress: - podSelector: matchLabels: app: test-app destinationCIDRs: - 1.2.3.0/24 egressSourceIP: 20.0.0.1 在上面的示例策略中，带有 app: test-app 标签的 Pod 和目标 CIDR 为 1.2.3.0/24 的流量，需要通过 20.0.0.1 网关节点的出口 IP（SNAT）与集群外部通信。 在 Cilium 1.11 开发周期中，我们投入了大量精力来稳定出口网关功能，使其可投入生产。现在， 出口网关现在可以工作在直接路由[44]，区分内部流量[45]（即 Kubernetes 重叠地址的 CIDR 的出口策略）及在不同策略中使用相同出口 IP[46]下。一些问题，如回复被错误描述为出口流量[47]和其他[48]等已经修复，同时测试也得到了改进，以便及早发现潜在的问题。 Kubernetes Cgroup 增强 Cilium 使用 eBPF 替代 kube-proxy [49] 作为独立负载均衡器[50]的优势之一是能够将 eBPF 程序附加到 socket hooks 上，例如 connect(2)、bind(2)、sendmsg(2) 以及其他各种相关的系统调用，以便透明地将本地的应用程序连接到后端服务。但是这些程序只能被附加到 cgroup v2。虽然 Kubernetes 正在努力迁移到 cgroup v2，但目前绝大多数用户的环境都是 cgroup v1 和 v2 混合使用。 Linux 在内核的 socket 对象中标记了 socket 与 cgroup 的关系，并且由于 6 年前的一个设定，cgroup v1 和 v2 的 socket 标签是互斥的。这就意味着，如果一个 socket 是以 cgroup v2 成员身份创建的，但后来通过具有 cgroup v1 成员身份的 net_prio 或 net_cls 控制器进行了标记，那么 cgroup v2 就不会执行附加在 Pod 子路径上的程序，而是回退执行附加到 cgroup v2 层次结构 (hierarchy) 根部的 eBPF 程序。这样就会导致一个很严重的后果，如果连 cgroup v2 根部都没有附加程序，那么整个 cgroup v2 层次结构 (hierarchy) 都会被绕过。 现如今，cgroup v1 和 v2 不能并行运行的假设不再成立，具体可参考今年早些时候的 Linux Plumbers 会议演讲[51]。只有在极少数情况下，当被标记为 cgroup v2 成员身份的 eBPF 程序附加到 cgroup v2 层次结构的子系统时，Kubernetes 集群中的 cgroup v1 网络控制器才会绕过该 eBPF 程序。为了在数据包处理路径上的尽量前面（early）的位置解决这个问题，Cilium 团队最近对 Linux 内核进行了修复，实现了在所有场景下允许两种 cgroup 版本 (part1[52], part2[53]) 之间相互安全操作。这个修复不仅使 Cilium 的 cgroup 操作完全健壮可靠，而且也造福了 Kubernetes 中所有其他 eBPF cgroup 用户。 此外，Kubernetes 和 Docker 等容器运行时最近开始陆续宣布支持 cgroup v2。在 cgroup v2 模式下，Docker 默认会切换到私有 cgroup 命名空间[54]，即每个容器（包括 Cilium）都在自己的私有 cgroup 命名空间中运行。Cilium 通过确保 eBPF 程序附加到正确的 cgroup 层次结构的 socket hooks 上，使 Cilium 基于套接字的负载均衡在 cgroup v2 环境中能正常工作。 增强负载均衡器的可扩展性 主要外部贡献者：Weilong Cui (Google) 最近的测试表明，对于运行着 Cilium 且 Kubernetes Endpoints 超过 6.4 万的大型 Kubernetes 环境，Service 负载均衡器会受到限制。有两个限制因素： Cilium 使用 eBPF 替代 kube-proxy 的独立负载均衡器的本地后端 ID 分配器仍被限制在 16 位 ID 空间内。 Cilium 用于 IPv4 和 IPv6 的 eBPF datapath 后端映射所使用的密钥类型被限制在 16 位 ID 空间内。 为了使 Kubernetes 集群能够扩展到超过 6.4 万 Endpoints，Cilium 的 ID 分配器以及相关的 datapath 结构已被转换为使用 32 位 ID 空间。 Cilium Endpoint Slices 主要外部贡献者：Weilong Cui (Google), Gobinath Krishnamoorthy (Google) 在 1.11 版本中，Cilium 增加了对新操作模式的支持，该模式通过更有效的 Pod 信息广播方式大大提高了 Cilium 的扩展能力。 之前，Cilium 通过 watch CiliumEndpoint (CEP) 对象来广播 Pod 的 IP 地址和安全身份信息，这种做法在可扩展性方面会带来一定的挑战。每个 CEP 对象的创建 / 更新 / 删除都会触发 watch 事件的组播，其规模与集群中 Cilium-agent 的数量呈线性关系，而每个 Cilium-agent 都可以触发这样的扇出动作。如果集群中有 N 个节点，总 watch 事件和流量可能会以 N^2 的速率二次扩展。 Cilium 1.11 引入了一个新的 CRD CiliumEndpointSlice (CES)，来自同一命名空间下的 CEPs 切片会被 Operator 组合成 CES 对象。在这种模式下，Cilium-agents 不再 watch CEP，而是 watch CES，大大减少了需要经由 kube-apiserver 广播的 watch 事件和流量，进而减轻 kube-apiserver 的压力，增强 Cilium 的可扩展性。 由于 CEP 大大减轻了 kube-apiserver 的压力，Cilium 现在已经不再依赖专用的 ETCD 实例（KVStore 模式）。对于 Pod 数量剧烈变化的集群，我们仍然建议使用 KVStore，以便将 kube-apiserver 中的处理工作卸载到 ETCD 实例中。 这种模式权衡了 “更快地传播 Endpoint 信息” 和“扩展性更强的控制平面”这两个方面，并力求雨露均沾。注意，与 CEP 模式相比，在规模较大时，如果 Pod 数量剧烈变化（例如大规模扩缩容），可能会产生较高的 Endpoint 信息传播延迟，从而影响到远程节点。 GKE 最早采用了 CES，我们在 GKE 上进行了一系列 “最坏情况” 规模测试，发现 Cilium 在 CES 模式下的扩展性要比 CEP 模式强很多。从 1000 节点规模的负载测试来看，启用 CES 后，watch 事件的峰值从 CEP 的 18k/s 降低到 CES 的 8k/s，watch 流量峰值从 CEP 的 36.6Mbps 降低到 CES 的 18.1Mbps。在控制器节点资源使用方面，它将 CPU 的峰值使用量从 28 核 / 秒减少到 10.5 核 / 秒。 GKE 中 1000 个节点规模的负载测试中的 CEP watch 事件和流量 GKE 中 1000 个节点规模的负载测试中的 CEP 和 CES watch 事件和流量 详情请参考 Cilium 官方文档[55]。 Kube-Proxy-Replacement 支持 Istio 许多用户在 Kubernetes 中使用 eBPF 自带的负载均衡器来替代 kube-proxy[56]，享受基于 eBPF 的 datapath 带来的高效处理方式[57]，避免了 kube-proxy 随着集群规模线性增长的 iptables 规则链条。 eBPF 对 Kubernetes Service 负载均衡的处理在架构上分为两个部分[58]： 处理进入集群的外部服务流量（南北方向） 处理来自集群内部的服务流量（东西方向） 在 eBPF 的加持下，Cilium 在南北方向已经实现了尽可能靠近驱动层（例如通过 XDP）完成对每个数据包的处理；东西流量的处理则尽可能靠近 eBPF 应用层，处理方式是将应用程序的请求（例如 TCP connect(2)）从 Service 虚拟 IP 直接 “连接” 到后端 IP 之一，以避免每个数据包的 NAT 转换成本。 Cilium 的这种处理方式适用于大多数场景，但还是有一些例外，比如常见的服务网格解决方案（Istio 等）。Istio 依赖 iptables 在 Pod 的网络命名空间中插入额外的重定向规则，以便应用流量在离开 Pod 进入主机命名空间之前首先到达代理 Sidecar（例如 Envoy），然后通过 SO_ORIGINAL_DST 从其内部 socket 直接查询[59] Netfilter 连接跟踪器，以收集原始服务目的地址。 所以在 Istio 等服务网格场景下，Cilium 改进了对 Pod 之间（东西方向）流量的处理方式，改成基于 eBPF 的 DNAT 完成对每个数据包的处理，而主机命名空间内的应用仍然可以使用基于 socket 的负载均衡器，以避免每个数据包的 NAT 转换成本。 要想开启这个特性，只需在新版 Cilium agent 的 Helm Chart 中设置 bpf-lb-sock-hostns-only: true 即可。详细步骤请参考 Cilium 官方文档[60]。 特性增强与弃用 以下特性得到了进一步增强： 主机防火墙 (Host Firewall) 从测试版 (beta) 转为稳定版 (stable)。主机防火墙通过允许 CiliumClusterwideNetworkPolicies[61] 选择集群节点来保护主机网络命名空间。自从引入主机防火墙功能以来，我们已经大大增加了测试覆盖率，并修复了部分错误。我们还收到了部分社区用户的反馈，他们对这个功能很满意，并准备用于生产环境。 以下特性已经被弃用： Consul 之前可以作为 Cilium 的 KVStore 后端，现已被弃用，推荐使用更经得起考验的 Etcd 和 Kubernetes 作为 KVStore 后端。之前 Cilium 的开发者主要使用 Consul 进行本地端到端测试，但在最近的开发周期中，已经可以直接使用 Kubernetes 作为后端来测试了，Consul 可以退休了。 IPVLAN 之前用来作为 veth 的替代方案，用于提供跨节点 Pod 网络通信。在 Cilium 社区的推动下，大大改进了 Linux 内核的性能，目前 veth 已经和 IPVLAN 性能相当。具体可参考这篇文章：eBPF 主机路由[62]。 策略追踪 (Policy Tracing) 在早期 Cilium 版本中被很多 Cilium 用户使用，可以通过 Pod 中的命令行工具 cilium policy trace 来执行。然而随着时间的推移，它没有跟上 Cilium 策略引擎的功能进展。Cilium 现在提供了更好的工具来追踪 Cilium 的策略，例如网络策略编辑器[63]和 Policy Verdicts[64]。 引用链接 [1] Service Mesh Beta 版本: https://cilium.io/blog/2021/12/01/cilium-service-mesh-beta [2] 分支: https://github.com/cilium/cilium/tree/beta/service-mesh [3] 更多详情: https://isovalent.com/blog/post/2021-12-release-111#opentelemetry [4] 更多详情: https://isovalent.com/blog/post/2021-12-release-111#kubernetes-apiserver-policy-matching [5] 更多详情: https://isovalent.com/blog/post/2021-12-release-111#topology-aware-hints [6] 更多详情: https://isovalent.com/blog/post/2021-12-release-111#bgp-pod-cidr-announcements [7] 更多详情: https://isovalent.com/blog/post/2021-12-release-111#graceful-termination [8] 更多详情: https://isovalent.com/blog/post/2021-12-release-111#feature-status [9] 更多详情: https://isovalent.com/blog/post/2021-12-release-111#service-backend-scalability [10] 更多详情: https://isovalent.com/blog/post/2021-12-release-111#transparent-xdp-bonding-support [11] 更多详情: https://isovalent.com/blog/post/2021-12-release-111#xdp-multi-dev [12] 更多详情: https://isovalent.com/blog/post/2021-12-release-111#istio-kpr [13] 更多详情: https://isovalent.com/blog/post/2021-12-release-111#egress-gateway-improvements [14] 更多详情: https://isovalent.com/blog/post/2021-12-release-111#managed-ipv4-ipv6-discovery [15] 更多详情: https://isovalent.com/blog/post/2021-12-release-111#route-based-device-detection [16] 更多详情: https://isovalent.com/blog/post/2021-12-release-111#kubernetes-cgroup [17] 更多详情: https://isovalent.com/blog/post/2021-12-release-111#cilium-endpoint-slices [18] 更多详情: https://isovalent.com/blog/post/2021-12-release-111#mke-integration [19] OpenTelemetry: https://opentelemetry.io/ [20] Jaeger: https://jaegertracing.io/ [21] 支持 OpenTelemetry 的 Hubble 适配器: https://github.com/cilium/hubble-otel [22] OpenTelemetry Operator: https://github.com/open-telemetry/opentelemetry-operator [23] 用户指南: https://github.com/cilium/hubble-otel/blob/main/USER\\_GUIDE\\_KIND.md [24] 拓扑感知路由: https://kubernetes.io/docs/concepts/services-networking/topology-aware-hints [25] 官方文档: https://kubernetes.io/docs/concepts/services-networking/topology-aware-hints [26] 发布负载均衡器的 service 的 VIP: https://cilium.io/blog/2021/05/20/cilium-110#bgp [27] eCHO episode: https://www.youtube.com/watch?v=nsfbFUO8eu4&t=668s [28]docs.cilium.io: https://docs.cilium.io/en/latest/gettingstarted/bgp/ [29] eXpress Data Path: https://cilium.io/blog/2020/06/22/cilium-18#kube-proxy-replacement-at-the-xdp-layer [30] BPF & Networking Summit: https://lore.kernel.org/netdev/20211011121238.25542-1-daniel@iogearbox.net/ [31] part1: https://lore.kernel.org/netdev/20211011121238.25542-1-daniel@iogearbox.net/ [32] part2: https://lore.kernel.org/netdev/20211013132140.11143-1-daniel@iogearbox.net/ [33] part3: https://lore.kernel.org/netdev/20211025154728.2161-1-daniel@iogearbox.net/ [34] 基于 XDP 层的 kube-proxy 替代: https://cilium.io/blog/2020/06/22/cilium-18#kube-proxy-replacement-at-the-xdp-layer [35] kube-proxy 替代: https://cilium.io/blog/2020/06/22/cilium-18#kube-proxy-replacement-at-the-xdp-layer [36] 独立负载均衡器: https://cilium.io/blog/2021/05/20/cilium-110#standalonelb [37] part1: https://lore.kernel.org/bpf/20210731055738.16820-1-joamaki@gmail.com/ [38] part2: https://lore.kernel.org/netdev/20210906085638.1027202-1-joamaki@gmail.com/ [39] 使用 eBPF 替代 kube-proxy: https://cilium.io/blog/2020/06/22/cilium-18#kube-proxy-replacement-at-the-xdp-layer [40] 带宽管理器: https://cilium.io/blog/2020/11/10/cilium-19#bwmanager [41] 主机防火墙: https://cilium.io/blog/2020/06/22/cilium-18#policy [42]docs.cilium.io: https://docs.cilium.io/en/v1.11/gettingstarted/kubeproxy-free/#graceful-termination [43] Cilium 1.10: https://cilium.io/blog/2021/05/20/cilium-110#egressgateway [44] 直接路由: https://github.com/cilium/cilium/pull/17517 [45] 区分内部流量: https://github.com/cilium/cilium/pull/17639 [46] 在不同策略中使用相同出口 IP: https://github.com/cilium/cilium/pull/17773 [47] 回复被错误描述为出口流量: https://github.com/cilium/cilium/pull/17869 [48] 其他: https://github.com/cilium/cilium/pull/17813 [49] eBPF 替代 kube-proxy : https://cilium.io/blog/2020/06/22/cilium-18#kube-proxy-replacement-at-the-xdp-layer [50] 独立负载均衡器: https://cilium.io/blog/2021/05/20/cilium-110#standalonelb [51] Linux Plumbers 会议演讲: https://linuxplumbersconf.org/event/11/contributions/953/ [52] part1: https://lore.kernel.org/bpf/20210913230759.2313-1-daniel@iogearbox.net/ [53] part2: https://lore.kernel.org/bpf/20210927123921.21535-1-daniel@iogearbox.net/ [54] 私有 cgroup 命名空间: https://docs.docker.com/config/containers/runmetrics/#running-docker-on-cgroup-v2 [55] Cilium 官方文档: https://docs.cilium.io/en/v1.11/gettingstarted/ciliumendpointslice/ [56] 替代 kube-proxy: https://docs.cilium.io/en/latest/gettingstarted/kubeproxy-free/ [57] 高效处理方式: https://docs.cilium.io/en/v1.10/operations/performance/tuning/#tuning-guide [58] 两个部分: https://cilium.io/blog/2020/06/22/cilium-18#kubeproxy-removal [59] 查询: https://www.envoyproxy.io/docs/envoy/latest/configuration/listeners/listener\\_filters/original\\_dst\\_filter [60] Cilium 官方文档: https://docs.cilium.io/en/latest/gettingstarted/kubeproxy-free/#socket-loadbalancer-bypass-in-pod-namespace [61] CiliumClusterwideNetworkPolicies: https://CiliumClusterwideNetworkPolicies [62] eBPF 主机路由: https://cilium.io/blog/2020/11/10/cilium-19#veth [63] 网络策略编辑器: https://app.networkpolicy.io/ [64] Policy Verdicts: https://cilium.io/blog/2020/06/22/cilium-18#policyverdicts
2021-12-14
优秀的个人博客,低调大师

ShopXO 企业级免费开源商城 v2.2.3 正式发布

更新日志 本次更新主要更新新版本主题适配H5端 1. 整体适配H5端 2. 订单、钱包、会员等级支付优化适配 3. 支持（账号、手机、邮箱）登录注册方式 4. 分享逻辑优化全局处理 5. 分销新增上级用户、阶梯返佣提示 6. 新增独立新增错误页面 7. 适配第三方登录插件 8. 支持线下支付自定义信息展示 9. 规格切换购买数量错误修复 10. 手机端富文本详情支持视频、超链接、图片预览 11. 页面设计图片地址处理优化 12. 问答数据处理用户出错修复 13. 新增web端首页关闭状态+新增电信经营许可证展示 14. 支持新增线下支付订单进入正常流程开关 15. 新增手机H5自定义地址 16. 商店账号未绑定优化 17. 订单自动收货参数错误修复 18. 老版本小程序主题适配新版本接口 效果图片（内置多种配色） 可视化DIY拖拽装修展示 PC端展示 后台管理展示
2021-12-13
优秀的个人博客,低调大师

ShopXO 企业级免费开源商城 v2.2.2 正式发布

更新日志 本次更新主要新版本小程序主题全面支持（微信、支付宝、百度、头条&抖音、QQ）6大平台小程序、并适配所有功能插件 1. 限时秒杀插件支持独立首页并适配小程序 2. 活动配置插件支持优惠价格设定并适配小程序 3. 标签插件适配小程序 4. 中间广告插件适配小程序 5. 弹屏广告插件适配小程序 6. 哀悼插件适配小程序 7. 文章支持分类页面并适配小程序 8. 博客插件适配小程序 9. 分销、会员等级增强版、钱包全面支持小程序 10. 新增批量评价插件 11. 新增用户授权获取用户信息API 12. 可视化商品分类排序错误修复 13. 百度支付插件支持自定义异步地址 14. 新增菜鸟物流插件、支持web端和小程序 15. 第三方登陆插件APP端支持（微信、QQ） 16. 插件隐私字段配置、避免重要信息暴露 小程序效果图片 可视化DIY拖拽装修展示 PC端展示 后台管理展示
2021-11-24

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

时间: 2026-10-18 大小: 211.28KB 下载: 56次
腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

时间: 2026-08-21 大小: 1MB 下载: 10次
Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

时间: 2026-09-24 大小: 189MB 下载: 9次
Rocky Linux

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。

时间: 2026-08-21 大小: 1.42GB 下载: 6次
热门标签
DeepSeek Jdk25 OpenAi HarmonyOS6 Nacos3 SpringBoot4 SpringCloud Docker Kubernetes Service Mesh Redis Gemini3 Rocky

欢迎您来访！

登录后，您将获得更多功能！
热门文章
联系我们

有任何问题或合作意向欢迎联系我们

Email: 99873273@qq.com

QQ: 99873273

用户登录
用户注册