简介

kube-router是一套开源网络计划，基于bgp协定构建路由，从而构建整个容器集群网络，它应用ipvs实现了k8s的service网络，并应用ipset和iptables工具实现了networkpolicy。

咱们晓得calico对于networkpolicy的实现也是ipset+iptables这一套，本文将联合源码和实例，介绍kube-router是如何实现networkpolicy的，并剖析它与calico在设计上的异同。

简要概括

kube-router在节点上启动一个agent同步pod、networkpolicy对象的信息，并构建iptables规定和ipset汇合。次要的程序入口在func (npc *NetworkPolicyController) fullPolicySync()。读者能够本人浏览源码，挺清晰的。

规定解决分为四步：

顶层规定集: npc.ensureTopLevelChains()
networkpolicy粒度的规定集: networkPoliciesInfo, err = npc.buildNetworkPoliciesInfo() ; activePolicyChains, activePolicyIPSets, err := npc.syncNetworkPolicyChains(networkPoliciesInfo, syncVersion)
pod粒度规定集：activePodFwChains, err := npc.syncPodFirewallChains(networkPoliciesInfo, syncVersion)
清理stale规定 err = cleanupStaleRules(activePolicyChains, activePodFwChains, activePolicyIPSets)

顶层规定集

与calico一样，在INPUT/FORWARD/OUTPUT三个中央做hook。别离hook到KUBE-ROUTER-INPUT、KUBE-ROUTER-FORWARD、KUBE-ROUTER-OUTPUT。

KUBE-ROUTER-FORWARD、KUBE-ROUTER-OUTPUT两个链中没有什么非凡的规定，间接就进入到了各个pod粒度的规定集中。

KUBE-ROUTER-INPUT链中做了一些非凡目标地址的egress白名单，如下：

容许拜访service cidr

-d $SERVICE_RANGE -j RETURN

容许拜访nodeport port range

-p tcp/udp -m addrtype --dst-type LOCAL -m multiport --dports $NODEPORT_RANGE -j RETURN

容许拜访service external ip

-d $SERVICE_EXTERNAL_RANGE -j RETURN

各个pod的规定

networkpolicy粒度规定集

networkpolicy粒度的规定以KUBE-NWPLCY为前缀，一个规定一个链。

来个例子:

Chain KUBE-NWPLCY-4UOMHLJABMXP4VW2 (1 references)target     prot opt source               destinationMARK       all  --  anywhere             anywhere             /* rule to ACCEPT traffic from source pods to dest pods selected by policyname access-pod namespace default */ match-set KUBE-SRC-IMXDMRGLZFP7QJCX src match-set KUBE-DST-5CXCQ5O6AOA47RC6 dst /* rule to mark traffic matching a network policy */ MARK or 0x10000RETURN     all  --  anywhere             anywhere             /* rule to ACCEPT traffic from source pods to dest pods selected by policyname access-pod namespace default */ match-set KUBE-SRC-IMXDMRGLZFP7QJCX src match-set KUBE-DST-5CXCQ5O6AOA47RC6 dst /* rule to RETURN traffic matching a network policy */ mark match 0x10000/0x10000MARK       all  --  anywhere             anywhere             /* rule to ACCEPT traffic from source pods to specified ipBlocks selected by policy name: access-pod namespace default */ match-set KUBE-SRC-5CXCQ5O6AOA47RC6 src match-set KUBE-DST-7VKW2UTKN2UOEU4I dst /* rule to mark traffic matching a network policy */ MARK or 0x10000RETURN     all  --  anywhere             anywhere             /* rule to ACCEPT traffic from source pods to specified ipBlocks selected by policy name: access-pod namespace default */ match-set KUBE-SRC-5CXCQ5O6AOA47RC6 src match-set KUBE-DST-7VKW2UTKN2UOEU4I dst /* rule to RETURN traffic matching a network policy */ mark match 0x10000/0x10000

一个KUBE-NWPLCY-*** chain里形容了一个networkpolicy对象，对于该对象的每一个rule（ingress or egress），咱们都会有如下的操作：

判断源地址+端口/目标地址+端口是否合乎ingress/egress rule。如果合乎就打mark: MARK or 0x10000 。这里的地址匹配，是一个ipset
判断mark是否匹配mark match 0x10000/0x10000, 如果匹配，return ，如果不匹配，再查看下一个rule的规定。

pod粒度规定集

从顶层规定集中，kube-router基于包的源/目标 IP跳转到相应的pod粒度规定集。

如何进入pod粒度集

因为kube-router对接的网络插件是官网的bridge插件， node上容器host-veth都绑在网桥上，pod彼此之间属于二层互联（包间接桥接转发）

所以同一个node上的pod-to-pod 的包会间接在bridge进行二层转发，这类包必须要经由如下的iptables规定解决：

-t filter KUBE-ROUTER-FORWARD -m physdev --physdev-is-bridged -m comment --comment "******" -d $POD_IP -j KUBE-POD-FW-XXXXX (匹配某个pod的ingress policy)    例：同node的pod要拜访本pod，node对pod做健康检查-t filter KUBE-ROUTER-FORWARD -m physdev --physdev-is-bridged -m comment --comment "******" -s $POD_IP -j KUBE-POD-FW-XXXXX (匹配某个pod的egress policy)    例：本pod要拜访同node其余pod

留神：

XXXXX是pod的ns+name的hash，但格局与calico不一样
同一个node上的pod-to-pod走二层转发，这个过程想要被netfilter hook，须要加载br_netfilter模块，并且开启/proc/sys/net/bridge/bridge-nf-call-iptables ,/proc/sys/net/bridge/bridge-nf-call-ip6tables为1

