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


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


灵雀云五年云原生之路

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

pic2.jpg


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

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

pic3.jpg


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

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

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

pic4.jpg


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

pic5.jpg


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

pic6.jpg


随后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);尽可能的易于使用,安装条件,默认配置,默认功能,监控工具。

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

0 个评论

要回复文章请先登录注册