MoreRSS

site iconAnZhihe | 安志合修改

博客 编程 运维 随笔 国学
国学和传统文化爱好者，IT行业从业者，运维和SRE。
RSS: https://chegva.com/feed/
请复制 RSS 到你的阅读器，或快速订阅到 :

Inoreader Feedly Follow Feedbin Local Reader

AnZhihe | 安志合的 RSS 预览

AI领域核心术语技术总览表

2025-07-11 01:12:03

分类 术语 基础概述 关键技术 发展历程 应用场景
基础概念 AI（Artificial Intelligence）人工智能 模拟人类智能的计算机系统，执行学习、推理、决策等任务，用于模拟、扩展和增强人类智能的技术工具和方法

符号主义（规则系统）、连接主义（神经网络）、行为主义（环境交互），

生成式AI、自然语言处理（NLP）、Transformer模型、BERT、PEFT微调方法及大语言模型（LLM）等

1956年达特茅斯会议提出；

2012年深度学习爆发；

2022年生成式AI革命

 自动驾驶、医疗诊断、智能客服、内容创作辅助、人机协作
ML（Machine  Learning）机器学习 利用数据进行学习的技术，从数据中学习规律，使计算机能够通过算法模型从数据中获取特征并不断优化模型以做出决策和预测，无需显式编程即可改进其性能

监督学习（分类/回归）、无监督学习（聚类）、强化学习（奖励机制）

机器学习的核心技术包括算法原理，涉及模型训练、特征工程、模型部署等流程，同时涵盖损失函数、正则化项等策略，以实现有效的模型评估与选择。

1958年感知机诞生；

1986年BP算法；

2012年ImageNet竞赛突破

 金融风控、推荐系统、图像识别
DL（Deep  Learning）深度学习 基于多层神经网络的复杂模式学习，利用多层神经网络处理复杂数据模式的机器学习技术，通过模拟人脑神经网络进行学习和识别的机器学习方法 CNN（图像处理）、RNN/LSTM（时序数据）、Transformer（自注意力机制）

2012年AlexNet夺冠；

2014年GAN；

2015年ResNet

 AlphaGo、语音识别、图像处理、自然语言理解
RL（Reinforcement Learning）强化学习 通过环境反馈（奖励/惩罚）优化决策策略，是一种优化整个决策过程以最大化累积收益的算法领域，重点关注决策之间的相互影响

Q-learning和Sarsa、策略梯度、深度强化学习（DQN）

强化学习的核心要素包括智能体、环境、状态、观测、动作、奖励和策略，它们共同决定了智能体如何通过与环境的交互来最大化累积奖励。

1997年IBM深蓝；

2016年AlphaGo；

2025年工业机器人自主决策

 游戏AI、机器人控制、游戏对抗、资源调度
模型技术 LLM（Large Language Model）大语言模型 超大规模神经网络，通过海量文本训练掌握语言规律，具备模拟人类语言理解和生成的能力 变压器架构（Transformer）、注意力机制、位置编码、预训练与微调

2018年BERT；

2020年GPT-3；

2023年GPT-4多模态融合

 ChatGPT、文心一言、代码生成
推理模型 结合逻辑规则与数据驱动的决策系统，专注于多步推理任务的模型，旨在增强人工智能的问题解决能力 神经符号融合、知识图谱集成、动态计算分配 2024年通义千问3推出"混合推理"（快思考+慢思考） 法律咨询、医疗诊断、金融预测
多模态模型 融合文本、图像、音频等多种输入/输出形式的AI模型和技术 跨模态对齐、联合表示学习、多模态生成、协同学习

2023年GPT-4V；

2024年谷歌Gemini；

2025年Sora视频生成

 视频内容创作、跨媒体搜索、智能硬件交互、图像建模
训练优化 预训练 通过在大规模未标注数据上进行训练，使模型能够学习到通用的语言模式和特征表示 掩码语言建模（MLM）、自监督学习、万亿级token处理 2018年BERT开启预训练时代；
2023年千亿参数成为常态		 模型初始能力构建、迁移学习基础、推荐系统
模型微调 在预训练模型上使用领域数据适配特定任务，通常涉及数据集准备、模型训练和效果评估等步骤，相比提示词调优，它更为复杂且资源需求大 指令微调（Instruction Tuning）、LoRA（低秩适配）、P-tuning v2参数高效微调技术 2020年后成为LLM落地标准流程；
2024年高效微调技术普及		 行业知识问答、专业文档分析、图像生成与编辑
模型剪枝 用于减少神经网络的大小和计算复杂度，通过删除不重要的权重或神经元来简化模型结构 结构化剪枝（通道/层移除）、非结构化剪枝（权重归零）、知识蒸馏结合剪枝 2015年首次应用于CNN；
2024年移动端模型压缩关键技		 大规模语言模型压缩、手机端部署（如荣耀Magic V5搭载通义千问3）
蒸馏 通过将大型模型的知识和技能传递给小型模型，以提高小型模型的性能和效率，用小模型模仿大模型行为以降低推理成本 知识迁移、软标签学习、输出分布匹配
白盒蒸馏、多教师蒸馏、自蒸馏		 2015年Hinton提出知识蒸馏概念；
2024年开源小模型（DeepSeek-V3）的核心技术		 大模型蒸馏、边缘计算、实时推理场景
数据标注 为训练数据添加标签以指导模型学习，是人工智能开发中的关键环节，涉及对原始数据进行标记和处理，以便机器学习算法能够理解和分析。这一过程通过添加标签、框选、涂色、转写等多种操作，确保数据集的质量和准确性 主动学习、手工标、半自动标注、自动化标注、众包质量控制 1992年LDC建立首个标注库；
2025年AI辅助标注效率提升10倍		 自动驾驶数据集（图像标框）、医疗影像标注
应用组件 RAG（Retrieval-Augmented Generation）检索增强生成 通过结合检索和生成模型，利用向量数据库存储和检索文档段落，增强大模型的回答能力，使其能够基于最新数据和文档内容准确回复用户问题，减少幻觉 向量检索、上下文融合、多轮迭代查询、外部知识库、生成框架 2020年Naive RAG；
2024年Modular RAG（模块化解耦）		 专业问答（医疗/法律）、客服知识库更新、智能问答系统
Prompt（提示词） 用于定义任务指令、提供输入内容并设定输出要求的关键元素，通过角色扮演、分隔符使用等技巧优化输出，引导AI模型生成特定的回答或执行特定任务。Prompt可以让AI更准确地理解你的需求，从而给出更有用的回答 角色设定、Few-shot Prompting、Chain-of-Thought Prompting及Prompt Chaining 从GPT-1线性指令→2023年混合提示策略（角色+约束+示例） 高效生成报告、创作诗歌、优化代码
NLP（Natural Language Processing）自然语言处理 使计算机能够理解、解释和生成人类语言的技术 词嵌入、依存句法分析、语义词法分析、情感计算、语言模型 1950s规则驱动→2013年神经NLP→2025年神经符号融合 聊天机器人、虚拟助手、机器翻译、情感分析、智能写作
AIGC（AI Generated Content）生成式人工智能 人工智能自动生成高质量的文本、图像、音视频等内容 GAN、扩散模型、自回归生成，embedding、one-hot编码、词袋模型、词嵌入模型、CLIP模型和DDPM，生成式AI、分析型AI、认知型AI，内容质量评估 2014年GAN诞生；
2022年Stable Diffusion；
2025年多模态AIGC爆发		 虚拟偶像（初音未来）、新闻自动撰稿、影视特效、AI绘图、智能UI
AI Agent（智能体） 具有自主感知规划、决策和执行任务的AI系统，通过学习与进化，能够完成复杂的任务 大规模预训练模型支持、记忆与认知机制、工具调用（Tool Use）、多智能体协作 2023年AutoGPT；
2025年钉钉AI表格（单元格即智能入口）		 智能客服、业务流程自动化、个人办公助手、日常任务助手
工作流编排 将多个AI任务组合为自动化流程，通过将一系列任务或步骤有序连接，确保业务高效流畅地执行 DAG调度、异常处理、人机协同介入 2024年LangChain流行；
2025年钉钉AI工作流引擎		 电商达人管理、跨部门审批流程、IT系统集成、制造业生产调度
应用系统 DeepSeek 中国领先的AI公司，专注于大型语言模型（LLM）和多模态模型的研发 MoE架构、小模型优化、长上下文支持 2024年发布R1；
2025年V3推理成本降1000倍		 企业私有化部署、学术研究、金融健康、医疗健康、电商推荐
通义千问 阿里云开发的大规模预训练语言模型，旨在提供先进的自然语言处理和多模态处理能力 混合推理（快/慢思考）、多语言支持（119种） 2023年开源；
2025年千问3性能超越Llama 3		 智能客服、内容生成、编程辅助、高德地图智能导航
ChatGPT OpenAI开发的对话式生成预训练Transformer模型，其核心目标是通过自然语言交互完成复杂任务。让"ChatGPT=智能"成为全球用户心智共识。 Transformer架构、RLHF（人类反馈强化学习）、指令微调（Instruction Tuning）、多模态扩展 2018：GPT-1诞生，1.17亿参数，验证Transformer有效性；

