1.什么是service服务

Service

Kubernetes（K8s）中的Service是一种抽象，用于定义一组Pod的访问方式和网络规则。它提供了一个稳定的网络终结点，使得应用程序能够通过Service名称来访问后端的Pod实例。

Service为一组具有相同功能的Pod提供了一个统一的入口，隐藏了Pod背后的具体细节。通过Service，应用程序可以使用DNS名称或Cluster IP来访问后端Pod，而不需要直接暴露Pod的IP地址。这样，当Pod的IP地址发生变化时，应用程序仍然可以通过Service来访问后端的Pod。

Service还支持负载均衡，可以将请求均匀地分发到后端的多个Pod实例，从而实现高可用和水平扩展。它可以根据不同的负载均衡策略（如轮询、IP哈希等）将请求路由到不同的Pod。

Kubernetes中有多种类型的Service，包括ClusterIP、NodePort和LoadBalancer。每种类型都提供了不同的访问方式和网络配置，以满足不同的应用需求。

总之，Kubernetes的Service是一种抽象层，用于定义和管理应用程序的网络访问方式，并提供负载均衡和稳定的网络终结点。它是构建在Pod之上的一种网络抽象，为应用程序提供了方便的访问和可扩展性。

Service分类

ClusterIP 是默认类型的Service，它将Service暴露在集群内部的虚拟IP上。其他Pod或Service可以通过该虚拟IP和指定的端口与Service进行通信。ClusterIP类型的Service仅在集群内部可访问，对外部网络是不可见的。
NodePort 对外访问应用使用，在ClusterIP基础上为Service在每台机器上绑定一个端口，就可以通过: ip+NodePort来访问该服务
LoadBalancer（付费方案）使在NodePort的基础上，借助公有云创建一个外部负载均衡器，并将请求转发到NodePort
可以实现集群外部访问服务的另外一种解决方案，不过并不是所有的k8s集群都会支持，大多是在公有云托管集群中会支持该类型
ExternalName（很少使用）把集群外部的服务引入到集群内部来，在集群内部直接使用。没有任何类型代理被创建，这只有 Kubernetes 1.7或更高版本的kube-dns才支持。

Service和pod的关系

service和pod之间是通过 selector.app进行关联的

yaml示例：

apiVersion: v1
kind: Service
metadata:creationTimestamp: nullname: svc
spec:ports:- port: 80  # service服务端口protocol: TCPtargetPort: 80 # pod端口，常规和容器内部端口一致selector: # 标签选择器，确定当前service代理控制哪些podapp: nginx-pod
status:loadBalancer: {}

2.多种port端口区分

关于K8S中端口的概念区分

port 是service端口，即k8s中服务之间的访问端口，clusterIP:port 是提供给集群内部客户访问service的入口
nodePort 容器所在node节点的端口，通过nodeport类型的service暴露给集群节点，外部可以访问的端口
targetPort 是pod的端口，从port和nodePort来的流量经过kube-proxy流入到后端pod的targetPort上，最后进入容器。
containerPort 是pod内部容器的端口，targetPort映射到containerPort。

总结：

4种端口作用不一样，port和nodePort都是service的端口
port暴露给集群内客户访问服务，nodePort暴露给集群外客户访问服务
这两个端口到来的数据都需要经过反向代理kube-proxy流入后端pod的targetPod，从而到达pod中的容器

yaml示例;

apiVersion: v1
kind: Pod
metadata:name: nginxnamespace: devlabels:app: nginx
spec:containers:- name: nginximage: nginx:1.20imagePullPolicy: IfNotPresentports:- containerPort: 80 #容器端口,不指定则为默认
---
apiVersion: apps/v1
kind: Service
metadata:name: nginx
spec:type: NodePort # 有配置NodePort，外部可访问k8s中的服务 ，ports:- name: nginxport: 80  # 服务service的访问端口protocol: TCPtargetPort: 80  # pod端口,映射到容器端口nodePort: 30015  # NodePort，通过nodeport类型的service暴露给集群外部访问selector:app: nginx

