江苏龙网

  1. 首页 > 人文 > >

『黑马程序员』网络模型来龙去脉，Kubernetes( 三 )


『黑马程序员』网络模型来龙去脉，Kubernetes
文章图片
它要做的事情就是：
『黑马程序员』网络模型来龙去脉，Kubernetes
文章图片
第1步 ， 绑定VIP到本地（欺骗内核）；首先需要让内核相信它拥有这样的一个虚IP ， 这是LVS的工作机制所决定的 ， 因为它工作在第四层 ， 并不关心IP转发 ， 只有它认为这个IP是自己的才会拆到TCP或UDP这一层 。 在第一步中 ， 我们将该IP设到内核中 ， 告诉内核它确实有这么一个IP 。 实现的方法有很多 ， 我们这里用的是iproute直接加local的方式 ， 用Dummy哑设备上加IP的方式也是可以的 。
第2步 ， 为这个虚IP创建一个IPVS的virtualserver；告诉它我需要为这个IP进行负载均衡分发 ， 后面的参数就是一些分发策略等等 。 virtualserver的IP其实就是我们的ClusterIP 。
第3步 ， 为这个IPVSservice创建相应的realserver 。我们需要为virtualserver配置相应的realserver ， 就是真正提供服务的后端是什么 。 比如说我们刚才看到有三个Pod ， 于是就把这三个的IP配到virtualserver上 ， 完全一一对应过来就可以了 。 Kube-proxy工作跟这个也是类似的 。 只是它还需要去监控一些Pod的变化 ， 比如Pod的数量变成5个了 ， 那么规则就应变成5条 。 如果这里面某一个Pod死掉了或者被杀死了 ， 那么就要相应地减掉一条 。 又或者整个Service被撤销了 ， 那么这些规则就要全部删掉 。 所以它其实做的是一些管理层面的工作 。
啥？负载均衡还分内部外部
最后我们介绍一下Service的类型 ， 可以分为以下4类 。
1.ClusterIP集群内部的一个虚拟IP ， 这个IP会绑定到一堆服务的GroupPod上面 ， 这也是默认的服务方式 。 它的缺点是这种方式只能在Node内部也就是集群内部使用 。
2.NodePort供集群外部调用 。 将Service承载在Node的静态端口上 ， 端口号和Service一一对应 ， 那么集群外的用户就可以通过:的方式调用到Service 。
3.LoadBalancer给云厂商的扩展接口 。 像阿里云、亚马逊这样的云厂商都是有成熟的LB机制的 ， 这些机制可能是由一个很大的集群实现的 ， 为了不浪费这种能力 ， 云厂商可通过这个接口进行扩展 。 它首先会自动创建NodePort和ClusterIP这两种机制 ， 云厂商可以选择直接将LB挂到这两种机制上 ， 或者两种都不用 ， 直接把Pod的RIP挂到云厂商的ELB的后端也是可以的 。
4.ExternalName摈弃内部机制 ， 依赖外部设施 ， 比如某个用户特别强 ， 他觉得我们提供的都没什么用 ， 就是要自己实现 ， 此时一个Service会和一个域名一一对应起来 ， 整个负载均衡的工作都是外部实现的 。
下图是一个实例 。 它灵活地应用了ClusterIP、NodePort等多种服务方式 ， 又结合了云厂商的ELB ， 变成了一个很灵活、极度伸缩、生产上真正可用的一套系统 。
『黑马程序员』网络模型来龙去脉，Kubernetes
文章图片
首先我们用ClusterIP来做功能Pod的服务入口 。 大家可以看到 ， 如果有三种Pod的话 ， 就有三个ServiceClusterIP作为它们的服务入口 。 这些方式都是Client端的 ， 如何在Server端做一些控制呢？
首先会起一些Ingress的Pod（Ingress是K8s后来新增的一种服务 ， 本质上还是一堆同质的Pod） ， 然后将这些Pod组织起来 ， 暴露到一个NodePort的IP ， K8s的工作到此就结束了 。
任何一个用户访问23456端口的Pod就会访问到Ingress的服务 ， 它的后面有一个Controller ， 会把ServiceIP和Ingress的后端进行管理 ， 最后会调到ClusterIP ， 再调到我们的功能Pod 。 前面提到我们去对接云厂商的ELB ， 我们可以让ELB去监听所有集群节点上的23456端口 ， 只要在23456端口上有服务的 ， 就认为有一个Ingress的实例在跑 。


推荐阅读


上一篇：FAST探索■你会支持谁？，如果以下4款国产手机互撕

下一篇：「小松鼠文选」自用半个月：怪我以前太不识货了！，从华为P30换到三星S20＋