小五的个人杂货铺

netfilter/conntrack 相关内核参数往往是用 Linux 服务器的互联网小公司业务量上去之后遇到的第 3 个 “新手怪”。（第 1 位：进程可用的 FD 不足，第 2 位：IP 临时端口不足 + TIME_WAIT 状态的连接过多导致无法建立新连接） 很多人以为 Linux 经过这么多年优化，默认参数应该 “足够好”，其实不是。默认参数面向 “通用” 服务器，不适用于连接数和访问量比较多的场景。 症状服务器负载正常，但请求大量超时，服务器／应用访问日志看不到相关请求记录。 在 dmesg 或 /var/log/messages 看到大量以下记录： 1kernel: nf_conntrack: table full, dropping packet. 原因服务器访问量大，内核 netfilter 模块 conntrack 相关参数配置不合理，导致 IP 包被丢掉，连接无法建立。 详细nf_conntrack 模块在 kernel 2.6.15（2006-01-03 发布）被引入，支持 IPv4 和 IPv6，取代只支持 IPv4 的 ip_con...

相关概念引自kubesphere - requests与limits 简介为了实现 K8s 集群中资源的有效调度和充分利用， K8s 采用requests和limits两种限制类型来对资源进行容器粒度的分配。每一个容器都可以独立地设定相应的requests和limits。这 2 个参数是通过每个容器 containerSpec 的 resources 字段进行设置的。一般来说，在调度的时候requests比较重要，在运行时limits比较重要。 一些本地临时存储的配置 **注: ** 当容器申请内存超过limits时会被oomkill，并根据重启策略进行重启。而cpu超过limit则是限流，但不会被kill 由于CPU资源是可压缩的，进程无论如何也不可能突破上限，因此设置起来比较容易。对于Memory这种不可压缩资源来说，它的Limit设置就是一个问题了，如果设置得小了，当进程在业务繁忙期试图请求超过Limit限制的Memory时，此进程就会被Kubernetes杀掉 1234567891011121314# requests: 可以使用requests来设置各容器需...

Nginx给网站添加用户认证配置（ Basic HTTP authentication） 说明：ngx_http_auth_basic_module模块实现让访问者只有输入正确的用户密码才允许访问web内容。web上的一些内容不想被其他人知道，但是又想让部分人看到。nginx的http auth模块以及Apache http auth都是很好的解决方案。 默认情况下nginx已经安装了ngx_http_auth_basic_module模块。 Nginx认证配置实例生成认证文件123# printf "test:$(openssl passwd -crypt 123456)\n" >> /home/htpasswd# cat /home/htpasswd test:xyJkVhXGAZ8tM **注意：**这里账号：test，密码：123456，记住认证文件路径 配置网站conf文件123456789101112131415server{ listen 80; server_name www.moer...

介绍 EnvoyFilter 提供了一种机制，可以自定义 Istio Pilot 生成的 Envoy 配置。使用 EnvoyFilter 修改某些字段的值、添加特定过滤器，甚至添加全新的监听器、集群等。这个功能必须小心使用，因为不正确的配置可能会破坏整个网格。与其他 Istio 网络对象不同，EnvoyFilters 是附加应用的。在特定命名空间中给定工作负载可以存在任意数量的 EnvoyFilters 。这些 EnvoyFilters 的应用顺序如下：所有位于配置根命名空间中的 EnvoyFilters ，然后是匹配工作负载命名空间中所有匹配到的 EnvoyFilters。 注意点注意1：此 API 的某些方面与 Istio 网络子系统以及Envoy XDS API 的内部实现密切相关。虽然EnvoyFilter API本身将保持向后兼容性，但通过此机制提供的任何 envoy 配置都应该在Istio代理版本升级时进行仔细监控，以确保已弃用字段被适当地删除和替换。 注意2：当多个Envoy Filters 绑定到给定名称空间中相同工作负载时，在创建时间顺序上按顺序处理所有补丁。...

1. Service 端口命名约束Istio 支持多平台，不过 Istio 和 Kubernetes 的兼容性是最优的，不管是设计理念，核心团队还是社区，都有一脉相承的意思。但 Istio 和 Kubernetes 的适配并非完全没有冲突，一个典型问题就是 Istio 需要 Kubernetes service 按照协议进行端口命名（port naming）。 端口命名不满足约束而导致的流量异常，是使用 mesh 过程中最常见的问题，其现象是协议相关的流控规则不生效，这通常可以通过检查该 port LDS 中 filter 的类型来定位。 原因Kubernetes 的网络对应用层是无感知的，Kubernetes 的主要流量转发逻辑发生在 node 上，由 iptables/ipvs 来实现，这些规则并不关心应用层里是什么协议。 Istio 的核心能力是对 7 层流量进行管控，但前提条件是 Istio 必须知道每个受管控的服务是什么协议，istio 会根据端口协议的不同，下发不同的流控功能（envoy filter），而 Kubernetes 资源定义里并不包括七层协议信...

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

前言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 就是公钥，公钥用于解密，可以暴露出去。 加密 和 数字签名 签名：为了防止中途传输...

记录一次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 的时候，就需要将最不可能产生更...