你可以通过在Kong中添加一个包含一个或多个target实体的upstream实体来配置一个使用环形负载均衡器的API代理。每个target都指向不同的IP地址(或主机名)和端口。环形负载均衡器将在各个target之间平衡负载,并根据upstream配置对target执行健康检查,根据目标是否响应来标记它们是健康的还是不健康的。然后,环形负载均衡器将只将流量路由到健康的目标上。
Kong支持两种类型的健康检查,可以单独或者结合使用:
注意:该功能在混合模式下不受支持。
健康检查功能的目标是为给定的Kong节点动态标记目标为健康或不健康。健康信息没有在整个集群中进行同步:每个Kong节点单独确定其目标的健康状况。这是可取的,因为在某一时刻,一个Kong节点可能能够成功连接到目标,而另一个节点可能无法达到它:第一个节点将认为它是健康的,而第二个节点将标记它为不健康状态,并开始将流量路由到上游的其他目标。
无论是主动探测(用于主动健康检查)还是代理请求(用于被动健康检查),都会产生用于确定目标是否健康的数据。请求可能会产生TCP错误、超时或生成HTTP状态码。基于这些信息,健康检查器会更新一系列内部计数器:
如果任何一个“TCP失败”、“HTTP失败”或“超时”计数器达到其配置的阈值,目标将被标记为不健康。
如果“成功”计数器达到其配置的阈值,目标将被标记为健康。
哪些HTTP状态码被配置为“健康”或“不健康”,以及每个计数器的阈值,可以在每个上游(Upstream)基础上进行配置。下面是一个上游实体配置的示例,展示了用于配置健康检查的各个字段的默认值。每个字段的描述在管理员API参考文档中提供。
{
"name": "service.v1.xyz",
"healthchecks": {
"active": {
"concurrency": 10,
"healthy": {
"http_statuses": [ 200, 302 ],
"interval": 0,
"successes": 0
},
"http_path": "/",
"timeout": 1,
"unhealthy": {
"http_failures": 0,
"http_statuses": [ 429, 404, 500, 501,
502, 503, 504, 505 ],
"interval": 0,
"tcp_failures": 0,
"timeouts": 0
}
},
"passive": {
"healthy": {
"http_statuses": [ 200, 201, 202, 203,
204, 205, 206, 207,
208, 226, 300, 301,
302, 303, 304, 305,
306, 307, 308 ],
"successes": 0
},
"unhealthy": {
"http_failures": 0,
"http_statuses": [ 429, 500, 503 ],
"tcp_failures": 0,
"timeouts": 0
}
},
"threshold": 0
},
"slots": 10
}
如果上游不健康(可用容量百分比低于配置的阈值),Kong将以503 Service Unavailable的响应回复对该上游的请求。
注意事项:
除了对个别目标进行健康检查功能外,上游还具有健康状态的概念。上游的健康状态是根据其目标的状态来确定的。
上游的健康配置通过属性healthchecks.threshold进行。这是使上游被视为健康所需的最小可用目标权重(容量)的百分比。
这是一个简单的例子:
当故障开始发生时,第一个目标的断路器会跳闸。现在它被视为不健康。这意味着在环形负载均衡器中,20%的容量现在是不健康的(100个权重占据了总共500个权重)。但这仍然高于55的阈值,因此剩余的目标将继续处理失败目标的流量。
当第二次故障发生时,另一个目标失败,又失去了100个权重。现在,环形负载均衡器的使用率降低到了60%,但仍然在配置的阈值范围内。
假设前面的两次故障是由于系统超负荷造成的,我们可以推断剩下的60%的容量也无法满足全部负载,并且很快会有第三个节点失败,将健康容量降低到40%。此时,上游的健康状态将低于其阈值,被标记为不健康状态。
一旦进入不健康状态,上游只会返回错误。这使得目标/服务能够从它们之前的级联故障中恢复过来。
一旦目标开始恢复并且上游的可用容量再次超过阈值,环形负载均衡器的健康状态将自动更新。