明天，「Inclusion 外滩大会」就要开幕了，在这场全球金融科技盛会中，作为金融业的得力助手，科技主题，也占据了不少的篇幅。而作为 IT 人，如果你来到了外滩大会，那么下面这些技术分享，一定不能错过。

必看一：OceanBase 是怎样炼成的？

作为一切 IT 应用的基础，数据库是每一场技术大会都必不可少的主题。而随着云计算时代的到来，数据库领域也发生了天翻地覆般的改变。互联网的海量应用场景给了数据库技术最肥沃的试验田。而自研数据库技术得益于国内海量的数据应用，快速创新，持续蓄力。

作为自研数据库的翘楚，OceanBase 是谈及自研数据库绕不过去的话题，在本次的 Inclusion 大会中，主办方邀请了 OceanBase 团队的首席技术官阳振坤博士，来「数据库，新标杆，新征途」分会场分享「OceanBase 数据库七亿 tpmC 的关键技术」

除了 OceanBase 以外，关于数据库，主办方还邀请了华东师范大学副院长，“智能+”研究院院长，数据学院教授周傲英博士分享「数据库的发展与中国的机遇」、西安银行科技部总架构师肖梁先生分享「企业级数据库加速客户数字化转型」、恒生电子股份有限公司云基础系统发展部总经理王佳玮分享「证券行业数据库应用创新之路」等。如果你对数据库感兴趣，那么一定不能错过「数据库，新标杆，新征途」分会场所分享的各种技术主题。

必看二：智能驱动金融变革

人工智能、分布式计算等新技术，引领了当下技术的潮流，更是将金融科技推向了新的发展高度。在新的时代，金融的创新更多的依赖这些新兴技术所带来的改变和智能与技术所引导的业务创新场景。在本次大会中，主办方邀请了全球顶级思想领袖、技术大咖和学术精英共同探讨在新的技术潮流下，金融科技将何去何从？

在本次的 Inclusion 大会中，蚂蚁集团副总裁芮雄文将会就新技术潮流下的金融科技这一话题，在「智能计算峰会 - 重塑金融」分会场分享「新时代新要求：科技重塑金融创新」。

不仅如此，蚂蚁集团副总裁韦韬将会分享「安全计算的演变与展望」，介绍蚂蚁集团是如何让计算变得更加安全和可信。

此外，你还可以在「智能计算峰会 - 重塑金融」分会场听到来自蚂蚁集团的计算存储首席架构师何昌华分享「智能计算实践」、美国三院院士，曾获冯诺依曼奖的 Michael Jordan 分享「人工智能发展趋势」以及恒生电子股份有限公司总裁刘曙峰分享「智能化推进金融数字化下半场」等主题。

如果你关注人工智能、机器学习、那么「智能计算峰会 - 重塑金融」，将是你不容错过的一场。

必看三：如何构建可信原生

云原生理念和实践已经取得了广泛的认可和传播，云原生的关键技术也在不断发展，提升IT系统的生产力，然而在注重信任的金融领域，如何在利用云原生带来的效能提升的同时，进一步提升安全和稳定性，仍然是个极具挑战的问题。为了更好的讨论这个问题，本次大会的主办方邀请了蚂蚁集团研究员何征宇在「可信原生 - 安全稳定的基础设施」分享「可信原生: 下一代的金融技术基础设施」。

除了下一代金融技术基础设施的分享以外，「可信原生 - 安全稳定的基础设施」分会场还邀请了陈渝副教授分享「基于 Rust 语言的 OS 探索」和英特尔 IAGS 系统软件 高级技术总监刘秉伟分享「英特尔系统全栈，赋能机密计算新时代」。

未来，每一个金融云，都将会基于可信原生建立，那么在现在，就是来了解他的最好时刻。

必看四：技术风险控制的实现秘诀

随着企业数字化转型的不断推进，越来越多的新兴技术开始出现在企业的各种应用中，这些应用改变了行业，但也同样带来了足以改变行业的问题。在这样的大背景下，控制技术因素引入的稳定性风险就显得日趋重要。在本次大会的「技术风险，稳妥创新」分会场，云集了蚂蚁集团、中国人寿、滴滴等多个企业的技术专家，一同探讨如何在企业内进行技术风险的控制。

在「技术风险，稳妥创新」分会场中，以下主题不容错过：

必看五：创新引领未来

