对云原生集群网络流量可观测性的一点思考
发布时间：2022-07-14 09:34:03 所属栏目：云计算 来源：互联网
导读：问题背景 在云原生技术的广泛普及和实施过程中，笔者接触到的很多用户需求里都涉及到对云原生集群的可观测性要求。实现集群的可观测性，是进行集群安全防护的前提条件。而在可观测性的需求中，集群中容器和容器之间网络流量的可观测性需求是其中一个比较重要
|
问题背景 在云原生技术的广泛普及和实施过程中，笔者接触到的很多用户需求里都涉及到对云原生集群的可观测性要求。实现集群的可观测性，是进行集群安全防护的前提条件。而在可观测性的需求中，集群中容器和容器之间网络流量的可观测性需求是其中一个比较重要的部分。对于容器网络的流量采集，其实施难度是大于传统主机网络的流量采集的。 那么容器网络的复杂度到底在哪里？如何更好的去适配容器网络？这里笔者结合在工作实践中的一些积累，在本文中给出一些关于云原生集群网络流量可观测性的一点思考，希望能起到抛砖引玉的效果。 CNI 插件 目前在云隙（自适应微隔离）产品云原生场景适配的过程中，已经遇到过如下的一些 CNI 插件： Flannel—— 默认为 Vxlan 的分布式网关模式，可选择 host-gw 模式，也可以选择 udp 模式（早已被淘汰的一种模式） Calico—— 默认的 BGP 模式，使用 IPIP 隧道进行跨节点容器间数据的转发，当然也可以不用 IPIP 隧道模式（类似于 Flannel 的 host-gw 模式） Openshift-SDN—— 基于 Openvswitch 技术，是一套基于 SDN 技术的网络方案 OVN-Kubernetes—— 基于 Openvswitch 中的 OVN 方案，其实和 Openshift-SDN 是差不多类似的体系，只是在架构和细节上做了更多的云原生优化 现有问题 上述几类插件是大多数云原生环境中常见的 CNI 插件，并且它们本身也涵盖了容器间网络所使用的大部分技术。而在对以这几类 CNI 插件基础的容器网络进行流量信息采集的过程中，笔者发现并不能用一种模式完成所有的采集功能。例如在有的 CNI 插件中，我们需要把宿主机当作一个网络中转设备，在主机上利用旁路的方式检测容器网络流量的变化情况；而在有的 CNI 插件中，我们没法在宿主机上直接观察到任何容器网络的流量信息，需要进入到容器的网络命名空间中去完成采集工作；甚至在有的 CNI 插件中，我们无法抓到两个容器之间的直接访问关系，必须要配合这个 CNI 插件本身实现的技术原理，通过更多的分析来完成对访问关系的确定。 所以，在进行容器网络流量的可观测性方案实施之前，需要对相关 CNI 插件做进一步的分析，来帮助理解为什么不同的 CNI 插件兼容适配的要求会有不同。 插件分析 Flannel 插件的原理 Flannel 是 CoreOS 团队针对 Kubernetes 设计的一个覆盖网络（Overlay Network）CNI 插件。它可以配置为很多种工作模式，目前默认的工作模式是 Vxlan，是一个虚拟的二层网络。 组件概述 npHfHJch_5RUn.png 图1 Flannel 是以 DaemonSet 的方式部署在 Kubernetes 集群中。一个完整的 Flannel 架构中包含了如下的一些组件： etcd—— 这是 Flannel 所依赖的配置中心，每个节点上的 flanneld 都会依赖这个 etcd 组件来实现协调和同步。在一般的部署方案中，这个 etcd 是直接复用的 Kubernetes 控制层平面的 etcd 组件，所以一般也没有单独部署。 flanneld—— 每一个宿主机节点之上都会启动一个 flanneld 服务，目前默认是基于 Vxlan 的配置工作模式，在这种模式和 host-gw 模式下，flanneld 都主要承担了一个旁路配置管理的工作。而在 UDP 模式下，flanneld 还要承担数据的转发工作，由于该方案本身有严重的性能问题。所以早已被放弃不用。 网络模式概述 总的来说，Flannel 是一个二层的网络解决方案。就其默认的 Vxlan 工作模式来说，可以看作是应用 Vxlan 的分布式网关架构组建了一个二层的通信网络。在这种架构下，宿主机中的虚拟网卡 flannel.1 可以看作是一个作为 Vxlan 二层网关和三层网关的 leaf 节点，而宿主机本身的网卡则可以看作是用于转发的 spine 节点。 runJZtQZ_JwAx.png 图2 在这种网络环境下，跨界点的容器通信在接收端其实是无法直接抓到来自于发送端的 IP 地址的，因为在三层转发的时候，发送端的 IP 就已经被替换为了网关的地址。如果从旁路的角度来看，宿主机上也无法直接观察到容器间流量。如果能观察到，一般都是节点自身两个容器之间的连接，因为它们本身处于一个二层网络中。同时，在这种环境中，如果使用 SideCar 模式去容器网络命名空间下进行观测，也会发现由于这个虚拟二层网络本身存在三层转发的网关，我们依然无法直接采集到两个容器之间的连接关系。 如果是 host-gw 模式，那么宿主机就会被纯粹配置一个三层转发的网关，虽然不走 Vxlan 这样的隧道了，但是由于三层转发的存在，我们依然无法直接观测到跨节点容器通信的网络关系。 综上所述，在观测基于 Flannel 的网络流量之时，一定要结合 Flannel 的架构本身，将三层网关的转发特性考虑到网络连接关系的梳理过程之中，才能真正地梳理出实际的连接关系。这样的网络架构，也是网络流量观察的一个难点。 Calico 插件的原理 Calico 是一套开源的网络和网络安全方案，用于容器、虚拟机、宿主机之间的网络连接，可以用在kubernetes、OpenShift、DockerEE、OpenStrack 等 PaaS 或 IaaS 平台上  （编辑：汕尾站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
站长推荐
热点阅读
