Envoy：主动健康监测
实验文件
docker-compose
version: '3'
services:
envoy:
image: envoyproxy/envoy-alpine:v1.15-latest
environment:
- ENVOY_UID=0
- HEALTHY=ok
ports:
- 80:80
- 443:443
- 82:9901
volumes:
- ./envoy.yaml:/etc/envoy/envoy.yaml
- ./certs:/etc/envoy/certs
networks:
envoymesh:
aliases:
- envoy
depends_on:
- webserver1
- webserver2
webserver1:
image: sealloong/envoy-end:latest
environment:
- COLORFUL=blue
- HEALTHY=ok
networks:
envoymesh:
aliases:
- myservice
- webservice
expose:
- 90
webserver2:
image: sealloong/envoy-end:latest
environment:
- COLORFUL=blue
networks:
envoymesh:
aliases:
- myservice
- webservice
expose:
- 90
networks:
envoymesh: {}
envoy配置文件
admin:
access_log_path: /dev/null
address:
socket_address: { address: 0.0.0.0, port_value: 9901 }
static_resources:
listeners:
- name: listener_0
address:
socket_address: { address: 0.0.0.0, port_value: 80 }
filter_chains:
- filters:
- name: envoy_http_connection_manager
typed_config:
"@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
stat_prefix: ingress_http
codec_type: AUTO
route_config:
name: local_route
virtual_hosts:
- name: local_service
domains: [ "*" ]
routes:
- match: { prefix: "/" }
route: { cluster: local_service }
http_filters:
- name: envoy.filters.http.router
clusters:
- name: local_service
connect_timeout: 0.25s
type: STRICT_DNS
lb_policy: ROUND_ROBIN
load_assignment:
cluster_name: local_service
endpoints:
- lb_endpoints:
- endpoint:
address:
socket_address: { address: webservice, port_value: 90 }
health_checks:
timeout: 1s
interval: 10s
unhealthy_threshold: 5
healthy_threshold: 5
http_health_check:
path: "/ping"
expected_statuses:
start: 200
end: 201
路由
/ping 健康监测的路由
/ping/ok 手动将节点设置为有效节点
/ping/fail 手动将节点设置为失效
测试结论
[root@redis ~]# curl -s 127.0.0.1:82/clusters|grep health
local_service::172.22.0.2:90::health_flags::healthy
local_service::172.22.0.3:90::health_flags::healthy
当在集群启动时，所有节点默认为健康状态，在没有流量进入时，默认的间隔时间为1分钟。
当有外部流量进入后，在结束上个默认间隔1分钟之后，会成为配置文件设置的默认10s
手动设置一个节点为不健康状态，
日志中可以看出，在手动设置为失效时，请求是不会到达后端失效节点，并且第一次请求时间明显长，在设置为成功时，后端节点判定为健康是在4次健康监测而非正常请求
webserver1_1 | [GIN] 2020/09/13 - 02:00:48 | 200 | 110.706µs | 172.22.0.4 | GET "/"
webserver2_1 | [GIN] 2020/09/13 - 02:00:48 | 200 | 47.29µs | 172.22.0.4 | GET "/"
webserver1_1 | [GIN] 2020/09/13 - 02:00:49 | 200 | 14.909µs | 172.22.0.4 | GET "/"
webserver2_1 | [GIN] 2020/09/13 - 02:01:18 | 200 | 58.53µs | 172.22.0.4 | GET "/"
webserver1_1 | [GIN] 2020/09/13 - 02:01:19 | 200 | 15.988µs | 172.22.0.4 | GET "/"
webserver2_1 | [GIN] 2020/09/13 - 02:01:42 | 200 | 20.844µs | 172.22.0.4 | GET "/ping"
webserver1_1 | [GIN] 2020/09/13 - 02:01:42 | 200 | 12.247µs | 172.22.0.4 | GET "/ping"
webserver1_1 | [GIN] 2020/09/13 - 02:01:52 | 200 | 38.892µs | 172.22.0.4 | GET "/ping"
webserver2_1 | [GIN] 2020/09/13 - 02:01:52 | 200 | 32.254µs | 172.22.0.4 | GET "/ping"
webserver2_1 | [GIN] 2020/09/13 - 02:01:54 | 200 | 33.689µs | ::1 | GET "/ping/fail"
webserver2_1 | [GIN] 2020/09/13 - 02:01:59 | 200 | 82.86µs | ::1 | GET "/ping/fail"
webserver1_1 | [GIN] 2020/09/13 - 02:02:02 | 200 | 155.202µs | 172.22.0.4 | GET "/ping"
webserver2_1 | [GIN] 2020/09/13 - 02:02:02 | 502 | 26.73µs | 172.22.0.4 | GET "/ping"
webserver1_1 | [GIN] 2020/09/13 - 02:02:07 | 200 | 19.193µs | 172.22.0.4 | GET "/"
webserver1_1 | [GIN] 2020/09/13 - 02:02:08 | 200 | 14.651µs | 172.22.0.4 | GET "/"
webserver1_1 | [GIN] 2020/09/13 - 02:02:09 | 200 | 15.101µs | 172.22.0.4 | GET "/"
webserver1_1 | [GIN] 2020/09/13 - 02:02:09 | 200 | 15.294µs | 172.22.0.4 | GET "/"
webserver1_1 | [GIN] 2020/09/13 - 02:02:10 | 200 | 26.45µs | 172.22.0.4 | GET "/"
webserver1_1 | [GIN] 2020/09/13 - 02:02:10 | 200 | 17.679µs | 172.22.0.4 | GET "/"
webserver1_1 | [GIN] 2020/09/13 - 02:02:11 | 200 | 14.703µs | 172.22.0.4 | GET "/"
webserver1_1 | [GIN] 2020/09/13 - 02:02:11 | 200 | 14.546µs | 172.22.0.4 | GET "/"
webserver2_1 | [GIN] 2020/09/13 - 02:02:12 | 502 | 8.37µs | 172.22.0.4 | GET "/ping"
webserver1_1 | [GIN] 2020/09/13 - 02:02:12 | 200 | 14.214µs | 172.22.0.4 | GET "/ping"
webserver2_1 | [GIN] 2020/09/13 - 02:02:22 | 502 | 8.998µs | 172.22.0.4 | GET "/ping"
webserver1_1 | [GIN] 2020/09/13 - 02:02:22 | 200 | 13.489µs | 172.22.0.4 | GET "/ping"
webserver2_1 | [GIN] 2020/09/13 - 02:02:30 | 200 | 119.326µs | ::1 | GET "/ping/ok"
webserver1_1 | [GIN] 2020/09/13 - 02:02:32 | 200 | 8.864µs | 172.22.0.4 | GET "/ping"
webserver2_1 | [GIN] 2020/09/13 - 02:02:32 | 200 | 14.679µs | 172.22.0.4 | GET "/ping"
webserver1_1 | [GIN] 2020/09/13 - 02:02:38 | 200 | 14.781µs | 172.22.0.4 | GET "/"
webserver1_1 | [GIN] 2020/09/13 - 02:02:39 | 200 | 15.452µs | 172.22.0.4 | GET "/"
webserver1_1 | [GIN] 2020/09/13 - 02:02:39 | 200 | 14.825µs | 172.22.0.4 | GET "/"
webserver1_1 | [GIN] 2020/09/13 - 02:02:40 | 200 | 14.784µs | 172.22.0.4 | GET "/"
webserver1_1 | [GIN] 2020/09/13 - 02:02:40 | 200 | 14.788µs | 172.22.0.4 | GET "/"
webserver1_1 | [GIN] 2020/09/13 - 02:02:41 | 200 | 72.985µs | 172.22.0.4 | GET "/"
webserver2_1 | [GIN] 2020/09/13 - 02:02:42 | 200 | 8.523µs | 172.22.0.4 | GET "/ping"
webserver1_1 | [GIN] 2020/09/13 - 02:02:42 | 200 | 14.497µs | 172.22.0.4 | GET "/ping"
webserver1_1 | [GIN] 2020/09/13 - 02:02:42 | 200 | 15.611µs | 172.22.0.4 | GET "/"
webserver1_1 | [GIN] 2020/09/13 - 02:02:47 | 200 | 46.065µs | 172.22.0.4 | GET "/"
webserver1_1 | [GIN] 2020/09/13 - 02:02:47 | 200 | 19.455µs | 172.22.0.4 | GET "/"
webserver1_1 | [GIN] 2020/09/13 - 02:02:47 | 200 | 15.079µs | 172.22.0.4 | GET "/"
webserver1_1 | [GIN] 2020/09/13 - 02:02:48 | 200 | 22.208µs | 172.22.0.4 | GET "/"
webserver2_1 | [GIN] 2020/09/13 - 02:02:52 | 200 | 39.693µs | 172.22.0.4 | GET "/ping"
webserver1_1 | [GIN] 2020/09/13 - 02:02:52 | 200 | 32.376µs | 172.22.0.4 | GET "/ping"
webserver1_1 | [GIN] 2020/09/13 - 02:03:02 | 200 | 19.476µs | 172.22.0.4 | GET "/ping"
webserver2_1 | [GIN] 2020/09/13 - 02:03:02 | 200 | 11.041µs | 172.22.0.4 | GET "/ping"
webserver2_1 | [GIN] 2020/09/13 - 02:03:12 | 200 | 14.292µs | 172.22.0.4 | GET "/ping"
webserver1_1 | [GIN] 2020/09/13 - 02:03:12 | 200 | 8.215µs | 172.22.0.4 | GET "/ping"
webserver1_1 | [GIN] 2020/09/13 - 02:03:22 | 200 | 16.145µs | 172.22.0.4 | GET "/ping"
webserver2_1 | [GIN] 2020/09/13 - 02:03:22 | 200 | 11.455µs | 172.22.0.4 | GET "/ping"
webserver1_1 | [GIN] 2020/09/13 - 02:03:29 | 200 | 15.02µs | 172.22.0.4 | GET "/"
webserver2_1 | [GIN] 2020/09/13 - 02:03:30 | 200 | 34.405µs | 172.22.0.4 | GET "/"
webserver1_1 | [GIN] 2020/09/13 - 02:03:30 | 200 | 14.647µs | 172.22.0.4 | GET "/"
webserver2_1 | [GIN] 2020/09/13 - 02:03:30 | 200 | 15.039µs | 172.22.0.4 | GET "/"
webserver1_1 | [GIN] 2020/09/13 - 02:03:31 | 200 | 16.706µs | 172.22.0.4 | GET "/"
webserver2_1 | [GIN] 2020/09/13 - 02:03:31 | 200 | 15.667µs | 172.22.0.4 | GET "/"
webserver1_1 | [GIN] 2020/09/13 - 02:03:31 | 200 | 15.025µs | 172.22.0.4 | GET "/"
webserver1_1 | [GIN] 2020/09/13 - 02:03:32 | 200 | 15.085µs | 172.22.0.4 | GET "/ping"
webserver2_1 | [GIN] 2020/09/13 - 02:03:32 | 200 | 13.446µs | 172.22.0.4 | GET "/ping"
webserver2_1 | [GIN] 2020/09/13 - 02:03:42 | 200 | 14.702µs | 172.22.0.4 | GET "/ping"
webserver1_1 | [GIN] 2020/09/13 - 02:03:42 | 200 | 9.262µs | 172.22.0.4 | GET "/ping"
无外部流量时的请求间隔设置 官方参考
no_traffic_interval
Envoy：主动健康监测的更多相关文章
- Consul-template的简单应用:配置中心,服务发现与健康监测
简介 Consul-template是Consul的一个方扩展工具,通过监听Consul中的数据可以动态修改一些配置文件,大家比较热衷于应用在Nginx,HAProxy上动态配置健康状态下的客户端反向 ...
- 服务发现与健康监测框架Consul-DNS转发的应用
关于Consul Consul是一个提供服务注册与发现,健康监测,Key/Value存储以及多数据中心存储的分布式框架.官网地址是https://www.consul.io/,公司初步应用后我们老大觉 ...
- lvs+keepalive实现主从效果，以及RS健康监测和tcp，udp实现非web的负载均衡
前面文章讲到了tcp和udp负载均衡,但是没有健康监测,这几天我优化了一下上次的操作.当然,我也是用的跨网段的通讯,因为线上业务主要是海外业务,所以做了iptables流量转发 IP: lvs-mas ...
- Nginx被动健康检查和主动健康检查
1.被动健康检查 Nginx自带有健康检查模块:ngx_http_upstream_module,可以做到基本的健康检查,配置如下: upstream cluster{ server max_fail ...
- Consul之：服务健康监测
服务注册 - 服务进程在注册中心注册自己的位置.它通常注册自己的主机和端口号,有时还有身份验证信息,协议,版本号,以及运行环境的详细资料. 服务发现 - 客户端应用进程向注册中心发起查询,来获取服务的 ...
- 微服务中的健康监测以及其在ASP.NET Core服务中实现运行状况检查
1 .什么是健康检查? 健康检查几乎就是名称暗示的.它是一种检查您的应用程序是否健康的方法.随着越来越多的应用程序转向微服务式架构,健康检查变得尤其重要(Health Check).虽然微服务架构有很 ...
- 基于RT-Thread的人体健康监测系统
随着生活质量的提高和生活节奏的加快,人们愈加需要关注自己的健康状况,本项目意在设计一种基于云平台+APP+设备端的身体参数测试系统,利用脉搏传感器.红外传感器.微弱信号检测电路等实现人体参数的采集,数 ...
- CUDA刷新：GPU计算生态系统
CUDA刷新:GPU计算生态系统 CUDA Refresher: The GPU Computing Ecosystem 这是CUDA Refresher系列的第三篇文章,其目标是刷新CUDA中的关键 ...
- 服务网格数据平面的关键：层层剖析Envoy配置
Envoy是一种高性能C++分布式代理,专为单个服务和应用程序设计.作为Service Mesh中的重要组件,充分理解其配置就显得尤为重要.本文列出了使用Envoy而不用其他代理的原因.并给出了Env ...
随机推荐
- 「Leetcode-算法_MId1006」从单栈到双栈
Mid 1006 笨阶乘 栈/后缀 运算优化 + 栈 思路描述 每四个数一组 这四个数中前三个会进行乘.除 然后与最后一个相加 Stack 入前三个之和 与 最后一个数 以 4 举例 运算式 4 * ...
- 工具 | Typora + PicGo-Core 自动上传图片到图床
0 前言 Markdown 是现在十分流行的标记式语言,在博客等很多场景中应用十分广泛.众所周知,Markdown 中的图片是以链接的形式存在的,不像 Word 等传统文本编辑器直接把图片嵌入文档中. ...
- 以聊天的形式解决traefik2.1.X的一个问题
海口-老男人 17:24:48 大哥,这个是啥报错呀 海口-老男人 17:27:04 E0413 09:23:13.134144 1 reflector.go:153] pkg/mod/k8s.io/ ...
- [图论]最优布线问题:prim
最优布线问题 目录 最优布线问题 Description Input Output Sample Input Sample Output Hint 解析 代码 Description 学校有n台计算机 ...
- 经典变长指令SIB
前言 ModR/M字段是用来进行内存寻址的,可当地址形如DS:[EAX + ECX*2 + 12345678]时,仅仅靠ModR/M字段,是描述不出来的. 这时就在ModR/M后面增加一个SIB字节, ...
- 添加ASP.NET文件夹(3)
注意:这里添加的是ASP.NET文件夹,而不是普通网站下项目创建的文件夹 ASP.NET文件夹主要有7个 1.Bin文件夹包含程序所需的所有已编译程序集 2.App_Code文件夹包含页所使用的类的源 ...
- Dapper, Ef core, Freesql 插入大量数据性能比较（一）
需求:导入9999行数据时Dapper, Ef core, Freesql 谁的性能更优,是如何执行的,级联增加谁性能更佳. 确认方法:sql server 的 sys.dm_exec_query_s ...
- java面试一日一题：mysql中常用的存储引擎有哪些？
问题:请讲下mysql中常用的引擎有哪些? 分析:该问题主要考察对mysql存储引擎的理解,及区别是什么? 回答要点: 主要从以下几点去考虑, 1.mysql的存储引擎的基本概念? 2.mysql中常 ...
- 从中国加入WTO来看Java设计模式：中介者模式
目录 应用场景 中介者模式 定义 意图 主要解决问题 何时使用 优缺点 世界贸易组织WTO 应用场景 系统中对象之间存在比较复杂的引用关系,导致它们之间的依赖关系结构混乱而且难以复用该对象 想通过一个 ...
- Ionic5手写签名SignaturePad
测试程序下载:https://hanzhe.lanzous.com/itt47kncw3a 初始化项目 1. 首先新建一个Ionic5的项目: ionic start test-1 blank 2. ...