文章目录

• service【svc】

• • Service 的概念

• service介绍

• service网络服务模式【概念】

• • ClusterIp 【内部访问】

• NodePort【外部访问】

• LoadBalancer【外部负载均衡】

• ExternalName【直达模式】

• 特别说明

• service网络服务模式【实现】

• • ClusterIP【内部访问】
• • Headless Service【无头服务，无头服务也是一种Cluster IP,只不过是一种特殊的Cluster IP】

• NodePort【外部访问】

• LoadBalancer【外部负载均衡】

• ExternalName【直达模式】

• 实现原理

• k8s代理模式的分类

• • VIP 和 Service 代理

• 为何不使用 round-robin DNS?

• userspace代理模式

• iptables代理模式

• ipvs代理模式

• service实操

service【svc】

===========================================================================

Service 的概念

---

• Kubernetes Service定义了这样一种抽象：一个Pod的逻辑分组，一种可以访问它们的策略 —— 通常称为微服务。这一组Pod能够被Service访问到，通常是通过Label Selector

• Service能够提供负载均衡的能力，但是在使用上有以下限制：

只提供 4 层负载均衡能力，而没有 7 层功能，但有时我们可能需要更多的匹配规则来转发请求，这点上 4 层负载均衡是不支持的

service介绍

---

• Service(简称svc)定义了Pod的逻辑集合和访问该集合的策略，是真实服务的抽象。Service提供了一个统一的服务访问入口以及服务代理和发现机制，用户不需要了解后台Pod是如何运行。Service通过Label找到Pod组。因为Service是抽象的，所以在图表里通常看不到它们的存在，这也就让这一概念更难以理解。

• svc在整个集群中负责网络服务（并不是底层容器网络实现），因为pod实际上是不可靠的，可能会被停止或者重启，一旦重启就会导致IP地址发生变化，SVC的功能就是使用kube-proxy进行网络的控制，pod的IP发生变化上层业务并不会中断，kube-proxy采用负载均衡等策略实现网络服务。

• 例如通过定义一个RC启动了4个pod，如何让外部能优雅的调用到这几个pod提供的服务？由于pod的IP地址可能随时发生变化（pod不健康或期间被重启或被重建等），在pod的外层使用nginx等进行负载也就不太方便了，而Service 就是解决这个问题而存在的：可以根据pod的标签将对应的所有pod纳入一个负载均衡组的形式，通过kube-proxy 进行数据转发，提供一个外部到pod的唯一入口而不用关心pod的变动，进而实现和外部的调用通信。

service网络服务模式【概念】

---

Service 在 K8s 中有以下四种类型

ClusterIp 【内部访问】

ClusterIp：默认类型，自动分配一个仅 Cluster 内部可以访问的虚拟 IP【service创建一个仅集群内部可访问的ip，集群内部其他的pod可以通过该服务访问到其监控下的pod】

NodePort【外部访问】

NodePort：在 ClusterIP 基础上为 Service 在每台机器上绑定一个端口，这样就可以通过:NodePort 来访问该服务【在service及各个node节点上开启端口，外部的应用程序或客户端访问node的端口将会转发到service的端口，而service将会依据负载均衡随机将请求转发到某一个pod的端口上。一般暴露服务常用的端口】

LoadBalancer【外部负载均衡】

LoadBalancer：在 NodePort 的基础上，借助 cloud provider 创建一个外部负载均衡器，并将请求转发到: NodePort【在NodePort基础之上，即各个节点前加入了负载均衡器实现了真正的高可用，一般云供应商提供的k8s集群就是这种】

ExternalName【直达模式】

④　ExternalName：把集群外部的服务引入到集群内部来，在集群内部直接使用。没有任何类型代理被创建，这只有 kubernetes 1.7 或更高版本的 kube-dns 才支持【当我们的集群服务需要访问k8s之外的集群时，可以选择这种类型，然后把外部服务的IP及端口写入到k8s服务中来，k8s的代理将会帮助我们访问到外部的集群服务】

特别说明

• Service 创建网络服务一般分为集群内部访问（clusterIP ）和集群外部访问（NodePort）模式：

• 内部访问clusterIP 的方式会创建一个虚拟IP地址，该地址没有基于某个实际网卡创建，所以在宿主机上是无法访问的，仅能在集群内部访问，也就是在容器内部访问；

• 外部访问NodePort 是通过映射端口到宿主机的方式，访问地址为宿主机IP地址加上端口的方式，和hostPort 类似，但是NodePort 会在kubernetes集群的所有node上监听，也就是说创建一个Service ，配置了一个NodePort 监听30000端口，那么集群内所有的node都会监听30000端口，不管访问该node上有没有对应的pod，随意访问任何一台node的30000端口都可以被转发到正确的后端pod中；

service网络服务模式【实现】

---

这个实现只是代码简单说明【具体流程去看我的service实操】，里面有详细说明

ClusterIP【内部访问】