2020：GPT-3（1750亿参数）支持零样本学习，API开放引爆开发者生态；

2025.2：GPT-5上线，强化复杂推理与工具调用

 反欺诈系统、编程辅助、办公自动化、超级助手

参考：


K8s集群etcd磁盘更换

2025-07-09 20:22:47

在 Kubernetes 生产环境中更换 etcd 节点的磁盘是一个高风险操作，需谨慎执行。什么情况需要更换磁盘？

  • 磁盘性能不足，如机械盘升级到 SSD

  • 磁盘硬件存在问题，影响稳定性

ETCD 对磁盘性能要求非常敏感，强烈建议使用 SSD 且独立挂盘。如果有更高性能要求，可以选择分离 snapshot(快照文件)/wal(预写日志)的目录，使用两块盘分离 IO 读写。

以下是详细步骤和注意事项，以三节点 etcd 集群 （ETCD 使用 static pod 方式部署）为例：

核心原则

  1. 一次只操作一个节点：确保集群始终满足 N/2 + 1 的存活节点（3 节点集群需至少 2 节点在线）。

  2. 完整备份：操作前必须备份 etcd 数据，并制定好灾备恢复计划。

  3. 业务低峰期操作：减少对集群的影响，并制定好验证方案。

  4. 演练及回滚计划：生产环境操作前务必在测试环境演练！确保团队熟悉流程并备有回滚计划。

操作步骤

1. 前置准备

  • 备份 etcd 数据（在任一 etcd 节点执行）：

    ETCDCTL_API=3 etcdctl \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  snapshot save /tmp/etcd-snapshot-$(date +%Y%m%d).db

    验证备份完整性：

    etcdutl snapshot status /tmp/etcd-snapshot-*.db

  • 检查集群健康状态：

    ETCDCTL_API=3 etcdctl \
  --endpoints=10.0.1.6:2379,10.0.1.7:2379,10.0.1.8:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  endpoint status -w table

ETCDCTL_API=3 etcdctl \
  --endpoints=10.0.1.6:2379,10.0.1.7:2379,10.0.1.8:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  endpoint health -w table

找到 leader 节点，换盘先从 follower 节点开始

2. 更换第一个 etcd 节点的磁盘（以 etcd-node1 为例）

  • 步骤 2.1：停止 etcd 服务，备份 etcd 目录数据

    mv /etc/kubernetes/manifests/etcd.yaml /etc/kubernetes/
# 检查 etcd 进程是否已经退出
ps -ef | grep etcd 
kubectl get po -n kube-system | grep etcd
# 备份 etcd 目录数据
cp -rp {etcd 数据目录} {备份目录}

  • 步骤 2.2：更换物理磁盘

  1. 卸载旧磁盘（如 umount -l dev/sdb）。

  2. 安装新磁盘并格式化（例如 mkfs.xfs /dev/sdc）。

  3. 挂载到原目录（如 /var/lib/etcd）：

    # 可将新盘做成lvm挂载，方便后续的运维和扩容等
pvcreate /dev/sdc
vgcreate vg_etcd /dev/sdc
lvcreate -l +100%FREE -n lv_etcd vg_etcd
mkfs.xfs /dev/vg_etcd/lv_etcd
# 配置挂载信息，防止机器重启后丢失
echo "/dev/vg_etcd/lv_etcd /var/lib/etcd xfs defaults 0 0" >> /etc/fstab 
mount -a

  • 步骤 2.3：恢复数据（可选）

    通常新节点会从集群同步数据，但若需快速恢复，可从备份还原：

    cp -r {备份目录}  {etcd 新盘挂载的数据目录}

  • 步骤 2.4：重启 etcd 服务

    mv /etc/kubernetes/etcd.yaml /etc/kubernetes/manifests/
