Kong网关upstream健康检查机制

upstream概念及作用

健康检查

健康检查方式

判定target是否健康

判定upstreams是否健康

两种康检查的区别

启用和禁用健康检查

禁用健康检查

使用总结

upstream概念及作用

upstream是Kong网关将流量转发到的多个target的集合，target可以是域名、ip，不同target可以有不同的port，且可分配不同的权重。通过使用upstream，Kong网关提供如下功能：

健康检查：Kong网关以特定策略，对target进行探活探死，若target不可用，Kong会将流量转发至其它健康的target；
熔断：根据健康检查的状态，对客户端请求进行熔断，防止后端级联服务雪崩；
负载均衡：使用ring-blancer将客户端流量均衡负载到健康的target上。

在实际生产环境中，upstream取代service中配置的单个host，结构图如下：

健康检查

健康检查方式

健康检查的目的是动态地将target标记为健康或不健康的状态。每个Kong服务节点分别确定target的健康状况，不会在集群范围内同步target的健康信息。因为Kong服务节点1可成功连接到target，而此时Kong服务节点2则可能因网络原因无法连接到target，第一个Kong服务节点1将target标记为健康状态，可正常路由客户端请求，第Kong服务节点2将target标记为不健康，将流量路由到其它健康的target。

Kong支持两种模式的健康检查，可以单独使用或结合使用：

主动检查（active checks）：定期请求target的特定的HTTP或HTTPS的endpoint，根据其响应确定目标的健康状况；

被动检查（passive checks）：也被称为断路器模式，该模式下Kong通过分析所代理的实时流量，根据target的响应状态确定target的健康状况。

判定target是否健康

Kong的两种健康检查方式都会产生用于判断target是否健康的数据，一次客户端调用可能会产生TCP错误、连接超时或产生特定的HTTP状态码，根据这些信息，Kong的健康检查程序会更新内部的相关计数器：

如果target返回的状态码为“健康”状态，会增加target的“成功”计数器，并清除所有其他计数器;
如果Kong和target连接失败，将增加target的“TCP失败”计数器，并清除“成功”计数器;
如果Kong获取target的响应超时，将增加target的“超时”计数器，并清除“成功”计数器;
如果target返回“不健康”的状态码，将增加目标的“HTTP失败”的计数器，并清除“成功”计数器。

如果“TCP失败”、“HTTP失败”或“超时”计数器中的任意一个达到配置的阈值，target将被标记为不健康状态。

如果“成功”计数器达到配置的阈值，则target将被标记为正常。

如果upstream整体处于“不健康”状态（可用容量百分比小于配置的阈值），则Kong对客户端返回503 Service Unavailable。

注意：

健康检查不会在Kong的数据库中记录target的健康状态；
不健康的target不会从loadbalancer中删除，因此在使用散列算法时不会对负载均衡器的布局产生任何影响(不健康的target将被跳过)；
DNS警告和负载均衡警告也适用于健康检查。如果target使用是hostname，应该确保DNS服务器总是返回hostname的完整IP地址集，并且不限制响应，否则，可能会导致不执行运行状况检查。(没搞明白什么意思，upstream最好配置为ip？)

判定upstreams是否健康

除了针对单个target的健康检查之外，upstream也具有是否健康的概念。 upstream的运行状况取决于其target的状态。

upstream通过healthchecks.threshold属性来进行健康状态的配置，即upstream最小可用target的“权重”（容量）百分比，健康target的权重/总target的权重。

例如：

upstream配置了healthchecks.threshold属性为55

有5个target，每个target的权重= 100，此时负载均衡的总权重为500。

当第一个target发生故障被标记为“不健康”状态。此时在ring-balancer中，有20％的target不健康，健康的target的权重值高于55的阈值，所以其余的target将继续提供服务。

若有三个target都为“不健康”的状态，则只有40%权重可用的target，低于55%的阈值，upstream的状态为“不健康”。

upstream一旦进入“不健康”状态，Kong将不再向upstream转发请求，而是直接向客户端返回错误，这样做的可以使服务有时间从级联故障中恢复。

两种康检查的区别

主动健康检查会主动探测target的健康状态。在upstream中启用主动健康检查后，Kong会定期向上游的每个target配置的路径发出HTTP或HTTPS请求， Kong会根据探测结果自动启用处于健康状态的target，并禁用不健康的target。

对target的"健康"或"不健康"的检查是分别以特定周期进行探测的，如果任何一个的间隔值（interval）设置为零，则相应的健康检查会被禁用。当两者均为零时，会完全禁用主动健康检查。

注意：主动健康检查目前只支持HTTP/HTTPS协议的target。不适用于协议属性设置为“tcp”或“tls”的upstream。

被动健康检查是基于Kong 网关代理的(HTTP/HTTPS/TCP)进行检查，不会主动发起对target的探测产生额外的网络流量。当target无响应时，被动健康检查将检测该目标并将其标记为不健康状态，ring-balancer也会跳过该target。

该模式下即使target恢复健康状态，Kong也无法探测到该target是健康的，只能通过管理端API手动触发并通知健康检查器再次启用该target。

$ curl -i -X POST http://localhost:8001/upstreams/my_upstream/targets/10.1.2.3:1234/healthy
HTTP/1.1 204 No Content

上述命令会在集群范围内广播该target的“健康”状态，同步到整个Kong集群。Kong节点会重置所有健康检查器的运行状况计数器，负载均衡可以再次将流量路由到该target。