产学研的打通，促进了研究的落地发芽，推进了产业和学界的交流和沟通，更是为行业和国家培养了一批又一批的优秀人才，在这次大会中，蚂蚁集团联合产学研机构，邀请了国内外优秀学者共话如何推进计算机科学领域基础性、前瞻性的技术发展和人才培养。在本次外滩大会的「校企合作 - 引领技术 、关注人才、共创未来关注」分会场，你将会了解到全世界高校的尖端研究与新时代下产学研如何合作、共进、共研。

在「校企合作」分论坛，主办方邀请了教育部高等教育司巡视员兼教育部高等教育教学评估中心主任刘凤泰分享「新时代下的校企合作探索与思考」

除了这些，还有什么值得看？

如果上面的这五个会场你还觉得不够，Inclusion 外滩大会还有其他的分论坛，可以满足你对于技术的一切要求，比如：

• 实时智能分论坛：专注实时计算系统和下一代数据存储于计算领域的创新与应用
• 图智能分论坛：了解复杂金融关系的最优解 —— 图智能
• 体验科技分论坛：探讨新一代极致的用户体验及最佳工程实践
• AI 安全分论坛：在新的安全形式下，如何推动和引领业界在AI安全领域的发展？
• IoT 安全分论坛：在 IoT 新时代，如何在服务模式业务创新的基础上，保障用户的安全和隐私？

当然，整个 Inclusion 外滩大会不止这些，更多的好内容，你可以访问官网 www.inclusionconf.com 了解。

总结

Inclusion 大会作为一场全球金融科技盛会，在科技领域能够邀请如此多的行业专家、学者来一同讨论金融科技的现在与未来，对于每一个从业者来说，都是不可多得的机会。如果你有机会来到外滩大会，一定不要错过这些精彩的分享，来听一听技术专家的分享。

随着业务的现代化和规模化，Kubernetes 和其背后的云原生成为如今软件系统的唯一选择。而对于众多的开发者来说， Kubernetes 并不是一个简单的问题，使用 Kubernetes 意味着需要理解 Kubernetes 背后的众多概念，你需要理解 Kubernetes 背后复杂的一套生态。但，对于一个企业来说，业务才是核心，Kubernetes 对于企业来说，更多只是一个基础设施，这个基础设施很重要，不得不有，但又无法产生价值，企业不会投入太多精力。

在这种情况下，选择使用开源社区提供的发行版和各种管理工具，就成为一个并不经济的选项。对于企业来说，找到一个可以以最低心智负担接入的 Kubernetes 服务，才是最佳选择。相比于社区的众多发行版，Amazon EKS 屏蔽了 Kubernetes 底层的基础设施的部分，将 Worker 层面的工作保留给用户，既可以给予用户一定的自由，同时又可以让用户可以无痛的从传统架构切换至云原生架构上。

对于企业而言，Amazon的 EKS 服务，可能是一个最佳的选择。

做一个敢于承诺 SLA 的 Kubernetes 服务

和很多 Kubernetes 服务/开源软件不同，Amazon 的 EKS 服务主打的是一个高度可用、可扩展且安全的 Kubernetes 服务，并且，EKS 承诺，为客户提供了 99.95% 的可用性，让自己的客户可以安全高效的运转业务。在众多 Kubernetes 服务中，敢于提出向企业承诺可用性保障的 Kubernetes 服务，Amazon 是其中之首。这让 Amazon EKS 脱颖而出。

EKS 工作模式

Amazon EKS 通过托管控制平面节点，尽可能的降低用户在维护整个集群的成本。在使用 Amazon EKS 后，企业只需要维护执行业务所需的 Worker 节点，就可以搞定整个集群的运转。剩下的工作，就交给 AWS 来完成。AWS 为用户提供了一个可以跨多个 AWS 可用区，可扩展且高度可用的控制平面，从而确保无论在什么情况下 Kubernetes API 和 etcd 服务都可以正常运转。从而确保业务的可用性。

不仅如此，Amazon EKS 还通过整合 AWS 的其他业务，诸如 Elastic Load Balancing、AWS CloudWatch 等服务，让整个 Kubernetes 集群可以更加动态的完成业务的请求而不会崩溃。

做一个功能强大的 Kubernetes 服务

企业之所以选择 AWS ，很大程度是因为 AWS 为企业提供了足够多的能力支持和足够强大的业务范围，只要你需要，AWS 就可以为你提供相应的服务。

