Liarlee's Notebook

发表于2024-04-12|更新于2025-09-23|Database

AWS-CNI 集成 Calico 并启用 WireGuard 加密

发表于2024-02-23|更新于2025-09-23|EKS

看了下说明，这个东西的主要作用是用于节点间 Pod 流量的加密。启动集群略 Helm 命令安装 Calico 添加一个helm repohelm repo add projectcalico https://docs.tigera.io/calico/charts 创建一个 value.yamlcat > values.yaml <<EOF installation: kubernetesProvider: EKS registry: reg.liarlee.site/docker.io EOF helm show values projectcalico/tigera-operator --version v3.27.2 通过命令安装kubectl create namespace tigera-operator helm install calico projectcalico/tigera-operator --version v3.27.2 -f values.yaml --namespace tigera-operator watch kubectl get pods -n calico-system 启用 WireGuardkubectl patch felixconfiguration default --type='merge' -p '{"spec":{"wireguardEnabled":true}}' # 在节点上面可以看到 wireguard 的网卡和内核模块，说明已经成功了。 # EKS 默认的 AMI 里面是带这个模块的，不需要手动安装，可以自动按需装载。 ~]$ lsmod | grep wireguard wireguard 98304 0 curve25519_x86_64 36864 1 wireguard libcurve25519_generic 49152 2 curve25519_x86_64,wireguard libchacha20poly1305 16384 1 wireguard ip6_udp_tunnel 16384 1 wireguard udp_tunnel 28672 1 wireguard ~]$ ip ad 35: wireguard.cali: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 8941 qdisc noqueue state UNKNOWN group default qlen 1000 link/none inet 192.168.137.134/32 scope global wireguard.cali valid_lft forever preferred_lft forever # 或者可以查看 > kubectl get felixconfiguration default -o yaml apiVersion: projectcalico.org/v3 kind: FelixConfiguration ... spec: bpfConnectTimeLoadBalancing: TCP bpfHostNetworkedNATWithoutCTLB: Enabled bpfLogLevel: "" floatingIPs: Disabled healthPort: 9099 logSeverityScreen: Info reportingInterval: 0s routeTableRange: max: 99 min: 65 vxlanVNI: 4096 wireguardEnabled: true 参考文档Project Calico：https://docs.tigera.io/calico/3.25/network-policy/encrypt-cluster-pod-traffic#enable-wireguard-for-a-cluster

使用 nsenter 从Kubernetes Node 进入容器网络 Namespace

发表于2024-01-10|更新于2025-09-23|EKS

