帮助同事看一个 gitlab-runner 的问题，最终发现是 docker 低版本的 bug，没清理掉 veth 导致的
这几天处理的一个问题，exsi 上 redhat8.4 搭建 k8s 环境，使用 flannel vxlan 模式，pod 的网络表现得非常异常
由来有事回到工位上，还没坐下同事就过来喊我，让我帮忙看个客户的生产环境问题，大致就是客户为了搞安全，开了 ipset，然后发现业务受影响了。
过程123456$ kubectl get pod -o wide | grep -v RunnNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATESxxxx-privilege-r97z...
由来06、02 凌晨被喊醒帮忙看问题，客户侧重启部分 k8s 节点机器后，业务的部分接口出现问题，环境无法向日葵之类的远程，只能发命令后，现场人员执行。
具体现象业务 pod 日志看是无法连到非 k8s 机器上的 mysql 的 3306， docker info 命令无 warning 也就是代表下面的几个内核参数正常：
1234net.bridge.bridge-nf-call-ip6tables = 1net.bridge.bridge-nf-call-iptables = 1net.bridge.bridge-nf-call-arptables = 1net.ipv4.ip_fo...
由来最近几次遇到的机器上所有容器内，都无法使用 unix:// 去通信的的一个问题。
遇到的几个错误现象最开始是我们部署容器内无法使用 ansible 去操作其他机器，后面是该机器上所有容器内的 supervisorctl 无法通过 unix sock 连接 supervisord
ansible报错如下：
1234failt: [10.x.x.x]: UNREACHABLE! => { "changed": false, "msg": "Data could not be sent t...
近期折腾 nfc 相关，以后 nfc 的折腾也会更新在这个文章内
客户环境 docker 和 containerd 启动时不时 segment fault 的一次处理过程。
一次客户 ecs 中毒的处理过程，可以给读者参考下中毒的处理过程。
客户的环境下，业务运行在 dmz 区，mysql 在非 dmz 区，业务连 mysql 的空闲 tcp 连接 240s 后会被 SDN 干掉，本文实际介绍一种不动业务(代码)，利用代理的解决办法
由来这几天内部有个功能就是看 kubernetes client 的权限有哪些
过程kubeconfig 生成先制作一个非 admin 的 kubeconfig，记得以前有个项目是部署后可以生成 kubeconfig 的，询问了一番后，其他群友提示下想起来是 permission-manager，部署后结果发现生成的 kubeconfig 压根不能用，报错未知机构签署的，结果还是按照以前 生成kubeconfig常规的两种方法 生成了一个简单的。
尝试过程其实一开始打算自己写逻辑，增删改查需要的资源便利来检查，然后突然想起来 kubectl (忘了哪个版本开始)有个 auth 子命令的 ...
ttf 转 woff 的工具太少了，离线安装的方案基本没有，所以找了个工具静态编译
由来今天碰到了这个问题，但是最终结果出乎意料
过程项目相关部分客户的 OA 对接我们的应用，使用过程中会调用我们的接口，我们的接口再回调客户的回调地址。调用流是：
1客户 OA 后端 ----> 我们应用 A 的后端 -----> 我们应用 B 后端 -----> 客户写的回调地址
然后我们接口 A 返回 B 访问回调的报错：
1"Get http://10.192.xxx.xxx/xxxxinfo?...: dial tcp 10.192.xxx.xxx:80: connect: cannot assign requested address"...
由来之前那篇 ipvs svc 的文章，内部已经上生产了，客户的环境可能完全内网，包管理安装 keepalived 不现实，所以 keepalived 是部署容器里的。在容灾测试的时候，例如 3 台机器部署好业务，然后跑压测脚本模拟用户使用，发现关台机器的时候故障时间很短，但是这个机器开机的期间，还是很大概率故障时间很长，体现在接口的错误数量很多。大概看了下，是 keepalived 启动慢，先试启动 docker daemon，然后容器启动是顺序不固定，可能 keepalived 很后起来，于是就想着看看能不能 keepalived 拿出来，也就是静态编译。
buildx 使用见文章 ...
一次 proxmox 机器突然宕机，开机后进入 grub resuce 无法启动的处理过程
记录一次 18.09.03 docker daemon 存储的层损坏无法修复的过程，虽然不优雅，但是没找到更好的解决办法，暂时记录仅供参考。
