在分布式 PostgreSQL 数据库上运行 Kong

本指南演示了如何通过在 YugabyteDB 上运行 Kong（一个基于 PostgreSQL 构建的分布式 SQL 数据库）来消除这最后的瓶颈。

在我之前的文章中，我们详细讨论了如何使用 Kong 和 YugabyteDB 构建全局 API 层和多区域服务网格。然而，所提出的解决方案仍然存在瓶颈和单点故障：Kong 内部使用的数据库来存储其元数据和特定于应用程序的配置。本指南演示了如何通过在 YugabyteDB 上运行 Kong（一个基于 PostgreSQL 构建的分布式 SQL 数据库）来消除这最后的瓶颈。

Kong 的默认数据库

Kong 使用 PostgreSQL 作为数据库来满足自己的需求。看一下 Kong 在引导过程中创建的数据库模式，你会发现有几十个表和其他数据库对象，它们存储元数据和特定于应用程序的配置：

SQL算法

1

kong=# \d

2

                     List of relations

3

 Schema |             Name              | Type  |  Owner

4

--------+-------------------------------+-------+----------

5

 public | acls                          | table | postgres

6

 public | acme_storage                  | table | postgres

7

 public | basicauth_credentials         | table | postgres

8

 public | ca_certificates               | table | postgres

9

 public | certificates                  | table | postgres

10

 public | cluster_events                | table | postgres

11

 public | clustering_data_planes        | table | postgres

12

 public | consumers                     | table | postgres

13

 public | filter_chains                 | table | postgres

14

 public | hmacauth_credentials          | table | postgres

15

 public | jwt_secrets                   | table | postgres

16

 public | key_sets                      | table | postgres

17

 public | keyauth_credentials           | table | postgres

18

 public | keys                          | table | postgres

19

20

 .. the list goes on

PostgreSQL 完美地服务于那些不需要跨多个可用区、区域或数据中心扩展的 Kong 部署。但是，当应用程序需要在不同位置部署 Kong Gateway 或 Kong Mesh 时，独立的 PostgreSQL 服务器可能会成为瓶颈或单点故障。

最初，Kong 提供 Apache Cassandra 作为 PostgreSQL 的替代品，供那些希望构建分布式 API 和服务网格的人使用。但后来，Cassandra 支持被正式弃用。Kong团队表示，PostgreSQL仍将是唯一官方支持的数据库。

为什么选择分布式 PostgreSQL？

尽管 Cassandra 已被弃用，但 Kong 用户对 Postgres 分布式版本的需求并没有减弱，原因如下：

• 高可用性： API 层和服务网格必须能够抵御各种潜在的中断，包括区域和区域级别的事件。
• 可扩展性：从全局负载均衡器到 API 层和数据库层，整个解决方案需要以低延迟处理读取和写入工作负载。
• 数据规定： 当 API 或网格跨越多个司法管辖区时，可能需要某些 API 端点在位于特定地理位置的数据中心内存储特定设置和配置。

因此，来自 Kong 和 YugabyteDB 社区的成员开始致力于使 YugabyteDB 适应分布式 Kong 部署。

为什么选择YugabyteDB？

YugabyteDB 是基于 PostgreSQL 构建的分布式 SQL 数据库。YugabyteDB 的上半部分（查询层）是 PostgreSQL，需要对 YugabyteDB 的分布式存储层进行修改。从本质上讲，您可以将 YugabyteDB 视为分布式 Postgres。

如果 YugabyteDB 保持与 Postgres 的功能和运行时兼容性，则为 Postgres 设计的大多数应用程序、库、驱动程序和框架都应该与 YugabyteDB 无缝运行，无需更改代码。例如，之前的一篇文章展示了如何使用最初为 Postgres 创建的集成在 YugabyteDB 上部署 Kubernetes。

早在 2022 年，在 Cassandra 弃用后，由于分布式数据库引擎中缺少某些 Postgres 功能，Kong 与 YugabyteDB 不兼容。但是，随着 YugabyteDB 版本 2.19.2 的发布，这种情况发生了变化，其中包括对 Kong 所有必要功能的支持。

接下来，我们将探讨如何在多节点 YugabyteDB 集群上启动和运行 Kong Gateway。

启动多节点 YugabyteDB 集群

有很多方法可以启动 Kong Gateway 和 YugabyteDB。其中一个选项是在 Docker 容器内运行所有内容。所以，今天让我们使用这种方法：

首先，为 YugabyteDB 和 Kong 容器创建自定义 docker 网络：

壳

1

docker network create custom-network

接下来，运行一个三节点 YugabyteDB 集群：

壳

1

mkdir $HOME/yb_docker_data

2

3

docker run -d --name yugabytedb_node1 --net custom-network \

4

  -p 15433:15433 -p 7001:7000 -p 9001:9000 -p 5433:5433 \

