服务发现与负载均衡机制Service实例创建

2024-09-28 17:52:44

什么是Service？

Service是逻辑上的一组Pod，一种可以访问Pod的策略，而且其他Pod可以通过Service访问到这个Service代理的Pod，可以把它理解为传统架构中的反向代理。

相对于Pod而言，Service有一个固定的名称，不会发生改变，并且提供了负载均衡的功能。

通过Service的定义，可以对客户端应用屏蔽后端Pod实例数量及Pod IP地址的变化，通过负载均衡策略实现请求到后端Pod实例的转发，为客户端应用提供一个稳定的服务访问入口地址。

Service实现的是微服务架构中的几个核心功能：全自动的服务注册、服务发现、服务负载均衡等。

创建一个Service实例

apiVersion: v1
kind: Service
metadata:
  labels:
    app: nginx-svc
  name: nginx-svc
spec:
  ports:
  - name: http #service端口名称
    port: 80 #service自己的端口
    protocol: TCP #支持TCP UDP SCTP等
    targetPort: 80 #后端应用接口
  - name: https
    port: 443
    protocol: TCP
    targetPort: 443
  selector:
    app: nginx  #这个就是匹配规则，代理标签中有nginx的后端服务器
  sessionAffinity: None
  type: ClusterIP

执行上面的yaml文件，创建一个service

[root@k8s-master01 ~]# kubectl create -f nginx-svc.yaml
service/nginx-svc created
[root@k8s-master01 ~]# kubectl get svc
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
kubernetes   ClusterIP   10.96.0.1       <none>        443/TCP          9d
nginx-svc    ClusterIP   10.110.150.87   <none>        80/TCP,443/TCP   15s

我们通过访问svc地址就能访问到后端的nginx

[root@k8s-master01 ~]# curl 10.110.150.87
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/" rel="external nofollow" >nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/" rel="external nofollow" >nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

在同一个namespace中，其他Pod访问svc只需要curl http://nginx-svc就可以
跨namespace的话，需要在svc名称后加.namespace名称就可以了，使用需谨慎，没必要不推荐
不建议通过IP地址访问，因为IP不是固定的，删除或重建后IP会随机生成

注意，以上内容只能在集群内部访问

集群外部访问svc

希望在生产中使用某个固定的名称而非IP地址进行访问外部的中间件服务
希望Service指向另一个namespace中或其他集群中的服务
某项目正在迁移至k8s集群，但是一部分服务仍然在集群外部，此时可以使用service代理外部的服务

创建代理外部应用的Service实例

下面我们定义一个外部应用的service

apiVersion: v1
kind: Service
metadata:
  labels:
    app: nginx-svc-w
  name: nginx-svc-w
spec:
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 80
#  - name: https
#    port: 443
#    protocol: TCP
#    targetPort: 443
#  selector:
#    app: nginx
  sessionAffinity: None
  type: ClusterIP

区别就是少了这两个参数：

  selector:
    app: nginx

创建成功后查看，可以发现虽然创建成功了但是没有ENDPOINTS

[root@k8s-master01 ~]# kubectl get svc
NAME          TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
kubernetes    ClusterIP   10.96.0.1       <none>        443/TCP          9d
nginx-svc     ClusterIP   10.110.150.87   <none>        80/TCP,443/TCP   31m
nginx-svc-w   ClusterIP   10.110.144.61   <none>        80/TCP           58s
[root@k8s-master01 ~]# kubectl get ep
NAME         ENDPOINTS                                                          AGE
kubernetes   192.168.10.2:6443,192.168.10.3:6443,192.168.10.4:6443              9d
nginx-svc    172.17.125.10:443,172.18.195.22:443,172.17.125.10:80 + 1 more...   31m

接下来我们需要手动创建一个自定义的ENDPOINTS借用存在的ep生成一个新的ep文件

[root@k8s-master01 ~]# kubectl get ep nginx-svc -o yaml > nginx-ep-w.yaml

apiVersion: v1
kind: Endpoints
metadata:
  labels:
    app: nginx-svc-w
  name: nginx-svc-w
  namespace: default
subsets:
- addresses:
  - ip: 110.242.68.3 # 代理的外部服务的地址
  ports:
  - name: http
    port: 80
    protocol: TCP

可以看到已经有外部的代理了

[root@k8s-master01 ~]# kubectl create -f nginx-ep-w.yaml
endpoints/nginx-svc-w created
[root@k8s-master01 ~]# kubectl get ep
NAME          ENDPOINTS                                                          AGE
kubernetes    192.168.10.2:6443,192.168.10.3:6443,192.168.10.4:6443              9d
nginx-svc     172.17.125.10:443,172.18.195.22:443,172.17.125.10:80 + 1 more...   47m
nginx-svc-w   110.242.68.3:80                                                    11s

接下来试试能不能访问成功

