为自由和真理，英勇地献身

在开始体验之前，我觉得我有必要介绍下Jev是个什么 其实就是一个前OpenAI创始人出来做的所谓system one模型，什么？你问我什么是system one模型？他的官网是这么说的，不管你信不信，反正我是信了.jpg 说他是一个LLM，倒也不完全是，因为他输出不是随机的，只要固定上下文和选项，输入结果就一定一致（有点像temperature=0），并且他的速度特别快，效率这么快的同时，又比那些分类器更强（毕竟没那么死板），算是他们的集合体 具体表现就是你只能输入结构化的数据，不能像传统LLM那样自由地进行自然语言对话。 在这里，结构化数据又表现为他只能接受三种形式的输入，分别是Choice，Socre，Noul，分别对应着几种选择中选择哪个（当然这个几种选择是你自己定义的），在某个维度中处于哪一档，以及某个条件是否成立（gork is that true?） 既然如此，我就有一个大胆的想法，既然jev有选择几个选项中概率的功能，那我岂不是可以给他加上词库，让他强行能说话？ 说干就干，我直接给他加了一个n-gram词库，原理大概就是：当你输入第一个字的时候，他就会根据这个字去词库里面找这个字后面可能会出现的字。 我再把返回的字作为结果，输入到jev里面去，让他根据上下午选一个字，形成一个循环，直到我想要的长度为止，并且为了防止他瞎说话，我还在第一个字的时候加入了个语境预设，让他自己来选择语境 效果如下： 您的浏览器不支持视频播放。 当然，如果你也想试的话也可以直接到这里，我已经”开源“了代码（指代码是gpt一把梭的） 试了几轮之后，我感觉jev最大的优势在于便宜和快，智能程度目前远远比不上主流的”大“模型，很多时候他做的一些决策远远不如主流模型思考后的结果，但是速度要快的多，在类似游戏等需要及时反应的场景会比较有用，说不定让LLM指定好todo之后，让jev去根据这个上下文来作为执行层会是一个不错的选择

你永远不知道意外和明天哪一个先到来，就像我不知道实习转正失败这种时期会发生在我的身上 大概是怪我秋招运气不好，没有任何一家公司愿意面我，朋友给的内推也完全没有用上 总之，快到寒假的时候，我就稀里糊涂的在boss上接到了面试邀请，稀里糊涂就在深圳开启了我的第二段实习 第二段实习总归没有遇到黑心公司让我实习带实习了，mt也非常负责任，公司说可以转正，mt也可以说是把很多东西教会给了我 做了一个多月，搓了一堆小工具，然后ld竟然认为这个算是“产出” 到了三月份，突然有机会接手各类排障工单，也在这个过程中学到了非常多的东西，后面基本所有的排障我都能找出原因，我认为我已经成长为了拥有3-5年经验的sre了（至少在排障上 突然四月份，总部那边进来了两个实习生，又过了几个星期，说hc全部冻结，这个时候我以为除了我们这些转正的后面不会招人了，没想到这只是个开始 就这样靠着ld画的饼干到了6月份，结果有一个实习生去打探风口，就直接说不能转正，一开始包括我在内的三个实习生都以为是只是走一个人，因为当时的mt还跟我说有两个实习生转正名额 再过了一个星期，在周一的一次ld让我排障的时候，他突然问了嘴：“你实习到什么时候？” 那其实意思很明确了，那就是没得转正，就这样，我提起了离职，混到了周五，自此，我就这样从公司“毕业” 躺尸了几天之后我就回了学校，对外嘴硬说是因为学校有大显示器打游戏爽，其实只有自己知道，屏幕上跳动的全是投出去、又石沉大海的简历 当然回学校也有个原因，去年我的习概挂了，结果考试精准安排在正常拿毕业证的那一天，就这样，我算是坐在以后可能不会再热闹的宿舍里面，看着舍友一步步把东西搬空，先我离去了，又因为是周末，他们又都要回去工作，连个散伙饭都没吃 没想到，我的学生时代就是这样，毫无遮拦的过去了。

一、故障现象 在一次客户升级内存CPU之后，服务全挂 最早暴露出来的是 CoreDNS 一直起不来，日志持续报错： 1 2 [INFO] plugin/ready: Still waiting on: "kubernetes" [WARNING] plugin/kubernetes: Kubernetes API connection failure: Get "https://10.43.0.1:443/version": dial tcp 10.43.0.1:443: i/o timeout 这说明 CoreDNS 的 kubernetes 插件无法访问集群内的 Kubernetes API Service，也就是 10.43.0.1:443。 复杂的是，机器里面有两张网卡，ens192和ens224 1 2 3 4 5 [root@linglang-Bi server]# ip route default via 192.168.1.1 dev ens192 10.42.0.0/24 dev cni0 proto kernel scope link src 10.42.0.1 192.168.1.0/24 dev ens192 scope link 192.168.30.0/24 dev ens224 scope link 二、确认 apiserver 存活状态 先查节点状态： ...