记录一下使用 nsenter 进入容器的 network namespace 中抓包。在 TroubleShooting 的过程中可能是需要这个方法的。进入容器ns的步骤选中一个poddefault haydenarch-68865d5b56-cblc6 ● 1/1 Running 0 172.31.48.162 ip-172-31-53-61.cn-north-1.compute.internal 在节点上找到这个pod的容器id ： 02182f3e9137[root@ip-172-31-53-61 ~]$ nerdctl ps| grep archlinux 02182f3e9137 1234567.dkr.ecr.cn-north-1.amazonaws.com.cn/archlinux:latest "sleep infinity" 23 hours ago Up k8s://default/arch-68865d5b56-cblc6/arch 查找这个容器id的进程pid。[root@ip-172-31-53-61 ~]$ nerdctl inspect 02182f3e9137 | grep -i pid "Pid": 10306, nsenter 命令进入容器的名称空间。 [root@ip-172-31-53-61 ~]$ nsenter -t 10306 -n [root@ip-172-31-53-61 ~]$ ip ad 3: eth0@if25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc noqueue state UP group default link/ether 22:fb:14:7b:91:22 brd ff:ff:ff:ff:ff:ff link-netnsid 0 inet 172.31.48.162/32 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::20fb:14ff:fe7b:9122/64 scope link valid_lft forever preferred_lft forever 对比容器里面执行命令的结果： [root@haydenarch-68865d5b56-cblc6 /]$ ip ad 3: eth0@if25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc noqueue state UP group default link/ether 22:fb:14:7b:91:22 brd ff:ff:ff:ff:ff:ff link-netnsid 0 inet 172.31.48.162/32 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::20fb:14ff:fe7b:9122/64 scope link valid_lft forever preferred_lft forever 这时候就可以使用节点上面的工具来进行抓包了。测试可以看到在容器内部是没有tcpdump命令的. [root@haydenarch-68865d5b56-cblc6 /]$ tcpdump bash: tcpdump: command not found 在容器内发出一个ping包。 [root@haydenarch-68865d5b56-cblc6 /]$ ping www.bing.com -c 1 PING a-0001.a-msedge.net (13.107.21.200) 56(84) bytes of data. 64 bytes from 13.107.21.200 (13.107.21.200): icmp_seq=1 ttl=102 time=80.6 ms --- a-0001.a-msedge.net ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 80.608/80.608/80.608/0.000 ms 在节点上面进入容器的名称空间，使用tcpdump抓包。 [root@ip-172-31-53-61 ~]$ tcpdump -i any -n tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes 09:09:18.172140 IP 172.31.48.162.46458 > 10.100.0.10.domain: 22082+ A? www.bing.com.default.svc.cluster.local. (56) 09:09:18.172181 IP 172.31.48.162.46458 > 10.100.0.10.domain: 59743+ AAAA? www.bing.com.default.svc.cluster.local. (56) 09:09:18.172406 IP 10.100.0.10.domain > 172.31.48.162.46458: 59743 NXDomain*- 0/1/0 (149) 09:09:18.172470 IP 10.100.0.10.domain > 172.31.48.162.46458: 22082 NXDomain*- 0/1/0 (149) 09:09:18.172513 IP 172.31.48.162.51210 > 10.100.0.10.domain: 59281+ A? www.bing.com.svc.cluster.local. (48) 09:09:18.172533 IP 172.31.48.162.51210 > 10.100.0.10.domain: 43411+ AAAA? www.bing.com.svc.cluster.local. (48) 09:09:18.172635 IP 10.100.0.10.domain > 172.31.48.162.51210: 43411 NXDomain*- 0/1/0 (141) 09:09:18.172707 IP 10.100.0.10.domain > 172.31.48.162.51210: 59281 NXDomain*- 0/1/0 (141) 09:09:18.172743 IP 172.31.48.162.36420 > 10.100.0.10.domain: 41442+ A? www.bing.com.cluster.local. (44) 09:09:18.172773 IP 172.31.48.162.36420 > 10.100.0.10.domain: 6893+ AAAA? www.bing.com.cluster.local. (44) 09:09:18.172947 IP 10.100.0.10.domain > 172.31.48.162.36420: 41442 NXDomain*- 0/1/0 (137) 09:09:18.172985 IP 10.100.0.10.domain > 172.31.48.162.36420: 6893 NXDomain*- 0/1/0 (137) 09:09:18.173030 IP 172.31.48.162.54253 > 10.100.0.10.domain: 9603+ A? www.bing.com.cn-north-1.compute.internal. (58) 09:09:18.173053 IP 172.31.48.162.54253 > 10.100.0.10.domain: 61573+ AAAA? www.bing.com.cn-north-1.compute.internal. (58) 09:09:18.173130 IP 10.100.0.10.domain > 172.31.48.162.54253: 9603 NXDomain* 0/1/0 (173) 09:09:18.173863 IP 10.100.0.10.domain > 172.31.48.162.54253: 61573 NXDomain 0/1/0 (173) 09:09:18.173893 IP 172.31.48.162.49537 > 10.100.0.10.domain: 64334+ A? www.bing.com. (30) 09:09:18.173941 IP 172.31.48.162.49537 > 10.100.0.10.domain: 31567+ AAAA? www.bing.com. (30) 09:09:18.174269 IP 10.100.0.10.domain > 172.31.48.162.49537: 64334 5/0/0 CNAME www-www.bing.com.trafficmanager.net., CNAME cn-bing-com.cn.a-0001.a-msedge.net., CNAME a-0001.a-msedge.net., A 13.107.21.200, A 204.79.197.200 (311) 09:09:18.174345 IP 10.100.0.10.domain > 172.31.48.162.49537: 31567 3/1/0 CNAME www-www.bing.com.trafficmanager.net., CNAME cn-bing-com.cn.a-0001.a-msedge.net., CNAME a-0001.a-msedge.net. (325) 09:09:18.174537 IP 172.31.48.162 > 13.107.21.200: ICMP echo request, id 45375, seq 1, length 64 09:09:18.255142 IP 13.107.21.200 > 172.31.48.162: ICMP echo reply, id 45375, seq 1, length 64 退出的方式直接使用exit即可，就回到了host本身的ns里面。

源地址检查造成丢包的分析

发表于2024-01-10|更新于2025-09-23|EKS

