Kubernetes 网络深度解析：从入门到实战

November 3, 2025

字数: 8371 · 阅读: 40 分钟 · 访问: -

从零开始理解 K8s 网络模型，深入 Flannel 和 Calico 原理，掌握网络故障排查与解决方案目录 Kubernetes 网络基础 Pod 间通信原理 Service 与 DNAT 机制 Flannel 网络方案详解 Calico 网络方案详解网络故障排查实战复杂场景解决方案 1. Kubernetes 网络基础 1.1 K8s 网络模型的三大原则 Kubernetes 采用扁平网络模型（Flat Network Model），核心原则： ✅ 原则 1：所有 Pod 可以在不使用 NAT 的情况下与其他 Pod 通信 ✅ 原则 2：所有节点可以在不使用 NAT 的情况下与所有 Pod 通信 ✅ 原则 3：Pod 看到的自己的 IP 和其他 Pod 看到的 IP 是同一个这意味着： Pod 之间是"直连"的（IP 层面）没有复杂的 NAT 转换网络拓扑清晰简单 1.2 网络组件架构 ┌─────────────────────────────────────────────────────┐ │ Application │ │ (你的应用) │ └──────────────────┬──────────────────────────────────┘ │ ┌──────────────────▼──────────────────────────────────┐ │ Service (ClusterIP) │ │ 虚拟 IP + 负载均衡 (kube-proxy) │ └──────────────────┬──────────────────────────────────┘ │ ┌──────────────────▼──────────────────────────────────┐ │ Pod Network (CNI) │ │ Flannel / Calico / Cilium 等 │ └──────────────────┬──────────────────────────────────┘ │ ┌──────────────────▼──────────────────────────────────┐ │ Node Network │ │ 物理网络 / 云厂商 VPC │ └─────────────────────────────────────────────────────┘ 1.

OpenYurt 完整使用手册 - 从入门到实践

October 29, 2025

字数: 1743 · 阅读: 9 分钟 · 访问: -

目录什么是 OpenYurt 核心概念与架构环境准备快速开始集群部署详解边缘节点管理边缘应用部署进阶特性运维与监控故障排查最佳实践什么是 OpenYurt 简介 OpenYurt 是阿里云开源的边缘计算平台，基于原生 Kubernetes 构建，专门为边缘计算场景设计。它将 Kubernetes 的能力无缝延伸到边缘端，使云端和边缘能够协同工作。核心优势非侵入式：无需修改 Kubernetes 核心代码云边协同：支持云端统一管理边缘资源边缘自治：网络断连时边缘节点可独立运行原生兼容：完全兼容 Kubernetes API 和生态轻量化：针对边缘资源受限场景优化适用场景物联网 (IoT)：设备管理、数据采集 CDN 边缘节点：内容分发、边缘缓存智慧城市：交通监控、视频分析工业互联网：设备监控、生产管理 5G MEC：边缘计算、低延迟应用核心概念与架构整体架构 ┌─────────────────────────────────────────────────┐ │ Cloud (云端) │ │ ┌──────────────┐ ┌──────────────┐ │ │ │ Kube-APIServer│ │ YurtHub │ │ │ └──────────────┘ │ (云端代理) │ │ │ ┌──────────────┐ └──────────────┘ │ │ │ YurtManager │ ┌──────────────┐ │ │ │ (控制器) │ │ YurtIoTDock │ │ │ └──────────────┘ └──────────────┘ │ └─────────────────────────────────────────────────┘ │ │ 不稳定网络 │ ┌─────────────────────────────────────────────────┐ │ Edge (边缘) │ │ ┌──────────────┐ ┌──────────────┐ │ │ │ YurtHub │ │ Kubelet │ │ │ │ (边缘代理) │ └──────────────┘ │ │ │ (缓存/过滤) │ ┌──────────────┐ │ │ └──────────────┘ │ 容器运行时 │ │ │ └──────────────┘ │ └─────────────────────────────────────────────────┘ 核心组件 1.

Kubernetes 集群 DNS 解析与网络问题排查完整指南

October 28, 2025

字数: 1493 · 阅读: 8 分钟 · 访问: -

