Kong

一、简介

Kong Gateway是一个轻量级、快速、灵活的云原生API网关。 API网关是一种反向代理，可让你管理、配置和将请求路由到你的 API。Kong Gateway在任何RESTful API前面运行，可以通过模块和插件进行扩展。它被设计为在分布式架构上运行，包括混合云和多云部署。

Kong Gateway是一款基于OpenResty（Nginx+Lua模块）编写的高可用、易扩展的，由Mashape公司开源的API Gateway项目。Kong是基于NGINX和Apache Cassandra或PostgreSQL构建的，能提供易于使用的RESTful API来操作和配置API管理系统，所以它可以水平扩展多个Kong服务器，通过前置的负载均衡配置把请求均匀地分发到各个Server，来应对大批量的网络请求。

Kong本身提供包括HTTP基本认证、密钥认证、CORS、TCP、UDP、文件日志、API请求限流、请求转发及Nginx监控等基本功能。整体架构图如下:

SERVICE

指管理upstream API和微服务的名称。service与下游的route相关联，匹配对应的route转发到哪个upstream。一个service可以对应多个route，service还可以添加插件功能
ROUTE

route相当于nginx配置文件中的server区域，它定义了匹配客户端请求的规则，每个匹配该路由的请求都会被代理到响应的service
CONSUMER

consumer代表一个API的消费者或用户。
PLUGINS

插件是将在HTTP请求/响应工作流程期间执行的插件配置，它是可以向在Kong后面运行的API添加功能的方式，例如身份验证或速率限制。
UPSTEARM

upstream代表一个虚拟主机名，一个upstream可以关联多个service，它会将API请求负载均衡到定义目标上。

二、功能特性

Kong Admin API

Kong Admin API为服务、路由、插件和消费者的管理和配置提供了一个RESTful接口。对网关执行的所有任务都可以使用Kong Admin API自动完成。
Kong Manager

Kong Manager是Kong Gateway的图形用户界面（GUI）。它使用Kong Admin的API来管理和控制Kong Gateway。

可以使用Kong Manager执行的一些操作:
- 创建新的路由和服务
- 只需点击几下就能激活或停用插件
- 按照要求对团队、服务、插件、消费者管理和其他所有内容进行分组
- 监控性能：使用直观的、可定制的仪表盘，可视化集群范围、工作区级别或对象级别的运行健康状况
Kong Dev Portal

Kong Dev Portal用于二次开发，生成API文档，创建自定义页面，管理API版本，并确保开发人员的访问安全。
Kong Vitals

Kong Vitals提供了关于Kong Gateway节点的健康性能的有用指标，以及关于代理API使用的指标。可以直观地监测生命体征，实时指出异常情况，并使用可视化的API分析，准确了解API和网关的性能，并访问关键的统计数据。Kong Vitals是Kong Manager用户界面的一部分。
Kong Gateway plugins

Kong Gateway插件提供先进的功能，以更好地管理API和微服务。Kong Gateway插件具有交钥匙功能，确保最大限度地控制和减少不必要的开销。通过Kong Manager或Admin API启用Kong Gateway插件，可以实现认证、速率限制和转换等功能。

三、相关组件

Kong Server

基于Nginx的服务器，用来接收API请求。

Apache Cassandra/PostgreSQL

用于存储相关数据的数据库。

Kong Manager/Konga

图形化管理工具，可以很好地通过UI观察到现在Kong的所有的配置，并且可以对于管理Kong节点情况进行查看、监控和预警。

四、访问端口

8000：侦听来自客户端的传入HTTP流量并将其转发到上游服务的端口。

8443：侦听传入HTTPS流量的端口。此端口具有与8000端口类似的行为，只是它只需要HTTPS流量。可以使用kong.conf配置文件禁用此端口。

8001：Admin API用于配置侦听的端口。

8444：Admin API侦听HTTPS流量的端口。

