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）；尽可能的易于使用，安装条件，默认配置，默认功能，监控工具。
他最后强调，目前两大开源项目均已展开使用，欢迎大家试用，同时给出您的反馈。