本篇文章给大家谈谈空间说说网站源码分享，以及空间说说代码大全免费对应的知识点，文章可能有点长，但是希望大家可以阅读完，增长自己的知识，最重要的是希望对各位有所帮助，可以解决了您的问题，不要忘了收藏本站喔。
在上一篇文章中，我们简要地解析了eBPF内核独立子系统的基本概念、发展历史、架构模型以及优缺点等，具体可参考：LinuxeBPF解析。
随着云原生生态领域的逐渐完善，云操作系统，例如：Kubernetes，正在吞噬着整个容器世界，越来越多的厂商在匆忙地布局着基于云操作系统的相关平台，以便尽可能在有限的时间及空间内获得一杯羹，而此时，在另一端，蜂拥而至的企业们也在不断尝试将自有业务迁移至容器平台，以便享受新技术带来的革命性红利，一时间，Kubernetes仿佛成了云系统的代名词，火热的一发不可收拾。
基于此，我们可以清晰地看到：围绕不同的企业、不同的业务场景、不同的技术实现需求以及差异化的技术发展趋势，容器的部署密度越来越高，而伴随着容器的生命周期却越来越短。然而，随着业务场景的创新化，基于传统的技术或多或少在某种特定的场景下开始显得很鸡肋，已经开始无法支撑新的需求，于是，新的技术就应运而生，开始尝试解决这一业务痛点。
Cilium是什么，我们为什么要关注它？这就是本篇文章所要探讨的。
在我们所了解的云原生编排系统中，基于不同的业务场景驱动，微服务的架构也随之进行着不断的演进，而此时，我们所依赖的云操作系统网络也因为各种诉求也随着更替，从最初的Flannel、Calico以及到现在的Cilium等。从本质上讲，Cilium是一个基于eBPF之上的通用性抽象，即Cilium对eBPF进行了封装，并提供了一个更上层的API，使得其能够覆盖分布式系统的绝大多数场景。为什么eBPF如此强大，使得其能够获得青睐？主要取决于以下3方面，具体如下所示：
Fast-快速
eBPF技术无论是基于何种场景，几乎总是比Iptables快，相对于Iptables，eBPF程序较短。Iptables基于一个非常庞大的内核框架（Netfilter），此框架出现在内核Datapath的多处，冗余性较高。因此，我们在实现类似ARPDrop这样相同的功能时，基于Iptables技术，冗余就会显得非常笨重，从而导致性能很低。
Flexible-灵活
基于eBPF，我们可以实现任何想要的需求，这或许也是最核心的原因。eBPF基于内核提供的一组接口，运行JIT编译的字节码，并将计算结果返回给内核。在此过程中，内核只关心XDP程序的返回是PASS、DROP还是REDIRECT。至于在XDP程序里做什么，完全无需知晓。
SeparatesDatafromFunctionality-数据功能分离
在内核体系中，Nftables和Iptables也可以将数据与功能进行分离，然而，经综合对比，2者功能并没有eBPF强大。例如，eBPF可以使用Per-cpu的数据结构，因此其能取得更极致、优越的性能体验。
从本质上讲，eBPF真正的优势在于能够将“数据与功能分离”此项事情做的非常干净（CleanSeparation）甚至完美。也就是说，可以在eBPF程序不中断的情况下修改它的运行方式。具体方式是修改它访问的配置数据或应用数据，例如黑名单里规定的IP列表和域名。具体可参考如下：
我们来看下Cilium的相关概念及架构，基于Cilium机制，其通常要求运行于LinuxKernel4.8.0及以上版本，官方建议Kernel版本至少在4.9.17以上，若运行环境为Ubuntu，则建议其发行版中Linux内核版本一般为4.12以上，若基于CentOS7，则需要升级才能运行Cilium。为方便起见，Cilium一般跟容器编排调度器使用同一个KV存储数据库，例如在Kubernetes中使用etcd存储。
接下来，我们了解下Cilium的组件示意图，Cilium是位于LinuxKernel与容器编排系统的中间层。向上可以为容器配置网络，向下可以向Linux内核生成BPF程序来控制容器的安全性和转发行为。具体如下所示：
基于上述组件图，管理员通过CiliumCLI配置策略信息，这些策略信息将存储在KV数据库里，Cilium使用插件（如CNI）与容器编排调度系统交互，来实现容器间的联网和容器分配IP地址分配，同时Cilium还可以获得容器的各种元数据和流量信息，提供监控API。
关于CiliumAgent，其作为守护进程运行在每个节点上，与容器运行时如Docker，和容器编排系统交互如Kubernetes。通常是基于插件的形式（如DockerPlugin）或遵从容器编排标准定义的网络接口（如CNI）。具体地，CiliumAgent的主要功能包含以下：
1、基于Clang/LLVM将BPF程序编译为字节码，在容器的虚拟以太网设备中的所有数据包上执行，并将它们传递给Linux内核。
2、与容器管理平台的网络插件交互，实现IPAM的功能，用于给容器分配IP地址，该功能与Flannel、Calico网络插件类似。
3、收集容器的元数据，例如Pod的Label，可用于Cilium安全策略里的Endpoint识别，这个跟Kubernetes中的Service里的Endpoint类似。
4、将其有关容器标识和地址的知识与已配置的安全性和可见性策略相结合，生成高效的BPF程序，用于控制容器的网络转发和安全行为。
5、其他相关自定义配置。
下面我们再来看下Cilium是如何基于eBPF实现容器网络方案的，首先，我们了解下其流程图，具体如下所示：
基于上述CiliumeBPF流程图，简要解析如下：
1、CiliumAgent生成对应的eBPF程序。
2、用LLVM编译eBPF程序，生成eBPF对象文件（objectfile，*.o）。
3、用eBPFloader将对象文件加载到Linux内核。
4、校验器（verifier）对eBPF指令会进行合法性验证，以确保程序是安全的，例如，无非法内存访问、不会Crash内核、不会有无限循环等。
5、对象文件被即时编译（JIT）为能直接在底层平台（例如x86）运行的NativeCode。
6、如果要在内核和用户态之间共享状态，BPF程序可以使用BPFmap，这种一种共享存储，BPF侧和用户侧都可以访问。
7、BPF程序就绪，等待事件触发其执行。对于此示例，在某一时刻，若存在有数据包到达网络设备时，便触发BPF程序的执行。
8、BPF程序对收到的包进行处理，随后将返回一个裁决（verdict）结果。
9、根据裁决结果，如果是DROP，这个包将被丢弃；如果是PASS，包会被送到更网络栈的更上层继续处理；如果是重定向，就发送给其他设备。
基于上述的流程，我们可以看出，基于eBPF，对数据平面（Datapth）进行了重新定义，具体如下，
首先，从长期看，eBPF这项新功能会减少未来的FeatureCreepingNormality。因为用户或开发者希望内核实现的功能，以后不需要再通过改内核的方式来实现了。只需要一段eBPF代码，实时动态加载到内核就行了。
其次，基于eBPF，内核也不会再引入那些影响FastPath的蹩脚甚至Hardcode代码，从而也避免了性能的下降。
再者，eBPF还使得内核完全可编程，安全地可编程（FullyandSafelyProgrammable），用户编写的eBPF程序不会导致内核Crash。另外，eBPF设计用来解决真实世界中的线上问题，而且我们现在仍然在坚守这个初衷。
站在网络角度，我们来看一下基于传统的Kube-Proxy处理KubernetesService时，包在内核中的转发路径是怎样的？简要流程如下图所示：
具体步骤如下：
1、网卡收到一个包（通过DMA放到Ring-Buffer）。
2、包经过XDPHook点。
3、内核给包分配内存，此时才有了大家熟悉的Skb（包的内核结构体表示），然后送到内核协议栈。
4、包经过GRO处理，对分片包进行重组。
5、包进入TC（TrafficControl）的IngressHook。接下来，所有标识为浅蓝色的框都是Netfilter处理点。
6、Netfilter：在PREROUTINGHook点处理RawTable里的Iptables规则。
7、包经过内核的连接跟踪（Conntrack）模块。
8、Netfilter：在PREROUTINGHook点处理MangleTable的Iptables规则。
9、Netfilter：在PREROUTINGHook点处理NatTable的Iptables规则。
10、进行路由判断（FIB：ForwardingInformationBase，路由条目的内核表示，译者注）。接下来又是四个Netfilter处理点。
11、Netfilter：在FORWARDHook点处理MangleTable里的Iptables规则。
12、Netfilter：在FORWARDHook点处理FilterTtable里的Iptables规则。
13、Netfilter：在POSTROUTINGHook点处理MangleTable里的Iptables规则。
14、Netfilter：在POSTROUTINGhook点处理NatTable里的Iptables规则。
15、包到达TCEgressHook点，会进行出方向（Egress）的判断，例如判断这个包是到本地设备，还是到主机外。
16、对大包进行分片。根据Step15判断的结果，这个包接下来可能会：发送到一个本机veth设备，或者一个本机ServiceEndpoint，或者，如果目的IP是主机外，就通过网卡发出去。
上述我们已经了解到传统的包转发路径，再来看下基于CiliumeBPF中的包转发路径，简要流程如下图所示：
基于对比可以看出，CiliumeBPFDatapath做了短路处理：从TCingress直接ShortCut到TCegress，节省了9个中间步骤（总共17个）。更重要的是：这个Datapath绕过了整个Netfilter框架（浅蓝色的组件），Netfilter在大流量情况下性能较差。
移除那些不必要的组件后，CiliumeBPFDatapath流程示意图可精简为以下：
其实，基于其设计理念，CiliumeBPF还能走的更远。例如，如果包的目的端是另一台主机上的ServiceEndpoint，那你可以直接在XDP框中完成包的重定向（收包1->2，在步骤2中对包进行修改，再通过2->1发送出去），将其发送出去，如下图所示：
基于XDP技术，XDP为eXpressDataPath的缩写，支持在网卡驱动中运行eBPF代码，而无需将包送到复杂的协议栈进行处理，因此处理代价很小，速度极快。
最后，我们来了解下Cilium的ServiceLoadBalancing设计，简要架构如下图所示：
因时间原因，故针对其流量解析暂不在本章描述，后续再做补充，基于此，本篇文章关于CiliumeBPF解析到此为止，大家有问题随时留意沟通。
-EOF-
如果您喜欢本文，欢迎点赞、收藏、留言，或者点击右下角，把文章分享给你的朋友们～～～
LugaLee
“路，在自己脚下～”
如果你还想了解更多这方面的信息，记得收藏关注本站。