# 直接访问的话是通的，返回值200
[root@k8s-master01 ~]# curl baidu.com -I
HTTP/1.1 200 OK
Date: Mon, 14 Feb 2022 01:43:18 GMT
Server: Apache
Last-Modified: Tue, 12 Jan 2010 13:48:00 GMT
ETag: "51-47cf7e6ee8400"
Accept-Ranges: bytes
Content-Length: 81
Cache-Control: max-age=86400
Expires: Tue, 15 Feb 2022 01:43:18 GMT
Connection: Keep-Alive
Content-Type: text/html
# 通过访问service的IP可以看到也是通的，返回值200
[root@k8s-master01 ~]# curl 10.110.144.61 -I
HTTP/1.1 200 OK
Date: Mon, 14 Feb 2022 01:44:20 GMT
Server: Apache
Last-Modified: Tue, 12 Jan 2010 13:48:00 GMT
ETag: "51-47cf7e6ee8400"
Accept-Ranges: bytes
Content-Length: 81
Cache-Control: max-age=86400
Expires: Tue, 15 Feb 2022 01:44:20 GMT
Connection: Keep-Alive
Content-Type: text/html

如果业务变更ep地址变了怎么办?只需要在ep中将代理的地址更换即可。

比如我们更换一个taobao的地址测试：

# 取出taobao的IP
[root@k8s-master01 ~]# ping taobao.com
PING taobao.com (140.205.94.189) 56(84) bytes of data.
64 bytes from 140.205.94.189 (140.205.94.189): icmp_seq=1 ttl=128 time=27.4 ms
64 bytes from 140.205.94.189 (140.205.94.189): icmp_seq=2 ttl=128 time=27.4 ms
# 修改ep的yaml文件：nginx-ep-w.yaml
apiVersion: v1
kind: Endpoints
metadata:
  labels:
    app: nginx-svc-w
  name: nginx-svc-w
  namespace: default
subsets:
- addresses:
  - ip: 140.205.94.189 # taobao
  ports:
  - name: http
    port: 80
    protocol: TCP
# 重新加载
[root@k8s-master01 ~]# kubectl replace -f nginx-ep-w.yaml

访问测试一下看是否连通：这个返回501是没问题的。

[root@k8s-master01 ~]# curl 10.110.144.61 -I
HTTP/1.1 501 Not Implemented
Server: Tengine
Date: Mon, 14 Feb 2022 01:39:16 GMT
Content-Type: text/html
Content-Length: 583
Connection: close

Service反代外部域名

这个不说了，知道怎么配就行了。
Service的yaml文件：

apiVersion: v1
kind: Service
metadata:
  labels:
    app: nginx-svc-wname
  name: nginx-svc-wname
spec:
  type: ExternalName
  externalName: www.baidu.com

然后创建就行了：

kubectl apply -f nginx-svc-wname.yaml

Service 的类型：

ClusterIP：在集群内部使用，默认

ExternalName：通过返回定义的CNAME别名

NodePort：在所有安装了kube-proxy的节点上打开一个端口，此端口可以代理至后端Pod，然后集群外部可以使用节点的IP地址和NodePort端口号访问到集群Pod服务。端口取值范围默认30000-32767

LoadBalancer：使用云服务商提供的负载均衡器公开服务

以上就是服务发现与负载均衡机制Service实例创建的详细内容，更多关于服务发现与负载均衡Service的资料请关注我们其它相关文章！

浅谈服务发现和负载均衡的来龙去脉

问题缘由随着时代发展,单机程序遇到了计算力和存储的双重瓶颈,分布式架构应运而生.单体应用通过函数名(标识)便可轻松完成本地函数调用,在分布式系统中,服务(RPC/RESTful API)承担了类似的角色,但请求服务单靠服务名还不够,服务名只是服务能力(服务类型)的标识,还需要指示服务位于网络何处,而部署在云中的服务实例IP是动态分配的,扩缩容.失败和更新则让问题变得更加复杂,静态配置服务实例适应不了新变化,需要更精细化的服务治理能力,为了解决或者说简化这个问题,服务发现作为一种基础能力被抽象和
详解Docker Swarm服务发现和负载均衡原理

本文将介绍基于 DNS 的负载均衡.基于 VIP 的负载均衡和路由网格(Routing Mesh). 使用的技术 Docker 使用了 Linux 内核 iptables 和 IPVS 的功能来实现服务发现和负载均衡. iptables 是 Linux 内核中可用的包过滤技术,它可用于根据数据包的内容进行分类.修改和转发决策. IPVS 是 Linux 内核中可用的传输级负载均衡器. 准备工作 swarm 集群: [Manager]node1.[Worker]node2 客户端镜像: regis
微服务架构之服务注册与发现功能详解

目录微服务的注册与发现 1.服务注册 2.服务发现 3.注册中心 4.现下的主流注册中心 4.1 Eureka 4.1.1 介绍 4.1.2 整体架构 4.1.3 接入Spring Cloud 4.2 ZooKeeper 4.2.1 介绍 4.2.2 整体架构 4.2.3 接入Dubbo生态 4.3 Consul 4.3.1 介绍 4.3.2 整体架构 4.3.3 生态对接 4.4 总结对比详解微服务架构及其演进史微服务全景架构全面瓦解微服务架构拆分策略详解微服务的注册与发现我们前面
服务器负载均衡是什么意思（服务器负载均衡的基本功能和实现原理）

