

zhangguanzhang's Blog

zhangguanzhang's Blog

v1.17+ k8s集群下CNI使用VXLAN模式SVC有63秒延迟的触发原因定位



v1.17+ k8s集群下CNI使用VXLAN模式SVC有63秒延迟的触发原因定位

63s timeout

字数统计: 4.2k阅读时长: 22 min

 2020/05/23   Share

• 
• 
• 
• 
• 

这个问题 flannel 和 calico 的 VXLAN 模式下都会发生，部分人的现象是集群的A记录 UDP 下查询可能有问题（也有人在 azure 上在宿主机上访问 svc 的 clusterIP 10%几率才能通），原因是v1.17+的k8s会引起内核的某个 UDP 相关 bug而不是cni的软件层面，weave没有，后面说。

写这篇文章的日期是05/28，发现是上周五也就是05/23号，文章从时间线写起(因为很多时候想发文章但是没空，所以文章的发布日期是05/23)

2020-07-19更新，版本v1.18.6, v1.16.13, v1.17.9+已经修复这个问题，可以同版本内升级，或者只切kube-proxy版本

由来

上周五我经过同事的工位看到同事的桌面是k8s的get po的输出，问他咋开始学k8s了，他说跟着视频学下，看了下用的kubeadm部署了一套1.18.2的集群。1.18的kube-proxy的ipvs包的parseIP有bug，我推荐他换v1.17.5。他当时在部署一个入门的svc实验，换了后还是无法解析域名(实际上后面对照组v1.18.2也解析不了)。使用dig命令排查了下，下面是对照:

• dig @<podIP> +short kubernetes.default.svc.cluster.local 能解析
• dig @10.96.0.10 +short kubernetes.default.svc.cluster.local 超时

很多市面上的kubeadm部署教程都是直接kubeadm init，所以我推荐同事去按照我文章的kubeadm部署一套后再试试，叫他用v1.17的最新版本v1.17.5，结果还是上面一样。coredns实际上还有metrics的http接口，从http层测了下：

• curl -I 10.96.0.10:9153/metrics 超时，很久之后才有返回
• curl -I <podIP>:9153/metrics 能直接返回

涉及到本次排查的信息为

$ kubectl get node -o wide
NAME     STATUS   ROLES    AGE    VERSION   INTERNAL-IP   EXTERNAL-IP   OS-IMAGE                KERNEL-VERSION          CONTAINER-RUNTIME
master   Ready    master   7d8h   v1.18.2   10.0.100.3    <none>        CentOS Linux 7 (Core)   3.10.0-957.el7.x86_64   docker://19.3.8
node1    Ready    <none>   7d7h   v1.18.2   10.0.100.4    <none>        CentOS Linux 7 (Core)   3.10.0-957.el7.x86_64   docker://19.3.8
node2    Ready    <none>   7d7h   v1.18.2   10.0.100.15   <none>        CentOS Linux 7 (Core)   3.10.0-957.el7.x86_64   docker://19.3.8

$ kubectl get po -o wide -n kube-system -l k8s-app=kube-dns
NAME                       READY   STATUS    RESTARTS   AGE   IP            NODE    NOMINATED NODE   READINESS GATES
coredns-546565776c-v5wwg   1/1     Running   2          25h   10.244.2.73   node2   <none>           <none>

多次尝试发现很久的时间都是一样，用time命令观察了下一直是63秒返回。包括其他任何svc都是这样

$ time    curl -I 10.96.0.10:9153/metrics
HTTP/1.1 200 OK
Content-Type: text/plain; version=0.0.4; charset=utf-8
Date: Wed, 25 May 2020 08:39:35 GMT


real	1m3.091s
user	0m0.002s
sys	0m0.007s

proxyMode是ipvs，用ipvsadm看下超时的时候的状态，一直是SYN_RECV，也就是发送了SYN，没收到回包

# ipvsadm -lnc |& grep 9153
TCP 00:59  SYN_RECV    10.96.0.10:41282   10.96.0.10:9153    10.244.2.73:9153

抓包

因为cni使用的flannel，用的vxlan模式。master上抓9153和flannel.1的8472端口，coredns的pod所在node上抓flannel的vxlan包，下面三个是对应的:

[root@master /root]# tcpdump -nn -i flannel.1 port 9153
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on flannel.1, link-type EN10MB (Ethernet), capture size 262144 bytes
16:30:56.705696 IP 10.244.0.0.2201 > 10.244.2.73.9153: Flags [S], seq 911217171, win 43690, options [mss 65495,sackOK,TS val 17148909 ecr 0,nop,wscale 7], length 0
16:30:57.708489 IP 10.244.0.0.2201 > 10.244.2.73.9153: Flags [S], seq 911217171, win 43690, options [mss 65495,sackOK,TS val 17149912 ecr 0,nop,wscale 7], length 0
16:30:59.712458 IP 10.244.0.0.2201 > 10.244.2.73.9153: Flags [S], seq 911217171, win 43690, options [mss 65495,sackOK,TS val 17151916 ecr 0,nop,wscale 7], length 0
16:31:03.716441 IP 10.244.0.0.2201 > 10.244.2.73.9153: Flags [S], seq 911217171, win 43690, options [mss 65495,sackOK,TS val 17155920 ecr 0,nop,wscale 7], length 0
16:31:11.732562 IP 10.244.0.0.2201 > 10.244.2.73.9153: Flags [S], seq 911217171, win 43690, options [mss 65495,sackOK,TS val 17163936 ecr 0,nop,wscale 7], length 0
16:31:27.764498 IP 10.244.0.0.2201 > 10.244.2.73.9153: Flags [S], seq 911217171, win 43690, options [mss 65495,sackOK,TS val 17179968 ecr 0,nop,wscale 7], length 0
16:31:59.828493 IP 10.244.0.0.2201 > 10.244.2.73.9153: Flags [S], seq 911217171, win 43690, options [mss 65495,sackOK,TS val 17212032 ecr 0,nop,wscale 7], length 0
16:31:59.829565 IP 10.244.2.73.9153 > 10.244.0.0.2201: Flags [S.], seq 435819916, ack 911217172, win 27960, options [mss 1410,sackOK,TS val 17212067 ecr 17212032,nop,wscale 7], length 0
16:31:59.829611 IP 10.244.0.0.2201 > 10.244.2.73.9153: Flags [.], ack 1, win 342, options [nop,nop,TS val 17212033 ecr 17212067], length 0
16:31:59.829714 IP 10.244.0.0.2201 > 10.244.2.73.9153: Flags [P.], seq 1:88, ack 1, win 342, options [nop,nop,TS val 17212033 ecr 17212067], length 87
16:31:59.829897 IP 10.244.2.73.9153 > 10.244.0.0.2201: Flags [.], ack 88, win 219, options [nop,nop,TS val 17212067 ecr 17212033], length 0
16:31:59.831300 IP 10.244.2.73.9153 > 10.244.0.0.2201: Flags [P.], seq 1:113, ack 88, win 219, options [nop,nop,TS val 17212069 ecr 17212033], length 112
16:31:59.831322 IP 10.244.0.0.2201 > 10.244.2.73.9153: Flags [.], ack 113, win 342, options [nop,nop,TS val 17212034 ecr 17212069], length 0
16:31:59.831435 IP 10.244.0.0.2201 > 10.244.2.73.9153: Flags [F.], seq 88, ack 113, win 342, options [nop,nop,TS val 17212035 ecr 17212069], length 0
16:31:59.831633 IP 10.244.2.73.9153 > 10.244.0.0.2201: Flags [F.], seq 113, ack 89, win 219, options [nop,nop,TS val 17212069 ecr 17212035], length 0
16:31:59.831660 IP 10.244.0.0.2201 > 10.244.2.73.9153: Flags [.], ack 114, win 342, options [nop,nop,TS val 17212035 ecr 17212069], length 0

