6、Kubernetes - Service/3、视屏/31、Kubernetes - Service 代理模式分类

欢迎大家继续收看上硅谷的零六次云计算视频，我是汪洋老师，之前呢给大家讲了我们的Co pro呢，可以通过我们的防火墙等机制去实现我们的负载均衡，对吧？那其实我们的VIP和斯Y代理及代理的模式还是有分类的呼叫更新，好，那我们先看第一个就是我们的在K8S中每一个node运行了一个库process竞争。呢，负责为S实现一种VIP，也就是我们的虚拟IP的形式，对吧，那这种虚拟IP的形式呢，我们就可以在集群内部去直接访问到它。而不是eternal的形式。在K8中。1.0版本代理完全由upa实现，在1.1新增了IP table这个代理方式，但不是默认的，1.2开始默认就是IP tables了，在1.8的BA0版本中添加了IPS的代理，你会发现随着我们版本的更新，这里的代理模式一直在变动，对吧？那如果我们去拿。

IP tables ipvs他们三个从性能角度考虑的话，那是逐级递增的，并且递增的。是非常明显的，能理解我的意思吗？那防火墙跟iOS比，那没有啥可比性吧，比较好理解对吧，好。在1.4版本中，1.14版本中开始默认使用我们的IP代理。那在1.0版本的时候，SVC是一个试概念，在1.1的时候新增了in Grace ipi的版，可以进行所谓的七成的负载均衡，那就是因为有了这么一个in increasece的ipi接口，我们才有后面的七成调度的这么一个功能。那这个呢，是对VIP和SVC的一个简述，对吧，那这里呢，还有一个叫做的概念内的概念，这个之前我们已经说过了，对吧，返回一个集群外部的这么一个地址信息，好。

那底下呢，有一个问，就是为何不使用装Rubin的电压去实现我们的负载均衡，我们大家想一下。给大家一分钟的时间，大家在脑海中想一下为什么不使用DNS进行负载均衡，你会发现不管是历史还是现在都没有使用过DNS。想通了吗？我们之前在讲DNS的时候，在讲我们的呃，负载均衡集群的时候，我们说为什么不采用DNS进行负载均衡集群，最大的一个，最有意义的一点就是。DNS会在很多的一些客户端里进行缓存。是这个意思吧。我们再去有很多服务，再去访问DNS进行域名解析的时候，解析完成以后，他得到地址以后，很多的一些服务都不会对所谓的DNS的解析进行。

清除缓存，清空缓存的操作，也就意味着一旦我有他的地址信息以后，我不管访问几次以后，还是这个地址信息。那这里的负载均衡也就不负载均衡了，对吧，很多都没有考虑它DNS的缓存问题，所以在这里肯定是不能使用我们DNS缓存去进行负载均衡的设置的，能理解我的意思吧。好，只能把它当做一个，怎么说呢，呃，辅助手段吧。那还有就是我们的代理模式的一个分类，就像我们刚才说的对吧，它分别有我们的UN，有我们的IP tables，有我们的ipvs，那这三种模式到底有怎样的区别，以及哪种模式到底最好，我们在进行代理模式分类的讲解，完成以后你会发现。Lips在最后一个添加是有道理的，或者是在最新版本中默认采用IPS是有理由的，对吧？好，我们现在第一种叫做U的代理模式，那这里呢，有一张我们的K8S的结构图，这里面有一个node X，一个node y。

好，并且在每个no里都运行了，分别运行了一个。以及两个serve po，也就是这个serve port是被访问端的，对吧，被访问端的好，那client po呢，就是我们的访问者，有一天他想访问我们的搜po，他需要先去访问到我们的防火墙，然后再从防火墙访问到pro，再从pro访问到，也就是它需要通过我们的pro进行一次代理。包括访问远程也是一致，先访问我们的IP tables，再访问远程的，再去访问到我们的。在这里你会发现我们的process它的压力是比较大的，对吧，包括我们的的IP也会监控这个process进行什么所谓的服务的更新，以及端点的。

端点的维护好，那这个是我们的第一种upa模式的这么一种运营方式，我们看第二种我们的IP式的代理模式，你会发现在这里，在这里我们所有的访问直接用我们的防火墙，直接用我们的防火墙去完成，而不需要再通过什么所谓的Google process去调度一段。那这样的话，我们的访问速度，访问速率就会大大增加，以及库的稳定性，包括压力，稳定性会提高，压力会减小，对吧，这也是我们在之前已经成为默认的这么一种调度的方案。那除了防火墙，它的性能可能没有那么高，其他之外没有任何缺点，很好理解对吧？包括我们的库ipi可以去进行监控，我们的库process，实现我们这里的端点的更新维护。好，这是IP tables代理模式，以及最后一种我们的IPVS代理模式。

你会发现，诶，这里的原来的IP变成了IPVS，也就是原来是把所有的调度规则通过我们的IP tables进行所谓的定向的变成了通过ipvs模块。也就是我们的内核模块对吧？好去实现我们所谓的负载均衡以及流量导向，我们的客户端只需要访问到这个ipvs服务，IPS服把你的请求分散到不同的pod上去运行即可完成，并且它也是不经过我们的库。那当然，这里的库pro也同样被IPSSO去监控维护这里的IPS模块的什么？服务器的对应信息对吧？端点的对应绑定信息，好，那也就意味着其实对于I ipvs和我们的IP apples的两种模式来说，除了这里的模块采用IPS，其他的都是一致的，对吧？好，那还需要注意一下，那还需要注一下，在这里呢，我们的l los需要开启这么多的一些算法以后才支持我们的IPS的代理模式，如果你提前没有安装我们的IPS模块，以及这些这些我们的最基础的一些需求没有被得到满足的话。

哪怕默认是。Ipvc的运营方式，它也会退成为IP table这个代理模式需要大家注意一下。好，那并且ippvs的这种代理模式呢，其实已经成为我们现行的一个标准了。那包括我们的集群现在呢，其实已经启用IPV的这么一个模式去进行所谓的负载均衡的，我们可以过来看一下ipvs I DM杠大LN看到了吗？

这些机群是不是已经出现了，我们可以看一下库CTRKSVC，那这里呢，已经有了一个叫做10.96.0.1的这么一个地址信息，对吧？好，那我们看一下10.96.0.143接口，转发到109119216866.10的643接口，也就是如果有人访问这么一个虚拟IP的43端口，会被访问到我们当前当前物理机物理IP的这么一个6643的端口上，那这是典型的一个。IPS的代理方式对吧，好，那这个呢，就是我们的三种的这么一个代理模式的实现好。