Service
在Kubernetes中，Service是一个关键组件，主要用于提供对一组运行在集群中的Pod的统一访问。Service的设计使得Pod可以方便地被外部访问或在集群内部进行通信，同时提供负载均衡功能。
Service支持多种类型，确保了其灵活性和广泛的适用场景。例如，ClusterIP类型使Service仅在集群内部可访问，而NodePort和LoadBalancer类型则允许从集群外部访问Service。此外，ExternalName类型提供了一种将Service映射到集群外部服务的方法，通过返回一个DNS名称来实现。
ClusterIP
当Service的类型为ClusterIP时，Kubernetes集群会为Service为分配对应的集群IP，并同时产生一个域名。集群内部可以通过这集群IP或者域名都可以访问整个Service对应的Pod。它为您提供集群内的服务，集群内的其他应用程序可以访问该服务。没有外部访问。
Loadblance
LoadBalancer 服务是暴露服务到 internet 的标准方式。
如果你想要直接暴露服务，所有通往你指定的端口的流量都会被转发到对应的服务。它没有过滤条件，没有路由等。这意味着你几乎可以发送任何种类的流量到该服务，像 HTTP，TCP，UDP，Websocket，gRPC 或其它任意种类.
这个方式的最大缺点是每一个用 LoadBalancer 暴露的服务都会有它自己的 IP 地址，每个用到的 LoadBalancer 都需要付费，这将是非常昂贵的
创建Service
- name: 服务名称,如果没有特殊需要，建议和组件名称保持一致；
- type: 服务 类型，支持ClusterIP、NodePort、LoadBalancer；
- headless: 是否为headless类型，如果为true，则为headless类型，否则为ClusterIP类型；
- sessionAffinity: 会话保持类型，支持None和ClientIP；
- ports: 服务端口列表，支持TCP和UDP协议；
- annotations: 服务注解列表；
- selector: 服务选择器，用于选择目标Pod；
Loadbalance类型
externalTrafficPolicy
用于控制外部流量（来自集群外部请求）的路由行为
空（默认为Cluster类型）
Cluster（推荐）
- 行为：外部流量到达任意节点后，kube-proxy会把流量转发到集群中任意一个健康的pod
- 负载均衡效果：更好、更均匀，即使某个节点上的pod数量减少，流量也能公平分配到所有pod
- 适用场景：不需要知道客户端真实ip
Local
-
行为：外部流量到达某个节点后，只转发给该节点上运行的pod，如果该节点上没有该S ervice的健康pod，流量会被直接丢弃
-
负载均衡效果：可能不均匀
-
额外影响&适用场景：
-
云厂商的 Load Balancer 会通过 HealthCheck NodePort 只把流量发给有 Pod 的节点（节点无 Pod 时被标记为不健康）。
-
减少了跨节点网络流量，延迟更低、性能更好。
-
需要客户端真实源 IP（如日志分析、IP 限制、WAF、某些安全场景）。
-
对跨节点延迟敏感的应用。
-
结合 Pod Anti-Affinity（反亲和性）让每个节点 Pod 数量尽量均匀时使用。
-
无头模式
- 不分配 ClusterIP（虚拟 IP） 的 Service：它绕过了 Kubernetes 内置的负载均衡和代理机制，直接把流量指向后端的 Pod
- 没有负载均衡：客户端自己决定连接哪个 Pod（例如通过 DNS 返回的多个 IP 轮询、随机选择，或客户端代码实现特定逻辑）。
- DNS 返回 Pod IP：查询 my-service.my-namespace.svc.cluster.local 时，会得到所有 Pod 的 A 记录（IP）。
- 适合有状态或需要直接访问 Pod 的场景。
会话亲和性
针对于有状态服务，但一般适用于弱有状态服务，可帮助缓解状态不一致的问题。