7.7 KiB
Kubernetes资源对象service
著作:行癫 <盗版必究>
一:Service
将运行在一组 Pods 上的应用程序公开为网络服务的抽象方法
使用 Kubernetes,你无需修改应用程序即可使用不熟悉的服务发现机制;Kubernetes 为 Pods 提供自己的 IP 地址,并为一组 Pod 提供相同的 DNS 名, 并且可以在它们之间进行负载均衡
Kubernetes Service 定义了这样一种抽象:逻辑上的一组 Pod,一种可以访问它们的策略 —— 通常称为微服务
举个例子,考虑一个图片处理后端,它运行了 3 个副本。这些副本是可互换的 —— 前端不需要关心它们调用了哪个后端副本。 然而组成这一组后端程序的 Pod 实际上可能会发生变化, 前端客户端不应该也没必要知道,而且也不需要跟踪这一组后端的状态
1.定义 Service
例如,假定有一组 Pod,它们对外暴露了 9376 端口,同时还被打上 app=MyApp
标签:
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app: MyApp
ports:
- protocol: TCP
port: 80
targetPort: 9376
上述配置创建一个名称为 "my-service" 的 Service 对象,它会将请求代理到使用 TCP 端口 9376,并且具有标签 "app=MyApp"
的 Pod 上
Kubernetes 为该服务分配一个 IP 地址(有时称为 "集群IP"),该 IP 地址由服务代理使用
注意:
Service 能够将一个接收 port
映射到任意的 targetPort
。 默认情况下,targetPort
将被设置为与 port
字段相同的值
2.多端口 Service
对于某些服务,你需要公开多个端口。 Kubernetes 允许你在 Service 对象上配置多个端口定义
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app: MyApp
ports:
- name: http
protocol: TCP
port: 80
targetPort: 9376
- name: https
protocol: TCP
port: 443
targetPort: 9377
二:发布服务
1.服务类型
ClusterIP
NodePort
LoadBalancer
ExternalName
2.服务类型
对一些应用的某些部分(如前端),可能希望将其暴露给 Kubernetes 集群外部 的 IP 地址
Kubernetes ServiceTypes
允许指定你所需要的 Service 类型,默认是 ClusterIP
Type
的取值以及行为如下:
ClusterIP
:通过集群的内部 IP 暴露服务,选择该值时服务只能够在集群内部访问。 这也是默认的 ServiceType
NodePort
:通过每个节点上的 IP 和静态端口(NodePort
)暴露服务。 NodePort
服务会路由到自动创建的 ClusterIP
服务。 通过请求 <节点 IP>:<节点端口>
,你可以从集群的外部访问一个 NodePort
服务
LoadBalancer
:使用云提供商的负载均衡器向外部暴露服务。 外部负载均衡器可以将流量路由到自动创建的 NodePort
服务和 ClusterIP
服务上
你也可以使用Ingress来暴露自己的服务。 Ingress 不是一种服务类型,但它充当集群的入口点。 它可以将路由规则整合到一个资源中,因为它可以在同一IP地址下公开多个服务
[root@master nginx]# kubectl expose deployment nginx-deployment --port=80 --type=LoadBalancer
3.NodePort
如果你将 type
字段设置为 NodePort
,则 Kubernetes 控制平面将在 --service-node-port-range
标志指定的范围内分配端口(默认值:30000-32767)
例如:
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
type: NodePort
selector:
app: MyApp
ports:
# 默认情况下,为了方便起见,`targetPort` 被设置为与 `port` 字段相同的值。
- port: 80
targetPort: 80
# 可选字段
# 默认情况下,为了方便起见,Kubernetes 控制平面会从某个范围内分配一个端口号(默认:30000-32767)
nodePort: 30007
4.案例
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx-server
image: nginx:1.16
ports:
- containerPort: 80
apiVersion: v1
kind: Service
metadata:
name: nginx-services
labels:
app: nginx
spec:
type: NodePort
ports:
- port: 88
targetPort: 80
nodePort: 30010
selector:
app: nginx
5.了解
ExternalName
是 Kubernetes
服务(Service
)类型中的一种,它允许你将服务映射到一个外部的 DNS 名称,而不是选择器(selector
)所定义的一组 Pod;这意味着当你在集群内部通过服务名称访问时,实际上是在访问外部指定的资源。
使用场景
ExternalName
类型的服务非常适合以下几种情况:
当你需要将内部服务指向外部系统或第三方 API
当你希望服务名称和外部资源名称之间保持解耦,即使外部资源发生变化,只需要更新服务配置
对于微服务架构中的跨团队合作,不同团队管理自己的服务,通过 ExternalName
来互相调用对方的服务
配置方式
创建一个 ExternalName
类型的服务非常简单,只需在服务定义文件中设置 spec.type
为 ExternalName
并提供 spec.externalName
字段来指明你要映射的外部域名
apiVersion: v1
kind: Service
metadata:
name: external-service
namespace: default
spec:
type: ExternalName
externalName: example.com
案例
假设你正在管理一个电子商务平台,该平台由多个微服务组成,并且有一个专门处理支付的外部服务,这个支付服务是由第三方提供商托管的,其域名是 payments.externalprovider.com
背景
你的电商平台需要调用支付网关来完成交易过程。支付网关是一个由外部供应商提供的服务,不在你的 Kubernetes
集群内运行,但是你的应用程序代码需要能够像调用内部服务一样方便地访问它
使用 ExternalName
服务
为了简化与外部支付服务的交互,你可以创建一个名为 payment-gateway 的 ExternalName 类型的服务,这样所有的内部服务就可以通过 payment-gateway.default.svc.cluster.local(假设在默认命名空间中)来访问外部的支付服务,而不需要直接硬编码外部域名
apiVersion: v1
kind: Service
metadata:
name: payment-gateway
namespace: default
spec:
type: ExternalName
externalName: payments.externalprovider.com
应用程序代码调整
在你的应用程序代码中,你只需要配置服务名称为 payment-gateway 或者根据集群内的 DNS 解析规则使用完整的 FQDN (Fully Qualified Domain Name) payment-gateway.default.svc.cluster.local 来发起请求。比如,在 Java Spring Boot 应用中,你可以设置 REST 客户端的基础 URL:
@Bean
public RestTemplate restTemplate(RestTemplateBuilder builder) {
// 注意这里使用的是服务名称,而不是直接使用外部域名
return builder.rootUri("http://payment-gateway").build();
}
总结
通过这种方式,ExternalName
服务帮助你在Kubernetes
环境中优雅地整合了外部依赖,同时保持了良好的抽象层次和灵活性