上一篇文章IoT边缘集群基于KubernetesEvents的告警通知实现目标告警恢复通知-经过评估无法实现原因:告警和恢复是单独完全不相关的事件,告警是Warning级别,恢复是Normal级别,要开启恢复,就会导致所有NormalEvents都会被发送,这个数量是很恐怖的;而且,除非特别有经验和耐心,否则无法看出哪条Normal对应的是告警的恢复.未恢复进行持续告警-默认就带的能力,无需额外配置.告警内容显示资源名称，比如节点和pod名称可以设置屏蔽特定的节点和工作负载并可以动态调整比如，集群001中的节点worker-1做计划性维护，期间停止监控，维护完成后重新开始监控。配置告警内容显示
背景边缘集群（基于树莓派+K3S)需要实现基本的告警功能。边缘集群限制CPU/内存/存储资源紧张，无法支撑至少需要2GB以上内存和大量存储的基于Prometheus的完整监控体系方案（即使是基于PrometheusAgent,也无法支撑）（需要避免额外的存储和计算资源消耗）网络条件，无法支撑监控体系，因为监控体系一般都需要每1min定时（或每时每刻）传输数据，且数据量不小；存在5G收费网络的情况，且访问的目的端地址需要开通权限，且按照流量收费，且因为5G网络条件，网络传输能力受限，且不稳定（可能会在一段时间内离线）;关键需求总结下来，关键需求如下：实现对边缘集群异常的及时告警，需要知道边缘集群
背景边缘集群（基于树莓派+K3S)需要实现基本的告警功能。边缘集群限制CPU/内存/存储资源紧张，无法支撑至少需要2GB以上内存和大量存储的基于Prometheus的完整监控体系方案（即使是基于PrometheusAgent,也无法支撑）（需要避免额外的存储和计算资源消耗）网络条件，无法支撑监控体系，因为监控体系一般都需要每1min定时（或每时每刻）传输数据，且数据量不小；存在5G收费网络的情况，且访问的目的端地址需要开通权限，且按照流量收费，且因为5G网络条件，网络传输能力受限，且不稳定（可能会在一段时间内离线）;关键需求总结下来，关键需求如下：实现对边缘集群异常的及时告警，需要知道边缘集群
?️Reference:IoT边缘计算系列文章什么是边缘容器？边缘容器的概念边缘容器是分散的计算资源，尽可能靠近最终用户或设备，以减少延迟、节省带宽并增强整体数字体验。可以访问互联网的设备数量每天都在增加。有包括但不限于：智能电视智能家居智能手机智能汽车物联网IoT创造的多种多样其他智能设备大多数用户运行对时间敏感的应用程序，滞后会降低用户体验的质量。遥远的集中式云服务存在高延迟，通常是应用程序性能不佳的罪魁祸首。开发边缘计算旨在使数据处理更接近用户并解决与网络相关的性能问题。具体而言，边缘容器允许组织通过将应用程序的关键组件移动到网络边缘来分散服务。通过将智能转移到边缘，组织可以实现更低的网
?️Reference:IoT边缘计算系列文章什么是边缘容器？边缘容器的概念边缘容器是分散的计算资源，尽可能靠近最终用户或设备，以减少延迟、节省带宽并增强整体数字体验。可以访问互联网的设备数量每天都在增加。有包括但不限于：智能电视智能家居智能手机智能汽车物联网IoT创造的多种多样其他智能设备大多数用户运行对时间敏感的应用程序，滞后会降低用户体验的质量。遥远的集中式云服务存在高延迟，通常是应用程序性能不佳的罪魁祸首。开发边缘计算旨在使数据处理更接近用户并解决与网络相关的性能问题。具体而言，边缘容器允许组织通过将应用程序的关键组件移动到网络边缘来分散服务。通过将智能转移到边缘，组织可以实现更低的网
开篇《K3s系列文章》《Rancher系列文章》问题概述202206065GIoT网关设备同时安装K3SServer,但是POD却无法访问互联网地址，查看CoreDNS日志提示如下：...[ERROR]plugin/errors:2update.traefik.io.A:readudp10.42.0.3:38545->8.8.8.8:53:i/otimeout[ERROR]plugin/errors:2update.traefik.io.AAAA:readudp10.42.0.3:38990->8.8.8.8:53:i/otimeout...即DNS查询forward到了8.8.8.8这个DN
开篇《K3s系列文章》《Rancher系列文章》问题概述202206065GIoT网关设备同时安装K3SServer,但是POD却无法访问互联网地址，查看CoreDNS日志提示如下：...[ERROR]plugin/errors:2update.traefik.io.A:readudp10.42.0.3:38545->8.8.8.8:53:i/otimeout[ERROR]plugin/errors:2update.traefik.io.AAAA:readudp10.42.0.3:38990->8.8.8.8:53:i/otimeout...即DNS查询forward到了8.8.8.8这个DN
1.问题背景项目在引用自研组件库后，启动后webpack报错热更新存在问题，无法正常启动2.解决方案在询问组件库开发同事，被告知无问题；百度无果；查找webpack源码后，发现能定位到报错的代码位置，却无力解决时。我决定使用控制变量法，禁用热更新插件，来解决问题。幸运的是，还真就解决了，注释掉热更新组件后，组件能正常引入了。3.结尾目前此问题还不知道原因，只能去找找其他热更新插件是否可用了。
1.问题背景项目在引用自研组件库后，启动后webpack报错热更新存在问题，无法正常启动2.解决方案在询问组件库开发同事，被告知无问题；百度无果；查找webpack源码后，发现能定位到报错的代码位置，却无力解决时。我决定使用控制变量法，禁用热更新插件，来解决问题。幸运的是，还真就解决了，注释掉热更新组件后，组件能正常引入了。3.结尾目前此问题还不知道原因，只能去找找其他热更新插件是否可用了。
目录1、Fail-Over：故障转移2、Fail-Fast：快速失败3、Fail-Back：失效自动恢复4、Fail-Safe：失效安全5、Forking：并行调用多个服务6、Broadcast：广播调用参考资料版权声明1、Fail-Over：故障转移Fail-Over意思是“故障转移，失败自动切换”，是一种备份操作模式。它的主要思路是：主要组件出现异常时，将其功能转移到具有同样功能的备份组件上。要点在于有主有备，且主发生故障时，可将备切换为主。比如HDFS的双NameNode，当ActiveNameNode出现故障时，可以启用StandbyNameNode来继续提供服务。【最佳实践】通常用于