问题网络访问路径：Client –> NLB –> Application Pod 特别的部分：NLB 开启了保留源地址就意味着 NLB 在转发网络流量的时候不会改变数据包五元组内的SourceIP，这时候对于后端的Pod和节点来说，收到的数据包的ip地址来源直接是Client 的IP 地址，这会导致所有的流量其实都是来自于VPC之外的。 NLB在这其中变成了一个透明代理。从 NLB 发到后端application pod 中的流量会有偶尔timeout的情况，并不是所有的请求都会timeout ，从客户端抓包显示tcp握手的时候就没有成功，第一个syn包出去就一直没有回复，然后继续重发等待。由于后端的pod比较多，并且nlb在四层做了负载均衡，很难定位到某次的请求具体到了哪个后端pod上面。写下这些的时候我已经知道了问题的答案是由于 VPC CNI 的一个 env ， AWS_VPC_K8S_CNI_EXTERNALSNAT 会指定是否做 SNAT，比较早的版本， cni 插件没有对 SNAT 在iptables上面进行标记和处理，这样会导致过不了操作系统的网络报文地址校验，进而导致丢包。关于 linux 的数据包源地址校验，也就是 rp_filter 的参数，在EKS中默认都是1 。 net.ipv4.conf.default.rp_filter = 1 net.ipv4.conf.all.rp_filter = 1 rp_filter参数用于控制系统是否开启对数据包源地址的校验。rp_filter参数有三个值，0、1、2，具体含义： 0：不开启源地址校验。 1：开启严格的反向路径校验。对每个进来的数据包，校验其反向路径是否是最佳路径。如果反向路径不是最佳路径，则直接丢弃该数据包。 2：开启松散的反向路径校验。对每个进来的数据包，校验其源地址是否可达，即反向路径是否能通（通过任意网口），如果反向路径不同，则直接丢弃该数据包。默认的情况下，这个参数是1，因此：数据包发到了eth1网卡，如果这时候开启了rp_filter参数，并配置为1，则系统会严格校验数据包的反向路径。从路由表中可以看，返回响应时数据包要从eth0网卡出，即请求数据包进的网卡和响应数据包出的网卡不是同一个网卡，这时候内核会判断该反向路径不是最佳路径，而直接丢弃该请求数据包。确认是否存在这个原因的丢包From ： https://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.kernel.rpf.html 定位是否存在丢包两个设置都是关闭的状态 ~# cat /proc/sys/net/ipv4/conf/enp3s0/rp_filter 0 ~# cat /proc/sys/net/ipv4/conf/enp3s0/log_martians 0 rp_filter导致的丢包数量可以通过netstat命令查看 netstat -s | grep IPReversePathFilter 让内核输出日志到 /var/log/messages 或者 dmesg sysctl -w net.ipv4.conf.all.log_martians=1 输出的结果大概是这样的。 IPv4: martian source 10.185.203.166 from 10.185.203.172, on dev eth1 ll header: 00000000: fa 16 3e dd 7b bb fa 16 3e 28 00 60 08 00 排查路由表和 Iptables当 AWS_VPC_K8S_CNI_EXTERNALSNAT 为 False 的时候查看节点的路由rule： [root@ip-172-31-53-61 ~]# ip rule ls 0: from all lookup local 512: from all to 172.31.49.222 lookup main 512: from all to 172.31.52.222 lookup main 512: from all to 172.31.59.203 lookup main 512: from all to 172.31.61.61 lookup main 512: from all to 172.31.49.246 lookup main 512: from all to 172.31.58.47 lookup main 512: from all to 172.31.53.79 lookup main 512: from all to 172.31.63.97 lookup main 512: from all to 172.31.53.74 lookup main 512: from all to 172.31.54.196 lookup main 512: from all to 172.31.51.218 lookup main 512: from all to 172.31.63.248 lookup main 512: from all to 172.31.54.200 lookup main 512: from all to 172.31.51.108 lookup main 512: from all to 172.31.56.137 lookup main 512: from all to 172.31.54.85 lookup main 512: from all to 172.31.51.82 lookup main 512: from all to 172.31.57.72 lookup main 512: from all to 172.31.59.200 lookup main 512: from all to 172.31.58.18 lookup main 512: from all to 172.31.55.235 lookup main 512: from all to 172.31.48.162 lookup main 512: from all to 172.31.60.128 lookup main 512: from all to 172.31.50.246 lookup main 512: from all to 172.31.61.216 lookup main 512: from all to 172.31.55.130 lookup main 512: from all to 172.31.49.208 lookup main 512: from all to 172.31.55.135 lookup main 512: from all to 172.31.50.208 lookup main 512: from all to 172.31.63.121 lookup main 512: from all to 172.31.52.205 lookup main 512: from all to 172.31.52.71 lookup main 512: from all to 172.31.51.7 lookup main 512: from all to 172.31.53.238 lookup main 1024: from all fwmark 0x80/0x80 lookup main 1536: from 172.31.56.137 lookup 2 1536: from 172.31.54.85 lookup 2 1536: from 172.31.51.82 lookup 2 1536: from 172.31.57.72 lookup 2 1536: from 172.31.59.200 lookup 2 1536: from 172.31.58.18 lookup 2 1536: from 172.31.55.235 lookup 2 1536: from 172.31.48.162 lookup 2 1536: from 172.31.60.128 lookup 2 1536: from 172.31.50.246 lookup 2 1536: from 172.31.61.216 lookup 2 1536: from 172.31.55.130 lookup 2 1536: from 172.31.49.208 lookup 2 1536: from 172.31.55.135 lookup 2 1536: from 172.31.50.208 lookup 3 1536: from 172.31.63.121 lookup 3 1536: from 172.31.52.205 lookup 3 1536: from 172.31.52.71 lookup 3 1536: from 172.31.51.7 lookup 3 1536: from 172.31.53.238 lookup 3 32766: from all lookup main 32767: from all lookup default 路由表 main： [root@ip-172-31-53-61 ~]# ip r s table main default via 172.31.48.1 dev eth0 169.254.169.254 dev eth0 172.31.48.0/20 dev eth0 proto kernel scope link src 172.31.53.61 172.31.48.162 dev enicfd09b318e8 scope link 172.31.49.208 dev eni3512a649bfb scope link 172.31.49.222 dev eni8cf9e51b58a scope link 172.31.49.246 dev eni9f41e641d45 scope link 172.31.50.208 dev eniffd28bfda2d scope link 172.31.50.246 dev eni1abad8afd57 scope link 172.31.51.7 dev eni76e381844d3 scope link 172.31.51.82 dev eni524077fd828 scope link 172.31.51.108 dev eni08e24263c30 scope link 172.31.51.218 dev enicb4edb90122 scope link 172.31.52.71 dev eni61a9554ce92 scope link 172.31.52.205 dev eniabe0e0a95e5 scope link 172.31.52.222 dev eni60eac028c5b scope link 172.31.53.74 dev enibecb9c399f8 scope link 172.31.53.79 dev eni6c5800d82af scope link 172.31.53.238 dev eni5a413534f4e scope link 172.31.54.85 dev eni2acd4947ff6 scope link 172.31.54.196 dev eni54f6d6a6254 scope link 172.31.54.200 dev eni47a45758006 scope link 172.31.55.130 dev ...

安装 headscale 建立自己的 Tailnet

发表于2023-12-27|更新于2025-09-23|Application

