service
更新于:2024年3月9日
Service
目录
[toc]
原文链接
https://onedayxyy.cn/docs/service.md
推荐文章
我的开源项目:
https://onedayxyy.cn/docs/MyOpenSourceProject
本节实战
实战名称 |
---|
💘 实战:定义与创建Service-2023.2.11(测试成功) |
💘 实战:多端口Service定义-2022.7.21(测试成功) |
💘 实战:Service代理模式-kubeadm方式修改ipvs模式-2022.7.21(测试成功) |
💘 实战:二进制方式修改ipvs模式-2023.2.11(测试成功) |
💘 实战:NodePort测试-2023.2.11(测试成功) |
💘 实战:ExternalName类型自定义Endpoints测试-2023.2.12(测试成功) |
💘 实战:Endpoints测试-2023.2.12(测试成功) |
💘 实战:EndpointSlice 使用-2023.2.12(测试成功) |
==💘 实战:多端口Service定义-2023.2.12(测试成功)==
- 实验环境
实验环境:
1、win10,vmwrokstation虚机;
2、k8s集群:3台centos7.6 1810虚机,1个master节点,2个node节点
k8s version:v1.25.4
containerd://1.6.10
- 实验软件(无)
1、Service
1.Service概念
我们前面的课程中学习了一些常用控制器的基本用法,我们也了解到 Pod 的生命是有限的,死亡过后不会复活了。然后我们知道可以用 ReplicaSet 和 Deployment 来动态的创建和销毁 Pod,每个 Pod 都有自己的 IP 地址,但是如果 Pod 重建了的话那么他的 IP 很有可能也就变化了(有的网络插件,支持重建pod后,其pod ip是不变的,但大多数网络插件,pod重建后,其pod ip都会被重新分配的。)。这就会带来一个问题:比如我们有一些后端的 Pod 集合为集群中的其他应用提供 API 服务,如果我们在前端应用中把所有的这些后端的 Pod 的地址都写死,然后以某种方式去(比如轮询方式)访问其中一个 Pod 的服务,这样看上去是可以工作的,对吧?但是如果这个 Pod 挂掉了,然后重新启动起来了,是不是 IP 地址非常有可能就变了,这个时候前端就极大可能访问不到后端的服务了。
遇到这样的问题该怎么解决呢?在没有使用 Kubernetes 之前,我相信可能很多同学都遇到过这样的问题,不一定是 IP 变化的问题,比如我们在部署一个 WEB 服务的时候,前端一般部署一个 Nginx 作为服务的入口,然后 Nginx 后面肯定就是挂载的这个服务的大量后端服务,很早以前我们可能是去手动更改Nginx 配置中的 upstream 选项,来动态改变提供服务的数量。到后面出现了一些服务发现的工具,比如 Consul、ZooKeeper 还有我们熟悉的 etcd 等工具,有了这些工具过后我们就可以只需要把我们的服务注册到这些服务发现中心去就可以,然后让这些工具动态的去更新 Nginx 的配置就可以了,我们完全不用去手工的操作了,是不是非常方便。
同样的,要解决我们上面遇到的问题是不是**实现一个服务发现的工具也可以解决?**没错的,当我们 Pod 被销毁或者新建过后,我们可以把这个 Pod 的地址注册到这个服务发现中心去就可以,但是这样的话我们的前端应用就不能直接去连接后台的 Pod 集合了,应该连接到一个能够做服务发现的中间件上面,对吧?
为解决这个问题 Kubernetes 就为我们提供了这样的一个对象 - Service,Service 是一种抽象的对象,它定义了一组 Pod 的逻辑集合和一个用于访问它们的策略,其实这个概念和微服务非常类似**。一个 Serivce 下面包含的 Pod 集合是由 Label Selector 来决定的。**
比如我们上面的例子,假如我们后端运行了3个副本,这些副本都是可以替代的,因为前端并不关心它们使用的是哪一个后端服务。尽管由于各种原因后端的 Pod 集合会发送变化,但是前端却不需要知道这些变化,也不需要自己用一个列表来记录这些后端的服务,Service 的这种抽象就可以帮我们达到这种解耦的目的。
画图说明如下: