diff --git a/k8s知识笔记/三、serveice/1、service的类型 b/k8s知识笔记/三、serveice/1、service类型.conf similarity index 100% rename from k8s知识笔记/三、serveice/1、service的类型 rename to k8s知识笔记/三、serveice/1、service类型.conf diff --git a/k8s知识笔记/三、serveice/2、clusterip类型.conf b/k8s知识笔记/三、serveice/2、clusterip类型.conf new file mode 100644 index 0000000..ee19194 --- /dev/null +++ b/k8s知识笔记/三、serveice/2、clusterip类型.conf @@ -0,0 +1,55 @@ +一、集群内部通信 +1.1、ClusterIP类型的Service + + ClusterIP是Kubernetes中Service的默认类型。 + 它为Service分配一个虚拟IP地址, 这个IP地址只能在集群内部访问。 + ClusterIP类型的Service通常用于集群内部的服务发现和负载均衡。 + + 例如, 假设有一个名为my-service的Service, 它的ClusterIP地址 是10.96.0.1。集群内的Pod可以通过访问这个IP地址来与my-service通信, 而不需要知道my-service背后的Pod的具体IP地址。 + + +1.2、svc选中pod的逻辑 + pod 是处于就绪状态 + pod 的标签和 svc 的 selector 匹配(是serviced的标签子集) + pod 与 svc 在同一命名空间下 + + +1.4 svc在集群内会被解析成一个集群内域名, cluster.local是默认域名: + + ..svc.cluster.local + + 例如, 如果有一个名为my-service的Service, 它位于default命名空间下, 那么它的集群内域名就是my-service.default.svc.cluster.local + 集群内的Pod可以通过这个域名来访问my-service + + +1.5、internalTrafficPolicy + ClusterIP类型的Service有一个internalTrafficPolicy字段, 用于控制集群内部流量的路由策略。 + 该字段有两个可选值: Local和Cluster。 + + Local: 只将流量路由到与请求源节点相同节点上的Pod。这种策略可以减少跨节点的网络延迟, 但可能导致某些节点上的Pod过载, 而其他节点上的Pod闲置。 + Cluster: 将流量路由到集群中所有匹配的Pod, 无论它们位于哪个节点上。这种策略可以实现更均匀的负载分布, 但可能增加跨节点的网络延迟。 + +1.6、示例配置文件 + +apiVersion: v1 +kind: Service +metadata: + name: my-service + namespace: default +spec: + type: ClusterIP + clusterIP: 10.96.0.1 + ports: + - port: 80 # Service暴露的端口 + targetPort: 8080 # 后端Pod监听的端口 + selector: + app: my-app # 选择标签为app=my-app的Pod作为后端 + + +二、命令行示例 +# 基于文件创建Service +kubectl apply -f my-service.yaml + +# 试运行并生成yaml文件 +kubectl create svc clusterip myapp --tcp=80:80 --dry-run -o yaml > myapp-clusterip.yaml + diff --git a/k8s知识笔记/三、serveice/3、NodePort类型.conf b/k8s知识笔记/三、serveice/3、NodePort类型.conf new file mode 100644 index 0000000..d314029 --- /dev/null +++ b/k8s知识笔记/三、serveice/3、NodePort类型.conf @@ -0,0 +1,43 @@ +一、NodePort类型的Service + + NodePort是Kubernetes中Service的另一种类型。 + 它为Service分配一个静态端口, 这个端口在每个节点上都是开放的, 可以通过节点的IP地址和这个端口来访问Service。 + NodePort类型的Service通常用于将集群内的服务暴露给集群外部的客户端。 + + 例如, 假设有一个名为my-nodeport-service的Service, 它的NodePort端口是30007。 + 集群外部的客户端可以通过访问任意一个节点的IP地址和端口30007来与my-nodeport-service通信, 而不需要知道my-nodeport-service背后的Pod的具体IP地址。 + + 集群外 → NodeIP:NodePort → ClusterIP → Pod + +1.1、NodePort的端口范围 + NodePort的端口范围是30000到32767, 这是Kubernetes默认 + 可以通过修改kube-apiserver的--service-node-port-range参数来更改这个范围。 + + +1.2、NodePort的工作原理 + 当创建一个NodePort类型的Service时, Kubernetes会在每个节点上开放一个指定的端口。 + 当集群外部的客户端发送请求到这个端口时, 请求会被转发到Service的ClusterIP, 然后再由ClusterIP将请求路由到后端的Pod。 + 这种转发和路由通常是通过kube-proxy来实现的, kube-proxy会在每个节点上运行, 负责监听NodePort端口并将请求转发到相应的ClusterIP。 + +1.3、externalTrafficPolicy + NodePort类型的Service有一个externalTrafficPolicy字段, 用于控制外部流量的路由策略。 + 该字段有两个可选值: Local和Cluster。 + + Local: 只将流量路由到与请求源节点相同节点上的Pod。这种策略可以减少跨节点的网络延迟, 但可能导致某些节点上的Pod过载, 而其他节点上的Pod闲置。 + Cluster: 将流量路由到集群中所有匹配的Pod, 无论它们位于哪个节点上。这种策略可以实现更均匀的负载分布, 但可能增加跨节点的网络延迟。 + +1.4、示例配置文件 + +apiVersion: v1 +kind: Service +metadata: + name: my-nodeport-service + namespace: default +spec: + type: NodePort + selector: + app: my-app + ports: + - port: 80 # Service暴露的端口 + targetPort: 8080 # Pod监听的端口 + nodePort: 30007 # NodePort端口 \ No newline at end of file diff --git a/k8s知识笔记/三、serveice/4、loadbalancer类型.conf b/k8s知识笔记/三、serveice/4、loadbalancer类型.conf new file mode 100644 index 0000000..3a4b013 --- /dev/null +++ b/k8s知识笔记/三、serveice/4、loadbalancer类型.conf @@ -0,0 +1,7 @@ +一、loadBalancer类型的Service + + LoadBalancer是Kubernetes中Service的另一种类型, 通常用于将集群内的服务暴露给集群外部的客户端。 + + 当创建一个LoadBalancer类型的Service时, Kubernetes会向[云提供商]请求一个外部负载均衡器, 并将该负载均衡器与Service关联起来。 + + 这样, 集群外部的客户端可以通过访问负载均衡器的IP地址来与Service通信, 而不需要知道Service背后的Pod的具体IP地址。 \ No newline at end of file diff --git a/k8s知识笔记/三、serveice/5、ExternalName.conf b/k8s知识笔记/三、serveice/5、ExternalName.conf new file mode 100644 index 0000000..ad3b7cf --- /dev/null +++ b/k8s知识笔记/三、serveice/5、ExternalName.conf @@ -0,0 +1,39 @@ +一、ExternalName类型的Service + ExternalName是Kubernetes中Service的另一种类型, 用于将Service映射到集群外部的DNS名称。 + + 当创建一个ExternalName类型的Service时, 你需要指定一个externalName字段, 该字段包含一个有效的DNS名称。 + 当集群内的Pod访问这个Service时, Kubernetes会将请求重定向到指定的DNS名称, 而不是将请求路由到集群内的Pod。 + + 例如, 假设有一个名为my-external-service的Service, 它的externalName字段设置为example.com。 + 集群内的Pod可以通过访问my-external-service来与example.com通信, 而不需要知道example.com背后的具体IP地址。 + + + ExternalName类型的Service通常用于以下场景: + 1. 访问集群外部的服务: 例如, 你可以使用ExternalName类型的Service来访问外部的数据库服务, API服务等。 + 2. 服务迁移: 当你需要将服务从集群内迁移到集群外部时, 可以使用ExternalName类型的Service来实现无缝迁移。 + 3. 简化DNS管理: 使用ExternalName类型的Service可以简化DNS管理, 因为你只需要在Service中指定一个DNS名称, 而不需要在每个Pod中配置具体的IP地址。 + 需要注意的是, ExternalName类型的Service不支持端口映射, 因为它只是将请求重定向到一个DNS名称, 而不是将请求路由到集群内的Pod。 + 因此, 当使用ExternalName类型的Service时, 你需要确保外部服务已经正确配置了端口和协议。 + +二、命令行示例 +kubectl create service externalname my-external-service --external-name=example.com + +三、示例配置文件 +apiVersion: v1 +kind: Service +metadata: + name: my-external-service + namespace: default +spec: + type: ExternalName + externalName: example.com # 指定外部的域名 + +# 通过DNS解析查看 +kubectl exec -it -- nslookup my-external-service + +# 通过curl访问 +kubectl exec -it -- curl http://my-external-service + +当集群内的Pod访问这个Service时, Kubernetes会将请求重定向到指定的DNS名称, 而不是将请求路由到集群内的Pod。 +例如, 假设有一个名为my-external-service的Service, 它的externalName字段设置为example.com。 +集群内的Pod可以通过访问[my-external-service.default.svc.cluster.local]来与[example.com]通信, 而不需要知道[example.com]背后的具体IP地址。 \ No newline at end of file diff --git a/k8s知识笔记/三、serveice/6、IPVS 持久化连接.conf b/k8s知识笔记/三、serveice/6、IPVS 持久化连接.conf new file mode 100644 index 0000000..e75bd48 --- /dev/null +++ b/k8s知识笔记/三、serveice/6、IPVS 持久化连接.conf @@ -0,0 +1,13 @@ +一、会话保持 + + IPVS支持会话保持功能, 可以通过以下方式实现: + 1. 使用--persistent参数, 该参数指定会话保持的时间, 单位为秒. 例如, --persistent=300表示会话保持300秒. + 2. 使用--hash参数, 该参数指定用于会话保持的哈希算法. 常用的哈希算法包括: + - sourceip: 基于源IP地址进行哈希计算, 适用于客户端IP地址不变的场景. + - sourceipport: 基于源IP地址和源端口进行哈希计算, 适用于客户端IP地址可能变化但端口不变的场景. + - destinationip: 基于目标IP地址进行哈希计算, 适用于服务端IP地址不变的场景. + - destinationipport: 基于目标IP地址和目标端口进行哈希计算, 适用于服务端IP地址可能变化但端口不变的场景. + + +# 资源清单内开启基于客户端的会话保持：默认3个小时超时（3个小时内有连接会重置3小时超时） +service.spec.sessionAffinity:ClientIP \ No newline at end of file diff --git a/k8s知识笔记/三、serveice/7、Endpoint.conf b/k8s知识笔记/三、serveice/7、Endpoint.conf new file mode 100644 index 0000000..05a634a --- /dev/null +++ b/k8s知识笔记/三、serveice/7、Endpoint.conf @@ -0,0 +1,27 @@ +一、Endpoint 与 Service 和 Pod 的关系 + + Kubernetes中的Service, 它定义了一组Pods的逻辑集合和一个用于访问它们的策略。 + 一个Service的目标Pod集合通常是由Label Selector来决定的。 + + Endpoints是一组实际服务的端点集合。 + 一个Endpoint是一个可被访问的服务端点,即一个状态为running的pod的可访问端点。 + 一般Pod都不是一个独立存在,所以一组Pod的端点合在一起称为EndPoints。 + 只有被Service Selector匹配送选中并且状态为Running的才会被加入到和Service同名的Endpoints中。 + +创建service时, 会自动创建一个和service同名的endpoints对象, 该对象中包含了所有匹配service selector的pod的IP地址和端口信息。 + + 例如, 假设有一个名为my-service的Service, 它的selector是app=my-app。 + 如果有两个Pod, 分别是pod-1和pod-2, 它们都有标签app=my-app, 并且它们都在运行状态。 + 那么, Kubernetes会自动创建一个名为my-service的Endpoints对象, 其中包含pod-1和pod-2的IP地址和端口信息。 + + Service通过Endpoints对象来实现负载均衡和服务发现。 + 当客户端请求Service时, Kubernetes会从Endpoints对象中选择一个Pod的IP地址和端口, 并将请求转发给该Pod。 + 这样, 客户端就可以通过Service来访问一组Pod, 而不需要知道它们的具体IP地址。 + +Endpoint的类型 + Endpoint对象中的每个端点都包含了Pod的IP地址和端口信息。 + 这些端点可以是IPv4地址, IPv6地址, 或者是主机名。 + 端点还可以包含一些元数据, 例如Pod的名称, 命名空间, 和标签等。 + + 自动关联: 当创建一个Service时, Kubernetes会自动创建一个与该Service同名的Endpoints对象。 + 手动创建: 也可以手动创建Endpoints对象, 并将其与Service关联起来。 \ No newline at end of file diff --git a/k8s知识笔记/三、serveice/8、publishNotReadyAddresses.conf b/k8s知识笔记/三、serveice/8、publishNotReadyAddresses.conf new file mode 100644 index 0000000..f90a85b --- /dev/null +++ b/k8s知识笔记/三、serveice/8、publishNotReadyAddresses.conf @@ -0,0 +1,9 @@ +一、创建为就绪pod的serveice + + + +二、命令行示例 +使用打补丁的命令修改: +# kubectl patch service myapp -p '{"spec":{"publishNotReadyAddresses": true}} + +三、示例配置文件