Tailscale 虽然是 mesh 的网络模式, 可以点对点的连接所有设备, 能直连会尽量直接连接, 然鹅还是需要一个默认的 server 来进行服务发现和临时中转流量. 那么大概的配置框架就已经出现了, 一个服务发现中心, 和多个不同的客户端.开始的时候直接使用的 tailscale + github 账户登录的方式使用, 然后发现 github 账户直接托管的中心服务不能关闭国外的中转服务器, 这就比较难受, 本来可以直通的线路走了国外的中转不稳定, 会断, 最后还是走国内的便宜云服务器自己维护了一个开源的 headscale 作为中心服务. 安装 Headscaleheadscale 官方文档现在的 headscale 容器镜像的是有问题的，不太好用，还得花时间修。 Update: 看起来现在是修复了, 并且费点儿劲可以用起来, 但是不确定稳定性如何. 我准备了这些: 域名和域名证书一台 Debian 的云服务器公网 ip 地址具体的安装步骤就是按照官方网站走下来就可以了.一些条件:需要注意的地方就是备案, 不备案会导致无法使用 443.那么需要在tailscale的配置文件中指定端口, 让 tailscale 监听在一个不常用的端口上. 因为没有写清楚 server 的地址和端口, 折腾了一天… 一度怀疑是不是换端口也不行, 必须备案 … 配置文件headscale ~$ vim /etc/headscale/config.yaml # 大约在配置文件的 13行左右. server_url 这个字段需要写成 https://YOURHOSTNAME.YOURDOMAIN:PORT 就可以了. 大约在配置文件的77行左右, 会有一个 DEPR 集成的服务, 开启这个服务之后, 可以使用当前的服务器直接作为DEPR中转节点. 77 derp: 78 server: 79 # If enabled, runs the embedded DERP server and merges it into the rest of the DERP config 80 # The Headscale server_url defined above MUST be using https, DERP requires TLS to be in place 81 enabled: true 绑定证书的位置在大约 151行之后, 我使用自己签发的证书, 就是直接配置 182 183 两行的参数就行. 181 ## Use already defined certificates: 182 tls_key_path: /path/to/cert.key 183 tls_cert_path: /path/to/cert.pem 关闭了官方的DERP服务列表: 98 # List of externally available DERP maps encoded in JSON 99 #urls: 100 # - https://controlplane.tailscale.com/derpmap/default 101 102 # Locally available DERP map files encoded in YAML 103 # 104 # This option is mostly interesting for people hosting 105 # their own DERP servers: 106 # https://tailscale.com/kb/1118/custom-derp-servers/ 107 # 108 # paths: 109 # - /etc/headscale/derp-example.yaml 110 paths: [] 关闭了 OverwriteDNS, 总是会尝试将客户的默认DNS服务器重写为 TailNet DNS. 204 dns_config: 205 # Whether to prefer using Headscale provided DNS or use local. 206 override_local_dns: false 安装tailscale客户端按照安装文档直接安装, 不一样的发行版(是的, Windows 也是 Linux 发行版) 安装方式不同, 基本上启动之后都能用, 完成度非常高. 注册节点的命令节点注册命令记录. sudo tailscale up --accept-dns=false --advertise-exit-node --advertise-routes=192.168.31.0/24 --login-server=https://YOURHOSTNAME.YOURDOMAIN:PORT --accept-routes # 也可以是: sudo tailscale up --accept-dns=false --advertise-exit-node --login-server=https://YOURHOSTNAME.YOURDOMAIN:PORT --accept-routes # 或者是: sudo tailscale up --accept-dns=false --login-server=https://YOURHOSTNAME.YOURDOMAIN:PORT --accept-routes # 最后是: sudo tailscale up --accept-dns=true --login-server=https://YOURHOSTNAME.YOURDOMAIN:PORT --accept-routes 这个命令执行完毕之后, 会返回一个网页, 网页打开里面有一个命令, 复制命令去 headscale 服务器的命令行(bash)里面执行一下,节点就注册进来了. 更新运行中的 Tailscale 客户端的设置最近需要更新我的一个节点，发布 VPC 内的 CIDR 块, 这个设置之前没有 advertise-route 参数进行更新。这个实例在我的默认VPC里面，这样的话这个实例就直接变成了这个VPC内的IGW, 流量会通过这个实例发送到VPC内, 可以直接将这个网络范围内的DNS指向VPC内的 .2 Resolver, 甚至感觉可以直接在家用 EFS 这类的东西了. 当然, 如果节点需要变动之前运行的参数, 是需要给出和之前一致的参数, 然后添加或者变更其中的一部分的. sudo tailscale up --accept-dns=false --advertise-exit-node --login-server=https://YOURHOSTNAME.YOURDOMAIN:PORT --accept-routes --advertise-routes=172.31.0.0/16 问题汇总查看当前客户端的网络状况 ╰─>$ tailscale netcheck Report: * UDP: true * IPv4: yes, PUBLIC_IP:35941 * IPv6: no, but OS has support * MappingVariesByDestIP: false * PortMapping: * CaptivePortal: false * Nearest DERP: Headscale Embedded DERP * DERP latency: - headscale: 24.3ms (Headscale Embedded DERP) 测试ping: ╰─>$ tailscale ping --until-direct -c 0 100.64.0.9 pong from home-SOME_NODE (100.64.0.9) via PUBLIC_IP:50177 in 6ms

tailscale 结合 Sunshine 串流

发表于2023-12-27|更新于2025-09-23|Application

