一文看懂Antrea架构

作者: MichaelChoo | 来源:发表于2021-06-08 15:59 被阅读0次

Antrea总览

Antrea开源项目是一个基于Open vSwitch（OVS）的Kubernetes CNI网络插件解决方案，旨在为Kubernetes集群提供更高效、更强大的跨平台网络和安全策略。

Antrea利用OVS作为网络数据平面，目前主要为Kubernetes集群提供二到四层的网络服务和安全特性。七层安全策略将在随后的版本中发布。OVS是一种高性能可编程虚拟交换机，使用统一的技术栈支持Linux和Windows。基于OVS，Antrea能够以更高效的方式实现Pod的网络连通、网络策略和服务负载均衡。借助OVS的“可编程”特性，Antrea能够实现更高级广泛的网络服务和安全特性。

本文档中的某些信息，尤其是有关Antrea Agent的信息是特指在Linux节点上运行Antrea。关于如何在Windows节点上运行Antrea，请参考Windows设计文档[1]。Windows设计中文版将后续推出。

组件

在一个Kubernetes集群内，Antrea以Deployment的形式部署运行中心控制器antrea-controller，以负责网络策略的解析转换、跨度（Span）计算，并能够以增量传输的方式向工作节点按需分发网络策略，以消除在每个工作节点上执行这一处理带来的计算、存储、传输开销。

在每个工作节点上，Antrea以DaemonSet的形式部署运行antrea-agent和OVS用户空间守护进程，并以init container的形式将antrea-cni插件安装到主机并加载OVS内核模块。antrea-agent负责OVS网桥和Pod网络接口的管理，并通过OpenFlow协议编程OVS来实现各种网络和安全功能。

此外，Antrea还带有命令行工具antctl和基于Octant的图形界面插件，提供了强大的故障诊断能力。

arch-1.png

Antrea Controller

Antrea Controller从Kubernetes API监听NetworkPolicy，Pod和Namespace资源，计算NetworkPolicy并分发计算出的策略给相关的Antrea Agents。目前Antrea Controller主要功能是实现网络安全策略。

Antrea Controller利用Kubernetes apiserver库[2]实现与Antrea Agent交互。每个Antrea Agent连接到Controller API Server并监听计算后的NetworkPolicy对象。Controller还提供了用于调试的REST API，可以由antctl调用展示计算后的策略信息。

Antrea Controller对计算和发布NetworkPolicy的过程进行了定制和优化：

Antrea Controller 将所有状态保存在内存中，不需要持久化保存数据。
仅将NetworkPolicy对象发送到需要该NetworkPolicy的节点。当且仅当NetworkPolicy被应用于该节点上至少一个Pod时，节点才会收到这条NetworkPolicy。
支持NetworkPolicy对象的增量更新。
Controller和Agent之间的消息使用Protobuf格式进行序列化并提高效率。

Antrea Controller API Server还利用Kubernetes Service实现服务发现以及身份验证和授权。Controller API通过Kubernetes ClusterIP对外提供服务。Antrea Agent从环境变量获取服务的ClusterIP并连接到Controller API Server。Controller API Server将身份验证和授权委托给Kubernetes API ，Antrea Agent使用Kubernetes ServiceAccount token向Controller进行身份验证，然后Controller API Server验证token并检查ServiceAccount是否有权访问所请求的API。

Antrea Controller还通过API Server向antctl命令行工具暴露了REST API。它利用Kubernetes API聚合[3]使antctl通过Kubernetes API访问Antrea Controller API。antctl连接并向Kubernetes API验证，然后该请求被转发到Antrea Controller。通过这种方式，antctl可以在任何能够访问Kubernetes API的机器上执行，并且还可以利用kubectl配置（kubeconfig文件）来发现Kubernetes API和身份验证信息。

Antrea Agent

Antrea Agent运行在每个Kubernetes节点上，接受Antrea controller的策略配置，管理OVS Bridge和Pod接口并实现Pod的网络连接和安全特性。