基于用户的需求， AWS 在标准的 Kubernetes 服务的基础之上，引入了对于 AWS 更多能力的支持，包括：

• 基于 AWS Cloud Map 的服务发现能力
• 基于 Amazon VPC CNI 的网络能力
• 基于 AWS IAM 验证器的权限管理能力
• 基于 Elastic Load Balancing 的负载均衡能力
• 基于 AWS Fargate 的无服务器计算能力
• 基于 AWS Outposts 的混合云部署对接能力
• 给予 AWS CloudTrail 的日志记录能力
• 给予 AWS CloudWatch 的云监控能力
• …

这些能力源自底层云计算强大实力的能力，非一般的云计算服务商所能比拟的。但，对于企业来说，也正是这些能力，给了企业无限的可能，企业可以放心大胆的拓展自己的业务，而无需担心自己的业务底层出现任何问题，源自于 AWS 多年的云计算研究的底气，非一般的云计算服务商所能比拟的。

做一个开放开源的 Kubernetes 服务

Kubernetes 的强大，源自于其生态链中的各种各样的软件和服务，而一个 Kubernetes 服务想要发挥最强的性能，就离不开和社区的 Kubernetes 服务进行整合，享受到来自社区的种种新能力的接入。

和一般的 Kuberntes 服务相比， Amazon EKS 提供了和上游 Kubernetes 一致的 API，这意味着如果企业希望使用 Kubernetes 生态中的插件或工具，都可以直接无痛接入，从而享受到来自 Kubernetes 社区的赋能。

同时，Amazon EKS 和上游保持一致也使得 Amazon EKS 可以十分轻松的完成 Kubernetes 集群的升级。Amazon EKS 会自动将正在运行的集群更新到最新的 Kubernetes 版本，对于企业来说，无需任何关注，集群就已经完成了整体的升级，让企业的集群可以享受到 Kubernetes 的最新特性。

不仅如此，Amazon EKS 还积极的参与到 Kubernetes SIG 的建设中，并开源出了诸如 CDK8s、FireCracker 这样的项目，来增强 Kubernetes 社区生态，帮助整个 Kubernetes 社区成长。

做一个不仅仅是 Kubernetes 的 Kubernetes 服务

Kubernetes 是云原生的未来，但对于专心于业务的企业来说，Kubernetes 可能还是太重了。如果你使用了 Amazon EKS ，则可以有一个更加简单的方案，就是在 Amazon EKS 基础之上，运行 AWS Fargate，从而将容器使用的成本进一步降低。

从 EKS 到 Fargate，变化的是提供的服务，不变的是让企业可以更加简单、低成本、无负担的切换到更好的基础设施的心态，也正是这样的心态，让 Amazon EKS 基于 Kubernetes ，但有提供了超出 Kubernetes 的服务。

总结

当你需要一个足够好用、足够安全、足够稳定的 Kubernetes 服务时， Amazon EKS 就会成为一个不错的选择；当你希望用尽可能少的精力去维护基础设施，希望将更多的精力投放在业务的研发上时，Amazon EKS 就会成为一个值得你选择的选项。如果你想要试一试 Kubernetes ，那为什么不从 Amazon EKS 开始呢？

今天，很高兴的告诉大家，筹备已久的 LCTT SIG - LCRH 成立啦！

什么是 LCTT SIG？

LCTT SIG 是 LCTT 特别兴趣小组 （ Special Interest Group ） ，LCTT SIG 是针对特定领域、特定内容的翻译小组，翻译组成员将遵循 LCTT 原有规范，参与翻译，并获得相应的奖励。

新的 SIG - LCRH 要翻译什么？

在 LCTT 历史的翻译文章中，《 代码英雄 （ Command Line Heroes ） 》系列是一批质量好、信息量大、阅读体验很好的有声阅读内容（“有声”部分是英文）。

而《 代码英雄 （ Command Line Heroes ） 》背后其实还有着数十篇精华文章都没有进行翻译，为了能够让更多的开发者阅读到这些好文章，Linux 中国特别与红帽（RedHat） 公司合作，获得了代码英雄的翻译授权，将这系列文章翻译成为中文，将其带给国内的开发者。