# 确认etcd启动
kubectl get po -n kube-system | grep etcd

  • 步骤 2.5：验证节点恢复

    ETCDCTL_API=3 etcdctl \
  --endpoints=10.0.1.6:2379,10.0.1.7:2379,10.0.1.8:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  endpoint status -w table

ETCDCTL_API=3 etcdctl \
  --endpoints=10.0.1.6:2379,10.0.1.7:2379,10.0.1.8:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  endpoint health -w table

watch "etcdctl member list"  # 观察节点状态变为 started

    • 3. 重复操作其他节点

    • 按相同流程操作 etcd-node2 → etcd-node3。

    • 每次间隔至少 10 分钟，确保集群完全稳定，中间间隔可做集群验证。

    4. 最终验证

    • 集群状态：

      ETCDCTL_API=3 etcdctl \
  --endpoints=10.0.1.6:2379,10.0.1.7:2379,10.0.1.8:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  endpoint status --cluster -w table

    • Kubernetes 功能测试：

      kubectl get nodes --v=7
kubectl create deployment test --image=nginx && kubectl delete deployment test

    关键注意事项

    1. 磁盘挂载配置：

    • 更新 /etc/fstab 确保重启后自动挂载：

      echo "/dev/sdc /var/lib/etcd xfs defaults 0 0" >> /etc/fstab

    • 使用 lsblk 确认磁盘路径。

  • etcd 参数检查：

    • 确保 etcd.yaml 中的 data-dir 指向新磁盘路径（如 /var/lib/etcd）。

    • 如果选择分离 snapshot/wal 以达到提升性能的目的, 需在启动前，需修改 etcd.yaml文件，增加 wal-dir 配置：

    --data-dir=/var/lib/etcd/data