五、插件介绍

插件官网文档

Kong开源版本一共开放28个插件，主要分8个类型：身份认证类、安全防护类、流量控制类、云平台插件类、分析监控类、转换请求类型类、日志记录类、其他插件类，这儿介绍些常用插件。

ip restriction（黑白名单）

Kong提供的IP黑白名单控制能力还算相当强，从配置项里面可以看到主要可以针对两个维度进行配置，一个是针对所有的API接口还是针对特定的API接口，一个是针对所有的消费方还是特定的某个消费方。对于IP配置可以是一个区段，也可以是特定的IP地址。但是黑白名单不能同时配置，其次当前没有一个功能是针对某一个系统提供的所有服务都启用黑名单或白名单功能。
Oauth2（身份认证）

向API添加OAuth 2.0身份认证，OAuth2.0 协议根据使用不同的适用场景，定义了用于四种授权模式。即Authorization code（授权码模式），Implicit Grant（隐式模式），Resource Owner Password Credentials（密码模式），Client Credentials（客户端模式）。使用这个插件需要先在API上安装SSL插件，并将only_https参数设置为 "true"，如果不这样做，将导致安全漏洞。
rate limiting（限流请求）

Rate Limiting插件可以限制上游服务从API消费者接收的请求数量，或者每个用户调用API的频率。速率限制可防止API意外或恶意过度使用，速率限制在给定的秒、分钟、小时、天、月或年的时间内可以发出多少HTTP请求。如果API没有认证层，则使用Client IP地址，如果配置了认证插件，则使用Consumer。
request size limiting（请求大小限制）

阻止正文大于特定大小（以兆字节为单位）的传入请求。
request termination（请求终止）

使用指定的状态代码和消息终止传入请求。这允许（暂时）阻止API或Consumer。此插件不能触发阈值自动熔断实际意义不大，可用于发版部署的时候率先熔断服务。
Prometheus（监控）

公开与Kong和代理上游服务相关的指标
File-log/http-log（日志）

file-log插件是将请求和响应数据附加到磁盘上的日志文件，指定路径为文件全路径不是目录路径。

http-log插件是将请求和响应日志发送到HTTP服务器。
Canary（灰度发布）

通过缓慢地将更改推广到一小部分用户，降低在生产中引入新软件版本的风险。此插件还可以回滚到原来的upstream服务，或将所有流量转移到新版本

六、负载均衡原理

Kong提供了对多个后端服务进行负载平衡的多种方法：一种直接的基于DNS的方法，另一种更动态的Ring-balancer(环形均衡器)，它允许服务注册而不需要DNS服务器。

1、基于DNS的负载均衡

当使用基于DNS的负载均衡时，后端服务的注册是在Kong之外完成的，而Kong只接收来自DNS服务器的更新。

如果主机名解析为多个IP地址，每个被定义为包含主机名（而不是IP地址）的服务将自动使用基于DNS的负载平衡，前提是该主机名没有解析到upstream名称或DNS主机文件中的名称。

DNS记录的ttl设置（生存时间）决定了信息被刷新的频率。当使用ttl为0时，每个请求将使用其自己的DNS查询来解决。显然，这将有一个性能缺陷，但更新/更改的延迟将非常低。

A记录

一个A记录包含一个或多个IP地址。因此，当一个主机名解析到A记录时，每个后端服务必须有自己的IP地址。因为没有权重信息，所有条目在负载均衡器中都将被视为同等权重，并且均衡器将执行直接循环。
SRV记录

一个SRV记录包含其所有IP地址的权重和端口信息。一个后端服务可以通过IP地址和端口号的独特组合来识别。因此，单个IP地址可以在不同端口上托管同一服务的多个实例。因为权重信息可用，每个条目将在负载均衡器中获得自己的权重，并执行加权循环。同样，任何给定的端口信息将被来自DNS服务器的端口信息所覆盖。如果一个服务的属性是host=myhost.com和port=123，而myhost.com解析到127.0.0.1:456的SRV记录，那么请求将被代理到http://127.0.0.1:456/somepath，因为123端口将被456所覆盖。
DNS优先级

