小五的个人杂货铺

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_connkt ...

Kubernetes 节点将conntrack_max值与节点上的 RAM 大小成比例地设置。高负载应用（尤其是在小型节点上）很容易超过conntrack_max，并导致连接复位和超时。 理论conntrack 是建立在 Netlifier 框架之上的功能。它对于高性能的 Kubernetes 复杂网络至关重要，其中节点需要跟踪数千个 Pod 和服务之间的连接信息。 在 Kubernetes 中, 默认值可以在 prometheus 指标中找到node_nf_conntrack_entries_limit（需要node_exporter） linux系统中可以通过以下指令查看【当然如果未配置过的话，默认值会以下面的公式计算出默认值】：sysctl net.netfilter.nf_conntrack_max conntrack_max值与节点的内存成正比，通常聚合代理类服务会需要持续跟踪大量连接【消耗大量的conntrack entries】。 问题现象如注意到服务存在各种连接问题和极高的错误率，如下： java 原因：org.apache.http.NoHttpRespon ...

相关概念引自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来设置各容器需要的最 ...

摘自： https://developer.jdcloud.com/article/2725 https://developer.jdcloud.com/article/2953 混沌工程介绍什么是混沌工程混沌工程是通过主动制造故障场景并根据系统在各种压力下的行为表现确定优化策略的一种系统稳定性保障手段，简单说就是通过主动注入故障的方式、提前发现问题，然后解决问题规避风险。 为什么要进行混沌演练随着互联网业务发展，微服务架构、分布式架构和虚拟化容器技术的广泛普及，软件架构的复杂度在不断提升，服务之间的依赖所带来的不确定性也成指数级增长，在这样的服务调用网中，任何一环出现的正常或者异常的变化，都有可能对其他服务造成类似蝴蝶效应一般的影响。目前营销体系的服务量级不断增加，整体链路增长以及数据流转复杂，对整个系统的可用性、稳定性挑战也越来越大，所以引入混沌演练，主动找出系统中的脆弱环节，然后针对性地进行加固、防范，从而避免故障发生时所带来的严重后果，进一步提升业务系统的高可用，提高业务系统应急保障能力。 混沌演练的价值应用混沌演练可以对系统抵抗扰动并保持正常运作的能力进行校验和评估,提前 ...

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.moerats.com ...

转自: https://blog.51cto.com/u_15127588/3305078 JetBrains 系列 IDE 有一个非常好用的 Kubernetes 的官方插件：JetBrains Kubernetes Plugin 。该插件支持资源对象关键字的自动补全和语法检查，这对于编写或者修改 YAML 文件非常方便。但是此前版本不支持 自定义的 CRD 对象，这对于该插件的易用性来说，略有一些遗憾。 现在新版的 Kubernetes 插件已经支持通过文件导入或者 URL 导入 CRD 定义文件，从而支持任意 CRD 资源对象的关键字自动补全和语法检查。 12Custom resource definition (CRD) supportCustom resources can be validated by providing complementary OpenAPI 2.0 files with CRD schemas and/or CRD resource definitions (YAML) (limited support). 下面以服务网格 Istio 为例， ...

介绍 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 个副本 ...

简介： 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 以提升可读性 ...