Docker Daemon 配置代理完整指南

November 28, 2025

字数: 209 · 阅读: 1 分钟 · 访问: -

1. 问题背景当 Docker daemon 需要访问外网资源（如 Docker Hub）时，但本地只能通过代理访问，直接运行 docker login 或 docker pull 会出现连接超时错误。这是因为设置在 shell 中的代理环境变量对 Docker daemon 服务无效。 Error response from daemon: Get "https://registry-1.docker.io/v2/": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers) 2. 解决方案 2.1. 第一步：创建 Docker daemon 配置目录 sudo mkdir -p /etc/systemd/system/docker.service.d 2.2. 第二步：编辑代理配置文件 sudo vim /etc/systemd/system/docker.service.d/http-proxy.conf 在文件中添加以下内容： [Service] Environment="HTTP_PROXY=http://PROXY_HOST:PROXY_PORT" Environment="HTTPS_PROXY=http://PROXY_HOST:PROXY_PORT" Environment="NO_PROXY=localhost,127.0.0.1" 参数说明： HTTP_PROXY - HTTP 连接代理地址 HTTPS_PROXY - HTTPS 连接代理地址 NO_PROXY - 不经过代理的地址列表（本地地址无需代理） 2.

深入理解 Linux conntrack：原理、用途、调优与生产实践

November 26, 2025

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

一、什么是 conntrack？ conntrack（全称 Connection Tracking，连接跟踪）是 Linux 内核 Netfilter 框架中的一个核心子系统，用于跟踪和记录主机上所有网络连接的状态信息。它不是用户态程序，而是内核模块（nf_conntrack），为有状态防火墙、NAT（网络地址转换）、负载均衡等高级网络功能提供基础支持。简单来说： conntrack 让 Linux 能“记住”每一个网络连接，而不仅仅处理孤立的数据包。二、conntrack 能做什么？有什么用？ ✅ 核心能力功能说明有状态包过滤允许 iptables 基于连接状态（如 ESTABLISHED, NEW）做策略，例如：“只放行已建立连接的返回流量”。 NAT 支持实现 SNAT（源地址转换）和 DNAT（目标地址转换）的关键。没有 conntrack，NAT 无法知道如何将返回包正确转发回原始客户端。连接状态管理跟踪 TCP/UDP/ICMP 等协议的连接生命周期，自动清理超时连接。安全防护拦截不符合连接状态的异常包（如伪造的 RST 包）。 🌐 典型应用场景 Docker / Kubernetes 网络：容器端口映射（-p 8080:8080）依赖 DNAT + conntrack。云服务器 NAT 网关：私有网络访问公网需 SNAT。 Web 服务器防火墙：仅允许 80/443 入站，但放行所有出站响应。透明代理、LVS 负载均衡：依赖连接状态做流量调度。三、如何安装和使用 conntrack 工具？虽然 conntrack 内核模块默认随系统加载，但用户态工具需单独安装。 🔧 安装（以主流 Linux 发行版为例） # Ubuntu / Debian sudo apt install conntrack # CentOS / Rocky / AlmaLinux sudo yum install conntrack-tools # 或 sudo dnf install conntrack-tools 🛠️ 常用命令命令作用 conntrack -L 列出当前所有被跟踪的连接 conntrack -E 实时监控连接事件（新建、更新、销毁） conntrack -S 显示各 CPU 的 conntrack 统计信息 conntrack -C 显示当前 conntrack 表中的连接总数 conntrack -D -s 192.

Linux ip 命令完全指南

November 25, 2025

字数: 1396 · 阅读: 7 分钟 · 访问: -

目录简介基础语法命令分类详解日常运维操作故障排查实战最佳实践简介 ip 命令是 Linux 系统中用于网络配置和管理的现代化工具,属于 iproute2 工具包。它是传统 ifconfig、route、arp 等命令的替代品,功能更强大、更灵活。为什么使用 ip 命令? 功能全面: 统一管理网络接口、路由、隧道、策略路由等输出清晰: 结构化的输出格式,便于脚本解析持续维护: 活跃开发,支持最新的内核特性性能更好: 直接与内核 netlink 接口通信基础语法 ip [ OPTIONS ] OBJECT { COMMAND | help } 常用选项 (OPTIONS) -4 或 -6: 指定 IPv4 或 IPv6 -s: 显示统计信息 (statistics) -d: 显示详细信息 (details) -c: 彩色输出 -br: 简洁输出 (brief) -j: JSON 格式输出 -p: 美化输出 (pretty print) 对象类型 (OBJECT) 对象简写说明 link l 网络设备 (网卡) address addr/a IP 地址 route r 路由表 neighbor neigh/n ARP 或 NDISC 缓存 rule ru 路由策略 tunnel t IP 隧道 maddress maddr 组播地址 netns netns 网络命名空间命令分类详解 1.

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.