xiaohack's Blog - Kubernetes
type: channel
link: https://blog.xiaohack.org/tag/Kubernetes/
items: containerd2.x接入Harbor仓库方法
items: 摩擦解决之道：改变关键要素
items: vivo GPU容器与 AI 训练平台探索与实践
items: Go语言跌到第16位：TIOBE榜单背后，咱们该怎么看这事儿？
items: CVE-2026-22822：External Secrets Operator严重漏洞破坏命名空间隔离机制
items: ETCD的内存问题
items: 希望各位大神解答一下我找不到工作的原因。
items: AI 时代如何证明个人项目的真实性？
items: 如何将 Minio DirectPV 配置为 RustFS PVC？
items: 【k8s部署】麒麟V10离线安装k8s1.32.11

containerd2.x接入Harbor仓库方法
type: item
date: 2026-02-03T21:27:24+08:00
description: 一、核心配置结构说明containerd 2.x 对镜像仓库配置进行了结构化优化，所有相关配置均集中在 /etc/containerd/certs.d/ 目录下，遵循 "一仓库一目录" 的配置原则：每个镜像仓库（registry）对应一个独立目录，目录名需与仓库域名（或 IP 地址）完全一致每个目录下必须包含一个 hosts.toml 文件，用于定义仓库连接参数hosts.toml 核心配置项：仓库服务地址（server）、操作权限（capabilities）、认证信息（auth）、证书验证开关（skip\_verify）二、分步配置实战1. 版本确认首先通过以下命令验证 containerd 版本是否为 2.x 系列：\\\[root@k8s-master ~]# containerd --version containerd containerd.io v2.2.0 1c4457e00facac03ce1d75f7b6777a7a851e5c412. 创建配置目录根据 Harbor 仓库地址创建对应的配置目录，目录名需与仓库域名（或 IP）严格匹配（示例中 Harbor 仓库地址为 harbor.liyb.com）：mkdir -p /etc/containerd/certs.d/harbor.liyb.com注意：若仓库未使用域名（直接通过 IP 访问），可直接以 IP 地址作为目录名（如 /etc/containerd/certs.d/192.168.1.100）3. 编写 hosts.toml 配置文件创建并编辑 hosts.toml 文件，配置仓库连接参数：vi /etc/containerd/certs.d/harbor.liyb.com/hosts.toml添加如下配置内容：server = "https://harbor.liyb.com" \\\[host."https://harbor.liyb.com"] capabilities = \\\["pull", "resolve", "push"] # 支持的操作：拉取、解析、推送 skip\\\_verify = true # 自签名证书时启用（跳过证书验证） \\\[host."https://harbor.liyb.com".auth] username = "admin" # Harbor 登录用户名 password = "Harbor12345" # Harbor 登录密码配置说明：若使用企业级可信证书，无需设置 skip\\\_verify = true，只需将 CA 证书文件放置到对应配置目录（如 /etc/containerd/certs.d/harbor.liyb.com/）即可权限配置可根据实际需求调整，例如仅需拉取镜像时可改为 capabilities = \\\["pull", "resolve"]4. 确认主配置文件路径检查 containerd 主配置文件 /etc/containerd/config.toml 中是否正确指定了仓库配置路径，确保以下配置项存在且无误：toml# /etc/containerd/config.toml \\\[plugins."io.containerd.grpc.v1.cri".registry] config\\\_path = "/etc/containerd/certs.d" # 仓库配置目录路径（默认已启用）注意：containerd 2.x 默认启用该配置，但生产环境部署时务必手动校验，避免路径配置错误导致配置失效三、配置验证方法1. 使用 nerdctl 验证（推荐）通过 nerdctl 工具拉取 Harbor 仓库镜像，验证配置是否生效：nerdctl pull harbor.liyb.com/prod/nginx:1.27成功输出示例：plaintextharbor.liyb.com/prod/nginx:1.27: manifest-sha256:114dff0fc8ee3d0200c3a12c60e3e2b79d0920dd953175ecb78a0b157425b25e: done config-sha256:1e5f3c5b981a9f91ca91cf13ce87c2eedfc7a083f4f279552084dd08fc477512: done elapsed: 0.1 s total: 0.0 B (0.0 B/s)2. Kubernetes 节点验证在 Kubernetes 节点上通过 crictl 工具拉取镜像（适用于 K8s 集群环境）：crictl pull harbor.liyb.com/prod/nginx:1.27关键注意点：镜像名称必须显式包含 Ha…

