背景我的测试环境有两个Deployment，我想在开发的时候启动，30分钟没请求后自动关闭，不占用资源。 Sablier就解决了这个问题，它支持Kubernetes，并且支持Traefik。 环境traefik: v2.9.10kubernetes: v1.24.6+k3s1Sablier: v1.7.0 安装在K3S中，我们已经内置了Traefik，所以如果想安装插件，我们需要对内置的Traefik进行改造，添加插件。 由于K3S会周期性的执行 /var/lib/rancher/k3s/server/manifests 目录下的所有yaml，而如果我们修改了默认的traefik.yaml，K3S会自动恢复默认文件，所以我们这里需要新建一个yaml文件，用HelmChartConfig的方式修改traefik安装的配置即可。 创建配置文件 nano /var/lib/rancher/k3s/server/manifests/traefik-config.yaml 1234567891011121314151617181920212223apiVersion: helm.cattle. ...

背景在Traefik中，Fail2Ban是一个非常强大的插件，可以轻松实现IP黑名单，IP白名单，IP封禁等操作。我们可以根据不同的需求，选择封禁的时长。 比如：我想针对1分钟内请求100次以上的IP封禁1小时。对于比DDOS小很多的某些攻击，可以有效防止。（如果处于DDOS，大部分都是在服务商那就已经将云服务拉入小黑屋了，此时服务流量基本进不来了，所以这里只是针对小攻击的处理方法，或者某些暴力爬虫等） 对于Fail2Ban的原理，你可以参考Github，基本原理是时间窗口，go语言写这类工具再对接Kubernetes有天生的优势，所以这里就不再赘述了。 环境traefik: v2.9.10kubernetes: v1.24.6+k3s1Fail2Ban: v0.7.1 安装在K3S中，我们已经内置了Traefik，所以如果想安装插件，我们需要对内置的Traefik进行改造，添加插件。 由于K3S会周期性的执行 /var/lib/rancher/k3s/server/manifests 目录下的所有yaml，而如果我们修改了默认的traefik.yaml，K3S会自动恢复默认文件，所 ...

简介Traefik 是一个开源的可以使服务发布变得轻松有趣的边缘路由器。它负责接收你系统的请求，然后使用合适的组件来对这些请求进行处理。 除了众多的功能之外，Traefik 的与众不同之处还在于它会自动发现适合你服务的配置。当 Traefik 在检查你的服务时，会找到服务的相关信息并找到合适的服务来满足对应的请求。 Traefik 兼容所有主流的集群技术，比如 Kubernetes，Docker，Docker Swarm，AWS，Mesos，Marathon，等等；并且可以同时处理多种方式。（甚至可以用于在裸机上运行的比较旧的软件。） 使用 Traefik，不需要维护或者同步一个独立的配置文件：因为一切都会自动配置，实时操作的（无需重新启动，不会中断连接）。使用 Traefik，你可以花更多的时间在系统的开发和新功能上面，而不是在配置和维护工作状态上面花费大量时间。 核心概念Traefik 是一个边缘路由器，是你整个平台的大门，拦截并路由每个传入的请求：它知道所有的逻辑和规则，这些规则确定哪些服务处理哪些请求；传统的反向代理需要一个配置文件，其中包含路由到你服务的所有可能路由，而 ...

存储LonghornLonghorn是一个轻量级、可靠且功能强大的分布式块存储系统，适用于 Kubernetes。使用容器和微服务实现分布式块存储。Longhorn 为每个块储存设备卷创建一个专用的存储控制器，并在存储在多个节点上的多个副本之间同步复制该卷。存储控制器和副本本身是使用 Kubernetes 编排的。Longhorn 是免费的开源软件。它最初由Rancher Labs开发，现在作为云原生计算基金会的孵化项目进行开发。 优点 ： 企业级分布式块存储，无单点故障； 支持增量快照和远程备份恢复(NFS/S3兼容对象存储)； 定期快照和备份； 提供UI页面，管理方便； 教程： k8s持久化存储longhorn(安装篇) - 简书 (jianshu.com) https://zhangzhuo.ltd/articles/2022/05/19/1652929973831.html 现在我已经把mongodb和mysql的存储使用longhorn的classpath，只需要更改各个配置的存储部分即可，例如： mongo.yaml: 123456789volumeClaimT ...

前言k3s的备份我们采用 kube-backup，它能帮我们把每个命名空间里一些基础的yaml备份，比如deployment、svc、pvc等，并通过git账号配置，自动上传至git仓库 开始 下载源码 1git clone https://github.com/pieterlange/kube-backup.git 创建命名空间 1kubectl create ns kube-backup 将源码的配置文件里面，所有的kube-system改为kube-backup 1sed -i 's#namespace: kube-system#namespace: kube-backup#g' *.yaml 在源码目录下创建密钥对 1ssh-keygen -t rsa -f ./id_rsa -N '' 将git仓库域名或ip添加授信列表里 1ssh-keyscan gitee.com > known_hosts 将密钥和授信列表存入kube-backup中 1kubectl create secret gener ...