既然 EC2 显卡都已经能用了，为啥不能直接启动一个 steam 呢？于是。。。安装的步骤比较简单： # Sunshine 用来作为 stream hosting sudo pacman -S sunshine # Steam 以及 Steam-navtive 是 steam 的runtime， ttf 是为了可以正常的显示中文字体，好像字体上面是最常见的问题，比如显示出来是一堆方块。 sudo pacman -S steam-native-runtime sudo pacman -S steam ttf-liberation 这些安装完成之后我自己直接 drun 去调用 steam 就可以了。启动使用的desktop 文件叫作 steam(native) 启动之后登录，然后可以正常下载游戏了。默认可以下载的游戏都是原生支持linux的，不支持的可以在steam的设置里面打开proton兼容，之后steam的界面上就不会区分任何平台了。手柄支持手柄默认不能传递到hosting， sunshine 的启动日志里面有报错： [2023:12:27:21:35:33]: Error: Could not create Sunshine Gamepad: Permission denied [2023:12:27:21:35:33]: Error: Could not create Sunshine Gamepad: Permission denied 给予这个报错的搜索结果有两个：添加当前的用户到 input 组里面 usermod -a -G input ec2-user # checking groups ec2-user 第二个方案是，确保自己的内核装载 uinput 模块。 modprobe uinput 同时还在文档里面找到了另一个地方，需要配置一个 udev ruleecho 'KERNEL=="uinput", SUBSYSTEM=="misc", OPTIONS+="static_node=uinput", TAG+="uaccess"' | \ sudo tee /etc/udev/rules.d/85-sunshine.rules 或者这文档以及这个Issue 我目前不太确定具体哪个是正确的, 因为重启这个实例的时候把tailscale给玩儿没了.. 现在连不上了…闹心

Redis 笔记

发表于2023-12-22|更新于2025-09-23|Database

ElastiCache主要概念 ElastiCache nodesA node is the smallest building block of an ElastiCache deployment.node is a fixed-size chunk of secure, network-attached RAM.总结来说，就是ec2实例上面跑了相同版本的Engine for Redis。 ElastiCache for Redis shards A Redis shard (called a node group in the API and CLI) is a grouping of one to six related nodes. A Redis (cluster mode disabled) cluster always has one shard.Redis (cluster mode enabled) clusters can have up to 500 shards, with your data partitioned across the shards. Shard 是多个 Nodes 的集合，或者叫作节点组. 一个Shard包括的节点有不同的角色，一个Primary 和最多5个 Replica. ElastiCache for Redis clustersA Redis cluster is a logical grouping of one or more ElastiCache for Redis shards. Data is partitioned across the shards in a Redis (cluster mode enabled) cluster.集群模式关闭， 1 Cluster – 1 Shard – 1 - 6 Nodes: 1 Primary and 5 Nodes集群模式开启， 1 Cluster – 500 Shard – 1 - 6 Nodes: 1 Primary Per Shard ElastiCache for Redis replicationRedis (cluster mode disabled) clusters support one shard (in the API and CLI, called a node group).Redis (cluster mode enabled) clusters can have up to 500 shards, with your data partitioned across the shards. 每个Replica都是Primary中全部数据的复制。 Replica使用异步的方式进行与Primary的数据同步。第一次 psync2 全量复制所有内存当前存储的数据，后续使用redis的增量复制。 AWS Regions and availability zones目前中国区不能使用 GlobalStore，并且Region之间也是无法相互同步数据的。在不同的az 之间可以做高可用来降低停机的时间。 ElastiCache for Redis endpointsAn endpoint is the unique address your application uses to connect to an ElastiCache node or cluster. Redis 禁用集群模式的单节点端点单节点的集群端点用于读取和写入. In one word, Single Primary, read and write at one point.用这个节点的 Endpoint 即可。 Redis 禁用集群模式的多节点端点多节点有两个不同的端点， Primary 端点总是连接到Primary 节点，故障切换会切换这个dns指向的后端。Reader Endpoint 在所有的 Replica节点之间分流Connection 用来提供读取行为。用控制台上面的 Primary Endpoint 和 Reader Endpoint Redis 启用集群模式的端点集群模式下，只是配置一个endpoint，但是连接到Endpoint之后，客户端可以发现所有的主节点和从节点。 ** 用Configuration Endpoint 可以找到集群内部的每一个 Primary 和 Replica节点 ** ElastiCache parameter groupsCache parameter groups are an easy way to manage runtime settings for supported engine software. Parameters are used to control memory usage, eviction policies, item sizes, and more. 简单来说，创建每一个配置文件在aws的控制台上，可以调整一部分Redis的参数，然后可能在集群内可以实时生效，也可能需要触发一次Failover才能生效。elasticache的参数管理通常来说，改动了参数组中的几个参数可能会需要重启节点： activerehashing databases ElastiCache for Redis securityPENDING… Maybe follow offical guide. ElastiCache security groups创建集群的时候需要指定一个安全组，需要放行 6379 port， DONE。 ElastiCache subnet groups子网组是运行 Redis 的所有子网的集合，创建一个子网，让托管的节点的把ENI放在这个子网里面，私有子网。 ElastiCache for Redis backups备份特定时间的数据，可以使用这个用来还原成新的集群，或者是创建一个集群的种子，备份中包括所有的data，和一部分集群的metadata。bgsave 或者 forkless save, 这两个取决于是否有足够的内存空间，当空间充足的时候使用的默认的 bgsave，但是肯定的是， bhsave 会有性能的开销，所以最好是使用副本节点来创建备份或者快照。对于forkless本身是另一个机制，但是forkless会尝试delay 写入的延迟，从而确保不会积累过多的change 导致内存压力过大失败。 ElastiCache eventsPENDING… Maybe follow offical guide. Redis 缓存穿透，击穿和雪崩穿透主要是指异常的查询请求，缓存未命中的场景下直接访问后端，后端承载了大量请求导致的崩溃。目前看到需要两个条件：数据在缓存层未命中。大量的请求转移到了后端。请求的数据可能在缓存层以及后端都不存在。避免的方法可能有：在redis 前面添加一个 BloomFilter，在请求进来的时候进行过滤，对于异常的请求直接拒绝或者返回一个NULL。提前缓存一部分数值为 NULL 的数据，在缓存层直接接下这些请求。这个本身是有点问题的。击穿这个概念是指的少部分热点数据被大量的查询时候，数据突然从缓存中消失，可能是过期也可能删除等等，这样有大量的相同请求发送到后端。解决方案：设置部分数据永远不过期。后端进行加分布式锁。雪崩批量的热数据过期，这时候大部分的请求可能还在继续尝试查询不同的数据，直接将这些请求发送到了后端的数据库，数据库崩了。解决方案：创建多个实例，和副本来提高可用性。后端加锁限流。调整过期时间，让不同的数据过期的时间错开，防止批量的key 相同的时间过期。总结起来就是，避免缓存在特定的场景下失效，想各种方法保护缓存的可用性。 More NoteCOB: Client Output Buffer, Primary 向 Replica 同步数据使用， Max Memory 没有计算这部分的内存，使用的是Redis引擎之外的内存（os管理的内存）。 Policy ： LRU 不严格，随机选择三个。maxmemory-sample: 3，可以调大。 sample越大，信号的时间越长。 Reclaim策略里面，每秒扫描200个key，如果数据量比较大的话， Redis会进入loop阶段，反复尝试Reclaim到25% 以下。可以尝试使用 scan 命令扫描全部的数据，遍历所有的key，这样会触发lazyway主动进行回收。扫描的指令： scan 0 match * count 20000 LRU vs LFU 为了保持主从一致， primary 上过期或者删除的key，会同步发送一个显式的 delete 指令，这个会统计在replica的settypecmd。 snapshot里面的数据在恢复的时候，会检查key 的ttl ，如果超过会直接删除。在Redis内存与物理内存mapping由操作系统的虚拟内存管理器和指定的内存分配器进行处理。关于Info指令的所有参数的解释：https://redis.io/commands/info/ localhost:6379> info memory # Memory used_memory:938464 used_memory_human:916.47K # Redis 存储数据的使用量 used_memory_rss:10747904 used_memory_rss_human:10.25M # Redis 常住内存集的用量 used_memory_peak:1134048 used_memory_peak_human:1.08M # Redis 的内存峰值 used_memory_peak_perc:82.75% used_memory_overhead:888488 used_memory_startup:865904 used_memory_dataset:49976 used_memory_dataset_perc:68.88% allocator_allocated:1479168 # 内存分配器已经分配的量 allocator_active:1601536 allocator_resident:4575232 total_system_memory:8182751232 total_system_memory_human:7.62G # 系统内存的总量 used_memory_lua:31744 used_memory_vm_eval:31744 used_memory_lua_human:31.00K # Lua 引擎的内存使用量 used_memory_scripts_eval:0 number_of_cached_scripts:0 number_of_functions:0 number_of_libraries:0 used_memory_vm_functions:32768 used_memory_vm_total:64512 used_memory_vm_total_human:63.00K used_memory_functions:184 used_memory_scripts:184 used_memory_scripts_human:184B maxmemory:0 # Max Memory 当前的配置 maxmemory_human:0B maxmemory_policy:noeviction allocator_frag_ratio:1.08 allocator_ ...