摩擦解决之道：改变关键要素
type: item
date: 2026-01-31T08:04:10+08:00
description: 当 Andrew Harmel-Law 邀请演讲者参加 QCon 伦敦大会时，他首先想到的是：“让 Diana 和 Cat 一起登台！”这完全是出于一种顽皮的冲动。 Cat Morris 是一位产品经理。Diana Montalion 是一位系统架构师。我们都专门从事软件系统和平台开发。我们都把对方视为我们所有痛苦的根源。不是个人层面的，我们从未一起工作过，但我们都认为对方所代表的角色是问题所在。 但我们也致力于改善我们的工作方式。如果我们能够消除我们之间存在的摩擦……那对每个人来说都是一件好事，对吧？ 首先，我们对参与的每一个重大项目做了建模分析。我们发现，每一个项目的结局都像泰坦尼克号一样：撞上了冰山。 我们发现了以下这些改变职业生涯的真相： 我们的工作有很多重合的地方。我们需要彼此。合作会带来更好的结果。我们思考问题的方式不同但互补。我们要解决的不是技术问题。技术挑战不难解决。困难之处在于消除摩擦。 摩擦是阻碍变革的无形暗流。摩擦并非孤立存在的，而是一个系统性问题，其来源是人、团队与技术之间的关系。解决之道不在于 Kubernetes、云计算或人工智能，而在于改变我们的思维模式、沟通方式和组织架构。 本文描述了在每一个项目中都会反复出现的六种摩擦： 反直觉行为拒绝改变效率与控制产品与技术角色之间相互指责线性管道思维交付能力不足 每一种摩擦都让我们忙于重写相同的代码库或重绘相同的组织结构图。摩擦导致很多无益于我们避开冰山的工作浪费。这篇文章将帮助你弄清楚如何应对这些问题。 反直觉行为 我们怪错了对象。因此，我们做错了事情。 反直觉行为，由系统科学家 Jay Forrester 定义，是指复杂的社会和管理系统倾向于用让问题变得更糟糕的解决方案来应对问题。例如，为一个处于后期的项目增派更多的工程师，加快项目进度。 面对系统性挑战时，我们人类会倾向于指责他人。遗憾的是，我们怪错了对象。我们责怪工程团队工作效率低下，或者断定是因为团队太小，却未能意识到甘特图不过是虚构的简化模型，它过度简化了复杂的动态过程。 “任何系统的输出结果都是其内在设计的必然产物‌。”——W. Edwards Deming 当我们改变一个系统的运作方式时，我们也需要改变塑造系统的底层模式、结构和心智模型。例如，不是在本已臃肿的数据库上放上 GraphQL 就能称之为图，而是需要重新构建我们思考数据的方式。我们需要创建异步事件，而不是把什么都塞进管道，我们需要创建反馈循环，让我们能及时知道数据在跨系统移动时出现了异常。 这可以解释为什么工程师们会工作到很晚。他们一边忙着给猪涂口红，一边又要完成甘特图上没有预料到的工作。 解决之道：理解系统 反直觉行为具有引力，会将我们吸入其中，卷入漩涡。至少，我们的感受是这样：感觉像是在行动，在前进，而实际情况是，我们就像烘干机里的衣物，在原地打转。自始至终，我们都是从同一个狭小的视角凝视问题。 解决方法是暂时停下来，找准方向再行动。 首先是确定核心领域。系统的目标是什么？对于联邦快递来说，是快速递送包裹。很可能，你所经历的反直觉行为，源于人们的说法一致但前进方向不同。 每个参与的人都清楚变革与核心领域的关系吗？怎么才能加快包裹递送而不产生负面影响？系统本身如何导致了问题的产生？当前的流程和模式会产生什么样的心态？系统中的关系如何强化了这些模式？有什么你没有看到的变革需求吗？开始绘制这些模式，确定你的核心领域，所需的变革自然便会显现。 拒绝改变 每个试图变革的组织都有这样一些人：守门人、地牢主、自封的 10 倍速工程师，他们对组织非常了解，并且拥有一个魔法词：不。 他们说，“我们已经尝试过迁移。我们已经尝试过平台迁移或重构。我们已经尝试过重组。都行不通。别费心了。”他们掌握着生产环境或管道或某个关键系统的控制权，你没法忽视他们。 对此，人们很容易把责任归咎于那人的固执性格。但他展现的行为模式，正是长期的奖励与强化所形成的。通过管理遗留系统的复杂性，他已成为不可或缺的存在。要改变他，必须改变整个组织的思维方式，否则，又会冒出另一个类似的角色取而代之。仅靠技术手段无法从根本上解决问题。 拒绝改变是会传染的。当那个人关闭了好奇心，其他人也会转向固定思维模式。人们首先做的是怀疑而不是实验。组织无法在规避风险和尝试新事物之间找到平衡。变革陷入了停滞。 “变革之所以困难，是因为人们高估了他们所拥有的东西的价值，低估了他们放弃这些东西可能获得的价值。” ——《会飞的水牛：卓越腾飞，学会让员工引领》（Belasco 和 Stayer，1999 年） 解决之道：解雇那个人 好吧，这可能有点极端。你可能无法解雇他们，但你可以限制他们的影响。你不是他们的导师、母亲或心理医生。不要陷入那种角色。 把他们装进盒子里。给他们一个静态领域，让他们可以保留自…

