Kubernetes证书过期怎么办？kubeadm集群证书更新全指南

如果你维护过Kubernetes集群超过一年，大概率会在某个周一的早晨收到告警：某个组件的证书还有不到30天到期。我第一次遇到这事儿的时候，集群里三个master节点同时报错，kubectl直接无法连接apiserver，排查了好几个小时才意识到问题出在证书上。后来我把整个证书体系的原理、检查方法和更新流程完整走了一遍，才发现这件事本身不难，难的是搞清楚“哪些证书会过期、谁负责续期、手动更新该从哪里入手”。

这篇指南就是围绕这套流程写的，涵盖Kubernetes集群证书的构成与过期机制、证书状态检查、更新方案选型、完整实操步骤，以及我在生产环境里踩过的坑和排查技巧。无论你是刚接触Kubernetes的运维新手，还是已经维护过一段时间集群的工程师，都可以直接照着文章里的命令和思路来操作。内容以kubeadm部署的集群为主线，因为这是最常见、也最适合演示证书更新流程的部署方式，二进制部署和其他方式我会在相关章节单独说明差异。

1. 为什么Kubernetes证书管理值得你紧张一次

1.1 集群里到底藏着多少张证书

很多朋友最初接触Kubernetes时，注意力都放在Pod、Deployment、Service这些工作负载概念上，证书这个事往往被忽略。直到集群某天突然不可用，才会意识到Kubernetes内部组件之间的通信，几乎全部建立在TLS证书之上。

一个典型的kubeadm部署集群，证书主要存放在两个地方：/etc/kubernetes/pki目录下保存核心CA和组件证书，/etc/kubernetes目录下保存kubeconfig文件所需的客户端证书。pki目录里通常是这些内容：

• ca.crt、ca.key：集群根CA，签发其他证书的基础。
• apiserver.crt、apiserver.key：kube-apiserver对外提供HTTPS服务时使用的证书。
• apiserver-kubelet-client.crt、apiserver-kubelet-client.key：apiserver访问kubelet时使用的客户端证书。
• front-proxy-ca.crt、front-proxy-ca.key：聚合API扩展（如metrics-server）专用的CA。
• front-proxy-client.crt、front-proxy-client.key：apiserver访问聚合API时使用的客户端证书。
• etcd/ca.crt、etcd/ca.key：etcd集群专用的CA。
• etcd/server.crt、etcd/server.key：etcd服务端证书。
• etcd/peer.crt、etcd/peer.key：etcd节点间通信证书。
• etcd/healthcheck-client.crt、etcd/healthcheck-client.key：etcd健康检查客户端证书。
• sa.pub、sa.key：ServiceAccount签名密钥，严格说不是证书对，但和证书体系一起管理。

再看/etc/kubernetes目录下的kubeconfig文件：admin.conf、kubelet.conf、controller-manager.conf、scheduler.conf。这些文件里各自内嵌了一张客户端证书，也需要纳入检查范围。注意apiserver.crt这张证书的SAN（Subject Alternative Name）里写入了集群的Service IP、Pod网段、DNS域名等关键地址，如果集群后续添加了新的节点IP或负载均衡地址，不更新SAN只续期是没有意义的。

1.2 证书过期之后会发生什么

理论上，如果集群的运行环境一切正常，kubeadm部署的集群会在证书到期前自动完成续期，这依赖于每个控制平面组件启动时自带的--cert-dir目录下的“自动续期”机制。但现实世界中证书过期导致的故障依然频繁发生，原因往往集中在三类情况：

• 控制平面组件长时间没有重启，而kubeadm的续期动作本质上依赖kubelet的证书轮换和组件重启配合。一个节点如果被冻结、休眠或者长时间不重启，自动续期就有概率失效。
• 用户手动替换过部分证书，导致kubeadm的自动续期逻辑认为证书“不是自己管理的”，跳过续期。
• 集群时间不同步。证书的签发和校验高度依赖系统时间，时间偏移超过几分钟就可能触发校验失败。

证书真正过期后，症状非常典型：kubectl执行任何命令都报Unable to connect to the server: x509: certificate has expired or is not yet valid，apiserver的日志里刷满TLS握手错误，节点状态变成NotReady。更麻烦的是，etcd和apiserver同时出问题时，连排查入口都很窄。所以证书管理这件事，核心思路不是“出了故障再修”，而是“定期检查、提前更新、控制风险”。

