Kong 面试题

答案：

Kong 是一款基于 OpenResty + Lua 构建的高性能、云原生 API Gateway，核心目标是在微服务入口处统一处理路由、认证、限流、可观测性等横切关注点。

核心架构：

flowchart TB
    Client["Client Request"]

    subgraph Nginx["Nginx (OpenResty)"]
        direction LR
        subgraph Hooks["Lua 钩子链（按请求生命周期）"]
            direction LR
            H1["rewrite_by_lua"]
            H2["access_by_lua"]
            H3["content_by_lua"]
            H4["log_by_lua"]
            H1 --> H2 --> H3 --> H4
        end
        Plugin["Plugin Chain (Lua 插件链)
rate-limiting → key-auth → prometheus → proxy"]
    end

    Upstream["Upstream Services
(Microservices / K8s Pods)"]

    Client --> H1
    H4 --> Plugin
    Plugin --> Upstream

为何选择 OpenResty + Lua：

• OpenResty 将 Nginx 的高性能事件循环与 LuaJIT 虚拟机结合，在请求处理的关键阶段（init_by_lua、rewrite_by_lua、access_by_lua、content_by_lua、log_by_lua、balancer_by_lua）注入 Lua 脚本，避免阻塞主循环
• LuaJIT 提供接近 C 的执行性能，JIT 编译热点路径，使插件逻辑与 Nginx 同等量级的吞吐量
• 协程模型：ngx.thread 提供轻量级协程，插件中可发起非阻塞 I/O（DB 查询、Redis 调用、HTTP 上游调用）而不阻塞 worker
• 动态配置：通过 lua-resty-kafka、lua-resty-redis 等生态与外部数据源（PostgreSQL/Redis）解耦，避免每次变更重启 Nginx

核心数据模型：

请求生命周期：Client → Nginx Worker → rewrite/access_by_lua 钩子触发插件链 → balancer_by_lua 选择上游 → proxy_pass 上游服务 → log_by_lua 记录指标。

答案：

Kong 插件以 Lua 模块 形式实现，按请求生命周期阶段组织 Handler，是 Kong 扩展能力的核心机制。

插件目录结构：

kong/plugins/my-plugin/
├── handler.lua        # 核心 Handler，定义各阶段方法
├── schema.lua         # 配置 schema（kong.db.schema 定义参数）
└── daos.lua           # 可选：自定义 DAO（持久化到 DB）

Handler 模板：

-- kong/plugins/my-plugin/handler.lua
local MyPlugin = {
  PRIORITY = 1000,    -- 数值越大越先执行
  VERSION = "1.0.0",
}

function MyPlugin:access(conf)
  -- access 阶段：认证/限流/请求头注入
  local headers = ngx.req.get_headers()
  if not headers["x-api-key"] then
    return kong.response.error(401, "missing api key")
  end
  kong.service.request.set_header("x-injected", "my-plugin")
end

function MyPlugin:log(conf)
  -- log 阶段：异步日志上报
  kong.log.inspect("request logged: ", conf.message)
end

return MyPlugin

Schema 定义：

-- kong/plugins/my-plugin/schema.lua
local typedefs = require "kong.db.schema.typedefs"

return {
  name = "my-plugin",
  fields = {
    { consumer = typedefs.no_consumer },       -- 是否可绑定 Consumer
    { protocols = typedefs.protocols_http },    -- 支持协议
    { config = {
        type = "record",
        fields = {
          { message = { type = "string", default = "ok" } },
          { ttl = { type = "number", default = 60 } },
        },
      },
    },
  },
}

可执行阶段（按请求顺序）：

启用方式：

# 在 K8s 通过 KIC CRD 启用
kubectl apply -f - <<EOF
apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: my-plugin
plugin: my-plugin
config:
  message: "hello"
EOF

Go/PDK 插件（Kong 3.x+）：

Kong 3.0+ 推出 Plugin Development Kit (PDK) for Go，允许用 Go 编写插件并通过 go-pluginserver 加载，适用于团队更熟悉 Go 而非 Lua 的场景，但需独立进程部署且与 Lua 插件存在性能差异。

答案：

Kong 同一厂商（Kong Inc.）旗下的 Gateway 与 Mesh 定位不同的网络层，常见误用是混为一谈。

核心定位差异：

Kong Mesh 的底层是 Kuma：

Kong Mesh 是 Kuma 的商业发行版，Kuma 是 CNCF Sandbox（后晋升）的开源 Service Mesh 控制面。Kong Mesh 在 Kuma 基础上加入企业级特性（UI、RBAC、审计、SAML）。

典型组合：

flowchart TB
    Clients["External Clients"]

    subgraph Gateway["Kong Gateway (Ingress)"]
        GW["Kong Gateway
TLS Termination · OAuth2 · Rate Limit · Logging"]
    end

    subgraph SvcA["Service A · Kong Mesh"]
        SA1[App]
        SA2[Envoy Sidecar]
        SA1 <--> SA2
    end

    subgraph SvcB["Service B · Kong Mesh"]
        SB1[App]
        SB2[Envoy Sidecar]
        SB1 <--> SB2
    end

    subgraph SvcC["Service C · Kong Mesh"]
        SC1[App]
        SC2[Envoy]
        SC1 <--> SC2
    end

    Clients --> GW
    GW --> SA2
    GW --> SB2
    GW --> SC2
    SA2 <--> SB2
    SB2 <--> SC2

选型决策：

• 仅有边缘 API 管理需求 → Kong Gateway 即可
• 集群内大量微服务需要 mTLS + 流量管理 → Kong Mesh
• 两者兼有 → Kong Konnect 统一平台，Gateway + Mesh 共享控制平面
• 不想被商业版绑定 → Gateway 可用开源版（OSS），Mesh 可选 Kuma OSS

答案：

Kong Ingress Controller (KIC) 将 K8s 的 Ingress / Gateway API 资源翻译为 Kong 的 Service/Route/Plugin 配置，实现 K8s 原生方式管理 Kong。

架构组件：

flowchart TB
    subgraph KCP["Kubernetes Control Plane"]
        CRD["Ingress / Gateway / HTTPRoute / KongPlugin CRD"]
    end

    subgraph KIC["KIC Controller (Deployment)"]
        K1["Watch K8s API
(Ingress, Service, Secret, CRD)"]
        K2["Translate to Kong Admin API
/ DB-less Config"]
        K3["Push config to Kong Data Plane"]
        K1 --> K2 --> K3
    end

    subgraph KP["Kong Proxy (Deployment / DaemonSet)"]
        KP1["OpenResty + Lua 接收真实流量"]
        KP2["路由 / 插件链 / 上游负载均衡"]
        KP1 --> KP2
    end

    CRD --> K1
    K3 --> KP1

支持的核心 CRD：

示例：KongPlugin 启用限流与认证

apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: rate-limit
plugin: rate-limiting
config:
  minute: 100
  policy: redis
  redis_host: redis.kong-system.svc
apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: jwt-auth
plugin: jwt
config:
  secret_is_base64: false
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api
  annotations:
    konghq.com/plugins: "rate-limit, jwt-auth"
spec:
  ingressClassName: kong
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /v1
        pathType: Prefix
        backend:
          service:
            name: api-svc
            port:
              number: 80

KIC 与传统 Ingress Controller 差异：

• 传统 Ingress Controller（如 ingress-nginx）自身实现路由逻辑，KIC 则是 配置生成器，运行时由 Kong Proxy 处理流量
• KIC 解耦后，Kong Proxy 可水平扩展为多实例并共享同一份配置
• KIC 支持 Gateway API（GatewayClass: kong），可统一 HTTP/TCP/UDP/gRPC 路由

答案：

DB-less（Declarative Configuration，无数据库模式）自 Kong 1.0（2018）起就是官方支持的部署形态，Kong 3.x 进一步强化了 KIC 集成、Hybrid Mode 性能与声明式配置校验。

两种模式对比：

DB-less 配置示例：

# kong.yaml (declarative config)
_format_version: "3.0"
services:
- name: api-service
  url: http://api-svc.default.svc:80
  routes:
  - name: api-route
    paths:
    - /v1
    methods:
    - GET
    - POST
  plugins:
  - name: rate-limiting
    config:
      minute: 100
      policy: local
  - name: key-auth
consumers:
- username: app-client
  keyauth_credentials:
  - key: secret-key-123
upstreams:
- name: api-upstream
  targets:
  - target: api-pod-1.default.svc:80
    weight: 100
  - target: api-pod-2.default.svc:80
    weight: 100

启动：kong start -c kong.conf（配置中设置 database: "off" 启用 DB-less），或使用 deck sync -s kong.yaml（推荐 GitOps 流程）。

DB-less 的限制：

• 不支持运行时修改：Admin API 写操作返回 405，必须改 YAML 后 reload
• 不支持部分动态插件：依赖 DB 的 rate-limiting（cluster 策略）、oauth2、developer-portal 不可用
• 插件策略降级：rate-limiting 仅支持 local（单机内存计数），跨节点不共享；key-auth 凭证必须在配置中预声明
• 变更影响：每次 reload 重建内存路由表，毫秒级抖动，毫秒级可接受

典型使用场景：

• GitOps 流程：Kong 配置即代码，ArgoCD/Flux 同步 → reload
• 边缘/IoT 节点：资源受限，部署 DB 不现实
• 多环境一致性：dev/staging/prod 同一份 YAML，避免 DB 漂移
• KIC 默认模式：KIC 推送 declarative config 给 Kong，避免部署 PostgreSQL

生产推荐：

• K8s 环境 → KIC + DB-less
• 大量运行时变更（多团队、动态消费者）→ DB 模式或转 Konnect

答案：

Kong 与 Service Mesh 并非互斥关系，常见集成模式有三种，分别覆盖不同治理范围。

集成模式对比：

模式 1：Kong Mesh 独立部署（基于 Kuma）

# kuma-control-plane 启动
kumactl install control-plane --set "controlPlane.mode=zone" | kubectl apply -f -
# 注入 sidecar
kubectl annotate namespace default kuma.io/sidecar-injection=enabled

Mesh 提供 mTLS、TrafficPermission、TrafficRoute，Kong 仍负责 Ingress。Konnect 平台 可统一管理两者。

模式 2：Kong Gateway + Istio

flowchart TB
    Internet --> Kong["Kong Gateway
边缘路由、OAuth2、限流"]
    Kong --> Istio["Istio Mesh"]
    subgraph Istio[" "]
        direction LR
        EnvoyA["Envoy Sidecar"] <--> EnvoyB["Envoy Sidecar"]
        SA["Service A"] --> EnvoyA
        SB["Service B"] --> EnvoyB
    end

Kong 部署在 Istio Ingress Gateway 之前（spec.type: ClusterIP + Kong Service + Istio VirtualService 路由），或反过来：Istio IngressGateway → Kong Proxy → Service。

模式 3：Kong 替代 Istio Ingress Gateway

# 自定义 GatewayClass 指向 KIC
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: kong
spec:
  controllerName: konghq.com/gateway

KIC 支持 Gateway API v1，可替代 Istio 的 Ingress Gateway 角色，但失去 Istio 在入口层的 mTLS 与 SNI 能力。

选型建议：

• K8s 多语言微服务 + 严格零信任 → Istio + Kong（边缘）
• 避免 Envoy 复杂度 + 已有 Kong 生态 → Kong Mesh 自闭环
• 轻量化 Mesh → Linkerd + Kong，Linkerd 资源占用低

答案：

Kong 的插件生态是其核心竞争力，官方维护 50+ 插件，社区插件上百个，按功能分为认证、安全、流量控制、可观测性、转换等大类。

核心插件矩阵：

限流插件：rate-limiting

plugins:
- name: rate-limiting
  config:
    minute: 100            # 每分钟 100 次
    hour: 10000            # 每小时 10000 次
    policy: redis          # cluster=Redis / local=单机 / database=DB
    redis_host: redis.kong.svc
    redis_port: 6379
    fault_tolerant: true   # Redis 故障时放行（fail-open）
    hide_client_headers: false

• 支持多维度 key：consumer、credential、ip、service、header、path
• policy: redis 时通过 Lua 脚本在 Redis sorted set 中实现滑动窗口计数（ZADD + ZREMRANGEBYSCORE），跨节点共享，精度高于固定窗口
• policy: local 时使用 OpenResty 共享字典（lua_shared_dict），性能最高但不跨节点

认证插件：jwt + key-auth 对比

可观测性插件：

- name: prometheus
  config:
    per_consumer: true           # 按 Consumer 维度统计
    status_code_metrics: true
    latency_metrics: true
    bandwidth_metrics: true
    upstream_health_metrics: true

暴露 /metrics 端点（默认独立 metrics 端口 9542，Kong 2.x+ 统一为 9542；Kong 1.x 时代为 9541），Prometheus 抓取后可在 Grafana 中按 service、route、consumer、status_code 分维度分析。

链路追踪：OpenTelemetry 插件

- name: opentelemetry
  config:
    endpoint: otel-collector:4317
    resource_attributes:
      service.name: kong-gateway
    sampling_rate: 0.1  # 10% 采样

通过 inject_response_headers 注入 traceparent，与上游服务 Trace 关联。

答案：

Kong 与 APISIX 是云原生 API Gateway 的两大主流选择，技术栈相似（都基于 OpenResty/Lua）但产品定位与生态差异显著。

核心对比：

架构差异详解：

Kong（DB-less 模式）：

ConfigMap → KIC → declarative config → Kong Proxy (内存)
                                        ↑ reload

APISIX（etcd 模式）：

etcd watch → APISIX Admin API → 路由表热更新 → 0 抖动
              ↑
       etcd cluster (Raft)

APISIX 通过 etcd watch + Lua 共享内存实现真正热更新，Kong DB-less 模式仍依赖 reload（虽然很快，但存在短暂不可用窗口）。

性能差异（典型基准，路径数 100+）：

选型建议：

• 企业级支持、长期商业合作 → Kong（Enterprise / Konnect）
• 追求极致性能、纯开源、热更新 → APISIX
• 已有 K8s 生态、与 Istio 联动 → Kong（KIC 成熟）
• 大规模路由 + 频繁变更 → APISIX（Radix Tree + 热加载）
• K8s 边缘网关 → 两者均可，Higress（阿里云基于 Envoy）也是强候选

答案：

Kong 生产部署需考虑数据面无状态化、配置同步、可观测性与零停机变更四大要素。

典型 K8s 部署架构：

flowchart TB
    Internet["Internet / CDN"]
    CLB["Cloud Load Balancer (L4)
SSL Termination → Backend to Kong :443"]

    subgraph KongProxy["Kong Proxy (Deployment, 3+ replicas) · 无状态"]
        P1["Pod-1
OpenResty + Lua"]
        P2["Pod-2
OpenResty + Lua"]
        P3["Pod-3
OpenResty + Lua"]
    end

    subgraph KIC["KIC Controller (Deployment, 2 replicas)"]
        K1["Leader Election (单 Leader 写)"]
        K2["Watch K8s API → 翻译为 Kong declarative config"]
        K3["推送到 Kong Proxy (DB-less 模式)"]
        K1 --> K2 --> K3
    end

    Upstream["Upstream Services / Microservices"]

    Internet --> CLB --> P1 & P2 & P3
    P1 & P2 & P3 -.无状态 / HPA 扩缩容.-> Upstream
    K3 -.配置同步.-> P1 & P2 & P3

DB 模式 HA 架构：

flowchart TB
    subgraph Kong["Kong Proxy (3+ replicas) — 无状态"]
        KP["Kong Nodes"]
    end

    PG_P["PostgreSQL Primary"]
    PG_S["PostgreSQL Standby"]
    PG_P <-->|stream replication| PG_S
    KP -.poll/cache.-> PG_P
    KP -.poll/cache.-> PG_S

PostgreSQL 主从 + Kong 节点轮询缓存配置变更（默认 5 秒），主库故障时手动切换或配合 Patroni。

DB-less + GitOps 模式：

flowchart TB
    Git["Git Repo
(kong.yaml + K8s manifests)"]
    Argo["ArgoCD
(监听 Git 变更)"]
    CM["ConfigMap (kong.yaml)"]
    Kong["Kong Proxy (replicas: 3)
kong reload (or hybrid mode)"]

    Git -- git push --> Argo
    Argo -- sync --> CM
    CM -- mount --> Kong

零停机变更：

• DB-less reload：kong reload 触发 worker 平滑替换（旧 worker 处理完在途请求后退出），通常 50-200ms
• Hybrid Mode（CP/DP 分离）：Kong 2.x+ 引入，控制面（CP）持久化配置，数据面（DP）通过 mTLS 长连接拉取增量变更，实现秒级配置生效且无 reload

# Kong DP 节点 hybrid 配置
role: data_plane
database: "off"
cluster_mtls: pki
cluster_server_name: kong-cp
cluster_control_plane: kong-cp.kong-system.svc:8005
cluster_telemetry_endpoint: kong-cp.kong-system.svc:8006

生产 Checklist：

答案：

Kong 生产故障多集中在配置、数据库、插件链性能与上游通信四类，以下为典型 Case。

Case 1：rate-limiting Redis 故障导致全站 500

现象： Redis 主从切换或网络抖动时，启用 rate-limiting 的路由开始返回 500。 根因： rate-limiting 默认 fault_tolerant: false，Redis 不可达时直接 fail-close。 解决：

plugins:
- name: rate-limiting
  config:
    policy: redis
    fault_tolerant: true    # Redis 故障时放行（推荐）
    redis_timeout: 2000     # 2s 超时
    redis_host: redis-cluster.kong.svc

同时配置 Redis Sentinel/Cluster 高可用，避免单点。

Case 2：DB-less reload 后短暂 502

现象： kubectl rollout restart 触发 reload 时部分请求返回 502。 根因： OpenResty 旧 worker 退出时未处理完在途请求，新 worker 已启动但 DNS/上游解析未就绪。 解决：

• 启用 Hybrid Mode（CP/DP 分离），避免 reload
• 配置 nginx_worker_processes 与 worker_shutdown_timeout
• 上游配置 healthchecks.active 主动探测，不健康上游自动摘除
• 灰度发布：先发 1/3 副本，观察 5 分钟

Case 3：JWT 验证性能瓶颈

现象： 高 QPS 下 JWT 验证插件 CPU 占用飙升，P99 延迟从 5ms 升至 50ms。 根因： 默认 jwt 插件每次请求都从 DB 查询 Consumer 与 Credential，DB 慢时成为瓶颈。 解决：

• DB-less 模式下 Consumer/凭证已加载内存，性能稳定
• DB 模式调优：增大 kong.db_cache_ttl、kong.db_cache_warmup_entities
• 使用 key-auth 替代（验证开销低一个数量级）
• JWT 验证前加 CDN/边缘缓存（针对幂等 GET）

Case 4：KIC 与 Kong 版本不兼容导致配置漂移

现象： KIC 升级后部分 Route 缺失，Kong Admin API 显示 404。 根因： KIC 与 Kong 严格版本绑定（如 KIC 3.0 仅支持 Kong 3.0+），混用旧版 KIC + 新版 Kong 导致部分 CRD 字段未翻译。 解决：

• 严格遵循 KIC 官方版本兼容矩阵
• 升级顺序：先 Kong 后 KIC，并使用 deck gateway sync 验证一致性
• 启用 KIC 的 --controller-election Leader 选举，多副本防脑裂

Case 5：插件链顺序错误导致 401 而非 403

现象： 用户携带过期 Token，应返回 401 但实际返回 403。 根因： acl 插件（基于 Consumer 检查权限）先于 jwt（认证）执行，未认证用户先被 acl 拒绝。 解决：

-- 调整插件优先级
-- jwt 优先级 1000（认证）
-- acl 优先级 950（授权）
plugins:
- name: jwt
  route: my-route
- name: acl
  route: my-route
  config:
    whitelist: ["vip-group"]

Kong 插件按 PRIORITY 数值倒序执行，认证类插件 PRIORITY 应高于授权类。

Case 6：上游 mTLS 握手失败

现象： Kong 代理 HTTPS 上游（开启 mtls-auth），握手阶段 500。 根因： 上游证书未在 Kong 节点信任链内，或 SNI 不匹配。 解决：

• 确保证书通过 kong.cluster.ca_cert 配置或挂载到 Pod
• service.tls.verify 设为 true 严格校验
• service.tls.verify_depth: 2 调整证书链深度

通用排查思路：

# 1. 开启 debug 日志
kubectl set env deploy/kong-kong KONG_LOG_LEVEL=debug

# 2. 查看 Admin API 状态
curl -s http://kong-admin:8001/status | jq .

# 3. 检查路由解析
curl -s http://kong-admin:8001/services/my-svc/routes | jq .

# 4. 验证插件执行
curl -s http://kong-admin:8001/plugins | jq '.data[] | {name, route, config}'

# 5. Prometheus 指标
curl -s http://kong-admin:9541/metrics | grep kong_request_count

# 6. 单次请求追踪
curl -v -H "kong-debug: 1" http://api.example.com/v1/test

预防措施：

• 蓝绿/灰度发布，避免 reload 全量
• 关键插件开启 fault_tolerant: true
• 配置漂移检测（KIC status CRD + Prometheus 告警）
• 定期演练 PostgreSQL/Redis 故障切换