1. 为什么要在Kubernetes里用Kong？聊聊我的真实感受

如果你正在搞微服务，或者已经在用K8s了，那你肯定对“网关”这个词不陌生。简单说，网关就是你所有服务对外的统一大门，流量进来、出去都得经过它。那为什么是Kong呢？我自己在好几个生产环境里折腾过，从早期的Nginx+OpenResty自己写配置，到后来用Spring Cloud Gateway，最后落到Kong上，感觉它确实是K8s生态里一个“省心”的选择。

首先，Kong不是凭空造出来的，它底层就是Nginx和OpenResty。这意味着什么？意味着它天生就继承了Nginx的高性能和稳定性，同时通过OpenResty的Lua脚本能力，变得极其灵活。你想想，一个网关，既要扛得住高并发，又要能灵活地加各种功能，比如限流、鉴权、日志，Kong这个底子就选对了。其次，也是我个人觉得最香的一点，就是它和Kubernetes的集成深度。Kong官方提供了Kong Ingress Controller，这玩意儿能直接把Kong变成K8s原生的Ingress控制器。你不用再像以前那样，在K8s外面单独维护一个网关集群，然后手动配置路由转发。现在，你只需要在K8s里定义几个YAML文件，路由规则、插件配置就能自动同步到Kong，完全是声明式的玩法，跟K8s的哲学一脉相承。

再说说它的模式。Kong从1.1版本后支持了dbless模式，也就是无数据库模式，直接用YAML文件声明所有配置。这适合配置相对固定、追求极简部署的场景。但我们今天要聊的，是更经典、也更适合动态管理微服务的PostgreSQL模式。这个模式下，所有配置（服务、路由、消费者、插件）都存数据库里，通过Kong的Admin API进行增删改查。如果你的服务经常变动，需要动态添加API路由，或者用户（Consumer）数量很多，需要频繁管理，那PostgreSQL模式绝对是首选。它提供了中心化的配置管理和持久化能力，让你操作起来心里有底。

所以，这篇文章就是给你的一份“从零到一”的实战手册。我会假设你有一个正在运行的Kubernetes集群（不管是Minikube、K3s还是云厂商的托管集群），然后带着你一步步把Kong网关、它的数据库PostgreSQL，还有那个很好用的管理界面Konga，全部在K8s里跑起来。过程中我会把每个YAML文件的关键配置掰开揉碎了讲，告诉你为什么这么配，踩过的坑也会提前给你指出来。目标很简单：让你看完就能在自己的环境里复现一个生产可用的Kong网关。

2. 打好地基：部署PostgreSQL数据库

万事开头难，但数据库这步走稳了，后面就顺了。Kong和它的管理面板Konga都需要数据库，我们最好给它们各自准备一个，隔离起来更清爽。这里我们用PostgreSQL，版本选个比较稳定的，比如10或者12都行。

2.1 编写数据库部署的YAML文件

我们先在K8s里创建一个独立的命名空间（Namespace）来放所有Kong相关的资源，这样好管理。然后部署PostgreSQL。下面这个YAML文件，我加了很多注释，你直接复制修改就能用。

# 创建一个专门的命名空间
apiVersion: v1
kind: Namespace
metadata:
  name: kong
---
# 部署PostgreSQL的Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: postgres
  namespace: kong  # 注意这里指定了命名空间
spec:
  replicas: 1  # 生产环境建议至少2个副本并配置高可用
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      labels:
        app: postgres
    spec:
      containers:
      - name: postgres
        image: postgres:12  # 我习惯用12，你也可以用其他稳定版本
        env:
        - name: POSTGRES_USER
          value: postgres  # 超级用户，用于管理
        - name: POSTGRES_PASSWORD
          value: your-strong-password-here  # 务必改成强密码！
        - name: POSTGRES_DB
          value: postgres   # 初始化创建的默认数据库
        - name: PGDATA
          value: /var/lib/postgresql/data/pgdata
        ports:
        - containerPort: 5432
        volumeMounts:
        - mountPath: /var/lib/postgresql/data
          name: postgres-data
      volumes:
      - name: postgres-data
        persistentVolumeClaim:  # 生产环境强烈建议用PVC持久化数据
          claimName: postgres-pvc  # 你需要提前创建好这个PVC