2. 证书状态体检：先查清楚家底再动手

2.1 kubeadm一键体检：check-expiration实操

kubeadm从1.11版本开始提供了一条内置命令，专门用于检查集群内各类证书的到期时间，这是我做证书体检时第一个会执行的命令：

bash复制kubeadm certs check-expiration

执行后输出会按证书类型列出剩余有效期，类似这样（这里用较短剩余时间做示例）：

text复制[check-expiration] Reading configuration from the cluster...
[check-expiration] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -o yaml'

CERTIFICATE                EXPIRES                  RESIDUAL TIME   CERTIFICATE AUTHORITY   EXTERNALLY MANAGED
admin.conf                 Oct 30, 2026 07:41 UTC   355d                                    no
apiserver                  Oct 30, 2026 07:41 UTC   355d            ca                      no
apiserver-kubelet-client   Oct 30, 2026 07:41 UTC   355d            ca                      no
controller-manager.conf    Oct 30, 2026 07:41 UTC   355d                                    no
etcd-healthcheck-client    Oct 30, 2026 07:41 UTC   355d            etcd-ca                 no
etcd-peer                  Oct 30, 2026 07:41 UTC   355d            etcd-ca                 no
etcd-server                Oct 30, 2026 07:41 UTC   355d            etcd-ca                 no
front-proxy-client         Oct 30, 2026 07:41 UTC   355d            front-proxy-ca          no
scheduler.conf             Oct 30, 2026 07:41 UTC   355d                                    no

注意最后一列EXTERNALLY MANAGED，如果显示为yes，说明这张证书由外部工具管理，kubeadm不会自动续期。看到这一项时要特别警惕：证书的更新职责已经不在kubeadm手里了，要么改用kubeadm统一管理，要么就得建立外部工具的监控机制。

check-expiration命令读取的是kubeadm在集群中保存的配置和本地文件，所以需要在能够访问/etc/kubernetes目录的master节点上执行。如果是高可用集群，三个master节点都要分别检查，因为每个节点本地的证书文件理论上应该一致，但实际操作中可能因为某个节点曾单独执行过更新操作而出现偏差。

2.2 手搓工具：openssl逐一扫描证书

check-expiration适合常规体检，但有两个场景它帮不上忙：一是kubeadm命令不可用的非标准部署集群，二是需要检查证书详细内容（比如SAN是否正确）而不是只看有效期。这时候就轮到openssl上场。

bash复制# 查看某张证书的到期时间
openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -dates

# 查看证书的SAN信息（重要！客户端校验时会比对域名和IP）
openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -text | grep -A 2 "Alternative Name"

# 查看证书签发者，确认是否由正确的CA签发
openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -issuer -subject

如果要检查整个目录下的所有证书，可以写一个小循环：

bash复制for cert in $(find /etc/kubernetes/pki -name "*.crt"); do
    echo "=== $cert ==="
    openssl x509 -in "$cert" -noout -dates
done

另外强烈建议把kubeconfig文件里的客户端证书也纳入检查。kubeconfig里的证书是base64编码后嵌入的，没法直接用文件路径检查，需要先提取出来：

bash复制grep "client-certificate-data" /etc/kubernetes/admin.conf | \
    awk '{print $2}' | base64 -d | openssl x509 -noout -dates

体检频率上，我的经验是：生产集群至少每月跑一次check-expiration，并在监控系统里为“证书剩余天数”设置告警阈值。剩余不足90天时开始预警，不足30天时升级为P1级别处理。这个频率和阈值听起来保守，但考虑到证书更新需要申请变更窗口、备份、分批操作，留够缓冲时间比事后救火舒服得多。

3. 证书更新方案的选型逻辑

3.1 kubeadm的自动更新机制，为何不能完全依赖

kubeadm在1.8版本之后引入了一个很有意思的设计：控制平面组件以Static Pod的方式运行，kubeadm会为每个组件生成包含证书参数的manifest文件。当kubelet检测到manifest文件变化时，会重建对应的Static Pod，新组件启动时会携带新的证书参数。kubeadm的证书自动续期机制正是利用了这个链路，在检测到证书临近过期时，通过更新kubeadm-config ConfigMap里的时间戳和证书参数，触发组件滚动重启来实现续期。

