构建基于 Kong Ingress Controller 的云原生网关架构实践

作者： /

本文面向已在 Kubernetes 环境下实践微服务架构的中高级工程师。我们将深入探讨如何利用 Kong Ingress Controller，将一个标准的 Kubernetes Ingress 升级为功能完备、高性能、可扩展的 API 网关。我们不止于介绍其功能，而是穿透其控制平面与数据平面的实现原理，剖析其在操作系统和网络层面的性能根基，并给出从零到一、再到大规模集群联邦的架构演进路径与工程权衡。

现象与问题背景

在从单体架构向微服务迁移的过程中，Kubernetes 已成为容器编排的事实标准。然而，当数百个微服务部署在集群中时，如何管理这些服务的入口流量（南北向流量）成为一个棘手的挑战。Kubernetes 内置的 Ingress 资源提供了一个基础的七层路由规范，但其原生实现（如 NGINX Ingress Controller）的功能相当有限，难以满足现代企业对 API 管理的复杂需求。

我们面临的典型问题包括：

  • 统一的横切关注点： 每个服务都需要认证、授权、日志、监控、限流等功能。在每个微服务内部重复实现这些逻辑，不仅是巨大的开发浪费，也导致了策略不一致和难以维护的困境。
  • 复杂的路由逻辑： 业务需求往往超越了简单的基于 Host 和 Path 的路由。我们需要基于 Header、请求方法、权重、金丝雀发布等更复杂的策略进行流量分发。
  • 安全与合规： API 是企业数字资产的门户，必须有强大的安全防护能力，如 JWT 验证、OAuth2、IP 黑白名单、WAF 等，以保护后端服务免受攻击。
  • 开发者体验： API 的消费者（无论是内部开发者还是外部合作伙伴）需要清晰的文档、自助的 Key 申请流程以及稳定的服务质量承诺（SLA）。

这些问题本质上都指向同一个解决方案：在集群的流量入口处，需要一个比 Ingress 更强大的角色——API 网关。Kong，作为一个基于 Nginx 和 OpenResty 的高性能网关，结合其为 Kubernetes 量身打造的 Ingress Controller，提供了一套将声明式 API 与强大网关能力无缝集成的云原生解决方案。

关键原理拆解

要真正掌握 Kong Ingress Controller，我们必须回归到几个核心的计算机科学原理，理解其架构设计背后的理论支撑。这里，我将以大学教授的视角，为你剖析其内核。

原理一：控制平面与数据平面的分离（Control Plane vs. Data Plane）

这是现代网络与分布式系统设计的基石。将系统的决策逻辑（控制平面）与流量处理执行（数据平面）解耦，可以带来极大的灵活性和可扩展性。

  • 数据平面 (Data Plane): 由一组 Kong 代理实例组成，它们是真正处理用户请求的“工人”。这些实例是无状态的，其行为完全由配置驱动。它们的核心任务是：以极致的性能进行路由、执行插件逻辑（认证、限流等）、并将流量转发到上游服务。数据平面的核心诉求是低延迟、高吞吐和高可用。
  • 控制平面 (Control Plane): 在 Kong Ingress Controller (KIC) 的场景下，控制平面就是那个运行在 Kubernetes 集群中的 KIC Pod。它的唯一职责是监听 Kubernetes API Server 的资源变化（如 Ingresses, Services, KongPlugins, etc.），然后将这些声明式的 Kubernetes 对象翻译成 Kong 数据平面能够理解的配置。它负责“思考”，但不直接处理任何一笔业务流量。控制平面的核心诉求是最终一致性与正确性。

这种分离使得我们可以独立地扩展两个平面。当流量洪峰来临时，我们只需扩展数据平面（增加 Kong Pod 的数量）；当配置变更频繁时，我们只需保证控制平面的稳定与响应性。二者互不干扰，架构清晰。

原理二：事件驱动与非阻塞 I/O (Event-Driven, Non-blocking I/O)