---
# 为PostgreSQL创建一个Service，方便Kong和Konga连接
apiVersion: v1
kind: Service
metadata:
  name: postgres-service
  namespace: kong
spec:
  selector:
    app: postgres
  ports:
  - port: 5432        # Service对集群内暴露的端口
    targetPort: 5432  # 容器内部的端口
  # type: ClusterIP  # 默认就是ClusterIP，只在集群内访问，最安全

这里有几个关键点我得唠叨一下。第一是密码，your-strong-password-here这个一定要换成你自己生成的复杂密码，别偷懒。第二是数据持久化，我用了persistentVolumeClaim，这只是一个示意。在实际生产环境，你必须先根据你的存储系统（比如云盘、NFS、Ceph等）创建一个PVC，名字要和这里对应上。如果只是测试，可以用hostPath，但重启节点数据可能就丢了，千万别在生产环境这么干。第三是Service类型，我用了默认的ClusterIP，这意味着数据库服务只在K8s集群内部可以访问，外部是连不上的，这样最安全。Kong和Konga都在同一个集群的kong命名空间里，所以它们能通过postgres-service.kong.svc.cluster.local这个域名访问到数据库。

2.2 进入Pod创建Kong和Konga的专属数据库

部署好PostgreSQL之后，我们需要进去创建两个数据库，分别给Kong和Konga用。别担心，操作很简单。

# 1. 先找到PostgreSQL的Pod名字
kubectl get pods -n kong

# 假设Pod名字叫 postgres-xxxxx-xxxx
# 2. 进入Pod的bash环境
kubectl exec -it postgres-xxxxx-xxxx -n kong -- /bin/bash

# 现在你已经进入容器内部了，执行：
# 3. 使用psql连接PostgreSQL
psql -h 127.0.0.1 -p 5432 -d postgres -U postgres
# 它会提示你输入密码，就是上面YAML里设置的`your-strong-password-here`

# 连接成功后，你会看到 postgres=# 的提示符，然后开始创建数据库和用户
# 4. 创建Kong的数据库和用户
CREATE USER kong WITH PASSWORD 'kong-password'; -- 给Kong设置一个专用密码
CREATE DATABASE kong OWNER kong;
GRANT ALL PRIVILEGES ON DATABASE kong TO kong;

# 5. 创建Konga的数据库和用户
CREATE USER konga WITH PASSWORD 'konga-password'; -- 给Konga设置一个专用密码
CREATE DATABASE konga OWNER konga;
GRANT ALL PRIVILEGES ON DATABASE konga TO konga;

# 6. 检查一下是否创建成功
\list  -- 查看数据库列表，应该能看到kong和konga
\du   -- 查看用户列表，应该能看到kong和konga用户
# 7. 退出
\q
exit

这一步千万别省。很多新手在这一步容易出错，要么密码不对，要么忘记授权。记住，我们创建了两个独立的用户和数据库，这样权限清晰，以后排查问题也方便。密码kong-password和konga-password也要换成你自己的。做完这一步，数据库的地基就算打牢了。

3. 核心主角登场：部署Kong网关

数据库准备好了，现在可以请出我们的主角Kong了。部署Kong到K8s稍微有点步骤，主要是因为它需要先做一次数据库迁移（Migration），把表结构创建好，然后再部署网关本身和它的Ingress Controller。

3.1 关键第一步：执行数据库迁移（Migration）

你可以把迁移理解成给Kong安装“数据库驱动”。Kong需要知道在PostgreSQL里怎么建表、怎么存数据。官方推荐的做法是使用一个Kubernetes Job来执行这个一次性任务。这个Job会启动一个Kong容器，运行kong migrations bootstrap命令。

apiVersion: batch/v1
kind: Job
metadata:
  name: kong-migrations
  namespace: kong
