云原生漫游指南3 从容器网络建设说起

原标题：云原生漫游指南3 从容器网络建设说起

上一期《云原生漫游指南（2）丨从CI&CD到计算存储分离》的最后，我们介绍了计算存储分离如何提升容器的灵活性。解决了容器的构建、运行和编排，接下来我们需要进行容器网络的建设，容器之间可以按照用户的预期进行网络打通或隔离是如何实现的呢？

本期《云原生漫游指南》就将从解决这个疑问开始，继续介绍云原生路径中的三个关键站点。

第六站

容器网络建设

在大量的云原生转型案例中我们发现，容器网络的实现往往是搭建容器平台中客户面临的最大挑战之一，因此在建设云原生架构之前，尽早对容器网络进行规划至关重要。

容器网络需要解决的核心问题在于：容器本身的网络通信依赖于其所在的宿主机上的网络设备，然而容器在调度过程中又可能随时在不同宿主机之间“迁移”。因此需要一套方案来解决容器间的通信与路由问题，并且充分考虑容器的灵活性、扩展性以及IaaS层不同网络实现等因素。

CNI（Container Network Interface）是由Google和CoreOS主导制定的一个容器网络标准，其核心目的就是只要提供一个标准的接口，就能为同样满足该协议的所有容器平台提供网络功能。这样云供应商就可以基于CNI开发自己的专属接口，让Kubernetes等平台的使用者无需感知到底层网络实现的差异，并实现为容器提供一个对应的网络空间、自动为容器分配IP地址等能力。

目前主流的CNI实现方案可以分为隧道方案和路由方案两类，核心差异就是在转发容器间的通信时是否需要对数据包进行再次包装。

如Calico就是典型的路由方案，通过BGP路由协议在集群中所有的节点上记录全网路由，让容器间可以通过IP直接通信，流量经过源容器所在的宿主机，到达数据中心路由，然后转发到目的宿主机并分配到目的容器。路由方案不需要额外增加封包和解包的过程，因此转发效率更高，但是由于有大量的路由信息需要记录，因此对网络设备的要求更高。

百度智能云CCE为用户提供了两种不同的网络方案：VPC网络模式和CNI插件模式。

其中VPC网络模式直接利用云上私有网络中的路由表进行路由规则记录，不会带来任何额外的资源开销，同时提供高性能的转发能力，但是受限于VPC路由网关的并发瓶颈，所以对集群规模会有限制。而CNI插件模式则利用了最新的弹性网卡特性，通过多网卡来为容器直接提供IP地址，从而满足容器网络和节点网络完全在同一网络层面，提供更高的网络性能。

第七站

服务通信框架

在容器间网络打通之后，我们需要考虑部署在容器内的服务如何互相通信。

在传统的单体应用开发中，由于系统间不同的服务都部署在一个空间中，因此服务之间通信通过本地函数调用即可，不需要考虑服务间的信息如何传递。而在云原生的架构中，不同服务可能部署在不同的容器并分布到不同服务器中，因此我们就需要构建起服务间的统一通信机制。

Restful架构是一种常见的服务件远程调用方式，当服务A需要被远程访问时，可以暴露一个Restful接口，其它服务即可通过访问这个Restful接口来调用服务A中的特定方法。

API其实也就是一个一个的URL，因此不同服务之间只需要利用HTTP协议，从发送端发送到接收端传输json对象，而互相不需要关心具体的开发语言和实现方式。

Restful是一种轻量级、高度标准化和跨语言的服务间通信方式，非常适用于系统间或者对外的服务暴露。它的缺点在于所有的通信都基于http协议，因此每次远程访问都需要在代码中建立http连接，客户端必须知道服务端的地址，对开发者不够友好。同时http请求支持的动词是非常有限的，在面对复杂业务时会导致接口的语义不够明确，因此Restful并不适用于系统内部的服务间调用。

相比之下RPC（Romote Procedure Call）是更适合于复杂系统内部的服务间通信方式，

RPC作为一种面向过程的服调用方式，在服务件远程调用时，能够像本地调用一样方便，让调用者感知不到远程调用的实现逻辑。为了实现这一点，除了服务提供方需要暴露可供远程访问的接口外，服务调用方还需要一个Client Stub （客户端存根）存放服务端的地址消息，再将客户端的请求参数打包成网络消息。RPC原理的具体实现框架有很多，如Google开源的gRPC框架、百度开源的bRPC框架等。

由于Restful和RPC各自有不同的适用场景，因此一个企业级的系统中往往是两种远程调用方式并存的。百度云原生微服务应用平台CNAP也充分考虑到了这种场景，同时支持对Restful和RPC接口的数据采集，从而在追踪请求链路和查看服务拓扑时能够整合两种类型的请求，为用户呈现出一个完整的服务间通信网络。

第八站

可观察性建设

当应用以容器化的方式运行在Kubernetes集群上，并且可以正常进行网络通信后。下一步需要考虑的问题，就是如何保障应用按照预期的状态可靠运行。

这时候我们就需要引入“可观察性”的概念，和可用性、可扩展性一样，可观察性是一个非常重要的非业务需求，它要求开发运维人员能够主动规划系统运行过程中的关键指标、随时对这些指标进行监控、并且汇总这些指标以用于分析和预测。

可观察性又可以拆分成很多层面：

• 对资源使用的观察，可以帮助优化平台的资源配置；
• 对应用运行状态的观察，可以及时发现系统中微小的故障并尽早恢复；
• 对应用日志的观察，可以分析应用运行的过程和内部逻辑是否符合预期；
• 对服务间交互和调用的观察，可以帮助发现整个系统的性能瓶颈从而提出优化方案；
• 可观察性的建设主要基于三类基本要素：日志（logging）、指标（metrics）、追踪（tracing），这些要素分别从不同角度记录系统的运行，同时也需要不同的工具来进行采集。

在面对不同的场景和不同角色的需求时，往往需要对这些要素进行灵活使用和组合，比如一个开发人员可能需要从logging中分析细节，而运维人员则更关注tracing与metrics之间的联系。所以一个优秀的云原生架构中，不仅要提供对丰富的各类元素进行观察的能力，也需要支持高度自定义的汇聚、分析和报警的策略。

在云原生开源社区中，opentracing和jaeger是tracing领域的典型工具代表、fluentd、kibana等专注于logging，而prometheus则是metric方向最热门的技术栈。

百度智能云为了降低用户对这些不同工具的整合成本，在云容器引擎（CCE）和云原生微服务应用平台（CNAP）中提供了基于这些开源工具的一站式方案，在最小化性能损耗的情况下提供丰富的观察要素采集，同时在统一的界面完成自定义的数据汇总、分析和报警配置。

生成海报

免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。