除此之外的包，都是通过对方向、src或dst IP的匹配，来进入特定pod的规定链。例如：

-t filter KUBE-ROUTER-FORWARD -d $POD_IP -j KUBE-POD-FW-XXXXX (匹配某个pod的ingress policy) 例：其余节点（及上的pod）拜访pod
-t filter KUBE-ROUTER-OUTPUT -d $POD_IP -j KUBE-POD-FW-XXXXX (匹配某个pod的ingress policy)
-t filter KUBE-ROUTER-INPUT -s $POD_IP -j KUBE-POD-FW-XXXXX (匹配某个pod的egress policy) 例：pod拜访其余任何地址
-t filter KUBE-ROUTER-FORWARD -s $POD_IP -j KUBE-POD-FW-XXXXX (匹配某个pod的egress policy)
-t filter KUBE-ROUTER-OUTPUT -s $POD_IP -j KUBE-POD-FW-XXXXX (匹配某个pod的egress policy)

pod粒度规定集里有什么？

ingress policy

在KUBE-POD-FW-XXXXX链中，增加了若干规定：

一、曾经建设的连贯，间接承受

-t filter KUBE-POD-FW-XXXXX -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

二、所有从node拜访过去的包，都予以承受

-t filter KUBE-POD-FW-XXXXX -m addrtype --src-type LOCAL -d $POD_IP -j ACCEPT

三、其余状况下，须要基于匹配该pod的每个ingress policy，都增加一条jump规定：

-t filter KUBE-POD-FW-XXXXX -j XXXXXXXXX  (XXXXXXXXX示意作用于该pod的第一个networkpolicy的ns+name的hash)-t filter KUBE-POD-FW-XXXXX -j XXXXXXXXY  (XXXXXXXXY示意作用于该pod的第二个networkpolicy的ns+name的hash)...

egress policy

一、曾经建设的连贯，间接承受

-t filter KUBE-POD-FW-XXXXX -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

二、其余状况下，须要基于匹配该pod的每个egress policy，都增加一条jump规定：

-t filter KUBE-POD-FW-XXXXX -j XXXXXXXXX  (XXXXXXXXX示意作用于该pod的第一个networkpolicy的ns+name的hash)-t filter KUBE-POD-FW-XXXXX -j XXXXXXXXY  (XXXXXXXXY示意作用于该pod的第二个networkpolicy的ns+name的hash)...

示例

Chain KUBE-POD-FW-VFY4MIYKQH6U2ZBK (7 references)target     prot opt source               destinationACCEPT     all  --  anywhere             anywhere             /* rule for stateful firewall for pod */ ctstate RELATED,ESTABLISHEDACCEPT     all  --  anywhere             10.0.0.24            /* rule to permit the traffic traffic to pods when source is the pod's local node */ ADDRTYPE match src-type LOCALKUBE-NWPLCY-4UOMHLJABMXP4VW2  all  --  anywhere             anywhere             /* run through nw policy access-pod */KUBE-NWPLCY-TOUTUXPCBONZJXQA  all  --  anywhere             anywhere             /* run through nw policy access-pod-and-node */NFLOG      all  --  anywhere             anywhere             /* rule to log dropped traffic POD name:hyserver-d4f9cf4df-55ggn namespace: default */ mark match ! 0x10000/0x10000 limit: avg 10/min burst 10 nflog-group 100REJECT     all  --  anywhere             anywhere             /* rule to REJECT traffic destined for POD name:hyserver-d4f9cf4df-55ggn namespace: default */ mark match ! 0x10000/0x10000 reject-with icmp-port-unreachableMARK       all  --  anywhere             anywhere             MARK and 0xfffeffff

咱们留神到，先是Accept了已成立的连贯和来自宿主机的IP，而后就会遍历所有的networkpolicy，全副走一遍后，判断mark，如果mark不匹配，打印日志，并且reject，如果匹配，咱们将用于标记的那一位再置0:MARK and 0xfffeffff

整体上的链路如下图：

总结

依据对kube-router的实现判断，能够看出它和calico-felix在实现上的一些区别。kube-router的规定脉络更清晰，更简略，而且有充沛的comment进行判断和跟踪。最重要的是，它是基于pod IP进行匹配的； felix在规定上更简单，然而做了一些优化，所以从设计上看，性能应该会比kube-router更好。体现在：

felix基于网卡做前缀判断pod流量，相比于依据pod IP（记录于etcd）更精确靠谱一些
felix基于网卡前缀做分表，能够节俭遍历工夫
felix在任何一个networkpolicy规定匹配后间接return，不须要遍历所有networkpolicy。

kube-router比拟人性化的中央在于：

它默认放行了node对pod的被动拜访（兼容了健康检查）
默认放行了pod对各种service的拜访（防止用户定义了过于严格的egress规定导致pod无法访问dns等要害service）

所以应用上心智累赘会更少。

附录

calico中networkpolicy的实现

能够参考[网易数帆k8s集群对networkpolicy的实际——felix]

iptables中physdev选项的阐明

--physdev-in [name|prefix+|!name] 匹配从name端口进入网桥的数据包。（作用于INPUT、FORWARD和PREROUTING链），能够通过'+'对端口名进行前缀匹配。'!name'用于反向匹配。
--physdev-out [name|prefix+|!name] 匹配从name端口收回的数据包。（作用于FORWARD、OUTPUT和POSTROUTING链）
--physdev-is-in 匹配进入网桥数据包
--physdev-is-out 匹配来到网桥数据包
--physdev-is-bridged 匹配被桥接不是被路由的数据包。（作用于FORWARD和POSTROUTING链）