- 浏览: 565176 次
- 性别:
- 来自: 北京
文章分类
- 全部博客 (267)
- 随笔 (4)
- Spring (13)
- Java (61)
- HTTP (3)
- Windows (1)
- CI(Continuous Integration) (3)
- Dozer (1)
- Apache (11)
- DB (7)
- Architecture (41)
- Design Patterns (11)
- Test (5)
- Agile (1)
- ORM (3)
- PMP (2)
- ESB (2)
- Maven (5)
- IDE (1)
- Camel (1)
- Webservice (3)
- MySQL (6)
- CentOS (14)
- Linux (19)
- BI (3)
- RPC (2)
- Cluster (9)
- NoSQL (7)
- Oracle (25)
- Loadbalance (7)
- Web (5)
- tomcat (1)
- freemarker (1)
- 制造 (0)
最新评论
-
panamera:
如果设置了连接需要密码,Dynamic Broker-Clus ...
ActiveMQ 集群配置 -
panamera:
请问你的最后一种模式Broker-C节点是不是应该也要修改持久 ...
ActiveMQ 集群配置 -
maosheng:
longshao_feng 写道楼主使用 文件共享 模式的ma ...
ActiveMQ 集群配置 -
longshao_feng:
楼主使用 文件共享 模式的master-slave,produ ...
ActiveMQ 集群配置 -
tanglanwen:
感触很深,必定谨记!
少走弯路的十条忠告
一、Kong 概述:
kong的管理配置,官方(https://docs.konghq.com/2.1.x/admin-api)都是通过Kong API 的方式设置,通过 konga 进行管理配置的资料比较稀少且零散,为此根据本人实际的使用经验,归纳总结分享,希望对大家有所帮助!!
默认开放的端口:8000、8001、8443、8444
接受客户端流量的端口:
8000,监听来自客户端的HTTP请求,转发到你的upstream服务上。
8443,监听来自客户端的HTTPS请求,功能跟8000一样。可以通过配置文件禁止。
Admin API 端口:
8001,Kong的HTTP监听的API管理接口。
8444,Kong的HTTPS监听的API管理接口。
port:8000 客户端调用api端口,网关对外开放端口。例如:新建一个api,访问path= /test,则访问http://10.110.2.3:8000/test
port:8001 kong admin api管理端口,可以通过该端口对api、consumer、plugin进行管理,例如:查看名字叫test这个api配置信息,访 http://10.110.2.3:8001/apis/test,查看所有api信息,访问 http://10.110.2.3:8001/apis
概念术语:
Upstream:是对上游服务器的抽象,托管后端服务器,设置负载均衡策略。
Target:代表了一个物理服务,是最终处理请求的Backend服务(IP:PORT)。
Services:是抽象层面的服务,他可以直接映射到一个物理服务(host指向ip+port);也可以指向一个Upstream来做到负载均衡,是多个Upstream的集合,是Route的转发目标,维护route与upstream之间的映射关系。
Route:是路由的抽象,路由是Kong的入口(client请求入口),路由实体定义规则以匹配客户端的请求。每个Route与一个Service相关联,他负责将实际的request映射到service,设置请求的转发规则,按照Hosts和Paths,将请求转发给Service,Kubernetes的Ingress中每个path对应一个Route。
Route 路由:
对请求进行路由功能。可以有多个,每个route中包含了serviceid。
路由用来匹配客户端请求的规则,每一个路由都要与一个服务相关联,当一个请求到达Kong的时候,会先给路由匹配,如果匹配成功,那么会将请求转发给服务,服务再去后端请求数据。所以路由是Kong的入口。
Consumer:是API的用户,里面记录用户的一些信息。
Plugin:是插件,plugin可以是全局的,绑定到Service,绑定到Router,绑定到Consumer。
Certificate:是https证书。
Sni:是域名与Certificate的绑定,指定了一个域名对应的https证书。
服务(Service)的主要属性是它的URL,其可以被设置为单个串或通过指定其protocol,host,port和path。
服务(Service)与路由(Route)相关联(服务可以有许多与之关联的路由)。路由是Kong的入口点,并定义匹配客户端请求的规则。一旦匹配路由,Kong就会将请求代理到其关联的服务。
一个服务(Service)可能有多个与之关联的路由(Route)。与给定路由匹配的每个请求都将代理到其关联的Service上。路由可以配置的字段有:
hosts
paths
methods
Service 和 Route 的组合(以及它们之间的关注点分离)提供了一种强大的路由机制,通过它可以在Kong中定义细粒度的入口点,从而使基础架构路由到不同上游服务。
对应关系:
Upstream :Target -> 1:n
Service :Upstream -> 1:1 or 1:0 (Service 可以直接指向具体的Target,相当于不做负载均衡)
Service : Route -> 1:n
注意:Client 请求的流量通过 Route 指向与之相关的 Service,如果配置插件的话就会作用插件,Service 接到流量后给相应的 Upstream 的 Target 服务上面。
流程原理:
client ----> route ----> service ------> upstream -----> target1,target2,.....
所以,Route(路由)是Kong的入口
二、Kong 配置:
Nginx配置文件:
upstream helloupstream{
server 192.101.11.162:30080 weight 100;
server 192.101.11.163:30080 weight 100;
server 192.101.11.164:30080 weight 100;
}
server{
listen 80;
server_name 192.101.11.152;
max_client_body 128M; ## 限制请求报文大小128M,对应kong的 Request Size Limiting插件
location /hi{
proxy_pass http://helloupstream/hello
}
allow 192.168.0.0/16; ## IP 白名单,对应kong的 Ip Restriction 插件
deny 10.0.0.0/16; ## IP 黑名单,对应kong的 Ip Restriction 插件
}
Kong 对应定义:
Upstream 定义 ngnix 中的 upstream helloupstream
Target 定义 niginx 中upstream 的 server对应
server 192.101.11.162:30080 weight 100;
server 192.101.11.163:30080 weight 100;
server 192.101.11.164:30080 weight 100;
Service 定义 nginx 中server 的 proxy_pass对应 http://helloupstream
Route 定义 ngnix中server中的listen 80; server_name 192.101.11.152; location /hi
通过Kong API配置:
1)配置Upstream
# curl -i -X POST http://<ip>:8001/upstreams -d "name=helloupstream"
2) 配置Target
# curl -i -X POST http://<ip>:8001/upstreams/helloupstream/targets -d "target=192.101.11.162:30080" -d "weight=100"
# curl -i -X POST http://<ip>:8001/upstreams/helloupstream/targets -d "target=192.101.11.163:30080" -d "weight=100"
# curl -i -X POST http://<ip>:8001/upstreams/helloupstream/targets -d "target=192.101.11.164:30080" -d "weight=100"
一个Upstream可以包含多个Target,负载均衡的过程,就是为当前的请求选择一个Target的过程。
Target是IP或者host加端口,是提供服务的最小单位,每个target可以设置不同的权重。
Upstream是对多个target封装,多个target封装成一个虚拟的host,这个虚拟的host就是upstream的name,被用在Service的host中。
每个upstream中有一个预先设置好的slot数量,upstream中的多个target按照各自的权重分到slot中的一块,slot需要是预计的target数量的100倍。
变更target的开销很小,upstream变更的开销比较大,因为涉及到slot的重新分配。
Target的权重设置为0,target将不被选用。
负载均衡算法默认是带有权重的轮询(weighted-round-robin )
3) 配置Service
# curl -i -X POST http://<ip>:8001/services -d "name=hello-service" -d "protocol=http" -d "host=helloupstream" -d "port=80" -d "path=/hello"
Service 服务:如果不需要负载均衡可以直接指定路径和url即可。可以不是Upstream的名字。
下三个参数设置太短容易超时,出现请求失败的可能
“connect_timeout”: 60000, 与上游连接的超时时间,单位毫秒
“write_timeout”: 60000, 向上游发送请求两次连续写操作的超时时间 ,单位毫秒
“read_timeout”: 60000, 用于向上游服务器发送请求的两次连续读取操作之间的超时 ,单位毫秒
4)配置Route
# curl -i -X POST http://<ip>:8001/routes -d "name=hello-route" -d "host=/<ip>" -d "path=/hi" -d "protocol=http" -d "service.id=50fdaec9-bfb0-42ce-8e8b-40d3a65f2270"
注意:<ip> 替换为 Kong 服务器地址 192.101.11.152
注意:methods,hosts,paths这三个参数必须要指定一个,否则无法创建路由。
Route中的匹配条件有host、path、method三个,条件越多的Route的优先级越高。
三、upstream健康检查:
upstream是指位于Kong网关之后的上游API/service,即客户端请求被Kong网关转发到的目标地址。在Kong网关中,upstream表示虚拟主机名,可用于:
健康检查
熔断
负载均衡。
在实际生产环境中,upstream可以指向部署在不同ip和端口的服务(target)。
健康检查方式:
健康检查的目的是动态地将target标记为健康或不健康的状态。每个Kong服务节点分别确定target的运行状况,而不会在集群范围内同步target的健康信息。因为其中的一个Kong服务节点可能成功连接到target,而另一个Kong节点则无法连接到target,第一个Kong服务节点将target标记为健康,第二个Kong节点将target标记为不健康,并将流量路由到其它target。
Kong支持两种健康检查,可以单独使用或结合使用:
主动检查(active checks):定期请求目标中特定的HTTP或HTTPS的endpoint,根据其响应确定目标的运行状况;
被动检查(passive checks):也被称为断路器,该模式下Kong通过分析代理的实时流量,根据其响应的状态确定目标的运行状况。
判定target是否健康
两种检查方式都会产生用于判断target是否健康的数据,一次客户端调用可能会产生TCP错误、超时或产生特定的HTTP状态码,根据这些信息,健康检查程序会更新其内部的相关计数器:
如果target返回的状态码为“健康”状态,将增加target的“成功”计数器,并清除所有其他计数器;
如果Kong和target连接失败,将增加target的“TCP失败”计数器,并清除“成功”计数器;
如果Kong获取target的响应超时,将增加目标的“超时”计数器,并清除“成功”计数器;
如果target返回“不健康”的状态码,将增加目标的“HTTP失败”的计数器,并清除“成功”计数器。
如果“TCP失败”、“HTTP失败”或“超时”计数器中的任意一个达到配置的阈值,target将被标记为不健康状态。
如果“成功”计数器达到配置的阈值,则target将被标记为正常。
配置HTTP状态代码为“健康”或“不健康”,以及这些计数器中每个计数器的各自阈值都可在upstream上进行配置。
如果upstream整体处于“不健康”状态(可用容量百分比小于配置的阈值),则Kong对客户端返回503 Service Unavailable。
注意:
健康检查仅对活动的target进行操作,而不会在Kong数据库中修改target的活动状态;
不健康的target不会从loadbalancer中删除,因此在使用散列算法时不会对负载均衡器的布局产生任何影响(不健康的target将被跳过)。
DNS警告和负载均衡警告也适用于健康检查。如果target使用是hostname,应该确保DNS服务器总是返回hostname的完整IP地址集,并且不限制响应,否则,可能会导致不执行运行状况检查。(没搞明白什么意思)
判定Upstreams是否健康
除了针对单个target的健康检查之外,upstream也具有运行健康概念。 upstream的运行状况取决于其target的状态。
upstream通过healthchecks.threshold属性来进行健康状态的配置,即upstream最小可用target的“权重”(容量)百分比,健康target/总target数。
例如:
upstream配置了healthchecks.threshold属性为55
有5个target,每个target的权重= 100,因此ring-balancer的总权重为500。
当故障发生,第一个target被标记为“不健康”状态。 此时在ring-balancer中,有20%的target不健康,该值高于55的阈值,因此其余target将继续提供服务。
若有三个target都为“不健康”的状态,则只有40%的可用target,低于55%的阈值,upstream的状态为“不健康”。
upstream一旦进入“不健康”状态,Kong将不再转发请求,直接向客户端返回错误,使服务有时间可以从级联故障中恢复。
一旦target恢复“健康”状态,且target可用容量超过阈值,环形负载均衡器的健康状态也会自动被更新。
主动健康检查会主动探测target的健康状态。 在upstream中启用主动健康检查后,Kong会定期向上游的每个target配置的路径发出HTTP或HTTPS请求。 这样,Kong可以根据探测结果自动启用和禁用负载均衡中的target。
四、Kong网关插件
Kong 网关是基于 OpenResty 应用服务器,OpenResty 是一个基于 Nginx 与 Lua 的高性能 Web 平台,其内部集成了大量精良的 Lua 库、第三方模块以及大多数的依赖项。用于方便地搭建能够处理超高并发、扩展性极高的动态 Web 应用、Web 服务和动态网关。而 Kong 核心基于 OpenResty 构建,并且拥有强大的插件扩展功能。
在 Http 请求到达 Kong 网关后,转发给后端应用之前,可以通过网关的各种插件对请求进行流量控制,安全,日志等各方面的处理能力。
目前,Kong 开源版本一共开放 25 个插件,主要分为五大类,Authentication认证,Security安全,Traffic Control流量控制,Analytics & Monitoring分析&监控,Logging日志,其他还有请求报文处理类。插件类似 AOP 开发中的横切功能,可以灵活的配置进行拦截控制。
下面选择一些关键性的插件进行简单的说明。
黑白名单控制能力(ip-restriction)
Kong 提供的 IP 黑白名单控制能力还算相当强,从配置项里面可以看到主要可以针对两个维度进行配置,是针对所有的 API 接口还是针对特定的 API 接口,一个是针对所有的消费方还是特定的某个消费方。对于 IP 配置可以是一个区段,也可以是特定的 IP 地址。但是黑白名单不能同时配置,其次当前没有一个功能是针对某一个系统提供的所有服务都启用黑名单或白名单功能。
日志记录能力(syslog、file-log、http-log)
这里主要日志的插件比较多,一个是 sysLog 在配置后可以直接将 Kong 产生的日志写入到应用服务器的系统日志文件中。如果配置了 file-log 则是单独写入到你指定的 file 文件中。对于 http-log 则是对于 http 服务请求,可以详细的记录请求的输入和输出报文信息,但是具体是记录到哪里,需要通过 config.http_endpoint 配置。具体关键的配置参数信息如下:
consumer_id: 可选参数,消费者 id(启用了消费者认证可以使用,根据 id 识别发出请求的消费者)
config.http_endpoint: 日志接收服务器(包括使用的协议,http or https)
config.method: 可选参数,默认POST,访问日志服务器的请求方式(可选值:PUT,PATCH,POST);
config.timeout: 可选参数,默认10000毫秒,请求超时时间
config.keepalive: 可选参数,默认60000毫秒,连接在关闭之前可存活时间
熔断插件(request-termination)
该插件用来定义指定请求或服务不进行上层服务,而直接返回指定的内容。用来为指定的请求或指定的服务进行熔断。注意 Kong 的熔断插件感觉是临时对服务的禁用,而不是说当达到某一种监控阈值的时候自动触发熔断,或者相关内容还没有了解到。从官方文档的应用场景也可以看到这点。
Temporarily disable a Service (e.g. it is under maintenance).
Temporarily disable a Route (e.g. the rest of the Service is up and running, but a particular endpoint must be disabled).
Temporarily disable a Consumer (e.g. excessive consumption).
如果仅仅是这种方式的熔断话,实际上意义并不是很大。但是可用的地方就在于当某个业务系统进行发版部署的时候我们可以对该业务系统或该业务系统所提供的所有服务进行熔断。
限流插件(rate-limiting)
Kong 当前提供的限流相对来说还是比较弱,即主要是控制某一个 API 接口服务在单位时间内最多只能够调用多少次,如果超过这个次数那么网关就直接拒绝访问并返回错误提示信息。限流实际上一个是根据服务调用次数,一个是根据服务调用数据量,需要在这两个方面进行限流。而里面更加重要的反而是数据量的限流,因为大数据量报文往往更加容易造成内存溢出异常。
安全认证类插件
当前 Kong 网关提供 basic-auth,key-auth,oauth2,hmac-auth,jwt,ldap-auth六种认证插件。
Basic Auth 基本认证插件,即我们根据用户名和密码来生成一个 base64 编码,同时将该编码和目标服务绑定,这样在消费目标服务的时候就需要在报文头填写这个 Base64 编码信息。
Key Auth 认证插件则是利用提前预设好的关键字名称,如下面设置的 keynote = apices,然后为 consumer 设置一个 key-auth 密钥,假如 key-auth = test@keyauth。在请求 api 的时候,将 apikey=test@keyauth,作为一个参数附加到请求 url 后,或者放置到 headers 中。
Hmac Auth 插件是设置绑定的 service 和 routte,以启动 hmac 验证。然后在 Consumers 页面中 Hmac credentials of Consumer 设置中添加一个 username 和 secret。
请求报文容量限制(request-size-limiting)
该插件用于限制请求报文的数据量大小,可以限制单个服务,也可以限制所有的 API 接口服务。
支持Oauth2.0身份认证(oauth2)
Kong 网关支持 Oauth2.0身份认证,Oauth2.0 协议根据使用不同的适用场景,定义了用于四种授权模式:
Authorization code(授权码模式):标准的 Server 授权模式,非常适合 Server 端的 Web 应用。一旦资源的拥有者授权访问他们的数据之后,他们将会被重定向到 Web 应用并在 URL 的查询参数中附带一个授权码(code)。在客户端里,该 code 用于请求访问令牌(access_token)。并且该令牌交换的过程是两个服务端之前完成的,防止其他人甚至是资源拥有者本人得到该令牌。另外,在该授权模式下可以通过 refresh_token 来刷新令牌以延长访问授权时间,也是最为复杂的一种方式。
Implicit Grant(隐式模式):该模式是所有授权模式中最简单的一种,并为运行于浏览器中的脚本应用做了优化。当用户访问该应用时,服务端会立即生成一个新的访问令牌(access_token)并通过 URL 的 #hash 段传回客户端。这时,客户端就可以利用 JavaScript 等将其取出然后请求 API 接口。该模式不需要授权码(code),当然也不会提供 refresh token 以获得长期访问的入口。
Resource Owner Password Credentials(密码模式):自己有一套用户体系,这种模式要求用户提供用户名和密码来交换访问令牌(access_token)。该模式仅用于非常值得信任的用户,例如 API 提供者本人所写的移动应用。虽然用户也要求提供密码,但并不需要存储在设备上。因为初始验证之后,只需将 OAuth 的令牌记录下来即可。如果用户希望取消授权,因为其真实密码并没有被记录,因此无需修改密码就可以立即取消授权。token 本身也只是得到有限的授权,因此相比最传统的 username/password 授权,该模式依然更为安全。
Client Credentials(客户端模式):没有用户的概念,一种基于 APP 的密钥直接进行授权,因此 APP 的权限非常大。它适合像数据库或存储服务器这种对 API 的访问需求。
简单转换能力(request-transformer、response transformer)
Kong 网关提供对输入和输出报文简单转换的能力。从当前配置来看,主要是对消息报文提供了Add,Replace,Rename,Append 等各种简单操作能力。
Kong Plugin通过consumer_id、route_id、service_id限定插件的作用范围:
作用于所有的Service、Router、Consumer: 创建时不指定consumer_id、service_id、route_id
作用于所有的Service、Router和指定的Consumer: 创建时只指定consumer_id
作用于所有的Consumer和指定的Service: 创建时只指定service_id,有些插件还需要指定route_id
作用于所有的Consumer和指定的Router: 创建时只指定route_id,有些插件还需要指定service_id
作用于特定的Service、Router、Consumer: 创建时指定consumer_id、service_id、route_id
没有绑定任何service、route、consumer的插件,称为global插件
五、Konga 配置使用:
Konga配置使用为了更直观,需要增加好多截图,因此通过我的印象笔记分享给大家:
https://app.yinxiang.com/fx/88e144ad-7396-48e2-82a2-472c554679af
六、Kong API:
API请求类型:
获取使用GET
修改使用 PATCH
创建使用 POST方法.添加
删除使用 DELETE 方法
GET /routers/ #列出所有路由
GET /services/ #列出所有服务
GET /consumers/ #列出所有用户
GET /services/{service name or id}/routes #列出服务关联的路由
GET /plugins/ #列出所有的插件配置
GET /plugins/enabled #列出所有可以使用的插件
GET /plugins/schema/{plugin name} #获得插件的配置模版
GET /certificates/ #列出所有的证书
GET /snis/ #列出所有域名与证书的对应
GET /upstreams/ #列出所有的upstream
GET /upstreams/{name or id}/health/ #查看upstream的健康状态
GET /upstreams/{name or id}/targets/all #列出upstream中所有的target
一、节点信息
查看节点信息:
curl -s http://<ip>:8001 | python -m json.tool
查看节点状态:
curl -s http://<ip>:8001/status | python -m json.tool
二、upstream/target
新增upstream:
curl -i -X POST http://<ip>:8001/upstreams -d 'name=hello-upstream'
新增target:
curl -i -X POST http://<ip>:8001/upstreams/hello-upstream/targets -d 'target=192.101.11.162:30080'
删除upstream:
curl -i -X DELETE http://10.10.203.230:8001/upstreams/hello-upstream
删除target:
target没有更新,只有新增/删除,设置weight=0就是删除。
curl -i -X POST http://<ip>:8001/upstreams/hello-upstream/targets -d 'target=192.101.11.162:30080' -d 'weight=0'
三、服务
添加服务:
curl -i -X POST http://<ip>:8001/services -d "name=test.service" -d "url=http://192.101.11.162:30080/hello"
curl -s -X POST --url http://<ip>:8001/services/ -d 'name=hello.service' -d 'protocol=http' -d 'host=192.101.11.162' -d 'port=30080' -d 'path=/hello' | python -m json.tool
查询所有服务:
curl -i -X GET http://<ip>:8001/services
curl -s --url http://<ip>:8001/services/ | python -m json.tool
查询某个服务:
curl -i -X GET http://<ip>:8001/services/{服务名称或服务ID}
curl -s --url http://<ip>:8001/services/{服务名称或服务ID} | python -m json.tool
curl -i -X GET http://<ip>:8001/services/test.service //查询name=test.service的服务(service.id=50fdaec9-bfb0-42ce-8e8b-40d3a65f2270)
curl -s --url http://<ip>:8001/services/hello.service | python -m json.tool
查询某个路由下的服务
curl -i -X GET http://<ip>:8001/routes/{路由ID}/service
curl -s -X GET --url http://<ip>:8001/routes/{路由ID}/service | python -m json.tool
curl -i -X GET http://<ip>:8001/routes/90a66cdb-476e-400f-9851-cff1f04ada99/service //route.id=90a66cdb-476e-400f-9851-cff1f04ada99
curl -s -X GET --url http://<ip>:8001/routes/90a66cdb-476e-400f-9851-cff1f04ada99/service | python -m json.tool
更新服务
curl -i -X PUT http://<ip>:8001/services/{服务名称或服务ID} -d "name=test.service" -d "protocol=http" -d "host=192.101.11.153" -d "path=/api"
curl -s -X PUT --url http://<ip>:8001/services/{服务名称或服务ID} -d 'name=test.service' -d 'protocol=http' -d 'host=192.101.11.153' -d 'path=/api' | python -m json.tool
curl -i -X PUT http://<ip>:8001/services/test.service -d "name=test.service" -d "protocol=http" -d "host=192.101.11.153" -d "path=/api"
删除服务
curl -i -X DELETE http://<ip>:8001/services/{服务名称或服务ID}
curl -i -X DELETE --url http://<ip>:8001/services/{服务名称或服务ID}
curl -i -X DELETE http://<ip>:8001/services/test.service
四、路由
添加路由:
curl -i -X POST --url http://192.101.11.152:8001/routes/ -d 'protocols[]=http&protocols[]=https' -d 'paths[]=/test&paths[]=/test/' -d 'hosts[]=192.101.11.152' -d 'preserve_host=false' -d 'strip_path=true' -d 'service.id=50fdaec9-bfb0-42ce-8e8b-40d3a65f2270'
curl -s -X POST --url http://192.101.11.152:8001/routes/ -d 'protocols=http' -d 'methods=GET' -d 'paths=/test' -d 'service.id=50fdaec9-bfb0-42ce-8e8b-40d3a65f2270' | python -m json.tool
curl -i -X POST --url http://<ip>:8001/routes/ -d 'protocols=http' -d 'paths=/test' -d 'service.id=50fdaec9-bfb0-42ce-8e8b-40d3a65f2270'
重要变量说明:
【strip_path】
值:false,true 默认true
是否把匹配成功的paths删除后再转发后端服务器.
该指令相当于proxy_pass http://jintest-server/
“strip_path”: true, 当通过其中一个路径匹配路由时,从上游请求URL中除去匹配前缀。匹配到path时,是否删除匹配到的前缀。
【preserve_host】
值:false,true 默认false
转发后端是否带host参数,默认不带。
该指令相当于proxy_set_header Host $host;
“preserve_host”: false, Route将请求代理给Service时,默认将请求头中的host修改为Route中配置的host,如果不希望这样,可以设置preserve_host,使用原始请求头中的host。
匹配到hosts时,使用请求头部的值为域名向后端发起请求,请求的头部为"host",例如"host:api.abc.com"
访问接口:
curl -i -X GET http://<ip>:8000/test/
查询全部路由:
curl -i -X GET --url http://<ip>:8001/routes/
curl -s http://<ip>:8001/routes/ | python -m json.tool
查询某个路由:
curl -i -X GET --url http://<ip>:8001/routes/{路由ID}
curl -s http://<ip>:8001/routes/{路由ID} | python -m json.tool
curl -i -X GET --url http://<ip>:8001/routes/90a66cdb-476e-400f-9851-cff1f04ada99
curl -s http://<ip>:8001/routes/90a66cdb-476e-400f-9851-cff1f04ada99 | python -m json.tool
查询某服务下的路由:
curl -i -X GET --url http://<ip>:8001/services/{服务名称或服务ID}/routes
curl -s http://<ip>:8001/services/{服务名称或服务ID}/routes | python -m json.tool
curl -i -X GET --url http://<ip>:8001/services/test.service/routes
curl -s http://<ip>:8001/services/test.service/routes | python -m json.tool
查看和路由关联的服务:
curl -s http://<ip>:8001/routes/{路由ID}/service | python -m json.tool
curl -s http://<ip>:8001/routes/90a66cdb-476e-400f-9851-cff1f04ada99/service | python -m json.tool
更新路由(可以使用PATCH和PUT方法,PATCH可以修改已存在的路由,PUT如果路由不存在则新建一个)
curl -i -X PUT http://<ip>:8001/routes/{路由ID} -d 'protocols[]=http&protocols[]=https' -d 'paths=/test'
curl -s -X PUT --url http://<ip>:8001/routes/{路由ID} -d 'protocols=http' -d 'methods=GET' -d 'paths=/test' -d 'service.id=50fdaec9-bfb0-42ce-8e8b-40d3a65f2270' | python -m json.tool
curl -i -X PUT http://<ip>:8001/routes/90a66cdb-476e-400f-9851-cff1f04ada99 -d 'protocols[]=http&protocols[]=https' -d 'paths=/test' -d 'service.id=50fdaec9-bfb0-42ce-8e8b-40d3a65f2270'
curl -i -X PUT http://<ip>:8001/routes/90a66cdb-476e-400f-9851-cff1f04ada99 -d 'protocols=http' -d 'paths=/test' -d 'service.id=50fdaec9-bfb0-42ce-8e8b-40d3a65f2270'
删除路由
curl -i -X DELETE http://<ip>:8001/routes/{路由ID}
curl -i -X DELETE http://<ip>:8001/routes/90a66cdb-476e-400f-9851-cff1f04ada99
五、用户
添加用户:
curl -s -X POST --url http://<ip>:8001/consumers -d 'username=luoms' | python -m json.tool
查询所有用户;
curl -s http://<ip>:8001/consumers/luoms | python -m json.tool
查询某个用户;
curl -s http://<ip>:8001/consumers/luoms | python -m json.tool
更新用户:
curl -s -X PUT --url http://<ip>:8001/consumers/{id} -d "custom_id=luoms123" | python -m json.tool
curl -s -X PUT --url http://<ip>:8001/consumers/c7456aff-ab6a-4d34-8d2e-2b987c795260 -d "custom_id=luoms123" | python -m json.tool
删除用户:
curl -i -X DELETE --url http://<ip>:8001/consumers/{id}
curl -i -X DELETE --url http://<ip>:8001/consumers/c7456aff-ab6a-4d34-8d2e-2b987c795260
六、插件
添加插件:
curl -s -X POST --url http://<ip>:8001/plugins/ -d 'name=basic-auth' -d 'route_id=90a66cdb-476e-400f-9851-cff1f04ada99' | python -m json.tool
查询所有插件:
curl -s --url http://<ip>:8001/plugins/ | python -m json.tool
查询某个插件:
curl -s --url http://<ip>:8001/plugins/{id} | python -m json.tool
更新插件:
curl -s -X PUT --url http://<ip>:8001/plugins/900aeaa3-0a47-49a1-9fea-649e6c90ab7f -d "service_id=da4dce88-4df3-4723-b544-b11b27184e97" | python -m json.tool
删除插件:
curl -s -X DELETE --url http://<ip>:8001/plugins/900aeaa3-0a47-49a1-9fea-649e6c90ab7f | python -m json.tool
查询已启用的插件:
curl -s -X GET --url http://<ip>:8001/plugins/enabled | python -m json.tool
检索插件架构:
curl -s -X GET --url http://<ip>:8001/plugins/schema/basic-auth | python -m json.tool
注意:<ip> 替换为 Kong 服务器地址 192.101.11.152
七、网关分类:
对于具体的后端业务应用或者是服务和业务有一定关联性的策略网关就是——业务网关。 业务网关针对具体的业务需要提供特定的流控策略、缓存策略、鉴权认证策略等等。
与业务网关相反,定义全局性的、跟具体的后端业务应用和服务完全无关的策略网关就是——流量网关。流量网关通常只专注于全局的Api管理策略,比如全局流量监控、日志记录、全局限流、黑白名单控制、接入请求到业务系统的负载均衡等,有点类似防火墙。Kong 就是典型的流量网关。
业务网关一般部署在流量网关之后、业务系统之前,比流量网关更靠近业务系统。
kong的管理配置,官方(https://docs.konghq.com/2.1.x/admin-api)都是通过Kong API 的方式设置,通过 konga 进行管理配置的资料比较稀少且零散,为此根据本人实际的使用经验,归纳总结分享,希望对大家有所帮助!!
默认开放的端口:8000、8001、8443、8444
接受客户端流量的端口:
8000,监听来自客户端的HTTP请求,转发到你的upstream服务上。
8443,监听来自客户端的HTTPS请求,功能跟8000一样。可以通过配置文件禁止。
Admin API 端口:
8001,Kong的HTTP监听的API管理接口。
8444,Kong的HTTPS监听的API管理接口。
port:8000 客户端调用api端口,网关对外开放端口。例如:新建一个api,访问path= /test,则访问http://10.110.2.3:8000/test
port:8001 kong admin api管理端口,可以通过该端口对api、consumer、plugin进行管理,例如:查看名字叫test这个api配置信息,访 http://10.110.2.3:8001/apis/test,查看所有api信息,访问 http://10.110.2.3:8001/apis
概念术语:
Upstream:是对上游服务器的抽象,托管后端服务器,设置负载均衡策略。
Target:代表了一个物理服务,是最终处理请求的Backend服务(IP:PORT)。
Services:是抽象层面的服务,他可以直接映射到一个物理服务(host指向ip+port);也可以指向一个Upstream来做到负载均衡,是多个Upstream的集合,是Route的转发目标,维护route与upstream之间的映射关系。
Route:是路由的抽象,路由是Kong的入口(client请求入口),路由实体定义规则以匹配客户端的请求。每个Route与一个Service相关联,他负责将实际的request映射到service,设置请求的转发规则,按照Hosts和Paths,将请求转发给Service,Kubernetes的Ingress中每个path对应一个Route。
Route 路由:
对请求进行路由功能。可以有多个,每个route中包含了serviceid。
路由用来匹配客户端请求的规则,每一个路由都要与一个服务相关联,当一个请求到达Kong的时候,会先给路由匹配,如果匹配成功,那么会将请求转发给服务,服务再去后端请求数据。所以路由是Kong的入口。
Consumer:是API的用户,里面记录用户的一些信息。
Plugin:是插件,plugin可以是全局的,绑定到Service,绑定到Router,绑定到Consumer。
Certificate:是https证书。
Sni:是域名与Certificate的绑定,指定了一个域名对应的https证书。
服务(Service)的主要属性是它的URL,其可以被设置为单个串或通过指定其protocol,host,port和path。
服务(Service)与路由(Route)相关联(服务可以有许多与之关联的路由)。路由是Kong的入口点,并定义匹配客户端请求的规则。一旦匹配路由,Kong就会将请求代理到其关联的服务。
一个服务(Service)可能有多个与之关联的路由(Route)。与给定路由匹配的每个请求都将代理到其关联的Service上。路由可以配置的字段有:
hosts
paths
methods
Service 和 Route 的组合(以及它们之间的关注点分离)提供了一种强大的路由机制,通过它可以在Kong中定义细粒度的入口点,从而使基础架构路由到不同上游服务。
对应关系:
Upstream :Target -> 1:n
Service :Upstream -> 1:1 or 1:0 (Service 可以直接指向具体的Target,相当于不做负载均衡)
Service : Route -> 1:n
注意:Client 请求的流量通过 Route 指向与之相关的 Service,如果配置插件的话就会作用插件,Service 接到流量后给相应的 Upstream 的 Target 服务上面。
流程原理:
client ----> route ----> service ------> upstream -----> target1,target2,.....
所以,Route(路由)是Kong的入口
二、Kong 配置:
Nginx配置文件:
upstream helloupstream{
server 192.101.11.162:30080 weight 100;
server 192.101.11.163:30080 weight 100;
server 192.101.11.164:30080 weight 100;
}
server{
listen 80;
server_name 192.101.11.152;
max_client_body 128M; ## 限制请求报文大小128M,对应kong的 Request Size Limiting插件
location /hi{
proxy_pass http://helloupstream/hello
}
allow 192.168.0.0/16; ## IP 白名单,对应kong的 Ip Restriction 插件
deny 10.0.0.0/16; ## IP 黑名单,对应kong的 Ip Restriction 插件
}
Kong 对应定义:
Upstream 定义 ngnix 中的 upstream helloupstream
Target 定义 niginx 中upstream 的 server对应
server 192.101.11.162:30080 weight 100;
server 192.101.11.163:30080 weight 100;
server 192.101.11.164:30080 weight 100;
Service 定义 nginx 中server 的 proxy_pass对应 http://helloupstream
Route 定义 ngnix中server中的listen 80; server_name 192.101.11.152; location /hi
通过Kong API配置:
1)配置Upstream
# curl -i -X POST http://<ip>:8001/upstreams -d "name=helloupstream"
2) 配置Target
# curl -i -X POST http://<ip>:8001/upstreams/helloupstream/targets -d "target=192.101.11.162:30080" -d "weight=100"
# curl -i -X POST http://<ip>:8001/upstreams/helloupstream/targets -d "target=192.101.11.163:30080" -d "weight=100"
# curl -i -X POST http://<ip>:8001/upstreams/helloupstream/targets -d "target=192.101.11.164:30080" -d "weight=100"
一个Upstream可以包含多个Target,负载均衡的过程,就是为当前的请求选择一个Target的过程。
Target是IP或者host加端口,是提供服务的最小单位,每个target可以设置不同的权重。
Upstream是对多个target封装,多个target封装成一个虚拟的host,这个虚拟的host就是upstream的name,被用在Service的host中。
每个upstream中有一个预先设置好的slot数量,upstream中的多个target按照各自的权重分到slot中的一块,slot需要是预计的target数量的100倍。
变更target的开销很小,upstream变更的开销比较大,因为涉及到slot的重新分配。
Target的权重设置为0,target将不被选用。
负载均衡算法默认是带有权重的轮询(weighted-round-robin )
3) 配置Service
# curl -i -X POST http://<ip>:8001/services -d "name=hello-service" -d "protocol=http" -d "host=helloupstream" -d "port=80" -d "path=/hello"
Service 服务:如果不需要负载均衡可以直接指定路径和url即可。可以不是Upstream的名字。
下三个参数设置太短容易超时,出现请求失败的可能
“connect_timeout”: 60000, 与上游连接的超时时间,单位毫秒
“write_timeout”: 60000, 向上游发送请求两次连续写操作的超时时间 ,单位毫秒
“read_timeout”: 60000, 用于向上游服务器发送请求的两次连续读取操作之间的超时 ,单位毫秒
4)配置Route
# curl -i -X POST http://<ip>:8001/routes -d "name=hello-route" -d "host=/<ip>" -d "path=/hi" -d "protocol=http" -d "service.id=50fdaec9-bfb0-42ce-8e8b-40d3a65f2270"
注意:<ip> 替换为 Kong 服务器地址 192.101.11.152
注意:methods,hosts,paths这三个参数必须要指定一个,否则无法创建路由。
Route中的匹配条件有host、path、method三个,条件越多的Route的优先级越高。
三、upstream健康检查:
upstream是指位于Kong网关之后的上游API/service,即客户端请求被Kong网关转发到的目标地址。在Kong网关中,upstream表示虚拟主机名,可用于:
健康检查
熔断
负载均衡。
在实际生产环境中,upstream可以指向部署在不同ip和端口的服务(target)。
健康检查方式:
健康检查的目的是动态地将target标记为健康或不健康的状态。每个Kong服务节点分别确定target的运行状况,而不会在集群范围内同步target的健康信息。因为其中的一个Kong服务节点可能成功连接到target,而另一个Kong节点则无法连接到target,第一个Kong服务节点将target标记为健康,第二个Kong节点将target标记为不健康,并将流量路由到其它target。
Kong支持两种健康检查,可以单独使用或结合使用:
主动检查(active checks):定期请求目标中特定的HTTP或HTTPS的endpoint,根据其响应确定目标的运行状况;
被动检查(passive checks):也被称为断路器,该模式下Kong通过分析代理的实时流量,根据其响应的状态确定目标的运行状况。
判定target是否健康
两种检查方式都会产生用于判断target是否健康的数据,一次客户端调用可能会产生TCP错误、超时或产生特定的HTTP状态码,根据这些信息,健康检查程序会更新其内部的相关计数器:
如果target返回的状态码为“健康”状态,将增加target的“成功”计数器,并清除所有其他计数器;
如果Kong和target连接失败,将增加target的“TCP失败”计数器,并清除“成功”计数器;
如果Kong获取target的响应超时,将增加目标的“超时”计数器,并清除“成功”计数器;
如果target返回“不健康”的状态码,将增加目标的“HTTP失败”的计数器,并清除“成功”计数器。
如果“TCP失败”、“HTTP失败”或“超时”计数器中的任意一个达到配置的阈值,target将被标记为不健康状态。
如果“成功”计数器达到配置的阈值,则target将被标记为正常。
配置HTTP状态代码为“健康”或“不健康”,以及这些计数器中每个计数器的各自阈值都可在upstream上进行配置。
如果upstream整体处于“不健康”状态(可用容量百分比小于配置的阈值),则Kong对客户端返回503 Service Unavailable。
注意:
健康检查仅对活动的target进行操作,而不会在Kong数据库中修改target的活动状态;
不健康的target不会从loadbalancer中删除,因此在使用散列算法时不会对负载均衡器的布局产生任何影响(不健康的target将被跳过)。
DNS警告和负载均衡警告也适用于健康检查。如果target使用是hostname,应该确保DNS服务器总是返回hostname的完整IP地址集,并且不限制响应,否则,可能会导致不执行运行状况检查。(没搞明白什么意思)
判定Upstreams是否健康
除了针对单个target的健康检查之外,upstream也具有运行健康概念。 upstream的运行状况取决于其target的状态。
upstream通过healthchecks.threshold属性来进行健康状态的配置,即upstream最小可用target的“权重”(容量)百分比,健康target/总target数。
例如:
upstream配置了healthchecks.threshold属性为55
有5个target,每个target的权重= 100,因此ring-balancer的总权重为500。
当故障发生,第一个target被标记为“不健康”状态。 此时在ring-balancer中,有20%的target不健康,该值高于55的阈值,因此其余target将继续提供服务。
若有三个target都为“不健康”的状态,则只有40%的可用target,低于55%的阈值,upstream的状态为“不健康”。
upstream一旦进入“不健康”状态,Kong将不再转发请求,直接向客户端返回错误,使服务有时间可以从级联故障中恢复。
一旦target恢复“健康”状态,且target可用容量超过阈值,环形负载均衡器的健康状态也会自动被更新。
主动健康检查会主动探测target的健康状态。 在upstream中启用主动健康检查后,Kong会定期向上游的每个target配置的路径发出HTTP或HTTPS请求。 这样,Kong可以根据探测结果自动启用和禁用负载均衡中的target。
四、Kong网关插件
Kong 网关是基于 OpenResty 应用服务器,OpenResty 是一个基于 Nginx 与 Lua 的高性能 Web 平台,其内部集成了大量精良的 Lua 库、第三方模块以及大多数的依赖项。用于方便地搭建能够处理超高并发、扩展性极高的动态 Web 应用、Web 服务和动态网关。而 Kong 核心基于 OpenResty 构建,并且拥有强大的插件扩展功能。
在 Http 请求到达 Kong 网关后,转发给后端应用之前,可以通过网关的各种插件对请求进行流量控制,安全,日志等各方面的处理能力。
目前,Kong 开源版本一共开放 25 个插件,主要分为五大类,Authentication认证,Security安全,Traffic Control流量控制,Analytics & Monitoring分析&监控,Logging日志,其他还有请求报文处理类。插件类似 AOP 开发中的横切功能,可以灵活的配置进行拦截控制。
下面选择一些关键性的插件进行简单的说明。
黑白名单控制能力(ip-restriction)
Kong 提供的 IP 黑白名单控制能力还算相当强,从配置项里面可以看到主要可以针对两个维度进行配置,是针对所有的 API 接口还是针对特定的 API 接口,一个是针对所有的消费方还是特定的某个消费方。对于 IP 配置可以是一个区段,也可以是特定的 IP 地址。但是黑白名单不能同时配置,其次当前没有一个功能是针对某一个系统提供的所有服务都启用黑名单或白名单功能。
日志记录能力(syslog、file-log、http-log)
这里主要日志的插件比较多,一个是 sysLog 在配置后可以直接将 Kong 产生的日志写入到应用服务器的系统日志文件中。如果配置了 file-log 则是单独写入到你指定的 file 文件中。对于 http-log 则是对于 http 服务请求,可以详细的记录请求的输入和输出报文信息,但是具体是记录到哪里,需要通过 config.http_endpoint 配置。具体关键的配置参数信息如下:
consumer_id: 可选参数,消费者 id(启用了消费者认证可以使用,根据 id 识别发出请求的消费者)
config.http_endpoint: 日志接收服务器(包括使用的协议,http or https)
config.method: 可选参数,默认POST,访问日志服务器的请求方式(可选值:PUT,PATCH,POST);
config.timeout: 可选参数,默认10000毫秒,请求超时时间
config.keepalive: 可选参数,默认60000毫秒,连接在关闭之前可存活时间
熔断插件(request-termination)
该插件用来定义指定请求或服务不进行上层服务,而直接返回指定的内容。用来为指定的请求或指定的服务进行熔断。注意 Kong 的熔断插件感觉是临时对服务的禁用,而不是说当达到某一种监控阈值的时候自动触发熔断,或者相关内容还没有了解到。从官方文档的应用场景也可以看到这点。
Temporarily disable a Service (e.g. it is under maintenance).
Temporarily disable a Route (e.g. the rest of the Service is up and running, but a particular endpoint must be disabled).
Temporarily disable a Consumer (e.g. excessive consumption).
如果仅仅是这种方式的熔断话,实际上意义并不是很大。但是可用的地方就在于当某个业务系统进行发版部署的时候我们可以对该业务系统或该业务系统所提供的所有服务进行熔断。
限流插件(rate-limiting)
Kong 当前提供的限流相对来说还是比较弱,即主要是控制某一个 API 接口服务在单位时间内最多只能够调用多少次,如果超过这个次数那么网关就直接拒绝访问并返回错误提示信息。限流实际上一个是根据服务调用次数,一个是根据服务调用数据量,需要在这两个方面进行限流。而里面更加重要的反而是数据量的限流,因为大数据量报文往往更加容易造成内存溢出异常。
安全认证类插件
当前 Kong 网关提供 basic-auth,key-auth,oauth2,hmac-auth,jwt,ldap-auth六种认证插件。
Basic Auth 基本认证插件,即我们根据用户名和密码来生成一个 base64 编码,同时将该编码和目标服务绑定,这样在消费目标服务的时候就需要在报文头填写这个 Base64 编码信息。
Key Auth 认证插件则是利用提前预设好的关键字名称,如下面设置的 keynote = apices,然后为 consumer 设置一个 key-auth 密钥,假如 key-auth = test@keyauth。在请求 api 的时候,将 apikey=test@keyauth,作为一个参数附加到请求 url 后,或者放置到 headers 中。
Hmac Auth 插件是设置绑定的 service 和 routte,以启动 hmac 验证。然后在 Consumers 页面中 Hmac credentials of Consumer 设置中添加一个 username 和 secret。
请求报文容量限制(request-size-limiting)
该插件用于限制请求报文的数据量大小,可以限制单个服务,也可以限制所有的 API 接口服务。
支持Oauth2.0身份认证(oauth2)
Kong 网关支持 Oauth2.0身份认证,Oauth2.0 协议根据使用不同的适用场景,定义了用于四种授权模式:
Authorization code(授权码模式):标准的 Server 授权模式,非常适合 Server 端的 Web 应用。一旦资源的拥有者授权访问他们的数据之后,他们将会被重定向到 Web 应用并在 URL 的查询参数中附带一个授权码(code)。在客户端里,该 code 用于请求访问令牌(access_token)。并且该令牌交换的过程是两个服务端之前完成的,防止其他人甚至是资源拥有者本人得到该令牌。另外,在该授权模式下可以通过 refresh_token 来刷新令牌以延长访问授权时间,也是最为复杂的一种方式。
Implicit Grant(隐式模式):该模式是所有授权模式中最简单的一种,并为运行于浏览器中的脚本应用做了优化。当用户访问该应用时,服务端会立即生成一个新的访问令牌(access_token)并通过 URL 的 #hash 段传回客户端。这时,客户端就可以利用 JavaScript 等将其取出然后请求 API 接口。该模式不需要授权码(code),当然也不会提供 refresh token 以获得长期访问的入口。
Resource Owner Password Credentials(密码模式):自己有一套用户体系,这种模式要求用户提供用户名和密码来交换访问令牌(access_token)。该模式仅用于非常值得信任的用户,例如 API 提供者本人所写的移动应用。虽然用户也要求提供密码,但并不需要存储在设备上。因为初始验证之后,只需将 OAuth 的令牌记录下来即可。如果用户希望取消授权,因为其真实密码并没有被记录,因此无需修改密码就可以立即取消授权。token 本身也只是得到有限的授权,因此相比最传统的 username/password 授权,该模式依然更为安全。
Client Credentials(客户端模式):没有用户的概念,一种基于 APP 的密钥直接进行授权,因此 APP 的权限非常大。它适合像数据库或存储服务器这种对 API 的访问需求。
简单转换能力(request-transformer、response transformer)
Kong 网关提供对输入和输出报文简单转换的能力。从当前配置来看,主要是对消息报文提供了Add,Replace,Rename,Append 等各种简单操作能力。
Kong Plugin通过consumer_id、route_id、service_id限定插件的作用范围:
作用于所有的Service、Router、Consumer: 创建时不指定consumer_id、service_id、route_id
作用于所有的Service、Router和指定的Consumer: 创建时只指定consumer_id
作用于所有的Consumer和指定的Service: 创建时只指定service_id,有些插件还需要指定route_id
作用于所有的Consumer和指定的Router: 创建时只指定route_id,有些插件还需要指定service_id
作用于特定的Service、Router、Consumer: 创建时指定consumer_id、service_id、route_id
没有绑定任何service、route、consumer的插件,称为global插件
五、Konga 配置使用:
Konga配置使用为了更直观,需要增加好多截图,因此通过我的印象笔记分享给大家:
https://app.yinxiang.com/fx/88e144ad-7396-48e2-82a2-472c554679af
六、Kong API:
API请求类型:
获取使用GET
修改使用 PATCH
创建使用 POST方法.添加
删除使用 DELETE 方法
GET /routers/ #列出所有路由
GET /services/ #列出所有服务
GET /consumers/ #列出所有用户
GET /services/{service name or id}/routes #列出服务关联的路由
GET /plugins/ #列出所有的插件配置
GET /plugins/enabled #列出所有可以使用的插件
GET /plugins/schema/{plugin name} #获得插件的配置模版
GET /certificates/ #列出所有的证书
GET /snis/ #列出所有域名与证书的对应
GET /upstreams/ #列出所有的upstream
GET /upstreams/{name or id}/health/ #查看upstream的健康状态
GET /upstreams/{name or id}/targets/all #列出upstream中所有的target
一、节点信息
查看节点信息:
curl -s http://<ip>:8001 | python -m json.tool
查看节点状态:
curl -s http://<ip>:8001/status | python -m json.tool
二、upstream/target
新增upstream:
curl -i -X POST http://<ip>:8001/upstreams -d 'name=hello-upstream'
新增target:
curl -i -X POST http://<ip>:8001/upstreams/hello-upstream/targets -d 'target=192.101.11.162:30080'
删除upstream:
curl -i -X DELETE http://10.10.203.230:8001/upstreams/hello-upstream
删除target:
target没有更新,只有新增/删除,设置weight=0就是删除。
curl -i -X POST http://<ip>:8001/upstreams/hello-upstream/targets -d 'target=192.101.11.162:30080' -d 'weight=0'
三、服务
添加服务:
curl -i -X POST http://<ip>:8001/services -d "name=test.service" -d "url=http://192.101.11.162:30080/hello"
curl -s -X POST --url http://<ip>:8001/services/ -d 'name=hello.service' -d 'protocol=http' -d 'host=192.101.11.162' -d 'port=30080' -d 'path=/hello' | python -m json.tool
查询所有服务:
curl -i -X GET http://<ip>:8001/services
curl -s --url http://<ip>:8001/services/ | python -m json.tool
查询某个服务:
curl -i -X GET http://<ip>:8001/services/{服务名称或服务ID}
curl -s --url http://<ip>:8001/services/{服务名称或服务ID} | python -m json.tool
curl -i -X GET http://<ip>:8001/services/test.service //查询name=test.service的服务(service.id=50fdaec9-bfb0-42ce-8e8b-40d3a65f2270)
curl -s --url http://<ip>:8001/services/hello.service | python -m json.tool
查询某个路由下的服务
curl -i -X GET http://<ip>:8001/routes/{路由ID}/service
curl -s -X GET --url http://<ip>:8001/routes/{路由ID}/service | python -m json.tool
curl -i -X GET http://<ip>:8001/routes/90a66cdb-476e-400f-9851-cff1f04ada99/service //route.id=90a66cdb-476e-400f-9851-cff1f04ada99
curl -s -X GET --url http://<ip>:8001/routes/90a66cdb-476e-400f-9851-cff1f04ada99/service | python -m json.tool
更新服务
curl -i -X PUT http://<ip>:8001/services/{服务名称或服务ID} -d "name=test.service" -d "protocol=http" -d "host=192.101.11.153" -d "path=/api"
curl -s -X PUT --url http://<ip>:8001/services/{服务名称或服务ID} -d 'name=test.service' -d 'protocol=http' -d 'host=192.101.11.153' -d 'path=/api' | python -m json.tool
curl -i -X PUT http://<ip>:8001/services/test.service -d "name=test.service" -d "protocol=http" -d "host=192.101.11.153" -d "path=/api"
删除服务
curl -i -X DELETE http://<ip>:8001/services/{服务名称或服务ID}
curl -i -X DELETE --url http://<ip>:8001/services/{服务名称或服务ID}
curl -i -X DELETE http://<ip>:8001/services/test.service
四、路由
添加路由:
curl -i -X POST --url http://192.101.11.152:8001/routes/ -d 'protocols[]=http&protocols[]=https' -d 'paths[]=/test&paths[]=/test/' -d 'hosts[]=192.101.11.152' -d 'preserve_host=false' -d 'strip_path=true' -d 'service.id=50fdaec9-bfb0-42ce-8e8b-40d3a65f2270'
curl -s -X POST --url http://192.101.11.152:8001/routes/ -d 'protocols=http' -d 'methods=GET' -d 'paths=/test' -d 'service.id=50fdaec9-bfb0-42ce-8e8b-40d3a65f2270' | python -m json.tool
curl -i -X POST --url http://<ip>:8001/routes/ -d 'protocols=http' -d 'paths=/test' -d 'service.id=50fdaec9-bfb0-42ce-8e8b-40d3a65f2270'
重要变量说明:
【strip_path】
值:false,true 默认true
是否把匹配成功的paths删除后再转发后端服务器.
该指令相当于proxy_pass http://jintest-server/
“strip_path”: true, 当通过其中一个路径匹配路由时,从上游请求URL中除去匹配前缀。匹配到path时,是否删除匹配到的前缀。
【preserve_host】
值:false,true 默认false
转发后端是否带host参数,默认不带。
该指令相当于proxy_set_header Host $host;
“preserve_host”: false, Route将请求代理给Service时,默认将请求头中的host修改为Route中配置的host,如果不希望这样,可以设置preserve_host,使用原始请求头中的host。
匹配到hosts时,使用请求头部的值为域名向后端发起请求,请求的头部为"host",例如"host:api.abc.com"
访问接口:
curl -i -X GET http://<ip>:8000/test/
查询全部路由:
curl -i -X GET --url http://<ip>:8001/routes/
curl -s http://<ip>:8001/routes/ | python -m json.tool
查询某个路由:
curl -i -X GET --url http://<ip>:8001/routes/{路由ID}
curl -s http://<ip>:8001/routes/{路由ID} | python -m json.tool
curl -i -X GET --url http://<ip>:8001/routes/90a66cdb-476e-400f-9851-cff1f04ada99
curl -s http://<ip>:8001/routes/90a66cdb-476e-400f-9851-cff1f04ada99 | python -m json.tool
查询某服务下的路由:
curl -i -X GET --url http://<ip>:8001/services/{服务名称或服务ID}/routes
curl -s http://<ip>:8001/services/{服务名称或服务ID}/routes | python -m json.tool
curl -i -X GET --url http://<ip>:8001/services/test.service/routes
curl -s http://<ip>:8001/services/test.service/routes | python -m json.tool
查看和路由关联的服务:
curl -s http://<ip>:8001/routes/{路由ID}/service | python -m json.tool
curl -s http://<ip>:8001/routes/90a66cdb-476e-400f-9851-cff1f04ada99/service | python -m json.tool
更新路由(可以使用PATCH和PUT方法,PATCH可以修改已存在的路由,PUT如果路由不存在则新建一个)
curl -i -X PUT http://<ip>:8001/routes/{路由ID} -d 'protocols[]=http&protocols[]=https' -d 'paths=/test'
curl -s -X PUT --url http://<ip>:8001/routes/{路由ID} -d 'protocols=http' -d 'methods=GET' -d 'paths=/test' -d 'service.id=50fdaec9-bfb0-42ce-8e8b-40d3a65f2270' | python -m json.tool
curl -i -X PUT http://<ip>:8001/routes/90a66cdb-476e-400f-9851-cff1f04ada99 -d 'protocols[]=http&protocols[]=https' -d 'paths=/test' -d 'service.id=50fdaec9-bfb0-42ce-8e8b-40d3a65f2270'
curl -i -X PUT http://<ip>:8001/routes/90a66cdb-476e-400f-9851-cff1f04ada99 -d 'protocols=http' -d 'paths=/test' -d 'service.id=50fdaec9-bfb0-42ce-8e8b-40d3a65f2270'
删除路由
curl -i -X DELETE http://<ip>:8001/routes/{路由ID}
curl -i -X DELETE http://<ip>:8001/routes/90a66cdb-476e-400f-9851-cff1f04ada99
五、用户
添加用户:
curl -s -X POST --url http://<ip>:8001/consumers -d 'username=luoms' | python -m json.tool
查询所有用户;
curl -s http://<ip>:8001/consumers/luoms | python -m json.tool
查询某个用户;
curl -s http://<ip>:8001/consumers/luoms | python -m json.tool
更新用户:
curl -s -X PUT --url http://<ip>:8001/consumers/{id} -d "custom_id=luoms123" | python -m json.tool
curl -s -X PUT --url http://<ip>:8001/consumers/c7456aff-ab6a-4d34-8d2e-2b987c795260 -d "custom_id=luoms123" | python -m json.tool
删除用户:
curl -i -X DELETE --url http://<ip>:8001/consumers/{id}
curl -i -X DELETE --url http://<ip>:8001/consumers/c7456aff-ab6a-4d34-8d2e-2b987c795260
六、插件
添加插件:
curl -s -X POST --url http://<ip>:8001/plugins/ -d 'name=basic-auth' -d 'route_id=90a66cdb-476e-400f-9851-cff1f04ada99' | python -m json.tool
查询所有插件:
curl -s --url http://<ip>:8001/plugins/ | python -m json.tool
查询某个插件:
curl -s --url http://<ip>:8001/plugins/{id} | python -m json.tool
更新插件:
curl -s -X PUT --url http://<ip>:8001/plugins/900aeaa3-0a47-49a1-9fea-649e6c90ab7f -d "service_id=da4dce88-4df3-4723-b544-b11b27184e97" | python -m json.tool
删除插件:
curl -s -X DELETE --url http://<ip>:8001/plugins/900aeaa3-0a47-49a1-9fea-649e6c90ab7f | python -m json.tool
查询已启用的插件:
curl -s -X GET --url http://<ip>:8001/plugins/enabled | python -m json.tool
检索插件架构:
curl -s -X GET --url http://<ip>:8001/plugins/schema/basic-auth | python -m json.tool
注意:<ip> 替换为 Kong 服务器地址 192.101.11.152
七、网关分类:
对于具体的后端业务应用或者是服务和业务有一定关联性的策略网关就是——业务网关。 业务网关针对具体的业务需要提供特定的流控策略、缓存策略、鉴权认证策略等等。
与业务网关相反,定义全局性的、跟具体的后端业务应用和服务完全无关的策略网关就是——流量网关。流量网关通常只专注于全局的Api管理策略,比如全局流量监控、日志记录、全局限流、黑白名单控制、接入请求到业务系统的负载均衡等,有点类似防火墙。Kong 就是典型的流量网关。
业务网关一般部署在流量网关之后、业务系统之前,比流量网关更靠近业务系统。
发表评论
-
HTTPS的加密原理解读
2021-12-31 11:25 275一、为什么需要加密? 因为http的内容是明文传输的,明文数据 ... -
容器技术的基石: cgroup、namespace和联合文件系统
2021-12-09 10:47 674Docker 是基于 Linux Kernel 的 Names ... -
链路追踪skywalking安装部署
2021-10-21 12:06 787APM 安装部署: 一、下载 版本目录地址:http://a ... -
自动化运维 Ansible 安装部署
2021-08-20 19:06 816一、概述 Ansible 实现了批量系统配置、批量程序部署、 ... -
Linux 下 Kafka Cluster 搭建
2021-07-08 11:23 950概述 http://kafka.apachecn.org/q ... -
ELK RPM 安装配置
2021-06-22 18:59 594相关组件: 1)filebeat。用于收集日志组件,经测试其 ... -
在Kubernetes上部署 Redis 三主三从 集群
2021-03-10 16:25 623NFS搭建见: Linux NFS搭建与配置(https:// ... -
docker-compose 部署ELK(logstash->elasticsearch->kibana)
2020-11-11 18:02 1545概述: ELK是三个开源软件的缩写,分别表示:elastic ... -
Kubernetes1.16.3下部署node-exporter+alertmanager+prometheus+grafana 监控系统
2020-10-28 10:48 1029准备工作 建议将所有的yaml文件存在如下目录: # mkd ... -
Linux NFS 搭建与配置
2020-10-21 17:58 402一、NFS 介绍 NFS 是 Network FileSys ... -
K8S 备份及升级
2020-10-20 15:48 850一、准备工作 查看集群版本: # kubectl get no ... -
云原生技术 Docker、K8S
2020-09-02 16:53 531容器的三大好处 1.资源 ... -
Kubernetes 应用编排、管理与运维
2020-08-24 16:40 557一、kubectl 运维命令 kubectl control ... -
API 网关 kong/konga 安装部署
2020-08-25 17:34 553一、概述 Kong是Mashape开 ... -
Linux 下 Redis Cluster 搭建
2020-08-13 09:14 699Redis集群演变过程: 单 ... -
Kubernetes离线安装的本地yum源构建
2020-08-08 22:41 491一、需求场景 在K8S的使用过程中有时候会遇到在一些无法上网 ... -
Kubernetes 证书延期
2020-08-01 22:28 426一、概述 kubeadm 是 kubernetes 提供的一 ... -
kubeadm方式部署安装kubernetes
2020-07-29 08:01 2319一、前提准备: 0、升级更新系统(切记升级一下,曾被坑过) ... -
Kubernetes 部署 Nginx 集群
2020-07-20 09:32 824一.设置标签 为了保证nginx之能分配到nginx服务器需要 ... -
Prometheus 外部监控 Kubernetes 集群
2020-07-10 15:59 1988大多情况都是将 Prometheus 通过 yaml 安装在 ...
相关推荐
基于centos 7.0,6.5 等安装测试,带网管配置界面,根据用户角色授权等。
安装方法:https://blog.csdn.net/qq_14999375/article/details/129228919 kong&konga完整安装包,包含文件: - kong - konga(已编译) - postgreSQL12.2 - node14
kongx是网关kong的可视化界面管理平台(参考konga的部分界面布局方式),能够集中化管理应用不同环境的网关配置,提供同步各环境的网关配置功能,并且具备规范的权限管理、参数配置、环境管理及日志审计等特性。
Kong / Konga / Keycloak:通过OIDC保护API 学分 ,作者:Joshua A Erney 要求 耐心 :hot_beverage: 安装版本 Kong 2.0.4-高山 Kong加0.14.7 钥匙斗篷10.0.2 本教程的目标 本教程的目标是能够通过kong和keycloak...
2. **插件支持**:Konga 集成了 Kong API 网关的插件系统,允许用户通过 GUI 安装、配置和管理各种插件,如认证、限流、缓存等。这提高了 API 的安全性、性能和可扩展性。 3. **服务发现**:Konga 支持服务发现机制...
Konga是一款基于Node.js开发的开源管理界面,用于管理和配置Kong API Gateway。Kong是业界广泛应用的微服务治理和API管理平台,提供安全、性能和可扩展性。Konga项目,即“konga-master.zip”中的内容,是Kong的图形...
Kongmap是一款专为Kong API网关设计的免费可视化工具,它使得管理和编辑Kong集群的配置变得直观且高效。Kong作为一款流行的开放源代码API网关,提供了路由、服务管理和Plugin策略等功能,而Kongmap正是这些功能的...
KONG API网关演示 使用docker和docker-compose部署Kong API Gateway 快速开始 docker-compose up -d 现在,KONG默认运行 Kong Proxy HTTP Kong Proxy HTTPS 管理员 KONG管理员SSL
Kong 网关是一款强大的 API 管理和微服务网关,它允许开发者轻松地对 API 进行路由、安全控制、限流等操作。在这个场景中,我们关注的是一个名为 "kong-plugin-http-log-with-body.zip" 的压缩包,它包含了一个扩展...
Konga是一款功能强大的管理工具,用于管理和操作Pumba、Docker和Kubernetes集群。...总的来说,使用提供的安装包可以简化在Linux环境下部署Konga的过程,避免手动下载源码和配置环境带来的复杂性。
1、docker安装kong,konga 2、Kong 基础认证插件(Basic auth) 3、Kong的插件: Key Authentication 4、Kong插件[IP Restriction]使用【黑白名单】 5、kong网关
该项目是一款基于Java开发的多语言支持kong网关可视化界面管理...该平台参照konga界面布局,旨在为不同环境下的kong网关提供集中式配置管理,支持环境配置同步,并具备权限管理、参数配置、环境管理和日志审计等功能。
6. **API 访问**:除了 GUI,Konga 还提供了 RESTful API,允许开发人员通过编程方式与 Konga 交互,自动化工作流程或集成到现有的 CI/CD 系统中。 7. **日志和监控**:集成日志和监控功能,帮助用户追踪容器运行时...
在本教程中,我们将深入探讨如何使用Docker安装Kong网关,这是一个流行的API Gateway解决方案。Kong可以作为微服务架构中的代理服务器,提供安全、性能优化和管理API的能力。以下是一个详细的步骤指南: 1. **创建...
不仅仅是另一个GUI Konga不是官方应用。 与没有隶属关系。 支持项目 如果您发现Konga有所帮助,可以向您或成为,以表示支持并帮助我继续维护该项目。...如果您使用的是较旧的Kong版本,请改用konga:legacy hu
总的来说,"konga-lang-plugin-master.zip"为Konga用户提供了便利,特别是对于中文环境下的用户,使他们能够更加流畅地使用这款强大的API管理工具。通过这个插件,我们可以看到Konga在国际化方面的努力,也展示了其...
Konga + Prometheus + Grafana + API和DDBB + Splunk 克隆proyect并运行docker-compose https://github.com/safernandez666/Kong-API-Manager.git && cd Kong-API-Managerchmod +x kong-start.shsh kong-start.sh...
浏览器输入 localhost:1338,端口可以在local.js改 默认登录名admin,密码是三个admin 配置kong API地址要填写完整地址,后面不要带‘/’ http://localhost:8001
概括先决条件二手图书馆安装配置环境变量跑金刚升级中常问问题更多香港相关的东西执照 讨论与支持如果您需要讨论与Konga相关的任何内容,我们可以在Gitter上提供一个聊天室: 特征管理所有Kong Admin API对象。...