Antrea Agent向antrea-cni提供gRPC服务（CNI服务）来实现Pod的网络资源管理。对于节点上每个新创建的Pod，antrea-cni将容器运行时的CNI ADD请求转发给 Antrea Agent，由后者创建Pod的网络接口，分配IP地址，并将该接口连接到OVS Bridge，同时在OVS中安装必要的流规则。要了解更多有关OVS 流规则请参见OVS流文档[4]。

Antrea Agent包括两个本地Controller：

Node Controller：监视Kubernetes API服务器中的新节点，并为每个远程节点创建一个OVS（Geneve/VXLAN/GRE/STT）隧道连接。
NetworkPolicy Controller：从Antrea Controller API监视计算后的NetworkPolicy，并为本地Pod安装对应的OVS 流规则。

此外，Antrea Agent同样提供了REST API，antctl可以调用它展示内部数据和状态从而支持故障定位。

OVS守护程序

两个OVS守护程序ovsdb-server和ovs-vswitchd运行在Antrea Agent DaemonSet中一个名为antrea-ovs的独立容器中。

antrea-cni

antrea-cni是Antrea的CNI[5]插件。它是一个简单的gRPC客户端，负责将CNI请求通过RPC发送给Antrea Agent。Antrea Agent执行实际工作（为Pod建立网络）并将结果或错误返回给antrea-cni。

antctl

Antctl[6]是Antrea的命令行工具。它可以显示基本的Antrea Controller和Antrea Agent的运行时信息，用于调试和故障定位。

访问Controller时，antctl调用Controller API来查询请求的信息。如前所述，antctl可以通过Kubernetes API访问Controller API，由Kubernetes API进行身份验证授权后将请求转发到Antrea Controller。antctl也可以作为kubectl的插件来执行。

访问Agent时，antctl会连接到Agent本地的REST API，并且只能在Agent容器内执行。

Octant UI插件

Antrea提供了Octant插件，可以在Octant UI中显示Controller和Agent的健康状况和基本运行时信息。Octant插件通过Kubernetes API从AntreaControllerInfo和AntreaAgentInfo CRD中获取Controller和Agent的信息，这些CRD由Antrea Controller和Antrea Agent创建并反馈它们的健康状况和运行时信息。

Pod 网络

Pod接口配置和IPAM

在每个节点上，Antrea Agent都会创建一个OVS Bridge（默认情况下名为br-int），并为每个Pod创建一对veth设备，一端在Pod的网络命名空间中，另一端连接到OVS Bridge。在OVS Bridge上，Antrea Agent还会创建一个内部端口（默认情况下为antrea-gw0）作为节点子网的内部网关，以及一个用来连接到其他节点的overlay隧道端口antrea-tun0。

arch-2.png

每个节点都分配有一个子网，该节点上的所有Pod均从该子网获得IP。Antrea利用Kubernetes的NodeIPAMController为节点做子网分配，并由其将分配的子网配置到Kubernetes Node API的podCIDR字段。Antrea Agent从podCIDR字段获得节点的子网，保留子网的第一个IP作为本地节点的网关IP，将其分配给antrea-gw0端口，并调用host-local IPAM插件[7]从子网给本地Pod分配IP。

对于每个远程节点，Antrea Agent添加一条Openflow规则使流量能够通过对应的隧道发送到该节点。该规则通过匹配数据包的目的IP来选择隧道端点。

流量分析

arch-3.png

节点内流量：两个本地Pod之间的数据包将直接由OVS Bridge转发。
节点间流量：到另一个节点上的Pod的数据包将首先转发到antrea-tun0端口，封装后通过隧道发送到目标节点，由目标端点解封装，通过antrea-tun0端口进入OVS Bridge，最后转发到目标Pod。
访问外部网络的流量：发送到外部网络的数据包将转发到antrea-gw0端口（因为它是本地Pod子网网关），由主机网络将其路由到节点上对应的网络接口（例如裸机的物理网络接口）然后发送到外部网络。Antrea Agent创建iptables（MASQUERADE）规则来对Pod的数据包执行SNAT，这样它们的源IP将在发送前重写为节点的IP。