听起来很智能，但实际运维中不能完全依赖它，原因有几点。第一，自动续期依赖kubelet正常工作，如果kubelet自己的证书（kubelet.conf中的客户端证书）已经过期，整个链路会断掉，形成“先有鸡还是先有蛋”的困境。第二，自动续期只针对有效期，不更新证书内的SAN信息。前面提到apiserver证书SAN里写入了ClusterIP、节点IP等地址，如果这些地址有变化，光续期不换证书内容，组件间的TLS校验照样过不了。第三，一些客户化程度较高的部署方式（比如使用了自定义的CA、外部签署的证书、cert-manager管理的证书）会让kubeadm误判为“外部管理”，进而跳过自动续期。

所以自动更新机制可以当作“默认防线”，但生产环境必须配套主动巡检和手动更新预案。遇到证书实际已过期、集群已经不可用的情况，手动执行更新几乎是唯一可靠的救急手段，这也是我把手动更新作为重点来讲的原因。

3.2 手动更新与自动化脚本的取舍

手动更新kubeadm集群证书的经典方案是两句话：

bash复制kubeadm certs renew all
kubeadm init phase kubeconfig --config=/etc/kubernetes/kubeadm-config.yaml

不过手动执行这两条命令只是起点，后续还有kubeconfig重写、组件重启、节点证书分发等一系列工作。很多教程到这里就结束了，但真正维护过集群的人都知道，后面的步骤才是踩坑高发区。

关于自动化，常见的做法是写脚本在master节点上定时执行上述命令，配合kubectl drain节点和重启kubelet。我不建议一开始就上全自动，原因很简单：证书更新涉及apiserver、etcd等核心组件，一旦自动执行过程中出现问题，定位难度比手动执行大得多。更稳妥的折中方案是“半自动”：脚本负责检查证书剩余时间和执行更新命令，但关键节点（重启apiserver、确认组件状态）保留人工确认步骤。

还有一类特殊的证书更新需要额外留意：当集群签署的证书由cert-manager或外部PKI管理时，kubeadm的renew all不生效，需要回到证书签发源头去续期，再把新证书回填到集群目录。这种场景我在第5章的避坑部分会展开讲。

4. 证书更新实操全流程（kubeadm集群版）

4.1 更新前的备份与检查清单

任何对控制平面的操作，第一步都是备份，证书更新尤其如此。证书属于无法从集群里直接重新生成的敏感文件，一旦更新失败、文件被覆盖，没有备份基本只能重建整个集群。备份命令很简单：