5

  -v $HOME/yb_docker_data/node1:/home/yugabyte/yb_data --restart unless-stopped \

6

  yugabytedb/yugabyte:latest \

7

  bin/yugabyted start --base_dir=/home/yugabyte/yb_data --daemon=false

8

9

docker run -d --name yugabytedb_node2 --net custom-network \

10

  -p 15434:15433 -p 7002:7000 -p 9002:9000 -p 5434:5433 \

11

  -v $HOME/yb_docker_data/node2:/home/yugabyte/yb_data --restart unless-stopped \

12

  yugabytedb/yugabyte:latest \

13

  bin/yugabyted start --join=yugabytedb_node1 --base_dir=/home/yugabyte/yb_data --daemon=false

14

15

docker run -d --name yugabytedb_node3 --net custom-network \

16

  -p 15435:15433 -p 7003:7000 -p 9003:9000 -p 5435:5433 \

17

  -v $HOME/yb_docker_data/node3:/home/yugabyte/yb_data --restart unless-stopped \

18

  yugabytedb/yugabyte:latest \

19

  bin/yugabyted start --join=yugabytedb_node1 --base_dir=/home/yugabyte/yb_data --daemon=false

最后，通过转到此处的 YugabyteDB UI 来验证集群的状态：

启动 Kong 网关

要使用 Docker 在 YugabyteDB 上部署 Kong Gateway，请按照以下步骤操作。

首先，连接到 YugabyteDB 并使用您首选的 SQL 工具创建数据库：kongpsql

壳

1

psql -h 127.0.0.1 -p 5433 -U yugabyte

2

3

create database kong;

4

5

\q

接下来，开始 Kong 引导和迁移过程：

壳

1

docker run --rm --net custom-network \

2

    -e "KONG_DATABASE=postgres" \

3

    -e "KONG_PG_HOST=yugabytedb_node1" \

4

    -e "KONG_PG_PORT=5433" \

5

    -e "KONG_PG_USER=yugabyte" \

6

    -e "KONG_PG_PASSWORD=yugabyte" \

7

    kong:latest kong migrations bootstrap

• KONG_DATABASE： 设置为 ，这将指示 Kong 继续使用 PostgreSQL 实现进行元数据存储。postgres
• KONG_PG_HOST：Kong 可以与 YugabyteDB 集群中的任何节点进行交互。所选节点将路由 Kong 的请求并管理其在整个集群中的执行。

引导过程最多可能需要 5 分钟，在此期间可能没有日志输出。完成后，以下日志消息将指示快乐的结局：

壳

1

....

2

3

migrating response-ratelimiting on database 'kong'...

4

response-ratelimiting migrated up to: 000_base_response_rate_limiting (executed)

5

migrating session on database 'kong'...

6

session migrated up to: 000_base_session (executed)

7

session migrated up to: 001_add_ttl_index (executed)

8

session migrated up to: 002_320_to_330 (executed)

9

58 migrations processed

10

58 executed

11

Database is up-to-date

最后，启动 Kong Gateway 容器，该容器配置为使用 YugabyteDB 作为数据库后端：

壳

1

docker run -d --name kong-gateway \

2

    --net custom-network \

3

    -e "KONG_DATABASE=postgres" \

4

    -e "KONG_PG_HOST=yugabytedb_node1" \

5

    -e "KONG_PG_PORT=5433" \

6

    -e "KONG_PG_USER=yugabyte" \

7

    -e "KONG_PG_PASSWORD=yugabyte" \

8

    -e "KONG_PROXY_ACCESS_LOG=/dev/stdout" \

9

    -e "KONG_ADMIN_ACCESS_LOG=/dev/stdout" \

10

    -e "KONG_PROXY_ERROR_LOG=/dev/stderr" \

11

    -e "KONG_ADMIN_ERROR_LOG=/dev/stderr" \

12

    -e "KONG_ADMIN_LISTEN=0.0.0.0:8001, 0.0.0.0:8444 ssl" \

13

    -p 8000:8000 \

14

    -p 8443:8443 \

15

    -p 127.0.0.1:8001:8001 \

16

    -p 127.0.0.1:8444:8444 \

17

    kong:latest

通过向网关发送请求来测试 Kong 的操作：

壳

1

curl -i -X GET --url http://localhost:8001/services

然后，返回 YugabyteDB UI，从“数据库”菜单中选择“kong”，查看 Kong 内部使用的数十个表和索引。

工作完成！

总结

尽管 Kong 团队不再支持 Cassandra 进行分布式部署，但他们最初对 PostgreSQL 的押注随着时间的推移得到了回报。作为增长最快的数据库之一，Postgres 拥有丰富的扩展生态系统和其他产品，可以扩展其用例。Kong 用户需要一个分布式版本的 Postgres 来用于跨不同位置的 API 和服务网格，而该用例最终由 YugabyteDB 解决，YugabyteDB 是一个基于 PostgreSQL 构建的分布式数据库。