ClusterIP服务

Antrea支持kube-proxy或Antrea Proxy 两种方法实现ClusterIP类型的服务，其中Antrea Proxy通过OVS为ClusterIP服务实现负载均衡。

在使用kube-proxy时，Antrea Agent通过添加OVS流规则来转发从Pod访问ClusterIP服务的数据包到antrea-gw0端口，kube-proxy将拦截数据包并选择一个Service Endpoint作为连接的目的地址，然后将数据包DNAT发送到Endpoint的IP和端口。如果目标Endpoint是本地Pod，则数据包将直接转发到Pod。如果目标Endpoint 在另一个节点上，则通过隧道方式将数据包发送到该节点。

arch-4.png

kube-proxy可以在任何支持的模式下使用，包括user-space，iptables或IPVS。请参阅Kubernetes服务文档[8]查看更多细节。

启用AntreaProxy后，Antrea Agent会添加OVS流规则来实现ClusterIP服务流量的负载均衡和DNAT。服务流量负载均衡将通过OVS内部来完成。因为在转发流量到主机网络时没有额外的开销和iptables处理，与kube-proxy相比可以获得更好的性能。Antrea Agent中AntreaProxy使用了部分kube-proxy的实现来监视和处理Service Endpoint。

NetworkPolicy

Antrea中NetworkPolicy的重要设计实现是选择集中的策略计算。Antrea Controller监视Kubernetes API中的NetworkPolicy，Pod和Namespace资源，并按以下方式处理podSelectors，namespaceSelectors和ipBlocks：

在NetworkPolicy规范下直接定义的PodSelector（定义了应用该NetworkPolicy的Pod）转换为Pod成员。
Selectors（podSelectors和namespaceSelectors）和ipBlocks（定义了此策略允许的进出口流量）将被映射到Pod IP地址或IP地址范围。
Antrea Controller还计算哪些节点需要接收NetworkPolicy。每个Antrea Agent仅接收本地Pod需要的网络策略，并直接使用由Controller计算的IP地址来创建实现特定NetworkPolicy的OVS流规则。

集中计算的方式更加高效，主要表现在以下几个方面：

只需要一个Antrea Controller实例接收和处理NetworkPolicy，Pod和Namespace的更新，并计算podSelector和namespaceSelectors选中的成员。相较于在所有工作节点监视这些更新和执行同样复杂计算的方式，总体成本要低得多。
很容易启用Controller的横向扩展来增加计算力，同时运行多个Controller并行计算NetworkPolicy，每个Controller只负责NetworkPolicy的一个子集（因为单个Controller已经满足2000节点的超大集群，所以目前Antrea仅可配置一个Controller实例）。
Antrea Controller是NetworkPolicy计算的唯一来源，这样在节点之间更容易实现数据一致性，并且极大降低了调试的难度。

多种网络模式

默认的Encap模式会封装所有节点间的Pod流量，除了Encap模式外， Antrea还支持其他封装模式，包括NoEncap、Hybrid和NetworkPolicyOnly模式。

NoEncap模式：此模式下Pod流量不会被封装。Antrea会假设节点网络可以处理跨节点的Pod流量路由。该实现通常需要为节点间的路由器添加 Pod子网路由，一般由Kubernetes Cloud Provider来实现。Antrea Agent还会在节点上为所有处于同一子网的远程节点创建静态路由，这样Pod间流量将直接转发到目标节点而无需通过节点的路由器从而优化了跳数。Antrea Agent还会创建iptables（MASQUERADE）规则，用于实现Pod到外部流量的SNAT。Antrea支持在GKE中启用NoEncap模式[9]。