vivo GPU容器与 AI 训练平台探索与实践
type: item
date: 2026-01-29T11:57:39+08:00
description: 作者：互联网容器团队-Chen Han、AI 研发团队 - Liu Dong Yang在大规模GPU容器集群与模型训练场景，面临稳定性和资源利用率等多重挑战。本文展示vivo GPU平台的总体架构，介绍容器平台在大规模GPU容器集群稳定性建设措施，以及探索多种GPU容器降本提效的解决方案。分享AI工程训练平台大规模训练稳定性建设，及GPU利用率提升实践经验。本文为2025年 vivo 开发者大会互联网技术专场分享内容之一，在微信公众号"vivo互联网技术"对话框回复【2025VDC】获取 2025VDC 互联网技术会场议题相关资料。1分钟看图掌握核心观点👇图1 VS 图2，您更倾向于哪张图来辅助理解全文呢？欢迎在评论区留言一、GPU平台架构vivo的GPU平台由物理层、容器平台层与AI工程层三方面构成。由多种GPU服务器和分布式存储以及高性能网络等基础设施，构成了可靠的物理层。容器平台层的GPU容器能力，主要包含了资源管理、编排调度、GPU虚拟化与多容器网络这四个方面。其中资源管理，表现为多种架构资源池的部署与管理能力。编排调度能力，由GPU弹性伸缩、训推潮汐部署以及多种卡调度策略组成。自研的GPU虚拟化囊括了业界主流的MIG虚拟化、内核层虚拟化以及CUDA层虚拟化三种技术。由传统的Underlay网络以及SRIOV的RDMA直通网络，组成了丰富的容器网络架构。容器平台提供了开放的API接口，为AI工程层的训练和推理平台，提供了坚实的算力底座。通过训练和推理平台，支撑公司内的智能计算业务。二、GPU容器能力实践GPU容器能力实践分为两个模块，首先是大规模容器集群稳定性建设，其次是GPU容器提效降本方案。先了解下容器平台在大规模容器集群场景，如何进行稳定性建设的。2.1 大规模容器集群稳定性集群稳定性是一切的基石。当集群规模大时，任务多，调度频繁，导致核心组件负载激增，极易发生集群崩溃。随着节点规模扩大，运维复杂度呈指数级增长，日常运维工作繁重，发现问题不及时。同时故障处理也面临严峻挑战，故障中涉及的复杂场景多，故障处理的难度大。稳定性建设需要解决上述问题。为了解决高频调度导致的核心组件高负载问题，我们针对Apiserver、etcd、CoreDNS，这3个核心组件进行了架构和性能优化，具体的方案如图所示。通过这些优化手段提升了组件性能，并且降低了组件负载，有利于大规模集群的平稳运行。为了减轻集群运维负担，我们重点建设了自动化节点管理方案。把重复性的运维事项自动化。同时我们还完善了监控告警体系，开发了自动化巡检功能，使运维人员能够及时发现集群问题，快速介入，处理潜在风险，保障集群能够长久稳定运行。故障处理是集群稳定的兜底措施，我们针对多个核心组件都做了，各类故障处理预案。结合可能存在的故障特点，构造故障场景，进行故障恢复演练，确保故障发生时，能够第一时间找到合理的解决方案，准确的处理问题。通过上述的措施，在集群稳定性方面取得了不错的效果，首先日常的集群可用性稳定保持在99.99%水平，其次平台的年度故障复盘数相较于上一年下降60%。核心组件方面的优化也达到了不错效果，其中Apiserver的CPU负载下降70%，etcd提交延迟，从秒级缩短到毫秒级，CoreDNS的毛刺现象消失了，并且负载量下降了90%左右。2.2 GPU容器提效降本实践容器平台的核心竞争力之一就是助力业务提效降本，我们从不同业务维度，对GPU容器提效降本方案进行了探索。首先在单卡维度，通过自研GPU虚拟化方案，使多个容器，互不干扰的共享一张卡资源。其次是在单服务维度，使业务能够自动应对，负载变化的GPU弹性扩缩容方案。在多服务维度，能够让推理服务和训练服务，分时复用整机资源的，训推潮汐部署方案。最后是在多机多卡的分布式场景中，让GPU容器搭配RDMA网络，来解决跨节点通信的瓶颈问题。2.2.1 单卡共享-GPU虚拟化如何让一张卡同时运行多个容器又不互相干扰，就涉及到GPU虚拟化技术。GPU虚拟化一直是AI云原生领域的热门话题之一，各大云厂商都有成熟的解决方案售卖。vivo容器平台的自研GPU虚拟化方案，主要为了解决业务的三大痛点，首先是部分推理业务负载偏低，无法有效用满整卡资源，需要通过共享部署方式，减少资源总量，降低业务成本，提升利用率。其次是不同业务共享同一张卡时，对于安全性以及隔离性的要求各不相同，就需要使用不同的GPU虚拟化技术来满足不同业务诉求。最后在Dev开发机场景，用户使用频率偏低，需要通过显存超售，来提升资源复用率，但显存超售后又需要避免某个用户将显存耗尽，导致OOM错误影响同卡的其他用户。自研GPU虚拟化方案包含MIG虚拟化、内核层虚拟化、CUDA层虚拟化这三种技术。结合业务场景，提供了丰富的卡调度策略，例如尽量聚集的Binpack策略、尽量…