graph LR
    A(先前解析的最后一个成功类型) --> B(SRV记录)
    B(SRV记录) --> C(A记录)
    C(A记录) --> D(CNAME记录)

此顺序可通过dns_order配置属性进行配置。

注意事项
1. 每当DNS记录被刷新时，就会产生一个列表来正确处理权重。尽量保持权重是对方的倍数，以保持算法的性能，例如，17和31的两个权重将导致一个具有527个条目的结构，而权重16和32（或其最小的相对对应的1和2）将导致一个只有3个条目的结构，特别是在一个非常小（甚至是0）的ttl值。
2. DNS是通过UDP传输的，默认限制为512字节。如果有许多条目需要返回，DNS服务器将以部分数据进行响应，并设置一个截断标志，表明有更多的条目未发送。包括Kong在内的DNS客户端，将通过TCP进行第二次请求，以检索完整的条目列表。
3. 默认情况下，某些名称服务器不使用truncate标志响应，而是将响应修剪为低于512字节的UDP大小。如果部署的名称服务器不提供truncate标志，则上游实例池的加载可能不一致。由于名称服务器提供的信息有限，Kong节点实际上不知道某些实例。为了缓解这种情况，请使用不同的名称服务器，使用IP地址而不是名称，或者确保使用足够的Kong节点来保持所有上游服务的使用。
4. 当名称服务器返回3 name error时，这就是Kong的有效响应。如果是意外的，首先验证正在查询的名称是否正确，然后检查您的名称服务器配置。
5. 从DNS记录（A 或 SRV）中选择IP地址的初始选择不是随机的。因此，当使用ttl为0的记录时，名称服务器会随机化记录条目。

2、Ring-balancer(环形均衡器)

当使用环形均衡器时，后端服务的添加和删除将由Kong处理，不需要更新DNS。Kong将充当服务注册中心，节点可以通过一个HTTP请求被添加/删除，并将立即开始/停止接收流量。

配置环形均衡器是通过upstream和target完成的。

Upstream

每个upstream都有自己的环形均衡器。每个upstream都可以有许多target条目，被代理到 "虚拟主机名"的请求将在target上进行负载均衡。一个环形均衡器有一个最大的预定义槽位数，根据target权重分配槽位。

更改upstream本身的成本很高，例如当插槽数量发生变化时需要重建均衡器。

在均衡器中，从1到slots属性中定义的值，它们随机地分布在环上。这种随机性是为了使运行时调用环形均衡器的成本降低。在环上进行简单的轮询，可以为target提供一个分布良好的加权轮询，同时插入/删除target的操作也很方便。
Target

target是一个带有端口的IP地址/主机名，用于标识后端服务实例，每个upstream可以有许多target。

当不活跃的条目比活跃的条目多10倍时，target将被自动清理。清理将涉及重建均衡器，这比添加target条目的代价更昂贵。

target也可以为主机名。在这种情况下，名称将被解析，所有发现的条目将被单独添加到环形均衡器中。例如，添加 api.host.com:123 和 weight=100。名称“api.host.com”解析为具有 2 个 IP 地址的 A 记录。然后将两个 ip 地址添加为目标，每个得到 weight=100 和端口 123。注意：权重用于单个条目，而不是整体！

如果它解析到一个SRV记录，那么DNS记录中的端口和权重字段也会被接收，并且会推翻给定的端口123和权重=100。

均衡器将遵守DNS记录的ttl设置，并在其过期时重新查询和更新均衡器。
均衡算法

环形均衡器支持一下负载均衡算法：round-robin、consistent-hashing、least-connections，默认使用round-robin算法，该算法在target上提供了一个分布良好的加权轮询。