--wal-dir=/var/lib/etcd/wal

    • 验证证书路径和参数正确。

  • 灾难恢复预案：

    • 若操作中集群崩溃（如意外停机两个节点）：

      • 从备份恢复整个集群：etcdutl snapshot restore ...

      • 重置 Kubernetes 控制平面组件。

  • 性能优化建议：

    • 使用 SSD 磁盘（etcd 对 I/O 延迟敏感）。

    • 分离 etcd 数据目录与操作系统磁盘。

    • 调整 etcd 的 --quota-backend-bytes 限制磁盘用量（默认 2GB）。

    • 如果选择分离 snapshot/wal 以达到提升性能的目的，可以使用使用两块新盘挂载到不同的目录，如 /var/lib/etcd/data 与 /var/lib/etcd/wal 。

    常见问题处理

    • 节点无法加入集群：

      • 检查网络防火墙（端口 2379/2380）。

      • 确保证书未过期且 CN/SAN 匹配。

      • 查看 etcd 日志：journalctl -u etcd 或 kubectl logs -n kube-system etcd-node1

    • 数据不一致：

      • 使用 etcdctl check perf 测试性能。

      • 若数据损坏，从备份恢复受影响节点。


    参考：


    高效沟通(一)：Talk和Code同等重要

    2025-07-02 23:10:29

    Talk is cheap，show me the code，是我们技术人常说的一句话，也是技术社区中经常用的一句话。这句话的意思是，那些光说不练的人说一句是很简单的，而写代码的人则会为一句话付出很多很多的精力，其表明，一个看上去再简单的东西，用一行一行的代码实现起来，并能让其运转起来也是一件很复杂很辛苦的事。说得容易，做起来难！

    这句话是 Linus 说的，也是我引入到中文社区的，然而，逐渐地，大众对这句话的解读开始有点变味了，走向了另外一个极端——他们觉得代码才是最重要的，甚至其中有些人开始觉得真正的技术人员是只用代码说话的！

    似乎，这个世界上总是会有一些人，当他们看到一个观点的时候，在他们的脑袋里只有两个答案，一个是 true，如果不是 true，那就是 false。就好像只要一个人犯了个错误，这个人就是一个不折不扣的大坏蛋，如果一个人是个好人，那他要在所有的地方都是优秀完美的。

    对于技术人员来说，其实，Talk 和 Code 是同样重要的， Talk 是人对人说的话，而 Code 也不仅仅只是人对机器说的话，也更是另外一种人对人说的话（因为 Code 需要易读和易维护，就需要让人读懂）。可见，无论是 Code 还是 Talk 其实都是要和人交流的，Code 是间接交流，Talk 则是直接交流。在公司中工作，需要了解公司的意图，与团队一起做项目，调研客户的需求，设计出用户易操作的界面……你会慢慢地发现，其实，Talk 并不 cheap，而 Code 才是其中比较 cheap 的（注：这是站在了另外一个角度）。

    一个好的程序员，需要有好的学习能力，这样你才能成为技术专家，但是，你还要有好的沟通能力，不然，你的技术能力完全发挥不出来。就像一棵大树一样，学习能力能让你的根越扎越深，无论遇到什么狂风暴雨，你都可以屹立不倒，而沟通能力则是树杆和枝叶，它们能让你伸展到更高更远的天空。

    所以，与人沟通是一项非常重要的软技能，我们应该刻意训练和培养自己这方面的能力。今天我们就来聊聊“技术人如何高效沟通”这一话题。我会分享很多我的工作经验，以及我这么多年来积累和总结的一些沟通技巧。它们在我的工作和生活中都起到了至关重要的作用，希望同样能给你一些启发。

    我特别想对技术人员强调一下我的观点：有效的沟通是事业成功的必要条件。不管你的目标是成为一名卓越的管理者，还是成为某个领域的技术牛人，你都应该提高自己的沟通能力。

    沟通的原理和问题

    想要获得高效的沟通，我们首先需要知道，什么是沟通以及其背后的原理。简单来说，沟通是指运用语言、文字或一些特定的非语言行为（面部表情、肢体动作等），把自己的想法、要求、信息等内容传递给对方。而沟通的原理跟计算机之间的通信有些类似。我在大脑里面将要表达的内容根据通信协议（比如中文）进行编码，发送出来，你接收到中文信息，但它表达的是什么意思呢？这时就需要去解码。

    然而，我们日常生活中经常出现的一种情况是，我这句话是这个意思，但却被对方理解为其他意思，即“说者无心，听者有意”。究其原因，其实是因为我们每个人的编码器和解码器完全不匹配造成的，这也是沟通中经常出现的问题。

    img

    那我们该怎样解决这个问题呢？我们来想象一下，在计算机世界中，遇到这个问题都是怎样解决呢？也就是出现编码器和解码器不一样的情况，怎么办？我们通常可以通过一些约定来解决这个问题。对应到沟通这个场景下，“约定”仍然是个好办法。我在一些国外公司工作过，基本上入职之后的第一件事都是，被告知公司里面有很多术语，在描述对应的事物时要用统一的术语。就好像江湖中的黑话一样，这就是我们的通讯协议的标准化，这样可以简化很多沟通的成本。

    此外，反馈也是个很好的方式，你把你理解的东西说给我听。如果有偏差，我再给你解释一下，直到双方达成共识。这就好像 TCP 协议一样，为了保证对方收到了，就需要接收方发出确认包。因为发送方和接收方的解码器不一样，所以，接收方把其解码的信息再编码后传回来，发送方这边再解码看看是不是同样的数据，于是就可以保证编码器和解码器中的信息是一致的了。这又叫“双工通信”（你看，我开始用到术语了，文科生听不懂了，嘿嘿），不要小看“双工”这事儿，它是有效沟通的前提。反之，则会有鸡同鸭讲、对牛弹琴的意味了。

    当然，就算是我们统一术语并且有反馈机制，人与人的沟通依然还是有很多的问题。最大的一个问题就是，我们的成长背景不一样，经历不一样，知识储备不一样，所以对相同事物的理解难免会存在一定的偏差。

    日常沟通可能还好一点，但涉及到一些专业领域中术语的表达，沟通不畅的问题会变得更为严重。比如，我在讲一些计算机术语，而那些没有计算机方面知识储备的人，是完全听不懂的。即便他能听懂我说的每一个字，但还是理解不了我在说什么。所以，这个世界上有一些“教 6 岁孩子学习 XXX”的文章，这种方式其实就是想把一些高级的知识通过低级知识来表达出来，以便可以让小孩子都能听懂，也就是所谓的科普。相信我，如果你能做到这点，你一定是这个行业的专家级人物了。

    就像那本相当经典的图书《从一到无穷大》，其实它在讲的是高阶物理知识，其中有非常难以理解的爱因斯坦相对论，然而这本书却被作者写成了中学生都可以读懂的科普书。能把深奥的物理知识写得这么通俗易懂，只有真正的专家才可以做到。这本书的作者是：乔治·伽莫夫（George Gamow）美籍俄裔物理学家、宇宙学家、科普作家，热大爆炸宇宙学模型的创立者，也是最早提出遗传密码模型的人。

    信息在传递中的损失也不容忽视。相信很多人都玩过一个类似“传话”的游戏：一个人将一句话偷偷说给站在队首的人听，然后他把自己听到的内容传给第二个人，依次传下去，直到队尾。最后由队尾的人大声说出听到的内容。很多时候这个最终的结果都会令人哭笑不得，因为在传递的过程中，最初的信息已经完全变了样子。

    因为，每一次信息的传递都是由不同的编码器和解码器完成的，而传递信息所使用的协议（人类的语言）是很难准确地携带所有的信息的，所以每一次编码和解码都会有信息的丢失和失真。还有一些人会在其中有意无意地“加油添醋”，甚至加入“谣言”，导致整个信息传递过程被黑！

    与之对应的，如果一个公司层级越深，那么执行力一定越差。为什么呢？因为老大的“旨意”一层一层往下传递，传到最下面其实信息早就变了样儿。基本的模式都是，我听我的领导讲了，自己理解了一下，然后对下面的人讲。经常会出现这样的情况，最高层老板讲，我要的是这个，但最终员工交付的却是另外一个东西。信息传递的渠道越多，损失也会越大。所以，会有下面这张经典的图。

    img

    另一方面，在职场里，出于各种各样的原因，有些领导不想直接把自己上级的话对自己下属去讲。一方面，要把其变成下属能理解的语言去讲，他们觉得这样会更有效率，下属不用管公司或是别人要什么，只管好自己要干什么就好。

    而另一方面也有政治上的原因，他们把一些信息阻断了，甚至修改了，以此来达到控制别人的目的。通常来说，只要有等级存在，职场中的管理层就会对上粉过饰非，对下盘剥利诱，这就是职场的生存法则，尤其是大公司更是这样。所以，公司大了后，如果管理跟不上，听之任之，上层和下层脱节基本上来说是必然的。

    对我而言，不管以前做公司管理层，还是现在经营自己的公司，我一直都秉承的原则是，将信息源头的信息原模原样分享出去，而不是我“嚼过的”。因为，我认为后者的信息损失会非常大，而且产生的不良后果也会很大。真正的团队管理，不应该屏蔽信息，信息应该是公开透明的，因为我相信团队成熟到可以面对各种信息，并且是可以一起找解一起找出路的。

    小结

    总结一下今天的内容。在文章伊始我先强调了我的观点，Talk 和 code 同样重要，有效的沟通是你事业成功的必要条件。随后介绍了何为沟通及其背后的原理。我认为，沟通原理跟计算机世界中的通信原理有些类似。由于编码器和解码器的不同，会造成理解的偏差。这个问题可以通过约定和反馈来解决，也就是要先达成共识，然后基于共识来进行沟通。最后我阐述了一些沟通问题，以及应对这些问题的方法。

    来源：《左耳听风专栏：高效沟通》

    kube-proxy iptables 和 ipvs 模式的工作原理及示例

    2025-06-26 01:05:28

    客户有个好几年前的k8s老环境，部署新的应用就出问题了，从部署的服务pod里访问k8s svc地址端口 172.16.0.1:443 不通，宿主机上访问都是通的，kube-proxy mode是 iptables 模式，endpoints检察都正常，svc 后端apiserver 6443 也都能正常访问，重建kube-proxy、kubernetes svc 后 pod 访问 svc 依然不通，最后定位到是客户环境问题，pod网络是自定义网络走了客户自己的网关，数据包被路由到网关并未进入本地处理流程，mark一下。

    kube-proxy iptables 模式的工作原理：

    1743671376637274.png

    kube-proxy是Kubernetes中的一个核心组件，负责维护节点上的网络规则，使得Pod之间的通信和从集群外部到服务的请求能够正确路由。在iptables模式下，kube-proxy并不直接处理流量，而是通过配置iptables规则来将流量导向正确的后端Pod。当一个Service被创建时，kube-proxy会为该Service配置iptables规则。这些规则的作用是将目标为Service的Cluster IP和端口的流量，重定向到后端Pod的IP和端口。负载均衡是通过iptables的随机概率算法实现的，每个后端Pod会被分配一定的权重，流量会按权重随机分发。

    在 iptables 模式下，kube-proxy 通过动态管理 iptables 规则来实现流量转发。以下是具体的工作流程：

    （1）监听 Kubernetes API Server

    • kube-proxy 会监听 Kubernetes API Server，实时获取 Service 和 Endpoint（Pod）的变化。

    • 当 Service 或 Pod 发生变化时（如创建、删除或更新），kube-proxy 会更新本地的 iptables 规则。

    （2）创建 iptables 规则

    kube-proxy 会根据 Service 和 Endpoint 的信息，在 nat 表中创建以下链和规则：

    • KUBE-SERVICES 链：

      • 这是所有 Service 流量的入口链。

      • 当流量进入节点时，kube-proxy 会将流量导向 KUBE-SERVICES 链。

      • 在 KUBE-SERVICES 链中，会根据目标 IP（ClusterIP）和端口将流量转发到对应的 Service 链。

    • KUBE-SVC-<hash> 链：

      • 每个 Service 都会有一个对应的 KUBE-SVC-<hash> 链，<hash> 是 Service 的唯一标识。

      • 这个链负责将流量负载均衡到后端的 Pod。

    • KUBE-SEP-<hash> 链：

      • 每个 Pod（Endpoint）都会有一个对应的 KUBE-SEP-<hash> 链，<hash> 是 Pod 的唯一标识。

      • 这个链负责将流量转发到具体的 Pod IP 和端口。

    （3）流量转发流程

    以下是流量从 Service IP 到 Pod IP 的转发流程：

    1. 流量进入节点的 PREROUTING 链。

    2. PREROUTING 链将流量转发到 KUBE-SERVICES 链。

    3. 在 KUBE-SERVICES 链中，根据目标 IP 和端口匹配到对应的 KUBE-SVC-<hash> 链。

    4. 在 KUBE-SVC-<hash> 链中，根据负载均衡算法（如随机或轮询）将流量转发到某个 KUBE-SEP-<hash> 链。

    5. 在 KUBE-SEP-<hash> 链中，流量被 DNAT（目标地址转换）到具体的 Pod IP 和端口。

    6. 流量最终被转发到目标 Pod。

    iptables 规则的示例

    以下是一个简单的 iptables 规则示例，展示了 kube-proxy 如何将流量从 Service IP 转发到 Pod IP：

    # PREROUTING 主要处理从外部引入的流量和来自 Pod 容器网络的引入流量，OUTPUT 主要处理流出到外部网络的流量和流出到 Pod 容器网络的流量。