Kong 的高性能基因继承自 Nginx。理解其性能的关键在于理解其网络 I/O 模型，这要追溯到著名的 C10K 问题。传统的 Web 服务器（如 Apache prefork 模式）采用“一个连接一个进程/线程”的模型，当并发连接数上万时，大量的进程/线程会消耗巨额的内存，并且操作系统在它们之间进行上下文切换（Context Switch）的开销会变得无法承受。

Nginx/Kong 则采用了基于事件循环（Event Loop）的异步非阻塞模型。在 Linux 环境下，它依赖于 `epoll` 这一系统调用。其工作方式可以概括为：

  1. 一个或多个 Worker 进程启动后，每个 Worker 都在一个独立的 CPU 核心上运行，形成一个事件循环。
  2. Worker 进程向内核注册它所关心的所有文件描述符（sockets）以及关心的事件（如“可读”、“可写”）。
  3. Worker 进程调用 `epoll_wait()` 将自己阻塞，让出 CPU，进入睡眠。
  4. 当任何一个 socket 上有事件发生时（例如，新的连接请求到达、客户端发送了数据），内核会被硬件中断唤醒，处理完网络协议栈的逻辑后，将就绪的事件通知给 Worker 进程。
  5. Worker 进程被唤醒，从 `epoll_wait()` 返回，并开始处理所有就绪的事件。处理过程是非阻塞的，意味着如果在读写某个 socket 时数据没有准备好，它不会等待，而是立刻去处理下一个就绪的 socket。

这个模型的好处是，极少数的 Worker 进程就可以处理海量的并发连接，因为进程几乎所有时间都在处理实际的业务逻辑，而不是在等待 I/O。CPU 和内存资源得到了最大化的利用。这就是为什么 Kong 能够以微秒级的延迟处理请求的底层秘密。

原理三：声明式 API 与调谐循环 (Declarative API & Reconciliation Loop)

Kubernetes 的核心设计哲学是声明式 API。用户不告诉系统“如何做”（how），而是告诉系统“想要什么”（what），即期望的最终状态（Desired State）。系统内部的各个控制器则负责不断地观察当前状态（Current State），并采取行动使当前状态趋向于期望状态。这个持续不断的过程被称为调谐循环（Reconciliation Loop）。

Kong Ingress Controller 正是这一模式的完美实践者。它是一个标准的 Kubernetes Controller：

  • 它通过 `informer` 机制 watch 着特定类型的资源（`Ingress`, `Service`, `Endpoint`, `KongPlugin` 等）。
  • 当这些资源被创建、更新或删除时，API Server 会通知 KIC。
  • KIC 将相关的资源对象放入一个工作队列中。
  • KIC 的主循环从队列中取出对象，基于所有相关的 K8s 资源，在内存中构建出一份完整的、期望的 Kong 配置。

    • – 将这份新配置与当前 Kong 数据平面的配置进行比较，计算出差异。

  • 通过 Kong Admin API，将差异部分推送给 Kong 数据平面，完成配置的更新。

这个循环确保了 Kubernetes 中的资源状态始终是驱动 Kong 行为的唯一事实来源 (Single Source of Truth)，完美融入了 GitOps 的工作流。

系统架构总览

一个典型的基于 Kong Ingress Controller 的部署架构可以用以下几个核心组件来描述：

  • 外部负载均衡器 (External Load Balancer): 这是集群的入口，通常是云厂商提供的 LB（如 AWS ELB, GCP Cloud Load Balancer）或自建的 MetalLB。它将外部流量（通常是 80/443 端口）路由到 Kubernetes 集群内部的 Kong Proxy 服务。
  • Kong 数据平面 (Data Plane): 以 `Deployment` 或 `DaemonSet` 的形式运行在 Kubernetes 中。它包含多个 Kong 实例的 Pod。这个 `Deployment` 对外暴露一个 `LoadBalancer` 或 `NodePort` 类型的 `Service`，以便接收来自外部 LB 的流量。
  • Kong 控制平面 (Control Plane): 这是一个单独的 `Deployment`，通常只有一个 replica（可以通过 leader-election 实现高可用）。这个 Pod 内部署了 Kong Ingress Controller。它拥有访问 Kubernetes API Server 的 RBAC 权限，以 watch 相关资源。
  • Kubernetes API Server: 作为整个系统的配置中心和事件总线。开发者或 CI/CD 系统通过 `kubectl` 或客户端库与 API Server 交互，创建或更新 `Ingress`、`KongPlugin` 等 CRD 资源。
  • （可选）配置数据库 (PostgreSQL): 在 DB-backed 模式下，Kong 的配置信息会持久化在一个外部数据库中。控制平面将配置写入数据库，数据平面实例则从数据库中拉取配置。这与将配置直接推送到数据平面的 DB-less 模式形成了鲜明对比。

整个工作流程是：开发者提交一个 YAML 文件到 Git -> CI/CD 流水线执行 `kubectl apply` -> Kubernetes API Server 持久化该资源对象 -> Kong Ingress Controller (控制平面) 监听到变化 -> KIC 将其翻译为 Kong 配置 -> KIC 通过 Admin API 更新 Kong 代理 (数据平面) -> 新的路由/策略生效。

核心模块设计与实现

理论讲完了，我们来点硬核的。作为工程师，代码和配置才是我们的语言。

部署模式选择：DB-less vs. DB-backed

这是一个关键的架构决策点。别听信任何“最佳实践”，选择只取决于你的场景和运维能力。

  • DB-less 模式: 这是云原生环境下更受欢迎的选择。配置由 KIC 在内存中生成，并通过 Admin API 的 `/config` 端点一次性推送给每个 Kong Pod。Kong Pod 将配置保存在内存中。
    • 优点： 运维简单，没有外部数据库依赖，天然契合 GitOps。整个网关层是“易失的”，可以随时销毁和重建。
    • 缺点： 每次配置变更，KIC 都需要重新生成完整配置并通知所有 Kong Pod 热加载。虽然 Kong 的热加载非常快，但在超大规模配置和高频变更下，可能会有短暂的性能抖动。此外，配置的体积受限于 etcd 的存储限制。
  • DB-backed 模式: Kong 的配置存储在 PostgreSQL 或 Cassandra 中。KIC 将变更写入数据库，Kong Pods 则通过轮询或数据库通知机制感知变更。
    • 优点： 配置可以非常巨大，不受 etcd 限制。配置变更是增量的，对数据平面的影响更小。允许通过 Kong Admin API 进行紧急的、命令式的配置修改。
    • 缺点： 引入了有状态的数据库组件，显著增加了运维复杂性（高可用、备份、恢复、升级）。违背了纯粹的声明式 GitOps 哲学。

我的建议： 除非你有成千上万条路由规则并且需要一个独立的管理平台去操作 Kong，否则永远从 DB-less 模式开始。它的简洁性带来的好处远超其限制。

通过 CRD 实现高级策略

Kong 的强大之处在于其丰富的插件生态，而 KIC 通过一系列 CRD (Custom Resource Definition) 将这些能力暴露给了 Kubernetes 用户。

场景一：为某个服务开启 JWT 认证和速率限制

假设我们有一个 `billing-service`，需要对其进行保护。

首先，定义插件配置。我们创建两个 `KongPlugin` 对象。


apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: billing-jwt
config:
  key_claim_name: iss
plugin: jwt
---
apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: billing-rate-limit
config:
  minute: 5
  policy: local
plugin: rate-limiting

然后，在我们的 Ingress 资源上，通过 annotation 将这些插件“附加”上去。


apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: billing-ingress
  annotations:
    konghq.com/plugins: billing-jwt, billing-rate-limit
spec:
  ingressClassName: kong
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /billing
        pathType: Prefix
        backend:
          service:
            name: billing-service
            port:
              number: 80