文章概述本文记录了一次完整的 Kubernetes 集群网络问题排查过程，从容器内 DNS 解析失败，到发现 RBAC 权限缺失，再到解决跨节点 Pod 网络不通的完整历程。适用于 Kubernetes 1.29 版本，使用 Flannel 作为 CNI 插件。目录问题现象排查思路问题一：kube-proxy RBAC 权限缺失问题二：flannel RBAC 权限缺失问题三：双 Pod CIDR 共存导致路由问题故障总结与预防 DNS 问题排查通用方法论问题现象环境信息 Kubernetes 版本: 1.29 网络插件: Flannel (VXLAN 模式) 集群规模: 5 节点（3 master + 2 GPU worker）故障时间: 已运行 n 天后突然出现初始症状容器内无法进行 DNS 解析和服务访问： # 在容器内测试 $ ping coredns.kube-system ping: bad address 'coredns.kube-system' $ nc -zv coredns.

Redis 参数配置详解与优化指南

October 17, 2025

字数: 2125 · 阅读: 10 分钟 · 访问: -

概述 Redis 作为高性能的内存数据库，其性能表现很大程度上取决于参数配置的合理性。本文将详细介绍 Redis 的核心参数，并针对不同的部署架构（单机、主从、哨兵、集群）提供优化配置建议。一、Redis 核心参数详解 1.1 基础配置参数 bind 说明：指定 Redis 监听的网络接口默认值：127.0.0.1 建议：生产环境建议绑定内网 IP，避免使用 0.0.0.0 bind 192.168.1.100 port 说明：Redis 监听端口默认值：6379 建议：可修改为非默认端口以提高安全性 port 6379 protected-mode 说明：保护模式，防止未授权访问默认值：yes 建议：生产环境必须开启，配合 requirepass 使用 protected-mode yes requirepass 说明：设置访问密码默认值：无建议：生产环境必须设置强密码 requirepass YourStrongPassword@2025 timeout 说明：客户端空闲多少秒后关闭连接，0 表示禁用默认值：0 建议：设置 300 秒，避免僵尸连接 timeout 300 tcp-keepalive 说明：TCP 连接保活时间（秒）默认值：300 建议：保持默认或设置为 60 tcp-keepalive 60 1.2 内存管理参数 maxmemory 说明：Redis 最大内存使用量默认值：0（不限制）建议：设置为物理内存的 60%-70%，留出空间给系统和持久化 maxmemory 4gb maxmemory-policy 说明：内存淘汰策略可选值： noeviction：不淘汰，写入失败（默认） allkeys-lru：对所有 key 使用 LRU 算法淘汰 volatile-lru：对设置了过期时间的 key 使用 LRU 淘汰 allkeys-random：随机淘汰所有 key volatile-random：随机淘汰有过期时间的 key volatile-ttl：淘汰即将过期的 key allkeys-lfu：对所有 key 使用 LFU 算法淘汰 volatile-lfu：对设置了过期时间的 key 使用 LFU 淘汰建议：根据业务场景选择，缓存场景推荐 allkeys-lru maxmemory-policy allkeys-lru maxmemory-samples 说明：LRU/LFU 算法采样数量默认值：5 建议：增加到 10 可提高准确性，但会增加 CPU 开销 maxmemory-samples 10 1.

Redis 集群完全指南：从原理到实战

October 17, 2025

字数: 5698 · 阅读: 27 分钟 · 访问: -

目录为什么需要 Redis 集群 Redis 集群核心概念集群架构深度解析搭建第一个 Redis 集群集群操作命令大全数据分片与路由故障检测与自动恢复集群扩容与缩容性能优化与最佳实践常见问题与故障排查 1. 为什么需要 Redis 集群 1.1 单机 Redis 的局限性问题一：容量瓶颈单机 Redis 内存上限： - 理论上限：512GB（受操作系统限制） - 实际生产：通常 32GB-64GB - 问题：业务数据超过单机容量怎么办？问题二：性能瓶颈单机 QPS 极限： - 读操作：约 10万 QPS - 写操作：约 8万 QPS - 问题：高并发场景无法满足问题三：可用性问题单点故障： - 主机宕机 → 服务完全不可用 - 硬件故障 → 数据可能丢失 - 维护升级 → 必须停机 1.2 Redis 集群的优势特性单机 Redis 主从复制 Redis 集群数据容量受限于单机内存受限于单机内存 ✅ 水平扩展，无限容量读性能约 10万 QPS ✅ 可扩展（主从分离） ✅ 线性扩展写性能约 8万 QPS 受限于主节点 ✅ 线性扩展高可用 ❌ 单点故障 ⚠️ 需要 Sentinel ✅ 自动故障转移数据分片 ❌ 不支持 ❌ 不支持 ✅ 自动分片 2.