Go语言跌到第16位：TIOBE榜单背后，咱们该怎么看这事儿？
type: item
date: 2026-01-27T18:20:54+08:00
description: 刚出的榜单，Go掉得挺多今年1月的TIOBE编程语言排行榜出来了。有个事儿挺显眼的，Go语言这次排到了第16名。要知道，2024年11月它还在第7名呢，这才过了多久，直接掉了9名。很多写Go的朋友看到这个可能心里会犯嘀咕：这语言是不是不行了？以后还能不能用它找工作了？咱们先别急着下结论。在讨论这个问题之前，咱们得先搞清楚这个榜单到底是怎么回事，这次排名下降是不是真的代表Go语言出了大问题。TIOBE指数到底是啥？TIOBE这个榜单，它统计的数据来源其实是各大搜索引擎。简单说，就是看有多少人在百度、谷歌、必应这些地方搜这门语言的名字。它反映的是一种“搜索热度”。这里面有个逻辑大家要明白：一门语言搜的人多，不代表用的人就多；反过来，搜的人少，也不代表用的人就少。通常什么样的人会去搜？新手刚开始学的时候，或者遇到报错搞不定的时候，搜得最多。如果一门语言大家都会用了，或者它运行很稳定、没啥新花样，大家反倒不去搜了。所以，TIOBE的排名主要代表的是大家对这门语言的“好奇心”和“陌生感”，而不是它在实际项目里的使用率。为啥这次Go掉到了第16？那Go语言这次为啥排名掉得这么明显？我觉得有这么几个实实在在的原因。Rust语言现在确实很受欢迎。在这次榜单上，Rust排到了第13名。Rust在安全性、系统底层开发这些方面确实有优势，吸引了很多开发者的注意力。本来有些可能打算学Go的人，现在可能转头去研究Rust了。大家的关注点分散了，搜Go的人自然就少了一些。还有就是Go语言现在太“稳”了。它现在的版本兼容性做得很好，依赖管理也成熟了。以前大家可能会经常搜“Go怎么配置环境”、“Go这个库怎么用”，现在这些问题都解决了，不需要老去搜。而且，Go语言现在主要用在服务器后台、云计算这些地方。大家用Docker、用Kubernetes，底层其实都是Go写的，但大家平时操作的是命令行，不需要直接去写Go代码，也就不会去搜它。实际情况到底怎么样？排名虽然掉了，但咱们看看实际工作中的情况。现在的互联网公司，特别是做后端开发的，用Go的还是非常多。像很多大厂的核心系统，依然是用Go在写。在云原生这个领域，Go的位置目前还是很稳固的，没什么语言能轻易替代它。Go语言有个很大的优点，就是简单、直接。代码写起来快，跑起来性能也不错，维护起来也方便。对于公司来说，这能省成本，能提高效率。只要这个优势还在，公司就不会轻易把它换掉。总结所以看到排名下降，不用太担心。这个榜单反映的是当下的关注度和话题度，不是实际的市场占有率。Go语言现在进入了一个平稳发展的阶段，不像刚出来时那么有新鲜感，但它在实际工作中还是非常有用的。大家该学还是学，该用还是用。选编程语言，看的是能不能解决实际问题，能不能帮你把活干好，而不是看它在榜单上排第几。只要它还能帮你高效地开发系统，它就是有价值的。⚡️ 别把时间浪费在低效复习上很多人复习抓不住重点。作为过来人，我分析了100+份大厂面试记录，将 Go/Java/AI 的核心考察点、高频题、易错点 浓缩进了一份 PDF。不搞虚的，全是干货。加我微信：wangzhongyang1993，备注 【面经】 免费发你，立即纠正你的复习方向，把时间用在刀刃上。

