小五的个人杂货铺

Kubernetes 中如何实现灰度发布当你Kubernetes 集群中部署业务时，可以利用 Kubernetes 原生提供的灰度发布的方式去上线业务。这种方式是通过在旧版本和新版本的服务之间，定义一个差异化的 Label，根据不同版本之间的公共 Label 负载流量到后端 Pod，最终实现根据 Pod 的副本数控制流量的百分比。 如下图所示：用户定义了两个 Deployment 对象，其中旧版本名为 frontend-stable，有3个副本。新版本为 frontend-canary，有1个副本。此时定义了一个 Service 对象，使用它们之间公共的 Label 进行选择。这就使得用户访问 frontend 这个 Service 时，能以 3:1 的比例同时访问到两个版本。并且还可以通过调整副本数持续控制流量比例，最终达到完整上线。 Kubernetes 默认的实现方式在简单的部署场景下很有效，但是在一些复杂场景中，仍然会有较大的局限，如： 业务配置自动伸缩后，会直接影响灰度发布的流量比例 低百分比的流量控制占用资源高，如 1 % 的流量到达新版本，则至少需要 100 ...

简介： istio-proxy也是我们常说的sidecar，istio默认使用envoy注入的，envoy的日志级别包括trace, debug, info, warning, error, critical, off Envoy 访问日志记录了通过 Envoy 进行请求 / 响应交互的相关记录，可以方便地了解具体通信过程和调试定位问题。 修改日志级别的几种方式全局配置istio配置都是在configmap中的，可以通过修改configmap来修改全局的proxy日志级别： 开启 Envoy 访问日志，执行以下命令修改 istio 配置1kubectl -n istio-system edit configmap istio 1234data: mesh: |- accessLogEncoding: JSON accessLogFile: /dev/stdout 其中，accessLogEncoding表示 accesslog 输出格式，Istio 预定义了 TEXT 和 JSON 两种日志输出格式。默认使用 TEXT，通常改成 JSON 以提升...

前言Jaeger 是一个开源的端到端的分布式跟踪系统， 允许用户在复杂的分布式系统中监控和排查故障。 利用Rancher的安装方式安装cert-manager参考文档： jaeger requires：https://www.jaegertracing.io/docs/1.49/operator/#prerequisite cmctl（the tool which is to manage and verify cert-manager） install：https://cert-manager.io/v1.6-docs/usage/cmctl/#installation cert-manager verify：https://cert-manager.io/v1.6-docs/installation/verify/ 安装cert-manager：https://cert-manager.io/v1.6-docs/installation/kubectl/ 默认静态安装cert-manager：https://cert-manager.io/v1.6-docs/installa...

7层是指OSI七层协议模型，主要是：应用层（Application）、表示层（Presentation）、会话层（Session）、传输层（Transport）、网络层（Network）、数据链路层（Data Link）、物理层（Physical）。 OSI 是Open System Interconnect的缩写，意为开放式系统互联。 OSI 七层协议模型是一个通用的模型，可以用于各种网络。它提供了一个理解和描述网络通信的框架。 OSI七层参考模型的各个层次的划分遵循下列原则： 1、同一层中的各网络节点都有相同的层次结构，具有同样的功能。 2、同一节点内相邻层之间通过接口(可以是逻辑接口)进行通信。 3、七层结构中的每一层使用下一层提供的服务，并且向其上层提供服务。 4、不同节点的同等层按照协议实现对等层之间的通信。 高级图示 物理层（Physical Layer）物理层是OSI 模型的最低层，负责数据在物理介质（如电缆、光纤）上的传输。它定义了数据的物理格式、传输速率和电信号的形式。 OSI的物理层规范是有关传输介质的特这些规范通常也参考了其他组织制定的标准。连接头、...

支付宝相关概念网站支付DEMO传送门：手机网站支付 DEMO ｜ 网页&移动应用 RSA、加密加签、密钥 对称加密 对称加密：发送方和接收方用的是同一把密钥，存在问题：当某一方将密钥泄漏之后，发送的消息可以被截取获悉并且随意进行通信。 非对称加密 非对称加密：发送方和接收方使用的不是同一把密钥，发送方使用密钥A对明文进行加密，接收方使用密钥B对密文进行解密，然后接收方将回复的明文用密钥C进行加密，发送方使用密钥D进行解密。采用非对称加密的好处是：即使有密钥被泄漏也不能自由的通信。 公钥与私钥 公钥和私钥是一个相对概念 密钥的公私性是相对于生成者而言的。发送方通过密钥A对明文进行加密，密钥A是只有发送方自己知道的，接收方想要解密密文，就需要拿到发送方公布出来的密钥B。 一对密钥生成后，保存在生产者手里的就是私钥（自己持有，不公开） 生成者发布出去让大家用的就是公钥 此时： 密钥A 和 密钥C 就是私钥，私钥用于加密，确保发送的消息不会被他人篡改 密钥B 和 密钥D 就是公钥，公钥用于解密，可以暴露出去。 加密 和 数字签名 签名：为了防止中途传输...

