Kong集群向导
简介
Kong集群允许用户横向扩展系统,添加更多机器来处理更多请求,因为它们指向同一个数据库,所有它们之间共享相同的配置,指向同一个数据仓库的Kong节点会成为同一个Kong集群的一部分
用户需要在Kong集群前配置负载均衡器,以便在节点之间分配流量
Kong集群可以做什么,不可以做什么
拥有一个Kong集群并不意味着客户端的流量会被自动负载均衡到各个Kong节点,用户需要在Kong节点前配置负载均衡器分配流量,Kong集群仅意味着这些节点将共享相同的配置
出于性能原因,Kong在代理请求时避免数据库连接,它将数据库的内容缓存在内存中,缓存的实体包括服务、路由、消费者、插件、凭证等等,由于这些值都存在内存中,所以通过 Admin API 修改一个节点后,需要将修改传播到其他节点
这篇文档描述了这些缓存实体如何失效,并且如何配置Kong节点,以兼顾性能和一致性
单节点Kong集群
连接到数据库(Cassandra 或 PostgreSQL)的单个Kong节点是一个单节点的Kong集群,通过 Admin API 附加到这个节点上的更改都会立即生效,比如,对于单节点Kong集群A,如果用户删除一个已注册的服务:
curl -X DELETE http://127.0.0.1:8001/services/test-service
然后任何对A节点的后续请求都会立即返回 404 Not Found
,因为节点已将其从本地缓存中清除:
curl -i http://127.0.0.1:8000/test-service
多节点Kong集群
在有多个节点的Kong集群中,连接到同一数据库的其他节点不会立即被通知A节点删除了服务,虽然服务不再存在于数据库中(已被节点A删除),但它仍然存在于B节点的内存中,所有节点定期执行后台任务同步其他节点可能触发的更改,可以通过配置这个参数修改同步的频率:
- db_update_frequency(默认5秒)
当过了指定时间后,运行中的Kong节点会轮询数据库的最新数据,并对缓存中的数据进行更新,如果用户在A节点删除了服务,B节点在进行下一次数据库轮询前不会马上生效,最终Kong集群会保持一致
缓存的内容
所有的核心如服务、路由、插件、消费者、凭证等都由Kong缓存在内存中,并通过轮询机制进行更新,此外,Kong还会缓存数据库缺失的信息,这意味着如果用户配置了一个没有插件的服务,Kong也会缓存下来:
在A节点上,我们添加一个服务和一个路由:
# A节点
curl -X POST http://127.0.0.1:8001/services --data "name=example-service" --data "url=http://example.com"
curl -X POST http://127.0.0.1:8001/services/example-service/routes --data "paths[]=/example"
可以发现A、B节点都缓存了这个服务,并且都没有配置插件的记录:
# A节点
curl http://127.0.0.1:8000/example
HTTP 200 OK
# B节点
curl http://127.0.0.2:8000/example
HTTP 200 OK
现在,假设我们通过A节点的 Admin API 为此服务添加一个插件:
# A节点
curl -X POST http://127.0.0.1:8001/services/example-service/plugins --data "name=example-plugin"
由于此请求是通过A节点的 Admin API 发出的,所以A节点本地之前的缓存已经失效了,在后续的请求中,它会检测到此API已经配置了插件,但是B节点尚未进行数据库轮询,缓存中的API仍然不包含插件
结论:所有的 CRUD 操作都会使之前的缓存失效
如何配置数据库缓存
用户可以在Kong的配置文件中配置三个属性,其中最重要的一个是 db_update_frequency
,它可以权衡Kong节点的一致性和性能,Kong提供了一致性的默认值,以便用户在使用集群的时候不至于感到特别意外,在投入生产后,用户应该考虑调整这些值以确保性能可靠
1. db_update_frequency(默认5秒)
这个值确定了Kong节点轮询数据库的频率,值越小表示轮询作业执行得越频繁,Kong节点会尽快更新最新配置;值越大Kong节点会花较少的时间执行轮询作业,并专注于代理客户端流量
2. db_update_propagation(默认0秒)
如果用户的数据库本身最终是需要一致的(即:Cassandra),则必须配置这个值,这是为了确保变更有时间在数据库节点间传播,当设置这个值后,Kong节点在执行轮询作业前,会延时 db_update_propagation
秒
用户应该将这个值设置为数据库集群同步数据所用时间的预估值
注意:设置此值后,更改传播到整个集群需要 db_update_frequency + db_update_propagation
秒
3. db_cache_ttl(默认0秒)
Kong会缓存数据库中的内容一段时间,当设置了TTL时,Kong会从缓存中清除该值,直到下一次从数据库读取数据
默认情况下,这个值默认值为0,这通常运行的很好,Kong节点依赖数据源的更改(Cassandra/PosgreSQL),如果用户担心Kong节点会因其他任何原因错过更新事件,则应设置TTL,否则节点可能会使用过期值运行一段时间,直到手动清除缓存或重新启动节点
4. 使用Cassandra
如果用户使用 Cassandra 作为数据源,那么必须设置 db_update_propagation 为正数,因为 Cassandra 集群各节点的数据最终会同步,这样可以保证Kong节点不会拿到一个还未来得及更新的值,如果用户没有配置这个值,Kong会显示给用户一个告警日志
此外,用户可能希望将 cassandra_consistency
配置为 QUORUM
或 LOCAL_QUORUM
,以确保Kong节点缓存的值是数据库中的最新值
通过Admin API与缓存交互
有些情况下,用户希望查询缓存的值,或者手动更改缓存值,可以通过 Admin API 的 /cache
端点来操作
检查缓存的值
- 端点
GET /cache/{cache_key}
- 响应
如果key值对应的值有缓存:
HTTP 200 OK ... { ... }
如果没有缓存:
HTTP 404 Not Found
注意:Kong现在尚未提供检索每个实体哪些 cache_key
被缓存的接口,之后的版本会提供
清除缓存的值
- 端点
DELETE /cache/{cache_key}
- 响应
HTTP 204 No Content ...
清除节点的缓存
- 端点
DELETE /cache
- 响应
HTTP 204 No Content
注意:在已经运行的生产节点上慎用这条命令,如果该节点正在接收大量请求,同时清除其缓存会触发对数据库的大量请求,并可能造成缓存雪崩效应