1 官方：Installing Kong Gateway (Enterprise) on Kubernetes - v2.5.x | Kong Docs

2 github: GitHub - pantsel/konga: More than just another GUI to Kong Admin API

1. 什么是kong
   1. API 网关和 API 服务管理层，它基于 Nginx 和 OpenResty 开发的一个具有分布式、高性能、高并发、可伸缩、可拓展，同时提供动态负载均衡、动态配置、服务注册、服务发现、授权认证、日志收集、插件拓展等特性和功能的 API 网关服务。
   2. Kong 支持三种数据存储的方式，分别是PostgreSQL、Cassandra 和 DB-less。我们本次课程使用的是和 PostgraSQL 的组合方式。
2. Kong 主要的三个组件：
   1. Kong Server ：基于 Nginx 的服务器，用来接收 API 请求。
   2. PostgraSQL ：用来存储数据。
   3. Kong Dashboard ：官方推荐UI管理工具，当然，也可以使用 restfull 方式 管理admin api，也有开源的，比较不错的 Web 管理平台 konga。
3. Kong 的基础对象主要是分为以下 8 大类：
   1. 路由
      1. 路由就是客户端请求到服务的匹配规则，它是请求入口，支持精确匹配、模糊匹配以及正则匹配，后面我们会一一演示。
      2. 路由与服务的关系都是多对一的，也就是说，每个服务可以对应一个或多个与之相关联的路由。每个路由都将被代理到对应的服务。

      3. 名称	描述
         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	路由所关联的服务。

   2. 服务

      1. 服务是用户管理上游微服务的入口，用于将对应的请求流量，分发给对应的上游服务器。

         客户端会先请求路由，若匹配成功，则 Kong 将请求，代理到该路由相关联的服务上。

      2. 名称	描述
         client_certificate	在与上游服务进行TLS握手时，所使用的客户端证书。
         connect_timeout	从请求到上游服务建立连接的超时时间，默认为 60000 毫秒。
         host	上游服务的名称或域名或upstream名称。
         name	服务名称，不填写则 Kong 自动生成。
         path	请求到上游服务之间要附加使用的路径。
         port	上游服务的端口号，默认值：80。
         protocol	与上游服务通信的协议，默认值：http。
         read_timeout	从上游服务接收数据的超时时间，默认为 60000 毫秒
         retries	代理失败后重试的次数，默认值：5。
         tags	与服务关联的一组可选字符串，用于分组和过滤。即标签。
         url	简写属性，一次性设置 protocol、host、port 和 path。
         write_timeout	将请求发送到上游服务的超时时间，默认为 60000 毫秒

   3. 上游

      1. 上游服务可以表示为一个虚拟的服务，我们可以对上游服务配置多个目标节点进行负载均衡及健康检查。

         健康检查有主动和被动两种模式，当检查到不健康的目标节点的时候，则将该目标节点禁用，使其不参与负载，也可以将已经处理好的目标节点加入到负载中。

      2. 名称	描述
         algorithm	使用的负载均衡算法。可接受值：consistent-hashing(一致性散列)、least-connections(最少连接)、round-robin(轮询)，默认值：round-robin。
         hash_fallback	如果主hash_on没有返回hash(例如。header丢失，或没有consumer识别).consumer，ip，header或cookie其中之一。如果hash_on设置为cookie，则不可用。默认为 "none"。
         hash_fallback_header	标头名称，用于将值作为hash输入。仅在hash_fallback设置为header时才需要。
         hash_on	什么用hash输入：none（导致加权循环方案没有hash），consumer，ip，header或cookie。默认为 "none"。
         hash_on_cookie	cookie名称从哈希输入中获取值。仅当hash_on或hash_fallback设置为cookie时才需要。如果指定的cookie不在请求中，Kong将生成一个值并在响应中设置cookie。
         hash_on_cookie_path	要在响应标头中设置的cookie路径。仅当hash_on或hash_fallback设置为cookie时才需要。默认为 "/"。
         hash_on_header	header名称，用于将值作为hash输入。仅在hash_on设置为标头时才需要。
         healthchecks.active.concurrency	在活动主动健康检查中同时检查的目标数。默认为10。
         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.http_path	在GET HTTP请求中使用的路径，作为活动运行状况检查的探测运行。默认为 "/"。
         healthchecks.active.https_sni	使用HTTPS执行主动健康检查时用作SNI（服务器名称标识）的主机名。当使用IP配置目标时，这尤其有用，因此可以使用正确的SNI验证目标主机的证书。
         healthchecks.active.https_verify_certificate	使用HTTPS执行活动运行状况检查时是否检查远程主机的SSL证书的有效性。默认为true。
         healthchecks.active.timeout	活动运行状况检查的套接字超时（以秒为单位）。默认为1。
         healthchecks.active.type	是使用HTTP还是HTTPS执行活动运行状况检查，还是仅尝试TCP连接。可能的值为tcp，http或https。默认为 "http"。
         healthchecks.active.unhealthy.http_failures	活动探测器中的HTTP故障数（由healthchecks.active.unhealthy.http_statuses定义）以考虑目标运行状况不佳。默认为0。
         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.interval	不健康目标的活动健康检查之间的间隔（以秒为单位）。值为零表示不应执行不健康目标的活动探测。默认为0。
         healthchecks.active.unhealthy.tcp_failures	活动探测器中用于考虑目标不健康的TCP故障数。默认为0。
         healthchecks.active.unhealthy.timeouts	活动探测器中用于考虑目标不健康的超时次数。默认为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，参数为数组即可。
         healthchecks.passive.healthy.successes	代理流量的成功次数（由healthchecks.passive.healthy.http_statuses定义）以考虑目标健康，如被动健康检查所观察到的那样。默认为0。
         healthchecks.passive.type	是否执行解释 HTTP/HTTPS 状态的被动运行状况检查，或仅检查TCP连接是否成功。可能的值是tcp，http或https（在被动检查中，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。
         host_header	通过 Kong 代理请求时，主机头所使用的名称
         name	这是主机名，必须等于Service的host。
         slots	负载均衡器算法中的插槽数（10-65536）。默认为10000。
         tags	与上游关联的一组可选字符串，用于分组和过滤。即标签。

   4. 目标

      1. 目标节点代表一个真实的物理服务，通常为IP地址和端口的组合，每个目标节点都是上游服务的一个具体的节点实例，上游服务与目标节点则是一对多的对应关系。在运行过程中，可动态的添加或者删除目标节点。

         此外，每个目标节点还可以设置权重，接收不同比例的请求流量。

      2. 名称	描述
         target	目标地址（IP地址或主机名）和端口。
         weight	权重，0 ～ 1000。默认值：100。
         tags	与目标关联的一组可选字符串，用于分组和过滤。即标签。

   5. 消费者
      1. 消费者代表一个具体的用户，是客户端请求的发起者。消费者ID可以作为主要的数据存储，可以与业务数据库的用户信息进行映射、关联。并为身份授权和鉴权功能提供更多的策略。

      2. 名称	描述
         username	唯一用户名。
         tags	与消费者关联的一组可选字符串，用于分组和过滤。即标签。
         custom_id	存储实际业务消费者的唯一标识，包括但不限于：用户名、ID等。

   6. 插件

      1. 有的时候，我们会需要在请求或者响应的生命周期中，去执行一些钩子动作。那么在 Kong 中，我们就可以使用插件的机制来在我们的路由和服务上添加、配置和扩展自定义功能，例如第三方的身份验证、限频以及其他的定制化需求。

         在向服务或者路由添加了插件后，则客户端请求这个服务的时候，都会先去执行插件。

         同时插件也是支持应用于某些特定的消费者，以及可以配置为全局插件。

      2. 下面我们就来说下它的插件运行顺序的优先级，依次为优先级从高到低。需注意，涉及到消费者的都是需要通过身份认证的：

         1. 路由、服务、消费者(身份验证)

         2. 路由、消费者(身份验证)

         3. 服务、消费者(身份验证)

         4. 路由、服务

         5. 消费者(身份验证)

         6. 路由

         7. 服务

         8. 全局插件

         9. 名称	描述
            name	插件的名称。
            route	当此属性指定的路由接收请求时，插件才会运行。默认值：null。
            service	当指定服务中某一个路由在接收请求时候，插件才会运行。默认值：null。
            consumer	当此属性匹配到指定的消费者时，插件才会运行。默认值：null。
            config	插件配置的外部属性。
            run_on	控制插件在哪些 Kong 节点上运行，常用与服务网格，接受的值如下： 1. first：在请求到的第一个 Kong 节点上运行插件。 2. second：在请求到的第二个 Kong 节点上运行插件。 3. all：在所有 Kong 节点上运行插件。
            protocols	触发此插件的协议列表。
            enabled	是否启用插件。默认值：true。
            tags	与插件关联的一组可选字符串，用于分组和过滤。即标签。

   7. 证书

      1. CA 证书对象表示受信任的 CA。Kong 使用这些对象来验证客户端或服务器证书的有效性。

         证书可以选择与 SNI 对象关联，并将证书 / 密钥对绑定到一个或多个主机域名上。

      2. 名称	描述
         tags	与证书关联的一组可选字符串，用于分组和过滤。即标签。
         snis	与此证书关联的零个或多个主机名的数组，如SNI。这是一个糖参数，为方便起见，它将创建一个SNI对象并将其与此证书相关联。
         key	SSL密钥对的PEM编码格式私钥。
         cert	PEM编码格式的SSL密钥对的公共证书。

   8. SNI(Server Name Indication 服务器名称指示)

      1. SNI 对象表示域名/主机名与证书的多对一映射。也就是说，证书对象可以有许多与之关联的域名/主机名。

         当 Kong 收到 SSL 请求时，它使用与其中的域名属性相关联的 SNI 来查找对应的泛域名证书对象。

      2.