NodePort+LoadBalancer+Ingress+MetalLB+HostNetwork+Istio Gateway

Kubernetes 处理外部流量的主要方案，按流量走向逐一详解：

根据实际需求（环境、协议、功能）选择合适的方案，通常生产环境推荐组合使用 Ingress + LoadBalancer 或 服务网格 。

流量走向：

客户端 → 任意节点IP:NodePort → kube-proxy（iptables/IPVS） → Pod

原理：
- 创建 NodePort 类型的 Service 时，Kubernetes 会在所有节点上开放一个固定端口（默认 30000-32767）。
- 流量到达任意节点的 IP 和 NodePort 后，由 kube-proxy 通过 iptables 或 IPVS 规则转发到后端 Pod。
适用场景：
- 本地开发或测试环境。
- 非云环境（如裸机集群）。
优缺点：
- ✅ 简单，无需云厂商支持。
- ❌ 需手动管理节点 IP 变化。
- ❌ 流量需经过额外跳转（节点 → Pod）。

流量走向：

客户端 → 云厂商负载均衡器 → NodePort → kube-proxy → Pod

原理：
- 创建 LoadBalancer 类型的 Service 时，云厂商（如 AWS ELB、GCP LB）自动分配一个外部负载均衡器。
- 负载均衡器将流量转发到各节点的 NodePort，后续流程与 NodePort 一致。
适用场景：
- 公有云环境（需云厂商支持）。
优缺点：
- ✅ 自动化管理外部 IP。
- ❌ 每个 Service 分配独立 LB，成本高。
- ❌ 流量路径较长（LB → NodePort → Pod）。

流量走向：

客户端 → Ingress 控制器（如 Nginx） → Service ClusterIP → Pod

原理：
- Ingress 资源：定义七层路由规则（如基于域名或路径）。
- Ingress 控制器 ：如 Nginx、Traefik，以 Deployment 形式运行，需通过 Service（如 LoadBalancer 或 NodePort）暴露。
- 外部流量先到达 Ingress 控制器，根据规则转发到对应的 Service ClusterIP，再经 kube-proxy 到 Pod。
适用场景：
- 需要 HTTP/HTTPS 路由、SSL 终止等七层功能。
- 单入口管理多服务。
优缺点：
- ✅ 集中管理路由和 TLS。
- ❌ 需额外部署和维护 Ingress 控制器。

流量走向：

客户端 → MetalLB 负载均衡器 → 直接路由到 Pod 所在节点 → Pod

原理：
- MetalLB ：在裸机环境中实现 LoadBalancer 类型，通过 ARP/BGP 协议分配 IP。
- 流量直接由外部 LB IP 发送到 Pod 所在节点（不经过 NodePort），利用 kube-proxy 转发到 Pod。
适用场景：
- 裸机或私有云环境。
- 需避免 NodePort 跳转的开销。
优缺点：
- ✅ 在非云环境提供 LB 功能。
- ❌ 需配置 BGP/ARP 和 IP 地址池。

流量走向：

客户端 → 指定节点 ExternalIP → Service → Pod

原理：
- 在 Service 的 spec.externalIPs 字段指定节点 IP，流量直接发送到该 IP 的 Service 端口。
- kube-proxy 监听该 IP 的端口并转发到 Pod。
适用场景：
- 需要固定 IP 且可控的环境。
- 节点有稳定的外部 IP。
优缺点：
- ✅ 直接绑定 IP，无中间跳转。
- ❌ 需手动管理 IP，扩展性差。

流量走向：

客户端 → 节点IP:Pod端口 → Pod

流量走向：

客户端 → 集群DNS解析 → 外部服务

流量走向：

客户端 → Istio Ingress Gateway → 虚拟服务（VirtualService） → Pod

原理：
- Gateway：定义入口监听器和 TLS 配置。
- VirtualService：路由规则指向集群内服务。
- 流量由 Envoy 代理处理，支持灰度发布、流量镜像等。
适用场景：
- 微服务架构下的复杂流量管理。
- 需要高级流量策略（如熔断、重试）。
优缺点：
- ✅ 功能强大，支持细粒度控制。
- ❌ 复杂度高，资源消耗大。

根据实际需求（环境、协议、功能）选择合适的方案，通常生产环境推荐组合使用 Ingress + LoadBalancer 或 服务网格。