当使用consistent-hashing算法时，hash的输入可以是none、 consumer、ip、header、cookie，设置none是，使用轮询算法并且禁用hash。consistent-hashing算法支持主备属性，主失败了则使用备属性。属性详解如下：
- none：不使用consistent-hashing，使用round-robin（默认）
- consumer：使用消费者ID作为hash输入。如果没有可用的消费者ID，它将回退到凭据ID。
- ip：使用原始IP地址作为hash输入。使用时，请查看确定真实IP的配置设置。
- header使用一个指定的header作为hash输入。header名称在hash_on_header或hash_fallback_header中指定，这取决于header是主属性还是后备属性。
- cookie：使用指定的cookie和指定的路径作为hash输入。cookie名称在hash_on_cookie字段中指定，路径在hash_on_cookie_path字段中指定。如果指定的cookie在请求中不存在，它将由响应来设置。因此，如果cookie是主要hash机制，hash_fallback的设置是无效的。
环形均衡器还支持least-connections算法，该算法选择连接数最少的target，其权重由target的权重属性来决定。
注意事项

环形均衡器设计用于在单个节点以及集群中工作。对于加权轮询算法，没有太大区别，但是在使用基于hash算法时，重要的是所有节点都要建立完全相同的环形均衡器，以确保它们都能正常工作。

当在Kong集群中使用hash方法时，只按其IP地址添加目标实体，不要在均衡器中使用主机名，因为均衡器可能/会慢慢出现分歧。因为DNS ttl只有秒级精度，更新是由一个名字实际被请求的时间决定的。除此之外，还有一些名称服务器不返回所有条目的问题，使这个问题更加严重。

七、健康检查机制原理

Kong支持两种健康检查，可以单独使用，也可以结合使用：

主动检查：定期请求target中的特定HTTP或HTTPS端点，并根据其响应确定target的健康状况。
被动检查：也称为断路器，Kong分析正在进行的代理流量，并根据其响应请求的行为来确定target的健康状况。

1、是否健康的定义

Target

健康检查功目的是将Kong节点的target动态地标记为健康或不健康，健康信息不会在集群中同步，每个Kong节点分别确定其目标的健康状况。

主动探测（主动健康检查）或代理请求（被动健康检查）都会生成用于确定目标是否健康的数据。一个请求可能产生一个TCP错误、超时或产生一个HTTP状态代码。根据这些信息，健康检查器会更新一系列的内部计数器：
- 如果返回的状态码是配置为“健康”的状态码，它将增加target的 "成功 "计数器并清除其所有其他计数器。
- 如果连接失败，它将增加target的 "TCP失败 "计数器并清除 "成功 "计数器。
- 如果超时，它将增加target的“超时”计数器并清除“成功”计数器。
- 如果返回的状态码是配置为“不健康”的状态码，它将增加target的“HTTP失败”计数器并清除“成功”计数器。
如果任何“TCP失败”、“HTTP失败”或“超时”计数器达到其配置的阈值，目标将被标记为不健康。

如果“成功”计数器达到其配置的阈值，目标将被标记为健康。

如果upstream不健康（可用容量百分比小于配置的阈值），Kong将使用503 Service Unavailable响应对upstream的请求。

Tips：
1. 健康检查仅对活动目标进行操作，不会修改Kong数据库中target的活动状态。
2. 不健康的目标不会从负载均衡器中删除，因此在使用hash算法时不会对均衡器布局产生任何影响（它们只会被跳过）。
3. 如果对target使用主机名，请确保DNS服务器始终返回名称的完整IP地址集，并且不限制响应。如果不这样做，可能会导致健康检查不被执行。
Upstream

除了针对单个target的健康检查功能外，upstream还具有健康概念。upstream的健康状况取决于其target的状态。

upstream的健康配置通过属性healthchecks.threshold完成。这是upstream被认为是健康的最小可用target“权重”的百分比。