CVE-2026-22822：External Secrets Operator严重漏洞破坏命名空间隔离机制
type: item
date: 2026-01-26T14:21:56+08:00
description: External Secrets Operator 中发现了一个严重安全漏洞。该工具是 Kubernetes 生态中广泛使用的外部密钥管理组件，用于连接 AWS Secrets Manager、HashiCorp Vault 等外部密钥系统与 Kubernetes 集群。漏洞编号为 CVE-2026-22822，CVSS 评分高达 9.3（严重），意味着攻击者可能借此直接获取敏感数据。 该漏洞导致 不安全的密钥读取（Insecure Secret Retrieval），并破坏了 Kubernetes 中最基本的命名空间隔离机制。 问题源于一个名为 getSecretKey 的模板函数。该函数最初是为了支持 senhasegura DevOps Secrets Management (DSM) 提供商而引入的，但后来被发现功能过于强大，从而带来安全隐患。 根据安全公告：“该函数能够在 external-secrets 控制器的 roleBinding 权限下跨命名空间读取密钥，从而绕过我们的安全机制。” 这意味着，一个命名空间中的恶意资源或配置错误的资源，可能读取到另一个命名空间的密钥—— 而这些密钥原本是完全不允许它访问的。“攻击者或配置错误的资源可以从非预期的命名空间中读取密钥。” 这种绕过的影响极为严重。如果攻击者能够读取特权命名空间中的密钥，他们就能轻松进一步提升权限并完全控制集群。报告指出：“未经授权访问密钥可能导致权限提升、数据泄露，或服务账号与凭据被窃取。” 管理员应立即审计其集群。该漏洞影响 External Secrets Operator 从 v0.20.2 到 v1.2.0 的所有版本。 维护者采取了果断的修复方式：直接删除了该功能。“该函数已被完全移除，因为它能实现的所有功能都可以通过其他方式完成，同时不会破坏我们的安全防护机制。” 用户被敦促立即升级到 v1.2.0 版本，该版本通过删除问题代码彻底修复了漏洞。 对于暂时无法升级的用户，也有临时缓解方案。管理员可以使用 Kyverno、Kubewarden 或 OPA 等策略引擎来 “阻止在任何 ExternalSecret 资源中使用 getSecretKey 函数”。

ETCD的内存问题
type: item
date: 2026-01-24T18:24:06+08:00
description: 今天跟大家分享一个etcd的内存大量占用的问题，这是前段时间在我们开源软件Easegress中遇到的问题，问题是比较简单的，但是我还想把前因后果说一下，包括，为什么要用etcd，使用etcd的用户场景，包括etcd的一些导致内存占用比较大的设计，以及最后一些建议。希望这篇文章不仅仅只是让你看到了一个简单的内存问题，还能让你有更多的收获。当然，也欢迎您关注我们的开源软件，给我们一些鼓励。为什么要用ETCD先说一下为什么要用etcd。先从一个我们自己做的一个API网关 – Easegress（源码）说起。Easegress 是我们开发并开源的一个API应用网关产品，这个API应用网关不仅仅只是像nginx那样用来做一个反向代理，这个网关可以做的事很多，比如：API编排、服务发现、弹力设计（熔断、限流、重试等）、认证鉴权（JWT，OAuth2，HMAC等）、同样支持各种Cloud Native的架构如：微服务架构，Service Mesh，Serverless/FaaS的集成，并可以用于扛高并发、灰度发布、全链路压力测试、物联网……等更为高级的企业级的解决方案。所以，为了达到这些目标，在2017年的时候，我们觉得在现有的网关如Nginx上是无法演进出来这样的软件的，必需重新写一个（后来其他人也应该跟我们的想法一样，所以，Lyft写了一个Envoy。只不过，Envoy是用C++写的，而我用了技术门槛更低的Go语言）另外，Easegress最核心的设计主要有三个： 一是无第三方依赖的自己选主组集群的能力 二是像Linux管道命令行那样pipeline式的插件流式处理（支持Go/WebAssembly） 三是内置一个Data Store用于集群控制和数据共享。 对于任何一个分布式系统，都需要有一个强一制性的基于Paxos/Raft的可以自动选主机制，并且需要在整个集群间同步一些关键的控制/配置和相关的共享数据，以保证整个集群的行为是统一一致的。如果没有这么一个东西的话，就没有办法玩分布式系统的。这就是为什么会有像Zookeeper/etcd这样的组件出现并流行的原因。注意，Zookeeper他们主要不是给你存数据的，而是给你组集群的。Zookeeper是一个很流行的开源软件，也被用于各大公司的生产线，包括一些开源软件，比如：Kafka。但是，这会让其它软件有一个依赖，并且在运维上带来很大的复杂度。所以，Kafka在最新的版本也通过内置了选主的算法，而抛弃了外挂zookeeper的设计。Etcd是Go语言社区这边的主力，也是kubernetes组建集群的关键组件。Easegress在一开始（5年前）使用了gossip协议同步状态（当时想的过于超前，想做广域网的集群），但是后发现这个协议太过于复杂，而且很难调试，而广域网的API Gateway也没遇到相应的场景。所以，在3年前的时候，为了稳定性的考量，我们把其换成了内嵌版本的etcd，这个设计一直沿用到今天。Easegress会把所有的配置信息都放到etcd里，还包括一些统计监控数据，以及一些用户的自定义数据（这样用户自己的plugin不但可以在一条pipeline内，还可以在整个集群内共享数据），这对于用户进行扩展来说是非常方便的。软件代码的扩展性一直是我们追求的首要目标，尤其是开源软件更要想方设法降低技术门槛让技术易扩展，这就是为什么Google的很多开源软件都会选使用Go语言的原因，也是为什么Go正在取代C/C++的做PaaS基础组件的原因。背景问题好了，在介绍完为什么要用etcd以后，我开始分享一个实际的问题了。我们有个用户在使用 Easegress 的时候，在Easegress内配置了上千条pipeline，导致 Easegress的内存飙升的非常厉害- 10+GB 以上，而且长时间还下不来。用户报告的问题是——在Easegress 1.4.1 上创建一个HTTP对象，1000个Pipeline，在Easegres初始化启动完成时的内存占用大概为400M，运行80分钟后2GB，运行200分钟后达到了4GB，这期间什么也没有干，对Easegress没有进行过一次请求。一般来说，就算是API再多也不应该配置这么多的处理管道pipeline的，通常我们会使用HTTP API的前缀把一组属于一个类别的API配置在一个管道内是比较合理的，就像nginx下的location的配置，一般来说不会太多的。但是，在用户的这个场景下配置了上千个pipeline，我们也是头一次见，应该是用户想做更细粒度的控制。经过调查后，我们发现内存使用基本全部来自etcd，我们实在没有想到，因为我们往etcd里放的数据也没有多少个key，感觉不会超过10M，但不知道为什么会占用了10GB的内存。这种时候，一般会怀疑e…