spec:
  template:
    spec:
      # 使用 initContainer 来等待数据库就绪，这是个好习惯
      initContainers:
      - name: wait-for-postgres
        image: busybox:1.28
        command:
        - /bin/sh
        - -c
        - |
          # 这个循环会一直尝试连接数据库，直到成功为止
          until nc -zv $KONG_PG_HOST $KONG_PG_PORT; do
            echo "等待数据库服务就绪...";
            sleep 2;
          done
          echo "数据库已就绪！"
        env:
        - name: KONG_PG_HOST
          value: "postgres-service.kong.svc" # K8s内部服务域名
        - name: KONG_PG_PORT
          value: "5432"
      containers:
      - name: kong-migrations
        image: kong:2.8.1  # 建议使用较新稳定版，如2.8.x或3.x
        command: ["/bin/sh", "-c", "kong migrations bootstrap && kong migrations up"]
        env:
        - name: KONG_DATABASE
          value: "postgres"
        - name: KONG_PG_HOST
          value: "postgres-service.kong.svc"
        - name: KONG_PG_PORT
          value: "5432"
        - name: KONG_PG_USER
          value: "kong"           # 对应之前创建的用户
        - name: KONG_PG_PASSWORD
          value: "kong-password"  # 对应之前创建的密码
        - name: KONG_PG_DATABASE
          value: "kong"           # 对应之前创建的数据库
      restartPolicy: OnFailure

这个Yaml有几个设计巧思。第一，用了initContainer来等待数据库。因为Job可能比数据库Pod启动得快，直接运行迁移肯定会失败。这个wait-for-postgres容器用nc（netcat）命令不断尝试连接数据库端口，连上了才放行，确保主容器执行时数据库是活的。第二，我不仅执行了bootstrap（初始化），还加了kong migrations up，这是一个好习惯，确保所有迁移脚本都运行到最新。部署完这个Job后，用kubectl get jobs -n kong看看状态，如果是Completed就成功了。如果失败，用kubectl logs job/kong-migrations -n kong查看日志，多半是数据库连接信息配错了。

3.2 部署Kong本体与Ingress Controller

迁移成功后，就可以部署Kong的核心组件了。这里我们会部署三样东西：Kong Proxy（处理流量的核心）、Kong Admin API（管理接口）、以及Kong Ingress Controller（负责监听K8s Ingress资源并同步配置）。我们会把它们放在一个Pod里，用Sidecar模式运行。

# 首先，需要一些K8s的RBAC权限和自定义资源定义(CRD)，Kong Ingress Controller需要它们来工作。
# 由于内容较长，这里给出关键部分，完整版建议从Kong官方GitHub仓库获取对应版本的部署清单。
# 1. 创建ServiceAccount和ClusterRole等（略，见官方manifests）
# 2. 部署Kong Proxy和Ingress Controller的Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ingress-kong
  namespace: kong
  labels:
    app: ingress-kong
spec:
  replicas: 2  # 生产环境建议至少2个，实现高可用
  selector:
    matchLabels:
      app: ingress-kong
  template:
    metadata:
      labels:
        app: ingress-kong
    spec:
      serviceAccountName: kong-serviceaccount # 前面RBAC中创建的
      containers:
      # 容器1: Kong Proxy (数据平面)
      - name: proxy
        image: kong:2.8.1
        env:
        # 核心配置：数据库连接
        - name: KONG_DATABASE
          value: "postgres"
        - name: KONG_PG_HOST
          value: "postgres-service.kong.svc"
        - name: KONG_PG_USER
          value: "kong"
        - name: KONG_PG_PASSWORD
          value: "kong-password"
        - name: KONG_PG_DATABASE
          value: "kong"
        - name: KONG_PG_PORT
          value: "5432"
        # 监听配置：Proxy监听所有网卡的8000和8443端口
        - name: KONG_PROXY_LISTEN
          value: "0.0.0.0:8000, 0.0.0.0:8443 ssl http2"
        # 端口映射，方便理解。比如外部80端口映射到内部的8000
        - name: KONG_PORT_MAPS
          value: "80:8000, 443:8443"
        # Admin API监听配置。注意：生产环境建议不要暴露到0.0.0.0，或者用网络策略严格限制
        - name: KONG_ADMIN_LISTEN
          value: "0.0.0.0:8001"
        # 状态监听，用于健康检查
        - name: KONG_STATUS_LISTEN
          value: "0.0.0.0:8100"
        # Nginx工作进程数，一般设置为CPU核心数
        - name: KONG_NGINX_WORKER_PROCESSES
          value: "auto"
        ports:
        - name: proxy
          containerPort: 8000
          protocol: TCP
        - name: proxy-ssl
          containerPort: 8443
          protocol: TCP
        - name: admin
          containerPort: 8001
          protocol: TCP
        - name: status
          containerPort: 8100
          protocol: TCP
        livenessProbe:
          httpGet:
            path: /status
            port: 8100
            scheme: HTTP
          initialDelaySeconds: 5
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /status
            port: 8100
            scheme: HTTP
          initialDelaySeconds: 5
          periodSeconds: 10
      # 容器2: Kong Ingress Controller (控制平面)
      - name: controller
        image: kong/kubernetes-ingress-controller:2.10  # 版本尽量与Kong版本匹配
        env:
        # 指向Kong的Admin API，因为它们在同一个Pod，可以用localhost
        - name: CONTROLLER_KONG_ADMIN_URL
          value: http://localhost:8001
        # 发布服务，告诉Controller哪个Service对外暴露流量
        - name: CONTROLLER_PUBLISH_SERVICE
          value: kong/kong-proxy
        # 启用Leader选举，多副本时只有一个Controller工作
        - name: CONTROLLER_ELECTION_ID
          value: "kong-ingress-controller-leader"
        # 设置监听的命名空间，为空则监听所有命名空间
        - name: CONTROLLER_WATCH_NAMESPACE
          value: ""
        args:
        - /kong-ingress-controller
        - --publish-service=kong/kong-proxy
        - --ingress-class=kong
        - --election-id=kong-ingress-controller-leader
        - --kong-admin-url=http://localhost:8001
        - --log-level=info
        - --v=3
        livenessProbe:
          httpGet:
            path: /healthz
            port: 10254
            scheme: HTTP
          initialDelaySeconds: 5
          periodSeconds: 10
