这一篇文章主要是对service发现新的理解
为什么要使用service服务发现？
首先pod的IP，是动态的，当我们重启一个pod的时候，它会给它分配一个新的IP，但是如果微服务a想要去调用微服务b，他是需要知道微服务b所有健康pod的当前地址的，这使得服务发现变得很困难，服务发现机制又是微服务架构的核心需求
第二个就是负载均衡，当我们有多个pod的副本用于同一个应用的时候，我们希望流量能够均匀的分发到这些pod上，所以我们需要一个机制来抽象后边所有的pod，这个机制就是service发现。当你向service发送请求的时候kube-proxy组件它会通过IPVS或者iptables将请求负载均衡到后端健康的pod上
并且客户端它是需要一个稳定的，不变的地址来连接这个服务的，就是service它发挥作用的地方，在创建一个service对象的时候，k8s会为其分配一个虚拟的在集群中稳定的IP地址，这个然后service会被自动注册到集群的DNS服务中，那么客户端就可以直接通过一个稳定的DNS名称来访问服务
headless service、clusterIP、NodeIP、LoadBalancer、Ingress、GateWay API等六种类型service
headless service、clusterIP、NodeIP、LoadBalancer、Ingress
GateWay API
Gateway API 是 Kubernetes 新一代的流量管理接口。在ingress的yaml文件里，基础设施和业务逻辑同时定义，Gateway API的进步就是，让这个过程可以角色分离，让不同团队（基础设施、集群运维、应用开发等）都能够独立且安全地管理流量。
它主要有三个核心组件：
1.GatewayClass (网关类)：定义了集群中哪种负载均衡器可用，以及由哪个控制器（如 Nginx,
Istio 等）来管理，它是一个集群级别的、全局性的资源。
2.Gateway (网关)：是根据 GatewayClass 模板在集群中创建的一个实际流量入口点，它配置
了监听的端口（如 80, 443）、协议、TLS 证书，并决定允许哪些命名空间的应用（通过 Route）
附加到它上面。
3.Route (路由)：将来自 Gateway 的流量，根据匹配规则（如主机名、路径、请求头），转发
到具体的后端服务（Service），它是应用开发者定义服务如何暴露的地方。
这个模型清晰地划分了职责：GatewayClass(模板) → Gateway(实例) → HTTPRoute(规则)
1.集群管理员提供 GatewayClass (比如，我们支持 Nginx 网关)。
2.运维团队创建一个 Gateway (比如，在生产环境创建一个监听 443 端口的 Nginx 网关实例)。
3.应用开发者创建一个 HTTPRoute (比如，将 api.myapp.com/v1 的流量路由到我的 v1-
service)。
这种分离使得网络管理更加安全、灵活且易于扩展，是它相对于传统 Ingress 的最大优势