Kong网关初探

拼搏现实的明天。 2022-11-13 15:25 422阅读 0赞

# 安装 #

[Kong安装文档][Kong]

Kong开源版不提供dashboard支持，只有Kong企业版才有该功能。但有第三方控制台[Konga][]同样可以友好地管理Kong Admin API对象，快速安装如下：

docker run -d -p 1337:1337  \
    --name konga  \
    --network=kong-net \
    -e DB_ADAPTER=postgres   \
    -e DB_HOST=kong-database  \
    -e DB_PORT=5432  \
    -e DB_USER=kong  \
    -e DB_PASSWORD=kong  \
    -e DB_DATABASE=konga  \
    pantsel/konga

# 使用 #

需求定位是通过网关不仅实现API网关功能，也要能够替代原先Nginx。因此需要的主要功能如下：

*  服务负载均衡
 *  负载节点健康检查
 *  静态资源访问
 *  调用方认证、路由鉴权
 *  限流、IP黑白名单
 *  灰度发布
 *  监控

Kong网关的主要概念有route、service、upstream、target，其逻辑关系见下图：

![在这里插入图片描述][20210327150030517.png]

## 负载均衡 ##

当前的负载均衡逻辑为Nginx做负载均衡，服务发版时通过动态模板解析实现：Jenkins自动化脚本修改Nginx的upstream文件实现。例如对某服务的a、b两节点发版时具体逻辑如下：

1.  先修改Nginx的upstream脚本摘除该服务的a节点
2.  等待a节点无流量请求后发布重启a节点的新版本
3.  最后再修改Nginx的upstream脚本重新添加a节点
4.  接着同样的逻辑操作b节点

通过以上逻辑实现服务的无缝发版，但每次节点变动都需要reload一次Nginx。虽然现在的Nginx版本的reload已经支持配置平滑更新，但实际上reload操作依然会造成CPU竞争、Nginx性能降低以及提前关闭HTTP长连接导致部分客户端调用异常。

![在这里插入图片描述][20210327150046630.png]

为了避免以上问题，常见的解决方案如下：

1.  DNS动态解析
2.  lua脚本解析

Kong网关对以上两种方案均支持，基于这两种方案，可以对当前上述服务发版流程优化成功以下几种方式：

### 集成Kubernetes ###

集成Kubernetes，通过Kubernetes的DNS服务发现实现负载均衡。Kong网关只负责路由匹配、调用者认证、路由鉴权等网关责任，而服务注册发现的逻辑全部交由Kubernetes处理，使Kong网关完全脱离upstream的逻辑处理。

### 集成注册中心 ###

![在这里插入图片描述][20210327150059620.png]

Kong网关提供了API接口，可以通过这些开放的API接口来管理Kong内部的各个对象，例如上线/下线节点target，详见官方文档[admin-api/add-target][admin-api_add-target]。

# 节点上线
    curl -X POST http://127.0.0.1:8001/upstreams/test-upstream/targets \
    --data "target=172.17.0.1:8080" \
    --data "weight=100"
    
    # 节点下线
    curl -X POST http://127.0.0.1:8001/upstreams/test-upstream/targets \
    --data "target=172.17.0.1:8080" \
    --data "weight=0"

因此可以搭建如上图的架构方案，自行代码实现一个节点监听服务，通过对接注册中心的API来实时监听各个服务节点的状态。当某服务节点上下线后，注册中心将节点上下线事件推送给监听服务，然后监听服务通过Kong的开放API修改该节点对应的Kong中的target对象状态。

通过上述方案从而实现一个注册中心同时管理微服务之间的服务发现和网关到服务的服务发现。此时应用发布流程例如对某服务的a、b两节点发版时具体逻辑如下：

1.  请求注册中心下线该服务的a节点
2.  监听服务监听到a节点下线后自动将Kong中的a节点下线
3.  等待a节点无流量请求后发布重启a节点的新版本
4.  a节点启动成功后自动将自己重新注册到注册中心
5.  监听服务监听到a节点上线后自动将Kong中的a节点上线
6.  接着同样的逻辑操作b节点