什么是负载均衡? 负载均衡是由多台服务器以对称的方式组成一个服务器集合,每台服务器都具有等价的地位,都可以单独对外供应效力而无须其他服务器的辅助.经过某种负载分管技术,将外部发送来的央求均匀分配到对称结构中的某一台服务器上,而接收到央求的服务器独登时回应客户的央求.均衡负载可以平均分配客户央求到服务器列阵,籍此供应快速获取重要数据,解决很多并发访问效力问题.这种群集技术可以用最少的出资取得接近于大型主机的性能. 负载均衡的类型根据DNS的负载均衡经过DNS效力中的随机姓名解析来完结负载均衡,
服务发现与负载均衡机制Service实例创建

目录什么是Service? 创建一个Service实例集群外部访问svc 创建代理外部应用的Service实例 Service反代外部域名 Service 的类型: 什么是Service? Service是逻辑上的一组Pod,一种可以访问Pod的策略,而且其他Pod可以通过Service访问到这个Service代理的Pod,可以把它理解为传统架构中的反向代理. 相对于Pod而言,Service有一个固定的名称,不会发生改变,并且提供了负载均衡的功能. 通过Service的定义,可以对客户端应
Spring Cloud Alibaba Nacos服务治理平台，服务注册、RestTemplate实现微服务之间访问负载均衡访问的问题

目录 Nacos简介 ☘Spring Cloud 组件依赖版本 ☘Nacos部署 ☘访问Nacos平台 Nacos服务注册.微服务访问.负载均衡实现 nacos-consumer微服务创建 ☘nacos-provider微服务创建测试 Nacos简介 Github:https://github.com/alibaba/nacos官网文档:https://nacos.io/zh-cn/docs/what-is-nacos.htmlNacos 提供了发现.配置和管理微服务能力,能快速实现动态服务发
springcloud中Ribbon和RestTemplate实现服务调用与负载均衡

文件目录结构文件目录结构很重要,特别注意的是rule文件要放在主启动类上一级位置,才能够扫描. 写pom <dependencies>  <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependenc
k8s 中的 service 如何找到绑定的 Pod 及实现 Pod 负载均衡的方法

目录 k8s 中的 service 如何找到绑定的 Pod 以及如何实现 Pod 负载均衡前言 endpoint kube-proxy userspace 模式 iptables ipvs kernelspace 服务发现环境变量 DNS 总结参考 k8s 中的 service 如何找到绑定的 Pod 以及如何实现 Pod 负载均衡前言 Service 资源主要用于为 Pod 对象提供一个固定.统一的访问接口及负载均衡的能力. service 是一组具有相同 label pod 集合的抽
Java Grpc实例创建负载均衡详解

Grpc是googe开发的,是一款语言中立.平台中立.开源的远程过程调用(RPC)系统.新公司的项目服务之间的调用使用的Grpc来实现服务间的调用,这边一开始接到的工作内容是基于Nginx实现Grpc服务端的负载均衡.Nginx的1.13及以上版本是支持grpc的反向代理和负载均衡的.但是公司的nginx服务器的版本是1.10的,所以没办法直接使用grpc的代理.只能使用更底层的tcp层的负载均衡.最终服务跑起来是感觉挺简单的,但是nginx的基础太差,所以过程有点曲折.还是记录下吧. 文章分两
Springcloud ribbon负载均衡算法实现

一前言经过几篇的cloud系列文章,我想大家都有一个坚实的基础,后续的学习就会轻松很多,如果是刚刚来看的读者需要有eureka基础知识,或者查阅知识追寻者的cloud系列专栏:这篇文章主要讲解如何使用ribbon实现web service客户端调用,ribbon默认算法实现负载均衡等! 二 ribbon简介 ribbon是一个客户端负载均衡器,其能够整合不同的协议工具进行web service API 调用: 主要特色如下: 提供可插拔式的负载均衡整合服务发现故障弹性恢复cloud支持客户端
ASP.NET Core3.1 Ocelot负载均衡的实现

1.负载均衡 Ocelot可以在每个路由的可用下游服务中实现负载均衡,这使我们更有效地选择下游服务来处理请求.负载均衡类型: LeastConnection:根据服务正在处理请求量的情况来决定哪个服务来处理新请求,即将新请求发送到具有最少现有请求的服务去处理.算法状态没有分布在Ocelot集群中. RoundRobin:遍历可用服务并发送请求.算法状态没有分布在Ocelot集群中. NoLoadBalancer:从配置或服务发现中获取第一个可用服务来处理新请求. CookieStickySess
详解SpringCloud的负载均衡

目录一.什么是负载均衡二.负载均衡的简单分类三.为什么需要做负载均衡四.springCloud如何开启负载均衡五.IRule 1.RandomRule:表示随机策略,它将从服务清单中随机选择一个服务: 2.ClientConfigEnabledRoundRobinRule:ClientConfigEnabledRoundRobinRule并没有实现什么特殊的处理逻辑,但是他的子类可以实现一些高级策略, 当一些本身的策略无法实现某些需求的时候,它也可以做为父类帮助实现某些策略,一般情况下