---
# 创建两个Service，一个对外提供代理服务，一个暴露Admin API（内部用）
apiVersion: v1
kind: Service
metadata:
  name: kong-proxy
  namespace: kong
spec:
  type: LoadBalancer  # 如果是云环境，会自动创建负载均衡器。测试环境可用NodePort
  # 如果使用NodePort，添加如下注释（以阿里云为例）：
  # annotations:
  #   service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "intranet"
  selector:
    app: ingress-kong
  ports:
  - name: proxy
    port: 80          # Service端口
    targetPort: 8000  # 对应容器端口
    protocol: TCP
  - name: proxy-ssl
    port: 443
    targetPort: 8443
    protocol: TCP
---
apiVersion: v1
kind: Service
metadata:
  name: kong-admin
  namespace: kong
spec:
  type: ClusterIP  # Admin API只在集群内部访问，确保安全
  selector:
    app: ingress-kong
  ports:
  - name: admin
    port: 8001
    targetPort: 8001
    protocol: TCP

这份配置信息量很大，我挑重点说。第一是双容器Pod：一个跑Kong Proxy（处理真实流量），一个跑Kong Ingress Controller（监听K8s API，更新配置）。它们通过localhost:8001通信。第二是环境变量：KONG_PROXY_LISTEN和KONG_ADMIN_LISTEN一定要设对，特别是Admin API，测试可以监听0.0.0.0，生产环境务必限制。第三是Service类型：kong-proxy用了LoadBalancer，在公有云上会自动创建一个外部负载均衡器把流量引进来。如果你在本地测试（比如Minikube），可以改成NodePort，然后通过<节点IP>:<NodePort>访问。kong-admin用了ClusterIP，很安全。部署完后，用kubectl get svc -n kong看kong-proxy的EXTERNAL-IP，如果显示<pending>（在本地环境），那就用NodePort端口访问。

4. 给Kong配上“眼睛”：部署Konga管理界面

Kong Admin API虽然强大，但毕竟是命令行和API操作，不够直观。Konga就是一个为Kong量身定做的Web管理界面，能可视化地管理服务、路由、消费者和插件，特别适合团队协作和日常运维。

4.1 初始化Konga数据库

和Kong一样，Konga也需要先初始化数据库。这里我们用一种更“Kubernetes”的方式，同样使用Job。注意，Konga镜像本身提供了-c prepare的初始化命令。

apiVersion: batch/v1
kind: Job
metadata:
  name: konga-prepare
  namespace: kong
spec:
  template:
    spec:
      containers:
      - name: konga-prepare
        image: pantsel/konga:latest  # 或用特定版本如 0.14.9
        command: ["/bin/sh", "-c"]
        args:
          - |
            # 使用Konga自带的命令准备数据库
            node ./bin/konga.js prepare --adapter postgres --uri postgresql://konga:konga-password@postgres-service.kong.svc:5432/konga
        env:
        - name: NODE_ENV
          value: production
      restartPolicy: OnFailure

