00:00
大家好。欢迎大家继续收看上硅谷的Linux云计算视频。我是汪洋老师。那之前呢,给大家讲解了我们的资源控制器,对吧?好,那其实在资源控制下,我们会暴露一些问题。我们在这里给大家分析一下,我们先创建一个PPT给大家画一下,我们看下效果。之前我们在讲我们控制器的时候,我们应该还记得讲了一个deployment对吧。假设我现在要部署这么一个结构,前端是一个endings,后端是我们的一些PHP的FPM模块。这里有很多个。好,然后呢,底下是我们的一个数据库,对于这个结构,现在如果我让你把它部署进我们的K8S,应该不难了,对吧?先创建一个我们的什么RS也好,Deployment也好,我们之前说过最好去创建deployment,通过deployment去部署一个它的副本数目一,对吧,然后再去部署一个deployment PHP的它的部署的副本数目为三,再部署一个my circle,通过我们的step set去部署。
01:21
当然这个的部署方案呢,我们暂时还没有学到,对吧?所以除了最后一个的部署可能会有些问题,其他几个部署8S应该已经不成问题了,对吧。好,那。在pad里呢,我就可以去调用我们三个不同的pipf PM的它的地址信息,达到这么一个对外暴露,负载均衡的这么一个功能。但其实有些问题大家有没有想过?假设这三个是由我们一个deployment去管理的。如果有一天。比如他的代码肯定叫幺幺,我们就随便写了哈,它的代码叫R,它的代码叫三三,如果有一天幺幺这个pod死了。
02:05
泡了死了变黑了对吧,死了好,那我们的在这里的line问题。那这里的呢,会监控到发现我的副本数目已经不为三了,所以他要再启动一个新的pod去把它给替代掉,满足这里的pot符合它的期望值为三的期望值。也就意味着这里的IP在后期的一个。运行中可能会被更改。他更改完毕以后,你的endings,它的up STEM区里写的IP地址跟你的真实环境就已经不一致了。是不是已经出现错误了?那如果我告诉你,你需要写个脚本,实时的监测这里的IP有没有变化,如果有的话,需要去更改里面的配置文件,并且把它重载,达到这么一个更新状态的话。
03:07
那这个K8S集群根本没有咱们想象中的这么优秀。因为他的管理工作依然会很大很大。能理解我的意思吧?好。那K8S到底有没有机制去帮我们去完成这个事件呢?肯定是有的,不然的话我也不会给大家提了,对吧,那他的机制呢,就叫SVC。SVCSVC呢,负责去监测它所匹配的pod的这么一个状态信息,把它加入到S队列SDC的队列里来,你可以理解为它是一个新的对象。这个SVC的对象呢,专门就去做这种所谓的服务发现的。也就意味着我定义一个SVC,比如叫PP-HSVC,它会根据标签匹配到后面三个不同的pod上,把这些pod信息记录到SVC的负载队列里来。在N里,我的配置信息只需要指定到pip的SVC即可。
04:18
后期这些pod如果有变化的话,如果有更新的话,这个更新信息会被同步到SVC里,那nnux再去反向代理的SVC的话,SVC会自己把它给更改掉,更新掉不需要我们在Linux里去做任何的修改。这就是我们的SVC的机制。也就意味着我一旦引入SVC以后,你后面的后后端的的不管是扩容,不管是扩容还是所谓的更新,都不会对我们的恩尼斯的反向代理造成影响,或者上一层服务的访问造成影响。能理解我的意思吧,SVC,我们可以把它理解为辅助发现对吧?好,那接下来呢,我们就需要去对这个SVC进行详细的讲解,那接下来我们继续往后看。
05:15
刚刚给大家画了这么一张图,以后给大家简单讲一下SVC的一个能力或叫作用,为什么需要SVC对吧?那接下来呢,给大家详细的讲解一下我们的SVC的一些概念,包括它的SVC的一个分类,每种分类的有什么特点对吧?以及它的实现方案等等。好。那首先呢,我们先看一下,第一个就是我们的SVC的一个概念。对于我们的SVC来说呢,它是一个通过select,也就是标签选择的方式匹配一组。对外访问服务的这么一个机制。那每一个SVC呢,你就可以理解为是一个微服务了,这是完全没有问题的。那下面有一张图定义了一个我们的。
06:02
From front的这么一个deployment,这个deployment呢,创建了三个不同的portd,对吧,创建了三个不同的port,每个port里面有三个不同的这么三组标签。好,那这里我又定义了一个方的SVC。当APP等于外部APP。当我们的肉等于。的时候。他会去跟后边的一些炮去匹配。诶,你会发现这里的泡的是不是都满足它的条件多了是没有问题的,但是不能少,这里需要注意一下哈,你说诶还有个沃没有匹配到这里没有啊,这个没有问题,只要他有的能够匹配到即可,好。一旦匹配成功以后呢?这些炮子的信息会被写入到我们的这个SVC里的记录里来,那以后我们再去访问到这个SV的时候,相当于就是从旗下的三个炮中随机去访问一个。
07:01
那当然讲随机其实不太靠谱,原因是什么呢?这里有个访问策略,就是run Rubin啊轮询这里有且只有一个算法,就是run Rubin轮询,需要大家注意一下。好,并且当我们的后端的如果有死亡了以后,创建出来一个新的,这个新的还会被我们的ICVC监控到,更新到它的负载策略语去,需要大家注意一下。这就是我们的一个SVC。那SVC虽然好,但是有一个限制,就是它只提供的负载能力,也就意味着只能基于我们的IP地址和端口进行转发。实现负载均衡。没有七层的负载均衡的能力,也就是不能通过我们的主机名或域名的方案去负载均衡。当然这里的SVC说的是默认没有,我们可以通过后面给它添加一个Grace的方案,为它添加一个七层的负载功能的这么一个能力,这是完全没有问题的。SVC呢,有以下的四种类型,我们一个一个去看。
08:04
首先第一个就是我们class的IP类型,也是它的默认类型,叫自动分配一个仅class的内部可以访问到的虚拟IP,这个可以给大家画一下它的效果,对吧。好,这里有个K8S集群,比如他是note。你假设我们现在在这里定义的是我们的class的IP的类型。那我现在需要有一些一组炮的,比如我们先订一个deployment。Chineseline。这个n deploy的运行的话,会在后面去生成几个不同的D,对吧。
09:07
好,比如我们就有三个。然后我如果想访问这些pod的话,我需要定义一个比如叫恩尼斯的SVC,我们的名称就叫恩尼斯杠SVC。好,那这个SVC呢,会根据自己的标签去匹配到后面的pod,比如它的标签就是IP等于in。那每一个炮的是不是都会有这个标签啊?都必须要有这个标签,对吧,不能讲会,应该是必须。好,那这样的话,我访问到这个SVC,其实就反映到三个不同的尼,当然这里实现的方案是R的负载均衡,对吧?好,那如果是我们的class IP的SVC的类型的话,那就会在这里去。
10:08
这个SV在创建以后,就会创建一个class,或叫做集群内部IP,会创建一个集群内部IP,这个集训内部IP是可以允许被我们比如在集训内部还有一个其他的炮的,就叫R炮,这个2PORTD呢,可以完全可以通过这个集群的IP访问到我们后边的portd,也就直接写IP地址,直接写这个集群内部的IP地址,就可以访问到我们后边的这个port。这有点看不见啊,改个黑色的好,访问这个集群内部的IP地址,就可以访问到三个后面不同的pod,并且实现的是一个负载均衡的方案,这就是我们的class的IP。
11:06
只能被集群内部的应用程序所访问,也可以被node节点本身所访问,完全没有问题。好,那我们再看下一个。下一个胶囊,我们的叫做note。叫在class集群的基础之上,为SVC在每台机器上绑定一个端口,这样可以通过我们的noted来访问该服务。怎么去理解呢?首先你要知道第一点就是每台机器上帮我一个端口。那这个端口应该就是可以被外部所直接访问的端口了,对吧,所以noted也是我们的SVC默认类型里。比较常见的一个用于暴露K8S内部服务的这么一种方式。好,那我们过来给大家画一下,看看效果。前面呢都一致对吧,但是我这里呢,类型改成note。
12:02
好。如果是not po的类型的话,那在这里呢,集群的SVC呢,集群的IP呢,就会被改为对应的端点了,比如这个。后端端口为八零,并且它会在我们NO01上开启一个端口。物理机上哈开启端口,那比如这个端口是大于3万的。30001对吧,好,那这样的话,我访问这个节点的NOTE01的30001相当于就是访问我们的。这里定义的SVC的后端的端口八零。也就是你访问这个NOTE01的30001端口,相当于访问这三个不同服务的八零端口,当然依然是一个装了Robin的负载均衡的方案。并且它会在每一个note节点上都这么去做,比如这里还有个NOTE2,这个SVC也会暴露一个相同的30001的端口,也就意味着我们的外部的外部的应用程序或者是客户端。
13:12
它不管是访问到NOTE01的这么一个30001的端口,还是访问到NOTE02的30001的端口,都可以实现访问到这个SVC后端对应的这么一些pod的这么一个服务。也就意味着,如果我在这里加一个我们的负载电路器。比如是或者ending等等,那它的后端节点呢,写到我们的30001。和我们的。另一个端点的30001,那这样的话,大家其实可以看到一个效果,就是它实现了一个真正的负载均衡,对吧,客户端访问了这个endings endings呢,反向代理到这两台其中的一台。为什么要这样做呢?
14:00
如果你只是访问这个节点的IP的话,有一天这个pod,如果有一天这个note死了的话,我们的服务是不是还是中断了?如果访问的是我们的K8S的所有note节点呢,其中一个的话,并且在这里加了健康状态检测的话,那客户端怎么访问?是不是都是高可能的。能理解我的意思吗?所以noted正常情况下也会在外部去添加一个负载器,实现这么一种方案类型。需要大家了解一下。好,那这就是我们第二种。No part。那第三种。他说,在note po的基础之上,借助我们的cloud provide去创建一个外部的负载均衡器,将这些转将这些请求转发至node IP到note port。也就意味着。其实。对于我们的第三种。它跟第二种note pod最大的区别就是这里的我们的前端的这么一个负载均衡器,不需要自己去设置了,那这里只需要引入我们的云供应商。
15:12
云供应商给我们去暴露的一个服务接口即可,也就意味着只要我采用这种的第三种的这么一个SVC的方案,它就会自动在云服务器那里去进行注册,并且把对应暴露端口给它填写进去,实现了一个自动化流程。那但是呢,他需要去借助到我们的云供应商的这么一个附带的路器的解决方案,所以还是需要独立收费的,需要大家注意一下SVC对吧。那最后一个走external name,把集群外部的服务引入到集群内部来,在集群内部直接使用。没有任何类型的代理被创建。那这个呢,给大家去解释一下什么叫eternal name,那假设我现在用,我们用它吧,用它为模板,假设我们现在在外部有一个集群。
16:10
这个集群呢,可能是一个阿米巴的集群。好,那我在集群内部如果想访问到这个服务的话,你只需要写这个集群的IP即可,因为在这里会实现一个SVC的代理。那但是如果阿米巴的地址有一天进行更新的话,那我在这里的配置文件里需要去更新,太费劲了,对吧?所以在这个时候我们可以创建一个SVC,这个SVC并不会有对应的一些什么服务的端口被链接啊等等并不会有,而是这个SVC呢,会在内部创建一个。访问信息,比如这个SVC叫做嗯,My circlel-SVC,它这里会写上外部服务的IP地址,加上它的访问端点或它的主机名都可以,好,那这样的话,我们的这个n pod它只要定义访问数据库的时候,访问这一个SVC的地址信息即可。
17:20
如果有一天这个地址发生变化了,你只需要去更更新这个SVC的信息即可,后边的po的信息完全不需要去动,这是我们第四种的SVC。那这是我们的四种SVC了,没有问题吧?在这里呢,也给大家讲了一个SVC的这么一个基础的导论,对吧,好需要这么几个组件的配合。首先监听我们的服务和端点是由我们的IP去完成的,通过我们的去监控。那pro呢,负责去监控到对应的pod匹配的pod的信息,把它写入到我们的IP tables的规则里去,当你的客户端想去访问我们的SVC的时候,其实访问就是这里的IP tables规则被我们的导向到后端的pod的地址信息。
18:12
也就意味着这里有这么几个概念。第一个。客户端访问到我们的节点,是通过我们的IP去实现的。IP的规则是通过我们的去写入的。IPS serve通过监控我们的酷播pro去进行所谓的服务和断定信息的发现。会到监控。好,那cool pro呢,会通过我们的pod的标签去判断这一个断定信息是否写入到我们对应的SVC的。Endpoint,也就是锻炼,你锻炼信息里去。这就是这么一张图的最终的含义。这个呢,就是我们的一个SVC的一个类型的解释,以及SVC的含义,以及它的一个实现流程。
我来说两句