K8S学习笔记2-NodePort

Service的实现：

k8s通过services对外将pod所提供的服务通过一组稳定的IP和端口暴露出来，只要服务存在客户端可以通过这个稳定的IP和端口访问服务而无需关心其背后实际提供服务pod可能出现的因扩容，缩容，迁移等原因导致的IP变化。

服务的暴露分两种场景：对内部暴露服务供其他pod访问；暴露服务给外部客户端访问。

暴露服务给外部客户端访问

NodePort服务

Nodeport服务会在每一个k8s node上开启一个固定的端口（端口号在30000+以上），该端口会被映射到对应的clusterIP上。

以前一篇笔记记录的K8S集群为例，Flannel作为网络插件，当我们部署一个以NodePort提供服务的kubedashboard时，实际上发生了什么：

Pod1: 

Pod2:

service

在service进行创建时，API服务器会给该service分配一个虚拟的IP（10.103.179.153），并通知所有节点上的kube-proxy，kube-proxy会根据所对应的信息在每个Node上创建相对应的iptables规则，来实现最终的服务暴露。

除了对service进行修改，kube-proxy同样对endpoint进行修改，以适应pod的变化，将请求转发到合适的节点上。

同时，因为集群内的每一个Node所开放的port均有可能接收到对应的请求，因此iptables规则也需要对等的添加到集群内的每一个Node中。

检查Node上的iptable的NAT表，关注NodePort相关的规则链条：

1. K8S节点的30000端口收到请求后，请求会先在iptables的PRE_ROUTING进行处理，在PRE_ROUTING hook点，有KUBE-SERVICE规则链

2. KUBE-SERVICE规则链中是是针对每一个不同的service的处理规则，根据请求的destination由不同的SVC规则进行处理。k8s集群内部对dashboard service的访问（destination为10.103.179.153）由KUBE-SVC-CEZPIJSAUFW5MYPQ进行处理

3. 从30000端口进入的数据包将由KUBE-NODEPORTS规则进行处理。

4. KUBE-NODEPORTS规则链接到KUBE-EXT-CEZPIJSAUFW5MYPQ，包含两条子链。

        a. 对于Node节点30000端口收到的数据执行KUBE-MARK-MASQ，增加0x4000标记。（这里为外部通过暴露端口访问NodePort流量的标记）

        b. 将数据交由KUBE-SVC-CEZPIJSAUFW5MYPQ进行处理。        

5. KUBE-SVC-CEZPIJSAUFW5MYPQ规则的处理过程包含：

        a. 对于源地址不是!10.244.0.0/16，目的地址为10.103.179.153，目的端口为443且协议为TCP的数据包，执行KUBE-MARK-MASQ规则，进行数据标记，增加0x4000标记。 对于非master节点的Pod访问service服务的流量进行标记。

        b. 后面4条规则分别是KUBE-SEP-2AMVQ5OMFVY3SNSI，KUBE-SEP-DZJNU2VF2VGZ6UZJ的重复，这里进行重复配置的原因为在service的配置时，我们设置了机遇ClusterIP的会话亲和性，通过会话亲和性的设置，可以确保请求能尽可能的发送到同一个后端endpoint进行处理，会话亲和性的实现依赖的ipdtables的recent模块，请求会先根据source ip进行连接状态检查，分别对两个后端pod的IP进行检查，对于都不能匹配的心的source IP，则会按照50%的概率随机分配到两个后端Pod中来实现负载均衡。

6. 对于实际分配到具体KUBE-SEP-2AMVQ5OMFVY3SNSI的数据包，源IP为10.244.2.6的数据包会被执行MARK标记，同时对数据包设置连接状态，同时进行DNAT，将目的地之转换为目标Pod的IP：PORT。

执行完成PRE_ROUTING阶段的数据处理后，数据就会进入路由，根据路由表的判断，确认数据的目的地是否在本机，如果目的地不在本机,则会进入转发的过程，这里就涉及到FORWARD hook点的数据处理，FORWARD hook点主要执行mangle链和filter链处理。