Command Line Heroes 是来自红帽公司的一款原创播客，它关注开源、软件构建，联合各嘉宾，向更多开发者传播开源知识，了解开发领域的点点滴滴。作为一个曾经荣获 Shorty Award Audience Hornor 和 Webby Award Best Branded Podcast 的播客，其内容量、丰富度、广泛度，都非普通播客可以比拟的。

出于重视，我们将代码英雄作为独立的 SIG 来进行运营，让大家可以专注在代码英雄这一个系列的内容分享和讨论。

同时，为了能够更早的让代码英雄在国内落地，LCTT 也在此邀请大家参与到 LCRH SIG 的团队中，一同进行代码英雄的翻译、校对和贡献。

我们需要什么样的人？

招募对象：在校大学生、研究生、博士生或已工作但是有相对自由时间，对代码英雄有兴趣的同学、朋友。

基本原则：

1. 我们不需要三分钟热度的人，翻译并非是图一时之快，而需要责任心与耐心。
2. 有较好的英译汉翻译能力或听译能力，同时要有良好的汉语组织和表达水平，无证书等硬性要求，有能力即可。
3. 具备相对固定的空余时间，能保证参与翻译，能保质保量地按时完成翻译。

你可以获得什么？

1. 来自红帽（Red Hat）公司正式颁发的专属贡献者证书
2. 来自红帽（Red Hat）公司特别定制的纪念礼品
3. 来自 Linux 中国的福利礼品
4. 翻译文章的专属署名权

如何参与

这个 SIG 的贡献协作采用传统的 QQ 群，在 QQ 中搜索群 940139452 ，加入我们，参与翻译，具体翻译流程可以进群后了解。

你感兴趣吗？

近些年来，云计算蓬勃发展，上云成为现在软件开发落地的首选。但随着企业业务的不断增长和扩大，传统云计算的劣势也暴露出来：单体硬件性能不够，只能堆集群；租户隔离不够彻底，时有新闻爆出问题。因此，物理机服务器又再一次的被提上了台面。

创立于 2012 年的 UCloud，从 2013 年伊始就面向市场同时提供了基于虚拟化服务器的公有云产品和基于裸金属服务器的物理云产品。不过，和绝大多数人想象中的不同，物理云服务器并非直接帮你上架一个服务器就行的，其背后也有不少复杂的技术难点需要 UCloud 及合作伙伴们去攻关。这其中最为艰难的，可能就是虚拟网络相关特性的研发。

物理云产品和公有云产品最大的不同就在于客户可以独占并完全控制整台物理服务器，UCloud 作为服务商并不会在服务器上运行任何虚拟化的软件。这使得想要让物理云产品和公有云产品的网络互通、让物理云产品享受到公有云产品所享有的网络优势变得十分困难。特别是一些有状态的特性比如安全组等实现起来更加困难。

UCloud 踩过的那些坑

从 2013 年开始，UCloud 开始使用 Open vSwitch 来构建基于 Openflow 技术的公有云 SDN 虚拟网络。也因此，同年， UCloud 提供物理云产品的时候，选用了支持 OpenFlow 的 SDN 交换机，以实现物理云产品和公有云 VPC 网络的互通。

2014 年，随着 UCloud 业务的扩大和快速发展，已有的交换机所提供的 OpenFlow 流表有限的条目已经无法支撑实际物理云产品业务的需求。

2015 年，已经在 DPDK 技术上做了两年研究储备的 UCloud 领先在产品环境推出了采用 DPDK 技术的服务器集群，从而替代硬件 SDN 交换机，满足业务层面的需求。

但随着以太网技术的发展，人工智能、大数据等应用的落地，网络技术的发展得到了爆发般的发展，25G、100G 的网络迅速得到普及， DPDK 网关集群的转发性能和成本问题逐渐成为业务发展的瓶颈。

时间来到了 2019 年， UCloud 开始使用智能网卡（Smart NIC）来替代原有的 DPDK 网关集群。UCloud 采用的智能网卡方案采用了 16 核 ARM CPU 运行 OVS 作为 SlowPath，采用 Linux TC Flower 卸载技术将网卡芯片作为 FastPath，通过 SRIOV 技术和用户系统集成，很好地解决了性能问题，但与此同时，其所带来的高昂采购成本造成了成本的提升。此外，由于所采用的智能网卡的转发面尚不可编程，也使得任何新的特性都需要网卡芯片厂商修改固件来实现。甚至一些比较复杂的特性也不能实现。比较典型的例子就是为了让智能网卡支撑 UCloud 使用的 Overlay 封装格式，就花费了半年时间才在和网卡芯片厂商反复沟通协调下完成，而类似带宽控制、硬件卸载的特性却难以实现。

