kubernetes service 服务?kubernetes提供了多种类型的service

kubernetes service 服务1 service作用
使用kubernetes集群运行工作负载时,由于Pod经常处于用后即焚状态,Pod经常被重新生成,因此Pod对应的IP地址也会经常

1 service作用

使用Kubernetes 集群运行工作负载时,Pod 经常会被烧毁并重新生成,因此Pod 对应的IP 地址也会频繁变化,导致Pod 提供的服务将无法直接访问。 Kubernetes使用Service来解决这个问题:无论Pod如何变化,只要Label存在,它就使用Service来代理Pod前面的Pod,Service连接到Pod并添加Pod。 Pod 的IP 地址。利用Service对应的端点列表(Endpoint)实现Pod IP Tracking,达到通过Service访问Pod的目的。

通过您的服务为pod 客户端提供访问方法。这意味着客户端可以访问Pod的入口,通过标签等方式动态感知Pod IP地址的变化,以防止Pod丢失,为访问Pod定义访问策略,将其与标签选择器关联起来,并执行以下操作:那。通过服务实现pod的负载均衡(TCP/UDP 4层)底层由kube-proxy通过userspace、iptables、ipvs三种代理模式实现。

2 Kube-proxy三种代理模式

2.1 userspace 模式

用户空间模式是kube-proxy最早的实现。主要工作原理是:

(1) kube-proxy 监控Kubernetes API 服务器服务和端点变化。

(2)当创建新的服务时,kube-proxy会在节点上打开一个端口,并将该端口映射到该服务对应的后端pod上。

(3) 所有访问该端口的请求都会被kube-proxy捕获并转发到后端Pod。 kube-proxy 使用用户空间程序来执行这些传输操作。

这种模式的优点是易于实现,缺点是每个数据包都必须在用户空间进行处理,增加了额外的开销和延迟,从而降低了性能。

2.2 iptables 模式

iptables 模式是kube-proxy 的改进版本,与userspace 模式相比,性能有显着提升。它的工作原理如下:

(1)kube-proxy还监控Kubernetes API服务器服务和端点的变化。

不同之处在于kube-proxy 使用iptables 来配置网络规则。这些规则直接在内核空间而不是用户空间处理。

(2) 当创建新服务时,kube-proxy 会生成相应的iptables 规则来定义从服务IP 和端口到后端pod 的NAT 转发规则。

(3)数据包直接转发到内核空间对应的后端Pod,减少上下文切换,提高转发性能。

iptables 模式的好处是提高了性能,但在处理大量规则时,管理和更新规则可能会很复杂。

2.3 ipvs 模式

ipvs 模式是kube-proxy 的现代实现,使用Linux 内核的IP 虚拟服务器(IPVS) 技术。它的工作原理如下:

(1)kube-proxy监控Kubernetes API服务器服务和端点变化

(2)kube-proxy使用IPVS创建和维护负载均衡规则。 IPVS是内核中专门用于负载均衡的模块,支持多种调度算法。

(3) 当创建新服务时,kube-proxy 使用IPVS 创建相应的负载均衡规则,定义服务IP 和端口到后端pod 的转发规则。

(4)数据包通过IPVS直接在内核空间传输。这提高了性能并支持更多的负载平衡算法(轮询、最小连接、最小延迟等)。

(5)ipvs模式的优点是性能最好,支持更多的负载均衡算法和更复杂的网络规则,但需要内核支持IPVS模块。

2.4 iptables与ipvs对比

iptables

优点:灵活、功能强大(可以对不同阶段的数据包进行操作) 缺点:表中的规则太多,会减慢响应速度。也就是说,规则以线性延迟进行匹配和更新。

ipvs

优点:传输效率高。丰富的调度算法:rr、wrr、lc、wlc、ip hash.缺点:内核支持不完整,旧版本内核无法使用,必须升级到4.0或5.0以上版本。

3 service类型

3.1 类型

集群IP

默认情况下,会分配一个在集群内可访问的虚拟IP。

节点端口

为每个节点分配一个端口作为外部访问入口。 nodePort 端口范围为30000-32767。

负载均衡器

与某些云提供商合作,例如Google Cloud、AWS 和OpenStack

外部名称

这意味着将集群外部的服务引入到集群中,也就是说能够实现集群内部的Pod与集群外部的服务之间的通信。