CFS 调度器资料

发表于2023-12-22|更新于2025-09-23|Linux

https://docs.kernel.org/scheduler/sched-design-CFS.htmlhttp://arthurchiao.art/blog/linux-cfs-design-and-implementation-zh/#11-cfs%E8%BF%9B%E7%A8%8Btask%E7%9A%84%E5%85%AC%E5%B9%B3%E8%B0%83%E5%BA%A6https://danluu.com/cgroup-throttling/https://heapdump.cn/article/4235306

追踪数据包经过的iptables规则

发表于2023-12-22|更新于2025-09-23|Linux

https://stackoverflow.com/questions/47645859/meaning-of-modules-instances-in-proc-modules Lsmod命令基于manpage的说明，这个命令的数据来源是： /proc/modules [root@centos ~]# lsmod Module Size Used by iptable_nat 12875 0 nf_conntrack_ipv4 19149 1 nf_defrag_ipv4 12729 1 nf_conntrack_ipv4 nf_nat_ipv4 14115 1 iptable_nat nf_nat 26583 1 nf_nat_ipv4 nf_conntrack 143360 3 nf_nat,nf_nat_ipv4,nf_conntrack_ipv4 iptable_filter 12810 0 nfit 59735 0 libnvdimm 163620 1 nfit iosf_mbi 15582 0 crc32_pclmul 13133 0 ghash_clmulni_intel 13273 0 aesni_intel 189456 0 ppdev 17671 0 lrw 13286 1 aesni_intel gf128mul 15139 1 lrw glue_helper 13990 1 aesni_intel ablk_helper 13597 1 aesni_intel cryptd 21190 3 ghash_clmulni_intel,aesni_intel,ablk_helper parport_pc 28205 0 parport 46395 2 ppdev,parport_pc i2c_piix4 22401 0 pcspkr 12718 0 ip_tables 27126 2 iptable_filter,iptable_nat xfs 1014152 1 libcrc32c 12644 3 xfs,nf_nat,nf_conntrack crct10dif_pclmul 14307 0 crct10dif_common 12595 1 crct10dif_pclmul crc32c_intel 22094 1 nvme 32382 1 serio_raw 13434 0 ena 96895 0 nvme_core 63547 3 nvme sunrpc 366617 1 /proc/modules 的输出结果 [root@centos ~]# cat /proc/modules iptable_nat 12875 0 - Live 0xffffffffc0661000 nf_conntrack_ipv4 19149 1 - Live 0xffffffffc065b000 nf_defrag_ipv4 12729 1 nf_conntrack_ipv4, Live 0xffffffffc05fd000 nf_nat_ipv4 14115 1 iptable_nat, Live 0xffffffffc05f4000 nf_nat 26583 1 nf_nat_ipv4, Live 0xffffffffc0603000 nf_conntrack 143360 3 nf_conntrack_ipv4,nf_nat_ipv4,nf_nat, Live 0xffffffffc0634000 iptable_filter 12810 0 - Live 0xffffffffc05dd000 nfit 59735 0 - Live 0xffffffffc066d000 libnvdimm 163620 1 nfit, Live 0xffffffffc060b000 iosf_mbi 15582 0 - Live 0xffffffffc05ed000 crc32_pclmul 13133 0 - Live 0xffffffffc05e5000 ghash_clmulni_intel 13273 0 - Live 0xffffffffc059e000 aesni_intel 189456 0 - Live 0xffffffffc05ad000 ppdev 17671 0 - Live 0xffffffffc05a4000 lrw 13286 1 aesni_intel, Live 0xffffffffc0575000 gf128mul 15139 1 lrw, Live 0xffffffffc0590000 glue_helper 13990 1 aesni_intel, Live 0xffffffffc0570000 ablk_helper 13597 1 aesni_intel, Live 0xffffffffc0418000 cryptd 21190 3 ghash_clmulni_intel,aesni_intel,ablk_helper, Live 0xffffffffc0569000 parport_pc 28205 0 - Live 0xffffffffc0596000 parport 46395 2 ppdev,parport_pc, Live 0xffffffffc0583000 i2c_piix4 22401 0 - Live 0xffffffffc057c000 pcspkr 12718 0 - Live 0xffffffffc0466000 ip_tables 27126 2 iptable_nat,iptable_filter, Live 0xffffffffc045e000 xfs 1014152 1 - Live 0xffffffffc0470000 libcrc32c 12644 3 nf_nat,nf_conntrack,xfs, Live 0xffffffffc0459000 crct10dif_pclmul 14307 0 - Live 0xffffffffc0438000 crct10dif_common 12595 1 crct10dif_pclmul, Live 0xffffffffc046b000 crc32c_intel 22094 1 - Live 0xffffffffc041d000 nvme 32382 1 - Live 0xffffffffc040f000 serio_raw 13434 0 - Live 0xffffffffc0407000 ena 96895 0 - Live 0xffffffffc0440000 nvme_core 63547 3 nvme, Live 0xffffffffc0427000 sunrpc 366617 1 - Live 0xffffffffc03ac000 调试 Iptables 的方法Kubernetes 里面大量的使用了iptables 规则的各种转换，可以使用iptables的trace功能进行追踪，查看具体经过了哪些链表。 iptables -t raw -A PREROUTING -p tcp -s 172.31.47.174/32 -j TRACE or iptables -t raw -A PREROUTING -p tcp -d 172.31.71.167 --dport 8090 -j TRACE modprobe ipt_LOG ip6t_LOG nfnetlink_log modprobe nf_log_ipv4 xtables-monitor --trace 完成之后就可以在 message 里面看到记录了。 kern :warn : [Thu Sep 21 15:01:24 2023] TRACE: raw:PREROUTING:policy:2 IN=eth3 OUT= MAC=02:19:e6:40:fc:c8:02:55:96:c9:21:66:08:00 SRC=172.31.47.174 DST=172.31.55.27 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=26039 DF PROTO=TCP SPT=22896 DPT=8090 SEQ=1763415057 ACK=0 WINDOW=62727 RES=0x00 SYN URGP=0 OPT (020423010402080ADBFD1C1B0000000001030307) kern :warn : [Thu Sep 21 15:01:24 2023] TRACE: mangle:PREROUTING:policy:4 IN=eth3 OUT= MAC=02:19:e6:40:fc:c8:02:55:96:c9:21:66:08:00 SRC=172.31.47.174 DST=172.31.55.27 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=26039 DF PROTO=TCP SPT=22896 DPT=8090 SEQ=1763415057 ACK=0 WINDOW=62727 RES=0x00 SYN URGP=0 OPT (020423010402080ADBFD1C1B0000000001030307) kern :warn : [Thu Sep 21 15:01:24 2023] TRACE: nat:PREROUTING:rule:1 IN=eth3 OUT= MAC=02:19:e6:40:fc:c8:02:55:96:c9:21:66:08:00 SRC=172.31.47.174 DST=172.31.55.27 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=26039 DF PROTO=TCP SPT=22896 DPT=8090 SEQ=1763415057 ACK=0 WINDOW=62727 RES=0x00 SYN URGP=0 OPT (020423010402080ADBFD1C1B0000000001030307) kern :warn : [Thu Sep 21 15:01:24 2023] TRACE: nat:KUBE-SERVICES:return:45 IN=eth3 OUT= MAC=02:19:e6:40:fc:c8:02:55:96:c9:21:66:08:00 SRC=172.31.47.174 DST=172.31.55.27 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=26039 DF PROTO=TCP SPT=22896 DPT=809 ...

