这个问题 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+已经修复这个问题，可以同版本内...
由来pve已经安装好系统(如果你还没安装且打算安装，安装完后可以看看我这个文章安装完proxmox的一些设置)，pve 的机器只有一个口子的情况下，就只能作为旁路由使用。
前置工作虚机准备先去恩山论坛x86版块下一个固件pve上开台机器
一般-高级-开机自启动勾上，有必要的话手动设置下vmID，后面有用
操作系统不适用任何介质
系统默认，下一步
硬盘随便设置，后面会删除
cpu按照实际，我给2核，内存我给的2g
网络，模型选VirtIO(半虚拟化)，防火墙的勾去掉
完成
选中虚机，硬件-选中硬盘，点击分离，删除
导入img把固件上传到 pve 的机器上，一般是 gz，解压成 img ...
由来这几天发现某个 zone 上游时不时地址无法解析，dnsmasq -> adguardhome 的 /xxx.com/10.x.x.x。
排查先用 dig 排查，发现是上游的问题，加上 noedns 就能解析了
12345678910111213141516171819202122232425262728293031323334353637383940root@OpenWrt:~# dig @10.x.x.x xxx.xxxxx.net ; <<>> DiG 9.17.13 <<>> @10.x.x.x xxx.xxxxx.ne...
由来之前一直是使用k2p刷openwrt或者pandora跑 xx 用，前几天看到了个 xx 的订阅地址给写到openwrt上了。结果运行了几天发现 web 上任何配置都无法更改，ssh 上去发现 touch 报错没有容量(而且重装后感觉还是有问题，github 访问也不稳定了)，意识到 k2p 容量实在太小了，于是去恩山论坛逛了下准备买个 N1 盒子玩玩旁路由。
N1有8G的rom 2G的ram，cpu 是 armv8 的。询问了一番 pdd 上有卖的，132买的刷机版+刷机线套餐(部分固件说好些白色的稳定，如果店铺能选颜色可以选白色的试试？，刷机线是双公头的USB，后期也可以用来救砖...
来探讨下git工作流下golang项目的version信息该如何处理比较符合标准
12345678apiVersion: v1kind: Podmetadata: name: testspec: containers: - name: test image: nginx:alpine
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354{ "kind":"Pod", "apiVersion":"v1", &qu...
这次文章是远程帮群友解决故障后的总结，以时间线描述 群友一开始是apiserver响应慢，使用角度上就是kubectl请求慢，如
123E0326 07:49:37.586690 1 available_controller.go:416] v1beta1.metrics.k8s.io failed with: failing or missing response from https://10.99.174.208:443/apis/metrics.k8s.io/v1beta1: Get https://10.99.174.208:443/apis/metrics...
go mod由来文章主要是针对新人来介绍 go mod 是啥以及新手如何使用，老手不用看。现阶段go mod已经完全GA了，你会用了的话会非常方便像 python 的项目根目录有requirement.txt记录依赖包，nodejs 是packages.json，同样 go 的包管理从早期的go dep(gopkg)到vendor到现在的go mod.go dep 很早，没有接触过，如果你接触的项目有go dep，看完本文希望你可以学会改造你手上的老项目，vendor则是把包都存放项目的根路径的vendor文件夹里，就像下面。这会导致一个项目很大，多达40M以上。
12345678910...
12345678910⣿⣿⣿⣿⣿⣿⢟⣡⣴⣶⣶⣦⣌⡛⠟⣋⣩⣬⣭⣭⡛⢿⣿⣿⣿⣿⣿⣿⣿⣿⠋⢰⣿⣿⠿⣛⣛⣙⣛⠻⢆⢻⣿⠿⠿⠿⣿⡄⠻⣿⣿⣿⣿⣿⣿⠃⢠⣿⣿⣶⣿⣿⡿⠿⢟⣛⣒⠐⠲⣶⡶⠿⠶⠶⠦⠄⠙⢿⣿⠋⣠⠄⣿⣿⣿⠟⡛⢅⣠⡵⡐⠲⣶⣶⣥⡠⣤⣵⠆⠄⠰⣦⣤⡀⠇⣰⣿⣼⣿⣿⣧⣤⡸⢿⣿⡀⠂⠁⣸⣿⣿⣿⣿⣇⠄⠈⢀⣿⣿⠿⣰⣿⣿⣿⣿⣿⣿⣿⣷⣤⣈⣙⠶⢾⠭⢉⣁⣴⢯⣭⣵⣶⠾⠓⢀⣴⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣉⣤⣴⣾⣿⣿⣦⣄⣤⣤⣄⠄⢿⣿⣿⣿⣿⣿⣿⣿⣿⣿⠿⠿⠿⠿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣇⠈⢿⣿⣿⣿⣿⣿⣿⡟⣰⣞⣛⡒⢒⠤⠦⢬⣉⣉⣉⣉⣉⣉⣉⡥⠴⠂⢸⠻⣿⣿⣿⣿⣏⠻⢌⣉⣉⣩⣉⡛⣛⠒⠶⠶⠶⠶⠶⠶⠶⠶⠂⣸⣿
昨晚刚整好那个ubuntu，今天下午又一台cen...
昨天一台 gpu 的主机的阵列卡突然坏了，最终整起来后上面的几台虚机恢复后有一台虚机无法正常开机，开机进 emergency mode，同事看上面的报错以为是挂载了啥 iscsi，当然无法开机应该找到最开始的错误，进到 emergency mode 这个视角的时候已经是雪崩的最后的错误了，多半是没有意义的。输入 root 密码后执行journalctl -xb翻看最开始的错误
按照关键字request_module: runaway loop modeprobe binfmt-0000搜到的都是裁剪内核出现的binfmt-484c啥的或者2.6内核的出错，尝试了换内核和挂载iso进re...
前言这几天打算把文件备份下，最后看到有网友说onedrive不错，就是容量小了点只有5g，然后酷安去安装安卓客户端，下面看到一堆人送office e5子账户的。看了下大概是微软为了推广自己产品面向开发者送的优惠，账户有免费的5t存储，而且安装office啥的免费。试用30天，30天内调用api来保持活跃度的话就会延期。评论里一大堆都是搭建oneindex或者onelist的，主要作用就是把onedrive给抽象成一个公共的网盘使用，oneindex是php写的，我看issue居然385个，作者的github也在更新，而且作者学了golang，居然也不打算重构下，估计也是烂尾了。oneli...
由来开发反应他们环境上有个 pod 不正常。他们先操作然后卡住后来找我的。
12345$ kubectl -n xxx get pod -o wide | grep 0/1xstorage-6d959cd8c8-rdscv 0/1 Init:0/1 0 15m xxxx$ kubectl -n xxx delete po xstorage-6d959cd8c8-rdscvpod "xstorage-6d959cd8c8-rdscv" deleted ^[[A^[[A^[[A^[[A
处理过程查看日志：
1234$...
凌晨 pod 状态异常且没有恢复，上线查看后 docker ps -a 命令无响应，kubelet 日志也刷和 docker 的 rpc 通信context deadline cancel重启了 docker 后 docker 无法启动，前台运行开 debug log level刚开始刷了个 /var/lib/docker/tmp 是个文件，对比了下其他机器上这个路径应该是个目录，然后改名后创建个权限和正常 docker 下权限一样的 tmp 文件夹再起
1234567891011121314151617181920212223242526272829303132333435363738...
昨晚吃完晚饭回到办公室，右边同事在控制台看着一个suse起不来一直启动的时候卡在suse的蜥蜴logo背景图那。见我来了叫我看下，他们已经尝试过恢复快照，但是还不行，应该是很久之前损坏的，只不过因为没重启没发现，我叫他重启下看看卡在哪，重启后进入内核后显示背景图那按下esc然后看卡在/sysroot挂载那。目测分区损坏了，经历了ubuntu的安装iso的rescue mode就是渣渣后，我还是信任centos的iso。
处理先备份和准备工作关闭虚机，后台拷贝下系统盘的卷先备份下。然后给虚机的IDE光驱挂载了个centos 7.5 DVD的iso，修改虚机启动顺序到ISO，进Tr...
同事叫我救援一台云主机，虽说是虚拟机，但是类比到硬件服务器还是一样的操作，这里记录下给后来者查阅
故障信息控制台进去看到centos7的背景虚化的数字7+转圈，重启下看下完整的错误，重启选了内核然后进到图形界面的时候按下ecs取消，观察终端
123456789101112131415161718192021222324[ OK ] Started Show Plymouth Boot Screen.[ OK ] Reached target Paths.[ OK ] Reached target Basic System.[ 124.522110] dracut-initqueu...