3.2 service参数

port:用于访问服务的端口

targetPort:pod内的容器端口

nodePort:允许外部网络用户通过节点(30000-32767)访问k8s集群中的服务。

4 service创建

4.1 ClusterIP类型

ClusterIP根据是否生成分为普通服务和无句柄服务。

普通服务:

为您的Kubernetes Service 分配一个集群内可访问的固定虚拟IP(ClusterIP),以便集群内可以访问。

无头服务:

该服务不分配ClusterIP 或通过kube-proxy 执行反向代理或负载平衡。相反,DNS 提供稳定的网络身份用于访问,并将无头服务后端直接解析到pod IP 列表。

4.1.1 普通ClusterIP service创建

通过命令行从部署创建服务

如果您有名为my-deployment 的部署,则可以使用以下命令为其创建服务:

kubectl 公共部署my-deployment –port=80 –type=ClusterIP

然后使用get和description显示svc

通过IP地址访问:

服务可以达到负载均衡的效果

创建具有三个副本的部署

[root@easzlab ~]# 获取kubectl pod

姓名准备状态简历年龄

nginx-deployment-55f598f8d-gcszt 1/1 运行0 22 米

nginx-deployment-55f598f8d-kj5nz 1/1 运行0 22 米

nginx-deployment-55f598f8d-p2dsr 1/1 运行0 22 米

以其中一个pod 为例

[root@easzlab ~]# kubectl exec -it nginx-deployment-55f598f8d-p2dsr — /bin/bash

root@nginx-deployment-55f598f8d-p2dsr:/# cd /usr/share/nginx/html

root@nginx-deployment-55f598f8d-p2dsr:/usr/share/nginx/html# echo \’web1\’index.html

root@nginx-deployment-55f598f8d-p2dsr:/usr/share/nginx/html# 退出

设置完三个pod 后,如果使用curl 访问它们,您将看到每次访问都会进入不同的pod,从而提供负载平衡。

从资源列表创建服务

1.创建部署YAML文件

apiVersion: 应用程序/v1

kind:的部署

元数据:

name: my-nginx-部署

规格:

复制品: 2

选择器:

匹配标签:

app: my-nginx

模板:

元数据:

标签:

app: my-nginx

规格:

集装箱:

-名称: nginx

图片: nginx:1.19.0

端口:

-集装箱港口: 80

2. 为服务创建YAML文件

api版本: v1

kind:服务

元数据:

name: my-nginx-service

规格:

选择器:

app: my-nginx

端口:

– 协议: TCP

端口: 80

目标端口: 80

type: 集群IP

检查资源是否创建成功

获取kubectl 部署

获取kubectl服务

查看资源详情

kubectl 描述部署my-nginx-deployment

描述kubectl 服务my-nginx-service

4.1.2 Headless Service

典型的ClusterIP 服务是服务名称解析为集群IP 的服务,集群IP 对应后续的pod IP。无头服务意味着服务名称直接解析为后续的pod IP。

特征和行为

DNS 记录:headless 服务为Kubernetes DNS 中的每个匹配Pod 创建一条A 记录(地址记录),该记录直接指向Pod 的IP 地址。无负载平衡:如果没有ClusterIP,无头服务不提供内置负载平衡。与StatefulSet 配合使用:Headless 服务非常适合与StatefulSet 配合使用,因为StatefulSet 为每个Pod 提供稳定的网络身份和持久存储。

为您的服务创建YAML 文件

api版本: v1

kind:服务

元数据:

name: 无头服务

规格:

clusterIP: None # 设置为None 创建无头服务

选择器:

app: my-app # 设置部署对应的标签

端口:

– 协议: TCP

端口: 80

目标端口: 80

DNS解析

在集群中,您可以使用nslookup 或dig 命令来解析无头服务的DNS 记录。

kubectl run -it –rm –image=tutum/dnsutils dnsutils –nslookup headless-service.default.svc.cluster.local。

这将显示与您的服务选择器匹配的Pod IP 地址列表。

4.2 NodePort类型

NodePort服务通常用于以下场景:

您需要从集群外部访问服务,但不想使用外部负载均衡器。作为配置外部负载均衡器之前的临时解决方案。允许外部流量直接但通过特定节点端口进入集群。

创建NodePort 服务

