灵雀云出席腾讯Techo开发者大会，揭秘灵雀云开源实践

11月6日，腾讯Techo开发者大会在北京召开，开源做为与大会紧密关联的新关键词，贯穿会议始终。灵雀云DevOps研发负责人Daniel在云原生技术实践会场应邀作了“灵雀云云原生产品实践之路”的主题演讲。他结合灵雀云的发展历程和产品经验分享了灵雀云自身的云原生之路，尤为是围绕Kubernetes管理网络和Helm分发改进的开源项目实践。

灵雀云五年云原生之路

他总结指出，灵雀云的代码交付方式经历了从以前最先的源代码、容器镜像、Kubernetes  yaml，到现在的Chart方式。灵雀云业务最先以提供公有云容器为主，前后发展为提供多集群、私有PaaS平台到如今的私有云原生PaaS平台。交付流程自己也有很大的变化：从最先期的构建，衍变成持续集成、CICD，到目前的DevOps集成。

2016年，灵雀云开始将整个产品包在容器里面去部署，交付频率能达到每周2次部署，每次1小时，迭代过程相较于以前基于单体应用提高50%。此时也是灵雀云开始普遍接触企业客户的起始点，灵雀云发现客户维护庞大复杂的单体应用很是困难，发布、合并代码等都面临诸多问题。所以开始容器微服务化自身的产品，同时将产品部署和维护到多个环境中。

2017年Kubernetes技术成为主流，灵雀云产品开始微服务化。在测试方面，除了手工测试，持续集成的逻辑出现。Daniel介绍到，部署频率可以实现每周上线10次，每次10分钟。此时在业务层面开始作私有部署，产品团队须要不断思考此前依赖公有云服务的产品，在私有云环境中如何实现，这些给产品的思路带来很是大的影响。

2018年随着数字化转型的进程，更多的客户和研发团队产品迭代过程开始发生变化，须要找到更好的替代产品。同时，回归测试占据了测试人员的大部分时间，须要提高交互能力和速度。并且此时，Kubernetes已成为容器编排的事实标准，灵雀云开始深刻了解Kubernetes自己的设计理念和扩张机制，积极重视Istio、Service Mesh服务网格等技术，并研发了独立的Service Mesh产品。

今年，灵雀云又进行了产品架构的重大升级，全部产品架构变成基于Kubernetes的原生架构。在交互部分，拥有了很是典型的交互方案。在流程里面，自动化测试变成须要在研发过程当中完成的一部分。每次发布一个新的功能，对应的自动化测试也已经存在，合并以后变成回归测试的一部分。交付升级到天天发布50次，每次5分钟。

要快速迭代，快速验证自身业务，灵雀云会提供相关的产品和工具帮助客户快速落地。

当引入至关的微服务以后，企业一般会面临另外的问题，即微服务治理。由于微服务架构的本质是以运维的复杂度为代价来换取敏捷性。微服务治理须要完整的基础设施去支撑。为此灵雀云也会针对不断出现的客户需求和问题，开发产品层面的解决方案。今年即新推出了API层面的新产品——企业级API管理平台Alauda API Management platform（AMP），帮助以稳态业务占大比例的传统企业客户进行云原生应用架构的落地。

Kube-OVN & Captain  两大开源项目实践

随后Daniel讲述了在Kubernetes管理过程当中，灵雀云踩过的一些坑，及由此引出的相关探索和项目实践。

 

他表示，Helm是灵雀云核心的迭代工具，Helm的准确率相当重要。若是自动化多了，任何数据都会变成复杂的问题。升级是开发过程的平常操做，任何新的迭代都须要升级到不一样的环境里。灵雀云在此中遇到的问题是，除更新组件外，不少时候应用自己须要调整，chart改动没法保证平滑升级，或者chart删除组件式没法自动清理。更改时会出现，要么可能更改失败，要么会有垃圾数据存在。

Helm 2 自己存在一些问题，如没有使用Kubernetes框架、Release 跟 Tiller 绑定、资源容易冲突、CRD/Hook 设计等。所以当Helm 3设计出来后，灵雀云研发了Captain项目，是一个基于Helm v3标准的Kubernetes Controller，对Helm应用分发进行改进。由此来应对前述Helm存在的问题。

Captain帮助用户简化Helm资源描述，更便捷、高效地实现Kubernetes应用的管理和控制，推动Helm项目向原生 Kubernetes迈进的步伐。相较Helm官方，Captain的优点在于：Helm v3 变成 CLI 工具，Captain 除了kubectl插件还提供Kubernetes 的 Controller 模式，相关的资源变成 CRD，能够在Kubernetes管理。

另外一重要开源项目Kube—OVN，解决的是OVN网络和Kubernetes集成的问题。做为私有化云平台总会遇到一些特殊的网络方面的要求。Kube-OVN提供了大量网络功能，并在原有基础进行加强。经过将OpenStack领域成熟的网络功能平移到Kubernetes，来对应企业应用合规性要求。OVN网络架构支持企业级应用网络场景和要求：

统一网络的数据面，包括Pod 网络，Service，DNS，NetworkPolicy等；覆盖全部已知开源网络插件的功能（固定IP，QoS，IP 暴露，网络加密，UI……）；平移 OpenStack 的网络设计概念到 Kubernetes（VPC，Subnet，Multi-Tenancy）；尽量的易于使用，安装条件，默认配置，默认功能，监控工具。

他最后强调，目前两大开源项目均已展开使用，欢迎你们试用，同时给出您的反馈。