希望各位大神解答一下我找不到工作的原因。
type: item
date: 2026-01-23T16:03:40+08:00
description: 下面是我的简历持有 CKA ccna 认证。长期负责高并发电商系统的稳定性与性能治理，理解 Nginx 的事件驱动模型、Worker 并发机制与请求生命周期控制方式，并将其抽象为 “进入策略（ Admission ）— 排队策略（ Queueing ）— 满载策略（ Overload ）” 的系统行为诊断框架。通过拆解全链路时间指标（ Time-based Metrics ），结合 P95 / P99 延迟分位数，对比 request_time 与 upstream_response_time，判断请求阻塞发生在进入控制、系统排队或下游依赖阶段，用于快速界定网络层、应用层与数据层的性能边界。参与并主导多次从单体架构向云原生、无状态化架构的演进，关注系统的可解释性、稳定性与成本控制。技术技能SRE 与性能诊断 使用 Ingress / Queue / Worker / Egress 作为系统分层对象进行问题定位 基于 P95 / P99 延迟分位数 分析尾延迟（ Tail Latency ） 通过 request_time 与 upstream_response_time 的分位数差异判断系统内部是否发生排队 区分整体性能退化与少量请求异常放大的不同问题模式 依据进入控制、排队与满载策略分析系统稳定性取舍 Web 与中间件 Nginx 事件驱动模型、Worker 并发模型、连接与请求生命周期 使用 limit / buffer / backlog / timeout 等配置参数实施系统行为控制 Nginx 与 PHP-FPM 的 Worker / Process / Queue 协同关系 高并发 WordPress 架构的稳定性与性能治理 云原生与基础设施 阿里云：ECS 、RDS 、OSS 、ALB AWS Docker 、Kubernetes （ CKA ） Terraform （基础设施即代码） Calico （ Kubernetes 网络模型与 NetworkPolicy ） 数据库与数据处理 MySQL 使用与常见性能问题定位 SQL 编写 PL/SQL 阅读 ETL 流程（数据抽取、清洗、加载） 结合 P95 / P99 延迟分布 判断数据库是否为系统尾延迟来源 自动化与运维 Ansible Playbook Shell 脚本 配置一致性与变更管理 网络 TCP/IP VPN 负载均衡 CCNA 网络体系 工作经历基础设施负责人 / 高级运维工程师负责自营跨境电商平台的技术架构设计、云资源管理与系统稳定性。性能瓶颈诊断与容量优化 通过时间指标发现平均响应时间稳定，但 P95 / P99 延迟显著升高 在 upstream_connect_time 正常的情况下，response_time 分位数拉长 判断请求未阻塞在网络或 TCP 层，而是在系统内部发生资源排队 结合 Nginx 与 PHP-FPM 的并发模型，将问题定位为应用层并发策略导致的 Worker 争用 优化措施： 引入 Redis 缓存，降低同步资源竞争 调整 PHP-FPM Worker 数量，减少高分位请求等待时间 调整 Nginx 超时与失败处理策略，防止慢请求放大系统负载 结果： 页面 P95 延迟从约 5 秒下降至 2 秒以内 尾延迟明显收敛 高峰期服务稳定性显著提升 电商架构云原生改造 数据库迁移至阿里云 RDS 媒体资源迁移至 OSS 前端通过 ALB 进行多节点负载 应用层实现无状态化部署 结果： 系统支持水平扩展 综合成本下降约 30% 大促期间可用性维持在 99.9% 日常运维 使用 Ansible 管理 Nginx / PHP 配置 MySQL 备份与恢复演练 OpenVPN 远程访问环境维护 早期经历网络管理员 / IT 支持2011 年 – 2015 年 企业网络规划与服务器维护 SQL 数据提取与分析 教育背景与证书 CKA （ Certified Kubernetes Administrator ） CCNA （ Cisco Certified Network Associate ） 请教各位。我做了 10 年电商，从 23 岁就开始做了，这些爱好自学的。现在走下坡路了，要出来找工作了。 我学历也很低，是函授大专。今年 33 岁了。 我对内核，nginx,sre ，这些也有深入的理解，我不会开发软件，纯粹的想走运维路线 最近也打算学 python ，不会写脚本确实没有竞争力。 我知道我的问题，学历低，没项目经验和实际的工作经验，年纪也大。 上面每项技术，我确实认真的学了很久，而且做过大量的实验实操，理论也很扎实。 boss 直聘主动联系我的人很多，但是简历发了后基本就没下文了。 各位有某些负责招聘的老大，希望能说一下你们的观…