api版本: v1

kind:服务

元数据:

name: nginx-nodeport

规格:

type: NodePort # 指定服务类型为NodePort

选择器:

app:nginx

端口:

– 协议: TCP

port: 80 # 服务端口,集群内部访问的端口

targetPort: 80 # 转发到Pod 的端口

nodePort: 30080 # 节点上的静态端口,外部访问的端口

应用服务

kubectl apply -f nginx-nodeport.yaml

服务验证

获取kubectl服务

上门服务

NodePort服务创建成功后,您可以通过任意节点的IP地址和nodePort来访问该服务。

http://任意节点IP:30080

4.3 LoadBalancer类型

LoadBalancer 是一种Kubernetes 服务,为服务提供外部可访问的IP 地址。此IP 地址是通过云服务提供商的负载均衡器实现的,用于将流量分配到服务后面的多个Pod。

创建负载均衡器服务

api版本: v1

kind:服务

元数据:

name: nginx-lb-service

规格:

:型负载均衡器

选择器:

app:nginx

端口:

– 协议: TCP

端口: 80

目标端口: 80

应用服务

kubectl apply -f nginx-lb-service.yaml

检查服务状态

获取kubectl服务

访问负载均衡器服务

http://外部IP

4.4 ExternalName类型

ExternalName 是一种特殊类型的服务,不用于在集群内创建服务代理或负载均衡器,而是用于将服务名称映射到外部DNS 名称。该服务类型通常用于指集群外部的服务,例如指向外部数据库、API 服务或其他基础设施服务。

4.4.1 将公网域名引入

1. 为ExternalName Service创建YAML定义

创建名为externalname-service.yaml 的YAML 文件来定义ExternalName 类型的服务。

api版本: v1

kind:服务

元数据:

name: 外部服务

规格:

type: 外部名称

externalName: www.baidu.com # 外部DNS 名称

2. 应用服务定义

kubectl apply -f externalname-service.yaml

3.检查服务

获取kubectl服务

名称类型集群IP 外部IP 端口期限

外部服务外部名称无www.baidu.com 无15h

4. 接入服务

集群中的Pod可以通过服务名访问外部服务。例如,集群中的某个Pod需要访问www.baidu.com,您可以使用external-service.default.svc.cluster.local来解析DNS。

5.DNS解析

在集群中,您可以使用nslookup 或dig 命令来解析ExternalName 服务的DNS 记录。

kubectl run -it expod –image=busybox:1.28

#nslookup www.baidu.com

# nslookup externalservice.default.svc.cluster.local。

这将显示外部DNS 名称www.baidu.com。

4.5 sessionAffinity

sessionAffinity 是Service 资源上的一个属性,用于控制来自客户端的多个请求是否始终路由到同一个pod。此功能称为会话亲和性,对于需要维护用户会话状态的应用程序(例如Web 应用程序)非常有用。

api版本: v1

kind:服务

元数据:

name: 我的服务

规格:

选择器:

app: 我的应用程序

端口:

– 协议: TCP

端口: 80

目标端口: 9376

sessionAffinity: ClientIP # 启用基于客户端IP的会话亲和性

type: 集群IP

sessionAffinity: 客户端IP

设置为ClientIP 以启用基于客户端IP 地址的会话关联。这意味着只要pod 仍然健康且可用,来自同一客户端IP 地址的所有请求将始终路由到同一个pod。此功能对于需要维护用户会话状态(例如用户登录状态或购物车信息)的应用程序非常有用。会话关联持续时间由sessionAffinityConfig 的timeoutSeconds 属性控制。如果某个Pod 不可用,客户端请求可以在超时后路由到其他Pod。

sessionAffinity: 无

如果设置为None 或未设置sessionAffinity 属性,则不会启用会话关联性。客户端请求不限于特定的Pod,而是根据服务的负载平衡算法(通常是循环)在可用的Pod 之间分配。这种方法适用于无状态应用程序,其中每个请求都是独立的,并且不需要维护会话状态。

以上#kubernetes服务相关内容来源仅供参考。相关信息请参见官方公告。

原创文章,作者:CSDN,如若转载,请注明出处:https://www.sudun.com/ask/92731.html

Like (0)
CSDN的头像CSDN
Previous 2024年6月28日
Next 2024年6月28日

相关推荐

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注