痛定思痛的深度思考

六年的艰辛探索，让 UCloud 调研试验了几乎市面上所有的各种网络网关方案。而这些年来踩的坑，也让 UCloud 看到了这一代网关产品的问题和不足。作为战斗在云计算网络技术一线的团队，UCloud 基于实践经验，总结出了下一代物理云网关应该满足的一些需求：

1. 全功能：能够提供和公有云一样的网络特性，比如有状态服务安全组等。
2. 高性能：能够满足从 25G 网络到 100G 网络的需求。
3. 低成本：比 DPDK 网关和智能网卡网关有更低的拥有成本。
4. 可定制：能够满足定制需求，可以基于此进行进一步的演进。

基于 Jericho2 芯片的下一代物理云网关 —— BCM88690

在使用现有的智能网卡解决方案的同时， UCloud 也在积极的在技术市场上寻找合适的下一代物理云网关，以替换现有的产品解决方案。

首先进入 UCloud 视线的是某公司的一款高性能交换机。它和智能网卡一样可以运行 Linux 和 Open vSwitch，更加难得的是，其通过 Switchdev 支持 OVS TC Flower 卸载，并使用交换机芯片作为 OVS 的 FastPath。遗憾的是交换芯片对 TC Flower 卸载的支持仍然不好，造成很多功能无法卸载。并且交换芯片不支持用户编程，UCloud 无法修改交换芯片的管线来满足自己实际的业务需求。

而在这时，博通正在研发 Jericho2 可编程交换芯片相关的产品，于是 UCloud 与博通一拍即合，与博通合作利用 Jericho2 可编程交换芯片研究开发物理云网关，并基于研究的成果，开发出了能够完美满足 UCloud 需求的物理云网关。

在技术层面上，UCloud 通过在 Jericho2 可编程交互芯片上定制了管线来作为 TC Flower 的 FastPath，并在交换机控制面运行 Linux + OVS 作为 SlowPath ，并通过 TC Flower Offload 将两者集成在一起，从而实现硬件的加速。

当报文进入交换芯片，首包未命中时通过可编程交换机的虚拟网卡进入交换机的 Linux 内核，通过 OVS 的 Datapath 触发 ovs-vswitchd 下发新的 Openflow 流表。UCloud 通过对 OVS 做了尽量少的改动，将原先通过 Netlink 发送到内核去的 TC Flower 卸载消息通过 UNIX 套接字发送到运行在用户态的 Jericho2 Agent，它再将消息转化为对应的可编程交换机的消息下发给交换芯片。后续报文将直接命中交换机管线中的流表，由交换芯片转发。

Jericho2 提供了业界独一无二的可编程架构，除了管线节点可编程外，还可以进行管线延展，在增加了处理流程的同时而没有损失任何转发性能。其基于 C++ 的编程工具链，成熟且直观，使 UCloud 可以轻松的基于现有芯片添加功能、在线升级，并轻松的根据实际需求进行定制和实施。得益于 Jericho2 灵活的可编程能力，UCloud 和博通合作在交换芯片上实现了 OVS 的 TC Flower 卸载转发面，可以实现和智能网卡同样的 OVS 卸载功能，但达到了 4.8T 的转发性能，相当于 48 块 100G 智能网卡。并且还保留了进一步扩展定制的能力，以实现 UCloud 使用的 Overlay 封装格式 GRETAP 为例，可以完全自行开发、灵活修改，一周的工作就能完成。

另外 Jericho2 真正的模块化表项结构，所有表项共享同一块物理缓存，极大增加了片上资源的使用效率。管线上所有处理节点可以并行访问，根据不同的应用场景进行逻辑表项的灵活划分，使得同样的硬件可以应用在完全不同的使用场景。丰富的表项资源使得新一代的网关能够完全满足用户现有甚至未来可见数年的规格需求。

最终， UCloud 实现了一个完全和公有云特性兼容，转发能力高达 4.8T ，并且可以自由定制，成本也非常有竞争力的物理云网关。这满足了对于下一代物理云网关所定义的四大需求：全功能、高性能、低成本、可定制。

总结