因为发布的服务需要对外暴露服务，所以 Kubernetes 创建了一个自定义规则链 KUBE-SERVICE 来支持集群级别的服务发现，即 ClusterIP 和 LoadBalancer 类型，最后通过另外一条自定义规则链 KUBE-NODEPORTS 来对外暴露服务
-A PREROUTING -m comment --comment "kubernetes service portals" -j KUBE-SERVICES
-A OUTPUT -m comment --comment "kubernetes service portals" -j KUBE-SERVICES
-A KUBE-SERVICES -m comment --comment "kubernetes service nodeports; NOTE: this must be the last rule in this chain" -m addrtype --dst-type LOCAL -j KUBE-NODEPORTS

# 将目标为 ClusterIP:443 的流量转发到 KUBE-SVC-XXX 链
-A KUBE-SERVICES -d 172.16.0.1/32 -p tcp -m comment --comment "default/kubernets:https cluster IP" -m tcp --dport 443 -j KUBE-SVC-XXX

# 后端 Pod 的 DNAT 规则（概率负载均衡）
-A KUBE-SVC-XXX -m statistic --mode random --probability 0.333 -j KUBE-SEP-AAA
-A KUBE-SVC-XXX -m statistic --mode random --probability 0.500 -j KUBE-SEP-BBB
-A KUBE-SVC-XXX -j KUBE-SEP-CCC

# KUBE-SEP-AAA 链（Pod 1 链）
-A KUBE-SEP-AAA -s 10.244.1.11/32 -j KUBE-MARK-MASQ
-A KUBE-SEP-AAA -p tcp -m tcp -j DNAT --to-destination 10.244.1.11:6443

# KUBE-SEP-BBB 链（Pod 2 链）
-A KUBE-SEP-BBB -s 10.244.1.12/32 -j KUBE-MARK-MASQ
-A KUBE-SEP-BBB -p tcp -m tcp -j DNAT --to-destination 10.244.1.12:6443

# KUBE-SEP-CCC 链（Pod 3 链）
-A KUBE-SEP-CCC -s 10.244.1.13/32 -j KUBE-MARK-MASQ
-A KUBE-SEP-CCC -p tcp -m tcp -j DNAT --to-destination 10.244.1.13:6443

    • KUBE-SVC-XXX 链将流量随机转发到三个 Pod 链（KUBE-SEP-AAA、KUBE-SEP-BBB 和 KUBE-SEP-CCC）。

    • KUBE-SEP-AAA、KUBE-SEP-BBB 和 KUBE-SEP-CCC 链分别将流量 DNAT 到具体的 Pod IP 和端口。

    iptables 模式的优缺点

    优点：

    • 简单可靠：iptables 是 Linux 内核的标准功能，兼容性较好。

    • 无需额外依赖：不需要安装额外的内核模块或工具。

    缺点：

    • 性能问题：当 Service 和 Pod 数量较多时，iptables 规则会变得非常复杂，导致性能下降。

    • 规则更新延迟：iptables 规则的更新是线性的，当规则数量较多时，更新速度较慢。

    • 负载均衡能力有限：iptables 只支持简单的负载均衡算法（如随机或轮询）。


    kube-proxy IPVS 模式的工作原理

    1743673467830600.png

    在 Kubernetes 中，kube-proxy 的 IPVS 模式（IP Virtual Server）是一种基于 Linux 内核的高性能负载均衡机制，用于替代传统的 iptables 模式。IPVS 模式通过内核级负载均衡技术，显著提升了服务流量转发的效率和可扩展性，特别适合大规模集群场景。与 iptables 模式相比，IPVS 模式的优势在于：

    • 更低的延迟：基于哈希表的规则匹配，而非线性遍历规则链。

    • 更高的吞吐量：支持多种负载均衡算法（如轮询、加权轮询、最少连接等）。

    • 更好的扩展性：规则更新和查询效率更高，适合管理数千个 Service 和 Endpoint。

    （1）监听 Kubernetes API Server

    • kube-proxy 持续监听 Kubernetes API Server，实时获取 Service、Endpoint 和 Node 的变化。

    • 当 Service 或 Pod 发生变化（如扩缩容、更新）时，kube-proxy 会动态调整 IPVS 规则。

    （2）创建虚拟服务（Virtual Service）

    IPVS 通过以下方式将 Kubernetes Service 映射到内核中的虚拟服务：

    • Service ClusterIP：为每个 Service 的 ClusterIP 和端口创建虚拟服务（Virtual IP，VIP）。

    • Service 类型：支持 ClusterIP、NodePort、LoadBalancer 和 ExternalIP 类型的 Service。

    （3）绑定后端 Pod（Real Server）

    每个虚拟服务（VIP）会绑定到多个后端 Pod（称为 Real Server，RS）：

    • 后端 Pod 的 IP 和端口会被注册为虚拟服务的 Real Server。

    • IPVS 根据负载均衡算法（如 rr 轮询、lc 最少连接）将流量分发到后端 Pod。

    （4）流量转发流程

    以下是流量从 Service 到 Pod 的完整流程：

    1. 流量进入节点：无论是通过 ClusterIP、NodePort 还是外部 IP，流量首先到达节点。

    2. IPVS 拦截流量：内核的 IPVS 模块根据目标 IP 和端口匹配到虚拟服务（VIP）。

    3. 负载均衡决策：IPVS 根据预设的算法选择一个后端 Pod（Real Server）。

    4. DNAT（目标地址转换）：将流量目标地址从 Service IP 转换为 Pod IP。

    5. 流量转发到 Pod：转换后的流量被发送到 Pod 所在的节点（可能经过 CNI 插件跨节点转发）。

    6. 返回流量处理：返回流量通过反向路径回到客户端，通常需要 SNAT 确保源地址正确。

    IPVS 规则示例

    通过 ipvsadm 命令可以查看 IPVS 规则：

    # 创建虚拟服务