例如：假设upstream配置healthchecks.threshold=55，它有5个target，每个target的weight=100，所以环形均衡器的总权重是500。当第一个target的断路器跳闸，target被认定为不健康时，那么在环形均衡器中有20%的容量是不健康的。此时仍然高于配置阈值55，因此其他目标仍能提供服务。当同时有三个target故障时，环形均衡器有60%不健康的容量。此时upstream的不健康容量大于其配置的阈值，因此upstream将被标记为不健康。

一旦进入不健康的状态，upstream将只返回错误。当target开始恢复并且upstream的不健康容量小于阈值，环形均衡器的健康状态将自动更新。

2、健康检查类型

主动健康检查

当upstream启用主动健康检查时，Kong将定期向upstream每个target的配置路径发出http/https请求。这使得Kong能够根据探测结果自动启用和禁用均衡器中的target。

可以针对target健康或不健康时，单独配置主动健康检查的周期。如果任何一个的间隔值设置为零，则在相应的场景中禁用检查。当两者都为零时，将完全禁用主动运行状况检查。

Tips：

主动健康检查目前只支持HTTP/HTTPS，它们不适用于分配给协议属性设置为“tcp”或“tls”的服务
被动健康检查(断路器)

被动健康检查是对Kong代理的请求执行检查，不会产生额外的流量。当一个target变得无响应时，被动健康检查会将该target标记为不健康。环形均衡器会跳过这个目标，不会有更多的流量路由到它。

一旦target恢复了，可以接受流量了，需要手动通知健康检查器重新启用该target。此通知会将target健康状态广播到整个集群，这将导致Kong节点重置所有在运行中的健康计数器，从而允许环形均衡器重新将流量路由到target。

Tips：

被动健康检查无法自动将重新恢复的target，需要系统管理员手动启用
优缺点总结
- 主动健康检查可以在target恢复健康时，自动重新启用环形均衡器中的target。被动健康检查则不能。
- 被动健康检查不会对target产生额外的流量。主动健康检查则会。
- 主动健康检查器要求在target中配置一个具有可靠状态响应的已知URL作为探测端点，被动健康检查不需要这种配置。
- 通过为主动健康检查器提供一个自定义探针端点，一个应用程序可以确定其自身的健康指标，并产生一个状态码供Kong使用。即使target继续为被动健康检查器看起来健康的流量提供服务，它也能够以故障状态响应主动探测，本质上是请求从接收新流量中解脱出来。
可以将两种模式结合起来。可以启用被动健康检查，仅根据其流量监测目标的健康状况，只在目标不健康时使用主动健康检查，以便自动重新启用它。

八、安装部署

环境规划

PostgreSQL、Konga、Nginx	10.81.0.101
Kong Server	10.81.0.102
Kong Server	10.81.0.103
Kong Server	10.81.0.104

1、PostgreSQL安装

konga软件对高版本postgresql不兼容

安装软件

yum -y install gcc* readline-devel wget zlib zlib-devel
cd /usr/local/src && wget --no-check-certificate https://ftp.postgresql.org/pub/source/v9.6.9/postgresql-9.6.9.tar.gz
tar zxf postgresql-9.6.9.tar.gz
mkdir -p /data/svc
cd postgresql-9.6.9 && ./configure --prefix=/data/svc/pgsql
gmake && gmake install

vim /etc/profile
export PGHOME="/data/svc/pgsql"
export PATH="$PATH:${PGHOME}/bin"

source /etc/profile

创建用户和数据目录并授权

groupadd postgres
useradd -g postgres postgres
mkdir -p /data/svc/pgsql/data
touch /data/svc/pgsql/.pgsql_history
chown -R postgres. /data/svc/pgsql

初始化数据库

su - postgres
initdb -D /data/svc/pgsql/data

设置systemd管理

