Reficul

在过去一段时间内，有一套相同的软件在不同的部署环境之间，断断续续有现场反馈出现 Pod 在用域名访问 Service 的时候无法解析域名。经过简单排查：

1. 排除掉了使用姿势问题，即 pod.spec.dnsPolicy 是正确配置的；
2. 排除了运行时问题，即 Pod 里 /etc/resolv.conf 是符合预期的；
3. 排除了网络问题，即 Pod 来回到 CoreDNS 的 UDP/TCP 都是正常通信无丢包的；

那么，排除掉基础设施的问题，去怀疑的用户态应用层就很合理了。而且众所周知且 Musl 被广为诟病（虽然其实可能是 Glibc 实现不规范的问题）的是 Musl 在容器里一直多多少少存在些坑，这点在差不多 10 年前就已经领教了过了因为 musl 不认识 nsswitch.conf 导致 Go 程序出问题。

排查中得知，的确出问题的 Pod 都是使用的 Alpine，所以基本上可以确定是 Musl 的问题，但是还有一个关键问题没有搞清楚：

为什么有的环境是好的，有的环境就不行了。这究竟是命中了什么 Musl 的哪个场景导致了这个行为？

这不是巧了么，这个问题属于三不管：

1. 系统团队：管我屁事，你又没用我们的发行版本；
2. DNS 团队：我看 DNS 都是好的，你看宿主机上就返回的很快，是网络问题吧？是 K8s 问题吧？
3. 业务团队：我测过都是好的，你说的我听不懂，阿巴阿巴。但是我换镜像、测试、发 hotfix 要 N 天，肯定都是 K8s 的问题。
4. 现场运维：客户说了，不管你用啥方法，这周要找到原因修好。另外，你先告诉我一个绕过的方法。

屮，行吧。

由于个人使用 https_dns_proxy 配合代理服务器，从而来解决 DNS 污染的问题。但是最近发现针对部分国内的 CDN 返回的地址都是针对代理服务器的IP进行的优化，而这部分 IP 莫名其妙又不在国内 IP 的段内从而导致直连访问，最终导致访问异常缓慢甚至无法正确返回。 在解决这个问题的这个过程中就需要对 DNS Server 进行一系列的查询测试，因此做了一些研究有了这个文章。这个文章包含了 DNS 优化的主流方案原理。此外由于主流的 DNS 工具都不支持 DoH，为了方便测试也提供了一个 Tricky 的方式来测试 DoH 查询。

可能是由于高温的原因，前段时间我的 TrueNAS 的磁盘阵列挂了。 我的阵列由四块磁盘组成，采用了 Raid1+0 的架构，这样可以保证只要不同时挂掉 Mirror 中的两块磁盘，就不会丢失数据。但是这次我的阵列突然出现了 3 块磁盘同时 S.M.A.R.T 自检失败，其中两块磁盘出现了掉盘的情况。虽然好在掉盘情况没有同时发生在同一个 Mirror 之中，不过也是足够吓人了。虽然后面经过十分痛苦的控制变量后排除了磁盘问题，锁定是 SATA 线的问题（线换了两次都是坏的，也是够倒霉的）。 考虑到磁盘都在同一个机箱内，温度、掉电等异常情况都是同时发生的，即使采用了 RAID1 冗余数据也未必安全。

痛定思痛，考虑再把数据同步一份到云上做异地灾备就被提上了日程。这样的话，就算本地彻底玩完也可以从云上把数据重新恢复过来。考虑到本地已经采用了 RAID1+0 阵列，因此实际需要从云上恢复的概率很低了，所以灾备方案最首要考虑的是长期可延续性和性价比。这样的话，各家网盘首先因为未来运营上的不确定性排除掉了。在考虑性价比的话，就只需要找一家足够便宜的对象存储罢了。

这个过程中，踩了不少坑，希望能帮助到一些人。

kube-apiserver 莫名其妙报 KubeAPIErrorsHigh 告警，CPU/Memory/Disk 都是好的。结果一路查下去似乎进了不知道有多深的兔子洞，坑深到这个问题从 2018 年到至今都没有完成彻底的修复。爬了很多楼，过程中学到了一些东西，这个文章全当做一个记录，假如有其他倒霉蛋看到这边也碰到了这个问题，希望这个文章能帮助到你。

这是一个八九年前的真实故事，请原谅我的旧事重提。 2009年的初见之后的第3年，我选择了AFK。

之所以今天突然旧事重提，是因为看到有人对《阿甘正传》中阿甘突然选择了在某一天停止了持续几年的长跑的一则解读；又大抵是在因为距离上次删掉所有矫情文章封笔已经有13年了，这段时间内喷薄欲出的无病呻吟已经积攒到了一个程度吧。

0x00

本文旨在对如何设计监控方面提供一些意见性的指导和建议。

本文章翻译自Prometheus官方文档：Best Pratices-INSTRUMENTATION

Go是一门语法以Less is More为哲学的语言，以简单易学为设计目标，致力于写出比Java还千人一面的符合工程要求的语言。GC、没有泛型、简单到没有的错误处理等等，都使得我这种不会管理内存，智商跟不上泛型，只要Try就Catch不到的小学生能够每天拼接一下字符串，勉强过得了生活的样子。但是，不信任用户的同义词就是只信任自己：“不让你用是怕你搞砸，至于我？我怎么可能搞砸？”。为了方便那些Go Author，他们早就给自己开好了后门。但是这些技巧最大的作用就是茶余饭后的装逼资本了，毕竟在项目里用了很可能就被买腿了。但是话说回来，黑魔法一般作为禁招也能够帮你绝处逢生，离开你地球就停转，从而保住饭碗。

Golang是一门工程语言，语法元素很少很容易掌握。从而，只要不是太扯的人写出来的代码理应相差不大，并能够很快被人理解。泛型在现代编程语言中被广泛使用，这里不谈Go缺失泛型是否是一种糟糕的设计，纯粹前段时间在gvisor的代码中看见一种实现泛型的方式比较新奇，因此拿来记录一下。

Shodowsocks是一个小有名气的代理工具，主要致力于减小流量特征，从而达到GFW无法对其进行定向的封杀的目的。Shadowsocks有多种语言的实现，本着学习一下原理的心态，看了一下其用Go版本的实现细节。

在Golang的基础中我们知道在用append的时候，或者Slice底层数组小于需求容量的时候，Go会自动重新分配内存，随之带来的有一次值拷贝。在数据量小或函数调用不频繁的时候对性能的损失并不明显，但是如果在高频率调用或者数据量大的时候，性能损失不能忽略不计。