servcie

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是默认域名: 
+
+    <service-name>.<namespace>.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
+

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端口

k8s知识笔记/三、serveice/4、loadbalancer类型.conf

@@ -0,0 +1,7 @@
+一、loadBalancer类型的Service
+
+    LoadBalancer是Kubernetes中Service的另一种类型, 通常用于将集群内的服务暴露给集群外部的客户端。
+
+    当创建一个LoadBalancer类型的Service时, Kubernetes会向[云提供商]请求一个外部负载均衡器, 并将该负载均衡器与Service关联起来。
+
+    这样, 集群外部的客户端可以通过访问负载均衡器的IP地址来与Service通信, 而不需要知道Service背后的Pod的具体IP地址。

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 <pod-name> -- nslookup my-external-service
+
+# 通过curl访问
+kubectl exec -it <pod-name> -- 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地址。

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 

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关联起来。

k8s知识笔记/三、serveice/8、publishNotReadyAddresses.conf

@@ -0,0 +1,9 @@
+一、创建为就绪pod的serveice
+
+
+
+二、命令行示例
+使用打补丁的命令修改: 
+# kubectl patch service myapp -p '{"spec":{"publishNotReadyAddresses": true}}
+
+三、示例配置文件