### 自动化脚本 ###

该方案需要配合健康检查使用，具体逻辑与动态模板解析方案基本相同，仅仅是将模板修改操作替换成API请求操作。例如对某服务的a、b两节点发版时具体逻辑如下：

1.  请求Kong网关API摘除该服务的a节点
2.  等待a节点无流量请求后发布重启a节点的新版本
3.  最后再请求Kong网关API重新添加a节点
4.  接着同样的逻辑操作b节点

# 健康检查 #

Kong的upstream支持target健康检查，详细文档见[health-checks-circuit-breakers][]。

Kong支持两种健康检查方式，即可以单独使用，也可以组合使用。通过健康检查target的健康状态，被标记为不健康的target不再有请求路由到该节点。

*  主动健康检查：定时请求target的指定path，并通过响应状态码标记该target为健康/不健康
 *  被动健康检查：target的指定响应码数量超过阈值后标记该target为不健康

被动健康检查不会将不健康的target标记成功健康状态，需要人工手动标记该target为健康状态从而恢复流量路由到该目标。因此如果需要使用被动健康检查，务必与主动健康检查组合使用，通过主动健康检查自动将恢复响应的target标记为健康状态。

# 静态资源 #

Kong目前仅支持API路由，不支持静态资源映射，为了最简单地方式使Kong实现静态资源访问，可以搭建下图所示的架构。单独搭建一个Nginx服务做静态资源服务器，然后在Kong中将该Nginx服务配置成service并设置路由规则，将静态资源访问请求通过路由规则请求到该Nginx上。

![在这里插入图片描述][2021032715011984.png]

# 限流 #

Kong自带限流插件[rate-limiting][]

local function get_identifier(conf)
      local identifier
    
      if conf.limit_by == "service" then
        identifier = (kong.router.get_service() or
                      EMPTY).id
      elseif conf.limit_by == "consumer" then
        identifier = (kong.client.get_consumer() or
                      kong.client.get_credential() or
                      EMPTY).id
    
      elseif conf.limit_by == "credential" then
        identifier = (kong.client.get_credential() or
                      EMPTY).id
    
      elseif conf.limit_by == "header" then
        identifier = kong.request.get_header(conf.header_name)
    
      elseif conf.limit_by == "path" then
        local req_path = kong.request.get_path()
        if req_path == conf.path then
          identifier = req_path
        end
      end
    
      return identifier or kong.client.get_forwarded_ip()
    end

rate-limiting插件限流逻辑的对象选择[关键代码][Link 1]如上，当基于path限流时，该插件的后续处理逻辑有点反常识。正常逻辑下对指定path限流意味着path规则匹配时则限流，path不匹配时不限流，但该插件的逻辑是path规则匹配时限流，path规则不匹配时按调用方ip限流。

且该插件的path匹配规则仅支持单个完全匹配，不支持范围匹配、正则匹配等常见规则。因此如果需要基于path做限流控制，可以对官方插件稍作修改后使用。

计数模式`config.policy`支持3种策略：

*  local: 节点本地内存中计数，应用场景为单节点模式，性能影响最小
 *  redis: redis中计数，应用场景为集群模式，需要额外依赖redis服务，性能影响中
 *  cluster: 集群计数，应用场景为集群模式，不需要额外依赖服务，但性能影响最大

# 灰度发布 #

灰度发布是指通过将更改缓慢推广到一小部分用户，降低在生产环境中引入新软件版本的风险。Kong开源版官方不提供该插件，但有第三方插件支持[kong-plugins-canary][]。

支持通过ip、header、cookie、args四种匹配方案来做灰度流量控制，并支持单个、多个、正则匹配规则。

# 数据监控 #

## 启用prometheus插件 ##

首先在Kong控制台启用prometheus插件，如下图所示，直接在全局范围启用该插件，关于prometheus插件更多配置详见[官方文档][Link 2]。

![在这里插入图片描述][20210327150136730.png]

插件启动后访问KongAdmin的`/metrics`地址，如下图所示，则说明prometheus插件启动成功。