3.K8S服务Service的ClusterIP

在Kubernetes中使用ClusterIP类型的Service非常简单。你可以按照以下步骤进行操作：
1.创建一个Service的定义文件（YAML格式），指定Service的名称、选择器、端口等信息。以下是一个示例

apiVersion: v1
kind: Service
metadata:name: my-service
spec:selector:app: my-appports:- name: httpport: 80targetPort: 8080

2.使用kubectl命令创建Service：

kubectl apply -f service-definition.yaml

3.等待Service创建成功。你可以使用以下命令来检查Service的状态：

kubectl get service my-service

通过Service的ClusterIP来访问相关的Pod。在集群内部，你可以使用Service的ClusterIP作为访问目标，而不需要直接暴露Pod的IP地址。
例如，在同一命名空间内的Pod中，你可以使用Service的ClusterIP来访问其他Pod，如下所示：

curl <cluster-ip>:<port>

请将<cluster-ip>和<port>替换为实际的Service的ClusterIP和端口。
注意：ClusterIP类型的Service默认只在集群内部可用，无法从集群外部访问。如果你需要从集群外部访问Service，可以考虑使用其他类型的Service，如NodePort或LoadBalancer。

4.K8S服务Service的NodePort和EndPoint

NodePort

NodePort是Kubernetes中一种类型的Service，它允许通过集群节点的特定端口将流量转发到Service中的Pod。

1.NodePort是Service的一种类型，它公开了一个固定的端口（NodePort），并将流量转发到Service中定义的端口（TargetPort）。

2.当创建一个NodePort类型的Service时，Kubernetes会为每个节点分配一个随机的端口号（30000-32767范围），并将此端口映射到Service的TargetPort。

3.NodePort类型的Service可以从集群外部访问。通过访问集群的任何节点的IP地址和NodePort端口，可以将流量转发到Service中的Pod。

4.创建NodePort类型的Service的示例定义文件如下：

apiVersion: v1
kind: Service
metadata:name: my-service
spec:type: NodePortselector:app: my-appports:- name: httpport: 80targetPort: 8080nodePort: 30080

上述示例中的nodePort字段指定了NodePort的端口号为30080。

5.使用kubectl命令创建NodePort类型的Service：

kubectl apply -f service-definition.yaml

6.从集群外部访问NodePort类型的Service时，可以使用任何节点的IP地址和指定的NodePort端口。例如：

curl <node-ip>:<node-port>

请注意，NodePort类型的Service通常用于测试或开发环境，并不适合在生产环境中直接使用。在生产环境中，建议使用LoadBalancer类型的Service或使用Ingress控制器来实现更灵活和可靠的流量管理。

Endpoint（ep）

1.是k8s中的一个资源对象，存储在etcd(存储数据库)中，记录service对应的所有pod的访问地址
2.里面有个Endpoints列表，就是当前service可以负载到的pod服务入口
3.service和pod之间的通信是通过endpoint实现的
4.查看endpoint列表 kubectl get ep svc-nodeport-nginx1 -n dev -o wide

kubernetes提供了两种负载均衡策略

Round Robin（轮询）：在轮询负载均衡策略下，每个请求按照顺序依次分发到后端的Pod。当有多个后端Pod时，每个请求会按照轮询的方式依次发送到不同的Pod上，确保每个Pod都能平均地处理请求。
Session Affinity（会话亲和）：在会话亲和负载均衡策略下，Kubernetes会根据客户端的源IP地址将一段时间内的请求路由到同一个后端Pod上。这样做的目的是为了保持与同一客户端的会话连续性，确保客户端在同一个Pod上处理的请求都属于同一个会话。

这两种负载均衡策略可以在Service的配置中进行指定。对于Round Robin策略，可以将Service的.spec.sessionAffinity字段设置为None（默认值），表示不启用会话亲和；对于Session Affinity策略，可以将.spec.sessionAffinity字段设置为ClientIP，表示根据客户端的源IP地址进行会话亲和。