专访UCloud徐亮：UCloud虚拟网络的演进之路

但是UCloud目前并没有采用K8S，事实上，UCloud所开发的IaaS控制面程序，本身就和K8S的功能类似。并且，UCloud有大量的既有服务。K8S的网络方案比较复杂，且性能堪忧，再通过IPTables来透明引流确实是雪上加霜，给未来的运维、Trouble-Shooting带来了很高的复杂度。目前UCloud主要使用gRPC和HTTP，但仍有数据库服务等业务不适合跑在K8S中，而K8S的网络方案需要能够兼容现有的数据库等业务。

经过对Istio代码的预研之后，UCloud最终选择了将Pilot从Istio中剥离出来，脱离K8S运行的轻量级ServiceMesh方案。在Istio中Pilot是作为Envoy的控制面提供集中式流量管理功能的模块，这是实现灰度发布必不可少的功能，事实上也是ServiceMesh的核心功能。Mixer提供的访问策略和控制，Istio-Auth提供安全认证功能，相对来说在UCloud的内网环境下，都可以裁剪掉。

而得益于Pilot的良好设计，很容易实现ETCD Platform，从ETCD获取Service和Service Instance信息。UCloud重写了Pilott的main.go，保留了Pilot的model、proxy和proxy/envoy模块，删除其他的Platform仅保留新增的ETCD Platform。

最后在保留完整的Istio DSL支持的同时，得到了完全脱离K8S运行和编译的Pilot。同时将Pilot和ETCD gRPC naming and discovery做了深度整合，自动剔除没有在线的ServiceEntry。

在脱离K8S后，仍然需要采用Sidecar的部署方式。UCloud采用container的方式打包和部署微服务，但采用Host的网络方式，简化了和现存服务的网络通信方式。同时利用docker-compose模拟K8S的POD，管理服务间的依赖。通过实现一个简单的服务管理、版本管理、集群管理、路由策略管理层，为集群中的每台Node(VM或物理服务器)生成docker-compose配置文件，实现每台Node的服务部署和管理。

最后针对HTTP 1.0、HTTP 2.0和gRPC的RPC方式，采用显式代理而不是IPTables透明引流和Envoy集成。如果服务中配置了Envoy的Proxy Port，则通过Envoy接入ServiceMesh;如果配置是IP地址和端口，则直连这个地址;如果配置的是域名且没有配置Envoy的Proxy则自动采用ETCD gRPC naming and discovery的方式去发现远端服务。

最终，UCloud轻松利用Pilot和Envoy实现了按用户灰度发布，目前该ServiceMesh框架已经在UCloud多个项目中使用。

后记

加入UCloud虚拟网络团队三年多，徐亮深刻地认识到这个领域百家争鸣，仍然在快速变化中。但 “Software is eating the network” 这个趋势始终清晰可见。从最早的SDN、软件vSwitch到智能网卡、可编程交换机，软件在网络中的作用越来越重要。

“同时密切关注网络和软件两个领域的发展，消化吸收符合自身需求的新技术，才能够跟上UCloud用户的发展，为客户提供稳定的服务，提供符合客户需求的、易用和低成本的产品。”徐亮总结道。

【51CTO原创稿件，合作站点转载请注明原文作者和出处为51CTO.com】

（编辑：厦门网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!