cp /usr/local/src/postgresql-9.6.9/contrib/start-scripts/linux /etc/init.d/postgresql
chmod a+x /etc/init.d/postgresql

vim /etc/init.d/postgresql
prefix=/data/svc/pgsql
PGDATA="/data/svc/pgsql/data"

systemctl daemon-reload
systemctl start postgresql
systemctl enable postgresql

创建数据库、用户并授权

psql -U postgres
postgres=# alter user postgres with password 'Postgresql123';
postgres=# create user kong with password 'kong123';
postgres=# create database kong owner kong;
postgres=# grant all on database kong to kong;
postgres=# \l
postgres=# \q

修改客户端认证配置文件

vim /data/svc/pgsql/data/pg_hba.conf
# "local" is for Unix domain socket connections only
local   all             all                                     password
# IPv4 local connections:
host    all             all             127.0.0.1/32            password
host    all             all             0.0.0.0/0               password
# IPv6 local connections:
host    all             all             ::1/128                 password

vim /data/svc/pgsql/data/postgresql.conf
listen_addresses = '10.81.0.101'
max_connections = 1024

systemctl restart postgresql

2、Kong安装

安装软件

cd /usr/local/src && wget --no-check-certificate https://download.konghq.com/gateway-2.x-centos-7/Packages/k/kong-2.8.1.el7.amd64.rpm
yum -y localinstall kong-2.8.1.el7.amd64.rpm

修改配置文件

cp -rp /etc/kong/kong.conf.default /etc/kong/kong.conf

vim /etc/kong/kong.conf
real_ip_header = X-Forwarded-For
real_ip_recursive = on
plugins = bundled
admin_listen = 0.0.0.0:8001, 0.0.0.0:8444 ssl, 127.0.0.1:8001, 127.0.0.1:8444 ssl
log_level = debug
pg_host = 10.81.0.101
pg_port = 5432
pg_user = kong
pg_password = kong123
pg_database = kong
nginx_proxy_set=$trace_id ''
nginx_http_log_format=basic '{"remote_addr":"$remote_addr","x_real_ip":"$http_x_real_ip","x_forwarded_for":"$http_x_forwarded_for","time_local":"$time_local","request_method":"$request_method","server_protocol":"$server_protocol","ssl_protocol":"$ssl_protocol","request_length":"$request_length","request_time":"$request_time","status":"$status","body_bytes_sent":"$body_bytes_sent","upstream_addr":"$upstream_addr","upstream_status":"$upstream_status","upstream_response_time":"$upstream_response_time","http_host":"$http_host","request_uri":"$uri","http_referer":"$http_referer","http_user_agent":"$http_user_agent","ng_server":"kong","request_id":"$request_id","trace_id":"$trace_id","grayscale":"$http_grayHeaderSign"}'

初始化数据库

kong migrations bootstrap -c /etc/kong/kong.conf

启动服务

systemctl start kong
systemctl enable kong

测试是否正常
```
curl '127.0.0.1:8001'
```

3、安装插件

上传插件包

解压到插件目录下

unzip -q canary-plugins.zip -d /usr/local/share/lua/5.1/kong/plugins/
unzip -q skywalking-plugins.zip -d /usr/local/share/lua/5.1/kong/plugins/
chown -R kong. /usr/local/share/lua/5.1/kong/plugins/
\mv nginx_kong.lua /usr/local/share/lua/5.1/kong/templates/
chown -R kong. /usr/local/share/lua/5.1/kong/templates/

安装依赖包

luarocks install lua-resty-http
luarocks install lua-resty-jit-uuid
luarocks install skywalking-nginx-lua
luarocks install lua-resty-iputils

修改kong配置文件并重启

vim /etc/kong/kong.conf
plugins = bundled,skywalking,canary
lua_package_path = /usr/local/?.lua;;

systemctl restart kong

4、设置负载均衡