[root@master /root]# tcpdump -nn -i eth0 port 8472
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
16:30:56.705718 IP 10.0.100.3.48683 > 10.0.100.15.8472: OTV, flags [I] (0x08), overlay 0, instance 1
IP 10.244.0.0.2201 > 10.244.2.73.9153: Flags [S], seq 911217171, win 43690, options [mss 65495,sackOK,TS val 17148909 ecr 0,nop,wscale 7], length 0
16:30:57.708523 IP 10.0.100.3.48683 > 10.0.100.15.8472: OTV, flags [I] (0x08), overlay 0, instance 1
IP 10.244.0.0.2201 > 10.244.2.73.9153: Flags [S], seq 911217171, win 43690, options [mss 65495,sackOK,TS val 17149912 ecr 0,nop,wscale 7], length 0
16:30:59.712478 IP 10.0.100.3.48683 > 10.0.100.15.8472: OTV, flags [I] (0x08), overlay 0, instance 1
IP 10.244.0.0.2201 > 10.244.2.73.9153: Flags [S], seq 911217171, win 43690, options [mss 65495,sackOK,TS val 17151916 ecr 0,nop,wscale 7], length 0
16:31:03.716452 IP 10.0.100.3.48683 > 10.0.100.15.8472: OTV, flags [I] (0x08), overlay 0, instance 1
IP 10.244.0.0.2201 > 10.244.2.73.9153: Flags [S], seq 911217171, win 43690, options [mss 65495,sackOK,TS val 17155920 ecr 0,nop,wscale 7], length 0
16:31:11.732590 IP 10.0.100.3.48683 > 10.0.100.15.8472: OTV, flags [I] (0x08), overlay 0, instance 1
IP 10.244.0.0.2201 > 10.244.2.73.9153: Flags [S], seq 911217171, win 43690, options [mss 65495,sackOK,TS val 17163936 ecr 0,nop,wscale 7], length 0
16:31:27.764513 IP 10.0.100.3.48683 > 10.0.100.15.8472: OTV, flags [I] (0x08), overlay 0, instance 1
IP 10.244.0.0.2201 > 10.244.2.73.9153: Flags [S], seq 911217171, win 43690, options [mss 65495,sackOK,TS val 17179968 ecr 0,nop,wscale 7], length 0
16:31:59.828541 IP 10.0.100.3.56618 > 10.0.100.15.8472: OTV, flags [I] (0x08), overlay 0, instance 1
IP 10.244.0.0.2201 > 10.244.2.73.9153: Flags [S], seq 911217171, win 43690, options [mss 65495,sackOK,TS val 17212032 ecr 0,nop,wscale 7], length 0
16:31:59.829521 IP 10.0.100.15.56771 > 10.0.100.3.8472: OTV, flags [I] (0x08), overlay 0, instance 1
IP 10.244.2.73.9153 > 10.244.0.0.2201: Flags [S.], seq 435819916, ack 911217172, win 27960, options [mss 1410,sackOK,TS val 17212067 ecr 17212032,nop,wscale 7], length 0
16:31:59.829617 IP 10.0.100.3.56618 > 10.0.100.15.8472: OTV, flags [I] (0x08), overlay 0, instance 1
IP 10.244.0.0.2201 > 10.244.2.73.9153: Flags [.], ack 1, win 342, options [nop,nop,TS val 17212033 ecr 17212067], length 0
16:31:59.829729 IP 10.0.100.3.56618 > 10.0.100.15.8472: OTV, flags [I] (0x08), overlay 0, instance 1
IP 10.244.0.0.2201 > 10.244.2.73.9153: Flags [P.], seq 1:88, ack 1, win 342, options [nop,nop,TS val 17212033 ecr 17212067], length 87
16:31:59.829883 IP 10.0.100.15.34571 > 10.0.100.3.8472: OTV, flags [I] (0x08), overlay 0, instance 1
IP 10.244.2.73.9153 > 10.244.0.0.2201: Flags [.], ack 88, win 219, options [nop,nop,TS val 17212067 ecr 17212033], length 0
16:31:59.831292 IP 10.0.100.15.34571 > 10.0.100.3.8472: OTV, flags [I] (0x08), overlay 0, instance 1
IP 10.244.2.73.9153 > 10.244.0.0.2201: Flags [P.], seq 1:113, ack 88, win 219, options [nop,nop,TS val 17212069 ecr 17212033], length 112
16:31:59.831327 IP 10.0.100.3.56618 > 10.0.100.15.8472: OTV, flags [I] (0x08), overlay 0, instance 1
IP 10.244.0.0.2201 > 10.244.2.73.9153: Flags [.], ack 113, win 342, options [nop,nop,TS val 17212034 ecr 17212069], length 0
16:31:59.831448 IP 10.0.100.3.56618 > 10.0.100.15.8472: OTV, flags [I] (0x08), overlay 0, instance 1
IP 10.244.0.0.2201 > 10.244.2.73.9153: Flags [F.], seq 88, ack 113, win 342, options [nop,nop,TS val 17212035 ecr 17212069], length 0
16:31:59.831612 IP 10.0.100.15.34571 > 10.0.100.3.8472: OTV, flags [I] (0x08), overlay 0, instance 1
IP 10.244.2.73.9153 > 10.244.0.0.2201: Flags [F.], seq 113, ack 89, win 219, options [nop,nop,TS val 17212069 ecr 17212035], length 0
16:31:59.831665 IP 10.0.100.3.56618 > 10.0.100.15.8472: OTV, flags [I] (0x08), overlay 0, instance 1
IP 10.244.0.0.2201 > 10.244.2.73.9153: Flags [.], ack 114, win 342, options [nop,nop,TS val 17212035 ecr 17212069], length 0