GitHub 开源协议完全指南：个人项目如何选择合适的许可证

October 11, 2025

字数: 581 · 阅读: 3 分钟 · 访问: -

1. 引言当你在 GitHub 上创建开源项目时，选择合适的开源协议（License）是至关重要的一步。它不仅定义了他人如何使用你的代码，也保护了你作为作者的权益。本文将详细介绍常见的开源协议及其使用场景，帮助你做出明智的选择。 2. 为什么需要开源协议？没有协议的代码在法律上属于"保留所有权利"，这意味着： ❌ 他人不能合法使用、修改或分发你的代码 ❌ 即使代码公开在 GitHub 上，也不代表可以随意使用 ✅ 添加协议后，明确了使用权限，让你的项目真正"开源" 3. 常见开源协议详解 3.1. MIT License（最宽松、最流行）特点： ✅ 极其简单宽松 ✅ 允许商业使用 ✅ 可以修改、分发、私有使用 ✅ 只需保留版权声明和许可声明限制：无担保声明（使用风险自负）不提供专利授权适合场景：个人项目想要最大化传播希望被广泛采用，包括商业项目不想有太多法律限制知名项目： jQuery, Node.js, React 3.2. Apache License 2.0（企业友好）特点： ✅ 允许商业使用 ✅ 明确的专利授权 ✅ 可以修改、分发 ✅ 必须声明修改内容限制：必须包含 NOTICE 文件不能使用项目商标适合场景：涉及专利的项目希望企业采用的项目需要明确贡献者专利权的场景知名项目： Android, Apache 系列软件, Kubernetes 3.3. GNU GPL v3.

MySQL 监控与告警

September 22, 2025

字数: 1190 · 阅读: 6 分钟 · 访问: -

1. 开启性能模式 2. 部署 mysqld-exporter 2.1. collectors 解读 2.2. 单实例 2.3. 主从实例 3. 告警规则 3.1. MySQL 服务可用性告警 3.2. 主从复制状态告警 3.3. 连接数告警 3.4. InnoDB 缓冲池告警 3.5. 查询性能告警 3.6. 锁等待告警 3.7. 二进制日志告警 3.8. 复制错误告警 4. 部署建议 5. 注意事项 1. 开启性能模式 [mysqld] performance_schema=1 optimizer_search_depth = 0 optimizer_switch = index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on performance_schema 解释： 1 或 ON：启用（推荐） 0 或 OFF：禁用 optimizer_search_depth 解释：控制 MySQL 查询优化器在探索执行计划时的搜索深度默认值：62（表示“自动”）设置为 0：表示“自动深度” 设置为 1-62：限制搜索范围 optimizer_switch 解释： index_merge=on 启用索引合并优化（总开关） ‘index_merge_union=on’ 启用 OR 条件下的索引联合（如 WHERE a=1 OR b=2） ‘index_merge_sort_union=on’ 启用排序后的索引联合（适用于无索引排序的 OR） ‘index_merge_intersection=on’ 启用 AND 条件下的索引交集（如 WHERE a=1 AND b=2，但 a、b 分属不同索引） 2.

MySQL 开启 Binlog 与误删除后的数据库恢复实战

September 22, 2025

字数: 235 · 阅读: 2 分钟 · 访问: -