AI 时代如何证明个人项目的真实性？
type: item
date: 2026-01-23T11:53:52+08:00
description: 背景前天朋友提供一个内推岗，这个公司蛮不错的，规模大待遇好还不是外包也不是有争议的 web3 ，他在里面工作，说招好几个月了还是没人去。我有个个人微服务项目准备拿去应聘，然而推荐后说没办法还是得垂直经验，因为现在有 AI 生成代码很简单，个人项目很容易被认为是 AI 代工。项目介绍项目原先是通过网课教程做的但不符合生产要求被我全部推翻重写，原来是 go micro 2.9.1 现在是 go micro 4 ，所有服务都是领域驱动，改过框架源码，链路追踪、监控、日志系统、架构等全部一人完成，期间技术栈做了很大的调整，一共迭代 6 个版本，目前是 6.1 ，耗时 3 个月，至今仍在迭代，有部分自编组件。包含压测报告、决策记录、变更日志和自述文件（含项目介绍及部署指南），用 Github Project 管理项目，2 周一版，部署在阿里云 K8S 集群上，使用超过 15 个组件，还用到 LUA 脚本。服务是模拟支付回调扣减库存过程，每个服务 2 个副本，单个 Pod 上限为单核 CPU + 512M 内存，压测 1596Qps ，P99 为 84ms 。不存在 AI 代工我开发过程中主要是用 AI 推荐轻量级工具并分析其难度，代码大部分还是自己写，因为 go micro 做 EDA 架构的案例本身就少得可怜直接导致 AI 生成的代码不靠谱，最后还是被我的方案优雅地取代。开发过程中每个版本都是巨大的挑战。请问各位大佬如何证明个人项目不是 AI 代工以实现成功转型 Golang 开发？

如何将 Minio DirectPV 配置为 RustFS PVC？
type: item
date: 2026-01-23T11:41:52+08:00
description: RustFS 作为新一代的分布式对象存储系统，提供了 Helm Chart 以便 Kubernetes 集群上安装 RustFS 实例。而 DirectPV 是一个符合 CSI 标准的 Kubernetes 存储项目，由 Minio 发布且开源。本文使用 DirectPV 为 Kubernetes 上的 RustFS 实例提供后端存储服务，实现两个对象存储服务的“结合”。前提运行良好的 Kubernetes 集群。本文使用 K3S 作为测试环境，根据 K3S 安装指南完成安装：# 安装 K3S curl -sfL https://get.k3s.io | sh - # 安装确认 kubectl get nodes NAME STATUS ROLES AGE VERSION vm-0-17-ubuntu Ready control-plane 63m v1.34.3+k3s1一块空磁盘本文在安装 K3S 的服务器上（OS 为 Ubuntu 24.04）挂载了一块容量为 20GB 的新磁盘：df -h vdb 253:16 0 20G 0 disk /root/data/disk mount | grep vdb /dev/vdb on /root/data/disk type ext4 (rw,relatime)安装 DirectPV可以直接根据 minio/directpv 文档进行 DirectPV 的安装。这个过程中会使用到 krew plugin，根据不同的 OS 执行安装命令即可。在 Ubuntu 上执行如下命令：( set -x; cd "$(mktemp -d)" && OS="$(uname | tr '[:upper:]' '[:lower:]')" && ARCH="$(uname -m | sed -e 's/x86_64/amd64/' -e 's/\(arm\)\(64\)\?.*/\1\2/' -e 's/aarch64$/arm64/')" && KREW="krew-${OS}_${ARCH}" && curl -fsSLO "https://github.com/kubernetes-sigs/krew/releases/latest/download/${KREW}.tar.gz" && tar zxvf "${KREW}.tar.gz" && ./"${KREW}" install krew )安装完毕，将 PATH="${KREW_ROOT:-$HOME/.krew}/bin:$PATH" 写到 ~/.bashrc 或 ~/.zshrc 即可。开始安装 DirectPV。安装 directpv krew 插件kubectl krew install directpv在 Kubernetes 集群中安装 DirectPVkubectl directpv install Installing on unsupported Kubernetes v1.34 ███████████████████████████████████████████████████████████████████████████ 100% ┌──────────────────────────────────────┬──────────────────────────┐ │ NAME │ KIND │ ├──────────────────────────────────────┼──────────────────────────┤ │ directpv │ Namespace │ │ directpv-min-io │ ServiceAccount │ │ directpv-min-io │ ClusterRole │ │ directpv-min-io │ ClusterRoleBinding │ │ directpv-min-io │ Role │ │ directpv-min-io │ RoleBinding │ │ directpvdrives.directpv.min.io │ CustomResourceDefinition │ │ directpvvolumes.directpv.min.io │ CustomResourceDefinition │ │ directpvnodes.directpv.min.io │ CustomResourceDefinition │ │ directpvinitrequests.directpv.min.io │ CustomResourceDefinition │ │ directpv-min-io │ CSIDriver │ │ directpv-min-i…