这个Job会连接到我们之前创建的konga数据库，并创建所需的表。执行成功后，Job状态会变为Completed。你可以通过kubectl logs job/konga-prepare -n kong查看初始化日志。

4.2 部署Konga应用

数据库准备好后，就可以部署Konga本身了。它的配置主要是一系列环境变量，用来指定数据库连接和运行参数。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: konga
  namespace: kong
spec:
  replicas: 1
  selector:
    matchLabels:
      app: konga
  template:
    metadata:
      labels:
        app: konga
    spec:
      containers:
      - name: konga
        image: pantsel/konga:latest
        ports:
        - containerPort: 1337  # Konga默认端口是1337
        env:
        - name: NODE_ENV
          value: production
        - name: DB_ADAPTER
          value: postgres
        - name: DB_HOST
          value: postgres-service.kong.svc
        - name: DB_PORT
          value: "5432"
        - name: DB_USER
          value: konga
        - name: DB_PASSWORD
          value: konga-password  # 记得换成你设置的密码
        - name: DB_DATABASE
          value: konga
        - name: DB_PG_SCHEMA
          value: public
        # 重要：这个必须设为false，否则会跳过登录，直接进入
        - name: NO_AUTH
          value: "false"
        # 可选：设置Token签名密钥，增强安全
        - name: TOKEN_SECRET
          value: your-super-secret-token-key-here
        readinessProbe:
          httpGet:
            path: /
            port: 1337
          initialDelaySeconds: 30  # Konga启动较慢，延迟设长点
          periodSeconds: 10
        livenessProbe:
          httpGet:
            path: /
            port: 1337
          initialDelaySeconds: 40
          periodSeconds: 30
---
apiVersion: v1
kind: Service
metadata:
  name: konga
  namespace: kong
spec:
  type: NodePort  # 方便用浏览器访问
  selector:
    app: konga
  ports:
  - port: 80
    targetPort: 1337
    nodePort: 30001  # 可以指定一个范围在30000-32767之间的端口

这里有几个坑我踩过，提醒你注意。第一是NO_AUTH环境变量，如果设为true，Konga会禁用登录，任何人都能进，生产环境绝对不要这么干。第二是TOKEN_SECRET，用于签名JWT Token，生产环境一定要设一个复杂的随机字符串。第三是健康检查的initialDelaySeconds，Konga这个Node.js应用启动比想象中慢，如果探针启动太快，会一直认为Pod没准备好，所以我把readinessProbe的初始延迟设到了30秒。部署好后，通过NodePort（例如http://<你的节点IP>:30001）就能访问Konga了。第一次访问需要注册一个管理员账号。

4.3 连接Konga与Kong网关

登录Konga后，第一件事就是“连接”到你的Kong网关。点击左侧导航的Connections，然后Add New Connection。

• Name: 随便起，比如 production-kong。
• Kong Admin URL: 这里填我们之前创建的Kong Admin Service的地址。因为Konga和Kong在同一个K8s集群的同一个Namespace，所以可以直接用服务名：http://kong-admin.kong.svc.cluster.local:8001。注意，如果Konga部署在其他地方，需要填能访问到的地址。
• 其他选项可以先保持默认，点击Submit。

连接成功后，Konga就会拉取Kong的当前配置（服务、路由、插件等），并显示在仪表盘上。你可以在这里点点鼠标就完成API的发布、插件的启用，比写curl命令舒服多了。

5. 实战演练：在K8s里用Kong暴露你的第一个服务

理论说了这么多，是时候动动手了。我们来模拟一个最常见的场景：你有一个部署在K8s里的Web应用（比如一个Nginx服务），现在想通过Kong网关把它暴露给外部用户访问。

5.1 方法一：使用Kong的Admin API（原生方式）

假设你的应用叫my-webapp，已经在default命名空间里跑起来了，并且有一个对应的Service叫my-webapp-svc，端口是80。首先，我们通过Kong的Admin API来操作。

# 1. 先获取Kong Proxy Service的访问地址。如果是LoadBalancer，用EXTERNAL-IP；如果是NodePort，用<NodeIP>:<NodePort>
KONG_PROXY_IP="你的Kong Proxy外部IP或域名"
KONG_ADMIN_URL="http://kong-admin.kong.svc.cluster.local:8001" # 在集群内操作，或用端口转发到本地

