计算节点的功能：
提供容器运行的环境
kube-proxy的主要功能：
术业有专攻，
kube-proxy的主要功能可以概括为4个字
网络规则
那么kube-proxy自己其实是个daemonset控制器跑的
每个节点上都有个的pod
它负责网络规则
其实呢
它还是个小领导
它不直接去搞网络规则
而是告诉别人，网络规则要怎么搞
你来搞
告诉谁？
1.14版本之前是iptables
1.14版本之后是ipvs
iptables是个命令行工具，装系统的时候一般默认就有
如果没有就装一个软件包就可以，ubuntu和centos系列的包名都是iptables
centos默认用了firewalld，如果管理员更习惯用iptables，可以暂时把firewalld先停掉
因为firewalld也是为了用户配置更简单吧，给了用户更友好的交互方式，然后用户的
配置指令，firewalld也是翻译给iptables, iptables再找内核模块netfilter去在内核层面执行
可以这么说，一般把iptables称为防火墙，是因为iptables调用
netfilter模块来进行流量过滤，利用netfilter内核模块的五个钩子点
也称为iptables的五条链
其实称为五个钩子点 ，可能更好理解一点
因为区别是，到底是链还是点？
prerouting
postrouting
input
output
forward
也就是数据到内核这了
内核有五个管理处来管理数据包
prerouting，数据包进入路由表之前，要怎么处理
postrouting，数据包离开路由表，往外发的时候，要怎么处理
（这里说一下，常用的snat源地址网络地址转换，内网机器上外网就是在这个点做改变，把数据包的源ip，本来是内网ip，出站的时候改成公网ip，就可以访问公网服务了，这个操作，的点，就是在内核模块netfilter的postrouting这个点上来执行的，具体操作方式是netfilter内核模块的提供的命令行工具iptables，然后在命令行设置规则，netfilter在内核层面就是运用这些规则）
input，数据包到达本地，这个管理处看怎么处理
output 出站
forward 数据包转发给其他主机
总结的是，iptables调用netfilter模块，可以实现流量更精细的控制，等于说，功能多。
而一般情况是功能多，其中单个功能的性能就一般。
相对来说
ipvs的方式，专注于负载均衡
核心是一个lvs虚拟服务器
所谓lvs，就是linux virtual service
linux虚拟服务器
这个虚拟服务器
跟传统的服务有点不一样
传统的服务大多是在应用层提供服务的
比如常见的web服务，比如nginx、apache、tomcat
openjdk跑个java运行环境
jenkins服务
maven
jde
等开发工具
更直观来讲
我们在图形界面
比如windows操作系统
安装的绝大多数软件都是工作在应用层的
开发人员写代码，也是在应用层JDE上写
写好了去调用编译器解释器去翻译给机器看
事实是，编译的结果是二进制文件
那么既然是文件，且能够在目录中查询到
基本上也都是应用层的服务交互的结果。
说回ipvs内核模块
工作在内核层面，
所谓的lvs虚拟服务器
不像传统的装包配置起服务，
也不像容器化的用镜像跑容器，在容器里面运行进程
如果说需要软件包，就是ipvsadm，然后用户在
命令行界面用这个命令行工具去部署ipvs的规则
但是在k8s，这个不用
先不说过程
先说结果
结果就是
系统调用ipvs内核模块
来生成具体的负载均衡路由方式
由一个虚拟服务器的虚拟ip地址接待流量
是vip，不是按个尊贵的vip，是一个virtual ip，是一个虚拟的ip地址
这个虚拟的ip地址接待访问流量
然后通过arp内核抑制的方法
把后端服务器的arp隐藏掉
客户端的访问请求到达vip
vip这里再搞个操作，把访问请求报文
的目标mac地址，给到抑制了arp的后端真实服务器
对于客户端来讲，客户要访问的ip是那个谁谁谁
而lvs集群告诉客户端的信息是，我就是那个谁谁谁
我的ip就是你要找的ip
客户端说是吗？
我先找人的时候，先搞arp地址请求
在网上问，我要找的ip是谁谁谁，这个谁谁谁，你把你的mac地址给我
我们对一下号
lvs集群怎么搞的
它就是让后端真实服务器的兄弟们悄悄的
别人发arp广播的时候，你们别吱声
这个功能是怎么实现的，是调整内核参数，arp_ingore = 1
忽略arp请求
再往深了讲，先不说了
先把k8s这一套怎么操作的说清楚
lvs的dr模式的内部原理
还有一个内核参数arp_anounce = 2
简单理解就是说
客户端的请求报文来到lvs集群的时候
lvs虚拟服务器让后端真实服务器arp_ignore = 1
就是别人来问的时候，你们别吱声
lvs虚拟服务说，本机器就是你要找的服务器
所以客户端的请求报文就到达lvs虚拟服务器了
然后lvs虚拟服务器通过修改报文的mac地址
把流量分配给后端干活的真实服务器
真实服务器完成计算任务后，将响应报文返回给客户端的时候
一般来讲，还是给lvs虚拟服务器，lvs虚拟服务器再给回客户端
就有点像nginx的反向代理了
但是
lvs的性能优秀就优秀在这个地方的与众不同
它集群的后端真实服务器返回数据的时候
不经过lvs虚拟服务器，
而是直接给客户端返回去。
管理员会有疑问，
根据同源策略，这样的报文回去，客户端不认啊
那能行吗
lvs就是这样搞的
用arp_anounce = 2
声明自己的另一张网卡
有意思的是，后端服务器的这个另一张网卡
是虚拟网卡，这个虚拟网卡的ip就是lvs接待流量的ip
后端真实服务器跑完应用程序生成响应报文了
回传数据的时候，报文的目标ip还是客户端的ip
为什么呢？
因为lvs虚拟服务器接待了流量转发给后端真实服务器的时候
只是改变了数据帧层面的帧头，也就是mac地址
而源目ip是包裹在数据帧之内的，所以
lvs虚拟服务器并没有改变报文的源目ip
它没有拆包
而数据包到了后端真实服务器那里
它就拆包，工作
然后搞完之后
返回响应报文
自然是目标ip就是客户端的ip
有意思的是
后端真实服务器进行了一个花操作
就是用arp_anounce = 2
让内核在返回响应报文的时候
给这个数据包的源ip用自己的
能够与客户端通信的ip地址
也就是那个虚拟ip地址
这个虚拟ip地址，lvs虚拟服务器和后端真实服务器都有，而且是一样的
那么这个数据包到达客户端那里
也不会有疑问
因为客户端访问的就是这个虚拟ip，vip
返回的数据包的源ip也是这个虚拟ip，vip
客户端觉得是ok的
是没问题的。
服务端集群这么一套搞下来，
就是lvs-dr模式了
linux vitual server - direct routing
linux虚拟服务器 - 直连 路由
这个好处是lvs虚拟服务器不用拆包
而且只管进来的流量，出去的流量不经手
所以负载减轻了好多
所以
就有了管理员常说的，lvs负载均衡性能好
它比nginx从性能方面来讲，就有这么一点了
出站的流量是后端服务器自己给出去的
那清闲了一半
这个也挺主要的。
总的来说
lvs的模式，可以用两句话大概概括
-
客户端来找服务器的时候，后端服务器说"不是我，不是我"
-
后端服务器给客户端返回数据的时候，后端服务器说"嘿嘿，就是我，我来啦"
那么lvs功能少，性能好，工作在四层
k8s集群创建服务的流程是这样的：
用户kubectl apply -f service_name.yaml
意思是告诉apiserver，我要创建一个service，名称叫service_name
apiserver会创建出来一个service
service的ip地址也是apiserver给提供的
kubeproxy主要是去找内核模块ipvs，说lvs虚拟服务器的ip就是这个了
也就是service的ip地址，后端的pod的ip
作为后端真实服务器和service的ip
组成一个lvs负载均衡集群。
那么ipvs内核模块就可以按照需求来创建一个lvs负载均衡集群
从整体来看，k8s集群可以视为一个大型的负载均衡集群
加上deployment、daemonset、statefulset、HPA
等控制器