Arthur Guo 的专栏

在动手建系统之前，先要明确计费是为了"看看"（成本洞察，成本可视化）还是"扣钱"（内部结算，真金白银内部结算）。源 IP: 10.32.45.67, 目的 IP: 151.101.x.x, 字节数: 1.2GB, 时间: 14:23。→ DHCP 日志 → MAC: aa:bb:cc:dd:ee:ff, 租约用户: zhangsan。2024-05, 数字营销部, 互联网出口流量, 1.2GB, 成本分摊: ¥0.8。将计费系统扩展为"全 IT 成本分摊平台"（含云、终端、软件许可），摊薄边际成本。

Pause 容器是 Pod 的“地基”，它创建了共享的命名空间，让多个容器能在同一个“房间”里工作；：日志审计、国密卸载、流量加密、监控埋点，这些辅助功能通过 sidecar 与核心业务解耦，既满足了等保/信创要求，又避免了对核心交易代码的侵入式改造。# 执行 iptables -t nat -A PREROUTING -p tcp -j REDIRECT --to-ports 15001。：如果没有 pause 容器，每个业务容器启动时都会创建独立的 netns，它们之间就无法直接。

Pod A ──► veth ──► cni0 ──► flannel.1(VTEP) ──► VXLAN封装 ──► eth0。──► 底层网络 ──► eth0 ──► VXLAN解封装 ──► flannel.1 ──► cni0 ──► Pod B。──► 底层网络（物理路由器已学习Pod CIDR路由）──► eth0 ──► 路由表 ──► veth ──► Pod B。Pod A ──► veth ──► 路由表(10.244.2.3 via Node2_IP) ──► eth0。

Flannel 的设计哲学是“最小可用”——它只做一件事：为每个节点分配一个 Pod 子网段，并确保跨节点的 Pod IP 可路由。f2:xx:xx:xx:xx:02 → VTEP IP = Node2_Physical_IP (如 192.168.1.12)查 ARP 表：10.244.2.0 → f2:xx:xx:xx:xx:02 (Node2 flannel.1 的 MAC)每个节点上的守护进程，监听 etcd/K8s API 获取集群子网分配，配置本地路由、ARP、FDB、VXLAN 设备。

虽然 1.24+ 默认使用 TokenRequest 投影（短期 Token），但传统 Secret 形式的 SA Token 曾是 Pod 访问 APIServer 的“通行证”。base64 的目的是“让二进制数据安全地穿越 JSON/YAML 文本协议”，而不是“防止人类读取”。银行生产环境中，信封里的内容必须被加密，钥匙必须放在 HSM 里，信封的开启必须被审计。etcd 是集群的“大脑”，一旦攻击者突破 Master 节点或 etcd 节点，所有 Secret 一览无余。

APIServer 的 API 在协议层面就是 HTTP/JSON（或 Protobuf），但在语义层面是"面向终态的、版本化的、事件驱动的、带内置安检链的分布式资源控制系统"。它与普通 HTTP API 的关系，类似于**"SQL 与 Excel 都是表格"**——表面都是行列数据，但底层哲学和适用域完全不同。"requestObject": { ... }, // 请求体（敏感资源可能省略）从协议底层看，它接收的仍然是标准的 HTTP/1.1 或 HTTP/2 请求，但。

lowerdir=/var/lib/containerd/.../layer1:/var/lib/containerd/.../layer2 (镜像层，只读)这个引擎比操作系统轻量得多——启动一个容器不是"开机"，而是**"执行一个系统调用序列，让普通进程换一套视图继续跑"**，耗时以毫秒计。它更像是一个**"借用宿主机内核，为单个应用进程快速搭建隔离环境"的启动器**。—— 这里对方可能会误以为容器里有完整操作系统，需要补一句："但它没有自己的内核，用的是宿主机的内核，只是被隔离了。