UCloud 作为国内公有云市场的大玩家，更是如今国内的公有云第一股，在国内风起云涌、巨头林立的大环境下，稳稳的占据了属于自己的市场， 实属不易。而 UCloud 能做到这一点，得益于其始终坚持“客户为先”的价值观，及时响应客户需求，快速解决客户问题，不断推出超出客户预期的创新产品和服务。也正是这样对于客户为先的价值观，让 UCloud 不仅能做好服务，更能打造出卓越的产品。

云原生 （ Cloud Native ） 绝对算的上是热词一个，但是，对于绝大多数的企业，甚至是绝大多数的互联网企业来说，却从来没有动手实践过云原生。无他，现在的云原生实践成本太高。

企业面临的云原生困境

云原生很好，弹性拓展、容错性好、易于管理、便于观察，但是，云原生的优势对应的是其高昂的实现和落地成本。对于绝大多数企业来说，想要在自己的企业中应用云原生绝非我们说的那么简单。云原生整个生态中包含了大量的软件设备、硬件基础设施、开发运维成本等，对于绝大多数的企业来说，绝非易事。

对于不少企业来说，其核心是自己的业务逻辑，而非处理容器编排、自动化测试、微服务等，企业的需求只是让自己的业务可以更加的平稳、高性能的运转，服务好自己的客户，解决客户的问题，赚取收益。

对于这些企业来说，他们希望能够被云原生赋能，但又无法支撑起高昂的落地费用和维护成本，毕竟，看起来云原生所使用的各种组件都已经开源，企业都可以免费使用，但免费使用不意味着好用。作为云原生容器编排的首选工具，Kubernetes 的学习成本很高且安装部署极为复杂，更不用说云原生还需要配合各种组件搭配使用，还要和网络、存储等基础设施配合使用，学习成本，使用成本极高。

对于企业来说，亟需一款能够帮助他们解决云原生基础部署和配置的产品，帮助他们抹平云原生落地场景下所需的各项应用，打通网络、存储等基础设施，让云原生变得开箱即用。

QKE —— 极简的云原生方案

青云QingCloud很早就感知了这个问题，并在 2018 年开发了 KubeSphere ，解决了云原生组件落地的使用和管理问题，让更多的开发者从学习 Kubernetes 的命令中解脱出来，借助 KubeSphere 的 GUI 来完成各项管理控制操作。

为了帮助企业快速稳定地落地云原生，青云又推出了 QKE （QingCloud KubeSphere Engine） 服务，是在青云QingCloud公有云上提供的 KubeSphere 容器服务，整合了来自青云公有云的计算、网络、存储资源，彻底抹平云原生落地的成本。

QKE 是基于青云QingCloud 数年的基础设施研发经验而来的，青云有自己的网络产品、存储产品，在 SDN 、存储方面有着大规模云平台经验和应用，可以很好的解决企业所需要的弹性拓展等问题。 QKE 基于 KubeSphere 提供的 Kubernetes 的标准接口，对接了青云的各项基础设施，可以让企业可以更加轻松的完成基础设施的调用和配置，为开发者屏蔽掉底层的基础设施、运维问题，更加专注于应用本身的日常开发、运维等工作。

同时，由于 QKE 是基于 KubeSphere 提供的，QKE 也支持了构建多云和混合云环境，只需要简单的配置，就可以将公有云中的 QKE 和部署在客户私有云或其他云环境的 KubeSphere 整合在一起，轻松的构建一整套高可用、高性能的云原生应用架构。

如何在 10 分钟内构建云原生方案？

QKE 的使用十分简单，对于绝大多数人来说，都可以在 10 分钟内构建出一套完整的云原生运行平台方案。

1、准备工作

创建 QKE 服务之前，需要创建相应的私有网络和 VPC ，以方便后续构建 QKE 云原生集群使用。

此外，还需要创建一个 API Key，用以后续 QKE 帮助你自动调整网络及存储相关的配置。

这样就完成了基础的准备工作

2、选择配置

准备工作完成后，就可以开始选择 QKE 所需的配置了。

根据实际的情况，选择所需的配置、私有网络、计费方式等。

再选择 QKE 所使用的 API KEY 和对应的公网 IP ，就可以点击创建了。

3、创建成功

点击创建后，会自动进入到 QKE 的管理控制台中。在这里可以看到 QKE 帮助开发者自动创建好了所需要的集群。

4、体验管理控制台