Iostat 参数说明

发表于2023-12-22|更新于2025-09-23|Linux

iostat - Report Central Processing Unit (CPU) statistics and input/output statistics for devices and partitions. 指标的解释说明如下： rrqm/s - wrqm/s 两个看的是的merge的请求数量，表示发送给驱动程序并被驱动程序合并的请求数量，表示有没有进行合并，这也表示系统将随机IO请求合并成连续以提高性能。 r/s - w/s IO读写的请求数量IOPS，发送给磁盘设备的请求数。 rKB/s - wKB/s 吞吐量，可以使用 -m 转换成MB/s，设备的传输数据量的吞吐量信息。 avgrq-sz 平均请求大小，也就是IO size 的大小。单位是扇区（512B）。 rareq-sz - wareq-sz 新版本的iostat已经是这两个指标了，这两个指标单位是 KB. avgqu-sz 在驱动队列和设备队列中或活跃的平均请求数量。单位是个。 await 这个指标记录的总的延迟，新的版本也包括 rw 两类请求的延迟。延迟单位是 ms ，通常不应该超过10ms. 磁盘读取相关 r/s: 每秒完成的读请求数 rkB/s: 每秒读取的数据量(KB) rrqm/s: 每秒这个设备相关的读取请求有多少被合并 %rrqm: 被合并的读取请求所占的百分比 r_await: 读取请求的平均响应时间(毫秒) rareq-sz: 平均每次读取请求的大小(扇区数) 磁盘写入相关 w/s: 每秒完成的写请求数 wkB/s: 每秒写入的数据量(KB) wrqm/s: 每秒这个设备相关的写入请求有多少被合并 %wrqm: 被合并的写入请求所占的百分比 w_await: 写入请求的平均响应时间(毫秒) wareq-sz: 平均每次写入请求的大小(扇区数) 磁盘总体 d/s: 设备每秒完成的丢弃(discard)请求数(经过合并后)。丢弃请求允许存储设备回收已删除块占用的存储空间。 dkB/s: 每秒为设备丢弃的数据量(KB)。 drqm/s: 每秒合并到设备排队的丢弃请求数。 %drqm: 丢弃请求在发送到设备之前合并在一起的百分比。 d_await: 向要服务的设备发出丢弃请求的平均时间(毫秒)。 dareq-sz: 向设备发出的丢弃请求的平均大小(KB)。其他 f/s: 每秒完成的刷新(flush)请求数(经过合并后)。这统计了磁盘执行的刷新请求数量。对于分区,不跟踪刷新请求。在合并之前,刷新操作被计为写入操作。 f_await: 完成操作的平均等待时间（以毫秒为单位）。这指的是发送到设备的刷新(flush)请求平均被服务的时间。块层会合并刷新请求,一次最多执行一个。因此,刷新操作可能会延长两倍时间:等待当前刷新请求,然后执行它,接着等待下一个。 aqu-sz: 平均请求队列长度 %util: 设备利用率百分比以3秒的间隔显示系统磁盘设备的IO使用状况和扩展统计数据. iostat -dx 3 Device r/s rkB/s rrqm/s %rrqm r_await rareq-sz w/s wkB/s wrqm/s %wrqm w_await wareq-sz d/s dkB/s drqm/s %drqm d_await dareq-sz f/s f_await aqu-sz %util nvme0n1 2147.33 34842.67 0.00 0.00 0.46 16.23 0.33 1.33 0.00 0.00 1.00 4.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 1.00 100.00 每隔 5 秒显示一次系统 CPU（c）、设备利用率（d）、分区统计数据（p）以及扩展 IO 统计数据（x)。 iostat -dcpx 5 Linux 6.4.10-arch1-1 (arch.liarlee.site) 08/22/2023 _x86_64_ (4 CPU) avg-cpu: %user %nice %system %iowait %steal %idle 5.23 0.00 2.05 0.01 0.01 92.71 Device r/s rkB/s rrqm/s %rrqm r_await rareq-sz w/s wkB/s wrqm/s %wrqm w_await wareq-sz d/s dkB/s drqm/s %drqm d_await dareq-sz f/s f_await aqu-sz %util nvme0n1 1.00 32.72 0.00 0.04 0.66 32.86 1.24 23.27 0.18 12.62 0.99 18.79 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.18 nvme0n1p1 1.00 32.72 0.00 0.04 0.66 32.86 1.24 23.27 0.18 12.62 0.99 18.79 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.18 监控数据来源： cat /proc/diskstats这些所有的指标都是 By Device 的，与进程的部分无关，统计的是发送到设备或者发送到设备分区的请求。基于man page 中的描述，这四个参数分别是： r/s The number (after merges) of read requests completed per second for the device. w/s The number (after merges) of write requests completed per second for the device. d/s The number (after merges) of discard requests completed per second for the device. f/s The number (after merges) of flush requests completed per second for the device. This counts flush requests executed by disks. Flush requests are not tracked for partitions. Before being merged, flush operations are counted as writes. 命令行参数的一部分解释-d 展示磁盘设备使用率的信息。-x 扩展显示更多的指标数据，不添加这个参数不区分设备读/写/磁盘/文件系统这四个维度。-c 查看CPU统计的使用率指标。-p 磁盘分区的指标。-z 只是输出一些有IO的设备的统计信息。性能之巅里面有写出这个参数。-t 来输出时间戳。这个命令主要看如下的点：看物理设备，具体是那个设备上面有 IO 请求。看 await，等待的时间长不长，这里面的等待时间是从请求进入设备队列到请求返回成功的时间，通常情况下应该是在 10ms 以内，尤其是 ssd。看 aqu-sz，按照 EBS 的规则，应该是每 1000 IOPS 队列数为 1 最合适。综合看 IOPS，块大小，吞吐量，使用率，确认设备是不是达到了瓶颈。最后切换工具定位具体是那个进程在大量的发送 IO 请求，大概可能的工具是 pidstat， htop ， atop ， sar 等等，感觉工具还可能有 pm 的这部分工具。