千家信息网

请输入关键字词

热门搜索排行

最新搜索排行

导航： 首页 > 服务器 >

Kubernetes里的Service究竟是如何工作的

发表于：2025-02-04 作者：千家信息网编辑
千家信息网最后更新 2025年02月04日，这篇文章将为大家详细讲解有关Kubernetes里的Service究竟是如何工作的，文章内容质量较高，因此小编分享给大家做个参考，希望大家阅读完这篇文章后对相关知识有一定的了解。Service是Kub
千家信息网最后更新 2025年02月04日Kubernetes里的Service究竟是如何工作的

这篇文章将为大家详细讲解有关Kubernetes里的Service究竟是如何工作的，文章内容质量较高，因此小编分享给大家做个参考，希望大家阅读完这篇文章后对相关知识有一定的了解。

Service是Kubernetes接入层的一种抽象资源，它为我们提供了一种固定的、统一的访问接口地址和负载均衡能力，这时可能会想到，当时使用docker-compose的时候，不存在Service概念，不也运行起来了吗？是的，在Kubernetes集群内部Pod ip也是互通的，但是Pod的ip会经常因为扩容、重建而导致客户端访问错误，pod访问无法提供负载均衡的能力，而Service通过选择一组Pod的label就直接可以访问到Pod，而且可以使用万年不变的域名，所以就选择Service了。

1、Service是怎么产生的，在集群内部是如何存在的呢？

在kubernetes当中所谓的Service是kube-proxy生成iptables或ipvs规则，它会产生一组虚拟地址，在集群环境下有效。Service不能直接到达Pod内部，中间会间隔EndPoints，这是一组ip和port的组合。默认类型是ClusterIP它仅能接收集群中pod客户端程序的访问请求。这也是最常用的一种类型，另外还有NodePort、LoadBalancer、ExternalName。

2、iptables或ipvs，到底是iptables还是ipvs呢？
一个Service对象就是工作节点上的一些iptables或ipvs规则，用于将到达Service对象IP地址的流量调度转发至相应的Endpoints对象指向的IP地址和端口之上。
这句话我们经常看到，如何理解呢？

Kubernetes1.1之前是基于userspace实现，这种模型之下，每次请求流量要先到达内核空间，经有套接字转发到kube-proxy，然后再由它送回到内核空间，之后调度到后端pod之上，可以看出请求在用户空间和内核空间来回转发，效率必然不高。但是当pod无响应时，能够自动重定向到其它pod。

在Kubernetes1.1版本开始引入iptables规则，Kubernetes1.2开始成为默认类型。即在创建Service资源时，集群上每个节点的kube-proxy都会收到通知，并且创建iptables规则，用于转发到此Service ClusterIP的流量。工作TCP/IP的传输层，高效稳定。
但是这种方式有如下缺点：
1、iptables代理模型挑中的pod无响应时，不能自动重定向到集群内部其它pod资源对象之上。
2、kube-proxy通过iptables处理Service和pod的交互，每产生一个计算节点或者产生大量的pod就需要产生相应大量的iptables规则，不难想象，这些iptables规则每次需要刷新匹配保证正确性，就需要占用大量的CPU资源，所以基于iptables的Service实现就成了制约Kubernetes承载更多pod的瓶颈。

在Kubernetes1.11开始默认使用ipvs模型，在这种模型下kube-proxy会跟踪APIServer上Service和endpoints对象变化，调用netlink创建ipvs规则，请求调度流量功能由ipvs实现，运行于netfilter之上的钩子函数，具有流量转发速度快，规则性能同步好的特点，支持众多调度算法，剩下仍然由iptables完成。说到这里我们就大概明白了iptables和ipvs的作用和关系了。

3、Kubernetes的服务发现是通过dns实现，那么为什么会出现四种类型的服务暴露方式呢？
说到Service不得不介绍kubernetes网络模型和通信方式

