kubernetes service 类型 以及工作原理

1.service 类型

2.ClusterIp

比如我们创建 service-tomcat 然后 ClusterIp 类型 会自动在 IPVS 生成一个 VIP 虚拟IP

然后将 IPVS的映射规则 根据选择器选中pod的ip 写进去 ,实现负载均衡的映射 这个规则他会自己去修改

这时候我们就可以写成这样

只要我们kubernetes 集群处于稳定状态 ,svc ClusterIp类型就会 一直存在,并且会动态的将后端pod的变化 更新至自己的负载均衡规则里去 好 至此我们达到了一个相对稳定的状态 这就是我们的cluseterip的意义

3.NodePort

其实很简单的在说一个问题,我们说这里有个用户,用户通过访问nginx的这个pod,问题是怎么把这个pod给用户呢,如果用户是集群以外的,pod的ip别忘了,它是一个扁平化的虚拟的IP,外部的用户是直接访问不到的

那就需要第二种类型 NodePort

创建一个service nodeport 类型 它就会在当前的物理网卡上绑定一个端口 这个端口一般大于3万,担任你也可以在启动我们对应的apiserver的时候去修改它的端口范围 默认30000以上

比如30001 那这个30001的物理网卡的物理端口绑定到哪里呢 依然是绑定到我们的ipvs集群

那这样的一个物理IP的物理端口 就成为了我们 ipvs集群的 VIP 虚拟IP 当然你也可以理解为是我们的集群IP 它的真实服务器就可以指向到我们当前的这个pod上 当然 service-N-NodePort 这边是不是也要加一个标签选择器 匹配 app=nginx 再由nginx 的upstream 指向另一个service-T-ClusterIp

负载均衡到 tomcat上面 给予用户访问

至此用户只需要访问物理网卡的物理端口 service-N-NodePort :30001 就可以被ipvs负载均衡到我们内部nginx 这个pod上 nginx 再通过自己的7层负载均衡 访问到我们的4层负载均衡上,再被我们4层负载均衡 再分发到我们对应的真实服务器上

所以大家会发现其实这里出现了多个负载均衡集群 4 7 4

相当于一个用户如果不加外部的net的话 那他出现的是 4层 7层 4层的负载均衡

4.loadbalancer

这是一个我们以云为载体的一种工作方式或叫做工作模式

举个例子

nodeport 并不是说在 master01 上 而是在当前的这个集群的所有节点对应的物理网卡都会存在这个物理接口

有这个物理端口

然后如果 在master01宕机了 ,那服务就不可用了,

我们可以再加一层 ipvs 集群 然后之间使用 keepalived方式进行心跳同步

整体高可用

很好的解决了每个节点的单点故障问题

这些都可以在私有云去搭建的

在阿里 百度 它们会有一个概念 LAAS(LoadBlance as a service) 负载均衡是一个服务 负载均衡既服务 它也是一种云服务的这么一个概念体现 我们只需要想官方对应的 LB的接口 发起创建负载均衡的请求 他会自动帮我们创建一个负载均衡与后端你需要去实现的真实服务器的机器关联,不再需要你自己去手动搭建ipvs

阿里云的SLB和CLB了解一下?

这个LB呢甚至可以由我们集群内部的apiservice 向它的接口发起创建

这样是不是就完成了呢

比如这是一个云供应商 CP

apiserver 这样的一个信息请求呢,我们是可以直接发出来的,当然其实本质上应该是放在每个节点kubeproxy去调用的,我们知道一下 由集群发起 发起对它的Apiserver的调用,调用完成后 CP 会帮我们创建出来负载均衡集群LB

当然如果非运营环境下的话,没有云供应商 能够帮我们提供laas服务那这个操作 工作类型是做不了的

所以在传统环境中 我们可以自己手动搭建ipvs去实现,只不过说第三种工作方式它能够更简化的帮我们去实现 在nodeport上加一步 高可用化

5.ExternalName

它是可以将我们的集群外部的服务 引入到集群内部的而且没有被任何代理所创建

举个例子

首先会给他起个名字 假设就叫db 描述所在的名称空间 default 写一下后端的域名或者是IP比如192.168.66.55

创建完成以后我们可以让tomcat pod 解析这个svc所产生的 DNS

注意:每一个svc创建完成以后,我们的DNS插件,在其内部都会出现一个默认域名,这个域名的格式一般是当前service的名字 比如在我们这叫db.当前名字空间的名字.svc.当前集群的域名 db.default.svc.cluster.local 当前集群域名默认为 cluster.local 可以在初始化的时候去更改,如果不更改默认就是 cluster.local

并不是基于IPVS去实现的

基于我们DNS去实现的

DNS别名机制

6.组件协调

采用的是 ipvs 的规则

相关推荐
键盘鼓手苏苏2 分钟前
Kubernetes与边缘AI最佳实践
云原生·kubernetes·k8
成为你的宁宁18 分钟前
【docker镜像加速器配置】
运维·docker·容器
风向决定发型丶31 分钟前
K8S中Pod驱逐介绍
docker·容器·kubernetes
海鸥8143 分钟前
Kubernetes 集群中缺少 kagent.dev/v1alpha2
云原生·容器·kubernetes
qq_396153451 小时前
docker ddns-go 忘记密码
docker·容器·golang
Zhu7581 小时前
【数据迁移】k8s平台本地数据迁移整改
云原生·容器·kubernetes
无效的名字1 小时前
windows下,怎么压缩Docker Desktop占用的磁盘空间
windows·docker·容器
不是书本的小明1 小时前
多套小规格k8s集群 集成到统一k8s集群
云原生·容器·kubernetes
小敬爱吃饭11 小时前
Ragflow Docker部署及问题解决方案(界面为Welcome to nginx,ragflow上传文件失败,Docker中的ragflow-cpu-1一直重启)
人工智能·python·nginx·docker·语言模型·容器·数据挖掘