• clusterIP主要在每个node节点使用iptables【新版本模式是ipvs代理模式因此此处为ipvs，代理模式不同所使用的底层方案也是不一致的】，将发向clusterlP对应端口的数据，转发到kube-proxy中。然后kube-proxy自己内部实现有负载均衡的方法，并可以查询到这个service下对应pod的地址和端口，进而把数据转发给对应的pod的地址和端口

• 为了实现图上的功能，主要需要以下几个组件的协同工作：

• apiserver 用户通过kubectl命令向apiserver发送创建service的命令，apiserver接收到请求后将数据存储到etcd中

• kube-proxy kubernetes的每个节点中都有一个叫做kube-porxy的进程，这个进程负责感知service，pod的变化，并将变化的信息写入本地的iptables规则中

• iptables 使用NAT等技术将virtuallP的流量转至endpoint中

• 资源清单示例：

㈠创建一个Deployment

apiVersion: apps/v1

kind: Deployment

metadata:

name: myapp-deploy

namespace: default

spec:

replicas: 3

selector:

matchLabels:

app: myapp

release: stabel

template:

metadata:

1abels:

app: myapp

release: stabel

env: test

spec:

containers:

• name: myapp

image: fanqisoft/myapp:v2

imagePullPolicy: IfNotPresent

ports:

• name: http

containerPort: 80

apiVersion: v1

kind: Service

metadata:

name: myapp

namespace: default

spec:

type: ClusterIP

selector:

app: myapp

release: stabel

ports:

• name: http

port: 80

targetPort: 80

Headless Service【无头服务，无头服务也是一种Cluster IP,只不过是一种特殊的Cluster IP】

• 有时不需要或不想要负载均衡，以及单独的Service IP。遇到这种情况，可以通过指定 ClusterIP(spec.clusterIP)的值为“None”来创建 Headless Service。这类Service 并不会分配 Cluster IP,kube-proxy 不会处理它们，而且平台也不会为它们进行负载均衡和路由

• 主要的特点是通过无头服务的方式去解决hostname和portname的变化问题，也就是通过它去进行绑定

apiVersion: v1

kind: Service

metadata:

name: myapp-headless

namespace: default

spec:

selector:

app: myapp

clusterIP: “None”

ports:

• port: 80

targetPort: 80

• 对于svc，一旦创建成功以后，它会写入到coreDNS中去，我们的svc的创建会有一个主机名会被写入到coreDNS，写入的格式体就是 svc的名称+命名空间的名称+当前集群的域名

yum -y install bind-utils

dig -t A myapp-headless.default.svc.cluster.local. @10.96.0.10

• 意味着在无头服务中，虽然它没有ip了，但可以通过访问域名的方案依然可以访问服务下的pod

NodePort【外部访问】

• nodePort的原理在于在node上开了一个端口，将向该端口的流量导入到kube-proxy，然后由 kube-proxy进一步到给对应的pod

apiVersion: v1

kind: Service

metadata:

name: myapp

namespace: default

spec:

type: NodePort

selector:

app: myapp

release: stabel

ports:

• name: http

port: 80

targetPort: 80

• 查询流程

iptables -t nat -nvL

KUBE-NODEPORTS

LoadBalancer【外部负载均衡】

• loadBalancer和nodePort 其实是同一种方式。区别在于 loadBalancer 比nodePort多了一步，就是可以调用cloud provider【云供应商】 去创建LB【负载均衡】来向节点导流

ExternalName【直达模式】

• 这种类型的 Service 通过返回 CNAME和它的值，可以将服务映射到externalName字段的内容（例如：hub.coreqi.cn)。ExternalName Service 是Service的特例，它没有 selector，也没有定义任何的端口和Endpoint。相反的，对于运行在集群外部的服务，它通过返回该外部服务的别名这种方式来提供服务

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注Java获取）

最后

做任何事情都要用心，要非常关注细节。看起来不起眼的、繁琐的工作做透了会有意想不到的价值。
当然要想成为一个技术大牛也需要一定的思想格局，思想决定未来你要往哪个方向去走, 建议多看一些人生规划方面的书籍,多学习名人的思想格局，未来你的路会走的更远。

更多的技术点思维导图我已经做了一个整理，涵盖了当下互联网最流行99%的技术点，在这里我将这份导图分享出来，以及为金九银十准备的一整套面试体系，上到集合，下到分布式微服务

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！
大牛也需要一定的思想格局，思想决定未来你要往哪个方向去走, 建议多看一些人生规划方面的书籍,多学习名人的思想格局，未来你的路会走的更远。

更多的技术点思维导图我已经做了一个整理，涵盖了当下互联网最流行99%的技术点，在这里我将这份导图分享出来，以及为金九银十准备的一整套面试体系，上到集合，下到分布式微服务

[外链图片转存中…(img-I40vUwjr-1713530235272)]

[外链图片转存中…(img-2Dvr8QQQ-1713530235273)]

[外链图片转存中…(img-HaKdGmOg-1713530235275)]

[外链图片转存中…(img-UDGwNmp4-1713530235277)]

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！