upstream kongservice {
  server 10.81.0.101:8000 weight=4 max_fails=2 fail_timeout=30s;
  server 10.81.0.102:8000 weight=4 max_fails=2 fail_timeout=30s;
  server 10.81.0.103:8000 weight=4 max_fails=2 fail_timeout=30s;
  keepalive 256;
}
server {
  listen          80;
  server_name    ~^(.*)$;
  charset utf-8;
  return 301 https://$host$request_uri;
}

server {
  listen          443 ssl;
  server_name    ~^(.*)$;
  charset utf-8;
  ssl_certificate /data/svc/nginx-1.16.1/certs/eminxing-com.crt;
  ssl_certificate_key /data/svc/nginx-1.16.1/certs/eminxing-com.key;
  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
  ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4:!DH:!DHE;
  ssl_prefer_server_ciphers on;
  access_log   /data/logs/nginx/elk-nginx-log/kong.access.log nginx-json-log;
  error_log   /data/logs/nginx/elk-nginx-log/kong.error.log;
  client_max_body_size    300m;
  client_body_buffer_size 128k;
  location / {
    proxy_pass http://kongservice/;
    proxy_next_upstream http_502 http_504 error  timeout invalid_header;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header $http_x_forwarded_for $remote_addr;
    proxy_http_version 1.1;
    proxy_set_header Connection "";
    proxy_connect_timeout  1800;
    proxy_send_timeout     1800;
    proxy_read_timeout     1800;
    proxy_buffer_size      4k;
    proxy_buffers          4 32k;
    proxy_busy_buffers_size 64k;
    proxy_temp_file_write_size 64k;
  } 
  location ^~ /WEB-INF{
    deny all;
  }
}

upstream kongadmin_service {
  server 10.81.0.101:8001 weight=4 max_fails=2 fail_timeout=30s;
  server 10.81.0.102:8001 weight=4 max_fails=2 fail_timeout=30s;
  server 10.81.0.103:8001 weight=4 max_fails=2 fail_timeout=30s;
}
server {
  listen          80;
  server_name    kong-admin.eminxing.com;
  charset utf-8;
  access_log   /data/logs/nginx/elk-nginx-log/kongadmin.access.log nginx-json-log;
  error_log   /data/logs/nginx/elk-nginx-log/kongadmin.error.log;
  client_max_body_size    10m;
  client_body_buffer_size 128k;  
  location / {
    proxy_pass http://kongadmin_service/;
    proxy_next_upstream http_502 http_504 error  timeout invalid_header;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header $http_x_forwarded_for $remote_addr;
    proxy_connect_timeout  1800;
    proxy_send_timeout     1800;
    proxy_read_timeout     1800;
    proxy_buffer_size      4k;
    proxy_buffers          4 32k;
    proxy_busy_buffers_size 64k;
    proxy_temp_file_write_size 64k;
  }
}

server {
  listen          443 ssl;
  server_name    kong-admin.eminxing.com;
  charset utf-8;
  ssl_certificate /data/svc/nginx-1.16.1/certs/eminxing-com.crt;
  ssl_certificate_key /data/svc/nginx-1.16.1/certs/eminxing-com.key;
  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
  ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4:!DH:!DHE;
  ssl_prefer_server_ciphers on;
  access_log   /data/logs/nginx/elk-nginx-log/kongadmin.access.log nginx-json-log;
  error_log   /data/logs/nginx/elk-nginx-log/kongadmin.error.log;
  client_max_body_size    10m;
  client_body_buffer_size 128k;
  location / {
    proxy_pass http://kongadmin_service/;
    proxy_next_upstream http_502 http_504 error  timeout invalid_header;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header $http_x_forwarded_for $remote_addr;
    proxy_connect_timeout  1800;
    proxy_send_timeout     1800;
    proxy_read_timeout     1800;
    proxy_buffer_size      4k;
    proxy_buffers          4 32k;
    proxy_busy_buffers_size 64k;
    proxy_temp_file_write_size 64k;
  }
}