![image][]

## 安装prometheus ##

[prometheus][]

修改配置文件，将KongAdmin的访问地址添加到`targets`值域中，如下图，然后启动prometheus服务。

![image][image 1]

docker run -d \
    --name prometheus \
    --network=kong-net \
    -p 9090:9090 \
    -v /etc/prometheus/prometheus.yml:/etc/prometheus/prometheus.yml \
    prom/prometheus

访问prometheus的访问地址`http://host:9090`后，在搜索栏中输入关键字`kong`后如下图自动补全搜索关键字，则表示prometheus成功收集到了Kong的监控数据。

![image][image 2]

## 安装grafana ##

docker run -d \
    --name=grafana \
    --network=kong-net \
    -p 3000:3000 \
    grafana/grafana

访问grafana的控制台地址`http://host:3000`(默认账号密码admin:admin)，需要先关联prometheus服务。如下图，在配置栏添加prometheus数据库，并输入prometheus的服务访问地址`http://host:9090`。

![image][image 3]

![image][image 4]

![image][image 5]

prometheus数据库配置完成后，添加Kong的dashboards，直接输入模板ID`7424`或者访问  
`https://grafana.com/grafana/dashboards/7424`下载模板JSON文件后导入均可，如下图。

\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-iN2oAYaN-1616828418728)(https://img.wakzz.cn/202102/N8zKbiCnsX.png)\]

![image][image 6]

最终效果展示：

![image][image 7]

![image][image 8]

![image][image 9]

[Kong]: https://docs.konghq.com/install/docker/
[Konga]: https://github.com/pantsel/konga
[20210327150030517.png]: /images/20221022/e14c1a1131494932a3333449e9a21d2c.png
[20210327150046630.png]: https://img-blog.csdnimg.cn/20210327150046630.png
[20210327150059620.png]: https://img-blog.csdnimg.cn/20210327150059620.png
[admin-api_add-target]: https://docs.konghq.com/gateway-oss/2.3.x/admin-api/#add-target
[health-checks-circuit-breakers]: https://docs.konghq.com/gateway-oss/2.3.x/health-checks-circuit-breakers/
[2021032715011984.png]: https://img-blog.csdnimg.cn/2021032715011984.png
[rate-limiting]: https://docs.konghq.com/hub/kong-inc/rate-limiting/
[Link 1]: https://github.com/Kong/kong/blob/master/kong/plugins/rate-limiting/handler.lua
[kong-plugins-canary]: https://github.com/raoxiaoyan/kong-plugins-canary
[Link 2]: https://docs.konghq.com/hub/kong-inc/prometheus/
[20210327150136730.png]: https://img-blog.csdnimg.cn/20210327150136730.png
[image]: https://img-blog.csdnimg.cn/img_convert/7dc9f14a7def5c4eb871d9986edc88f1.png
[prometheus]: https://github.com/prometheus/prometheus
[image 1]: https://img-blog.csdnimg.cn/img_convert/8b4ce7e52e91f17b3ce9a9554a4c8946.png
[image 2]: https://img-blog.csdnimg.cn/img_convert/b1b16d6144880e341e2c59e3338c8dfb.png
[image 3]: https://img-blog.csdnimg.cn/img_convert/032857b809b8dd09018609fed1665d02.png
[image 4]: https://img-blog.csdnimg.cn/img_convert/8c5fe5a5769a1fbd3921010f66152f78.png
[image 5]: https://img-blog.csdnimg.cn/img_convert/e9abbdfbb455f44da44645f89c7fa775.png
[image 6]: https://img-blog.csdnimg.cn/img_convert/ab8bf41c9cf17a89cf61fbab8145f4ab.png
[image 7]: https://img-blog.csdnimg.cn/img_convert/2d66562723240f3b9a82ce0d6b4fd9e8.png
[image 8]: https://img-blog.csdnimg.cn/img_convert/31c43aff5ed406f7222d5d1e43c6bf04.png
[image 9]: https://img-blog.csdnimg.cn/img_convert/55b9fa8ea66adc2e4792b7145f2cd921.png