# 2. 创建一个Service（这里的Service是Kong内部的概念，对应你的后端应用）
curl -i -X POST $KONG_ADMIN_URL/services \
  --data name=my-webapp-service \
  --data url=http://my-webapp-svc.default.svc.cluster.local:80
# 注意url格式：http://<service-name>.<namespace>.svc.cluster.local:<port>

# 3. 为上一步创建的Service添加一个Route（路由规则）
curl -i -X POST $KONG_ADMIN_URL/services/my-webapp-service/routes \
  --data 'paths[]=/webapp' \
  --data 'name=my-webapp-route'

# 4. 测试一下！
# 现在，访问 http://$KONG_PROXY_IP/webapp 就应该能访问到你的后端应用了。
curl -i http://$KONG_PROXY_IP/webapp

这几条命令干了啥？第一，在Kong里注册了一个“服务”，指向你真正的K8s Service。第二，给这个服务加了一条“路由”规则，规定路径前缀是/webapp的请求，才转发给这个服务。这样，网关就配置好了。你可以在Konga的Services和Routes页面看到刚刚创建的内容，并且可以随时编辑。

5.2 方法二：使用Kubernetes Ingress资源（声明式，更推荐）

上面的方法需要主动调用API，不够“云原生”。更K8s的方式是使用Ingress资源。Kong Ingress Controller会一直监听集群内所有的Ingress对象，并自动将规则同步到Kong。

# my-webapp-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-webapp-ingress
  namespace: default # 你的应用所在的命名空间
  annotations:
    # 最关键的一行：指定Ingress Class为kong
    kubernetes.io/ingress.class: "kong"
    # 可选：启用Kong插件，例如限流
    konghq.com/plugins: "rate-limiting, cors"
spec:
  rules:
  - http:
      paths:
      - path: /webapp
        pathType: Prefix
        backend:
          service:
            name: my-webapp-svc # 你的后端Service名
            port:
              number: 80 # 你的后端Service端口

把这个YAML文件kubectl apply -f一下，Kong Ingress Controller几乎会瞬间感知到，并在Kong里创建出对应的服务和路由。你可以通过kubectl get ingress查看状态。这种方式的好处是，你的网关配置和你的应用部署描述（Deployment, Service）都在一套YAML文件里，版本控制、回滚都特别方便。

5.3 玩转Kong插件：给API加上限流

Kong最强大的功能之一就是插件生态。我们以最常用的“速率限制”（Rate Limiting）插件为例，看看怎么给刚才的my-webapp-service加上每分钟最多5次请求的限制。

在Konga里操作（可视化）：

1. 进入Services，点击my-webapp-service。
2. 在服务详情页，找到Plugins选项卡，点击Add Plugin。
3. 在插件列表里找到Rate Limiting，点击。
4. 在配置页面，你可以这样填：
   • config.minute: 5 （每分钟5次）
   • config.policy: local （使用本地计数器，对于单实例或共享存储的集群，也可以用redis）
5. 点击Submit。

用YAML声明（Ingress注解方式）： 如果你想用声明式的方式，可以在Ingress的注解里直接配置插件。首先，创建一个KongPlugin自定义资源：

apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: global-rate-limit
  namespace: default
config:
  minute: 5
  policy: local
plugin: rate-limiting

然后，在Ingress的注解里引用它：

annotations:
  kubernetes.io/ingress.class: "kong"
  konghq.com/plugins: "global-rate-limit" # 这里引用上面创建的插件名

配置完成后，你可以快速用curl连续访问几次你的API，第六次就会收到429 Too Many Requests的响应，说明限流生效了。通过这种方式，你可以轻松地为API添加认证、日志、监控、转换等各种功能，而无需修改后端应用的一行代码。

走到这里，一个包含数据库、网关、管理界面的完整Kong on K8s环境就已经搭建并配置完毕了。从最基础的服务暴露，到高级的插件使用，你已经掌握了核心流程。在实际生产环境中，还需要考虑更多，比如使用Helm Chart来简化部署、配置数据库高可用、设置网络策略加强安全、以及结合CI/CD流水线自动化配置管理等。但有了这个扎实的起点，那些都是顺理成章的下一步了。记住，遇到问题多查日志（kubectl logs），善用Konga的可视化界面进行调试，这个组合拳能帮你解决大部分日常的网关管理和运维问题。