一、环境与现象 1.1 环境信息 项目 值 OS CentOS 7 Kernel 3.10.0-1160.119.1.el7.x86_64 容器编排 K3s (内置 containerd) CNI Flannel 1.2 故障现象 在之前客户环境升级组件时，经常有pod长期处于Terminating状态导致无法升级的情况 我在相同内核版本的测试机复现了这个环境，升级后出现多个 Pod 长时间卡在 Terminating 状态无法销毁，新 Pod 处于 Pending： 1 2 3 4 5 6 7 8 9 $ kubectl get pods | grep -E "Terminating|Pending" spark-job-engine-controller-c46bfcc7d-vtpdj 0/1 Pending 0 25h langfuse-worker-8588567885-vxkxw 0/1 Terminating 7 8d analytics-server-controller-7bcf876764-mkg2w 0/1 Terminating 4 8d langfuse-redis-6c5b76587f-4jj26 0/1 Terminating 4 8d langfuse-web-b4bf858d8-2l4xv 0/1 Terminating 11 8d grafana-controller-59cc7fd9bd-dpb7t 0/1 Terminating 4 12d spark-job-engine-controller-c46bfcc7d-xr2g4 0/1 Terminating 2 5d19h analytics-admin-controller-6fb9f7c5b5-ppv2h 0/1 Terminating 7 12d 1.3 Kubelet 报错 1 2 3 4 5 6 7 8 9 10 11 12 13 $ journalctl -u k3s --no-pager -n 500 | grep "device or resource busy" E0331 11:27:25.242419 kuberuntime_manager.go:1040] "PodSandboxStatus of sandbox for pod" err="...remove netns: unlinkat /var/run/netns/cni-4c32477c-303b-b39b-d8df-d94fae2326ff: device or resource busy" pod="default/spark-job-engine-controller-c46bfcc7d-xr2g4" E0331 11:27:25.242649 kuberuntime_manager.go:1040] "PodSandboxStatus of sandbox for pod" err="...remove netns: unlinkat /var/run/netns/cni-d45c9dbd-42b7-e043-17ff-d4881623b543: device or resource busy" pod="default/langfuse-redis-6c5b76587f-4jj26" # ...其余 4 个 Pod 报同样的错误 共 6 个不同的 netns 文件触发 EBUSY，对应 6 个不同的 Pod。 ...

记一次 K3s 网络深坑：为什么宿主机访问 ClusterIP 会超时丢包 TL;DR 由于旧版内核（3.10）与网卡硬件校验卸载（Checksum Offload）不兼容，导致跨节点 VXLAN 封包的 UDP Checksum 错误，被目标节点内核拦截。 背景 故障复现环境 OS: CentOS 7 (Kernel 3.10) K8s Distro: Client Version: v1.18.3-k3s1 Server Version: v1.18.3-k3s1 CNI: Flannel (VXLAN) 网络拓扑资源 宿主机 Node IP: 10.66.3.15 (Gateway: 10.66.3.125) Service CIDR: 10.43.0.0/16 Pod CIDR: 10.42.0.0/16 目标服务: spark-webui (ClusterIP: 10.43.236.230:8080) 1 2 3 4 5 6 [root@master-node ~]# kubectl get nodes -o wide NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME worker-1 Ready <none> 4y52d v1.18.3-k3s1 10.66.3.18 <none> CentOS Linux 7 (Core) 3.10.0-862.14.4.el7.x86_64 docker://18.6.3 worker-2 Ready <none> 50d v1.18.3-k3s1 10.66.3.34 <none> CentOS Linux 7 (Core) 3.10.0-862.14.4.el7.x86_64 docker://18.6.3 master-node Ready master 4y242d v1.18.3-k3s1 10.66.3.15 <none> CentOS Linux 7 (Core) 3.10.0-862.14.4.el7.x86_64 docker://18.6.3 worker-3 Ready <none> 50d v1.18.3-k3s1 10.66.27.195 <none> CentOS Linux 7 (Core) 3.10.0-862.14.4.el7.x86_64 docker://18.6.3 故障现象记录与排查 在某个客户的环境中 ...