1. 从零上手Weave这个工具到底在解决什么问题第一次接触Weave的人十有八九是被同一个场景带进来的手头有一堆容器在跑服务之间调用关系错综复杂某天线上突然某个接口超时你打开监控面板发现满屏都是容器ID和IP地址根本分不清谁调用了谁。这时候有人跟你说“装个Weave吧”你装完之后发现确实能看到网络拓扑了但随之而来的是一连串新问题——DNS解析怎么配、跨主机通信为什么不通、策略规则写了不生效、性能怎么调优。这些问题散落在各种文档和论坛里每次遇到都要重新搜一遍。这篇内容就是把这些高频问题集中整理出来结合我自己在多个项目里实际踩过的坑给出可复现的排查路径和配置方案。不管你是刚接触Weave的新手还是已经用了一段时间但总被某些“玄学问题”卡住的老手都能从这里找到对应的答案。核心关键词包括Weave网络、容器通信、DNS解析、网络策略、故障排查、性能调优这些都会在后面的章节里逐一展开。Weave的本质是一个为容器编排环境设计的虚拟网络方案它做的事情说穿了就一句话让分布在不同主机上的容器像在同一个局域网里一样互相通信。听起来简单但要把它用稳、用好需要理解它的几个核心机制——Peer之间的加密隧道、基于 gossip 的拓扑发现、内置的DNS服务、以及策略控制器。这四个模块任何一个出问题表现出来的症状都可能是“网络不通”但根因和排查方法完全不同。适合阅读这篇内容的人我大致分三类第一类是刚把Weave部署起来正在做基础连通性验证的运维或开发第二类是已经在生产环境跑着Weave但遇到了性能瓶颈或者偶发故障需要系统化排查思路第三类是在做技术选型想搞清楚Weave和其他容器网络方案的差异以及它在什么场景下更合适。这三类人的关注点不同但底层需要掌握的知识是共通的。2. Weave核心机制拆解为什么你的网络会出问题2.1 Peer通信与加密隧道的工作原理Weave的Peer机制是整个网络的基础。每台运行Weave的主机上会启动一个weaverouter进程这个进程负责和其他主机上的weaverouter建立TCP连接默认端口是6783。这些连接构成了一个全网状的拓扑每个Peer都知道其他所有Peer的存在。当你启动一个容器并接入Weave网络时它的网络流量会被weaverouter接管通过已经建立的Peer连接转发到目标主机。这里第一个高频问题就来了为什么我的Peer状态显示是established但容器之间就是ping不通这种情况大概率不是Peer连接本身的问题而是数据平面的转发出了问题。Peer连接走的是控制平面负责交换拓扑信息和路由规则实际的数据包转发走的是另一个通道。你需要分别检查这两个层面。排查的时候先在每台主机上执行weave status connections看看Peer之间的连接状态。正常情况应该显示所有Peer都是established。如果某个Peer显示connecting或者failed那问题就在控制平面需要检查防火墙规则是否放行了6783端口以及主机之间的时钟是否同步——Weave的加密握手对时间偏差比较敏感超过一定阈值会拒绝连接。如果Peer连接都正常但容器不通那就进入数据平面排查。用weave status查看各个Peer的转发规则是否一致有时候某个Peer因为网络抖动导致路由表没有同步重启一下weaverouter进程就能恢复。我遇到过最隐蔽的一次是MTU问题主机网卡的MTU是1500但中间某段网络设备的MTU只有1400导致大包被丢弃小包正常。表现就是ping能通但HTTP请求偶尔超时。解决办法是在Weave配置里把MTU调小具体设成多少需要根据你的网络环境实测。注意调整MTU之后需要重启所有Peer上的weaverouter并且重建容器网络命名空间否则已有容器仍然使用旧的MTU值。2.2 DNS解析机制与常见解析失败场景Weave内置了一个DNS服务这是它相比其他方案的一个明显优势。每个接入Weave网络的容器都会自动获得一个域名格式是容器名.weave.local。这个DNS服务由weaverouter进程提供监听在容器网络内部的特定地址上。DNS解析失败是仅次于连通性问题的第二大高频问题。常见的症状是容器之间用IP能通但用域名就不行。这时候按以下顺序排查第一步确认容器内的/etc/resolv.conf是否指向了Weave的DNS地址。正常情况下应该看到类似nameserver 10.32.0.1这样的条目。如果没有说明容器启动时没有正确注入DNS配置需要检查Weave的启动参数里--dns相关的设置。第二步在容器内直接dig一下目标域名看返回什么。如果返回NXDOMAIN说明Weave的DNS服务没有注册这个容器名。这通常发生在容器启动后Weave还没来得及注册的情况下等几秒钟再试。如果一直不注册检查容器名是否符合规范——Weave对容器名的字符集有要求包含下划线或特殊字符的名字可能无法正确注册。第三步如果DNS返回了IP但连接超时那就不是DNS的问题了回到连通性排查的流程。这里有个容易混淆的点DNS解析成功只代表域名到IP的映射没问题不代表网络路径是通的。还有一个场景是跨子网的DNS解析。如果你的Weave网络跨越了多个子网默认情况下DNS注册信息可能不会跨子网同步。需要在启动weaverouter时加上--dns-effective-zone参数明确指定DNS生效的区域范围。这个参数的具体值取决于你的网络规划一般设成你的容器域名后缀即可。2.3 网络策略的生效逻辑与优先级Weave的策略控制器允许你定义容器之间的访问规则比如只允许A容器的80端口被B容器访问其他一律拒绝。策略的语法看起来不复杂但实际用起来有几个容易踩的坑。第一个坑是策略的默认行为。Weave的策略默认是“允许所有”也就是说如果你不写任何策略所有容器之间可以自由通信。只有当你显式定义了拒绝规则限制才会生效。这和某些防火墙的“默认拒绝”逻辑正好相反很多人按防火墙的思维去配结果发现配了跟没配一样。第二个坑是策略的作用范围。Weave的策略是基于标签label来匹配的不是基于IP或容器名。你需要在启动容器时给它们打上合适的标签然后在策略里引用这些标签。如果标签打错了或者漏打了策略就不会按预期生效。排查的时候用weave status policy查看当前生效的策略列表确认你的规则是否在里面。第三个坑是策略的优先级。当多条策略同时匹配一个连接时Weave按照“最具体优先”的原则来决定。比如你有一条规则允许所有容器访问A的80端口另一条规则拒绝B访问A的80端口那么B访问A的时候会被拒绝因为第二条规则更具体。理解这个优先级逻辑才能写出符合预期的策略组合。实操心得写完策略后不要急着上线先用weave status policy确认规则已经加载然后用一个测试容器实际验证一下允许和拒绝的场景。我见过太多次策略写对了但标签打错导致规则不生效的情况。3. 高频问题实操排查手册3.1 容器跨主机通信失败的完整排查路径跨主机通信失败是Weave使用中最常见的问题类型。我把它拆成一条固定的排查路径你按顺序走一遍基本能定位到根因。第一步确认基础网络连通性。在两台主机之间互相ping对方的物理IP确保底层网络是通的。如果物理网络都不通Weave再怎么配也没用。这一步看起来废话但我确实遇到过因为交换机VLAN配置问题导致主机之间不通却在Weave层面折腾了半天的案例。第二步检查Weave Peer状态。在每台主机上执行weave status connections确认所有Peer都是established。如果有Peer显示failed或connecting先解决Peer连接问题。Peer连接不建立跨主机通信一定不通。第三步验证容器网络配置。进入容器内部执行ip addr查看网卡配置。正常情况下应该看到一个weave网卡IP地址在10.32.0.0/12这个网段内。如果容器里只有lo网卡说明容器没有正确接入Weave网络检查启动命令里是否加了weave attach或者--netweave参数。第四步检查路由表。在容器内执行ip route确认默认路由指向了weave网卡。然后在主机上执行ip route查看是否有到目标容器网段的路由条目。Weave会在主机上自动添加路由规则如果这些规则丢失了跨主机通信就会失败。路由丢失的常见原因是主机重启后weaverouter没有正确恢复状态重启一下weaverouter即可。第五步抓包分析。如果前面四步都没问题但通信仍然失败那就需要在主机上抓包了。在源主机上抓weave网卡的包看数据包是否发出在目标主机上抓包看数据包是否到达。如果源主机发出了但目标主机没收到问题在中间网络如果目标主机收到了但没有回应问题在目标主机的容器配置或策略规则上。这套流程走下来90%以上的跨主机通信问题都能定位到具体环节。剩下的10%通常是MTU不匹配、内核版本兼容性、或者安全策略拦截这类比较隐蔽的问题需要结合具体环境分析。3.2 Weave DNS不生效的六种原因与修复方法DNS问题我单独拿出来讲因为它出现的频率太高了而且症状容易和连通性问题混淆。下面这六种原因覆盖了我遇到过的绝大多数DNS故障场景。原因一容器启动时未指定DNS。如果你是用weave run启动容器Weave会自动注入DNS配置。但如果你是用docker run然后手动weave attachDNS配置可能不会自动注入。解决办法是在docker run时加上--dns参数指向Weave的DNS服务地址。原因二容器名不符合规范。Weave的DNS注册对容器名有要求只支持字母、数字和连字符。如果容器名包含下划线、点号或其他特殊字符DNS注册会失败。解决办法是启动容器时用--name指定一个符合规范的名称。原因三DNS服务未启动。在主机上执行weave status确认DNS服务显示为ready。如果显示not ready检查weaverouter的日志看是否有端口冲突或配置错误。原因四跨子网DNS未同步。前面提到过跨子网场景需要配置--dns-effective-zone。如果你有多台主机分布在不同的子网而DNS解析只在同子网内有效就是这个原因。原因五容器内resolv.conf被覆盖。有些基础镜像在启动时会重写/etc/resolv.conf把Weave注入的DNS配置覆盖掉。解决办法是在Dockerfile里避免覆盖resolv.conf或者在容器启动后手动修正。原因六DNS缓存污染。如果之前用同样的容器名启动过容器DNS缓存里可能还留着旧的IP记录。解决办法是重启weaverouter清除缓存或者换一个容器名。故障现象可能原因快速验证方法修复操作容器内无DNS配置启动时未注入查看/etc/resolv.conf加--dns参数重启容器解析返回NXDOMAIN容器名不规范检查容器名特殊字符用规范名称重建容器同子网能解析跨子网不行DNS区域未配置对比不同子网容器解析结果加--dns-effective-zone参数解析时好时坏DNS缓存污染多次dig同一域名重启weaverouter清缓存解析到IP但连不上非DNS问题ping目标IP转连通性排查流程3.3 策略规则写了不生效的调试方法策略不生效这个问题我总结了一个“三层验证法”从外到内逐层排查。第一层确认策略已加载。执行weave status policy看你的规则是否出现在输出里。如果没出现说明策略文件没有被正确读取。检查策略文件的路径和格式Weave的策略文件是JSON格式一个字符写错都会导致加载失败。第二层确认标签匹配。策略是基于标签匹配的你需要确认容器的标签和策略里写的标签完全一致。执行weave ps查看容器的标签列表注意标签是大小写敏感的appweb和appWeb会被当成两个不同的标签。第三层确认连接方向。Weave的策略是有方向的allow规则里指定的源和目标顺序很重要。如果你写的是“允许A访问B”那B主动访问A是不被允许的。很多人在这里搞反了方向导致策略看起来写了但实际不生效。还有一个隐藏的坑策略的生效时间。Weave的策略是动态加载的但已经建立的连接不会立即受新策略影响。也就是说如果你在连接建立之后才添加拒绝策略这个连接可能还会继续通信一段时间直到连接超时重建。验证策略的时候最好用新的连接来测试不要复用已有连接。实操心得调试策略的时候我习惯先写一条“全部拒绝”的策略确认所有通信都被阻断然后再逐条添加允许规则。这样能确保策略机制本身是生效的避免出现“以为策略生效了其实根本没加载”的尴尬。4. 性能调优与稳定性保障4.1 大规模容器场景下的Weave性能优化当容器数量超过一定规模我的经验值是单主机超过50个容器或者集群总容器数超过500个Weave的默认配置可能会成为性能瓶颈。表现包括容器启动变慢、DNS解析延迟增加、网络吞吐下降。第一个优化点是调整gossip参数。Weave用gossip协议来同步拓扑信息默认的同步频率比较高在大规模场景下会产生大量控制平面流量。可以通过--gossip-interval参数调大同步间隔减少控制平面开销。具体设成多少需要根据集群规模来定一般容器数越多间隔可以设得越大。第二个优化点是启用Fast Datapath。Weave支持一种叫做Fast Datapath的模式它利用内核的Open vSwitch模块来加速数据转发绕过用户态的weaverouter进程。启用方式是在启动weaverouter时加上--datapathfast参数。实测下来Fast Datapath模式能带来30%到50%的吞吐提升延迟也有明显降低。但要注意Fast Datapath对内核版本有要求太老的内核可能不支持。第三个优化点是合理规划容器网段。Weave默认使用10.32.0.0/12这个网段这个网段很大但如果你的集群跨越多个子网需要确保每个子网的容器网段不冲突。网段冲突会导致路由混乱表现为部分容器能通部分不通。规划的时候建议给每个子网分配独立的子网段比如子网A用10.32.0.0/16子网B用10.33.0.0/16。第四个优化点是限制Peer连接数。在全网状拓扑下每个Peer都要和其他所有Peer建立连接N个Peer就有N*(N-1)/2条连接。当Peer数量超过20个时连接数会急剧增加控制平面压力很大。解决办法是使用Weave的--no-discovery模式手动指定Peer列表只和必要的Peer建立连接减少连接数。4.2 容器频繁重启导致网络不稳定的处理容器频繁重启是另一个常见的稳定性问题。每次容器重启Weave都需要重新注册DNS、更新路由规则、同步拓扑信息。如果重启频率太高Weave的控制平面会一直处于忙碌状态影响其他容器的网络性能。处理这个问题的第一步是找到容器重启的原因。用docker events或者weave status查看容器的重启记录分析是应用崩溃、资源不足还是健康检查失败导致的。如果是应用本身的问题优先修应用如果是资源不足调整容器的资源限制。第二步是调整Weave的重连参数。Weave在检测到容器消失后会等待一段时间才清理相关的网络资源。如果容器很快又启动了Weave可能还没来得及清理旧资源导致新容器注册失败。可以通过--container-reconnect-delay参数调整这个等待时间让Weave更快地响应容器变化。第三步是考虑使用固定IP。如果容器需要频繁重启每次重启后IP都变会给依赖方带来麻烦。Weave支持给容器分配固定IP在启动容器时通过--ip参数指定。这样即使容器重启IP保持不变DNS记录也不需要更新减少控制平面的开销。注意固定IP需要你自己管理IP分配避免冲突。建议用一个简单的表格记录哪些IP已经分配或者写个脚本自动管理。4.3 监控Weave健康状态的实用方法Weave本身提供了一些状态查询命令但要全面掌握它的健康状态还需要结合一些外部监控手段。最基础的监控是定期执行weave status检查各个组件的状态。你可以写一个简单的脚本每隔几分钟执行一次把结果输出到日志或者监控系统。重点关注Peer连接数、DNS服务状态、策略加载状态这几个指标。进阶一点的做法是采集Weave的metrics。Weave暴露了一个metrics接口可以输出各种运行时指标包括连接数、转发包数、丢包数等。你可以用Prometheus之类的工具来采集这些指标配置告警规则。比如Peer连接数突然下降、丢包率超过阈值都值得关注。还有一个实用的技巧是在容器内定期做连通性探测。选几个关键容器在它们内部定期ping其他容器的域名记录成功率和延迟。这个数据能直观反映Weave网络的健康程度而且是从应用视角看到的真实情况比看Weave自身的状态更贴近实际体验。监控项采集方式正常范围异常处理Peer连接状态weave status connections全部established检查防火墙和时钟同步DNS解析成功率容器内定期dig99%以上检查DNS服务和容器名规范网络延迟容器间ping同子网1ms跨子网10ms检查MTU和路由丢包率ping统计接近0检查网络设备和MTU策略加载状态weave status policy规则数与预期一致检查策略文件格式5. 版本升级与迁移中的避坑指南5.1 Weave版本升级的注意事项Weave的版本迭代比较快升级过程中有几个地方需要特别注意。首先是版本兼容性。Weave的不同大版本之间协议格式可能有变化。如果你要跨大版本升级比如从1.x升到2.x需要先确认新旧版本能否互通。稳妥的做法是先升级一台主机观察一段时间确认没有问题再升级其他主机。升级过程中新旧版本的Peer可能无法建立连接所以最好在业务低峰期操作。其次是配置文件的兼容性。新版本可能引入新的配置参数或者废弃旧的参数。升级前先看一下新版本的release notes确认你的配置文件是否需要调整。我遇到过升级后因为某个参数被废弃导致weaverouter启动失败的情况排查了半天才发现是配置问题。第三是数据平面的兼容性。如果你启用了Fast Datapath升级时需要确认新版本是否支持你当前的内核版本。有些新版本的Fast Datapath需要更新的内核升级Weave之前可能需要先升级内核。升级的操作步骤我建议这样安排先在测试环境完整走一遍升级流程记录每一步的输出和耗时然后在生产环境选择一台非关键主机先升级观察24小时确认无异常后逐台升级剩余主机。每台主机升级后用weave status确认状态正常再做下一台。5.2 从其他网络方案迁移到Weave的实操建议如果你之前用的是其他容器网络方案想迁移到Weave有几个关键点需要注意。IP网段的规划是最先要做的。Weave默认用10.32.0.0/12你需要确认这个网段和你现有网络不冲突。如果冲突可以在启动weaverouter时通过--ipalloc-range参数指定其他网段。规划的时候要留足余量考虑未来容器数量的增长。DNS名称的迁移是第二个要考虑的。如果你之前的方案用的是自定义DNS名称迁移到Weave后需要把名称映射到Weave的DNS格式。可以在Weave的DNS基础上用CNAME记录做一层别名让应用不需要改配置就能继续用原来的名称。策略规则的迁移是第三个。不同网络方案的策略语法不同没法直接复制。你需要把原来的策略规则逐条翻译成Weave的格式。翻译的时候注意Weave的策略是基于标签的所以需要先给容器打上合适的标签再写策略规则。迁移的节奏建议是逐步切换不要一次性全切。可以先迁移一部分非关键业务跑一段时间确认稳定后再迁移关键业务。迁移过程中新旧两套网络可以并存通过路由配置让它们互通这样切换的时候业务不会中断。实操心得迁移前一定要做一次完整的网络拓扑梳理把所有的通信关系画出来。我见过太多迁移到一半发现漏了某个通信路径导致业务中断的情况。梳理的时候不要只看配置文件要结合实际流量抓包确认没有隐藏的通信关系。6. 那些文档里不会写的实战经验6.1 容器时间不同步引发的诡异网络问题这个问题我单独拿出来讲因为它太隐蔽了而且症状和网络问题一模一样很容易误导排查方向。Weave的Peer之间用加密隧道通信加密握手对时间敏感。如果两台主机的时间偏差超过一定阈值通常是几分钟握手会失败Peer连接建立不起来。但症状表现出来是“网络不通”你可能会去查防火墙、查路由折腾半天才发现是时间问题。更隐蔽的是时间偏差不大的时候Peer连接能建立但数据传输过程中会出现间歇性的失败。因为加密会话的序列号和时间相关时间偏差会导致部分数据包被判定为过期而丢弃。表现就是网络时通时不通丢包率不高但一直有。解决办法很简单在所有主机上配置NTP时间同步。如果主机不能访问外网NTP服务器可以在内网搭一个NTP服务所有主机指向它。配置完成后用ntpq -p确认时间同步状态偏差应该控制在毫秒级。注意调整系统时间可能会影响正在运行的其他服务建议在业务低峰期操作或者用逐步调整的方式而不是直接跳变。6.2 Weave与主机防火墙的共存配置主机防火墙和Weave的共存是个老生常谈的问题但每次配置新环境还是会遇到。核心原则是放行Weave需要的端口但不要完全关闭防火墙。Weave需要放行的端口主要有两个TCP 6783用于Peer之间的控制连接UDP 6783用于数据平面的转发如果没用Fast Datapath的话。另外如果你用了Weave的DNS服务还需要放行DNS相关的端口。配置防火墙规则的时候建议限制源地址范围只允许你的主机网段访问这些端口而不是对所有地址开放。这样既保证了Weave的正常运行又不会引入额外的安全风险。还有一个容易忽略的点Docker自身的iptables规则。Docker在启动时会自动添加一些iptables规则这些规则可能会和Weave的规则冲突。如果发现Weave的规则被Docker覆盖了可以调整Docker的启动参数让它不要管理iptables或者手动调整规则顺序。6.3 备份与恢复Weave配置的正确姿势Weave的配置信息分布在多个地方weaverouter的启动参数、策略文件、DNS注册信息、Peer连接状态。备份的时候需要把这些都覆盖到。启动参数通常写在systemd的service文件或者启动脚本里直接备份这些文件即可。策略文件是独立的JSON文件备份它就行。DNS注册信息和Peer连接状态是运行时数据没法直接备份但可以在恢复时通过重启容器和weaverouter来重建。恢复的步骤是先恢复启动参数和策略文件然后启动weaverouter最后重启所有容器让它们重新注册。恢复过程中要注意Peer连接的建立顺序最好先启动一台主机作为种子节点其他主机再依次加入。我建议把Weave的配置纳入版本管理每次修改都提交到Git。这样不仅方便备份恢复还能追溯配置变更历史排查问题时能快速定位到是哪次变更引入的。配置项存储位置备份方式恢复方式启动参数systemd service文件文件复制覆盖后重启服务策略规则JSON策略文件文件复制覆盖后重新加载DNS注册信息运行时内存无法直接备份重启容器重建Peer连接状态运行时内存无法直接备份重启weaverouter重建容器IP分配运行时内存无法直接备份重启容器重建7. 常见问题速查与排查思路总结把前面散落的问题集中成一张速查表遇到问题的时候可以先在这里对照一下快速定位到可能的章节。问题现象最可能的原因优先排查方向参考章节容器之间完全不通Peer连接未建立weave status connections2.1同主机通跨主机不通路由或MTU问题主机路由表和MTU设置3.1域名解析失败DNS配置或容器名问题resolv.conf和容器名3.2策略不生效标签不匹配或方向反了weave status policy3.3网络时通时不通时间不同步或MTU不匹配NTP状态和MTU6.1容器启动变慢控制平面负载过高gossip参数和Peer数量4.1升级后网络异常版本兼容性问题新旧版本协议差异5.1防火墙配置后不通端口未放行或规则冲突6783端口和iptables6.2排查的时候有一个通用原则从底层往上层查从简单往复杂查。先确认物理网络通不通再确认Peer连接建没建立然后查容器网络配置最后查策略和DNS。不要一上来就怀疑最复杂的原因大部分问题其实都出在基础配置上。另外养成看日志的习惯。weaverouter的日志里有很多有用的信息包括Peer连接过程、DNS注册记录、策略加载结果。日志默认输出到syslog你可以配置输出到独立文件方便查看。排查问题的时候先把日志级别调到debug复现问题后分析日志往往能直接定位到根因。我个人在实际操作中的体会是Weave的很多“玄学问题”归根结底都是配置不一致导致的。不同主机的Weave版本不一致、启动参数不一致、防火墙规则不一致都会导致各种奇怪的现象。所以我在管理Weave集群的时候会用配置管理工具保证所有主机的配置完全一致每次变更都走统一的流程。这样做之后网络故障率明显下降排查问题也简单多了——因为你知道所有主机的配置都是一样的问题一定出在环境而不是配置上。最后再分享一个小技巧如果你不确定某个配置变更会不会影响网络可以先在一台非关键主机上试用weave status和实际连通性测试验证效果确认没问题再推广到整个集群。Weave支持滚动重启你可以逐台重启weaverouter业务不会中断。这个方式虽然慢一点但稳妥适合生产环境。