在学习 Kong 之前,我们有必要先了解下它的基础对象,这样有助于我们了解 Kong 在运行时的内部运行机制和结构关系。
Kong 的基础对象主要是分为以下 8 大类:
- 路由
- 服务
- 上游
- 目标
- 消费者
- 插件
- 证书
- SNI
下面我们就详细介绍一下这些组件。
路由 (route)
路由就是客户端请求到服务的匹配规则,它是请求入口,支持精确匹配、模糊匹配以及正则匹配,后面我们会一一演示。
路由与服务的关系都是多对一的,也就是说,每个服务可以对应一个或多个与之相关联的路由。每个路由都将被代理到对应的服务。
需注意,每条规则都至少需要一个匹配规则和协议,而不同的协议,也有一些必须要设置的属性。
- HTTP:methods、hosts、headers/paths
- HTTPS:methods、hosts、headers、paths/snis
- TCP:sources/destinations
- TLS:sources、destinations/snis
- GRPC:hosts、headers/paths
- GRPCS:hosts、headers、paths/snis
上面简单介绍了下配置对应协议的时候,都必须要设置的值,下面就看下路由的所有属性有哪些:
名称 | 描述 |
---|---|
name | 路由名称,不填写则 Kong 自动生成。 |
protocols | 允许的协议列表,默认值:http、https,若仅设置为 https,则 http 请求将升级为 https。 |
methods | http 方法列表,例如:GET、POST、PUT、DELETE 等。 |
hosts | 域名列表,支持精确匹配域名及泛域名。 |
paths | 路径列表,支持精确前缀匹配及正则匹配。 |
headers | 请求头列表。 |
https_redirect_status_code | 若匹配到路由的所有属性,但请求的协议是 http,则该 http 状态码响应为指定值,并且可将 http 强行切换成 https。默认值:426。 |
regex_priority | 优先级,若路由属性匹配相同,则根据优先级高低匹配。若优先级也相同则按照路由创建时间选择。默认值:0。 |
strip_path | 当请求匹配到此路由中的某一条时,则先从请求的URL中删除此路径前缀,再将请求转发至上游服务。默认值:true。 |
preserve_host | 当请求匹配到路由中的域名时,则在请求头中使用此域名,如果将该值设置为false,则请求头中的域名为上游服务的域名。 |
snis | 使用流路由时,与此路由相匹配的SNI列表。 |
sources | 使用流路由时,与此路由相匹配的传入连接的IP源地址列表。 |
destinations | 使用流路由时,与此路由相匹配的请求连接的IP目的地址列表。 |
tags | 与路由关联的一组可选字符串,用于分组和过滤。即标签。 |
service | 路由所关联的服务。 |
服务 (service)
服务是用户管理上游微服务的入口,用于将对应的请求流量,分发给对应的上游服务器。
客户端会先请求路由,若匹配成功,则 Kong 将请求,代理到该路由相关联的服务上。
名称 | 描述 |
---|---|
name | 服务名称,不填写则 Kong 自动生成。 |
retries | 代理失败后重试的次数,默认值:5。 |
protocol | 与上游服务通信的协议,默认值:http。 |
host | 上游服务的名称或域名。 |
port | 上游服务的端口号,默认值:80。 |
path | 请求到上游服务之间要附加使用的路径。 |
connect_timeout | 从请求到上游服务建立连接的超时时间,默认为 60000 毫秒。 |
write_timeout | 将请求发送到上游服务的超时时间,默认为 60000 毫秒 |
read_timeout | 从上游服务接收数据的超时时间,默认为 60000 毫秒 |
tags | 与服务关联的一组可选字符串,用于分组和过滤。即标签。 |
client_certificate | 在与上游服务进行TLS握手时,所使用的客户端证书。 |
url | 简写属性,一次性设置 protocol、host、port 和 path。 |
上游 (upstream)
上游服务可以表示为一个虚拟的服务,我们可以对上游服务配置多个目标节点进行负载均衡及健康检查。
健康检查有主动和被动两种模式,当检查到不健康的目标节点的时候,则将该目标节点禁用,使其不参与负载,也可以将已经处理好的目标节点加入到负载中。
名称 | 描述 |
---|---|
name | 这是主机名,必须等于Service的host。 |
algorithm | 使用的负载均衡算法。可接受值:consistent-hashing(一致性散列)、least-connections(最少连接)、round-robin(轮询),默认值:round-robin。 |
hash_on | 什么用hash输入:none(导致加权循环方案没有hash),consumer,ip,header或cookie。默认为 “none”。 |
hash_fallback | 如果主hash_on没有返回hash(例如。header丢失,或没有consumer识别).consumer,ip,header或cookie其中之一。如果hash_on设置为cookie,则不可用。默认为 “none”。 |
hash_on_header | header名称,用于将值作为hash输入。仅在hash_on设置为标头时才需要。 |
hash_fallback_header | 标头名称,用于将值作为hash输入。仅在hash_fallback设置为header时才需要。 |
hash_on_cookie | cookie名称从哈希输入中获取值。仅当hash_on或hash_fallback设置为cookie时才需要。如果指定的cookie不在请求中,Kong将生成一个值并在响应中设置cookie。 |
hash_on_cookie_path | 要在响应标头中设置的cookie路径。仅当hash_on或hash_fallback设置为cookie时才需要。默认为 “/”。 |
slots | 负载均衡器算法中的插槽数(10-65536)。默认为10000。 |
healthchecks.active.https_verify_certificate | 使用HTTPS执行活动运行状况检查时是否检查远程主机的SSL证书的有效性。默认为true。 |
healthchecks.active.unhealthy.http_statuses | 一组HTTP状态,用于在活动运行状况检查中由探测器返回时考虑失败,指示不健康。默认[429, 404, 500, 501, 502, 503, 504, 505] , 用 form-encoded 的时候,参数http_statuses[]=429&http_statuses[]=404;使用JSON,参数使用数组即可 |
healthchecks.active.unhealthy.tcp_failures | 活动探测器中用于考虑目标不健康的TCP故障数。默认为0。 |
healthchecks.active.unhealthy.timeouts | 活动探测器中用于考虑目标不健康的超时次数。默认为0。 |
healthchecks.active.unhealthy.http_failures | 活动探测器中的HTTP故障数(由healthchecks.active.unhealthy.http_statuses定义)以考虑目标运行状况不佳。默认为0。 |
healthchecks.active.unhealthy.interval | 不健康目标的活动健康检查之间的间隔(以秒为单位)。值为零表示不应执行不健康目标的活动探测。默认为0。 |
healthchecks.active.http_path | 在GET HTTP请求中使用的路径,作为活动运行状况检查的探测运行。默认为 “/”。 |
healthchecks.active.timeout | 活动运行状况检查的套接字超时(以秒为单位)。默认为1。 |
healthchecks.active.healthy.http_statuses | 一组HTTP状态,用于在主动健康检查中由探针返回时考虑成功,指示健康状况。默认[200, 302] 。使用 form-encoded 参数为http_statuses[]=200&http_statuses[]=302 ; 使用JSON,参数使用数组即可。 |
healthchecks.active.healthy.interval | 健康目标的主动健康检查之间的间隔(以秒为单位)。值为零表示不应执行健康目标的活动探测。默认为0。 |
healthchecks.active.healthy.successes | 活动探针中的成功次数(由healthchecks.active.healthy.http_statuses定义)以考虑目标健康。默认为0。 |
healthchecks.active.https_sni | 使用HTTPS执行主动健康检查时用作SNI(服务器名称标识)的主机名。当使用IP配置目标时,这尤其有用,因此可以使用正确的SNI验证目标主机的证书。 |
healthchecks.active.concurrency | 在活动主动健康检查中同时检查的目标数。默认为10。 |
healthchecks.active.type | 是使用HTTP还是HTTPS执行活动运行状况检查,还是仅尝试TCP连接。可能的值为tcp,http或https。默认为 “http”。 |
healthchecks.passive.unhealthy.http_failures | 代理流量,(由healthchecks.passive.unhealthy.http_statuses 定义),中的HTTP故障数,以考虑目标不健康,如被动运行状况检查所观察到的那样。默认为0. |
healthchecks.passive.unhealthy.http_statuses | 当被动健康检查的探针返回值是 http 状态数组中的某一个值时,代表不健康的状态是由代理流量产生的。默认值:[429, 500, 503] |
healthchecks.passive.unhealthy.tcp_failures | 通过被动运行状况检查观察到的代理流量中考虑目标不健康的TCP故障数。默认为0。 |
healthchecks.passive.unhealthy.timeouts | 通过被动运行状况检查观察到的代理流量中考虑目标不健康的超时次数。默认为0。 |
healthchecks.passive.type | 是否执行解释 HTTP/HTTPS 状态的被动运行状况检查,或仅检查TCP连接是否成功。可能的值是tcp,http或https(在被动检查中,http和https选项是等效的。)。默认为 “http”。 |
healthchecks.passive.healthy.successes | 代理流量的成功次数(由healthchecks.passive.healthy.http_statuses定义)以考虑目标健康,如被动健康检查所观察到的那样。默认为0。 |
healthchecks.passive.healthy.http_statuses | 一组HTTP状态,表示由代理流量生成的健康状况,如被动健康检查所观察到的那样。默认[200, 201, 202, 203, 204, 205, 206, 207, 208, 226, 300, 301, 302, 303, 304, 305, 306, 307, 308],使用 form-encoded,参数为http_statuses[]=200&http_statuses[]=201 ,使用 JSON,参数为数组即可。 |
host_header | 通过 Kong 代理请求时,主机头所使用的名称 |
tags | 与上游关联的一组可选字符串,用于分组和过滤。即标签。 |
目标 (target)
目标节点代表一个真实的物理服务,通常为IP地址和端口的组合,每个目标节点都是上游服务的一个具体的节点实例,上游服务与目标节点则是一对多的对应关系。在运行过程中,可动态的添加或者删除目标节点。
此外,每个目标节点还可以设置权重,接收不同比例的请求流量。
名称 | 描述 |
---|---|
target | 目标地址(IP地址或主机名)和端口。 |
weight | 权重,0 ~ 1000。默认值:100。 |
tags | 与目标关联的一组可选字符串,用于分组和过滤。即标签。 |
消费者 (consumer)
消费者代表一个具体的用户,是客户端请求的发起者。消费者ID可以作为主要的数据存储,可以与业务数据库的用户信息进行映射、关联。并为身份授权和鉴权功能提供更多的策略。
名称 | 描述 |
---|---|
username | 唯一用户名。 |
custom_id | 存储实际业务消费者的唯一标识,包括但不限于:用户名、ID等。 |
tags | 与消费者关联的一组可选字符串,用于分组和过滤。即标签。 |
插件 (plugins)
有的时候,我们会需要在请求或者响应的生命周期中,去执行一些钩子动作。那么在 Kong 中,我们就可以使用插件的机制来在我们的路由和服务上添加、配置和扩展自定义功能,例如第三方的身份验证、限频以及其他的定制化需求。
在向服务或者路由添加了插件后,则客户端请求这个服务的时候,都会先去执行插件。
同时插件也是支持应用于某些特定的消费者,以及可以配置为全局插件。
对于每个请求,配置的插件只能运行一次。
同时我们还可以为插件配置外部参数,比如使用各种自定义参数集合或者 Kong 内置的上下文参数(如:服务、路由、消费者等)。
目前 Kong 已经为我们提供很多内置的插件,当然有一些是只能在商业版中才可以使用的,但是社区版中的插件,基本能满足我们的需求,如果有定制化的需求,自己扩展一个插件即可,Kong 的插件开发,在 2.0 版本已经支持了 Go,2.3 及以上版本已经开始支持 Python 和 JS了,相信后面会支持越来越多的开发语言。
如果将插件应用到不同配置的不同对象中,则其优先级顺序规则为:插件配置的对象越多、越具体,优先级就越高。
下面我们就来说下它的插件运行顺序的优先级,依次为优先级从高到低。需注意,涉及到消费者的都是需要通过身份认证的:
- 路由、服务、消费者
- 路由、消费者
- 服务、消费者
- 路由、服务
- 消费者
- 路由
- 服务
- 全局插件
名称 | 描述 |
---|---|
name | 插件的名称。 |
route | 当此属性指定的路由接收请求时,插件才会运行。默认值:null。 |
service | 当指定服务中某一个路由在接收请求时候,插件才会运行。默认值:null。 |
consumer | 当此属性匹配到指定的消费者时,插件才会运行。默认值:null。 |
config | 插件配置的外部属性。 |
run_on | 控制插件在哪些 Kong 节点上运行,常用与服务网格,接受的值如下: 1. first:在请求到的第一个 Kong 节点上运行插件。 2. second:在请求到的第二个 Kong 节点上运行插件。 3. all:在所有 Kong 节点上运行插件。 |
protocols | 触发此插件的协议列表。 |
enabled | 是否启用插件。默认值:true。 |
tags | 与插件关联的一组可选字符串,用于分组和过滤。即标签。 |
证书 (certificate)
CA 证书对象表示受信任的 CA。Kong 使用这些对象来验证客户端或服务器证书的有效性。
证书可以选择与 SNI 对象关联,并将证书 / 密钥对绑定到一个或多个主机域名上。
名称 | 描述 |
---|---|
cert | PEM编码格式的SSL密钥对的公共证书。 |
key | SSL密钥对的PEM编码格式私钥。 |
tags | 与证书关联的一组可选字符串,用于分组和过滤。即标签。 |
snis | 与此证书关联的零个或多个主机名的数组,如SNI。这是一个糖参数,为方便起见,它将创建一个SNI对象并将其与此证书相关联。 |
SNI (Server Name Indication 服务器名称指示)
SNI 对象表示域名/主机名与证书的多对一映射。也就是说,证书对象可以有许多与之关联的域名/主机名。
当 Kong 收到 SSL 请求时,它使用与其中的域名属性相关联的 SNI 来查找对应的泛域名证书对象。
本文为原创文章,未经授权禁止转载本站文章。
原文出处:兰玉磊的个人博客
原文链接:https://www.fdevops.com/2021/07/25/kong-30920
版权:本文采用「署名-非商业性使用-相同方式共享 4.0 国际」知识共享许可协议进行许可。