[root@node2 /root]# tcpdump -nn  -i eth0 port 8472
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
16:31:59.836137 IP 10.0.100.3.56618 > 10.0.100.15.8472: OTV, flags [I] (0x08), overlay 0, instance 1
IP 10.244.0.0.2201 > 10.244.2.73.9153: Flags [S], seq 911217171, win 43690, options [mss 65495,sackOK,TS val 17212032 ecr 0,nop,wscale 7], length 0
16:31:59.836328 IP 10.0.100.15.56771 > 10.0.100.3.8472: OTV, flags [I] (0x08), overlay 0, instance 1
IP 10.244.2.73.9153 > 10.244.0.0.2201: Flags [S.], seq 435819916, ack 911217172, win 27960, options [mss 1410,sackOK,TS val 17212067 ecr 17212032,nop,wscale 7], length 0
16:31:59.836811 IP 10.0.100.3.56618 > 10.0.100.15.8472: OTV, flags [I] (0x08), overlay 0, instance 1
IP 10.244.0.0.2201 > 10.244.2.73.9153: Flags [.], ack 1, win 342, options [nop,nop,TS val 17212033 ecr 17212067], length 0
16:31:59.836910 IP 10.0.100.3.56618 > 10.0.100.15.8472: OTV, flags [I] (0x08), overlay 0, instance 1
IP 10.244.0.0.2201 > 10.244.2.73.9153: Flags [P.], seq 1:88, ack 1, win 342, options [nop,nop,TS val 17212033 ecr 17212067], length 87
16:31:59.836951 IP 10.0.100.15.34571 > 10.0.100.3.8472: OTV, flags [I] (0x08), overlay 0, instance 1
IP 10.244.2.73.9153 > 10.244.0.0.2201: Flags [.], ack 88, win 219, options [nop,nop,TS val 17212067 ecr 17212033], length 0
16:31:59.838385 IP 10.0.100.15.34571 > 10.0.100.3.8472: OTV, flags [I] (0x08), overlay 0, instance 1
IP 10.244.2.73.9153 > 10.244.0.0.2201: Flags [P.], seq 1:113, ack 88, win 219, options [nop,nop,TS val 17212069 ecr 17212033], length 112
16:31:59.838522 IP 10.0.100.3.56618 > 10.0.100.15.8472: OTV, flags [I] (0x08), overlay 0, instance 1
IP 10.244.0.0.2201 > 10.244.2.73.9153: Flags [.], ack 113, win 342, options [nop,nop,TS val 17212034 ecr 17212069], length 0
16:31:59.838621 IP 10.0.100.3.56618 > 10.0.100.15.8472: OTV, flags [I] (0x08), overlay 0, instance 1
IP 10.244.0.0.2201 > 10.244.2.73.9153: Flags [F.], seq 88, ack 113, win 342, options [nop,nop,TS val 17212035 ecr 17212069], length 0
16:31:59.838703 IP 10.0.100.15.34571 > 10.0.100.3.8472: OTV, flags [I] (0x08), overlay 0, instance 1
IP 10.244.2.73.9153 > 10.244.0.0.2201: Flags [F.], seq 113, ack 89, win 219, options [nop,nop,TS val 17212069 ecr 17212035], length 0
16:31:59.838836 IP 10.0.100.3.56618 > 10.0.100.15.8472: OTV, flags [I] (0x08), overlay 0, instance 1
IP 10.244.0.0.2201 > 10.244.2.73.9153: Flags [.], ack 114, win 342, options [nop,nop,TS val 17212035 ecr 17212069], length 0

先看上面的第一部分，搜了下资料 https://blog.csdn.net/u010039418/article/details/78234570

得知tcp默认SYN报文最大retry 5次，每次超时了翻倍，1s -> 3s -> 7s -> 15s -> 31s -> 63s。只有63秒的时候node的机器上才收到了vxlan的报文。说明pod所在node压根没收到63秒之前的。

一般lvs的dr模式下tcp的时间戳混乱或者其他几个arp的内核参数不对下SYN是一直收不到的而不是63秒后有结果，所以和内核相关参数无关。于是同样上面的步骤tcpdump抓包，加上-w选项把抓的包导出下来导入到wireshark里准备看看

报文分析

9153的包wireshark里看63秒前面都是tcp的SYN重传，看到了master上向外发送的vxlan报文的时候有了发现。下面的截图是放github上的，网络不好会看不到截图

可以看到udp的checksum是0xffff，我对udp报文不太熟悉，udp的header的checksum没记错的话crc32校验的，不可能是这种两个字节都置1的0xffff，明显就是udp的header的校验出错了。后面几个正常包的checksum都是missing的

wireshark的编辑->首选项->Protocols->UDP的Validate the UDP checksum if possible勾上更直观看

解决

搜了下wireshark linux udp checksum incorrect，都是推荐把checksum offload disable掉就行了，例如我这里是flannel，则是

$ /sbin/ethtool -K flannel.1 tx-checksum-ip-generic off
Actual changes:
tx-checksumming: off
	tx-checksum-ip-generic: off
tcp-segmentation-offload: off
	tx-tcp-segmentation: off [requested on]
	tx-tcp-ecn-segmentation: off [requested on]
	tx-tcp6-segmentation: off [requested on]
	tx-tcp-mangleid-segmentation: off [requested on]
udp-fragmentation-offload: off [requested on]

再测下正常，而weave他们也用的vxlan模式，但是他们在创建网卡的时候把这个已经off掉了，所以他的vxlan模式在v1.17+集群没出现这个问题

$ time curl -I 10.96.0.10:9153
HTTP/1.1 404 Not Found
Content-Type: text/plain; charset=utf-8
X-Content-Type-Options: nosniff
Date: Wed, 27 May 2020 02:14:04 GMT
Content-Length: 19


real	0m0.009s
user	0m0.005s
sys	0m0.003s

你以为这样就完了？其实并没有，因为我自己维护了一套ansible部署k8s的方案，每次新版本发布我都会实际测下。并且同事反映了他同样云主机开出来用我ansible部署v1.17.5没有这个问题。这就很奇怪了，原因后面说，请接着继续看

什么是checksum offload

资料:

• https://wiki.wireshark.org/CaptureSetup/Offloading
• https://zh.wikipedia.org/wiki/TCP%E6%A0%A1%E9%AA%8C%E5%92%8C%E5%8D%B8%E8%BD%BD
• Checksum Offload 是网卡的一个功能选项。如果该选项开启，则网卡会负责计算需要发送或者接收到的TCP消息的校验和，从而节省CPU的计算开销。此时，在需要发送的消息到达网卡前，系统会在TCP报头的校验和字段填充一个随机值。
  但是，尽管Checksum Offload能够降低 CPU 的计算开销，但受到计算能力的限制，某些环境下的一些网卡计算速度不如主频超过400MHz的CPU快

正文

对照组

很奇怪的就是为啥就是我的ansible部署的二进制就正常没这个问题，而kubeadm部署的就不正常，后面我花时间整了以下几个对照组(期间同事也帮我做了几个条件下的测试，但是不是系统用错了就是版本整错了。。。)，终于找到了问题的范围，下面是我自己统计的对照组信息，kubeadm和ansible版本均为1.17.5测试。os不重要，因为最终排查出和os无关

os	type(kubeadm or ansible)	flannel version	flannel is running in pod?	will 63 sec
7.6	kubeadm	v0.11.0	yes	yes
7.6	kubeadm	v0.12.0	yes	yes
7.6	kubeadm	v0.11.0	no	yes
7.6	kubeadm	v0.12.0	no	yes
7.6	ansible	v0.11.0	yes	no
7.6	ansible	v0.12.0	yes	no
7.6	ansible	v0.11.0	no	no
7.6	ansible	v0.12.0	no	no

这就看起来很迷了。但是排查出和flannel无关，感觉kube-proxy有关系，然后今天05/28针对kube-proxy做了个对照组

os	type(kubeadm or ansible)	kube-proxy version	kube-proxy is running in pod?	will 63 sec
7.6	kubeadm	v1.17.5	yes	yes
7.6	kubeadm	v1.17.5	no	no
7.6	kubeadm	v1.16.9	yes	no
7.6	kubeadm	v1.16.9	no	no
7.6	ansible	v1.17.5	yes	yes
7.6	ansible	v1.17.5	no	no

可以看出就是1.17以上的版本如果使用pod则会有这个问题，而非pod则不会，github上compare了下v1.17.0和v1.16.3 https://github.com/kubernetes/kubernetes/compare/v1.16.3...v1.17.0

发现了Dockerfile的改动 https://github.com/kubernetes/kubernetes/commit/fed582333f639dc22e879f4bbb258e403c210c30

见上面的commit 1.17.0里的 Dockerfile 的BASEIMAGE是用 指定了一个源安装了最新的iptables，然后利用update-alternatives把脚本/usr/sbin/iptables-wrapper去替代iptables 来检测应该使用nft还是legacy， hack 下镜像回自带源里的 iptables 验证下

FROM registry.aliyuncs.com/google_containers/kube-proxy:v1.17.5
RUN rm -f /usr/sbin/iptables && 
    clean-install iptables

构建的镜像推送到了dockerhub上zhangguanzhang/hack-kube-proxy:v1.17.5，更改下集群kube-proxy ds的镜像

$ kubectl -n kube-system get ds kube-proxy -o yaml | grep image:
        image: zhangguanzhang/hack-kube-proxy:v1.17.5

测试访问成功

 time curl -I 10.96.0.10:9153
HTTP/1.1 404 Not Found
Content-Type: text/plain; charset=utf-8
X-Content-Type-Options: nosniff
Date: Thu, 28 May 2020 04:47:21 GMT
Content-Length: 19


real	0m0.008s
user	0m0.003s
sys	0m0.003s

对于这个问题我在flannel的pr下面也参与了回复，https://github.com/coreos/flannel/pull/1282 官方github上提了一个issue https://github.com/kubernetes/kubernetes/issues/91519

这个问题的触发是由于v1.17+的 kube-proxy 的 docker 镜像里安装了最新的 iptables ， --random-fully选项会触发内核vxlan的bug

总结

解决问题三种办法:

• 关闭vxlan的网卡的checksum offload
• 更改Docker镜像
• 升级到新内核，具体版本就不知道了，只要在这个内核pr并后出的内核版本都行 https://github.com/torvalds/linux/commit/ea64d8d6c675c0bb712689b13810301de9d8f77a

原文作者：Zhangguanzhang

原文链接：http://zhangguanzhang.github.io/2020/05/23/k8s-vxlan-63-timeout/

发表日期：May 23rd 2020, 7:01:01 pm

更新日期：May 23rd 2020, 7:01:01 pm

版权声明：本文采用知识共享署名-非商业性使用 4.0 国际许可协议进行许可

• Next Post
  [未写完]使用go开发一个Prometheus的exporter
• Previous Post
  proxmox x86软路由笔记

Powered by Hexotheme Archer

PV: :)

CATALOG

1. 1. 由来
   1. 1.1. 抓包
   2. 1.2. 报文分析
   3. 1.3. 解决
   4. 1.4. 什么是checksum offload
2. 2. 正文
   1. 2.1. 对照组
3. 3. 总结

• Archive
• Tag
• Cate

Total : 186



2024