一个完整的Kubernetes集群应该包含三层网络，首先第一层是mater和node节点之间的网络，这个网络需要在部署kubernetes集群之前配置完成；
第二层网络是pod的网络通过kubelet或者cni插件实现，用于pod之间或者内部的通信，集群中的所有pod均处在同一个网络平面空间内，可以直接通信；
第三层网络是Service资源的网络，是一个虚拟网络，用于为Kubernetes集群配置IP地址，但此地址并不配置于任何主机或者容器的网络接口之上，而是通过kubeproxy配置为iptables规则，将发往该地址的所有流量调度至后端的pod之上。

通信方式分为以下四种：

  • 同一个pod的内部通信；

  • 各个pod彼此通信；

  • pod和service的通信；

  • 集群外部流向service的通信。


所以Service为了满足这些通信方式就出现了如下类型：
ClusterIP：为集群内部ip地址暴露服务，仅在集群内可达，外部ip无法访问，默认Service类型；

NodePort：这种类型建立在clusterIp之上，为节点的IP地址暴NodePort服务，外部节点可以通过NodeIP:NodePort直接访问；

LoadBalancer：这种类型构建在NodePort之上，它可以关联到集群外部的某个负载均衡设备。Kubernetes没有为私有化集群提供LoadBalancer的支持。如果在私有化集群使用需要自建负载均衡器；
ExternalName：其通过将Service映射至由externalName字段的内容指定的主机名来暴露服务，此主机名需要被DNS服务解析至CNAME类型的记录。这句话怎么理解呢？

举个例子，你所有的服务都在集群内部，但是你有个数据库是mongodb，没有实现容器化，更没有部署在Kubernetes内部，当然你可以通过在ConfigMap中添加配置访问这个外部服务，但是当你的环境发生变化，比如从开发环境和生产环境的数据地址不同，这个时候你需要修改和重建ConfigMap。
这个时候可以使用Kubernetes ExternalName内置服务发现机制运用于集群外部运行的服务，像使用集群内的服务一样使用外部服务！通过这种方式，您可以在开发环境和生产环境中实现相同的功能，如果您最终将服务移入集群内，则不需要更改任何代码和配置。
kind: ServiceapiVersion: v1metadata: name: mongospec: type: ExternalName externalName: mango123456.com
你只需要访问：mongodb://:@mongo:就可以自动访问外部服务。

4、Service本身有端口、Pod也有端口、容器也有端口，之间有什么关系呢？

containerPort：一个信息性数据，为集群提供一个可以快速了解相关pod可以访问端口的途径，而且显式指定容器端口，无论你是否指定都不影响其他节点上的客户端pod对其进行访问；

port：服务提供端口，用于kubernetes集群内部服务访问；

targetPort：pod目标端口，如果不设置使用默认port端口，port和nodePort的数据通过这个端口进入到Pod内部，Pod里面的containers的端口映射到这个端口，提供服务；
nodePort：Kubernetes集群外部用户访问端口；

关于Kubernetes里的Service究竟是如何工作的就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。

很赞哦！
集群 服务 端口 网络 地址 类型 规则 通信 节点 方式 流量 环境 对象 模型 空间 资源 调度 配置 工作 均衡 数据库的安全要保护哪些东西 数据库安全各自的含义是什么 生产安全数据库录入 数据库的安全性及管理 数据库安全策略包含哪些 海淀数据库安全审计系统 建立农村房屋安全信息数据库 易用的数据库客户端支持安全管理 连接数据库失败ssl安全错误 数据库的锁怎样保障安全 闵行区新型网络技术质量保障 服务器传输数据的理由 浙江巨声网络技术有限公司马俊 qt 数据库 二进制 机房网络安全升级通讯稿 南充创新网络技术有限公司 php插入数据库变量 pl sql 上传数据库吗 思科零信任网络安全架构 以网络安全为题目写一段话 网络安全 tafang 计算机网络安全问题是什么 网络安全防护概念 医院网络安全指哪些 网信办信息化网络安全 服务器双网卡有什么好处 远程管理web服务器 社工邮件网络安全问题 网络安全运营中心现状调研 网络安全法规定了由 梦幻西游服务器有专门pk吗 vs2012 数据库 我的世界服务器违规去哪举报 lnmp 数据库远程连接 机载网络安全 图书 长沙民政软件开发难吗 龙腾服务器安装win7 如何看自己是不是无限数据库 浦东新区无线网络技术产品 服务器设备的管理

相关文章

0