bash复制# 备份证书目录
cp -rp /etc/kubernetes/pki /etc/kubernetes/pki.bak.$(date +%Y%m%d)
cp -rp /etc/kubernetes/*.conf /etc/kubernetes/conf.bak.$(date +%Y%m%d)

# 有条件的话，整个 /etc/kubernetes 目录一起备份更稳妥
cp -rp /etc/kubernetes /etc/kubernetes.bak.$(date +%Y%m%d)

备份完成后，对照这个清单逐项检查，避免中途出现意外：

• 确认所有master节点的系统时间一致且同步NTP。证书签发和校验对时间偏移非常敏感。
• 确认/etc/kubernetes/pki目录下存在kubeadm-config.yaml或集群中的kubeadm-config ConfigMap正常，因为后续生成kubeconfig需要读取配置信息。
• 确认当前kubectl资源可用（如果只是部分证书过期，kubectl一般还能用；如果已经全面不可用，请直接跳到故障恢复章节）。
• 记录当前集群中所有控制平面节点的数量。如果超过一个master节点，建议逐个节点串行更新，不要同时在三个master上执行更新命令。
• 检查是否有依赖证书的外部组件（如ingress-nginx、metrics-server等）以及它们的证书更新方式，避免集群证书更新后这些组件反而报错。

备份做完、清单核对无误，再继续下一步。

4.2 核心更新命令执行与验证

kubeadm提供了重新生成全部证书的命令，执行前你需要确认kubeadm版本与集群初始化时的版本一致或兼容。版本差距过大会导致生成的证书参数不匹配，这是很多人忽略的坑。先查看kubeadm版本：

bash复制kubeadm version

然后查询集群初始化时保存的配置（在任意master节点上执行即可）：

bash复制kubectl -n kube-system get cm kubeadm-config -o yaml

确认无误后，在第一个master节点上执行：

bash复制kubeadm certs renew all

如果集群配置信息无法从ConfigMap读取，可以显式指定配置文件：

bash复制kubeadm certs renew all --config=/etc/kubernetes/kubeadm.yaml

执行完成后，用第2章的检查命令确认到期时间已经更新：

bash复制kubeadm certs check-expiration

这里要特别说明：renew all重新生成的是/etc/kubernetes/pki下的证书文件，但/etc/kubernetes目录下的kubeconfig文件（admin.conf等）并没有被自动更新。这些kubeconfig文件里的客户端证书是独立管理的，需要额外生成：

bash复制kubeadm init phase kubeconfig admin --config=/etc/kubernetes/kubeadm-config.yaml
kubeadm init phase kubeconfig controller-manager --config=/etc/kubernetes/kubeadm-config.yaml
kubeadm init phase kubeconfig scheduler --config=/etc/kubernetes/kubeadm-config.yaml

注意，kubelet.conf这个文件的分发位置和上面几个不同。它不只是master节点上的文件，所有worker节点的kubelet都依赖它来连接apiserver。不过kubelet.conf的证书与master节点上的新证书实际上是同一个CA签发的，是否要立即更新，取决于kubelet当前的连接是否正常。对于Master节点，建议执行kubeadm init phase kubeconfig kubelet更新本地的kubelet配置。

到这里，证书文件层面已经完成更新。接下来最关键的一步是让运行中的组件加载新证书。由于控制平面组件以Static Pod方式运行，最直接的方式是重启kubelet，它会自动重建所有Static Pod：

bash复制systemctl restart kubelet

注意不要单独重启apiserver或etcd容器，因为它们是kubelet管理的Static Pod，手动重启容器与kubelet的管理逻辑容易产生状态不一致。正确的顺序是：更新所有证书文件后，统一重启每个节点上的kubelet，让kubelet按新证书的参数重新拉起控制平面Pod。

一种更细化的验证方式，是在执行完上述命令后，检查apiserver是否以新证书启动。看Pod的启动时间是否有变化，并观察apiserver日志里有没有TLS相关的报错：

bash复制kubectl -n kube-system get pod -l component=kube-apiserver
kubectl -n kube-system logs kube-apiserver-master01 | grep -i "certificate\|tls\|error" | tail -20

如果日志干净、Pod处于Running状态、kubectl get nodes能看到所有节点Ready，更新就算成功了一大半。剩余的工作是检查所有客户端组件是否都能正常连接apiserver，比如controller-manager、scheduler、kube-proxy、CoreDNS，以及集群里的业务Pod是否出现异常。

在一个多master的高可用集群中，第一个master节点更新后，先不要急着操作第二个节点。观察几分钟，确认集群稳定后，再用同样的流程处理第二个、第三个master节点。串行更新的核心价值在于：如果第一个节点更新后有问题，影响面可以被控制在单点，并且此时其他master节点还能提供API服务，便于回滚和排查。

4.3 从worker节点角度理解证书更新

worker节点的kubelet连接apiserver，依赖两个证书：一是kubelet自身的客户端证书（kubelet.conf），二是集群CA根证书（ca.crt）。当master节点更新了CA根证书或apiserver证书后，worker节点上的kubelet并不需要立即人工干预，因为kubelet启动时加载的ca.crt如果和apiserver新证书的签发CA一致，TLS校验是可以正常通过的。但有一种情况需要手动处理worker节点：master节点重建了全新的CA（比如kubeadm init phase certs ca之后又执行了renew），此时worker节点上的ca.crt还是旧CA，无法校验新apiserver证书，所有worker节点都会变成NotReady。

处理方式是用新的ca.crt覆盖worker节点上的旧文件，然后重启kubelet：

bash复制# 在worker节点执行，将新ca.crt从master拷贝过来
scp master01:/etc/kubernetes/pki/ca.crt /etc/kubernetes/pki/ca.crt

systemctl restart kubelet

需要区分的是，常规的kubeadm certs renew all不会重建CA，它只是在已有CA基础上重新签发证书，CA的根证书内容不变。所以大多数场景下，worker节点不需要做第二步操作。只有当你在初始化或排查中重新执行过kubeadm init phase certs ca、手动替换过CA时，才需要把新的CA根证书分发到所有节点。

关于worker节点kubelet.conf中的客户端证书，它默认支持自动轮换。检查/var/lib/kubelet/config.yaml中rotateCertificates字段，如果为true，kubelet会在自身证书临近过期时向apiserver申请新的证书。这个机制依赖集群的CertificateSigningRequest审批能力，若配置了自动审批插件（如kubelet-rubber-stamp），整个过程无需人工干预，否则需要在控制平面节点上手动审批kubectl certificate approve。

5. 高频故障排查与避坑实录

5.1 apiserver起不来、证书不匹配这类问题怎么定位

证书更新后最典型的问题就是某个组件起不来，或者所有组件都在CrashLoopBackOff，日志里报certificate signed by unknown authority或者x509: certificate is valid for xxx, not yyy。

遇到这种问题，第一步不要慌着去翻日志，先确认“你更新后的证书是否和其他节点的ca.crt匹配”。这是证书更新后故障最高频的根因。在apiserver所在节点执行：

bash复制# 检查apiserver证书的签发者
openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -issuer

# 检查集群的ca.crt
openssl x509 -in /etc/kubernetes/pki/ca.crt -noout -subject

如果apiserver证书的issuer和ca.crt里记录的subject对不上，说明证书链断裂。解决方法是确认更新证书时是否执行过CA重建类的命令，如果有，需要把新CA分发到所有节点并用它签发组件证书。

第二步检查SA key和SA pub是否移动过。ServiceAccount的令牌签名密钥（sa.key/sa.pub）也存放在pki目录，很多证书更新操作会误覆盖这个文件对。如果SA密钥被更换，集群内所有ServiceAccount令牌都会失效，Pod无法访问Kubernetes API服务，现象表现为Pod内部调用API接口时全部401或403。处理方式是从备份中恢复sa.key、sa.pub，并重启所有Pod让其重新获取令牌。

第三步检查时间同步。一个很容易被忽略的现象是，更新证书后组件日志显示证书信息看起来正确，时间也对得上，但就是校验失败。此时执行date对比所有节点的系统时间，如果偏差超过30秒，TLS校验大概率失败。等同步好时间后，通常不需要重新生成证书，重启组件即可恢复。

5.2 etcd证书与外部组件证书的特殊处理

etcd在Kubernetes体系里相对独立，它有自己的CA和证书集合，位置在/etc/kubernetes/pki/etcd目录下。etcd证书更新后，除了etcd自身要重启，kube-apiserver连接etcd时使用的客户端证书也需要同步更新。apiserver连接etcd使用的是etcd-client.crt和etcd-client.key（如果没有单独生成，默认就是/etc/kubernetes/pki/etcd下的健康检查证书，或者通过apiserver的--etcd-certfile参数指定）。

在kubeadm集群中，kubeadm certs renew all会一并处理etcd相关证书，但要注意：apiserver的Static Pod manifest里如果写死了旧的证书路径，即使证书文件已更新，apiserver也需要重启才能加载新证书。前面提到的systemctl restart kubelet就是一个合理的触发方式。

外部组件的情况更复杂。以ingress-nginx为例，它对外提供HTTPS服务时使用的证书，和在集群内部组件间通信使用的证书完全是两套体系，前者通常由cert-manager或人工上传的Secret管理，不受kubeadm证书更新的影响。但metrics-server这类依赖聚合API的组件，使用的是front-proxy-client证书来连接apiserver的聚合端口，如果更新了front-proxy-ca.crt却没有同步更新front-proxy-client.crt的签发CA，metrics-server会连不上apiserver，表现为kubectl top nodes报错。

排查这类问题的通用思路是：明确组件连接的方向、使用的证书文件路径和对应的签发CA，再按“证书内容——CA匹配——加载状态”的顺序逐层验证。很多看起来玄学的问题，最后都能归因到某一层不匹配。

还有一个我见过很多次的坑：证书更新后，部分客户端（比如kubectl的admin.conf）因为用的还是旧证书，访问apiserver时提示Unauthorized。这种不是apiserver的问题，而是kubeconfig文件需要重新获取。把新生成的admin.conf内容更新到本机~/.kube/config，问题就能解决。同理，CI/CD系统、监控系统里配置的kubeconfig，也都要在证书更新后同步替换。

5.3 我踩过的坑和总结的检查清单

第一次在生产集群做证书更新时，我犯过一个很低级的错误：直接在三个master节点上同时执行了kubeadm certs renew all和重启命令，导致apiserver产生了一小段时间的双主写冲突，集群部分请求报错。后来规范成串行更新，故障面就能控制在小范围。

第二个教训是关于备份的。当时我觉得证书文件就那几个，备份pki目录就够了，结果更新时kubeadm init phase kubeconfig重新生成的kubeconfig配置需要读取原/etc/kubernetes/admin.conf等文件的上下文，如果只备份pki，遇到配置被覆盖时会很被动。所以现在我的备份策略是pki目录和所有*.conf文件一起备份，且备份文件保留至少一个版本周期（一般是上一次和当前各一份）。

第三个坑是kubeadm certs renew all执行时如果报错failed to load kubeadm config，说明命令没有找到kubeadm配置。解决办法是先确认当前集群的kubeadm配置通过kubectl -n kube-system get cm kubeadm-config -o yaml可以正常读取，再通过--config参数显式指定本地配置文件。如果集群的ConfigMap已经损坏或删除，需要从/etc/kubernetes/kubeadm-config.yaml恢复初始配置。

我把更新后的完整验证步骤整理成一个清单，每次操作完逐项确认：

这套流程走一遍，证书更新的操作才算真正闭环。如果中间任何一步异常，回到第5.1节的排查思路逐层定位即可，大部分问题都不是什么高深的技术难点，而是证书不匹配、配置路径错误、组件没加载新文件这类基础问题。

6. 证书管理计划：做完一次更新后怎么保持长期健康

证书不是更新完就一劳永逸，它本质上是一个周期性任务。维护集群时间久了，我总结了一套轻量但有效的“证书管理计划”，分享出来供参考。

首先是建立证书台账。把集群中所有节点的IP、角色、证书路径、到期时间记录在一个表格或运维系统里，每月更新一次。不需要太复杂，但至少要能回答“这个集群的证书什么时候到期”这个问题。尤其有多套集群的公司，没有台账的话，各个集群的到期时间很容易被遗忘，只能等告警来提醒。

其次是配置监控告警。最基础的做法是用cron定时执行kubeadm certs check-expiration，将输出导入到监控系统；进阶做法是直接读取文件系统里的证书信息，通过Prometheus的自定义exporter暴露“证书剩余天数”指标。在告警规则中，参考阈值设为：剩余90天发Warning，剩余30天发Critical。这里不建议直接根据“证书过期”去告警，因为证书过期意味着集群已经受影响，提前量很重要。

再次是规划更新窗口。证书更新属于控制面变更，建议走变更管理流程。在生产集群，我一般会选择业务低峰期，先在一个master节点上更新并验证，观察10到30分钟后再处理剩余节点。如果集群规模较大（超过50个节点），worker节点的kubelet和kubeconfig同步也要纳入计划，不要只在master节点上完成就收工。

最后是思考是否引入自动化工具。如果你管理的集群数量多、证书种类复杂，可以考虑用cert-manager或专业证书管理平台来统一管理Kubernetes各组件的证书。对于kubeadm集群，Kubernetes社区还提供了kubeadm通过CRI接口实现证书轮换的方案，以及在较新版本中引入的KubeletCertificateRotation特性，这些都可以减少人工操作。但引入任何工具之前，先想清楚你的场景是否需要：单集群、小规模的场景，手动加定时巡检完全够用；多集群、大规模的场景，才值得投入自动化成本。

在自动化和手动操作之间，我个人更倾向“先手动跑通，再用脚本固化”。手动跑通的意义在于，你能真正理解每一步操作对集群产生的影响，而不是把黑盒脚本丢给生产环境。脚本固化则能把重复劳动压缩到最低。如果哪一天真的要靠自动化来救急，至少你知道脚本每一步在做什么，排查起来也不会一头雾水。