• 09/16 hostPort 不通排查，以及挖掘问题根源
• 08/02 在 IPv6 单栈下适配部署 K8S、中间件、应用适配
• 07/25 [持续更新] - headscale 搭建和应用场景
• 07/21 [持续更新] - 安卓折腾笔记
• 06/17 hostPort 访问进来的源 IP 是 cni0 地址的排查
• 05/22 arm64 redis COW 检测
• 05/01 k8s node 热扩容内存导致的一次业务故障
• 04/22 开源容器镜像扫描 trivy 懒人重点指南
• 04/16 golang pprof 转 svg 的最小二进制依赖尝试
• 04/11 cri-dockerd 无法拉取需认证仓库上的 pause 镜像解决
• 04/08 docker 和 k8s 使用 gpu 笔记
• 02/06 高版本client-go在serviceAccountToken下invalid bearer token?
• 01/26 docker v2 registry 本地仓库如何只删除指定 tag 而非 manifest 下的所有 tag
• 01/16 golang 代码层面构建和推送容器镜像到远端仓库
• 01/08 docker 和 apparmor

2023

• 12/01 openat /etc/resolv.conf 卡住的一次排查
• 11/03 [持续更新] - 容器非 root 启动改造的经验
• 10/20 proxmox 7.4 升级8 后开机卡在 Loading kernel 6.2.16-15
• 08/18 k8s 使用 nfs 下 pod 无法创建的解决思路
• 08/08 qemu-user-static 下 cgo go build 卡住的一次解决
• 07/13 为什么ipvs下externalIPs乱设置会崩
• 05/22 pod 的 /etc/resolv.conf 生成机制
• 04/12 国产系统上解决docker pull卡住的问题
• 03/07 利用 qemu user 模式和 binfmt_misc 构建其他架构的 docker 镜像
• 02/14 openstack 虚机上 rabbitmqctl 超时

2022

• 12/30 k8s java 容器未设置 requests.cpu 导致性能问题
• 11/03 如何打包一个不依赖 python 的 supervisor 的包去离线部署
• 10/09 磁盘问题宕机后 docker 的 containerd 无法启动
• 09/07 低版本docker veth没清理造成容器网络问题
• 07/28 exsi 使用 redhat8.4 搭建k8s集群，flannel vxlan 模式的不正常排错
• 07/12 k8s pod 没有 IP ，报错 failed to read pod IP from plugin/docker
• 06/03 docker info无warning，iptables规则正常，宿主机就是不转发
• 05/13 低版本内核下容器内部无法使用 unix socket 通信
• 04/23 nfc 折腾笔记，ACR122U/proxmark3
• 04/22 docker containerd 不定时的 segfault 的一次处理过程
• 04/21 ecs 中毒的一次处理过程
• 04/11 无数据的 tcp 链接被 SDN/防火墙 干掉的一种处理办法
• 03/24 python kubernetes client list permission
• 03/17 ttf转woff工具谷歌woff2的静态编译
• 03/16 server 端的 cannot assign requested address
• 02/24 keepalived static link build
• 02/18 proxmox 开机 error: disk 'lvmid/[vg uuid]/[lv uuid]' not found
• 02/10 18.09.03 docker daemon layer broken 的一次不优雅处理
• 01/26 利用 docker buildx 静态编译 nginx
• 01/22 EmuELEC 笔记

2021

• 12/19 openwrt 的在线升级固件和扩容的研究
• 12/12 docker数据盘损坏后启动报错 Error starting daemon: Error initializing network controller: Error creating default "bridge" network: package not installed
• 10/29 1.15 kubelet 在 nodefs 容量富裕下循环 reclaim ephemeral-storage
• 09/28 在非容器环境上实现散装的 IPVS SVC
• 09/16 解决 docker 的 read unix @->/run/containerd/s/xxx read: connection reset by peer: unknown
• 09/03 [持续更新] - Openwrt USB 网络
• 09/02 fio 静态编译和基础使用
• 09/01 ubuntu18下io调度算法是cfq导致mysql非常慢
• 08/27 干掉烦人的 open /run/xtables.lock: is a directory
• 08/25 flannel下集群有个节点网络不通的一次排查
• 08/24 一次 cni-plugins 导致集群 dns 无法解析的排错
• 08/16 kubelet 为系统配置预留资源
• 07/26 鲲鹏920的麒麟v10物理服务器断电后无法启动处理
• 07/20 dlv命令行的远程调试 golang 进程步骤(包含容器进程)
• 07/16 编译mips64le架构的consul
• 07/06 机器重启后 kube-apiserver 无法启动，etcd刷(error "EOF", ServerName "")
• 07/05 Job for docker.service canceled
• 06/08 openshift 4.5.9 etcd损坏+脑裂修复过程
• 05/26 docker-ce 18.09.3 启动panic: invalid freelist page: 56, page type is leaf的解决处理
• 04/30 一次单节点单个pod网络问题排查过程
• 04/08 kubelet 和 runc 编译关闭 kmem
• 03/23 iptables --wait -t nat -A DOCKER...: iptables NO chain/target/match by that name
• 03/22 Internal error occurred: jsonpatch add operation does not apply: doc is missing path: xxx
• 03/12 使用github action 配合 docker buildx 编译 arm64 docker-compose
• 02/02 集群节点关机导致dns在eviction pod之前几率不可用
• 01/24 e2fsck 太老报错 has unsupported feature(s): metadata_csum，从而尝试静态编译
• 01/23 chrony 静态编译和笔记