定位是服务发现 + KV，Raft 实现正确但 KV 层是附加功能，Watch 机制（Blocking Queries）基于索引但不如 etcd 的 revision 模型精确，且非 K8S 原生集成。：Controller 需要可靠的事件流。分布式 KV（TiDB 底层），强一致但架构重（PD + TiKV 多节点），延迟高于 etcd，且设计目标是海量数据存储而非 K8S 的"小数据 + 高并发 Watch"。：集群状态是 K8S 的"黄金数据"，丢失 etcd 数据等于丢失整个集群的"大脑"。

插件会持续 watch Kubernetes API 中的 Service 和 Endpoints/EndpointSlice 对象。如果 Headless Service 与 StatefulSet 配合，CoreDNS 还会为每个 Pod 创建一个唯一的、稳定的 DNS 子域名，例如。CoreDNS 与 Headless Service 的协作是服务发现的核心。对象正是连接逻辑服务与物理实例的桥梁，也是 Headless Service 的。的角色，提供了一份可直接访问的“Pod 名册”。

以下在技术层面上对 Kubernetes 中的五种 CNI 插件进行深入比较：Flannel、Calico、kube-router、Weave Net 和 Cilium。kube-router DaemonSet 进程。依赖 kube-proxy。依赖 kube-proxy。✅ (eBPF 替代)高性能路由，强大策略。

eBPF已经不仅仅是一个内核技术，而是一个蓬勃发展的生态系统，涵盖了各种工具、库和项目，为可观测性、网络、安全等领域提供了强大的支持。eBPF已经成为构建现代可观测性解决方案的关键技术，为可观测性带来了更广阔的前景。

bpftrace是基于eBPF（extended Berkeley Packet Filter）技术的高级跟踪工具。eBPF是Linux内核中的一个虚拟机，允许用户在内核空间安全、高效地运行自定义的程序（称为eBPF程序）。bpftrace可以作为APM、安全监控、系统诊断等工具的核心组件，实现工程化应用。

eBPF 是一种更底层、更通用、更安全的技术，可以用于实现更广泛的可观测性场景，包括 Jaeger/Zipkin 所关注的分布式追踪。

Kubernetes（K8S）网络模型与传统网络有一些相似之处，但也有其独特的设计和实现方式。以下是对 Kubernetes 网络的详细技术解析，旨在帮助熟悉传统网络的人理解其工作原理。

Kubernetes（K8S）网络模型与传统网络有一些相似之处，但也有其独特的设计和实现方式。以下是对 Kubernetes 网络的详细技术解析，旨在帮助熟悉传统网络的人理解其工作原理。

1.2 Kustomize: 不使用模板化，使用 kustomization.yaml 文件定义资源、变更和生成器，通过覆盖和组合 YAML 文件来管理配置。它通过 Helm Charts 来定义应用程序的结构和配置，允许使用 Go 模板语言来动态生成配置文件，允许在模板中使用变量和条件逻辑。2.1 Helm: 是一个完整的包管理工具，支持版本控制、依赖管理和发布管理。3.2 Kustomize: 适合用于需要简单配置管理和定制化的场景，特别是当你希望保持原始 YAML 文件的可读性和可维护性时。

流量回放”通常指的是将之前记录的网络请求和响应数据重新发送到系统中，以模拟真实用户的操作。这种技术主要用于测试和调试目的，帮助开发人员和测试人员更好地理解系统在特定条件下的行为。

Real User Monitoring (RUM) 主要功能和目的，实现技术，应用场景。

日志存储策略、常用技术和常见工具

开源SDN系统Tungsten Fabric面临数据产生过多问题。至少有两个办法可以解决。

Linux环境，当python -m ensure pip --upgrade无效时候怎么安装pip

常用redis配置

使用Nginx-vtx-exporter在Prometheus里监控Nginx，网上多数文章都用的编译源码方式部署。本文采用容器方式在K8S环境里部署。

RedisSearch简介

大运维平台常常需要展示系统健康度，究竟健康度要从哪些方面提取数据？本文浅析。