就这样，所有到 `/billing` 的请求，都必须携带合法的 JWT，并且每个客户端每分钟不能超过 5 次请求。没有一行业务代码需要改动。这就是网关的威力。

自定义插件开发：释放终极灵活性

当内置插件无法满足你刁钻的需求时（比如，需要对接一个私有的认证中心），你可以用 Lua 编写自己的插件。Kong 基于 OpenResty，其核心是 LuaJIT，这是一个性能极高的 Lua 运行时。自定义插件开发，是区分 Kong 高级玩家和普通用户的分水岭。

一个简单的插件，给响应添加一个自定义 Header：


-- my-header-plugin/handler.lua
local BasePlugin = require "kong.plugins.base_plugin"

local MyHeaderHandler = BasePlugin:extend()

MyHeaderHandler.PRIORITY = 1000
MyHeaderHandler.VERSION = "0.1.0"

function MyHeaderHandler:new()
  MyHeaderHandler.super.new(self, "my-header-plugin")
end

-- 在 'access' 阶段执行，这个阶段在请求被代理到上游服务之前
function MyHeaderHandler:access(conf)
  MyHeaderHandler.super.access(self)
  -- 可以在这里做认证、请求改写等
end

-- 在 'header_filter' 阶段执行，这个阶段在收到上游服务的响应头之后
function MyHeaderHandler:header_filter(conf)
  MyHeaderHandler.super.header_filter(self)
  ngx.header["X-Served-By-My-Plugin"] = conf.header_value
end

return MyHeaderHandler

你还需要一个 `schema.lua` 文件来定义插件的配置项。


-- my-header-plugin/schema.lua
return {
  name = "my-header-plugin",
  fields = {
    { config = {
        type = "record",
        fields = {
          { header_value = { type = "string", required = true, default = "Hello Kong" }, },
        },
      },
    },
  },
}

将这个插件打包进你的自定义 Kong 镜像，并在 `kong.conf` 中启用它。之后，你就可以像使用官方插件一样，通过 `KongPlugin` CRD 来使用它了。这为你提供了无限的扩展能力。

性能优化与高可用设计

部署只是开始，保证网关在生产环境中稳定、高效地运行才是真正的挑战。

数据平面性能调优

  • 合理设置 Worker 数量： Kong (Nginx) 的 `worker_processes` 配置项应设置为 `auto`，它会自动设置为等于机器的 CPU 核心数。因为 Nginx Worker 是 CPU 密集型的，更多的 Worker 并不会带来性能提升，反而会增加上下文切换的开销。
  • CPU 亲和性 (CPU Affinity): 将每个 Worker 进程绑定到一个独立的 CPU 核心上（通过 `worker_cpu_affinity`），可以有效减少 CPU 核心间的缓存失效（Cache Miss），提升 L1/L2 Cache 的命中率，对延迟敏感的场景有奇效。
  • 启用 HTTP/2 和 Keep-Alive: 开启 `http2` 可以通过多路复用减少连接数，降低延迟。为客户端和上游服务开启 `keepalive` 连接，可以避免频繁的 TCP 握手开销。这些都是基础但极其有效的优化。
  • 监控与分析： 深度依赖 Kong 的 Prometheus exporter。监控关键指标，如请求延迟（特别是 `kong_latency_ms`），HTTP 状态码（关注 4xx, 5xx），上游服务健康状况等。利用火焰图等工具分析 Lua 代码的热点，特别是自定义插件的性能。