2020

• 12/04 docker18.03 hang at 'restoring container'
• 11/23 ansible reload user group
• 11/23 ansible hang in docker container
• 11/20 永久关闭swap的正确姿势
• 11/06 银河麒麟arm64系统克隆机器上k8s vxlan跨节点不通的一次排查
• 10/30 统信USO 20 hostPort 无法访问
• 10/20 银河麒麟arm64系统上k8s集群跨节点不通的一次排查
• 09/18 openshift 4.5.9 离线安装
• 08/27 skopeo 静态编译
• 08/05 个人用 wireguard 笔记
• 07/30 prometheus的rate与irate内部是如何计算的
• 07/23 k8s master机器文件系统故障的一次恢复过程
• 07/05 Linux audit 审计
• 06/25 k8s pprof 分析 cpu 和内存
• 06/23 阿里云上使用flannel host-gw跨节点pod不通的解决
• 06/19 [未写完]使用go开发一个Prometheus的exporter
• 05/23 v1.17+ k8s集群下CNI使用VXLAN模式SVC有63秒延迟的触发原因定位
• 05/13 proxmox x86软路由笔记
• 05/12 adguardhome dns FORMERR 错误
• 05/12 斐讯N1刷机和旁路由的设置
• 04/27 git工作流下golang项目的version信息该如何处理
• 03/26 一次deploy,rs,sts Mismatch 的处理
• 03/10 go mod的基础使用-科普
• 03/02 centos6中毒重启后卡在启动页面
• 03/02 记录一次request_module: runaway loop modeprobe binfmt-0000
• 02/27 使用microsoft-graph的api对接onedrive
• 01/15 Killing container "docker://xxx with 30 second grace period
• 01/08 docker-18.06.3-ce启动panic: invalid page type: 0: 0的解决处理

2019

• 12/05 opensuse的一次救援
• 12/03 从PTTYPE="dos"到TYPE="LVM2_member"的救援
• 11/24 [长期更新]--应大多数人要求写下kubeadm的基础使用
• 10/24 consul仅当服务发现在k8s无状态部署使用
• 10/21 手动修复v1.14-v1.15版本k8s的issue:76956
• 10/12 /boot目录被清空下物理机无法开机的一次救援
• 10/11 ansible数量限制上的幂等性
• 09/27 高可用的SSL consul cluster实践
• 09/05 修改源码更改prometheus的时区问题
• 08/24 gobot控制esp8266
• 08/06 ubuntu preseed无人应答安装
• 07/14 golang headless browser包chromedp初探
• 07/08 为什么我不用nodePort之偶然中奖几率
• 07/07 golang的net/http包的客户端简单科普
• 06/26 uefi模式下docker+交换机部署pxe批量安装
• 06/23 拟定excel表格服务器自动按照表格配置信息和安装的实现过程
• 06/12 SMASH CLP的一些笔记
• 06/02 golang cobra的一些笔记
• 05/11 standard_init_linux.go:211: exec user process caused "too many open files in system"
• 04/28 闲谈线上俩k8s环境同等limits下pod启动时间不一样解决过程
• 03/22 一次kube-controller-manager的bug导致的线上无法调度处理过程
• 03/15 不走etcd v2 api下二进制跑flannel的总结
• 03/11 k8s高可用涉及到ip填写的相关配置和一些坑
• 03/03 二进制部署Kubernetes v1.13.12 HA可选
• 02/19 docker部署jira(8.0.0)和confluence(6.14.1)
• 02/12 通用的dashboard部署和tls，SSL相关部署
• 01/30 fstab与systemd.mount自动挂载的一点研究和见解
• 01/22 proxmox里使用cloud-init和一些笔记

2018

• 12/04 prometheus的黑盒监控
• 11/24 对于初入k8s和kubeadm的一些建议
• 11/06 一次docker镜像的解耦--onlyoffice
• 11/05 记录一次十字符病毒清理过程
• 10/27 生成kubeconfig常规的两种方法
• 10/12 全手动部署prometheus-operator监控K8S集群以及一些坑
• 10/06 IngressController使用和它的高可用落地
• 09/24 跨VPC或者跨云供应商搭建K8S集群正确姿势
• 09/18 二进制部署Kubernetes v1.11.x(1.12.x) HA可选
• 08/03 Kubernetes v1.11.x HA全手动苦工安装教学
• 07/18 基于openstack的ecs上使用VIP
• 07/08 利用travis同步gcr.io镜像到dockerhub
• 06/25 记录一次线上k8s节点故障
• 06/03 kubernetes's Job总结和实战以及坑
• 06/02 kubernetes的PodAffinity的不解
• 05/05 [转载+修正]Kubernetes v1.10.x HA全手动苦工安装教学
• 04/29 kubernetes的configMap文件挂载不同的路径且不覆盖目录的解决方法
• 03/18 使用管理网当作业务网keepalived VIP的心跳线
• 02/15 Linux tc基础使用
• 02/05 docker无法删除掉镜像的解决方法
• 01/20 慎用docker的--rm选项!!!
• 01/10 docker的一些概念