被动运行状况检查的优点是不会产生额外的流量，但是它们无法再次自动将target标记为“健康”（因为熔断器已经打开），只能通过管理端口重新启用目标。

小结

主动健康检查可以在target再次恢复健康后自动将其加入到负载均衡器中，而被动健康检查不能。

在客户端请求数量大于主动探测发起的请求时，被动健康检查响应速度更快。例如，配置为故障阈值3和探测间隔5的主动检查可能需要10到15秒的时间才能将target标记为不健康状态。失败阈值为3的被动检查将仅需要3个请求即可标记为不健康。

被动健康检查不会对目标产生额外的流量，主动进行健康检查会产生额外流量。

主动健康检查需要在target中配置要探测URL（可以简单配置为“ /”）和判定健康或不健康的状态码，而被动运行状况检查不需要这种配置。

使用主动健康检查，target可以根据自身请求状态动态返回HTTP状态码，而被动健康检查则无法做到；

综上：可以组合这两种模式的健康检查。例如，可以启用被动健康检查仅基于转发到target的流量来监视target健康，且仅在目标不健康时使用主动健康检查，以便自动重新启用健康的target。

启用和禁用健康检查

启用主动健康检查

配置active health checks下的配置项。

healthchecks.active.type - 指定执行HTTP还是HTTPS探测（http/https类型），或者通过简单地测试与给定主机和端口的连接是否成功（tcp类型）。

healthchecks.active.http_path - 向target发出HTTP GET请求时应该使用的路径，默认值是"/"；

healthchecks.active.timeout - HTTP GET请求的连接超时，默认值是1秒；

healthchecks.active.concurrency - 并发检查的target数目；

healthchecks.active.healthy.interval - 对健康target的健康检查间隔（单位秒）。零值表示不执行对健康target的探测；

healthchecks.active.unhealthy.interval - 对不健康的target执行健康的间隔(单位秒)，零值表示不执对不健康target的健康探测。

可以灵活的调整对target探活探死的运行间隔，以相同时间间隔探测，或者其中一个探测可以比另一个探测更频繁地运行。

如果使用HTTPS健康检查，还可以指定以下字段:

healthchecks.active.https_verify_certificate - 使用HTTPS执行健康检查时是否检查远程主机的SSL证书的有效性。

healthchecks.active.https_sni - 使用HTTPS执行健康检查时的SNI（服务器名称标识）主机名。当target使用IP时，只有配置SNI才可以正常验证目标主机的证书。

注意：失败的TLS验证会增加“ TCP失败”计数器； “ HTTP失败”仅指HTTP状态代码，无论是通过HTTP还是HTTPS进行健康检查。

配置Kong的不同状态的计数器阈值:

healthchecks.active.healthy.successes - 根据healthcheck.active.health.http_statuses定义的健康HTTP返回码累加的次数；

healthchecks.active.unhealthy.tcp_failures - 根据TCP连接失败或TLS验证失败进行累加；

healthchecks.active.unhealthy.timeouts - target不健康的超时累加计数；

healthchecks.active.unhealthy.http_failures - 根据healthcheck.activity.unhealth.http_statuses定义的不健康的HTTP返回码累加次数。

启用被动健康检查

被动健康检查没有探测功能，只需配置相应计数器阈值即可。

healthchecks.passive.healthy.successes - 根据healthchecks.passive.healthy.http_statuses配置的健康返回码累加的计数器；

healthchecks.passive.unhealthy.tcp_failures - TCP连接失败累加的计数器；

healthchecks.passive.unhealthy.timeouts - 超时失败的累加计数器；

healthchecks.passive.unhealthy.http_failures - 根据healthcheck.passiing.unhealth.http_statuses设置的不健康HTTP状态码的累加计数器。

禁用健康检查

把健康检查中配置的计数器阈值或者间隔设置为零即可禁用该维度的探测功能。将探测间隔设置为零将禁用探测，将计数器的阈值设置为零可禁用该类型的检查。例如，在健康检查时不考虑超时的情况，可以将超时字段（timeouts ）设置为零，通过这样的方式对健康检查器的行为进行细粒度的控制。

要完全禁用主动健康游的健康状况检查，可以把healthchecks.active.healthy.interval和healthchecks.active.unhealthy.interval都设置为0。

要完全禁用被动健康检查，需要将healthchecks.passive下所有计数器的阈值设置为零；

默认情况下，健康检查中的所有计数器阈值和时间间隔均为零，即在新创建的upstream中是完全禁用健康检查的。

使用总结

通过启动三个不同端口的服务（target），动态设置健康检查的HTTP响应码，可以验证Kong网关健康检查的机制。

在实际使用中，使用被动健康检查可能会误杀一些还处于正常状态的target可以承接的流量，所以应该谨慎使用被动模式；

且对target进行探活探死的时候，不能进行有冲突的配置，比如HTTP 403在主动探测模式下认为是健康的返回码，而在被动模式下却认为是不健康的返回码；

在使用HTTP类型探测的时候，可以同时配置TCP错误的探测，但是如果仅仅使用TCP类型进行探测，则最好禁用HTTP类型的探测，在实际测试中发现只使用TCP探测，也会根据HTTP响应码进行健康状态的判断。

一言以蔽之：选择符合业务场景的方式进行健康探测，探活探死使用相同的探测类型，配置不冲突的判断标准。