九、Konga管理界面

1、安装

安装nodejs

cd /usr/local/src/ && wget https://registry.npmmirror.com/-/binary/node/v12.16.0/node-v12.16.0-linux-x64.tar.gz
tar zxf node-v12.16.0-linux-x64.tar.gz -C /usr/local/
cd .. && mv node-v12.16.0-linux-x64/ node
chown -R root. node/
vim /etc/profile
export NODE_HOME="/usr/local/node"
export PATH="$NODE_HOME/bin:$PATH"
source /etc/profile
node -v
npm -v

下载软件

git clone https://github.com/pantsel/konga.git
cd konga && npm i --unsafe-perm=true --allow-root

创建数据库、用户并授权

psql -U postgres
postgres=# create user konga with password 'konga123';
postgres=# create database konga owner konga;
postgres=# grant all on database konga to konga;

修改配置文件

cat > .env <<'EOF'
HOST=0.0.0.0
PORT=1337
NODE_ENV=production
KONGA_HOOK_TIMEOUT=120000
DB_ADAPTER=postgres
DB_URI=postgresql://konga:[email protected]:5432/konga
KONGA_LOG_LEVEL=warn
TOKEN_SECRET=some_secret_token
EOF

初始化数据库

node ./bin/konga.js prepare --adapter postgres --uri postgresql://konga:[email protected]:5432/konga

设置systemd管理

cp /usr/local/node/bin/node /usr/bin
cat >/etc/systemd/system/konga.service <<'EOF'
[Unit]
Description=konga service
After=network.target

[Service]
User=root
Type=simple
WorkingDirectory=/usr/local/konga
ExecStart=/usr/local/node/bin/npm run production
ExecStop=/usr/bin/kill $MAINPID
Restart=on-failure

[Install]
WantedBy=multi-user.target
EOF
systemctl daemon-reload
systemctl start konga
systemctl enable konga

设置反向代理

upstream konga_service {
  server 10.81.0.103:1337 max_fails=2 fail_timeout=30s;
}
server {
  listen          80;
  server_name    konga.eminxing.com;
  charset utf-8;
  return 301 https://$host$request_uri;
}

server {
  listen        443 ssl;
  server_name    konga.eminxing.com;
  charset utf-8;
  ssl_certificate /data/svc/nginx-1.16.1/certs/eminxing-com.crt;
  ssl_certificate_key /data/svc/nginx-1.16.1/certs/eminxing-com.key;
  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
  ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4:!DH:!DHE;
  ssl_prefer_server_ciphers on;
  access_log   /data/logs/nginx/elk-nginx-log/konga.access.log nginx-json-log;
  error_log   /data/logs/nginx/elk-nginx-log/konga.error.log; 
  location / {
        proxy_pass http://konga_service/;
        proxy_next_upstream http_502 http_504 error  timeout invalid_header;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header $http_x_forwarded_for $remote_addr;
        client_max_body_size    10m;
        client_body_buffer_size 128k;
        proxy_connect_timeout  1800;
        proxy_send_timeout     1800;
        proxy_read_timeout     1800;
        proxy_buffer_size      4k;
        proxy_buffers          4 32k;
        proxy_busy_buffers_size 64k;
        proxy_temp_file_write_size 64k;
  } 
}

2、使用

创建管理员用户
连接kong-admin
查看节点信息
添加插件
创建services
创建路由
创建upstream

Kong

一、简介

二、功能特性

三、相关组件

四、访问端口

五、插件介绍

六、负载均衡原理

1、基于DNS的负载均衡

2、Ring-balancer(环形均衡器)

七、健康检查机制原理

1、是否健康的定义

2、健康检查类型

八、安装部署

1、PostgreSQL安装

2、Kong安装

3、安装插件

4、设置负载均衡

九、Konga管理界面

1、安装

2、使用

你可能感兴趣的:(Kong)