Admin API
详细的内容请参考官网说明，可以通过 kong 的 API 查看数据变化。
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 http://localhost:8001/services 2>/dev/null |python -m json.tool
列出可使用的插件
curl http://localhost:8001/plugins/enabled 2>/dev/null |python -m json.tool
kong 定义的资源之间的关联关系
Service：
Service 顾名思义，就是我们自己定义的上游服务，通过Kong匹配到相应的请求要转发的地方。Service 可以与下面的Route进行关联，一个Service可以有很多Route，匹配到的Route就会转发到Service中，当然中间也会通过Plugin的处理，增加或者减少一些相应的Header或者其他信息Service可以是一个实际的地址，也可以是Kong内部提供的upstream object
Route：
Route 字面意思就是路由，实际就是通过定义一些规则来匹配客户端的请求，每个路由都会关联一个Service，并且Service可以关联多个Route，当匹配到客户端的请求时，每个请求都会被代理到其配置的Service中。Route作为客户端的入口，通过将Route和Service的松耦合，可以通过hosts path等规则的配置，最终让请求到不同的Service中
例如：规定api.example.com 和 api.service.com的登录请求都能够代理到123.11.11.11:8000端口上，可以通过hosts和path来路由
- 创建一个Service s1，其相应的host和port以及协议为http://123.11.11.11:8000
- 创建一个Route，关联的Service为s1，其hosts为[api.service.com, api.example.com],path为login
- 将域名api.example.com和api.service.com的请求转到到我们的Kong集群上，也就是我们上面一节中通过Nginx配置的请求地址
- 当请求api.example.com/login和api.service.com/login时，其通过Route匹配，然后转发到Service，最终将会请求自己的服务。
Upstream：
这是指您自己的API /服务位于Kong后面，客户端请求被转发到该服务器。相当于Kong提供了一个负载的功能，基于Nginx的虚拟主机的方式做的负载功能。当部署集群时，一个单独的地址不足以满足的时候，可以使用Kong的upstream来进行设置。
首先在service中指定host的时候，可以指定为upstream定义的hostname。在创建upstream时指定名字，然后指定solts(暂时不确定具体作用)，upstream可以进行健康检查等系列操作。然后可以再创建target类型，将target绑定到upstream上，部署集群时，也可以使用。
Target：
target 就是在upstream进行负载均衡的终端，当我们部署集群时，需要将每个节点作为一个target，并设置负载的权重，当然也可以通过upstream的设置对target进行健康检查。当使用upstream时，整个路线是 Route >> Service >> Upstream >> Target
Consumer：
Consumer 可以代表一个服务，可以代表一个用户，也可以代表消费者，可以根据我们自己的需求来定义，可以将一个Consumer对应到实际应用中的一个用户，也可以只是作为一个Service的请求消费者
Plugin：
在请求被代理到上游API之前或之后执行Kong内的动作的插件。例如，请求之前的Authentication或者是请求限流插件的使用。Plugin可以和Service绑定，也可以和Route以及Consumer进行关联。
| 信息 |
|---|
Route是请求的转发规则，按照Hostname和PATH，将请求转发给Service，Kubernetes的Ingress中每个path对应一个Route。 Services是多个Upstream的集合，是Route的转发目标。 Consumer是API的用户，里面记录用户的一些信息。 Plugin是插件，plugin可以是全局的，绑定到Service，绑定到Router，绑定到Consumer。 Certificate是https证书。 Sni是域名与Certificate的绑定，指定了一个域名对应的https证书。 Upstream是负载均衡策略。 Target是最终处理请求的Backend服务。 |
插件的作用范围
kong 通过 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 的插件，称为全局插件。
| 目录 |
|---|