2017

• 12/24 docker容器访问宿主机
• 12/23 docker容器网络互联
• 08/03 Linux 上 iptables ipset 白名单
• 07/25 centos桥接测试
• 07/15 使用 dd 利用 iso 文件制作 USB 启动盘
• 07/06 windows 笔记
• 07/05 centos7 的一些常见软件的安装 mirror
• 06/26 lua列出所有upsteam
• 06/03 bash自定义补全
• 05/25 shell脚本的选项和参数处理
• 05/15 rpm包的制作笔记
• 05/12 ssh互信
• 05/06 shell利用快捷键提升命令输入和编辑
• 04/29 个人zabbix安装和坑的解决
• 04/26 正则零宽断言的一个注意点
• 04/25 [转载]awk中RS,ORS,FS,OFS区别于联系
• 04/20 记录LVM和raid的练习
• 04/20 虚拟化扩容硬盘大小
• 04/17 分享下自己做的外网控制硬件
• 04/15 shell多进程并发执行
• 04/15 shell的字符串截取
• 04/11 8266模块的烧写和sdk的坑
• 04/09 安卓安装linux并且源码编译安装搭建lnmp的坑和总结
• 04/03 centos配置bond
• 04/03 编写一个动态准入控制
• 03/28 Linux 僵尸进程处理
• 03/23 判断是否是 dhcp 获取ip的一个手段
• 03/20 vsftpd虚拟用户简单部署
• 03/15 源码编译安装lnmp
• 02/26 Altium Designer里走线开窗和挖除铺铜还有一些技巧
• 02/12 微信公众号接入自己服务器
• 02/02 lamp环境搭建总结
• 01/08 微信公众号接入图灵机器人api

2016

• 11/13 cad
• 10/30 记录下自己制作的led-vu
• 10/28 hello world

 linux  微信  diy  8266  总结  ipmi  CLP  k8s  Mismatch  Altium Designer  ansible  consul  docker  lnmp  安卓  Linux  kernel  prometheus  exporter  boot  grub  cad  tcp  golang  centos6  chromedp  chrony  kubernetes  cni-plugins  mips64le  kubeconfig  swap  dlv  adguardhome  dns  Dockerfile  e2fsck  fsck  keepavlied  ecs  xmrig  etcd  fio  flannel  ftp  go mod  go  gobot  esp8266  hello world  host-gw  mqtt  原创  jira  confluence  kube-controller-manager  java  springboot  vip  keepalived  ConfigMap  PodAffinity  kylin  arm64  Kylin  audit  fs  nginx  microsoft  graph  onedrive  nodeport  usb-net  overlay  kernal  preseed  Prometheus  openstack  cloud-init  python  containerd  keepalive  shell  bash  skopeo  ssh  kubelet  systemd  dockerhub  gcr.io  api  ubuntu18  initrd  tftp  uos  x86  openwrt  zabbix  zombie  正则  awk  EmuELEC  ingress  N1  cobra  hang  cifs  http  lvs  ipvsadm  kube-proxy  63s  timeout  lamp  nfc  pm3  coredns  openshift  ocp  squashfs  timezone  rpm  rpmbuild  segfault  suse  wireguard  raid  kubeadm  operator  exsi  redhat8.4  vxlan  veth  panic  supervisor  pyinstaller  ttf  woff  hostname  qemu  binfmt_misc  loongarch64  externalIP  cgo  nfs  ipset  proxmox  non-root  containers  vmware  hung  apparmor  serviceAccountToken  gpu  nvidia  cri-dockerd  pprof  trivy  redis  /etc/resolv.conf  hostPort  hotplug  android  headscale  derper  iptables



缺失模块，请参考主题文档进行安装配置：https://github.com/fi3ework/hexo-theme-archer#%E5%AE%89%E8%A3%85%E4%B8%BB%E9%A2%98

 日志  心得  闲搞  ipmi  kubernetes  ansible  kubelet  Linux  心得  prometheus  boot  Auto cad  boot  golang  kubeconfig  grub  linux  centos6  容器  docker  docker  容器  openstack  boot  vsftp  go  version  panic  gobot  闲聊  iptables  admission  kube-controller-manager  keepalived  k8s  Prometheus  Job  k8s  lua  microsoft  openwrt  preseed  Prometheus  proxmox  总结  CI  Kylin  ubuntu18  pxe  uos  graph  运维  zombie  技巧  travis  docker  onedrive  kickstart  consul  fstab  http  vxlan  coredns  node-cache  golang  kmem  suse  wireguard  raid  kubeadm  LVM  kickstart  prometheus  raid