高可用架构设计

  • 数据平面高可用： Kong 数据平面本身是无状态的，高可用非常简单。在 `Deployment` 中设置多个 `replicas`，并配置 `PodAntiAffinity` 规则，确保 Pod 分散在不同的物理节点上。结合 HPA (Horizontal Pod Autoscaler)，根据 CPU 或内存使用率自动伸缩 Pod 数量。
  • 控制平面高可用： 虽然控制平面不直接影响线上流量，但它的宕机会导致配置无法更新。从 KIC 2.0 开始，官方支持多副本部署，通过 Kubernetes 的 Leader Election 机制保证同一时间只有一个 KIC 实例在工作，其他实例处于热备状态。
  • DB-backed 模式下的数据库高可用： 如果你选择了 DB-backed 模式，那么数据库就成了关键的单点故障。你必须为 PostgreSQL 搭建一套主从复制、自动故障切换的高可用方案。这部分的复杂度远高于网关本身。再次强调，谨慎选择 DB-backed 模式。
  • 故障隔离与容灾： 考虑在多个可用区（Availability Zone）部署 Kong 数据平面节点，并利用 Kubernetes 的拓扑感知路由（Topology-Aware Routing）将流量优先路由到同一可用区的后端服务，降低跨区访问的延迟和成本。对于关键业务，考虑在不同地域（Region）部署独立的网关集群，实现多活或灾备。

架构演进与落地路径

一个复杂系统的引入不应该是一蹴而就的，而是分阶段演进的。以下是一个可行的落地策略。

第一阶段：作为 Ingress Controller 的增强替代品

初期目标是替换掉集群中功能孱弱的默认 Ingress Controller。采用 DB-less 模式，部署 Kong Ingress Controller。首先将非核心业务的流量切入，主要使用其基础的路由功能和一些简单的插件，如 Metrics (Prometheus), Logging, Rate Limiting。这个阶段的目标是让团队熟悉 Kong 的声明式配置方式，并将其集成到现有的 CI/CD 流程中。验证其稳定性与性能。

第二阶段：构建统一的 API 网关平台

随着越来越多的服务接入，需要将 Kong 定位为全公司的统一 API 网关。在这个阶段，可能会遇到 CRD 管理变得复杂的问题。可以考虑构建一个简单的内部开发者门户（Portal），该门户提供 UI 界面，让服务开发者可以自助地注册 API、申请凭证、配置插件。这个门户的后端会将用户的操作翻译成 `KongPlugin`, `KongConsumer` 等 CRD，并应用到 Kubernetes 集群中。此时，依然可以坚持使用 DB-less 模式，将 Gitops 作为唯一的配置来源，门户的修改最终也是提交 PR 到配置仓库。

第三阶段：走向多集群与联邦网关

对于拥有多个 Kubernetes 集群的大型企业，管理多个独立的 Kong 网关会成为新的痛点。此时需要考虑网关的联邦化。可以探索的方案包括：

  • 中心化控制平面： 部署一个中心的、高可用的 Kong 控制平面（可能需要切换到 DB-backed 模式），由它来管理分布在各个集群中的数据平面。这需要解决跨集群的网络通信和服务发现问题。
  • 利用服务网格（Service Mesh）： 将 Kong 与 Istio 或 Kong 自己推出的 Kong Mesh 结合。Kong 作为东西向流量和南北向流量的统一网关（Gateway），而服务网格负责处理集群间的通信细节。这是一种更云原生的联邦方案。

架构的演进没有终点，但每一步都应基于业务的实际需求和团队的技术储备。Kong Ingress Controller 提供了一个极高的起点和宽广的演进空间，从一个简单的 Ingress 替代品，到支撑整个企业数字化转型的流量中枢，它都能够胜任。关键在于理解其背后的原理，做出明智的工程权衡。

延伸阅读与相关资源

  • 想系统性规划股票、期货、外汇或数字币等多资产的交易系统建设，可以参考我们的
    交易系统整体解决方案。
  • 如果你正在评估撮合引擎、风控系统、清结算、账户体系等模块的落地方式，可以浏览
    产品与服务
    中关于交易系统搭建与定制开发的介绍。
  • 需要针对现有架构做评估、重构或从零规划，可以通过
    联系我们
    和架构顾问沟通细节，获取定制化的技术方案建议。
滚动至顶部