为什么仅靠 Kubernetes 不够：API 网关与服务网格的必要性
Source: Dev.to
Canonical URL:
如果 Kubernetes 已经处理了网络，为什么我们还需要像 Istio 这样的 API 网关和服务网格？
Kubernetes（K8s）已经成为部署和扩展现代应用的首选平台。它抽象了基础设施的复杂性，自动化容器编排，并且开箱即提供弹性。
但我经常被问到一个问题：
👉 “如果 Kubernetes 已经处理了网络，为什么我们还需要像 Istio 这样的 API 网关和服务网格？”
简短的回答是：Kubernetes 提供了跑道，但你仍然需要空中交通管制和安全检查站来确保安全、受控的旅行。
北‑南 与 东‑西 流量
- North‑South Traffic – 在 外部客户端 与集群内部服务之间的通信（例如，用户通过 API 端点访问您的应用）。
- East‑West Traffic – 在 集群内部服务之间 的通信（例如，服务 A 调用服务 B 获取数据）。
Kubernetes Services 和 Ingress 为连接这些流量提供了基础——但“basic”才是关键词。
Kubernetes 网络策略：内置的护栏
在深入高级工具之前，让我们先认识一下 Kubernetes 已经提供的功能。
Kubernetes 附带了 网络策略，它们充当集群内部的基础防火墙。它们允许你定义诸如：
- 哪些 Pod 可以相互通信。
- 哪些外部 IP 或 CIDR 被允许访问。
- 连接是仅入口、仅出口，还是两者兼有。
这非常有价值。默认情况下，Kubernetes 中的 Pod 可以自由互相通信——网络策略为 护栏 提供了第一层。
但这里有个关键点：
- 网络策略是 基于 IP/标签 的。它们不理解应用协议、认证头或用户身份。
- 它们不提供 流量整形（重试、熔断、金丝雀部署等）。
- 它们 不提供可观测性或服务间加密。
👉 换句话说：网络策略把门锁上了，但它们不检查 谁在敲门 或 他们为何在此。
这正是 API 网关和服务网格发挥作用的地方。
进入 API 网关：您的机场登机口（南北流量）
API 网关充当机场入口的 守门人。
它：
- 对传入请求进行身份验证。
- 验证负载并强制执行速率限制。
- 将请求路由到相应的后端服务。
可以把它想象成机场的 值机柜台：只有持有有效机票的乘客才能继续，并且他们的行李在进入前会被检查。
如果没有网关，每个服务都必须自行实现外部安全和请求验证——这会导致重复和不一致的局面。
进入 Istio：您在终端内的机场安保（东西向流量）
对于东西向流量，Istio（服务网格）就像 机场内部安保系统。
它：
- 在服务之间提供 mTLS 加密。
- 强制执行 细粒度、了解应用的策略。
- 提供 流量控制（蓝绿部署、金丝雀发布、重试、熔断）。
- 提供 深度可观测性，包括指标和追踪。
可以把 Istio 想象成 安检闸门和航班信息系统：它们阻止未授权的移动，扫描交互，并确保航班（服务）按计划运行，且全程可见。
强化组合：网关 + Mesh 一起
单独来看，API 网关和 Istio 各自解决特定问题。将它们结合使用，就能为你的 Kubernetes 环境提供 机场级别的安全与控制。
- API 网关 保护并管理 南北向流量。
- Istio 保护并管理 东西向流量。
结合后，它们把 Kubernetes 从仅仅是一个“跑道”提升为 拥有检查站、安全防护和航班控制的完整机场。
如果没有它们，Kubernetes 只能提供飞机和跑道——但会让你面临航班误导、未授权乘客以及安全盲区的风险。
结束语
Kubernetes 功能强大，但它并非安全或流量管理的灵丹妙药。
- Network Policies 为您提供坚实的基础。
- API Gateways 为外部入口点添加控制。
- Service Meshes 如 Istio 带来深度可视化和集群内安全。
它们共同将 Kubernetes 从“仅仅是编排”转变为 弹性、安全、可投入生产的平台。
所以，下次有人问：
👉 “Why do we …”
(根据需要继续对话。)
当我们已经拥有 Kubernetes 时，还需要 API Gateway 和 Istio 吗？
因为 Kubernetes 为你提供了跑道——但你仍然需要机场级别的安全来确保航班安全。
文章最初发布于 dev.to.