前言由于微服务日志分散在各个容器内，又不好做到统一时序查看，因此需要一个组件来观测日志，这里采用ELK，目前我们先创建单节点的elasticsearch和kibana。如果你想尝试使用二进制部署，可以看下这篇文章：【大数据】Elastic + canal + kibana 安装文档 | Leopold’s Blog (leofitz7.com) ElasticSearch这里的存储类我使用了rancher的local-path，自动帮我生成pv。节点默认在m2，请根据自身情况调整 elasticsearch.yaml 12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788899091929394959697989910010110210310410510610710810911011111211311 ...

前言在上文中，我成功从将SpringBoot转为go。接下来，我将尝试把redis锁改为etcd锁。 Redis锁和Etcd锁是两种常见的分布式锁实现方式，它们在设计和特性上存在一些区别。 存储系统：Redis是一个基于内存的键值数据库，而Etcd是一个高可用的分布式键值存储系统。 一致性模型：Redis使用主从复制或哨兵模式来提供高可用性，并且在某些情况下可能会存在数据不一致的风险。Etcd则采用了Raft一致性算法，确保了强一致性。 锁的实现方式：在Redis中，可以使用单个Redis实例或Redis集群作为锁服务。通常使用SETNX（SET if Not eXists）指令尝试在特定键上设置值，以获取锁，并使用DEL指令来释放锁。在Etcd中，可以通过创建一个有序的临时键（ephemeral key）来实现分布式锁。多个客户端尝试创建相同的键，只有最小的键持有者获得锁。 锁的可重入性：Redis锁不支持可重入性，即同一个线程/进程不能重复获取同一个锁。而Etcd可以通过维护客户端的标识符和计数器来实现可重入性。 锁的自动过期：Redis支持设置锁的过期时间，可以使用E ...

前言在上文中，我成功从MySQL到MongDB的转型，接下来，我将尝试将SpringBoot转为go Protocol首先，我需要让protoc即生成java代码，也生成go代码。 只需要指定 go_package 即可： 12syntax = "proto3";option go_package = "test/"; 由于我还不是很了解生成的机制，所以这里的包路径全都一样的，你可以尝试对包路径分类。由于我这里有对别的proto文件有引用，导致go的引包错误了，所以才出此下策，当然，所有的名称在声名时也保证了一定不重复。 由于java的代码是通过maven插件生成的，这里我采用原本的protoc命令执行生成go代码，所以我写了这个脚本： 1234protoc --go_out=./ --go-grpc_out=require_unimplemented_servers=false:./ --proto_path=src/main/proto src/main/proto/common/*.protoprotoc --go_out=./ - ...

如遇图片无法加载请使用代理访问 前言在上文中，我成功拆分了单体服务为多个SpringBoot微服务，本文将主要讲述在数据库中，MySQL到MongDB的转型 创建MongoDBMongoDB有多种创建方式，这里我选择的是比较稳妥的主从Replicate，版本是比较旧的4.4，因为机器的内存和带宽小，再加上网络延迟大，这里没有选择新版本的分片 巨页（Huge Pages）是一种Linux内核特性，它允许将连续的物理页面组合成一个大页面。每个大页面可以包含多个传统大小的页面，通常为2MB或1GB。 使用巨页可以提高系统的内存管理效率和性能。在一些内存密集型的应用场景中（例如数据库），使用巨页可以减少内存碎片，并且仅使用更少的页表项来映射相同数量的物理内存，从而降低了内存访问的延迟和CPU开销。 不过，使用巨页需要操作系统和应用程序的支持，并且可能需要进行一些额外的配置工作。因此它只适用于特定的应用场景，而不是所有的应用都会受益于使用巨页。 MongoDB官方文档中指出，在很多情况下，使用巨页并不能带来明显的性能提升，而且还可能会导致一些稳定性问题。具体来说，可能会遇到以下问题： ...

如遇图片无法加载请使用代理访问 前言在上个月的25号，我成功搭建了Nexus，在接下来的一个月中，我做了这些事情： 封装各个starter的jar包，上传至Nexus 拆分单体项目为多个微服务 引入ProtoBuf，多个微服务之间采用grpc通信 rancher创建项目，构建测试环境、生产环境 测试环境回归测试，生产环境回归测试 至此，我成功将单体服务拆分，共耗时一个月的时间，代码逻辑没有变化，拆分工作比较费心，但万事开头难，后面的开发会更加简单和高效，下面，我将详细论述这些操作的难点和细节，偏简单口语点，勿对号入座直接照搬。目前暂未考虑开源，仅提供一些思路，取之精华，弃之糟粕 starterleopold-spring-boot-starter我的项目都是基于SpringBoot的，因此一定需要一个starter来封装有关SpringBoot的内容，而且微服务之间的通讯基本是grpc，所以也会涵盖grpc的内容 pom.xml 内容如下： 1234567891011121314151617181920212223242526272829303132333435 ...