ipvsadm -A -t 172.16.0.1:443 -s rr

# 配置 IP 组绑定到虚拟服务 IP 上
ipvsadm -a -t 172.16.0.1:443 -r 10.244.1.11:6443 -m
ipvsadm -a -t 172.16.0.1:443 -r 10.244.1.12:6443 -m
ipvsadm -a -t 172.16.0.1:443 -r 10.244.1.13:6443 -m

# 查看所有虚拟服务和后端 Pod
ipvsadm -Ln

# 示例输出：
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  172.16.0.1:443 rr
  -> 10.244.1.11:6443             Masq    1      0          0
  -> 10.244.1.12:6443             Masq    1      0          0
  -> 10.244.1.13:6443             Masq    1      0          0
TCP  172.16.0.10:53 rr
  -> 10.244.1.2:53                Masq    1      0          0
  -> 10.244.1.3:53                Masq    1      0          0

    • 虚拟服务：172.16.0.1:443 对应 Kubernetes 的 API Server Service。

    • 后端 Pod：10.244.1.11:6443、10.244.1.12:6443 和 10.244.1.13:6443 是实际的 API Server Pod。

    • 调度算法：rr 表示轮询（Round Robin）。

    IPVS 负载均衡算法

    IPVS 支持多种负载均衡算法，可通过 kube-proxy 的 --ipvs-scheduler 参数配置：

    算法缩写 全称 描述
    rr Round Robin 轮询分发请求（默认算法）。
    wrr Weighted Round Robin 根据权重轮询。
    lc Least Connection 将新请求分发给当前连接最少的 Pod。
    sh Source Hashing 基于源 IP 的哈希分配，保证同一客户端始终访问同一 Pod。

    IPVS 模式的优缺点

    优点：

    • 高性能：基于内核哈希表，规则匹配效率高，适合大规模集群。

    • 低延迟：避免线性遍历规则链，提升转发速度。

    • 灵活的负载均衡算法：支持多种调度策略。

    • 更少的规则膨胀：规则数量与 Service 数量成线性关系，而非指数关系。

    缺点：

    • 依赖内核模块：需确保 Linux 内核已加载 ip_vs、ip_vs_rr 等模块。

    • 功能局限性：某些高级功能（如 externalTrafficPolicy: Local）仍需依赖 iptables。


    IPVS 与 iptables 的协同

    尽管 IPVS 模式主要依赖内核的 IPVS 模块，kube-proxy 仍依赖少量 iptables 规则完成辅助任务：

    • Masquerading（SNAT）：对某些流量进行源地址转换（如 NodePort 流量）。

    • 过滤特定流量：例如，丢弃无效的包或处理本地回环流量。

    • 兼容性保障：确保某些特殊场景（如 externalTrafficPolicy: Local）的流量正确处理。

    1) ipvs 与iptables 协同示例：

    • iptables：负责流量捕获、SNAT 和辅助过滤。

    • ipvs：专注于高效负载均衡。

    • 协同优势：ipvs 提升性能，iptables 补充关键网络功能，共同实现灵活高效的 Service 流量管理。

    a. 流量捕获

    NodePort 服务：通过 iptables 规则捕获节点端口流量，转发到 ipvs 处理。

    -A KUBE-NODEPORTS -p tcp --dport 30080 -j KUBE-MARK-MASQ