点击确认后，稍等几分钟，当看到所有的节点都变为活跃状态，就说明集群已经正常运行，就可以开始体验 QKE 提供的管理控制台了。

点击 QKE 集群详情页的 “KubeSphere 控制台链接” 标签页，找到其中的 KubeSphere 控制台地址，并使用账号 [email protected] ，密码 P@88w0rd 即可登录到 KubeSphere 上，享受来自 KubeSphere 提供的 CI/CD、微服务管理、集群运维管理等功能。

整个 QKE 创建的过程流畅，一气呵成，十分钟，就可以轻松的部署一个 QKE 集群，十分的方便。

QKE ：开源与云的完美结合

开源社区的兴盛近几年有目共睹，但开源社区的最大问题在于，过于理想化和技术化，这使得整个产品在可用性、产品化方面举步维艰。QKE 的出现是一个很好的开源与云计算的结合。

一方面， QKE 可以借助开源项目 KubeSphere ，吸收来自开源社区的优秀创意和修改，让用户体验得到提升，用户能力得到拓展。

另一方面，QKE 基于云计算构建，可以让开源产品得以产品化，让过去难以落地的云原生现在触手可及。对于一些技术能力储备没有那么充沛的企业来说，也可以轻松用上云原生方案，享受云原生带来的企业和商业价值。

总结

QKE 的出现，是开源的一小步，更是云原生的一大步。对于开源来说，产品化的路径被打通，后人可以借鉴。从云原生来说，QKE 的出现让过去需要数十个人，数人日的工作，被缩短为 10 分钟，大大的提升了云原生普及的可能。

在第一篇文章中，我提到，项目的自动部署是放在 now.sh 上，以方便预览。但出于用户体验和速度的考虑，我们选择了国内的七牛云作为页面的承载。不过，七牛毕竟是一个对象存储，而不是一个专业的静态托管业务，在使用上遇到了一些坑，还好经过努力都得到了解决。

七牛的 Bucket 名规则

和绝大多数的云计算厂商一样，七牛也使用了 Bucket 来作为存储的单元。

由于这个项目要挂 Linux.cn 的二级域名，于是我便让老王创建了一个 Bucket，绑定域名，并通过七牛自带的权限控制机制，将其分发给我，让我来使用。

在我的个人控制台看到了这个 Bucket：

发现问题

我通过控制台，手动上传了生成的文件后，确认没有问题，就将相应的功能写入到 Github Action 的 配置文件（配置文件点这里）中，实现自动的部署。但在部署过程中，屡次报错，不知道为什么。在开启了 DEBUG 信息后发现，竟然是 Bucket 不存在（点我查看 CI 的构建信息）。

解决问题

和老王沟通以后才发现，是七牛的 Bucket 名机制的问题。

在七牛中进行权限分配的时候，会要求你为 Bucket 设定一个别名，而且名字和已有的名字必须是不同的，这导致我看到的 Bucket 的名和老王创建的 Bucket 名是不相同的。

而我使用的 AK 和 SK 又是让老王设置在 Github 后台的 Secrets，Bucket 则是我自己设置的，所以就出现了问题。具体来说，是下面这张图。

由于我填写的 Bucket 是我自己看到的，而不是老王那边真正的 Bucket 名称，导致在上传的时候，无法找到 Bucket。在将 Bucket 名称替换为老王那边看到的 Bucket 名称后，问题得到解决。

七牛不支持 Vue Router 的 History 模式

在第二篇文章中，我提到了引入了 Vue 的 History 模式来优化体验。但是，七牛本身作为一个存储系统，没有转发的功能，也就导致其没有办法很好的支持 Vue History 模式。

在经过一番研究后，找到了解决方案，就是将 index 页面，同时作为 404 页面，这样就可以实现从某种意义上的将所有请求都转发给 Index 页面。

你需要做的，就是将 index.html 复制一份，并重命名为 errno-404，并和其他文件一同上传，这样用户请求一些不存在的文件时，会自动将请求转发给 errno-404， 又因为这个文件的内容是索引文件的内容，所以就可以实现了请求的转发。

相关代码的实现，你可以在 https://github.com/LCTT/tldr.linux.cn/blob/master/.github/workflows/nodejs.yml 这里找到。

总结

在这篇文章中，介绍了七牛的 Bucket 问题，以及 Vue Router History 模式在七牛下的解决方案。