网关kong及其管理工具konga的初步使用小结

1、背景

当前微服务网关的技术选型不少。常见的有springcloud系的zuul1，gateway；也能够选择nginx+lua方案；或者直接使用UI集成度较高的Kong。

本文记述了如何使用docker安装kong与konga(一个开源的Kong管理UI项目)，以及它们的简单使用和一些注意事项。

2、经过docker安装kong(DB模式)与konga

2.1 经过docker安装kong(DB模式)

官方文档：https://docs.konghq.com/install/docker/

2020/07/03 kong目前的最新版本2.0.4，在作websocket转发时，与tomcat版本9.0.29有冲突，会致使websocket没法正常转发。所以这里咱们选择安装kong的一个稍微低一点的版本 2.0.0。

# 若是不指定subnet，建立的network默认使用172.17网段，可能会与实际网段发生冲突
docker network create --subnet=12.10.10.0/24 kong-net

# 拉取postgres:9.6做为kong的数据库
docker run -d --name kong-database \
               --network=kong-net \
               -p 5432:5432 \
               -e "POSTGRES_USER=kong" \
               -e "POSTGRES_DB=kong" \
               -e "POSTGRES_PASSWORD=kong" \
               postgres:9.6

# 拉取kong:2.0.0并生成初期数据
docker run --rm \
     --network=kong-net \
     -e "KONG_DATABASE=postgres" \
     -e "KONG_PG_HOST=kong-database" \
     -e "KONG_PG_USER=kong" \
     -e "KONG_PG_PASSWORD=kong" \
     -e "KONG_CASSANDRA_CONTACT_POINTS=kong-database" \
     kong:2.0.0 kong migrations bootstrap

# 启动kong
docker run -d --name kong \
     --network=kong-net \
     -e "KONG_DATABASE=postgres" \
     -e "KONG_PG_HOST=kong-database" \
     -e "KONG_PG_USER=kong" \
     -e "KONG_PG_PASSWORD=kong" \
     -e "KONG_CASSANDRA_CONTACT_POINTS=kong-database" \
     -e "KONG_PROXY_ACCESS_LOG=/dev/stdout" \
     -e "KONG_ADMIN_ACCESS_LOG=/dev/stdout" \
     -e "KONG_PROXY_ERROR_LOG=/dev/stderr" \
     -e "KONG_ADMIN_ERROR_LOG=/dev/stderr" \
     -e "KONG_ADMIN_LISTEN=0.0.0.0:8001, 0.0.0.0:8444 ssl" \
     -p 8000:8000 \
     -p 8443:8443 \
     -p 127.0.0.1:8001:8001 \
     -p 127.0.0.1:8444:8444 \
     kong:2.0.0

# 启动后在宿主机访问8000与8001端口
curl http://localhost:8000
curl http://localhost:8001

注意，kong的四个端口做用：

1. 8000与8443分别用于对http和https的代理访问；
2. 8001与8444分别是http与https的管理API访问端口，由于管理API不宜对外暴露，因此在挂载端口时，明确了127.0.0.1，即只有宿主机本地可以访问。

2.2 经过docker安装konga

konga安装直接默认最新版本(目前是0.14.9)。

# 拉取pantsel/konga，并建立数据库konga_db。
# 注意这里直接使用刚刚为了kong建立的PG数据库实例，并使用kong的DB用户，
# 注意这里postgresql链接的写法：
#  postgresql://<用户>:<密码>@<PG_Host>:<PG_Port>/<database>

docker run --rm \
 --network=kong-net \
 pantsel/konga -c prepare -a postgres -u postgresql://kong:kong@kong-database:5432/konga_db

# 启动konga
docker run -p 1337:1337 \
             --network=kong-net \
             -e "DB_ADAPTER=postgres" \
             -e "DB_HOST=kong-database" \
             -e "DB_USER=kong" \
             -e "DB_PASSWORD=kong" \
             -e "DB_DATABASE=konga_db" \
             -e "KONGA_HOOK_TIMEOUT=120000" \
             -e "NODE_ENV=production" \
             --name konga \
             pantsel/konga

konga从命令行启动后不会退出，但docker容器已经正常启动。建议后面经过 portainer来重启该容器。(portainer是一个开源的docker管理工具，自己直接拉取docker运行便可。)

3、首次访问konga并配置kong管理API链接

观察docker容器情况，确认kong-database、kong、konga三个容器所有成功启动后，访问地址：http://localhost:1337。

首次访问会让你建立konga的管理员帐户，而后登陆，而后建立到kong管理API的链接，过程以下：