【k8s部署】麒麟V10离线安装k8s1.32.11
type: item
date: 2026-01-23T09:53:40+08:00
description: 本文以麒麟V10为例，演示超简单离线部署k8s 1.32.11。1 说明关于ktkt是基于kk二次开发产物，具备kk的所有功能，二开重点适配了信创国产化环境。主要改进包括：简化arm架构部署过程、支持国产化和国际环境在线、离线部署及一条命令所有节点初始化。支持arm64和amd64架构操作系统，已适配芯片+操作系统 如下：CPU： 鲲鹏、飞腾、海光、兆芯、intel、amd 等。OS： Centos、Ubuntu、Debian、银河麒麟V10、麒麟国防版、麒麟信安、中标麒麟V7、统信UOS、华为欧拉、移动大云、阿里龙蜥、TencentOS等。注：本文使用kt版本3.1.13kt文档： kt文档2.环境准备服务器基本信息主机名架构OS配置IPmasterx86_64麒麟V102核4G192.168.85.1532.1 上传离线制品操作系统不需要安装docker,不需要设置selinux,swap等操作，全新的操作系统即可。将离线制品、配置文件、kt和sh脚本上传至服务器其中一个节点(本文以master为例)，后续在该节点操作创建集群。2.2 修改配置文件根据实际服务器信息，配置到生成的config-sample.yaml中kind: Cluster metadata: name: sample spec: hosts: - {name: master, address: 192.168.85.160, internalAddress: 192.168.85.143, user: root, password: "123123"} roleGroups: etcd: - master control-plane: - master worker: - master # 如需使用 kk 自动部署镜像仓库，请设置该主机组 （建议仓库与集群分离部署，减少相互影响） # 如果需要部署 harbor 并且 containerManager 为 containerd 时，由于部署 harbor 依赖 docker，建议单独节点部署 harbor registry: - master controlPlaneEndpoint: ## Internal loadbalancer for apiservers internalLoadbalancer: haproxy domain: lb.kubesphere.local address: "" port: 6443 kubernetes: version: v1.32.11 clusterName: cluster.local autoRenewCerts: true containerManager: docker etcd: type: kubekey network: plugin: calico kubePodsCIDR: 10.233.64.0/18 kubeServiceCIDR: 10.233.0.0/18 ## multus support. https://github.com/k8snetworkplumbingwg/multus-cni multusCNI: enabled: false registry: type: harbor registryMirrors: [] insecureRegistries: [] privateRegistry: "dockerhub.kubekey.local" namespaceOverride: "kubesphereio" auths: # if docker add by `docker login`, if containerd append to `/etc/containerd/config.toml` "dockerhub.kubekey.local": username: "admin" password: Harbor@123 # 此处可自定义，kk3.1.8新特性 skipTLSVerify: true # Allow contacting registries over HTTPS with failed TLS verification. plainHTTP: false # Allow contacting registries over HTTP. certsPath: "/etc/docker/certs.d/dockerhub.kubekey.local" addons: []2.3 系统初始化解压kt-x86.tar.gz文件后执行./kt init-os -f config-sample.yaml 已适配操作系统和架构见1.说明该命令kt会根据配置文件自动判断操作系统和架构以完成所有节点的初始化配…