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 ...
随机推荐
- java例题_33 等腰输出杨辉三角
1 /*33 [程序 33 杨辉三角] 2 题目:打印出杨辉三角形(要求打印出 10 行如下图) 3 程序分析: 4 1 5 1 1 6 1 2 1 7 1 3 3 1 8 1 4 6 4 1 9 1 ...
- mybatis-plus的Could not set property 'updateDate' of 'class com.example.pojo.User' with value 'Fri Jul 24 10:29:39 CST 2020' Cause: java.lang.IllegalArgumentException: argument type mismatch解决方案
按照官网在写mybatis-plus的自动填充功能一直报错,发现官网的解说不全,数据库是datetime类型,java程序又是date,类型不匹配 org.mybatis.spring.MyBatis ...
- abp加DDD开发：低耦合、可复用、可扩展的【工单】业务模块-简介和集成
前言 很多场景[单体+模块化]比微服务更合适,开发难度低.代码可复用性强.可扩展性强.模块化开发有些难点,模块启动与卸载.模块之间的依赖和通讯.asp.net core abp为我们提供了模块化开发能 ...
- 自动统计zabbix过去一周监控告警
# -*- coding:utf-8 -*-import jsonimport requestsimport time,datetimeimport csv,chardetdef getToken(u ...
- 想要更高效地找到信息，你需要掌握这些搜索技巧 (google or baidu)
想要更高效地找到信息,你需要掌握这些搜索技巧 (google or baidu) 转载:https://tingtalk.me/search-tips/ 在大型局域网(互联网)的今天,你以为搜索是一门 ...
- Java学习笔记--异常机制
简介 在实际的程序运行过程中,用户并不一定完全按照程序员的所写的逻辑去执行程序,例如写的某个模块,要求输入数字,而用户却在键盘上输入字符串:要求打开某个文件,但是文件不存在或者格式不对:或者程序运行时 ...
- 201871030131-谢林江 实验二 个人项目—《D{0-1} KP》项目报告
项目 内容 课程班级博客链接 班级博客 这个作业要求链接 作业要求 我的课程学习目标 1.学习编写PSP2.完成个人项目实验要求3.在Github建仓 这个作业在哪些方面帮助我实现学习目标 1.首次编 ...
- Chrome插件开发入门
最近学习了Chrome插件的开发,总体来说上手还是很容易的,因为浏览器插件本质上依旧是网页,写几个demo基本就了解了他的开发过程. 完整项目:xmy6364/chrome-extension-get ...
- Seata搭建与分布式事务入门
在单体架构下,我们大多使用的是单体数据库,通过数据库的ACID特性支持,实现了本地事务.但是在微服务架构下复杂的业务关系中,分布式事务是不可避免的问题之一.Seata是Spring Cloud Ali ...
- SpringBoot+Gradle构建多模块项目
1 概述 Gradle由于构建速度比Maven快,且比Maven灵活,因此很多后端的应用都使用了Gradle进行构建,但一个问题是,Gradle的多模块项目比较难构建,再加上Gradle的更新非常快, ...