200 lines
13 KiB
Markdown
200 lines
13 KiB
Markdown
|
||
|
||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||
|
||
|
||
10 小试牛刀（二）：如何突破VPC网络的速度限制？
|
||
你好，我是静远。
|
||
|
||
在冷启动这节课里，我跟你聊到了影响函数第一次执行速度的因素有很多，其中一个关键因素就是：VPC网络的建联时间。
|
||
|
||
我们知道，VPC是云厂商提供给用户的一个安全隔离的网络环境，用户可以在VPC空间中部署自己的服务，如Redis、数据库、MQ等。而我们的函数通常是创建在函数专属的VPC中的。一个生产级别的函数服务应用，少不了需要和其他的资源和中间件打交道。那么，跨VPC之间的通信效率就显得尤为重要了。
|
||
|
||
今天这节课，我就针对VPC之间的通信效率，通过案例实操的方式，为你剖析函数在跨VPC上的技术要点。
|
||
|
||
希望通过这节课，能够让你得到一些在Serverless的实战和后续优化工作的启发，能举一反三地找到更多优化方法，进一步突破函数访问速度的上限。
|
||
|
||
跨VPC问题的演进
|
||
|
||
针对云上网络连接的方式，相信你已经了解到不少，如专线（高速通道）、VPN网关、对等连接等方式。这些方式，有的用来解决IDC和VPC的连接，有的用来解决VPC与VPC之间的互通。
|
||
|
||
这其中，对等连接的确可以解决函数跨VPC的问题，但我们试想一下，如果每个用户都通过这种方式来解决这种问题，那么平台每次都需要搭建两端的连接，并且还可能会遇到IP网段冲突的问题。这样的做法显然不具备普适性，成本也过高。
|
||
|
||
为此，针对Serverless的函数计算场景，我们通常会通过弹性网卡（ENI）的方式来打通。弹性网卡是绑定在云主机或者容器实例上的，也就是说，我们是通过弹性网卡ENI来关联用户的VPC和用户的设备实例，使得设备和VPC互通的。
|
||
|
||
|
||
|
||
|
||
|
||
但实际上，我们暂且抛开这两者在网络速率上的差别，不论是在容器实例还是在主机上，他们都会面临同样的问题。
|
||
|
||
|
||
冷启动耗时较长：弹性网卡这种虚拟化的资源，它的创建时间是避免不了的；
|
||
资源受限：正因为资源虚拟化，也就意味着要依赖于硬件的基本参数，受限于内核、CPU等因素，为此，几乎所有的云厂商都会限制VPC内弹性网卡的数量，也就从一定程度上导致了此方法的局限性；
|
||
资源浪费：由于容器或者主机上要绑定弹性网卡，也就意味着多个实例就得占用多个网卡资源，造成资源浪费。
|
||
|
||
|
||
我们可以看出，它们虽然解决了跨VPC的问题，但还是会带来性能和资源成本上的压力。那么，我们是否可以不创建这么多弹性网卡，探索一种共用的方式呢？通常我们立马能想到的方式，就是出口代理了。
|
||
|
||
什么是代理？
|
||
|
||
如何代理呢？我们可以了解一下它的整体流程。
|
||
|
||
简单来说，就是我们在函数计算的集群与用户的VPC之间添加Proxy Node，在Proxy Node上构建网卡（如eth1），网卡会提前在用户VPC所在的子网Subnet中创建，但租户的权限属于函数计算VPC。
|
||
|
||
有了弹性网卡，接下来就需要解决函数到代理节点的打通问题了，也就是在函数的主机和代理主机之间构建一条链路，将数据包传递过去，且保证源IP和目的IP保持不变。
|
||
|
||
我们通常采用的是隧道技术。隧道打通后，我们还得注意两件事情。其一就是在Proxy Node中多张网卡的转发处理；其二，由于函数通常以容器的方式运行，所以需要有一个容器网络转发的过程。
|
||
|
||
接下来，我将一步一步介绍它们是如何起作用的。
|
||
|
||
动手实操
|
||
|
||
这节课，我会通过一个打通跨VPC网络的实验案例，带你实现函数通过Proxy机器代理的方式访问用户VPC的资源的全过程。在这个案例中，我选取了百度智能云服务器BCC来进行实验。
|
||
|
||
在实验之前，我们需要准备两个VPC网段，模拟创建函数集群和用户集群，并在云上购买三台云服务器BCC，其中2台BCC在VPC1，另外1台在VPC2。下面这个图可以清晰的描述部署的逻辑：
|
||
|
||
|
||
|
||
隧道技术
|
||
|
||
准备工作完成之后，我们来看隧道技术。
|
||
|
||
什么是隧道？在网络中，隧道是一种使用网络不支持的协议，构建网络之间高效和安全的链接，实现在网络中传输数据的方法。
|
||
|
||
内核中的tunnel可以通过ip tunnel help看到，当前有五个：IPIP、GRE、SIT、ISATAP和VTI。
|
||
|
||
|
||
|
||
本节课，我们选择使用GRE（Generic Routing Encapsulation），它是IPIP（IP in IP）协议的更进一步版本，从官方的描述上来看，可以取代IPIP。隧道技术本身的概念和区别不是本节的重点。不过，如果感兴趣的话，你也可以通过我文末给的延伸阅读深入了解。
|
||
|
||
接下来我们来创建隧道，使得func bcc1和proxy bcc能通过隧道打通连接。我们先在func bcc1中执行如下命令来创建GRE隧道：
|
||
|
||
# 加载GRE模块
|
||
modprobe ip_gre
|
||
lsmod | grep gre
|
||
# 创建gre模式的通道tunnel，关联上IP并赋予虚拟本端IP为10.0.0.3
|
||
ip tunnel add gre0 mode gre local 192.168.80.8 remote 192.168.4.4 dev eth0
|
||
ip addr add 10.0.0.3 peer 10.0.0.4 dev mgre0
|
||
ip link set dev mgre0 up
|
||
|
||
|
||
在proxy bcc上执行如下命令来打通GRE隧道：
|
||
|
||
modprobe ip_gre
|
||
lsmod | grep gre
|
||
ip tunnel add mgre0 mode gre local 192.168.4.4 dev eth0
|
||
ip link set dev mgre0 up
|
||
ip address add 10.0.0.4/24 dev mgre0
|
||
ip neigh replace 10.0.0.3 lladdr 192.168.80.8 dev mgre0
|
||
|
||
|
||
最后，我们还可以通过ping命令来验证proxy bcc与func bcc1的GRE隧道是否打通。
|
||
|
||
|
||
|
||
到这里，我们隧道的打通任务已经完成一半了，下面，我们要看proxy bcc如何与user bcc打通。
|
||
|
||
转发技术
|
||
|
||
我们注意到，proxy bcc和user bcc是不在一个VPC集群内的。那我们要怎么解决这个问题呢？
|
||
|
||
构建的逻辑就是在user vpc下构建一个虚拟网卡eth1，而eth1，又隶属于proxy bcc下。这个方法，和我们在上面“跨VPC的演进”中讲到的“动态创建网卡”的方法是一致的。
|
||
|
||
这里需要说明一点，如果你是一个业务函数的开发者，可能云厂商没有开放相应的特权账号，没有创建弹性网卡的能力，实操不了，那么，这里你只要了解过程即可。如果你是云平台维护工作者，可以体验一下这其中的操作方式。
|
||
|
||
弹性网卡创建并绑定好后，我们会发现，有2个网卡存在于proxy bcc中。
|
||
|
||
|
||
|
||
我们通过ping命令，可以验证是否能够和user bcc打通。这里要注意，proxy bcc与user bcc可以互通是因为弹性网卡是基于user bcc所在的VPC的子网Subnet创建的，但租户还是属于proxy bcc。
|
||
|
||
|
||
|
||
打通之后，我们就需要用到转发技术了，也就是将func bcc1的数据包通过proxy bcc的请求到达user bcc。
|
||
|
||
首先，我们需要通过将ip_forward设置为1，开启proxy bcc的转发能力。
|
||
|
||
echo 1 > /proc/sys/net/ipv4/ip_forward
|
||
|
||
|
||
这里需要说明一下，出于安全考虑，Linux系统默认的是禁止数据包转发的。所谓转发，就是当主机拥有多于一块网卡时，其中一块收到数据包，根据数据包的目的IP地址将包发往本机的另一网卡，该网卡即会根据路由表继续发送数据包。
|
||
|
||
我们这里因为是eth0接收云主机的数据，通过eth1来发送出去，所以需要开启转发能力。当然，为了能让func bcc1的路由触达user bcc，我们还需要继续完善路由规则。
|
||
|
||
我们在func bcc1中通过ip route add命令添加一条到user bcc子网172.16.101.0/24的路由：
|
||
|
||
ip route add 172.16.101.0/24 dev mgre0
|
||
|
||
|
||
此时 func bcc1 访问 user bcc 172.16.101.4 仍然访问不通，在 proxy bcc 侧监听 eth1 流量可以发现，eth1 发往用户 VPC 的包的源 IP 仍是 func1 bcc gre0 设备的 IP 10.0.0.3，这个 IP实际只存在于我们 bcc 内部，因此用户 bcc 收到请求后，它的返回流量无法路由到这个 IP。
|
||
|
||
因此，我们这里需要在proxy bcc添加一条 iptables 规则，在 POSTROUTING 链里把从 eth1 出口的流量的源 IP SNAT 设置为 eth1 的IP 地址，即 172.16.101.4。
|
||
|
||
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
|
||
|
||
|
||
到这里，我们就可以在func bcc1中ping通user bcc了。
|
||
|
||
|
||
|
||
容器网络
|
||
|
||
在虚机上，我们已经操作体验一遍了，但通常我们的函数是在容器实例里面运行的 的，容器在访问用户vpc服务的时候，是存在一点差别的。我们也可以验证一下，会发现，pod 发起的请求正常路由到了 proxy bcc 下的 tunnel 设备，但是没有继续转发到 eth1 中。
|
||
|
||
为什么会出现这样的情况呢？通常是因为Pod的IP和我们在proxy bcc上构建的路由规则是不一致的。至于怎么解答，我先不做回答，你可以先思考一下。我们先来看一个概念：ip-masq-agent。
|
||
|
||
ip-masq-agent 是一个用来管理 IP 伪装的扩展，即管理Kubernetes集群节点中 IP 网段的 SNAT 规则。它以 DaemonSet 形式部署在Kubernetes的集群中，在每个节点上启动一个代理程序。代理程序通过配置 iptables 规则，再将容器流量发送到集群节点的 IP 和集群 IP 范围之外的目标时，就可以选择以容器自己的 IP 地址或伪装成节点的 IP 地址作为出向流量的源地址。
|
||
|
||
看完ip-masq-agent的解说，相信你已经有答案了。解决办法，就是把 Pod IP SNAT 设置成 gre0 设备的 IP，再转给 proxy bcc，再对 proxy bcc 隐藏 Pod的IP即可。
|
||
|
||
ip-masq-agent 的配置来自于 configMap，可以通过 kubectl edit cm 命令来查看或修改配置。
|
||
|
||
到这里，我们在Pod中也能访问user bcc的服务了。
|
||
|
||
高可用
|
||
|
||
如果我们要上生产环境，你还需要考虑服务的高可用。在我们这节课反复提到的案例图中，我只画了一个Proxy Node，用来实验还可以，但生产环境肯定是不够的。为此，我们需要为每个VPC/Subnet建立一对主备Proxy。主备Proxy要使用HaVip进行容灾切换。
|
||
|
||
HaVip是一种可以独立创建和释放的内网IP，可以与高可用软件（例如，KeepAlived）配合使用，搭建高可用主备服务，提高业务的可用性。
|
||
|
||
另外，从Serverless的角度看，你还需要依据函数访问的流量对Proxy Node进行自动扩缩容。当流量增大时，需要自动对Proxy Node进行扩容；当流量降低时，需要自动对Proxy Node进行缩容。
|
||
|
||
我们继续在上面的架构图上进一步完善一下，增加主备Proxy Node和容器Pod之后的架构示意图如下所示。
|
||
|
||
|
||
|
||
小结
|
||
|
||
最后，我来小结一下我们今天的内容。
|
||
|
||
这节课主要围绕着优化函数在跨VPC场景的访问速度来做讲解。我们学习了跨VPC打通的演进过程以及代理的四大要素，最后，也结合一个案例的实操过程，了解了函数代理技术的实现过程。
|
||
|
||
在演进过程的回顾里，我们会发现，对等连接由于其在函数计算上的构建不具备普适性，只有在极少数大客户的场景下会使用。而弹性的网卡实时创建，虽然具备一定的通用能力，但由于其高延迟和对资源的浪费，我们也不太推荐使用。
|
||
|
||
这两个技术，给我们来带来的思考是，如果我们能提前准备好访问的通路且可复用，是不是就可以解决这样的问题了？是的。为此，我们提出了函数代理技术。
|
||
|
||
其实，代理技术需要解决的技术卡点还不少，主要包括我们提到的隧道通路、网卡转发、容器网络转发技术，以及最后在生产环境下，还需要考虑到的高可用的问题。我们可以通过高可用的虚拟IP和主备Proxy集群解决。同时，从弹性的角度，我也建议你引入扩缩容的能力，这个能力，你也可以贯穿在整个Serverless的学习生涯中，可以说，它就是Serverless的精髓所在。
|
||
|
||
最后，函数计算由于其胶水语言的特性，跨介质跨网络的访问是不可忽视的一件事情。虽然我们已经在不断的演进解决，但函数代理技术也有其缺点的，比如资源一定程度上的增加。因此，希望通过这节课的内容和思考的过程，能让你打开眼界，提出更多的优化手段，让Serverless的技术积淀越来越深厚。
|
||
|
||
思考题
|
||
|
||
好了，这节课到这里也就结束了，最后我给你留了一个思考题。
|
||
|
||
如果我们在隧道打通那里，采用IPIP隧道协议，会有什么问题？
|
||
|
||
欢迎在留言区写下你的思考和答案，我们一起交流讨论。感谢你的阅读，也欢迎你把这节课分享给更多的朋友一起交流学习。
|
||
|
||
延伸阅读
|
||
|
||
|
||
你可以通过VPC的对等链接，继续深入了解一下对等链接的概念。
|
||
这一篇隧道技术，可以帮助你进一步了解隧道的知识要点。
|
||
腾讯云的这一篇VPC网络优化的文章，也是值得我们一看的。
|
||
文中提到的ip-masq-agent，感兴趣的话，你可以继续看这一篇ip-mast-agent指南，写得也是非常详细的。
|
||
|
||
|
||
|
||
|
||
|