-A KUBE-NODEPORTS -p tcp --dport 30080 -j KUBE-SVC-XXXXXX

      • KUBE-SVC-XXXXXX 链最终指向 ipvs 虚拟服务。

    b. 源地址伪装（MASQUERADE）

    当流量离开节点时，iptables 进行 SNAT（确保返回流量经原节点）：

    -A KUBE-POSTROUTING -m comment --comment "kube-proxy MASQUERADE" -j MASQUERAD

    c. 过滤和兜底规则

    • 健康检查：kube-proxy 通过 iptables 开放健康检查端口（如 10256）。

    • 兜底策略：未命中 ipvs 规则的流量可能由 iptables 处理（如拒绝非法请求）。

    d. 协作流程示例（NodePort 流量）

    1. 入口流量：外部请求到达节点的 NodePort 端口（如 30080）。

    2. iptables 拦截：KUBE-NODEPORTS 链匹配端口，标记并跳转到 KUBE-SVC-XXXXXX。

    3. ipvs 处理：KUBE-SVC-XXXXXX 指向 ipvs 虚拟服务，由 ipvs 按调度算法分发到后端 Pod。

    4. 出站伪装：iptables 的 MASQUERADE 规则修改源 IP，确保响应正确返回。

    2) 模式选择与配置

    • –proxy-mode 参数：当你配置为 --proxy-mode=ipvs，立即激活 IPVS NAT 转发模式，实现 POD 端口的流量负载。

    • –ipvs-scheduler 参数：修改负载均衡策略，默认为 rr——轮询调度。

    • –cleanup-ipvs 参数：启动 IPVS 前清除历史遗留的规则。

    • –ipvs-sync-period 和 –ipvs-min-sync-period 参数：配置定期同步规则的周期，例如 5s，必须大于 0。

    • –ipvs-exclude-cidrs 参数：过滤自建的 IPVS 规则，让你可以保留之前的负载均衡流量。

    • 依赖条件：ipvs 需内核模块支持（如 ip_vs、ip_vs_rr）。

    3)  iptables 模式 与 ipvs 模式 的对比

    以下是 iptables 模式 与 ipvs 模式 的对比表格，总结了它们在 Kubernetes 中管理网络流量的核心差异：

    对比项 iptables 模式 ipvs 模式
    工作方式 基于链式 iptables 规则实现流量转发和负载均衡。 基于内核级 IPVS 虚拟服务（L4）实现高效负载均衡。
    性能 规则链庞大时性能显著下降（时间复杂度 O(n)）。 高性能，时间复杂度 O(1)，适合大规模集群。
    负载均衡算法 仅支持随机概率均衡（statistic mode random）。 支持多种算法（如轮询 rr、加权最小连接 wlc、哈希 sh 等）。
    规则管理 每新增一个 Service/Endpoint 需添加多条 iptables 规则，规则复杂度高。 直接管理虚拟服务和后端 Pod，规则更简洁。
    适用场景 小规模集群或对性能要求不高的场景。 大规模集群、高并发或需要复杂负载均衡策略的场景。
    资源消耗 规则数量多时内存和 CPU 占用较高。 资源占用低，规则与后端数量无关。
    配置复杂度 规则链复杂，调试困难（需跟踪多条链）。 配置简单，调试直观（ipvsadm 命令查看虚拟服务）。
    内核依赖 依赖 iptables 和 conntrack 模块。 依赖 ip_vs、ip_vs_rr、ip_vs_wlc 等 IPVS 内核模块。
    SNAT 处理 直接通过 iptables 的 MASQUERADE 规则实现。 需依赖 iptables 的 MASQUERADE 规则辅助实现。
    流量兜底处理 通过 iptables 规则直接拒绝非法流量。 依赖 iptables 补充兜底规则（如拒绝非法请求）。
    健康检查支持 通过 kube-proxy 维护 iptables 规则，间接支持。 由 IPVS 直接管理后端健康状态（需结合 kube-proxy 的 Endpoint 监听）。

    选择建议：

    • 小规模集群/简单场景：优先使用 iptables（默认兼容性更好）。

    • 大规模/高性能场景：选择 ipvs（需内核支持）。

    • 特殊需求：如需高级负载均衡算法（如最小连接数），必须使用 ipvs。

    了解了k8s kube-proxy网络流量管理模式，接下来排查思路就很清晰了：

    排查步骤

    1、检查 Service、Endpoints、kube-proxy等服务是否正常：

    [zkqw]

    # 查看 Service 配置
kubectl describe svc kubernetes -n default
kubectl get svc kubernetes -n default -o yaml

# 查看 Endpoints 配置
kubectl describe endpoints kubernetes -n default
kubectl get endpoints kubernetes -n default -o yaml

# 检查 kube-proxy 日志
kubectl logs -n kube-system <kube-proxy-pod-name>

# 检查网络插件日志
kubectl logs -n kube-system <cni-pod-name>
journalctl -u kubelet | grep -i proxy

# 检查内核日志
dmesg | grep kube-proxy

# 重启 kubelet 和容器运行时
systemctl restart kubelet docker/containerd

    • 确认 Endpoints 指向正确的 apiserver IP 和端口(6443)

    • 确保 kubernetes Service 的端口映射正确(443→6443)

    2、检查是否有防火墙、网络策略等规则限制：

    ### 查看是否有网络策略测试影响

kubectl get networkpolicy --all --all-namespaces


### 检查流量是否被其他 iptables 表/链丢弃

# 查看 filter 表的 INPUT/FORWARD/OUTPUT 链
iptables-save -t filter | grep -E "DROP|REJECT"

# 查看是否有规则丢弃 172.16.0.1 的流量
iptables-save -t filter | grep 172.16.0.1

如果有 DROP/REJECT 规则，临时允许流量：

iptables -I INPUT -d 172.16.0.1 -p tcp --dport 443 -j ACCEPT


### 检查 NAT 规则是否正确跳转

# 确保 KUBE-SERVICES 正确跳转到 KUBE-SVC-...，并最终到 KUBE-SEP-...（API Server 的 Endpoint）。

# 查看 KUBE-SERVICES 链的跳转目标
iptables-save -t nat | grep "KUBE-SVC-.*TCP.*443"

# 查看最终的 KUBE-SEP-... 规则（应指向 API Server 的 IP:6443）
iptables-save -t nat | grep "KUBE-SEP-"


### 检查流量是否被 filter 表丢弃

# 查看 filter 表的 INPUT/FORWARD/OUTPUT 链是否有 DROP/REJECT 规则
iptables-save -t filter | grep -E "DROP|REJECT"

# 检查是否有针对 172.16.0.1:443 的拦截规则
iptables-save -t filter | grep 172.16.0.1

修复方法：临时允许流量（测试用）：

iptables -I INPUT -d 172.16.0.1 -p tcp --dport 443 -j ACCEPT
iptables -I FORWARD -d 172.16.0.1 -p tcp --dport 443 -j ACCEPT

临时修复尝试：强制清理 iptables 规则

# 1. 备份当前 iptables 规则（防止误操作）
iptables-save > /tmp/iptables-backup.rules

# 2. 清理所有 kube-proxy 相关的规则
iptables-save | grep -v KUBE- | iptables-restore

# 3. 重启 kube-proxy
kubectl delete pod -n kube-system -l k8s-app=kube-proxy

    3、检查路由是否正确，使用 tcpdump 抓包：

    ### 检查路由是否正确

# 使用 traceroute 查看流量路径
traceroute -n -T -p 443 172.16.0.1
tracepath -p 443 172.16.0.1

# 测试访问
curl -vk https://172.16.0.1:443
telnet 172.16.0.1 443

# 检查路由表优先级
ip route show table all | grep 172.16.0.1

# 查看目标 IP 的路由
ip route get 172.16.0.1

# 期望输出示例（应走主网卡 eth0）：
# 172.16.0.1 dev eth0 src 10.0.0.1 uid 0

异常情况：

如果显示 dev tun0 或其他虚拟网卡，可能是 VPN 或 CNI 插件干扰。
如果显示 via <网关>，需确保网关能正确转发 Service IP。