在日常运维工作中，MySQL 的 binlog（二进制日志）往往是最后一道“后悔药”。很多新手 DBA 或开发者认为单实例不需要 binlog，直到哪一天手滑执行了 DROP DATABASE，才发现： ——没有 binlog，数据只能恢复到最近一次全量备份； ——有了 binlog，我们就能基于时间点恢复（PITR）把数据救回来。这篇文章将从开启 binlog、误删除恢复演练到生产环境最佳实践，带你完整走一遍。一、为什么要开启 binlog？ binlog 的作用主要有三点：数据恢复：结合全量备份，支持时间点恢复（Point-In-Time Recovery，PITR）。主从复制：MySQL 主从架构依赖 binlog。审计与排查：可以追溯数据修改的来源与内容。不开启 binlog，你的恢复手段就只能依赖全量备份，而全量备份通常是 T+1 或每周一次，数据丢失窗口巨大。二、如何开启 binlog 1. 修改 MySQL 配置在 /etc/my.cnf（或 /etc/mysql/my.cnf）中，[mysqld] 段添加： [mysqld] # 开启 binlog log_bin = /var/lib/mysql/mysql-bin # server-id 必须非0（即使单机也要设置） server-id = 1 # binlog 格式：ROW 更安全（记录行级别变化） binlog_format = ROW # binlog 过期清理天数, 5.7 expire_logs_days = 7 # binlog 过期清理天数, 8.

MySQL关键参数优化全面指南：从理论到实践

September 18, 2025

字数: 647 · 阅读: 4 分钟 · 访问: -

mysql

MySQL作为世界上最流行的开源关系型数据库，其性能很大程度上取决于配置参数的合理设置。本文将深入分析MySQL核心配置参数，提供实用的优化公式和不同环境下的配置建议。核心参数详解 1. InnoDB Buffer Pool 配置 innodb_buffer_pool_size - 数据缓存池 InnoDB Buffer Pool是MySQL性能的核心，缓存数据页和索引页，直接影响查询性能。作用机制：缓存热点数据页，减少磁盘I/O 提供MVCC快照读支持管理脏页刷新策略配置公式： -- 专用MySQL服务器 innodb_buffer_pool_size = 总内存 × 0.75 到 0.8 -- 混合用途服务器 innodb_buffer_pool_size = 总内存 × 0.5 到 0.6 -- 容器化环境 innodb_buffer_pool_size = 容器内存 × 0.6 到 0.7 innodb_buffer_pool_instances - 实例分割将Buffer Pool分割成多个实例，减少并发竞争。配置规则： -- 基础公式 instances = min(CPU核心数 / 2, buffer_pool_size_GB) -- 但需满足：buffer_pool_size = chunk_size × instances 的整数倍 -- 默认chunk_size = 128MB 具体建议：

Kubernetes 网络排障手册：从容器网络到服务发现的完整解决方案

September 5, 2025

字数: 1203 · 阅读: 6 分钟 · 访问: -

在 Kubernetes 集群的运维过程中，网络问题是最常见也是最复杂的故障类型之一。本文将基于一个真实的生产环境案例，详细介绍如何系统性地排查和解决 K8s 网络问题，涵盖从基础网络连通性到 DNS 解析的完整故障链条。案例背景在一个运行 Kubernetes 1.29 的生产集群中，我们遇到了以下问题：宿主机网络正常，可以访问外网容器内无法访问外网使用 Flannel 作为 CNI 网络插件后续发现容器无法 ping 通 CoreDNS Service IP 通过深入排查，我们发现了一个有趣的现象：DNS 配置错误不仅影响域名解析，还会导致整个 Service 网络不可达。第一部分：容器外网访问故障排查 1.1 基础网络连通性检查当容器无法访问外网时，首先需要验证网络的分层连通性： # 进入问题 Pod 测试网络 kubectl exec -it <pod-name> -- /bin/sh # 测试容器到节点网络 ping 10.244.0.1 # Pod 网关，通常是节点IP # 测试集群内部网络 nslookup kubernetes.default.svc.cluster.local # 测试外网IP连通性 ping 8.8.8.8 # 测试外网DNS解析 nslookup google.com 诊断要点：如果 ping 节点 IP 不通：CNI 网络问题如果 ping 外网 IP 不通：NAT/路由问题如果 IP 通但 DNS 不通：DNS 配置问题 1.