只放行允许的流量进来；挡住不明来历、恶意攻击的访问；控制哪些程序、哪些端口能联网；防止别人随便扫描、入侵你的电脑；保护服务器不被乱访问、乱攻击firewalld是防火墙管理器，它把网络分成了不同的 “安全区域”，每个区域都有自己的一套放行 / 拒绝规则，不同区域的安全等级不一样，流量进来时，会根据源 IP或网络接口匹配到对应的区域，再按规则处理。数据包进来时，firewalld 会按这个顺序找规则

用户可以从registry下载或拉取这些容器 image 到本地系统，以便运行容器。容器镜像是创建容器的只读模板 / 蓝图；镜像是不可修改的，容器是从镜像跑出来的实例。用户级：~/.config/containers/registries.conf。必须先删除依赖该镜像的容器，再执行：podman rmi 镜像名或ID。）占用资源更少：内存 / 存储只需要 MB 级，虚拟机是 GB 级。无根容器：

就像一个公司：控制平面是总部的管理层，工作节点是前线的业务部门，两者通过严格的协作流程运转。这个核心进行交互，它是整个集群的唯一入口，所有操作（不管是人还是程序）都必须先通过它。工作节点是真正跑你业务的地方，每个节点都有三个关键组件，它们都要和控制平面的。1. 提供 RESTful API，供用户、其他组件调用。1. 监听 apiserver 上未被调度的 Pod。1. 调用云厂商 API 创建负

1. Pod是“容器组+共享资源”的集合，不是单个容器，最小调度单元；2. Pause容器是Pod的灵魂，负责打底（网络、存储），永不退出；3. 所有应用容器共享网络和存储，同生共死，高效协作；4. 元数据层用于标识Pod，是K8s管理Pod的核心依据。结合示意图来看，Pod的内部结构逻辑清晰：元数据标识身份，Pause容器搭建基础，应用容器负责业务，共享资源层实现协作，缺一不可。理解了这个结构，

很多刚接触 K8s 的同学，都会被 “Pod 生命周期” 这个概念绕晕：当我们敲下后，一个 Pod 是如何从 “一段 YAML 配置” 变成集群里真正运行的服务的？这篇文章就结合官方流程，用一张图 + 分步拆解，带你把 Pod 从创建到运行的完整过程讲透，帮你彻底理解 K8s 核心组件的协同工作逻辑。API Server 是唯一入口：所有组件不直接通信，全部通过 API Server 中转，保证集

数据库高可用是后端架构的核心能力，主从复制作为最基础的高可用方案，广泛应用于生产环境。本文基于虚拟机集群主从复制与Docker 容器化主从复制两套对比实验，从原理、实践到架构差异，分享对 MySQL 主从复制及容器化部署的深度思考。技术方案无优劣，适配业务场景才是关键。传统虚拟机稳定性强，适合核心数据库部署；Docker 容器化轻量化、易扩展，适合微服务架构下的数据库集群。主从复制作为高可用基石，

最近在学习 K8s Pod 基础操作时，我遇到了一个90% 新手都会混淆的致命误区修改本地 YAML 文件中 Pod 的name字段，再次执行到底是更新原 Pod 还是新建 Pod？为什么最后只能删掉新 Pod，旧 Pod 还残留？今天通过亲手实验，彻底搞懂的底层逻辑，记录学习心得。改配置不改 name → apply 更新资源改配置同时改 name → apply 新建资源K8s 资源唯一标识是

在K8s学习过程中，很多新手只会简单使用，但完全不懂底层逻辑：为什么Deployment更新后，旧ReplicaSet不会被删除？回滚时Pod名称和旧版本一模一样，是Pod复活了吗？是巧合吗？明明ReplicaSet可以管理Pod，生产为什么只用Deployment，不用ReplicaSet？本文结合本人真实实操踩坑全过程，彻底讲透Deployment更新、滚动升级、版本回滚的底层原理，同时厘清生

NodePort和LoadBalancer的核心差异，本质是「临时使用」和「正式上线」的区别——NodePort胜在简单、无需额外组件，适合快速验证业务；LoadBalancer胜在稳定、安全、功能完善，适合生产环境规模化使用（私有集群需依赖MetalLB完成IP分配和对外广播）。另外记住两个关键细节：1. NodePort访问可跨节点转发，不受访问节点限制，只看Pod标签是否匹配；2. Load

通过本次3节点实战实验，我们不仅亲手验证了LoadBalancer的Pod负载均衡效果，还掌握了MetalLB的部署与配置，整理成面试背诵版，方便大家记忆：MetalLB是裸机K8s集群实现LoadBalancer功能的必备组件，核心负责IP分配和对外广播；LoadBalancer Service的核心是“均匀分配流量到后端Pod”，与节点无关，这是其核心作用；MetalLB L2模式仅实现Pod