###  使用 tcpdump 抓包

# 在节点上抓取 172.16.0.1:443 流量
tcpdump -i bondxxx 172.16.0.1 and port 443 -nnvvv

# 如果无流量，说明数据包未到达节点（被路由或防火墙拦截）。
# 如果有流量但无响应，可能是 NAT 未生效。

    4、跟踪 iptables 规则是否命中，检查 NAT 规则是否正确跳转：

    # 查看规则计数器（观察 pkts 是否增加）
iptables -t nat -L KUBE-SERVICES -n -v

如果 pkts 不增加，说明流量未命中规则，可能是：

流量被其他链（如 FORWARD）丢弃。

路由问题导致流量未进入 KUBE-SERVICES 链。

# 临时添加日志规则（观察流量路径）
iptables -t raw -I PREROUTING -d 172.16.0.1 -p tcp --dport 443 -j TRACE
iptables -t raw -I OUTPUT -d 172.16.0.1 -p tcp --dport 443 -j TRACE

# 查看内核日志
dmesg -T | grep TRACE

    经过以上排查步骤，结果如下：

    1、svc、ep、kube-proxy都正常，且无防火墙和网络测试限制

    2、iptables NAT规则配置都正常，添加iptables日志规则无数据说明数据包未经过 NAT 表，pkts无数据说明也没有命中KUBE-SVC规则，通过以上分析基本可以定位到是路由问题：数据包被路由到其他网卡或未进入本地处理流程。

    3、pod 有到网关的路由规则，抓包返回 reset 包（问题定位）

    image.png

    image.png

    原因分析

    问题本质：Pod 访问 172.16.0.1 时，路由表错误地将流量导向网关 10.240.xxx.xxx，而正确的行为应该是：

    宿主机处理：流量应留在宿主机，由 kube-proxy 的 iptables/IPVS 规则转发到 API Server（6443 端口）。

    测试验证：

    Pod 使用本机网络，设置  hostNetwork：true，访问 172.16.0.1:443 能通

    # 进入一个启用宿主机网络测试 Pod
kubectl run -it --rm testpod --image=busybox --overrides='{"spec": {"hostNetwork": true}}' -- sh

# 验证 Pod 是否使用宿主机网络，预期输出：hostNetwork: true
kubectl get pod my-hostnetwork-pod -o yaml | grep hostNetwork

# 通过 YAML 文件创建（推荐），创建文件 hostnetwork-pod.yaml：
apiVersion: v1
kind: Pod
metadata:
  name: my-hostnetwork-pod
spec:
  hostNetwork: true  # 关键配置
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80  # 容器内端口（实际会绑定到宿主机）

# 应用配置
kubectl apply -f hostnetwork-pod.yaml

# 在 Pod 内测试
wget 172.16.0.1:443 -O - -T 5
telnet 172.16.0.1 443

    注意事项

    1、端口冲突风险

    如果容器内的进程绑定到某个端口（如 80），该端口会直接在宿主机上暴露，可能与其他进程冲突。如果容器需要绑定宿主机特权端口（如 80），需提升权限：

    spec:
  containers:
  - name: nginx
    securityContext:
      privileged: true  # 授予特权模式（谨慎使用）

    2、DNS 解析行为

    使用 hostNetwork: true 时，Pod 默认继承宿主机的 DNS 配置（/etc/resolv.conf），而非 Kubernetes 的 CoreDNS。

    若需使用集群内服务发现，需手动配置 DNS。

    spec:
  dnsPolicy: "None"  # 覆盖默认 DNS 策略
  dnsConfig:
    nameservers:
      - 10.96.0.10  # 替换为集群 CoreDNS 的 ClusterIP
    searches:
      - default.svc.cluster.local
      - svc.cluster.local
      - cluster.local

    3、安全风险

    暴露宿主机网络栈可能带来安全隐患，建议仅用于特定场景（如网络监控工具、测试）。


    参考：

    [/zkqw]

    绝地大逃杀

    2025-06-23 02:33:05

    最近整了两个新手快乐缸，一个养龟，一个养鱼，大多是小孩电玩城里弄的和野采搞的。乌龟缸里现有五只龟，一只虾，一条小鱼。野采放了几十只虾和小鱼都被乌龟给祸害掉了。尤其是这只大点的巴西龟啥都吃，鱼、虾、螺、水草绿植，只要是它想吃的，能吃的感觉它都想给吃咯，还特凶，叫它巴西蛊王不为过。

    1750613949530464.jpg

    1750614005855156.jpg

    这眼神一看就很有杀气！仅剩的这只虾和小鱼在这群恶龟围追堵截下能活下来也真不容易，就叫虾王和小强吧。

    1750614244846880.jpg

    [video dplayer="true" autoplay="false" src="https://cdn.chegva.com/ueditor/php/upload/video/20250623/1750615590338990.mp4" loop="false" preload="true" theme="#b7daff" mutex="true" iconsColor="#ffffff"]

    最近又整了6条国斗，以斗鱼快速的游速和火暴的脾气，乌龟想吃到它们应该没那么容易，结果就出去吃了个饭，小捞网被跳开了，两条斗鱼直接越狱，一条已经梆硬，一条还有一口气，还得打氧抢救，这两条鱼对自己是真狠。还有四条正常鱼，一条半残鱼。

    1750614735348453.jpg

    为了迎接斗鱼，周末把乌龟缸地图重新设计了下，之前的地图像个孤岛，这次有躲避城堡，桥洞，空隙，绿植，就叫它水中乐园，恶龟们想轻松吃肉是没那么容易了。

    1750615152931439.jpg

    1750615185435029.jpg

    最后，看效果还不错，国斗游得挺快，还在里头干架，给恶龟们运动运动锻炼下，又扔了些旁边鱼缸里的田螺宝宝过来，希望鱼龟虾螺最终能实现共生。当然，不管是虾王，小强还是斗鱼们，活到最后的才是真正的赢家。5只恶龟、4.5条斗鱼，1条小鱼，1只虾，绝地大逃杀开始了，快跑吧老六。

    [video dplayer="true" autoplay="false" src="https://cdn.chegva.com/ueditor/php/upload/video/20250623/1750615556361521.mp4" loop="false" preload="true" theme="#b7daff" mutex="true" iconsColor="#ffffff"]

    [video dplayer="true" autoplay="false" src="https://cdn.chegva.com/ueditor/php/upload/video/20250623/1750614301927164.mp4" loop="false" preload="true" theme="#b7daff" mutex="true" iconsColor="#ffffff"]