加深讲解 L4 L7 调度跟apiserver通信

一、L4 L7 都是什么

L4 是4层调度的意思，4层调度又是什么?

首先A软件要跟B软件单项或者互相通信，这时B软件自己开放一个端口，说要想跟我通信连接我的这个端口，而这个端口是走TCP/IP协议，这种需要连接TCP/IP协议的端口，就是在4层调度。比如ssh、ftp，xshell要连接Linux的sshf服务的22端口，才能进入Linux 的命令行界面。而这种就是通TCP/IP协议的端口连接。4层调度一般使用iptables底层原理实现，通过iptables的规则，实现流量怎么转发，具体查询百度iptables。

L7 是7层调度的意思，7层调度又是什么?

上文讲述了，A软件要跟B软件通信，访问的是TCP/IP协议的端口，7层就不是TCP/IP协议，而是http协议。比如windows浏览器要访问百度，它一定是通过本机dns或者上级、上上级的dns解析出baidu.com这个域名的IP是多少，比如是是110.242.68.3，然后把访问www.baidu.com请求数据包原封不动的给110.242.68.3这个IP传过去，当110.242.68.3服务器拿到这个请求数据包，在解析返回给客户端浏览器，其中这个http传输的就叫做7层调度。7层调度一般使用IPVS底层原理实现，通过IPVS的规则，实现流量怎么转发，具体查询百度IPVS。

二、L4 调度

首先要知道，我们L4 调度的是谁，是apiserver，apiserver是k8s的核心大脑，所有的组件必须跟它通信，进而获取etcd中的配置。比如kubectl 需要在配置文件中配置连接apiserver。而apiserver在生产中，一般只是部署3台，3台为了做负载均衡用的，而我们只部署了2台，也可以做负载均衡。以kubectl连接apiserver为例子，讲解。

 1、apiserver默认启动6334端口，我们部署在10.4.7.21、10.4.7.22节点上。而两台apiserver配置文声明了他们连接的是同一个etcd集群，所以，如果kubectl要连接apiserver获取etcd中的配置，连接那个都行，因为两个apiserver都是为一个etcd集群工作

2、这个时候就就想了，那都一样，连接那个都行，我何不为这两个做一个负载均衡。让kubectl等组件连接我这个负载均衡不就行了么。所以我们选择了10.4.7.11或者10.4.7.12 中一个机器做这个事情，比如是10.4.7.11，配置如下信息后，让kubectl 连接10.4.7.11的7443端口，然后负载均衡给10.4.7.21:6443或者10.4.7.22:6443，这时候在想，那我是不是这个10.4.7.11到时候压力会很大呀，一旦10.4.7.11崩了咋整，集群直接不废了么，所有的组件都连接10.4.7.11:7443

3、如果可以给10.4.7.11做高可用keepalived，让10.4.7.11 、10.4.7.12 做一个vip 10.4.7.10，让10.4.7.11默认启动10.4.7.10，然后时刻监听自己的7443端口，如果7443端口没了，立马把10.4.7.10飘逸10.4.7.12。这样让所有的组件，比如kubectl连接10.4.7.10:7443不就行了么（注只需要声明vip10.4.7.10就行，假如10.4.7.10在10.4.7.11上，你访问10.4.7.10就是在访问10.4.7.11，你访问10.4.7.10:7443就是访问10.4.7.11:7443）

 4、所以查看kubectl的配置，连接的

三、L7 调度

上述也讲述了，7层主要用于http协议，比如k8s中部署了一套dashboard的业务，而且这个业务是提供http的网址的，他的网址是（dashboard.od.com:443），那我k8s外部如何访问这个网址。

2、从外网访问www.dashboard.od.com后，通过name的解析，直接把流量抛给了10.4.7.10

3、10.4.7.10 上述讲过，是为了做高可用，让k8s内部程序，直接调用10.4.7.10:7443，但是这次不一样，我们通过name解析后，直接抛给了10.4.7.10（可能是10.4.7.11 或者10.4.7.12）。然后这份流量怎么办呢？在nginx上做一个匹配，只要我（10.4.7.11 或者10.4.7.12）接收到的流量，是访问*.od.com，就把流量抛给后端的10.4.7.21:81 或者10.4.7.22:81。所以www.dashboard.od.com流量是给到了10.4.7.21:81 或者10.4.7.22:81。那10.4.7.21:81 或者10.4.7.22:81又是啥呢？

4、了解：对于http协议在k8s 集群中，如何被调度？k8s提供了一个ingress资源，他是专门匹配http协议的一个资源，只要把流量引入到ingress资源中，后续就可以让ingress进行规则调度。而如何才能把外部流量引入到k8s内部中，k8s没有给我们提供对应的组件实现，但可以选择安装Traefik ，他能实现ingress资源的调度，我们简称为Ingress控制器。把Traefik交付到k8s中会发现，它配置了rbac.yaml，说明外部流量通过Traefik，Traefik拿着rbac.yaml，通过跟apiserver通信，能获取部分的资源使用权限，比如跟ingress资源通信。如何实现呢？通过查看资源配置清单，Traefik容器内部启动了80端口，并挂载到容器外，也就是docker -p 80:80。其中容器的80端口还挂载到了宿主机的81端口，也就是curl 宿主机的81端口，就是curl 容器的80端口。这就是对应的上述，10.4.7.21:81 或者10.4.7.22:81，所以访问www.dashboard.od.com流量引入到了treafik 控制器

5、通过treafik跟apiserver通信，把访问www.dashboard.od.com流量，引入到与之相匹配的ingress资源中。在ingress资源中，(hostname: dashboard.od.com)   (paths:)   (http:)意思是，我匹配的是http://www.dashboard.od.com   。再例如，你想匹配https://www.hello.od.com/index.html  （hostname: hello.od.com  ）(paths:/index.html )  (https:)。然后ingress把流量在给谁呢？给（serviceName :kubernetes-dashboard），这个又是谁呢？kubernetes-dashboard是一个service资源的名字，如下，然后把流量抛给了service资源。然后service资源声明了，你访问的是serviceIP:8443端口，而serviceIP的8443端口反代的是(pod:kubernetes-dashboard)的pod资源的443端口