Kong Quick Start & Core Concepts (cn)

2020-07-28 9213 words 19 minutes

Contents

说明：作者Qicz将有可能随时的修订本文的内容，为了保证内容的一致性和严谨性，作者Qicz保留本文的所有权利。未经作者Qicz本人同意，不得转载或者以其他方式使用这些内容。

从技术的角度来说，Kong是什么（因为Kong也有金刚意思）? (https://docs.konghq.com/2.1.x/getting-started/introduction/)

Kong是一个运行在Nginx中的基于Lua - Nginx模块实现的Lua应用程序。Kong与OpenResty一起发布的，以此替代在Nginx中还需编译Lua - Nginx模块，OpenResty已经包含了lua- Nginx模块。OpenResty不是Nginx的一个分支，而是一组扩展其功能的模块。

Kong是一个基于云的、快速的、可伸缩的分布式微服务抽象层(也称为API网关或API中间件)。2015年作为开源项目发布，其核心价值是高性能和可扩展性。

为何选择Kong？

如果您正在为web、移动或物联网构建服务，那们您可能还需要通用功能来运行您的实际软件。Kong可以充当微服务请求的网关(或侧卡)，同时通过插件提供负载平衡、日志记录、身份验证、速率限制、转换等功能。

Kong的构建遵循以下主要原则：

高性能：亚毫秒级处理延迟，可支持关键任务用例和高吞吐量。
可扩展性：带有可插拔的体系结构，可通过Kong的Plugin SDK扩展Lua或GoLang中的Kong。
可移植性：要在每个平台，每个云上运行，并通过我们的现代Ingress Controller本地支持Kubernetes。

Features

Cloud-Native：与平台无关，Kong可以在任何平台上运行-从裸机到容器-并且可以在本机上的每个云上运行。
Kubernetes-Native：使用官方的Ingress Controller通过本地Kubernetes CRD声明性地配置Kong，以路由和连接所有L4 + L7通信。
动态负载平衡：在多个上游服务之间平衡流量。
基于哈希的负载平衡：具有一致的哈希/粘性会话的负载平衡。
断路器：智能跟踪不健康的上游服务。
**运行状况检查：**主动和被动监视上游服务。
服务发现：在第三方DNS解析器（例如Consul）中解析SRV记录。
无服务器：直接从Kong调用和保护AWS Lambda或OpenWhisk功能。
WebSockets：通过WebSockets与您的上游服务进行通信。
gRPC：与gRPC服务进行通信，并通过日志记录和可观察性插件观察流量
OAuth2.0：轻松将OAuth2.0身份验证添加到您的API。
记录：通过HTTP，TCP，UDP或磁盘记录对系统的请求和响应。
安全性：ACL，僵尸程序检测，允许/拒绝IP等…
Syslog: 系统日志记录.
SSL：为基础服务或API设置特定的SSL证书。
监视：实时监视提供关键的负载和性能服务器指标。
转发代理：使Kong连接到透明的中介HTTP代理。
认证：HMAC，JWT，Basic等。
速率限制：基于许多变量的阻止和限制请求。
转换：添加，删除或处理HTTP请求和响应。
缓存：在代理层缓存并提供响应。
CLI：从命令行控制Kong群集。
REST API：Kong可以使用其RESTful API进行操作，以实现最大的灵活性。
地理复制：跨不同区域的配置始终是最新的。
故障检测和恢复：如果您的Cassandra节点之一发生故障，则 Kong不会受到影响。
集群：所有Kong节点自动加入集群，并在各个节点之间更新其配置。
可伸缩性：Kong本质上分布，只需添加节点即可水平扩展。
性能：Kong通过扩展和使用NGINX作为核心轻松处理负载。
插件：可扩展的体系结构，用于向Kong和API添加功能。

Concepts

Services
Routes
Upstreams
Targets
Tags
Consumers
Plugins
Others
- Certificate Object
- CA Certificate Object
- SNI Object

Plugins

proxy-cache plugin (https://docs.konghq.com/hub/kong-inc/proxy-cache/)

主要参数
- config.content_type 缓存某指定的content_type类型的数据
- config.cache_ttl 缓存存活时间，默认 300秒
- config.strategy 缓存策略，社区版本只支持memory
- config.request_method 默认取值 ["GET","HEAD"]
- config.response_code 默认取值 200, 301, 404
缓存状态
- Miss: 在缓存中没有找到数据，向上游服务请求以获取数据，并缓存返回数据。
- Hit: 请求中缓存中命中数据。
- Refresh: 由于在Cache-Control行为或达到其硬编码cache_ttl阈值，因此在缓存中找到了资源，但无法满足请求。
- Bypass: 根据插件配置，缓存无法满足该请求。

Rote Limiting plugin (https://docs.konghq.com/hub/kong-inc/rate-limiting/)

主要参数
- config.policy用于检索和增加限制的速率限制策略。可用值为local（计数器将存储在本地内存中的节点上），cluster（计数器存储在数据存储区中并在节点上共享）和redis（计数器存储在Redis服务器上并在节点之间共享）。在无DB模式下，必须至少指定local或之一redis。请参阅实施注意事项，以了解有关应使用哪种策略的详细信息。
config.policy=redis

使用 config.redis* =>redis_host|redis_password|redis_database|redis_timeout
- config. second|minute|hour|day|month|year 配置对应单位时间内的请求限制数

Key Auth plugin (https://docs.konghq.com/hub/kong-inc/key-auth/)

主要参数
- config.key_names 默认名称 apikey，可以配置修改
使用步骤
- 创建 a Consumer
- 创建一个 Key
- 然后使用 Key

Load Balancing plugin (https://docs.konghq.com/getting-started-guide/2.1.x/load-balancing/)

Concepts
- Upstreams
- Targets

自定义Nginx模板并嵌入Kong (https://docs.konghq.com/2.1.x/configuration/)

$ kong start -c kong.conf --nginx-conf custom_nginx.template

术语

client: 向Kong的代理接口发起请求的下游客户端。
upstream service: Kong代理的上游服务，也就是具体的业务服务。
Service: Kong对上游服务在Kong内部的抽象。
Route: client进入Kong的入口，定义对应的匹配规则，并将匹配的路由到对应的上游服务。
Plugin: Kong“插件”，它们是在代理生命周期中运行的业务逻辑。可以通过Admin API配置插件-全局（所有传入流量）或特定的路由和服务上。

Ports

proxy：默认http端口8000，https端口8443 ，下游的服务经过此接口进入Kong。
admin：默认http端口8001，https端口8444 ，对Kong的动态配置的RestfulApi

均可通过 /etc/kong/kong.conf进行修改。

路由及其匹配

Kong支持HTTP / HTTPS，TCL / TLS和GRPC / GRPCS协议的本机代理；如前所述，这些协议中的每一个都接受一组不同的路由属性：

http: methods, hosts, headers, paths (and snis, if https)
tcp: sources, destinations (and snis, if tls)
grpc: hosts, headers, paths (and snis, if grpcs)

请注意，这三个字段都是可选字段，但必须至少指定其中一个。

一个可以被匹配的请求，需满足:

该请求必须包含所有已配置的字段。
请求中字段的值必须至少与配置的值之一匹配（虽然字段配置接受一个或多个值，但请求仅需要将其中一个值视为匹配项）。

举例说明：

1
2
3
4
5


{
    "hosts": ["example.com", "foo-service.com"],
    "paths": ["/foo", "/bar"],
    "methods": ["GET"]
}

与此路由匹配的一些可能请求如下所示:

1
2


GET /foo HTTP/1.1
Host: example.com

1
2


GET /bar HTTP/1.1
Host: foo-service.com

1
2


GET /foo/hello/world HTTP/1.1
Host: example.com

所有这三个请求都满足“路由定义”中设置的所有条件。

但是，以下请求将不符合配置的条件：

1
2


GET / HTTP/1.1
Host: example.com

路径未匹配。

1
2


POST /foo HTTP/1.1
Host: example.com

请求方法未匹配。

1
2


GET /foo HTTP/1.1
Host: foo.com

URL未匹配。

所有这三个请求仅满足两个已配置的条件。第一个请求的路径与任何已配置的都不匹配，paths第二个请求的HTTP方法与第三个请求的Host标头相同。

现在我们了解了路由属性如何协同工作，让我们分别探讨每个属性。

`preserve_host` 属性

代理时，Kong的默认行为是将上游请求的Host标头设置为Service的中指定的主机名host。该preserve_host字段接受一个布尔型标志，指示Kong不这样做。

例如，当preserve_host属性未更改且路由配置如下时：

1
2
3
4
5
6


{
    "hosts": ["service.com"],
    "service": {
        "id": "..."
    }
}

客户对Kong的可能请求可能是：

1
2


GET / HTTP/1.1
Host: service.com

Kong将从Service的host属性中提取Host标头值，并将发送以下上游请求：

1
2


GET / HTTP/1.1
Host: <my-service-host.com>

但是，通过显式配置Route preserve_host=true：

1
2
3
4
5
6
7


{
    "hosts": ["service.com"],
    "preserve_host": true,
    "service": {
        "id": "..."
    }
}

并假设来自客户端的相同请求：

1
2


GET / HTTP/1.1
Host: service.com

Kong将保留客户端请求上的主机，并改为发送以下上游请求：

1
2


GET / HTTP/1.1
Host: service.com

扩展Request headers (except Host)

从Kong 1.3.0开始，可以通过以外的其他报头来路由请求Host。

为此，可以通过headers来配置扩展的信息，如下扩展了version信息：

1
2
3
4
5
6


{
    "headers": { "version": ["v1", "v2"] },
    "service": {
        "id": "..."
    }
}

给定带有扩展header的请求，例如：

1
2


GET / HTTP/1.1
version: v1

如下的请求也将被路由到服务：

1
2


GET / HTTP/1.1
version: v2

但是，如下的请求不会路由到服务：

1
2


GET / HTTP/1.1
version: v3

注意：headers键是逻辑AND关系，其值是逻辑OR关系。

请求路径paths

路由匹配的另一种方法是通过请求路径。为了满足此路由条件，客户端请求的路径必须以paths属性值之一为前缀。

例如，使用如下配置的路由：

1
2
3


{
    "paths": ["/service", "/hello/world"]
}

以下请求将被匹配：

1
2


GET /service HTTP/1.1
Host: example.com

1
2


GET /service/resource?param=value HTTP/1.1
Host: example.com

1
2


GET /hello/world/resource HTTP/1.1
Host: anything.com

对于这些请求中的每一个，Kong都会检测到其URL路径以 paths值之一为前缀。默认情况下，Kong然后将在不更改URL路径的情况下向上游代理请求。

使用路径前缀代理时，最长的路径将首先被评估。也就是这样的两个路径：/service和/service/resource，前者并不会“覆盖”后者。

在`paths`中使用正则表达式

Kong paths通过PCRE（Perl兼容正则表达式）支持路由字段的正则表达式模式匹配。您可以同时将路径作为前缀和正则表达式分配给路由。

例如，如下的paths配置：

1
2
3


{
    "paths": ["/users/\d+/profile", "/following"]
}

下列的请求将被匹配：

1
2


GET /following HTTP/1.1
Host: ...

1
2


GET /users/123/profile HTTP/1.1
Host: ...

所提供的正则表达式使用aPCRE标志（PCRE_ANCHORED）进行评估，也就是它们将被约束为在路径的第一个匹配点（根/字符）匹配。

`strip_path` 属性

在配置路由时，指定了对应的路径前缀，但又不希望其包括在上游请求中。为此，可strip_path通过配置Route来使用boolean属性，如下所示：

1
2
3
4
5
6
7


{
    "paths": ["/service"],
    "strip_path": true,
    "service": {
        "id": "..."
    }
}

启用此标志指示Kong所匹配的路由paths信息，在代理处理时它不应该包括在上游请求的URL的URL路径的匹配部分。

例如，如下的请求：

1
2


GET /service/path/to/resource HTTP/1.1
Host: ...

Kong将发送以下上游请求：

1
2


GET /path/to/resource HTTP/1.1
Host: ...

同样，如果在已strip_path启用的Route上定义了正则表达式路径，则将剥离请求URL匹配序列的全部。例：

1
2
3
4
5
6
7


{
    "paths": ["/version/\d+/service"],
    "strip_path": true,
    "service": {
        "id": "..."
    }
}

以下HTTP请求与提供的正则表达式路径匹配：

1
2


GET /version/1/service/path/to/resource HTTP/1.1
Host: ...

Kong将在上游代理为：

1
2


GET /path/to/resource HTTP/1.1
Host: ...

匹配优先级规则

一条路线可以基于其定义匹配规则headers，hosts，paths，和methods（加snis-用于安全的路线"https"，"grpcs"，"tls"字段）。为了使Kong将传入请求匹配到Route，必须满足所有现有字段。但是，Kong允许通过使用包含相同值的字段配置两个或更多路由来提供相当大的灵活性-发生这种情况时，Kong将应用优先级规则。

规则是：在匹配评估请求时，Kong首先会尝试将规则最多的路线进行匹配。

例如，有两个路由配置如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


{
    "hosts": ["example.com"],
    "service": {
        "id": "..."
    }
},
{
    "hosts": ["example.com"],
    "methods": ["POST"],
    "service": {
        "id": "..."
    }
}

第二条路线有一个hosts字段和一个methods字段，因此它将首先由Kong进行匹配评估。这样，我们避免了针对第二个路线的第一个路线“影子”调用。

如下请求将匹配第一个路线

1
2


GET / HTTP/1.1
Host: example.com

如下请求将匹配第二个请求：

1
2


POST / HTTP/1.1
Host: example.com

按照此逻辑，如果要为第三条路线配置一个hosts字段，一个methods字段和一个uris字段，则Kong将首先对其进行评估。

如果给定请求的规则数在A和B两个路由相同，则以下所列规则将按照列出的顺序匹配。如果满足以下条件，A将优先于B：

A仅具有“普通”header配置，B并且具有一个或多个“通配符”header配置。
A 比 B有更多的非hosts的属性.
A具有至少一个“正则表达式”路径，B而只有“纯”路径。
A的更长路径比B更长的路径更长。
A.created_at < B.created_at

代理行为 (https://docs.konghq.com/2.1.x/proxy/#proxying-behavior)

配置一个备用路由 (https://docs.konghq.com/2.1.x/proxy/#configuring-a-fallback-route)

实现“后备路由”，可以避免Kong在HTTP响应404时出现“找不到路由”，我们可以捕获此类请求并将其代理到特殊的上游服务，或对其应用插件（例如，该插件可以使用其他状态代码或响应终止请求，而无需代理请求）。

一个后备路由的示例：

1
2
3
4
5
6


{
    "paths": ["/"],
    "service": {
        "id": "..."
    }
}

当向Kong发出的任何HTTP请求实际上都将与此路由匹配，因为所有URI都以根字符为前缀/。从“请求路径”部分我们知道，最长的URL路径首先由Kong评估，因此该/路径最终将最终由Kong评估，并有效地提供了“后备”路线，仅在万不得已时才进行匹配。然后，您可以将流量发送到特殊服务，或在此路线上应用您希望的任何插件。

WebSocket 代理 (https://docs.konghq.com/2.1.x/proxy/#proxy-websocket-traffic)(TODO)

负载均衡 (https://docs.konghq.com/2.1.x/loadbalancing/)

基于DNS的负载平衡

后端服务的注册是在Kong之外进行的。

Ring-balancer

算法选择: consistent-hashing, least-connections, round-robin

Blue-Green 发布 (https://docs.konghq.com/2.1.x/loadbalancing/#blue-green-deployments)

扩展: (https://blog.christianposta.com/deploy/blue-green-deployments-a-b-testing-and-canary-releases/)

使用 ring-balance，可以轻松地为服务编排蓝绿色部署。切换目标基础架构仅需要PATCH对服务的请求即可更改其host价值。

设置“Blue”环境，运行地址服务的版本1：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


# create an upstream
$ curl -X POST http://kong:8001/upstreams \
    --data "name=address.v1.service"

# add two targets to the upstream
$ curl -X POST http://kong:8001/upstreams/address.v1.service/targets \
    --data "target=192.168.34.15:80"
    --data "weight=100"
$ curl -X POST http://kong:8001/upstreams/address.v1.service/targets \
    --data "target=192.168.34.16:80"
    --data "weight=50"

# create a Service targeting the Blue upstream
$ curl -X POST http://kong:8001/services/ \
    --data "name=address-service" \
    --data "host=address.v1.service" \
    --data "path=/address"

# finally, add a Route as an entry-point into the Service
$ curl -X POST http://kong:8001/services/address-service/routes/ \
    --data "hosts[]=address.mydomain.com"

主机头设置为的请求address.mydomain.com将由Kong代理到两个已定义的目标；2 / 3的请求将去http://192.168.34.15:80/address（weight=100），和1 / 3将去http://192.168.34.16:80/address（weight=50）。

在部署地址服务的版本2之前，请设置“Green”环境：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# create a new Green upstream for address service v2
$ curl -X POST http://kong:8001/upstreams \
    --data "name=address.v2.service"

# add targets to the upstream
$ curl -X POST http://kong:8001/upstreams/address.v2.service/targets \
    --data "target=192.168.34.17:80"
    --data "weight=100"
$ curl -X POST http://kong:8001/upstreams/address.v2.service/targets \
    --data "target=192.168.34.18:80"
    --data "weight=100"

要激活Blue/Green 开关，我们现在只需要更新服务：

1
2
3


# Switch the Service from Blue to Green upstream, v1 -> v2
$ curl -X PATCH http://kong:8001/services/address-service \
    --data "host=address.v2.service"

主机头设置为的传入请求address.mydomain.com将由Kong代理到新目标；1 / 2的请求将去http://192.168.34.17:80/address（weight=100），以及其它1 / 2将去http://192.168.34.18:80/address（weight=100）。

金丝雀版本发布 (https://docs.konghq.com/2.1.x/loadbalancing/#canary-releases)

扩展: (http://blog.christianposta.com/deploy/blue-green-deployments-a-b-testing-and-canary-releases/)

使用ring-balancer，可以精确调整目标权重实现平稳，控制的金丝雀版本的发布。

一个非常简单2个目标的示例：

1
2
3
4
5
6
7
8
9


# first target at 1000
$ curl -X POST http://kong:8001/upstreams/address.v2.service/targets \
    --data "target=192.168.34.17:80"
    --data "weight=1000"

# second target at 0
$ curl -X POST http://kong:8001/upstreams/address.v2.service/targets \
    --data "target=192.168.34.18:80"
    --data "weight=0"

通过重复请求，但每次更改权重，流量将缓慢地路由到另一个目标。例如，将其设置为10％：

1
2
3
4
5
6
7
8
9


# first target at 900
$ curl -X POST http://kong:8001/upstreams/address.v2.service/targets \
    --data "target=192.168.34.17:80"
    --data "weight=900"

# second target at 100
$ curl -X POST http://kong:8001/upstreams/address.v2.service/targets \
    --data "target=192.168.34.18:80"
    --data "weight=100"

通过Kong Admin API进行的更改是动态的，将立即生效。无需重新加载或重启，也不会丢弃任何进行中的请求。

健康检查和断路器 (https://docs.konghq.com/2.1.x/health-checks-circuit-breakers/)

Upstreams上游服务

除了针对单个目标的运行状况检查功能之外，上游还具有运行状况概念。上游的运行状况取决于其目标的状态。

通过属性可以配置上游的运行状况healthchecks.threshold。这是被认为是健康的上游最小可用目标“权重”（容量）的百分比。

一个简单示例：

假设配置了的上游healthchecks.threshold=55。
它有5个目标，每个目标都有weight=100，因此ring-balancer的总权重为500。

当故障开始发生时，第一个目标的断路器跳闸。现在认为它不健康。这意味着在ring-balancer中，现在有20％的容量不正常（500权重中有100权重）。该阈值仍高于55的阈值，因此其余目标将为失败目标的流量提供服务。

当第二次失败发生时，另一个目标失败，另外100权重的服务作为不健康服务而丢失。现在，ring-balancer以其容量的60％运行，但仍在配置的阈值内。

如果我们假设这2个故障是由于系统过载而发生的，那么现在我们可以假设剩余的60％也将无法应付满负荷，并且很快第三个节点将发生故障，从而将正常容量减少到40％。此时，上游健康状况将小于其阈值，并且自身将被标记为不健康。

一旦进入不正常状态，上游只会返回错误。这可使目标/服务从遇到的级联故障中恢复。

一旦目标开始恢复并且上游的可用容量再次超过阈值，则ring-balancer 的运行状况将自动更新。

健康检查类型

主动健康检查

顾名思义，主动健康检查会主动探测其健康目标。在上游实体中启用主动健康检查后，Kong会定期向上游的每个目标处的已配置路径发出HTTP或HTTPS请求。这样，Kong可以根据探测结果自动启用和禁用平衡器中的目标。

可以针对目标健康或不健康分别配置主动健康检查的周期。如果将interval其中一个的值设置为零，则在相应的情况下将禁用检查。当两者均为零时，将完全禁用活动的健康检查。
被动健康检查（断路器）

被动健康检查（也称为断路器）是根据Kong（HTTP / HTTPS / TCP）代理的请求执行的检查，不会生成其他流量。当目标变得无响应时，被动健康检查器将检测到该目标并将其标记为不健康。ring-balancer将开始跳过此目标，因此不再有流量路由到该目标。

解决目标问题并准备再次接收流量后，Kong管理员可以通过Admin API端点手动通知运行状况检查器应再次启用目标：
1 2

$ curl -i -X POST http://localhost:8001/upstreams/my_upstream/targets/10.1.2.3:1234/healthy HTTP/1.1 204 No Content
此命令将广播整个群集的消息，以便将“健康”状态传播到整个Kong集群。这将导致Kong节点重置在Kong节点的所有工作程序中运行的运行状况检查器的运行状况计数器，从而允许环形平衡器再次将流量路由到目标。

被动运行状况检查的优点是不会产生额外的流量，但是它们无法自动将目标再次标记为运行状况良好：“电路已断开”，系统管理员需要重新启用目标。

集群 (https://docs.konghq.com/2.1.x/clustering/)

Kong群集允许您通过添加更多计算机来处理更多传入请求来水平扩展系统。它们都指向相同的数据库，因此它们将共享相同的配置。指向同一数据存储的 Kong节点将属于同一Kong集群。

您需要在Kong群集前面安装一个负载平衡器，以在可用节点之间分配流量。

多节点Kong集群

每db_update_frequency秒钟，所有运行中的Kong节点将轮询数据库是否有更新，并在必要时从其缓存中清除相关实体。

如果我们从A节点删除了一个服务，这个变化在节点B轮训数据库变化前，不会在节点B上生效。该轮询可能会在db_update_frequency几秒钟后发生（尽管可能会更快发生）。

哪些内容将被缓存?

所有核心实体（如服务，路由，插件，使用者，凭证）都由Kong缓存在内存中，并依赖于它们通过要更新的轮询机制的失效。

怎样配置数据库缓存?

您可以在Kong配置文件中配置3个属性，其中最重要的是db_update_frequency，它确定您的Kong节点在性能与一致性之间的权衡。

Kong带有为一致性而调整的默认值，以便让您尝试其群集功能同时避免“意外”。在准备生产设置时，应考虑调整这些值，以确保遵守性能约束。

db_update_frequency (默认: 5s) 这个值确定您的Kong节点将轮询数据库中的无效事件的频率。较低的值表示轮询作业将更频繁地执行，但是Kong节点将跟上您应用的更改。较高的值表示您的Kong节点将花费较少的时间来运行轮询作业，并将专注于代理您的流量。

注意：更改最多在db_update_frequency秒内在整个群集中传播。
db_update_propagation (默认: 0s) 如果数据库本身最终是一致的（即：Cassandra），则必须配置该值。这是为了确保更改有时间在数据库节点之间传播。设置后，从轮询作业接收到无效事件的Kong节点将使清除其缓存的时间延迟db_update_propagation秒。

如果连接到最终一致数据库的Kong节点没有延迟事件处理，则它可以清除其缓存，仅再次缓存未更新的值（因为更改尚未在数据库中传播）！

您应该将此值设置为数据库集群传播更改所花费的时间的估计值。

注意：设置此值后，更改将在整个db_update_frequency + db_update_propagation秒内传播。
db_cache_ttl (默认: 0s) Kong将缓存数据库实体（命中和未命中）的时间（以秒为单位）。此生存时间值可作为安全措施，以防Kong节点错过失效事件，从而避免其在陈旧数据上运行太长时间。当达到TTL时，将从其缓存中清除该值，并再次缓存下一个数据库结果（其实就是上游服务返回的结果）。

默认情况下，没有数据基于此TTL无效（默认值为0）。通常这是一个很好选择：Kong节点依赖于无效事件，这些事件在数据库存储级别（Cassandra / PosgreSQL）处理。如果您担心Kong节点可能因任何原因错过失效事件，则应设置TTL。否则，节点可能会在其缓存中以陈旧值运行不确定的时间，直到手动清除缓存或重新启动节点为止。即就是允许一定时间范围内的数据不一致性。
使用Cassandra时

如果将Cassandra用作Kong数据库，则必须设置db_update_propagation为非零值。由于Cassandra最终在本质上是一致的，因此这将确保Kong节点不会过早地使它们的缓存失效，而只是再次获取并捕获不最新的实体。如果您在使用Cassandra时未配置此值，则Kong将向您显示警告日志。

此外，您可能需要配置cassandra_consistency为QUORUM或LOCAL_QUORUM，以确保Kong节点缓存的值是数据库中的最新值。

建议不要将cassandra_refresh_frequency选项设置0为，因为需要重启Kong才能发现对Cassandra群集拓扑的任何更改。

防火墙 (https://docs.konghq.com/2.1.x/network/#firewall)

透明代理 (https://blog.stackpath.com/transparent-proxy/)

例如一个HTTP请求目的地址10.0.0.1端口80需要能跳转到127.0.0.1端口为8000。要实现这样的网络，您需要（对于Linux）将transparent侦听选项添加到Kong代理proxy_listen=8000 transparent。这使Kong可以看到请求（10.0.0.1:80）的原始目的地，即使Kong并未实际直接收听它。有了这些信息，Kong可以正确地路由请求。在transparent听取选项只能在Linux中使用。macOS / BSD允许没有transparent侦听选项的透明代理。使用Linux，您可能还需要以root用户身份启动Kong 或为可执行文件设置所需的功能。

通过systemd管理Kong

Start Kong

1

$ sudo systemctl start kong

Stop Kong

1

$ sudo systemctl stop kong

随系统一起启动

1

$ sudo systemctl enable kong

关闭随系统启动

1

$ sudo systemctl disable kong

Restart Kong

1

$ sudo systemctl restart kong

查看Kong状态

1

$ sudo systemctl status kong

通过包含的Nginx指令的文件来自定义Kong的Nginx实例 (https://docs.konghq.com/2.1.x/systemd/#customize-kongs-nginx-instance-including-files-via-the-injected-nginx-directives)

在/etc/systemd/system/kong.service文件中定义

1

Environment=KONG_NGINX_HTTP_INCLUDE=/path/to/your/my-server.kong.conf

在/etc/kong/kong.config中定义

1

nginx_http_include=/path/to/your/my-server.kong.config

插件的执行顺序

内置插件的顺序为:

Plugin	Priority
pre-function	`+inf`
zipkin	100000
ip-restriction	3000
bot-detection	2500
cors	2000
session	1900
kubernetes-sidecar-injector	1006
jwt	1005
oauth2	1004
key-auth	1003
ldap-auth	1002
basic-auth	1001
hmac-auth	1000
request-size-limiting	951
acl	950
rate-limiting	901
response-ratelimiting	900
request-transformer	801
response-transformer	800
aws-lambda	750
azure-functions	749
prometheus	13
http-log	12
statsd	11
datadog	10
file-log	9
udp-log	8
tcp-log	7
loggly	6
syslog	4
request-termination	2
correlation-id	1
post-function	-1000

重要的配置

Upstreams

healthchecks.active.healthy.interval 默认和设置为 0时，不会进行健康目标的探测。
healthchecks.active.unhealthy.interval 默认和设置为 0时，不会进行不健康目标的探测。