Hybrid模式：当两个节点位于两个不同的子网中时，两个节点之间的Pod流量将被封装；当两个节点位于同一子网中时，Pod之间的流量不会被封装，而是从一个节点路由到另一个节点。对于同一子网的其他节点，Agent会添加一条静态路由，将该节点IP用作其Pod子网的下一跳。（Hybrid模式要求节点网络允许将带有Pod IP的数据包从节点的网卡中发送出。）
NetworkPolicyOnly模式：节点间Pod流量既不被Antrea通过隧道传输也不被路由。Antrea只为Pod流量实现NetworkPolicy，此时需要额外的CNI和Cloud网络来实现Pod网络分配和跨节点流量转发。更多信息请参阅NetworkPolicyOnly模式设计文档[10]。Antrea支持在AKS[10]和EKS[11]启用仅网络策略模式。

特性

Antrea网络策略

除了Kubernetes NetworkPolicy，Antrea还提供了 NamespacedNetworkPolicy和ClusterNetworkPolicy额外两个CRD来实现更复杂的网络策略，前者的作用域是特定的Namespace，后者将作用于整个集群。这两个CRD有效扩充了 Kubernetes NetworkPolicy并提供了策略优先级，分层，拒绝操作，外部实体和策略统计信息等高级特性。更多有关Antrea网络策略的信息请参阅Antrea网络策略文档[12]。

正如Kubernetes NetworkPolicy一样，Antrea Controller将AntreaNetworkPolicy和ClusterNetworkPolicy转换为内部NetworkPolicy，AddressGroup和AppliedToGroup对象，并将它们分发给Antrea Agent， Antrea Agent则创建OVS流规则作用于其节点上的Pod。

IPsec加密

Antrea支持使用IPsec ESP加密GRE隧道流量。IPsec实现使用OVS IPsec[13]并使用StrongSwan[14]作为IKE守护进程。

要启用IPsec，必须将一个额外的容器antrea-ovs-ipsec添加到Antrea Agent DaemonSet，该容器运行了ovs-monitor-ipsec和strongSwan守护程序。Antrea现在仅支持通过环境变量"ANTREA_IPSEC_PSK"读取预共享密钥（PSK ）并将其用于IKE身份验证。用户可以在Antrea IPsec部署文件[15]中指定PSK密钥。该密钥将存储在Kubernetes Secret中然后被Antrea Agent容器引用。

启用IPsec后，Antrea Agent将在OVS Bridge为每个远程节点创建一个单独的GRE隧道端口，并将PSK密钥和远程节点IP地址配置到OVS 隧道接口。ovs-monitor-ipsec守护程序可以检测隧道并使用PSK为远程节点创建IPsec安全策略，strongSwan基于安全策略创建IPsec安全关联。这些额外的隧道端口不会被用来发送流量到远程节点，隧道流量仍通过OVS流规则从默认隧道端口（antrea-tun0）发送出去，但是来自远程节点的流量将由节点的IPsec隧道端口接收。

网络流可视化

Antrea支持使用IPFIX来导出网络流信息和Kubernetes上下文。导出的网络流可以使用Elastic Stack和Kibana仪表板进行可视化。更多信息请参阅网络流可视化文档[16]。

Windows节点

在Windows节点上，Antrea的行为与在Linux节点上的行为非常相似。Antrea Agent和OVS仍在节点上运行，Windows Pod也连接到OVS Bridge，Pod网络大部分仍然是通过OVS流规则实现的，甚至OVS 流规则与Linux节点上的流规则都基本相同。Window节点在Antrea实现中的主要区别是：Antrea Agent和OVS守护程序如何被运行和管理，OVS Bridge的配置方式，Pod网络接口如何连接到网桥，以及主机网络路由和SNAT的实现方式。有关Antrea Windows实现的更多信息请参阅Windows设计文档[1]。

原文链接：https://mp.weixin.qq.com/s/5KI3AXP5AWFE3lCJ7n-U5A

Antrea的Github地址：https://github.com/antrea-io/antrea