1. 建立gonga管理员帐户
2. 用管理员帐户登陆
3. 建立到kong管理API的链接(链接地址:http://kong:8001/)
4. 激活该链接

注意上面第三步，建立到kong管理API的链接时，由于前面启动kong时，8001端口只挂载在 12.0.0.1:8001上，所以只有宿主机本身能够访问。这里在konga容器内访问kong时，就必须经过网络 kong-net中的容器ip或hostname访问。所以这里填写的是kong容器的name: kong，而不是宿主机IP。

4、添加路由规则

此时konga的界面仍是比较简陋的，功能也很少。dashbord只能看到一些整体的统计信息，看不到具体每一个目标服务的访问量。

若是须要添加其余功能，须要经过PLUGINS去一个一个添加，具体还没有研究。

但动态添加路由规则是彻底没有问题的。这里主要介绍如何添加路由规则。

kong添加路由规则主要分为两步：

1. 添加要访问的目标服务。
2. 在已经添加的Sevice里添加网关接收到的请求的过滤规则，即把什么样的请求转发给该Service。

4.1 添加目标服务

经过左侧导航菜单SERVICES，添加目标服务ADD NEW SERVICE，通常配置项目以下：

• Name: 一般写目标服务名。
• Protocol: http 或 https
• Host: 目标服务的Host
• Port: 目标服务的端口
• Path: 目标服务访问根路径，没有特殊状况就填写/

注意Path不要空着，没有指定Path就填上 /表示服务根目录。

其余项目通常保持默认便可。

4.2 为目标服务添加路由

经过左侧导航菜单SERVICES，点击一个目标服务，选择它的Routes，并点击ADD ROUTE，配置以下：

路由通常配置项:

• Name : 路由名称。
• 其余 : 略

路由过滤条件配置项：

• Hosts : 网关所在服务器有多个域名时，能够根据请求的域名作过滤条件；通常不填。
• Paths : 通常都是在Paths作过滤条件。Kong经过PCRE（与Perl兼容的正则表达式）支持paths字段的正则表达式模式匹配。所以能够同时使用path前缀和正则表达式匹配路由。注意每写一个Path过滤条件就要回车(必定要回车，否则konga认为你没有输入。。。)，多个Path过滤条件就写多个。
• Methods : 将HTTP methods做为过滤条件，填入POST，GET等。
• Headers : 须要经过Header信息做为过滤条件时填写。直接将header信息的属性:值填入便可，注意回车。例如:Connection: keep-alive。
• Protocols : 将协议做为过滤条件，http或https。
• 其余 : 略

注意：

1. Hosts,Paths,Methods三者最少须要配置一个。
2. 大部分状况下，咱们都是根据Path来作转发的过滤条件的，所以不一样目标系统若是某些资源访问Path相同的话，会致使不一样目标服务的路由规则冲突。

关于Path冲突，建议以下:

1. 尽可能确保不一样的目标服务具备各自统一的资源访问根目录。即每一个目标服务都有本身统一且惟一的Path前缀。如，某个目标服务的Path都是/service1/*，静态资源用/service1/static/*，API用/service1/api/*等等。
2. 没有统一访问根目录的目标服务，尽可能保证各自的路径知足不一样的正则表达式。好比Path的中间某一层统一为能识别具体服务的字符串。如，某个目标服务的Path都知足/*/service2/*，静态资源用/static/service2/*，API用/api/service2/*等等。
3. 前面两点都不能知足的话，考虑加入其余过滤条件(Hosts,Headers等)，例如，网关有多个域名，当请求用域名1访问时，路由到目标服务1，用域名2访问时，路由到目标服务2。

路由附加操做配置项：

• Strip Path : 知足条件的请求在转发给目标服务时，是否将Paths中匹配的部分从访问路径中去掉。
• 其余 : 略

5、关于websocket的转发

kong是天生支持websocket转发的，关于这一点，能够参考官网的说明：https://docs.konghq.com/2.0.x/proxy/#proxy-websocket-traffic

但当kong位于客户端与服务端之间时，kong的某些版本与服务器的版本可能会有冲突，致使websocket转发发生异常。

例如，目前kong的最新版本(2.0.4)做为网关，若是目标服务是tomcat的9.0.29版本，那么会发生如下现象:

• 客户端在试图链接websocket时，发生Error during WebSocket handshake: 'Upgrade' header is missing错误。
• 位于kong后面的服务端tomcat可以接收到转发的websocket链接请求并成功创建链接，但紧接着就会发生java.io.EOFException异常，致使链接被关闭。

具体缘由在kong的issue #5714 (https://github.com/Kong/kong/issues/5714) 中有讨论，该issue已被关闭但实际上问题并未解决。。。却是其中一个回答提到，若是将kong版本回退到2.0.0则该问题不会发生。