创建blob存储为其创建一个单独的存储空间。 进入设置 依次建立npm仓库 创建npm(hosted)私有仓库(hosted改成allow redeploy，这样才能运行重复上传一个包，不然会报400：bad request) 创建npm(proxy)仓库(proxy的remote storage设置：当私有仓库和代理仓库缓存包里无请求的包时，就会通过这里配置的地址去服务器下载需要的包，然后再缓存下来) 创建npm(group)仓库 配置权限 注意点： npm install后报错如下，可通过配置npm bearer token realm解决 检查npm nexus的 Realms设置，把npm Bearer Token realm放入Active中，并保存 检查一下Nexus Repository Manager上的Anonymous是否开放 使用私有仓库方式为某一个组配置仓库地址 1npm config set @chint:registry http://10.104.30.197:8081/repository/npm-group/ 全局配...

记录一次node项目优化方案优化前: 以ubuntu发行版为基础镜像 不带小版本号 每次构建都从头构建(这里也推荐将package*json先copy过来进行install再copy . .,如果文件没变化,那就使用缓存,不重新构建) 优化后： 建立runtime基础镜像(包含提前安装好的基础依赖和环境, 包括node_modules),并使用alpine为基础镜像发行版 使用nexus管理项目包(docker/npm/maven) 指定具体版本号(只有 major version，没有指定 minor version、patch version。当该基础镜像 minor 或 patch 版本更新后，如果本地的镜像缓存也被清除了，那么打包就会使用新版本的基础镜像) 构建 Docker 镜像的时候，会缓存 Dockerfile 中尚未更改的所有步骤。所以，如果新构建时更改任何指令，将后的指令步骤将会重新来不再使用缓存。举例来说，就是指令 3 发生了变更，其后的 4-n 就会重跑并重新生成缓存。因此，编写 Dockerfile 的时候，就需要将最不可能产生更...

安装nexus312345678910111213141516171819202122mkdir -p /usr/local/nexus3chown -R 200 /usr/local/nexus3docker run -d \--privileged=true \--name=nexus3 \-u root \-p 8081:8081 \# 这几个端口给docker私有仓库使用，在创建仓库时指定，并且在Dockers中需要添加配置 "insecure-registries": ["ip:port"]-p 8001:8001 \-p 8002:8002 \-p 8003:8003 \# 启动容器时加入时间挂载，使用宿主机时间-v /etc/localtime:/etc/localtime:ro \-v /usr/share/zoneinfo/Asia/Shanghai:/etc/localtime:ro \-v /usr/local/nexus3/nexus-data:/nexus-data \-v /usr/local/nexus3/so...

先清理mainfests方法1 - Cleanup Policies查看docker repo 比如你的docker repo名字叫做test-repo，然后在nexus3首页的seatch下面找到docker，点进去随便查看一个已经上传的镜像 记住上面的Name选项，之后要用到 设定清理策略（clean policies） 在nexus3 设置中找到 Cleanup Policies 点击 Create Cleanup Policy 创建一个新的清理策略 注意到Asset Name Matcher区域，这里可以填写RE表达式，过滤的是第一步中得到的Name选项。比如你想要过滤所有以clean结尾的rabbitmq镜像，你可以这么编写你的表达式： 1v2/rabbitmq/manifests/.*-clean 如果你想要清理所有的镜像，而不只是rabbitmq 1v2/.*/manifests/.*-clean 当然你也可以根据情况选择是否设置镜像过期时间一起配合使用（注意这里的三个条件是逻辑与的关系）配置完成后，不要忘了点击下方进行预览，以...

关于MySQL的死锁 MySQL的死锁指的是两个事务互相等待的场景，这种循环等待理论上不会有尽头。 比如事务A持有行1的锁，事务B持有行2的锁，然后事务A试图获取行2的锁，事务B试图获取行1的锁，这样事务A要等待事务B释放行2的锁，事务B要等待事务A释放行1的锁，两个事务互相等待，谁也提交不了。 这种情况下MySQL会选择中断并回滚其中一个事务，使得另一个事务可以提交。MySQL会记录死锁的日志。 制造一个死锁的场景新建一个表，添加两条数据： 创建两个事务，事务执行的sql分别是： 事务A： 1234set autocommit=0;update medicine_control set current_count=1 where id='1';update medicine_control set current_count=1 where id='2';COMMIT; 事务B： 1234set autocommit=0;update medicine_control set current_count=2 where id=&...