运维 on Liangweidong's blog

K8s 节点扩容：worker 加入集群一键脚本

Sun, 15 Dec 2024 00:00:00 +0800

K8s 集群扩容的场景

集群跑了一段时间，资源不够了，要加新 worker？常见两种来源：

全新机器（裸金属 + Ubuntu 22.04）
之前装过 kubeadm 跑挂了，现在想重新加入

第二种特别棘手——kubeadm 残留的证书、配置文件、iptables 规则都会让 node join 失败。

适用版本：K8s 1.28.5 / Ubuntu 22.04

1. 全新 worker 加入（推荐）

1.1 master1 上操作

设置 hosts

1
2
3
4


cat << "EOF" >> /etc/hosts
<新 worker1 ip> worker1
<新 worker2 ip> worker2
EOF

免密登录

1
2
3
4
5


sshpass -p <YOUR_SSH_PASSWORD> ssh-copy-id -o StrictHostKeyChecking=no worker1

# 如果 worker 之前有 known_hosts 冲突
ssh-keygen -f "/root/.ssh/known_hosts" -R "worker1"
sshpass -p <YOUR_SSH_PASSWORD> ssh-copy-id -o StrictHostKeyChecking=no worker1

实际密码用占位符 <YOUR_SSH_PASSWORD> 替代（执行前请把 <YOUR_SSH_PASSWORD> 替换为真实 SSH 密码，或通过 export SSHPASS=... 后 sshpass -p $SSHPASS 注入）。

推送二进制 + 证书 + 服务配置

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


# 1. 推送二进制
scp /usr/local/bin/kube{let,-proxy} worker1:/usr/local/bin/
scp /usr/local/bin/cri-dockerd worker1:/usr/local/bin/

# 2. 推送证书
ssh worker1 mkdir -p /etc/kubernetes/{manifests,pki}
cd /etc/kubernetes
for FILE in pki/ca.pem pki/ca-key.pem pki/front-proxy-ca.pem kubelet-conf.yml kube-proxy.yaml bootstrap-kubelet.kubeconfig kubelet.kubeconfig kube-proxy.kubeconfig; do
 scp /etc/kubernetes/$FILE worker1:/etc/kubernetes/${FILE}
done
scp -r /etc/kubernetes/manifests worker1:/etc/kubernetes

# 3. 推送 systemd 单元
for FILE in /etc/systemd/system/cri-docker.service /etc/systemd/system/cri-docker.socket /etc/systemd/system/kubelet.service /etc/systemd/system/kube-proxy.service; do
 scp $FILE worker1:${FILE}
done

1.2 一键脚本（推荐）

把上面 3 步封装到 join_k8s.sh，在 master1 上：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


#!/bin/bash
# join_k8s.sh <worker-name>
WORKER=$1
echo "=== Pushing binaries to $WORKER ==="
scp /usr/local/bin/kube{let,-proxy} $WORKER:/usr/local/bin/
scp /usr/local/bin/cri-dockerd $WORKER:/usr/local/bin/

echo "=== Pushing certs ==="
ssh $WORKER "mkdir -p /etc/kubernetes/{manifests,pki}"
for FILE in pki/ca.pem pki/ca-key.pem pki/front-proxy-ca.pem kubelet-conf.yml kube-proxy.yaml bootstrap-kubelet.kubeconfig kubelet.kubeconfig kube-proxy.kubeconfig; do
 scp /etc/kubernetes/$FILE $WORKER:/etc/kubernetes/${FILE}
done
scp -r /etc/kubernetes/manifests $WORKER:/etc/kubernetes

echo "=== Pushing systemd units ==="
for FILE in /etc/systemd/system/cri-docker.service /etc/systemd/system/cri-docker.socket /etc/systemd/system/kubelet.service /etc/systemd/system/kube-proxy.service; do
 scp $FILE $WORKER:${FILE}
done
echo "=== Done. Now SSH to $WORKER and start services ==="

worker 上的 worker.sh：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31


#!/bin/bash
# worker.sh
echo "=== Disable swap ==="
swapoff -a
sed -ri 's/.*swap.*/#&/' /etc/fstab

echo "=== Set hostname ==="
hostnamectl set-hostname $(hostname)

echo "=== Install nfs-common (for nfs pv) ==="
apt install -y nfs-common

echo "=== Reload systemd ==="
systemctl daemon-reload

echo "=== Start services ==="
systemctl enable --now cri-docker.socket
systemctl enable --now cri-docker.service
systemctl enable --now kubelet.service
systemctl enable --now kube-proxy.service
systemctl restart kubelet.service
systemctl restart kube-proxy.service

echo "=== Status ==="
systemctl status cri-docker.socket
systemctl status cri-docker.service
systemctl status kubelet.service
systemctl status kube-proxy.service

echo "=== Logs ==="
journalctl -f -u kubelet

执行：

1
2
3
4
5


# 在 worker 上
bash worker.sh worker1

# 在 master1 上
bash /data/softs/join_k8s.sh worker1

1.3 验证

1
2


kubectl get node
# worker1 应该出现在列表中，STATUS 从 NotReady 变 Ready

2. 之前装过 kubeadm 的 worker 清理

kubeadm reset 是最干净的清理方式（如果还装在系统里）：

1
2


# 如果 kubeadm 还在
kubeadm reset

如果 kubeadm 已经删了，需要手动清：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


# 卸载相关包
sudo yum remove -y kubeadm kubectl kubelet kubernetes-cni kube*
sudo yum autoremove -y

# Ubuntu
sudo apt-get purge kubeadm kubectl kubelet kubernetes-cni kube*
sudo apt-get autoremove

# 清残留
rm -rf ~/.kube
rm -rf /var/lib/kube*
systemctl stop kubelet.service
systemctl stop kube-proxy.service
systemctl disable kubelet.service
systemctl disable kube-proxy.service

# 清 iptables 规则（kubeadm 会留下）
iptables -F
iptables -t nat -F
iptables -t mangle -F
iptables -X

再走"全新 worker"流程。

3. 常见坑

3.1 日志采集不到

1
2
3


failed to tail file, stat failed
stat /var/log/pods/kube-system_calico-node-95qkq_d7cbeb3d-5f17-40b9-bbb4-6e4cdb04a42e/calico-node/0.log:
no such file or directory

原因：docker 改过数据目录路径（比如 data-root）。

解决：改回 /var/lib/docker 或者把 journalctl 改用 journal 模式（不依赖文件）。

临时方案：删 calico-node Pod，让它自动重建：

1

kubectl delete pod -n kube-system -l k8s-app=calico-node

3.2 kubelet 启动报 `kubelet.go:2286] "Error updating node status"`

通常是 node IP 选错（多网卡场景）。在 kubelet-conf.yml 加：

1

nodeIP: <固定 IP>

3.3 `kubelet: failed to create kubelet: cgroup driver "cgroupfs" is different from docker "systemd"`

Docker cgroupDriver 与 kubelet 不一致：

1
2
3


{
 "exec-opts": ["native.cgroupdriver=systemd"]
}

1

systemctl restart docker

3.4 `kubelet: failed to start ContainerManager ... cgroup ... not found`

swap 没禁，或 cgroup 子系统没加载：

1
2
3
4


swapoff -a
# 加载内核模块
modprobe br_netfilter
modprobe ip_vs

3.5 `kubelet.go:1380] "Failed to start cAdvisor" ... Failed to get cgroup stats`

cgroup v2 内核与 cadvisor 不兼容。降级到 cgroup v1：

1
2
3
4
5
6


# 启动参数加 systemd.unified_cgroup_hierarchy=0
# /etc/default/grub
GRUB_CMDLINE_LINUX="systemd.unified_cgroup_hierarchy=0"

update-grub
reboot

3.6 `kubelet: node "<name>" not found`

node 没注册到 apiserver。检查：

1
2
3
4


kubectl get csr
# 应该有 Pending 的 CSR（worker 发出的证书请求）

kubectl certificate approve <csr-name>

3.7 容器启动后立即退出

1
2
3


kubectl describe pod <pod>
# Events 里有 "Back-off pulling image" / "Failed to pull image"
# 解决：检查 docker daemon.json 的 insecure-registries + imagePullSecrets

3.8 节点 NotReady

1
2
3
4
5
6
7


kubectl describe node <name>
# Conditions：
# Ready False
# NetworkUnavailable True（calico 没装）
# MemoryPressure False
# DiskPressure False
# PIDPressure False

NetworkUnavailable = calico DaemonSet 还没起来，重启一下。

3.9 节点 Ready 但 Pod 起不来

1

kubectl get events -A | grep -i error

常见：calico-kube-controllers CrashLoopBackOff → 重新 apply calico.yaml。

4. 缩容

如果要把 worker 退出集群：

1
2
3
4
5
6


# 驱逐 Pod
kubectl drain <node> --ignore-daemonsets --delete-emptydir-data
# 标记不可调度
kubectl cordon <node>
# 删除节点
kubectl delete node <node>

worker 上清理：

1
2
3
4
5
6
7
8
9


systemctl stop kubelet
systemctl stop kube-proxy
systemctl disable kubelet
systemctl disable kube-proxy

rm -rf /etc/kubernetes
rm -rf /var/lib/kubelet
rm -rf /usr/local/bin/kubelet
rm -rf /usr/local/bin/kube-proxy

5. 实战：worker10 加入（带坑排查）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# 1. SSH 免密
sshpass -p <YOUR_SSH_PASSWORD> ssh-copy-id -o StrictHostKeyChecking=no worker10

# 2. 跑一键脚本
bash join_k8s.sh worker10

# 3. 在 worker10 上启动
bash worker.sh

# 4. 等 30 秒
kubectl get node
# worker10 出现

日志采不到 → 删 calico-node 让它重建。

6. 小结

节点扩容 / 缩容看似简单，但隐藏的坑很多：

全新机器 走 join_k8s.sh + worker.sh 一键脚本
kubeadm 残留 必须 kubeadm reset 或手动清包 + iptables
calico-node CrashLoopBackOff 删 Pod 重建最省事
cgroup driver 一致 是节点 Ready 的前提
cgroup v2 K8s 1.24 之前需要 systemd.unified_cgroup_hierarchy=0

下一步：[cert-manager 1.13 自动证书管理 + Ingress TLS 自动化](/p/k8s-cert-manager-zi dong-zhengshu-guanli-ingress-tls-zidonghua/)。

K8s 集群升级与卸载：版本升级 + finalizers 清理

Fri, 15 Nov 2024 00:00:00 +0800

升级 vs 卸载

K8s 集群"生命周期"两个最复杂的操作：

升级：小版本（1.28.5 → 1.28.8）可以"无脑"替换二进制；大版本（1.28 → 1.29）要看组件参数变化
卸载：彻底清掉所有 master / worker 上的 K8s 文件、systemd 单元、容器运行时、证书

适用版本：升级 1.28.5 → 1.28.8 / 卸载 K8s 1.28.5

1. 升级策略

1.1 大版本 vs 小版本

小版本升级（patch 1.28.x → 1.28.y）：只换二进制 + 重启组件
次版本升级（1.28 → 1.29）：要关注 deprecated API（如 policy/v1beta1）、CRD schema 变化、组件 flag 变化
大版本升级（1.x → 2.x）：官方不支持，必须重装

1.2 升级顺序

1

master1 → master2 → master3 → worker1 → worker2 → ... → workerN

etcd 先升，K8s 控制面组件（apiserver → controller-manager → scheduler）后升，最后 worker。

1.3 当前环境

组件	当前	目标
etcd	v3.5.11	3.5.13
kubernetes-server	1.28.5	1.28.8
coredns	1.29.0	1.29.0（不动）

2. 升级 etcd

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


# 备份
mkdir -p /data/etcd-bak
etcdctl snapshot save /data/etcd-bak/etcd-snapshot-$(date +%Y%m%d).db

# 停 etcd
systemctl stop etcd.service
mv /usr/local/bin/etcd* /data/etcd-bak/

# 装新版本
cd /data/softs
tar -xf etcd-v3.5.13-linux-amd64.tar.gz
mv etcd-v3.5.13-linux-amd64/etcd /usr/local/bin/
mv etcd-v3.5.13-linux-amd64/etcdctl /usr/local/bin/
mv etcd-v3.5.13-linux-amd64/etcdutl /usr/local/bin/

# 同步到其他 master
for NODE in master2 master3; do
 ssh $NODE "mv /usr/local/bin/etcd* /data/etcd-bak/"
 scp /usr/local/bin/etcd* $NODE:/usr/local/bin/
done

# 启动
systemctl start etcd.service
etcdctl version
# etcdctl version: 3.5.13

3. 升级 K8s 控制面

3.1 升级 master1

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


# 备份
mkdir -p /usr/local/bin/bak
mv /usr/local/bin/kube{let,ctl,-apiserver,-controller-manager,-scheduler,-proxy} /usr/local/bin/bak

# 装新版本
cd /data/softs
tar -xf kubernetes-server-linux-amd64.tar.gz \
 --strip-components=3 \
 -C /usr/local/bin \
 kubernetes/server/bin/kube{let,ctl,-apiserver,-controller-manager,-scheduler,-proxy}

# 重启所有 master 组件
systemctl restart kube-apiserver.service
systemctl restart kube-controller-manager.service
systemctl restart kube-scheduler.service
systemctl restart kubelet.service
systemctl restart kube-proxy.service

# 验证
kubectl get node
# master1 应该还是 Ready，但 VERSION 还是 1.28.5（只有 etcd 那台没升时）

3.2 升级 master2 + master3

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


for NODE in master2 master3; do
 echo "=== $NODE ==="
 ssh root@$NODE "mkdir -p /usr/local/bin/bak && \
 mv /usr/local/bin/kube{let,ctl,-apiserver,-controller-manager,-scheduler,-proxy} /usr/local/bin/bak"
 scp /usr/local/bin/kube{let,ctl,-apiserver,-controller-manager,-scheduler,-proxy} \
 $NODE:/usr/local/bin/
 ssh root@$NODE "systemctl restart kube-apiserver.service && \
 systemctl restart kube-controller-manager.service && \
 systemctl restart kube-scheduler.service && \
 systemctl restart kubelet.service && \
 systemctl restart kube-proxy.service"
done

3.3 升级 worker

1
2
3
4
5
6
7
8


for NODE in worker1 worker2 worker3 worker4 worker5 worker6 worker7 worker8 worker9; do
 echo "=== $NODE ==="
 ssh root@$NODE "mkdir -p /usr/local/bin/bak && \
 mv /usr/local/bin/kube{let,-proxy} /usr/local/bin/bak"
 scp /usr/local/bin/kube{let,-proxy} $NODE:/usr/local/bin/
 ssh root@$NODE "systemctl restart kubelet.service && \
 systemctl restart kube-proxy.service"
done

3.4 验证

1
2


kubectl get node
# 全部 Ready，VERSION 显示 1.28.8

4. 升级时的节点隔离

升级 master 时要先把 master 标记不可调度（避免新 Pod 调度到正在重启的 master）：

1
2
3
4
5
6
7
8


# 隔离
kubectl cordon master1
kubectl drain master1 --delete-local-data --ignore-daemonsets --force
systemctl restart kube-apiserver.service
# ...

# 恢复
kubectl uncordon master1

drain 驱逐所有非 DaemonSet Pod 到其他节点。--delete-emptydir-data 允许删除 emptyDir 类型数据（一般安全）。

5. 卸载 K8s 集群

5.1 停服务顺序

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 1. 停所有 K8s 服务
systemctl status kube-apiserver.service
systemctl status kube-controller-manager.service
systemctl status kube-scheduler.service
systemctl status kubelet.service
systemctl status kube-proxy.service

# 停
systemctl stop kube-apiserver.service
systemctl disable kube-apiserver.service
# ... 同上其他

5.2 删 systemd 单元

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


rm -rf /etc/systemd/system/kube-apiserver.service
rm -rf /etc/systemd/system/multi-user.target.wants/kube-apiserver.service
rm -rf /etc/systemd/system/kube-controller-manager.service
rm -rf /etc/systemd/system/multi-user.target.wants/kube-controller-manager.service
rm -rf /etc/systemd/system/kube-scheduler.service
rm -rf /etc/systemd/system/multi-user.target.wants/kube-scheduler.service
rm -rf /etc/systemd/system/kubelet.service
rm -rf /etc/systemd/system/multi-user.target.wants/kubelet.service
rm -rf /etc/systemd/system/kube-proxy.service
rm -rf /etc/systemd/system/multi-user.target.wants/kube-proxy.service
rm -rf ~/bootstrap
systemctl daemon-reload

5.3 删目录

1
2
3
4
5
6
7


rm -rf /etc/kubernetes
rm -rf /usr/local/bin/kube{let,ctl,-apiserver,-controller-manager,-scheduler,-proxy}
rm -rf /var/lib/kubelet
rm -rf /var/log/kubernetes
rm -rf /etc/cni/net.d
rm -rf /root/.kube
rm -rf ~/bootstrap/bootstrap.secret.yaml

5.4 清环境变量

1
2
3
4
5
6


# 临时
unset KUBECONFIG

# 永久
sudo sed -i '/KUBECONFIG/d' /etc/profile ~/.bashrc ~/.profile
source ~/.bashrc

5.5 停 etcd

1
2
3
4
5
6
7
8


systemctl status etcd.service
systemctl stop etcd.service
systemctl disable etcd.service
rm -rf /etc/systemd/system/etcd.service
rm -rf /usr/local/bin/etcd*
rm -rf /etc/etcd
rm -rf /var/lib/etcd
systemctl daemon-reload

5.6 停容器运行时

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


# 停所有 docker 相关
systemctl stop docker.service
systemctl disable docker.service
systemctl stop cri-docker.socket
systemctl disable cri-docker.socket
systemctl stop cri-docker.service
systemctl disable cri-docker.service
systemctl stop containerd.service
systemctl disable containerd.service

# 删 systemd 单元
rm -rf /etc/systemd/system/{docker.service,docker.socket,cri-docker.service,cri-docker.socket,containerd.service}
rm -rf /etc/docker
rm -rf /usr/local/bin/{containerd*,docker*,runc,cri-dockerd,ctr}
rm -rf /var/lib/docker
rm -rf /var/lib/containerd
rm -rf /run/cri-dockerd.sock
rm -rf /var/run/docker.sock

systemctl daemon-reload

5.7 其他清理

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# 网络（IPIP 模式 / CNI）
modprobe -r ipip 2>/dev/null
ip link delete tunl0 2>/dev/null
rm -rf /opt/cni/bin
rm -rf /var/lib/cni
rm -rf /var/lib/calico 2>/dev/null

# bootstrap 目录
rm -rf ~/bootstrap

# 历史镜像
docker system prune -af 2>/dev/null

5.8 验证

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 进程
ps -ef | grep -E "kube|etcd|docker|containerd" | grep -v grep
# 应当空

# 端口
ss -tlnp | grep -E "6443|2379|2380|10250|10251|10252|10255"
# 应当空

# 残留目录
ls /usr/local/bin | grep -E "kube|etcd|containerd|docker"
# 应当空

6. namespace 卡 Terminating 终极清理

卸载过程中如果 namespace 一直卡 Terminating（典型场景：Rook-Ceph、cert-manager）：

1
2
3
4
5


# 通用方法
ns=rook-ceph
kubectl get namespace $ns -o json | jq '.spec = {"finalizers":[]}' > temp.json
curl -k -H "Content-Type: application/json" -X PUT \
 --data-binary @temp.json 127.0.0.1:8001/api/v1/namespaces/$ns/finalize

或：

1

kubectl patch ns rook-ceph --type=merge -p '{"metadata":{"finalizers":null}}'

但要先启动 kubectl proxy：

1

kubectl proxy &

6.1 PVC 卡 Terminating

1
2
3
4


kubectl patch pvc jenkins-agent-pvc -n kube-ops --type=merge -p '{"metadata":{"finalizers":null}}'

kubectl patch pv pvc-c87554c7-6b20-42ed-8cdd-8be1d630a744 \
 -p '{"metadata":{"finalizers":null}}' --type=merge

6.2 Pod 卡 Terminating

1
2
3
4


kubectl patch pod nacos-0 -n safety-xjprod \
 --type=merge -p '{"metadata":{"finalizers":null}}'

kubectl delete po <pod> -n <ns> --grace-period=0 --force

6.3 后台强删 namespace

1
2


nohup kubectl delete ns cattle-impersonation-system --grace-period=0 --force > /dev/null 2>&1 &
nohup kubectl delete ns cattle-system --grace-period=0 --force > /dev/null 2>&1 &

6.4 KubeSphere 等第三方组件

1
2
3
4
5
6
7
8
9


# 看 CRD
kubectl get crd,clusterrole,clusterrolebinding | grep kubesphere

# 删 cluster CRD
kubectl edit crd clusters.cluster.kubesphere.io
# 删 metadata.finalizers 保存

# 后台删 namespace
nohup kubectl delete namespace kubesphere-system --force --grace-period=0 > /dev/null 2>&1 &

7. 排错速查

现象	原因	解决
升级后 `kubectl get node` 仍是旧版本	部分 master 没升完	检查每台 master 的 `kubelet --version`
`etcdctl: this member is not a leader`	etcd 升级没让 leader 先升	先升 leader，重启会自动选主
`kubectl drain` 报 “cannot delete Pods using local storage”	用了 local PV	加 `--delete-emptydir-data --force`
卸载后 `kubelet` 还在	daemon-reload 没跑	跑 `systemctl daemon-reload` 再 `systemctl reset-failed`
节点还在 cluster 里	`kubectl delete node` 没跑	`kubectl delete node <name>`

8. 小结

升级 / 卸载是 K8s 集群"压箱底"操作：

小版本升级 只换二进制，2 分钟一台
卸载顺序：停服务 → 删单元 → 删目录 → 清环境变量
finalizers 是 namespace 卡死的最常见原因，patch 一下就解决
保留备份（etcd snapshot、admin.kubeconfig）永远不亏

下一步：K8s 节点扩容：worker 加入集群一键脚本。

Watchtower 容器自动更新：守护所有容器的升级

Sat, 15 Jun 2024 00:00:00 +0800

Docker 镜像升级是日常运维里最烦又最不能不做的事——CVE 漏洞、版本过期、安全审计都要求镜像保持最新。Watchtower 把这件"每月手动 docker pull + restart"的事自动化：它会按周期拉取镜像、检查新版本、自动重启容器。

阅读对象：管 5+ 容器实例的运维 / DevOps 覆盖范围：Watchtower 基础用法 + 选择性更新 + 标签筛选 + 远程仓库认证 + 远程主机升级 + 定时调度 + 监控日志

一、为什么需要 Watchtower

手动升级 Docker 容器的痛点：

CVE 爆出 → 需要紧急升级 nginx → 10 台机器挨个 pull + restart
测试环境新版本发布 → 手动改 5 个 compose 文件
半夜收到 Prometheus 告警 → 紧急 docker pull redis:7.2-alpine

Watchtower 本质：把"定期升级"做成可调度、可过滤、可观测的 cron 任务。

When to use：

测试 / 预发环境镜像更新（强烈推荐）

内部工具的镜像（推荐）

生产环境（谨慎使用，建议灰度 + 人工 confirm）

不适用：需要特殊启动参数 / 一次性初始化（如数据库迁移）的镜像——升级可能丢数据。

二、最小化启动

1
2
3
4
5
6


docker run -d \
 --name watchtower \
 --restart always \
 -v /var/run/docker.sock:/var/run/docker.sock \
 containrrr/watchtower \
 -c

参数说明：

-v /var/run/docker.sock：必须挂载，Watchtower 通过 Docker API 操作其他容器
-c / --cleanup：升级后自动删除旧镜像——避免磁盘满

启动后 Watchtower 默认 每 5 分钟轮询一次所有运行容器的镜像，看是否有新版本。

三、选择性更新

只升级特定容器，避免 Watchtower 动到不该动的：

1
2
3
4
5
6
7


docker run -d \
 --name watchtower \
 --restart always \
 -v /var/run/docker.sock:/var/run/docker.sock \
 containrrr/watchtower \
 -c \
 nginx redis mysql

nginx redis mysql 是容器名列表——只升级这几个，其他的不动。

3.1 通过文件列表更新

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


# 1. 创建列表
cat > ~/.watchtower.list <<'EOF'
aria2-pro
unlockmusic
mtg
nginx
EOF

# 2. 启动
docker run -d \
 --name watchtower \
 --restart always \
 -v /var/run/docker.sock:/var/run/docker.sock \
 -v /root/.watchtower.list:/root/.watchtower.list:ro \
 containrrr/watchtower \
 -c \
 $(cat ~/.watchtower.list)

好处：增删容器名只改文件，不用重启 Watchtower。

四、排除特定容器

给容器加 label com.centurylinklabs.watchtower.enable=false，Watchtower 会自动跳过：

1
2
3
4
5
6
7
8


docker run -d \
 --name openwrt-mini \
 --restart always \
 --network openwrt \
 --privileged \
 --label com.centurylinklabs.watchtower.enable=false \
 p3terx/openwrt-mini \
 /sbin/init

反向操作：watchtower 只升级显式标记的容器，其他一律不管。

启动 Watchtower 时加 --label-enable：

1
2
3
4
5
6


docker run -d \
 --name watchtower \
 --restart unless-stopped \
 -v /var/run/docker.sock:/var/run/docker.sock \
 containrrr/watchtower -c \
 --label-enable

启动容器时加 --label com.centurylinklabs.watchtower.enable=true：

1
2
3
4
5


docker run -d \
 --name my-critical-app \
 --restart always \
 --label com.centurylinklabs.watchtower.enable=true \
 myapp:latest

五、调度频率

5.1 间隔模式

1
2
3
4
5
6
7


# 每 3600 秒（1 小时）检查一次
docker run -d \
 --name watchtower \
 --restart unless-stopped \
 -v /var/run/docker.sock:/var/run/docker.sock \
 containrrr/watchtower -c \
 --interval 3600

5.2 Cron 模式

1
2
3
4
5
6
7


# 每天凌晨 2 点检查
docker run -d \
 --name watchtower \
 --restart unless-stopped \
 -v /var/run/docker.sock:/var/run/docker.sock \
 containrrr/watchtower -c \
 --schedule "0 0 2 * * *"

注意：Watchtower 的 cron 是 6 位（秒分时日月周），比传统 cron 多 1 位秒。

六、私有 Registry 认证

公司用 Harbor 时，Watchtower 升级私有镜像需要认证：

1
2
3
4
5
6
7
8
9


docker run -d \
 --name watchtower \
 --restart always \
 -e REPO_USER=admin \
 -e REPO_PASS={{REDACTED}} \
 -v /var/run/docker.sock:/var/run/docker.sock \
 containrrr/watchtower \
 -c \
 base

环境变量 REPO_USER / REPO_PASS 会被 Watchtower 用于 docker login Harbor。

更安全的做法：用 ~/.docker/config.json 挂载：

1
2
3
4
5
6
7
8


docker run -d \
 --name watchtower \
 --restart always \
 -v /root/.docker/config.json:/config.json \
 -e REPO_USER=$(jq -r .auths."dockerhub.example.com".auth /config.json | base64 -d | cut -d: -f1) \
 -e REPO_PASS=$(jq -r .auths."dockerhub.example.com".auth /config.json | base64 -d | cut -d: -f2) \
 -v /var/run/docker.sock:/var/run/docker.sock \
 containrrr/watchtower

七、远程主机升级

通过 DOCKER_HOST 环境变量，让本机 Watchtower 升级远程机器的容器：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


docker run -d \
 --name watchtower \
 --restart always \
 -e REPO_USER=admin \
 -e REPO_PASS={{REDACTED}} \
 -e DOCKER_HOST="tcp://203.0.113.10:2375" \
 -v /var/run/docker.sock:/var/run/docker.sock \
 containrrr/watchtower \
 -c \
 base

前提：远程机器的 Docker daemon 监听 0.0.0.0:2375。

生产强烈推荐 TLS（tcp://host:2376 + CA 证书），避免 2375 明文端口被扫到。

八、手动触发更新

偶尔需要立即升级某容器（不等调度），用 --run-once：

1
2


docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
 containrrr/watchtower -cR aria2-pro

参数：

-c：清理旧镜像
-R / --run-once：跑一次就退出，不进入常驻守护模式

适用场景：

CVE 紧急升级
调试时反复升级测
一次性升级指定容器

九、监控与日志

9.1 看实时日志

1

docker logs -f watchtower

输出示例：

1
2
3
4


time="2024-06-15T03:00:00Z" level=info msg="Found new redis:7.2-alpine image"
time="2024-06-15T03:00:01Z" level=info msg="Stopping /running redis (abc123)"
time="2024-06-15T03:00:05Z" level=info msg="Creating /running redis (def456)"
time="2024-06-15T03:00:10Z" level=info msg="Updated container redis"

9.2 接入 Loki / ELK

1
2
3
4
5
6
7
8
9


docker run -d \
 --name watchtower \
 --restart always \
 -v /var/run/docker.sock:/var/run/docker.sock \
 --log-driver=loki \
 --log-opt loki-url="http://internal.example.com:3100/loki/api/v1/push" \
 --log-opt max-size="50m" \
 --log-opt max-file="10" \
 containrrr/watchtower

告警规则（Loki + Grafana）：

1
2


# 升级失败告警
{job="watchtower"} |= "level=error"

9.3 Prometheus 指标（通过 cAdvisor）

Watchtower 自身不暴露 metrics 端点，但它操作的容器被 cAdvisor 抓取——可以看每个容器重启次数。

十、典型坑位

10.1 Watchtower 自己被升级

症状：Watchtower 升级自己时失败，陷入死循环。

修复：给 Watchtower 加 disable label：

1
2
3
4
5
6
7


docker run -d \
 --name watchtower \
 --restart always \
 --label com.centurylinklabs.watchtower.enable=false \
 -v /var/run/docker.sock:/var/run/docker.sock \
 containrrr/watchtower \
 -c

或者用 --label-enable 模式 + 给所有其他容器显式 enable。

10.2 升级后容器启动失败

症状：Watchtower 升级 redis:7.2 → 7.4，但 7.4 改了配置文件路径，容器启动失败。

修复：升级前在测试环境验证；或者用 --no-restart 模式只下载不重启：

1
2
3
4
5


docker run -d \
 --name watchtower \
 -v /var/run/docker.sock:/var/run/docker.sock \
 containrrr/watchtower \
 --no-restart

人工确认升级后的容器能起来，再 docker restart。

10.3 数据库容器被升级丢数据

症状：MySQL 8.0.36 → 8.4 自动升级，数据文件结构不兼容，启动报错。

修复：永远别让 Watchtower 自动升级数据库——给 mysql / postgres / mongodb 容器加 disable label。

10.4 大量容器同时升级

症状：20 个容器同时重启，业务抖动 30 秒。

修复：分批升级——用容器名列表分多个 Watchtower：

1
2
3
4
5
6
7


# Watchtower 1：升级 nginx / redis
docker run -d --name wt-frontend -v /var/run/docker.sock:/var/run/docker.sock \
 containrrr/watchtower -c nginx redis --schedule "0 0 2 * * *"

# Watchtower 2：升级 backend
docker run -d --name wt-backend -v /var/run/docker.sock:/var/run/docker.sock \
 containrrr/watchtower -c api worker scheduler --schedule "0 30 2 * * *"

十一、生产级建议

11.1 灰度升级

1
2
3
4
5
6
7
8


# 1. 升级 1 台机器（canary）
DOCKER_HOST=tcp://host-1:2375 watchtower -cR --run-once api

# 2. 监控 5 分钟无异常
# 3. 批量升级其他机器
for host in host-2 host-3 host-4; do
 DOCKER_HOST=tcp://$host:2375 watchtower -cR --run-once api
done

11.2 升级前快照

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


# 1. 升级前 commit 当前容器为镜像
docker commit api api:pre-upgrade-backup

# 2. 触发升级
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
 containrrr/watchtower -cR api

# 3. 监控 10 分钟

# 4. 出问题回滚
docker stop api
docker rm api
docker run -d --name api api:pre-upgrade-backup

11.3 通知集成

Slack 通知（用 [shouts](https://github.com/containrrr/shoutrrr) 库，Watchtower 内置支持）：

1
2
3
4
5
6


docker run -d \
 --name watchtower \
 -v /var/run/docker.sock:/var/run/docker.sock \
 -e WATCHTOWER_NOTIFICATIONS=shoutrrr \
 -e WATCHTOWER_NOTIFICATION_URL=slack://token@channel \
 containrrr/watchtower

支持的通知方式：Slack / Discord / Telegram / Email / Pushover / Gotify / Microsoft Teams / Mattermost / Smtp。

十二、完整生产配置示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


version: "3.8"
services:
 watchtower:
 image: containrrr/watchtower
 container_name: watchtower
 restart: always
 volumes:
 - /var/run/docker.sock:/var/run/docker.sock
 environment:
 - TZ=Asia/Shanghai
 - WATCHTOWER_LABEL_ENABLE=true  # 只升级标记的容器
 - WATCHTOWER_INCLUDE_STOPPED=false
 - WATCHTOWER_CLEANUP=true
 - WATCHTOWER_SCHEDULE=0 0 3 * * *  # 每天凌晨 3 点
 - WATCHTOWER_TIMEOUT=60s
 - REPO_USER=admin
 - REPO_PASS={{REDACTED}}
 - WATCHTOWER_NOTIFICATIONS=shoutrrr
 - WATCHTOWER_NOTIFICATION_URL=slack://{{SLACK_TOKEN}}@{{SLACK_CHANNEL}}
 labels:
 - "com.centurylinklabs.watchtower.enable=false" # 自身不升级

业务容器（要被自动升级的）：

1
2
3
4
5


services:
 nginx:
 image: nginx:1.25-alpine
 labels:
 - "com.centurylinklabs.watchtower.enable=true"

十三、Watchtower 替代方案

工具	优势	劣势
Watchtower	简单、单二进制	不支持 K8s
Diun（diun）	只通知不升级，安全首选	不自动操作
Renovate / Dependabot	适合 K8s manifest 自动 PR	需要 GitOps 体系
ArgoCD Image Updater	K8s 生态完整	K8s only

K8s 用户推荐 ArgoCD Image Updater + Renovate 组合——Watchtower 在 K8s 里不是最佳实践。

十四、安全加固清单

/var/run/docker.sock 权限最小化：默认是 root 拥有，容器挂载后相当于 root in container
加 label disable：防止 Watchtower 升级自己
数据库容器 disable：避免自动升级导致数据丢失
审计日志：所有 Watchtower 操作都进 Loki，定期回看
CVE 优先级：用 Diun + Watchtower 组合，先通知再决定升不升

2024+ 视角补充

本文写于 2024-06，2024-2026 期间容器自动更新工具演进：

Watchtower 1.7+（2024）：Podman 原生支持（除 Docker 外）；OCI 1.1+ 镜像清单；HTTP API（查询 / 触发 / 状态）；Healthcheck endpoint
Diun 4.x（2024-2025）：仍是 “只通知不升级” 首选——配合 Watchtower 是稳态组合
Renovate / Dependabot 2024+：K8s manifest 自动 PR 仍是 GitOps 体系推荐
ArgoCD Image Updater 0.13+：K8s 自动化 + GitOps 黄金组合
K8s 场景新选择：Keel.sh（轻量 Deployment 自动滚动）；Pulumi + Kubernetes Operator
OrbStack / Docker Desktop 5.x：本地开发环境已经内置自动更新检测

实战建议（2025-2026 视角）：

Docker 单机 / VM → Watchtower + Diun 仍是首选
K8s → ArgoCD Image Updater + Renovate 黄金组合
企业合规 → Diun 通知 + 人工审核 + 灰度（不要让 Watchtower 自动升级生产数据库）
新趋势：AI 辅助 CVE 评估（如 Snyk / Aikido）——自动判断镜像升级是否引入 breaking change

下一步

想看 VPN 与代理自托管（OpenVPN / V2Ray）→ VPN 与代理自托管
想看 站点与博客自托管（WordPress / WVP 视频监控）→ 站点与博客自托管
想看 Vaultwarden 密码管理（Bitwarden 自托管）→ Vaultwarden 密码管理
想看 MinIO 对象存储实战（S3 兼容对象存储）→ MinIO 对象存储实战

Windows 系统管理员实战：远程桌面、SNMP 监控、注册服务与 winget 时代工具链

Thu, 15 Dec 2022 00:00:00 +0800

一、为什么 Windows 系统配置仍然是"必备技能"

很多人以为 Windows “开箱即用"不需要管，但对真正在企业环境里维护 Windows Server 的人来说，“装好之后还要改的东西"远比装系统本身多：

远程桌面授权到期，全员登不上；
自研 exe 想常驻，注册成系统服务；
SNMP 装好但"安全"标签页没出来；
C 盘一年没清，几个 G 的 Hiberfil.sys 默默躺在那；
包管理器从零散的 .msi 下载到 winget 一行命令；
终端代理怎么设、命令行怎么拉起 Python 解释器。

本文把 6 类高频场景串成一份可对照操作的速查手册，全部基于 PowerShell 7 + Windows 10/11/Server 2019+。

二、远程桌面：复制失效 & 授权到期

2.1 远程无法互相复制文件

远程桌面里"复制粘贴"突然失效，最常见的原因是 rdpclip.exe 进程挂了。

1
2


# 在远程主机上任务管理器 → 结束 rdpclip.exe
# 然后 Win+R → 运行 rdpclip.exe 重启

或者一行 PowerShell：

1
2


Get-Process rdpclip -ErrorAction SilentlyContinue | Stop-Process -Force
Start-Process rdpclip

2.2 远程授权到期：“由于没有远程桌面授权服务器可以提供许可证，远程会话连接已断开”

Server 默认 120 天宽限期，过期后管理员也无法登录。应急办法：用 /admin 模式强制登录一次，然后清理注册表里的宽限期记录。

1
2


# 强制登录（用 /admin 而非 /console，2012 R2 之后 console 已废弃）
mstsc /admin /v:internal.example.com

注：internal.example.com 在此仅作占位，请替换为实际服务器地址。

登录后清理授权记录（可重置回 120 天）：

1
2
3
4
5
6
7


1. 打开注册表 regedit
2. 进入 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM\GracePeriod
3. 右键 GracePeriod → 权限 → 高级
4. 所有者 → 更改 → 高级 → 立即查找 → 选择 Administrators → 确定
5. 审核 → 添加 → 主体：Administrators → 勾选安全控制
6. 回到 GracePeriod 权限 → Administrators 勾选安全控制
7. 删除 REG_BINARY → 重启

此方法可继续使用 120 天，过期后再次按此操作。这是临时续命方案，长期请部署正式的 RD Licensing 服务器。

三、可执行程序注册为系统服务

3.1 nssm：最省心的方案

下载 nssm（建议 2.24+），把 nssm.exe 加入 PATH：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


# 安装服务
nssm install 服务名

# 编辑已存在服务
nssm edit 服务名

# 删除服务
nssm remove 服务名 confirm

# 安装 + 启动 + 设自启（一气呵成）
nssm install MyApp "C:\apps\myapp.exe" "--config C:\apps\config.yaml"
nssm set MyApp AppDirectory "C:\apps"
nssm set MyApp AppStdout "C:\apps\logs\stdout.log"
nssm set MyApp AppStderr "C:\apps\logs\stderr.log"
nssm set MyApp Start SERVICE_AUTO_START
net start MyApp

nssm install 会弹出 GUI 让你填：

Application 路径（你的 exe）
Startup directory
Arguments
I/O 重定向（Logs tab 里把 stdout/stderr 重定向到文件，没配这个进程挂了根本查不到原因）
Restart behavior（默认是"应用退出时不重启”，要改成"On exit"或"On failure"并设重试次数）

比写 sc.exe 命令或 unit 文件简单一个量级，特别适合把 jar、bat、PowerShell 脚本注册成服务。

3.2 PowerShell 原生方式（无 GUI，适合脚本化）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 把可执行文件注册为服务（需要管理员）
New-Service -Name "MyService" `
 -BinaryPathName "C:\apps\myapp.exe --config C:\apps\config.yaml" `
 -DisplayName "My Application" `
 -StartupType Automatic

# 启动
Start-Service MyService

# 设置失败时自动重启（sc.exe 的 failureflag 命令，PowerShell 里没有原生命令）
sc.exe failure "MyService" reset= 60 actions= restart/5000/restart/10000/restart/30000

nssm 优势是自带"应用崩溃自动重启 + 日志重定向”；纯 New-Service 想要这些得自己写恢复脚本。

四、SNMP 监控：装、配置、安全选项丢失、接监控平台

SNMP 在企业网管里出场率仍然很高。Windows Server 装 SNMP 后，“安全"标签页丢失是经典坑。

4.1 完整安装流程

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


# 查询是否已安装
Get-WindowsCapability -Online -Name "SNMP*"
# State: NotPresent 表示未安装
Get-WindowsCapability -Online -Name "WMI-SNMP-Provider.Client~~~~0.0.1.0"

# 安装 SNMP 客户端
Add-WindowsCapability -Online -Name "SNMP.Client~~~~0.0.1.0"

# 安装 WMI SNMP Provider
Add-WindowsCapability -Online -Name "WMI-SNMP-Provider.Client~~~~0.0.1.0"

# 安装 RSAT-SNMP（含管理工具，Server 才有这个 Feature）
Install-WindowsFeature RSAT-SNMP

4.2 修复"安全"选项卡丢失

安装完成后刷新一下组策略：

1

gpupdate /force

如果还不行就重启。重启后用管理员身份打开 services.msc，右键 SNMP Service → 属性，应该能看到"安全"标签页，可配置 community（v2c）或用户名（v3）。

4.3 用 Apache HertzBeat 接入 Windows 监控

HertzBeat（Apache 顶级项目，2022-11 毕业）是国产开源的监控告警平台，支持 SNMP 直接拉取 Windows 指标。

被监控端（Windows）：

按 4.1 装好 SNMP + WMI Provider
services.msc → SNMP Service → 属性 → 安全
添加 community：public（v2c 测试用，生产请改复杂字符串）
接受来自指定 NMS 服务器的 SNMP 包

监控端（HertzBeat）：

登录 HertzBeat Web 控制台
监控中心 → 新增 → 操作系统 → Windows
填主机名/IP、SNMP 版本（v2c）、community、采集间隔（默认 60s）
启用模板：hostName、uptime、cpu、memory、disk、interface
提交后等 1-2 个采集周期，Dashboard 即可看到数据

HertzBeat 相比 Zabbix 的优势是配置都在 Web UI，agent 端零配置；劣势是 SNMP 指标不如 Zabbix 默认模板细。

五、文件清理：C 盘减肥必杀技

5.1 关闭休眠文件

Hiberfil.sys 占用 ≈ 物理内存大小（16G 内存 = 16G 占用）。不用休眠功能可以直接关掉：

1

powercfg -h off

关掉后立刻回收几个 G。如果以后想恢复：powercfg -h on。服务器/笔记本慎用——笔记本开盖唤醒、Server 断电恢复都依赖休眠。

5.2 虚拟内存 pagefile.sys

不建议直接删（删了会蓝屏），但可以把它从 C 盘挪到 D 盘：

1
2
3
4


系统属性 → 高级 → 性能设置 → 高级 → 虚拟内存 更改
→ 取消"自动管理" → 选 C 盘 → "无分页文件"
→ 选 D 盘 → "系统管理的大小"
→ 重启

5.3 磁盘可视化分析

SpaceSniffer（免安装、绿色软件）是看"哪个文件夹在偷空间"的利器。treemap 视图一眼就能找到几十 G 的"未知文件夹”。配合 WizTree（NTFS MFT 直读，速度比 SpaceSniffer 快一个量级）双剑合璧。

六、环境变量与代理

6.1 命令行代理

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# CMD 临时设置
set http_proxy=http://127.0.0.1:1081
set https_proxy=http://127.0.0.1:1081

# PowerShell 临时设置
$env:http_proxy = "http://127.0.0.1:1081"
$env:https_proxy = "http://127.0.0.1:1081"

# PowerShell 永久设置（用户级）
[Environment]::SetEnvironmentVariable("http_proxy", "http://127.0.0.1:1081", "User")
[Environment]::SetEnvironmentVariable("https_proxy", "http://127.0.0.1:1081", "User")

Python pip 不支持 socks5 代理。要么走 HTTP 代理，要么用 pip install --proxy=http://... 显式指定。Scoop/winget 同样走 HTTP_PROXY/HTTPS_PROXY 环境变量。

6.2 永久环境变量

1
2
3
4
5
6
7
8
9


# 用户级
[Environment]::SetEnvironmentVariable("MY_VAR", "value", "User")

# 系统级（需要管理员）
[Environment]::SetEnvironmentVariable("JAVA_HOME", "C:\Program Files\Java\jdk-17", "Machine")

# 追加到现有 PATH（而不是覆盖！）
$current = [Environment]::GetEnvironmentVariable("Path", "User")
[Environment]::SetEnvironmentVariable("Path", "$current;C:\my\bin", "User")

七、命令行工具与软件分类（2022 版）

7.1 包管理器：winget / choco / scoop 三足鼎立

2022 年 Windows 原生包管理器终于成气候了，已经不用再去 Ninite 或手动下 .msi。

工具	出品方	优势	适合
winget	微软官方（2020-05 起随 App Installer 内置）	系统自带、`msstore` 源、企业可私有源	个人日常、批量脚本
choco	Chocolatey 社区	仓库最大（9000+ 包）、成熟稳定	开发机、CI 服务器
scoop	社区	绿色安装、装在用户目录、不污染 PATH	开发者、命令行控

winget 常用命令

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


# 搜索
winget search "nodejs"

# 安装（含 msstore 源和 winget 仓库）
winget install --id Microsoft.PowerShell -e
winget install --id Git.Git -e --source winget
winget install --id Microsoft.VisualStudioCode -e

# 升级全部
winget upgrade --all

# 卸载
winget uninstall --id Git.Git

# 导出/导入（机器间同步）
winget export -o packages.json
winget import -i packages.json

winget 安装包走 Microsoft.DesktopAppInstaller_8wekyb3d8bbwe.msixbundle 这个 App Installer 内置，Windows 10 1809+ / Windows 11 默认可用，老系统手动装一下 App Installer 即可。

choco 常用命令

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# 安装（管理员 PowerShell）
Set-ExecutionPolicy Bypass -Scope Process -Force
iex ((New-Object System.Net.WebClient).DownloadString('https://community.chocolatey.org/install.ps1'))

# 改安装路径（默认 C:\ProgramData\chocolatey，SSD 小的话挪去 D 盘）
choco config set --name installLocation --value "D:\soft\choco"

# 装软件
choco install git -y
choco install vscode -y
choco install googlechrome -y

# 升级全部
choco upgrade all -y

scoop 常用命令

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# 安装（PowerShell，普通用户权限即可）
irm get.scoop.sh | iex

# 加常用 bucket
scoop bucket add extras
scoop bucket add java

# 装
scoop install git
scoop install nodejs-lts
scoop install python@3.11

# 全部升级
scoop update *

三选一建议：日常主力 winget（系统自带），开发环境额外装 scoop（绿色不污染系统），企业批量部署用 choco（成熟 + 私有源支持）。

7.2 实用工具分类速查

类别	推荐工具	用途
截屏标注	Snipaste	贴图截图、像素级标注，截图工具事实标准
终端	Windows Terminal（微软官方 2019 开源）	多 Tab + 分屏 + GPU 加速
SSH 客户端	WindTerm（2019 发布，开源免费） electerm（2017 起，跨平台）	终端 + SFTP + 端口转发一体
下载	Motrix（2019 开源，免费） IDM	多线程下载、BT/磁力
知识管理	Obsidian（2020 发布，Markdown + 双链）	本地 Markdown、插件丰富
API 调试	Apifox（国产，2020 至今） Postman	HTTP + Mock + 文档 + 团队协作
容器	Docker Desktop（2016 至今，WSL2 后端）	容器 + Kubernetes 本地集群
内网穿透	frp（2016 起，反向代理神器）	把内网服务暴露到公网
压缩	7-Zip	解压各种格式
视频	PotPlayer、OBS	播放 / 录屏
鼠标	YoloMouse	改光标样式 / 大小 / 颜色
FTP	FileZilla、WinSCP	文件传输
IDE	VS Code、IntelliJ IDEA	编码
文本	Notepad++、Sublime Text	轻量编辑
数据库	Navicat、DBeaver	多数据库 GUI
Markdown	Typora	写作

7.3 端口与进程

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


# 查 443 端口占用
netstat -aon | findstr "443"
# 最后一位是 PID

# 通过 PID 找程序
tasklist | findstr "1008"

# 通过 PID 杀进程
taskkill /f /pid 4620

# PowerShell 7 等价（更易解析）
Get-NetTCPConnection -LocalPort 443 -State Established |
 Select-Object OwningProcess, @{N='Path';E={(Get-Process -Id $_.OwningProcess).Path}}

Get-NetTCPConnection 是 PowerShell 7+ 原生命令，输出可对象化，比 netstat 字符串解析舒服得多。

八、启用 Administrator 账户

1
2
3
4
5
6
7
8


# CMD（管理员）
net user administrator /active:yes

# 设密码
net user administrator <新密码>

# 注销重新登录
shutdown -l

九、安全模式 & 定时关机

9.1 进入安全模式

1

shutdown /r /o

一分钟后弹出"选择一个选项"界面：

1

疑难解答 → 高级选项 → 启动设置 → 重启

按 F4 进入安全模式，F5 带网络的安全模式。Win10/11 时代按住 F8 进安全模式的老办法已失效。

9.2 定时关机

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 300 秒后关机
shutdown -s -t 300

# 带"我要加班"提示
shutdown -s -t 3600 -c "1 小时后自动关机，请保存文件"

# 取消
shutdown -a

# 改成重启
shutdown -r -t 300

十、常见 5 个坑

远程桌面授权过期直接用 /admin 强登，再清注册表，不要重装系统。
SNMP"安全"选项卡消失：gpupdate /force 不行就重启，不要反复重装。
powercfg -h off 后启动变慢：少量机器关掉休眠后冷启动更慢，是正常现象，因为 Windows 把休眠恢复的那部分代码也禁用了。
pip 不走 socks5 代理：socks5 代理需要先转 HTTP，或用 pip install --proxy。
mstsc 保存的密码丢了：Win10/11 RDP 凭据默认存放在"凭据管理器 → Windows 凭据"里；遇到读取失败时，先 cmdkey /list 看凭据是否还在，再用 gpedit.msc → “本地计算机策略 → 计算机配置 → 管理模板 → Windows 组件 → 远程桌面服务 → 设备与资源重定向"检查是否被 GPO 禁用。

十一、总结

远程桌面问题：/admin + 注册表清理 是双保险。
注册服务：nssm > PowerShell New-Service，但 nssm 是 GUI，对自动化部署不友好。
SNMP 装好却没"安全"选项：gpupdate /force → 重启。接监控平台首选 HertzBeat（国产、UI 友好、SNMP 直拉）。
C 盘减肥：powercfg -h off 收益最大。
包管理：winget 系统自带 + scoop 绿色补充 + choco 企业批量，三件套覆盖 90% 装软件场景。
工具链：截屏 Snipaste、终端 Windows Terminal + WindTerm、下载 Motrix、知识库 Obsidian、API Apifox、容器 Docker Desktop、内网穿透 frp。

参考资料

面试软技能 + 智力题：技术之外的硬通货

Sun, 15 Dec 2019 00:00:00 +0800

本文写于 2019 年 12 月——经济下行期，面试软技能 + 智力题权重上升。

一、面试软技能清单

1.1 沟通能力

STAR 法则：Situation（情境）/ Task（任务）/ Action（行动）/ Result（结果）
用数据说话：不说"做了高并发系统"，说"支持 10 万 QPS、可用性 99.99%"
结论先行：先说结论，再说过程
听不懂就问：面试官也欣赏"敢问"的人

1.2 抗压能力

接受挑战：不回避难题
承认边界：不会就说不会，但说明学习路径
情绪稳定：不与面试官争论

1.3 学习能力

学习路径：展示如何学一项新技术
举一反三：用类比说明理解深度
总结输出：博客 / GitHub / 技术分享

1.4 团队协作

冲突处理：如何处理技术分歧
代码评审：如何给别人 review
知识传递：如何给团队培训

二、智力题分类

2.1 推理题

经典题：

蓝眼岛：岛上有蓝眼/棕眼两种人，每天傍晚有人离岛。岛主说"你们中间有蓝眼的人"，第二天所有蓝眼都离岛了，为什么？
- 解法：n=1 时自己会走（如果自己是棕眼，岛主的话无意义），所以当 n 个人时，递归 n-1 后第 n 步自己走
疯狗：村里有 50 条狗，其中若干是疯狗（不表现出任何症状），每天傍晚杀掉所有疯狗。村民不知道自己是疯狗。第几天杀完？
- 解法：第 49 天（如果有 1 条疯狗，当天就杀光；以此类推）
耳光：100 个逻辑学家围成一圈，每人头上一个数（红/蓝），能看见其他人看不见自己。每晚有人按规则打耳光。三天后耳光声响了，怎么推理？
- 解法：递归 + 公共知识

2.2 二进制问题

经典题：

毒酒问题：1000 桶酒，1 桶有毒，10 只小白鼠，24 小时找出毒酒。
- 解法：每桶编号二进制，每只老鼠喝对应位为 1 的酒。24h 后看哪几只死，二进制转十进制就是毒酒编号
砝码问题：1-100 找最重 / 最轻的多少次？
- 解法：天平分组（3 进制）
  - 找最重：1 次分 3 组
  - 找最重 + 最轻：⌈n/3⌉ 次

2.3 先手必胜

经典题：

取石子：100 个石子，每次取 1-3 个，先取必胜？
- 解法：必胜点为 4 的倍数（先手凑到 4 的倍数必胜）
翻硬币：N 枚硬币排成一行，每次翻一枚 + 邻接一枚，所有正面朝上为赢。
- 解法：分奇偶讨论

2.4 水桶问题

经典题：

3 升和 5 升：如何量出 4 升？
- 解法：3L 倒满 5L → 5L 倒掉 → 3L 倒进 5L → 再取 3L 倒满 → 5L 已有 3L 只能再装 2L → 3L 剩 1L → 5L 倒空 → 1L 倒入 5L → 再取 3L → 4L 搞定
8 升和 5 升：量出任意整数升

2.5 赛马问题

经典题：25 匹马，每次只能 5 匹比赛，最少几次找出最快的 3 匹？

解法：

6 次（无计时器）/ 5 次（有计时器）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


第 1-5 轮：5 组比赛，每组 5 匹（共 25 匹）
 → 找出每组最快的 1 匹（A1, B1, C1, D1, E1）

第 6 轮：A1, B1, C1, D1, E1 比赛
 → 排序：A1 > B1 > C1 > D1 > E1

最快的 3 匹：A1 + A2 + A3 或 B1 或 B2

- A1：确定最快
- A2：A 组第二
- A3 / B1 / B2：竞争第二、第三

A3 比 B1：需要第 6 轮 A1, B1, C1 + A2, A3, B1 比赛
 → 答案 6 次

2.6 过河/过桥

经典题：4 人过桥，1/2/5/10 分钟，最少几分钟？

解法：

1+2 过，1 回 → 3 分钟
5+10 过，2 回 → 12 分钟
1+2 过 → 2 分钟
总计 17 分钟

2.7 灯泡开关

经典题：3 个开关控制 3 个灯泡（楼下看不见楼上），只能上楼 1 次，怎么确定对应关系？

解法：

开 1 号 5 分钟 → 关 1 号 → 开 2 号 → 上楼
亮的是 2 号控制
灭但热的是 1 号控制
灭且冷的是 3 号控制

2.8 最优解问题

经典题：

撕书问题：N 页书（双面），最少多少次撕出 100 张单页？
- 解法：50 张 = 1 次（N/2 张）
煎饼排序：每次翻转前缀，最少几次排好序？

三、Java 集合类

3.1 Java 基础合集

类	作用	关键
ArrayList	动态数组	扩容 1.5x
LinkedList	双向链表	增删快，查找慢
HashMap	哈希表	JDK 8 红黑树化
ConcurrentHashMap	线程安全哈希表	CAS + synchronized
TreeMap	红黑树	有序
HashSet	基于 HashMap	O(1) 查找

3.2 经典面试追问

Q1：HashMap 为什么用红黑树而不是 AVL？

AVL 严格平衡，查询快 O(log n)
红黑树近似平衡，插入删除快（旋转少）
哈希冲突链表 > 8 时转红黑树，避免 hash 攻击退化为 O(n)

Q2：ConcurrentHashMap 1.7 vs 1.8？

1.7：Segment（16 个）+ ReentrantLock
1.8：Node + CAS + synchronized（锁粒度更细）

Q3：ArrayList vs LinkedList？

维度	ArrayList	LinkedList
随机访问	O(1)	O(n)
头部插入	O(n)	O(1)
内存占用	少	多（每个节点 2 个指针）
缓存友好	友好	不友好

四、Java IO 模型

4.1 BIO / NIO / AIO

模型	全称	适用
BIO	Blocking I/O	传统阻塞（连接数少）
NIO	Non-blocking I/O	高并发（Netty 底层）
AIO	Asynchronous I/O	异步回调（Linux 5+）

4.2 NIO 三大组件

组件	作用
Channel（通道）	双向数据通道（FileChannel / SocketChannel）
Buffer（缓冲区）	数据容器（ByteBuffer / CharBuffer）
Selector（选择器）	多路复用（一个线程管理多个 Channel）

五、MyBatis 实战

5.1 一级缓存 vs 二级缓存

维度	一级缓存	二级缓存
范围	SqlSession	Mapper（namespace）
默认开启	✓	✗（需配置）
失效	增删改 / commit / close	同 namespace 增删改

5.2 #{} vs $

#{}：预编译，? 占位符（防 SQL 注入）
${}：字符串拼接（有注入风险）

六、设计模式高频题

6.1 单例模式 8 种实现

方式	线程安全	性能	推荐
饿汉	✓	高	★★★
懒汉（同步方法）	✓	低	✗
懒汉（DCL）	✓	中	★★★★
静态内部类	✓	高	★★★★★
枚举	✓	高	★★★★★
容器式	取决于实现	-	单例池
ThreadLocal	单线程	高	线程内单例
CAS	✓	高	✗（代码复杂）

6.2 工厂模式 vs 抽象工厂

维度	工厂方法	抽象工厂
复杂度	单一产品	产品族
扩展	新增产品加新工厂	新增产品族加新工厂

6.3 代理模式

静态代理：手动写代理类
JDK 动态代理：基于接口（Proxy + InvocationHandler）
CGLIB 动态代理：基于继承（Enhancer + MethodInterceptor）

七、Netty 面试

7.1 Netty 三大特点

异步 NIO：基于 Java NIO
事件驱动：ChannelPipeline + ChannelHandler
高性能：零拷贝、内存池、无锁设计

7.2 经典面试题

Q1：Netty 的线程模型？

Reactor 单线程：所有 I/O + 业务在单线程（NIO）
Reactor 多线程：I/O 单线程 + 业务线程池
主从 Reactor 多线程：Main Reactor + Sub Reactor + 业务线程池（Netty 推荐）

Q2：Netty 的零拷贝？

堆外内存（DirectByteBuffer）
CompositeByteBuf（合并多个 buffer）
FileChannel.transferTo（sendfile 系统调用）
ByteBuf 池化（减少 GC）

Q3：Netty 的心跳机制？

IdleStateHandler：读 / 写 / 读写空闲检测
服务端定期发送 Ping + 客户端响应 Pong
超时未响应则关闭连接

八、写在最后

面试软技能要点：

STAR 法则：讲故事用情境-任务-行动-结果

数据量化：用具体数字说明成就

诚实谦逊：不懂就说不懂，承认边界

反向提问：准备 2-3 个有深度的问题

参考资料

Docker 进阶与运维：网络模式、Volume 与镜像加速实战

Thu, 20 Jun 2019 00:00:00 +0800

装好 Docker 引擎只是入门。真正决定一台主机能不能稳定跑生产容器的，是网络、存储和镜像拉取这三件事。这一篇围绕"网络模式 + 存储卷 + 镜像代理 + 常见排障"四个高频主题，把零散的运维笔记整理成可复用的参考。

阅读对象：已经能跑 docker run 的开发者、想把 Docker 用于生产环境或本地自建集群的运维同学 覆盖范围：bridge / host / none / container / 自定义网络 + Volume 生命周期 + Docker Hub / ghcr / GCR / k8s / Quay 代理 + 故障排查

一、为什么需要关注网络与存储

跑一个 hello-world 很简单，但一旦要把 Docker 真正"用起来"，就会撞到这些问题：

容器之间怎么互访？同一个 Pod 里的两个 sidecar 容器能直接 localhost 通信吗？
数据库的数据在容器里，删容器数据就没了——怎么持久化？
怎么让外部用户访问容器内的服务？
不同机器上的容器怎么互联？
国内服务器拉 Docker Hub 镜像慢到秒级超时，K8s 节点拉 CoreDNS 镜像也卡怎么办？
私有仓库（ghcr.io / gcr.io / quay.io）在国内怎么拉？

这些问题的答案，藏在网络模式、Volume、镜像代理三个核心机制里。

When to use：

单机多容器互访 → bridge / 自定义网络

容器需要"绑定宿主机端口"的高性能场景 → host 网络

强隔离、不能联网的安全沙箱 → none 网络

数据库、需要长期保存的日志 → Volume（命名卷）/ bind mount

跨主机容器互联（Swarm / k8s）→ overlay 网络（本文不展开）

国内服务器拉镜像 → 镜像代理（dockerproxy / ghcr.nju.edu.cn 等）

二、容器网络基础：docker0 网桥与 veth pair

Docker 启动时会在宿主机上创建一个叫 docker0 的虚拟网桥（默认子网 172.17.0.0/16）。所有以 bridge 模式启动的容器都会接到这张网桥上，通过这张网桥 + iptables NAT 表与宿主机通信。

可以用 ifconfig（或 ip a）看到 docker0：

1
2
3
4
5


$ ifconfig
docker0 Link encap:Ethernet HWaddr 02:42:xx:xx:xx:xx
 inet addr:172.17.0.1 Bcast:172.17.255.255 Mask:255.255.0.0
 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
 ...

核心机制（veth pair）：

容器内看到的 eth0 并不是真正的网卡，而是一对 veth pair 设备的一端
另一端放在宿主机，挂到 docker0 网桥上
数据从一端进，另一端出，等同于一根虚拟网线

可以用 brctl show（来自 bridge-utils 包）查看网桥上挂了哪些 veth：

1
2
3


$ brctl show docker0
bridge name bridge id STP enabled interfaces
docker0 8000.0242xxxxxx no vethxxxxxx

重要结论：docker0 网桥对外是不可见的，外部网络无法通过 Container-IP 直接访问容器。要让外部访问，必须做端口映射（-p 参数）。

三、四种网络模式详解

Docker 在安装时会自动创建三个网络：bridge（默认）、none、host：

1
2
3
4
5


$ docker network ls
NETWORK ID NAME DRIVER SCOPE
xxxxx bridge bridge local
xxxxx host host local
xxxxx none null local

创建容器时通过 --net / --network 指定：

模式	指定方式	核心特点	典型场景
bridge	`--net=bridge`（默认）	独立 netns，分配 IP，通过 docker0 + NAT 通信	90% 场景
host	`--net=host`	共享宿主机 netns，无独立 IP	高性能网络服务、监控 agent
none	`--net=none`	仅有 lo 回环，无任何网络	强隔离、离线批处理
container	`--net=container:NAME`	共享另一个容器的 netns	sidecar 模式紧密协作

3.1 bridge 模式（默认）

1
2
3
4
5


# 随机端口映射（大写 P）
docker run -itd --name test1 -P nginx

# 指定端口映射（小写 p）
docker run -itd --name test2 -p 44541:80 nginx

访问路径：

1

外部网络 → 宿主机 IP:宿主机端口 → iptables DNAT → 容器 IP:容器端口

可以用 iptables -t nat -vnL 看到 Docker 自动添加的 DNAT 规则：

1
2
3
4


$ iptables -t nat -vnL
Chain DOCKER (2 references)
 pkts bytes target prot opt in out source destination
 0 0 DNAT tcp -- !docker0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:44541 to:172.17.0.2:80

等价类比：bridge 模式 ≈ VMware 里的 NAT 模式——容器有独立 IP、能上网，但需要端口映射才能被外部访问。

3.2 host 模式

容器不创建自己的网卡，直接使用宿主机的 IP 和端口。

1

docker run -itd --name test-host --net=host nginx

优势：

没有 NAT 转换，性能最佳
适合需要"处理大量端口"的服务（如 nginx 反代、Kafka、Prometheus exporter）

代价：

容器与宿主机共用网络栈，端口冲突会直接报错
-p / --publish 参数被忽略，会出现 WARNING: Published ports are discarded when using host network mode

注意：host 网络驱动只支持 Linux 宿主机。Docker Desktop for Mac / Windows / Windows Server 上的 Docker 不支持 host 模式。

在 Swarm 集群里也可以使用 host 网络：

1

docker service create --network host nginx

控制流量（swarm manager 相关）仍走 overlay 网络，但 swarm 服务容器本身使用 Docker 守护进程的主机网络和端口发送数据——这意味着如果一个服务容器绑定到 80 端口，那么在给定的集群节点上只能运行一个该服务容器。

3.3 none 模式

容器有独立的 Network Namespace，但 Docker 不会给它配置任何网络。

没有 eth0、没有 IP、没有路由
只有 lo 回环网卡
完全不能上网

典型场景：安全沙箱、离线批处理任务（如敏感数据脱敏、纯计算作业）。

3.4 container 模式

新创建的容器共享指定容器的 netns，而不是和宿主机共享。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


# 查看已有容器的 PID
$ docker inspect -f '{{.State.Pid}}' 5ace523962fc
14685

# 验证 net namespace
$ ls -l /proc/14685/ns
... net -> net:[4026532649] # 就是这个 net namespace ID

# 创建新容器并共享
$ docker run -itd --name test3 --net=container:5ace523962fc centos bash

# 验证新容器的 net namespace 一致
$ docker inspect -f '{{.State.Pid}}' 2b7af7c8842d
15832
$ ls -l /proc/15832/ns
... net -> net:[4026532649] # 跟前面一样

特性：

两个容器共享 IP、端口范围
网络之外（文件系统、进程、用户）仍然隔离
两个容器的进程可以通过 lo 通信

典型场景：sidecar 模式——主容器和 sidecar 容器（如日志收集器、监控 agent、Service Mesh proxy）共用 netns，方便在 localhost 上互调。

四、自定义网络：指定 IP / 子网

直接用默认 bridge 模式，不能给容器指定固定 IP：

1
2
3


# 报错：只能在自定义网络指定 IP
$ docker run -itd --name test4 --network bridge --ip 172.17.0.5 centos:7 /bin/bash
Error response from daemon: User specified IP address is supported only when connecting to networks with user configured subnets.

正确做法：先自定义网络，再指定 IP 启动。

1
2
3
4
5
6
7
8


# 1. 创建自定义网络（指定子网 + 网卡名）
docker network create \
 --subnet=172.18.0.0/16 \
 --opt "com.docker.network.bridge.name"="docker1" \
 mynetwork

# 2. 用指定 IP 启动容器
docker run -itd --name test5 --net mynetwork --ip 172.18.0.10 centos /bin/bash

参数说明：

--subnet：定义子网范围
--opt "com.docker.network.bridge.name"="docker1"：让 ifconfig -a 看到的是 docker1，而不是 br-110eb56a0b22 这种随机名
mynetwork：网络名，docker network ls 里的 NAME 列

Why 用自定义网络：

容器 DNS 自动解析（容器名 → IP），默认 bridge 不支持
可以在创建时规划 IP 段
适合需要稳定网络拓扑的复杂部署

配套的清理命令：当自定义网络不再需要时：

1
2
3
4
5
6


# 临时把容器从指定网络断开（排查网络问题很有用）
docker network disconnect -f bridge <container_name>

# 禁用并删除 docker0 网桥
ifconfig docker0 down
brctl delbr docker0

注意：手工 brctl delbr docker0 之后，下次 daemon 启动（未指定 -b 参数）会自动重建 docker0。要真正控制默认网桥，需要在 daemon.json 里写：
1
2
3
4
{
 "iptables": false,
 "bridge": ""
}

五、存储卷（Volume）：让数据活过容器生命周期

容器的文件系统是临时的——docker rm 时容器层全部销毁。任何需要持久化的数据，都必须挂载到 Volume 或 bind mount。

5.1 Volume 操作四件套

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 创建
docker volume create mydata

# 查看
docker volume ls

# 删除单个
docker volume rm mydata

# 清理（删所有未挂载的 volume —— 危险）
docker volume prune

5.2 两种挂载方式

1
2
3
4
5


# 1. 命名卷（推荐，Docker 自动管理）
docker run -d -v mydata:/var/lib/mysql mysql:5.7

# 2. bind mount（直接挂主机目录，运维最常用）
docker run -d -v /host/path:/container/path nginx

维度	Volume	Bind Mount
路径	Docker 管理（默认 `/var/lib/docker/volumes/`）	任意宿主机路径
迁移	`docker volume` 命令一键迁移	手动 rsync
权限	Docker 自动设	手动 chmod
适用	数据库、共享数据	配置文件、日志、特殊路径

5.3 关键避坑

docker volume prune 会删所有未挂载的卷——生产环境跑这个命令之前必须 docker volume ls 确认
bind mount 时容器内 UID 与宿主机不一致会导致权限问题——用 user: "1000:1000" 显式指定
Volume 在多容器间共享非常合适（如配置中心、日志聚合），但不能用 tmpfs 替代——重启数据就没了

5.4 配合清理

1
2
3
4
5


# 只删除未使用的网络
docker network prune -f

# 删除 12 小时前创建的网络
docker network prune -a --filter "until=12h"

六、镜像代理与加速

国内服务器拉 Docker Hub 镜像默认会非常慢甚至超时。除了 daemon.json 里配 registry-mirrors，还可以直接用镜像代理拉特定 registry 的镜像。

6.1 Docker Hub 镜像代理

场景	官方命令	代理命令
用户镜像	`docker pull stilleshan/frpc:latest`	`docker pull dockerproxy.com/stilleshan/frpc:latest`
根镜像（library）	`docker pull nginx:latest`	`docker pull dockerproxy.net/library/nginx:latest`

dockerproxy.com 和 dockerproxy.net 是两个常用的镜像代理。根镜像（library/xxx）必须显式写 library/——这是和用户镜像最大的区别。

6.2 GitHub Container Registry (ghcr.io)

2019 年 9 月 GitHub 即将开放公开测试的 ghcr.io，配合 GitHub Actions 的 docker push 流程，越来越多的开源项目（包括很多 K8s 生态组件）开始把镜像推到 ghcr 而非 Docker Hub。

1
2
3
4
5


# 官方
docker pull ghcr.io/username/image:tag

# 代理
docker pull ghcr.dockerproxy.com/username/image:tag

南京大学的 ghcr 加速：ghcr.nju.edu.cn 是高校里对 ghcr 比较稳定的镜像（南大信管系维护）。速度通常比走 dockerproxy 更快，适合学术 / 教学环境。

6.3 Google Container Registry (gcr.io) 与 k8s.gcr.io

K8s 自身组件（coredns、kube-proxy、etcd 等）都托管在 k8s.gcr.io（2018 年起）或新地址 registry.k8s.io（2019 年开始迁移）。国内拉这些镜像几乎必走代理：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# GCR 官方
docker pull gcr.io/username/image:tag

# GCR 代理
docker pull gcr.dockerproxy.com/username/image:tag

# K8s 镜像（CNCF 仓库，从 k8s 1.11 开始 CoreDNS 取代 kube-dns 成为默认 DNS）
docker pull k8s.gcr.io/coredns:1.6.5
docker pull registry.k8s.io/coredns:1.6.5

# 代理
docker pull k8s.dockerproxy.com/coredns:1.6.5

CoreDNS 1.6.5 是 2019 年中比较常用的稳定版本——CNI 插件、KubeDNS 替换等场景都会用到。

6.4 Quay.io

Red Hat 系镜像（coreos/etcd 旧版本、Operator Framework 等）大多托管在 Quay：

1
2
3
4
5


# 官方
docker pull quay.io/username/image:tag

# 代理
docker pull quay.dockerproxy.com/username/image:tag

6.5 加速效果对比

1
2
3


# 测速（删本地缓存后用 time 计时）
docker rmi node:latest
time docker pull node:latest

直连 Docker Hub：~1m14s（国内典型）
用镜像代理：~5-15s（视镜像大小）

注意：公开镜像代理可能因合规或运营原因失效。生产环境建议自建 mirror（用 registry 镜像 + 反代），或者用云厂商（阿里云 ACR、DaoCloud）的企业级加速服务。

七、常见问题与排障

7.1 WARNING: IPv4 forwarding is disabled

容器网络不通，dockerd 启动时打这条警告。生产环境装完 Docker 必须先修这个：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# 临时启用
sysctl -w net.ipv4.ip_forward=1

# 永久（任选其一）
echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
# 或
echo "net.ipv4.ip_forward=1" >> /usr/lib/sysctl.d/00-system.conf

# 生效
sysctl -p

# 验证
sysctl net.ipv4.ip_forward
# 期望输出：net.ipv4.ip_forward = 1

7.2 unknown or invalid runtime name: docker-runc

从老版本（Docker 18.06 之前）升级到 Docker 18.09+ 后，runtime 名从 docker-runc 改为 runc，老容器的 hostconfig.json 还引用老名字，导致容器起不来。

1
2
3
4
5


# 批量替换
grep -rl 'docker-runc' /var/lib/docker/containers/ | xargs sed -i 's/docker-runc/runc/g'

systemctl stop docker
systemctl start docker

7.3 live-restore：让容器在 daemon 重启时不停机

升级 Docker daemon 或 daemon 崩溃时，默认会停掉所有正在运行的容器。开启 live-restore 可让容器继续运行：

1
2
3


{
 "live-restore": true
}

1
2
3


systemctl daemon-reload
sudo systemctl reload docker.service # 注意是 reload 不是 restart
docker info | grep -i live # 验证：Live Restore Enabled: true

之后 systemctl restart docker 时，容器不会停。

多机同步：在 K8s 集群里，可以用脚本批量同步 daemon.json：

1
2
3
4
5


for NODE in master2 master3 worker1 worker3 worker4 worker5 worker6 worker7 worker8 worker9; do
 echo $NODE
 scp /etc/docker/daemon.json $NODE:/etc/docker/
 ssh root@$NODE "systemctl daemon-reload && systemctl reload docker && systemctl restart docker"
done

7.4 network disconnect：容器临时断网

1
2


# 临时把容器从指定网络断开
docker network disconnect -f bridge <container_name>

排查网络问题时很有用——能快速判断"是容器问题还是网络问题"。

八、核心要点 / 常见坑

把这一篇的要点压缩成 8 条：

bridge 模式是默认（90% 场景），host 模式换性能换隔离，none 模式是沙箱
端口映射必须用 -p——bridge 模式下不映射外部访问不了
容器共享 netns用 container 模式，sidecar 利器
指定固定 IP必须用自定义网络，默认 bridge 不支持
数据持久化用 Volume，docker volume prune 是危险命令
bind mount vs Volume：配置/日志用 bind mount，数据库用 Volume
国内拉镜像必须用代理或 mirror——dockerproxy 系列、ghcr.nju.edu.cn、阿里云、DaoCloud 都要会
live-restore 是 daemon 升级不停机的关键配置

九、小结

网络模式：4 种核心模式（bridge / host / none / container）+ 自定义网络，理解 veth pair 是关键
存储卷：Volume 管数据生命周期，bind mount 管配置文件，两手都要硬
镜像代理：dockerproxy 系列覆盖 Docker Hub / GCR / k8s.gcr.io / Quay，ghcr.nju.edu.cn 补足 ghcr
排障思路：先看 docker info 状态、再看 journalctl -u docker 日志、最后看 iptables 和 netns

下一步：单机 Docker 玩熟之后，下一步就是 Swarm / Kubernetes 的多机编排——那时网络（overlay / flannel / calico）、存储（Rexray / CSI）、调度（scheduler）都会变成新的核心议题。在 2019 年的 K8s 生态里，CoreDNS 已经取代 kube-dns 成为默认 DNS，ghcr.io 即将开放公开测试，镜像分发的格局正在重写——提前理解这些变化能少踩很多坑。

参考资料

Docker 容器启动命令还原：cucker / runlike 工具对比

Wed, 15 Mar 2017 00:00:00 +0800

容器跑久了之后，谁、用什么参数起的经常说不清。docker inspect 能看到参数但格式反人类，没有一个工具能直接还原成 docker run 命令就是问题。

社区里有三个工具专门干这事：cucker/get_command_4_run_container、assaflavie/runlike、joinsunsoft/runcommand。这一篇把它们的使用、差异、坑点一次性说清楚。

阅读对象：需要批量迁移容器、查历史启动参数、自动化复现容器配置的运维 / 开发者 覆盖范围：三个工具的对比 + 实战演示 + 自定义 alias + 边界场景

一、问题：为什么"看启动参数"这么难

docker inspect 能看所有配置，但输出的 JSON 字段名和 docker run 参数不一一对应：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


$ docker inspect mysql01 | jq '.[0].Config.Env'
[
 "MYSQL_ROOT_PASSWORD=py123456",
 "PATH=/usr/local/sbin:/usr/local/bin:...",
 ...
]

$ docker inspect mysql01 | jq '.[0].HostConfig.PortBindings'
{
 "3306/tcp": [
 {
 "HostIp": "",
 "HostPort": "13306"
 }
 ]
}

要把这些反向工程成 docker run -d --name mysql01 -p 13306:3306 -e MYSQL_ROOT_PASSWORD=py123456 mysql，光看 JSON 就要在脑子里做几层翻译。三个工具就是干这个的。

二、cucker/get_command_4_run_container

最老牌、用得最多的工具，Docker Hub 上被 pull 了 100w+ 次。

2.1 拉取 + 跑

1
2
3
4
5
6


# 拉镜像
docker pull cucker/get_command_4_run_container:1.3

# 还原容器的启动命令
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
 cucker/get_command_4_run_container:1.3 <container-name-or-id>

关键点：

--rm——跑完就删容器

-v /var/run/docker.sock:/var/run/docker.sock——挂载 docker daemon 的 socket，让容器内的工具能跟宿主机的 daemon 通信

2.2 输出示例

1
2
3
4
5
6
7
8
9


$ docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
 cucker/get_command_4_run_container:1.3 mysql01

docker run -d \
 --name mysql01 \
 --env MYSQL_ROOT_PASSWORD=py123456 \
 -p 13306:3306/tcp \
 --restart=always \
 mysql

直接复制粘贴就能跑。

2.3 配合 alias 用

1
2
3
4
5


# ~/.bashrc
alias get_run_command='docker run --rm -v /var/run/docker.sock:/var/run/docker.sock cucker/get_command_4_run_container:1.3'

# 用
get_run_command mysql01

三、assaflavie/runlike

另一个流行工具，和 cucker 类似但输出格式略有不同。

3.1 用法

1
2
3
4
5
6


# 拉镜像
docker pull assaflavie/runlike

# 还原
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
 assaflavie/runlike <container-name-or-id>

3.2 差异

维度	cucker	runlike
输出格式	`docker run -d \\\n --name xxx \\\n ...`	`docker run -d --name xxx ...`（一行）
命名	短名（`mysql01`）	FQDN（`/mysql01`，带斜杠）
网络	`--network=bridge`	`--network=bridge`
多网络	部分支持	支持更全
维护	偶尔更新	较活跃

四、joinsunsoft/runcommand

第三个工具，相对小众，但支持输出 docker-compose 格式。

1
2


docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
 joinsunsoft/runcommand loki

特色：能输出 YAML 格式的 docker-compose 配置。

五、批量还原所有容器

1
2
3
4
5
6


# 所有运行中容器
for CONTAINER in $(docker ps --format '{{.Names}}'); do
 echo "=== $CONTAINER ==="
 docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
 cucker/get_command_4_run_container:1.3 $CONTAINER
done

典型场景：接手一个"无文档"的 Docker 主机，用这个脚本快速还原整个部署。

六、还原 Docker Compose 配置

cucker 输出的是 docker run 单条命令。如果容器是用 docker-compose up 启动的，实际配置在 docker-compose.yml 里——还原不回来。

变通方案：

1
2
3
4
5
6
7


# 1. 看容器实际配置
docker inspect <container> > /tmp/container.json

# 2. 用 jq 提取关键字段
docker inspect <container> | jq '.[0].Config.Env'
docker inspect <container> | jq '.[0].HostConfig.PortBindings'
docker inspect <container> | jq '.[0].Mounts'

或者用社区脚本 rekcod：

1
2
3


# 把任意容器还原成 docker-compose.yml
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
 nexdrew/rekcod <container>

七、常见坑

7.1 `permission denied` 挂载 socket

1
2


$ docker run --rm -v /var/run/docker.sock:/var/run/docker.sock cucker/get_command_4_run_container:1.3 mysql
docker: error during connect: ... permission denied

解决：

Linux：当前用户在 docker 用户组里，或者用 sudo
Mac/Windows (Docker Desktop)：socket 路径在 VM 里，默认配置应该 OK

1
2
3


# Linux 上加 docker 组
sudo usermod -aG docker $USER
newgrp docker

7.2 还原出来的命令跑不起来

Why：

镜像已被删除（docker rmi 过）
网络 / 卷不存在
端口冲突

cucker / runlike 只还原配置，不还原前置依赖。先验证镜像还在：

1
2


$ docker images | grep mysql
mysql latest 7d0a4dc9b... 2 weeks ago 546MB

7.3 容器里有 bind mount 到宿主机路径

cucker 还原的命令会保留 -v /host/path:/container/path，但如果目标宿主机上 /host/path 不存在，启动会失败。

配合 creates 标记：

1
2
3
4
5


# 在还原的命令前先确保路径
mkdir -p /host/path

# 再跑还原的命令
docker run -d --name xxx -v /host/path:/container/path ...

7.4 `docker run` 输出和 `docker-compose.yml` 不一样

实例：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


# 实际启动：docker-compose.yml
version: "3"
services:
 nginx:
 image: nginx:1.19
 ports:
 - "8080:80"
 volumes:
 - ./html:/usr/share/nginx/html
 restart: always

# cucker 还原
docker run -d --name nginx -p 8080:80 \
 -v /root/project/html:/usr/share/nginx/html \
 --restart=always nginx:1.19

Why 不一样：

compose 会自动加 --name <project>_<service>_<index>（如 project_nginx_1）

compose 自动加 com.docker.compose.* 标签

bind mount 的相对路径变成绝对路径

生产建议：别用 cucker 还原 compose 启动的容器——直接读 compose 文件最准。

八、工具对比

维度	cucker	runlike	runcommand	rekcod
输出格式	docker run	docker run	docker run	docker-compose
镜像大小	~30MB	~20MB	~25MB	~30MB
多网络支持	部分	是	是	是
维护活跃	偶尔	活跃	少更新	活跃
推荐	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐	⭐⭐⭐

九、最佳实践

核心生产环境：写好 docker-compose.yml + Git 版本管理——别依赖"事后还原"
应急查命令：cucker / runlike 一键还原
批量盘点：用 for 循环扫所有容器，输出成文档
不要把"还原命令"作为"日常运维工具"——SSoT 应该是 compose 文件 / K8s manifest

十、要点回顾

cucker / runlike / runcommand / rekcod 是社区主流的"反查启动命令"工具
必须挂载 /var/run/docker.sock——容器内的工具才能跟 daemon 通信
还原的命令可能不能直接跑——镜像删除 / 路径不存在 / 端口冲突都常见
compose 启动的容器还原出来是 docker run 格式——不是 compose
生产 SSoT 应该是 compose / K8s manifest——还原工具只应急

十一、小结

“还原启动命令"是接手历史部署、自动化盘点、应急迁移的利器。但最佳实践仍然是把启动配置写在文件里——docker-compose.yml / K8s manifest，让 Git 成为 SSoT。

下一步：理解了"还原单条启动命令”，下一步是"还原整套部署"——rekcod 风格的 docker-compose 还原、Helm chart 模板化、Kustomize 跨环境覆盖——把"凭记忆启动"变成"声明式部署"。

参考资料

宝塔与 1Panel：两款 Linux 服务器管理面板的 Docker 部署实战

Mon, 15 Dec 2014 00:00:00 +0800

Linux 服务器的"装系统、装环境、装服务"过去全靠命令行——装一个 Nginx 要写一长串 apt / yum 指令，配置 SSL 还要碰 openssl 的细节，对刚入门的人来说门槛不低。“服务器管理面板"就是为了把这套流程做成 Web 化、可视化的产品：宝塔、1Panel、AppNode、URLOS、aaPanel 都是这一脉的代表。这篇文章聚焦两款最常见的产品——宝塔（pch18/baota） 和 moelin/1Panel——把它们的 Docker 部署、目录映射、默认凭据和排错一次性说清楚。

阅读对象：刚接触 Linux、想把日常运维（站点、数据库、SSL、计划任务）从命令行解放出来的同学；以及需要在容器里跑管理面板的 CI/CD / 演示环境搭建者。 覆盖范围：宝塔（CentOS/Debian 一键脚本 + pch18/baota 镜像）的安装与目录映射；1Panel 的 docker run / docker-compose 启动、目录约定、默认账户与首次进入。

一、为什么需要"服务器管理面板”

痛点	命令行解法	面板解法
装 Nginx/PHP/MySQL/Redis 一套 LNMP	多个 `apt install` + 手动改配置	选 LNP/MPN 模板，一键安装
给站点申请/部署 SSL 证书	手写 `acme.sh` cron + nginx 站点配置	域名 → 申请 → 自动续期
看磁盘/CPU/网络	`df -h` / `top` / `vmstat` 拼图	仪表盘一屏看完
多用户/多站点权限隔离	nginx vhost + sudo 配置	图形化"网站 → 权限"
容器化部署	`docker run` / `docker compose`	“应用商店” 里点一下

When to use：单台/几台机器、想快速搞起一套 Web 环境、不想折腾配置时；或团队需要让非运维同学也能上手时。Kubernetes 集群级别仍然不靠面板，而是 Helm + GitOps。

二、宝塔面板（pch18/baota）

宝塔是国产老牌面板，最早（2014 年）发布的是一键安装脚本，覆盖 CentOS/Debian/Ubuntu。后来社区出了 pch18/baota 镜像，让它可以跑在 Docker 里——非常适合演示、CI、临时环境。

2.1 原生安装（一键脚本）

1
2
3
4
5


# CentOS
yum install -y wget && wget -O install.sh https://download.bt.cn/install/install_6.0.sh && sh install.sh ed8484bec

# Debian / Ubuntu
wget -O install.sh https://download.bt.cn/install/install-ubuntu_6.0.sh && sudo bash install.sh ed8484bec

安装完后会输出管理地址（通常是 http://<IP>:8888/<随机入口>）和默认账号。

2.2 Docker 部署 pch18/baota

核心思路：把 /www 目录从容器里拷出来挂到宿主机，这样重启/升级容器不会丢数据。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# 第一次启动（host 网络，端口全开）
docker run -tid --name baota --restart always \
 -p 8002:80 -p 8043:443 -p 8808:8888 -p 808:888 \
 --privileged=true \
 --shm-size=1g \
 pch18/baota:latest

# 把容器里的 /www 拷出来
docker cp baota:/www /home/docker/baota

# 关掉临时容器
docker rm -f baota

接下来用持久化的方式重新启动（推荐）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


mkdir -p /home/docker/baota/www/wwwroot

# host 网络（推荐：避免端口转发的性能损失）
docker run -tid --name baota --restart always \
 --net=host \
 --privileged=true \
 --shm-size=1g \
 -v /home/docker/baota/www:/www \
 -v /home/docker/baota/www/wwwroot:/www/wwwroot \
 pch18/baota:latest

# bridge 网络（如需端口隔离）
docker run -tid --name baota --restart always \
 -p 8002:80 -p 8043:443 -p 8808:8888 -p 808:888 \
 --privileged=true \
 --shm-size=1g \
 -v /home/docker/baota/www:/www \
 -v /home/docker/baota/www/wwwroot:/www/wwwroot \
 pch18/baota:latest

端口说明：80:80（HTTP）、443:443（HTTPS）、8888:8888（面板）、888（phpMyAdmin）。--shm-size=1g 给 PHP 足够的共享内存，--privileged=true 让面板能在容器里调 systemd / mount 等特权操作。

访问入口：

1

http://<宿主机IP>:8808/login

默认账号 username/password 会在控制台输出，登录后必须改密码。

2.3 进入容器操作

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


docker logs -f --tail=100 baota
docker exec -it baota bash

# 容器内的命令行
[root@<container> wwwroot]# bt
===============宝塔面板命令行==================
(1) 重启面板服务 (8) 改面板端口
(2) 停止面板服务 (9) 清除面板缓存
(3) 启动面板服务 (10) 清除登录限制
(4) 重载面板服务 (11) 取消入口限制
(5) 修改面板密码 (12) 取消域名绑定限制
(6) 修改面板用户名 (13) 取消IP访问限制
(7) 强制修改MySQL密码 (14) 查看面板默认信息
(22) 显示面板错误日志 (15) 清理系统垃圾
(23) 关闭BasicAuth认证 (16) 修复面板
(24) 关闭谷歌认证 (17) 设置日志切割是否压缩
(25) 设置是否保存文件历史副本 (18) 设置是否自动备份面板
(0) 取消

2.4 常见问题

Q1：lsattr: Operation not supported While reading flags on python

容器化宝塔有时会触发这个错误（共享卷的属性查询在内核层不支持）。解决：

1
2


rm -rf /www/server/panel/pyenv
curl http://download.bt.cn/install/update_panel.sh | bash

Q2：Error: BT-Panel service startup failed.

通常是端口被占用或权限问题。重新跑一次安装脚本即可。

三、1Panel（moelin/1Panel）

1Panel 是 2022 年开源的新一代面板（飞致云出品），定位"现代化、开源、安全"，界面更现代，自带"应用商店"。Docker 化的 moelin/1Panel 镜像让体验完整保留。

3.1 docker run 启动

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


docker run -d \
 --name 1panel \
 --restart always \
 -p 10087:10086 \
 -v /var/run/docker.sock:/var/run/docker.sock \
 -v /var/lib/docker/volumes:/var/lib/docker/volumes \
 -v /opt:/opt \
 -v /root:/root \
 -v /data:/data \
 -e TZ=Asia/Shanghai \
 moelin/1panel:latest

3.2 docker-compose 启动

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


version: "3"
services:
 1panel:
 container_name: 1panel
 restart: always
 network_mode: "host"
 volumes:
 - /var/run/docker.sock:/var/run/docker.sock
 - /var/lib/docker/volumes:/var/lib/docker/volumes
 - /opt:/opt
 - /root:/root
 environment:
 - TZ=Asia/Shanghai
 image: moelin/1panel:latest
 labels:
 createdBy: "Apps"

3.3 首次进入

1
2
3
4
5
6


docker exec -it 1panel bash
root@<host>:/$ 1pctl user-info
面板地址: http://$LOCAL_IP:10086/entrance
面板用户: 1panel
面板密码: <随机生成>
提示：修改密码可执行命令：1pctl update password

访问 http://<宿主机IP>:10086/entrance（不是 10087，是容器内 10086 端口暴露给宿主的入口）。

3.4 关键约定

项	值	备注
默认端口	10086	通过 `-p 10087:10086` 映射
默认账号	`1panel`
默认密码	`1panel_password`	第一次安装随机生成
默认入口	`entrance`	即 URL 末尾的 `entrance`

3.5 注意事项

容器化部署的 1Panel 升级：不要点 UI 里的"立即更新"，应该拉新镜像 → 删除旧容器 → 用同样的目录映射重新部署。容器内 systemd 不完整，UI 升级路径会卡住。
不可调整的挂载：/var/run/docker.sock（必须挂，否则 1Panel 不能管理宿主机上的容器）。
可调整的挂载：/opt（应用数据）、/root（可选）、/var/lib/docker/volumes（Docker 卷）、TZ=Asia/Shanghai（时区）。
systemd 限制：因为容器内 systemd 不完整，部分面板功能（开机自启、服务守护）可能表现异常，复杂场景仍建议在裸机上跑 1Panel。

四、宝塔 vs 1Panel：怎么选

维度	宝塔	1Panel
起源	2014 国产老牌	2022 飞致云开源
资源占用	较低（约 200MB）	较高（Go 后端 + 前端）
Docker 支持	较弱（“Docker 容器"模块粗糙）	原生设计（“应用商店"直接装 WordPress / Halo / Halo 2）
应用商店	第三方脚本合集	内置官方市场（MySQL、Redis、Nginx、PHP 一键装）
主机防火墙	无图形化（要装 iptables 插件）	内置
Web 终端	宝塔 SSH 终端	内置
HTTPS 证书	一键申请 + 自动续期	一键申请 + 自动续期
备份	面板级 + 站点级	面板级 + 计划任务 cron
适合	老项目、LAMP/LNMP 站群、内存小的机器	新项目、容器化部署、想要现代 UI

经验法则：

内存 ≥ 4GB + 想"装 WordPress / 各类应用” → 1Panel
内存 ≤ 2GB + 老项目维护 + 习惯原生命令 → 宝塔
临时演示 / CI 环境 → pch18/baota 镜像（不用装扩展）

五、扩展阅读

宝塔官方：bt.cn
1Panel 官方：1panel.cn
pch18/baota 镜像：hub.docker.com/r/pch18/baota
moelin/1panel 镜像：hub.docker.com/r/moelin/1panel

Docker 数据目录搬家：磁盘满的根治方案

Sat, 15 Mar 2014 00:00:00 +0800

服务器跑 Docker 一段时间后，最常见的事故就是 / 分区被 /var/lib/docker 吃满——尤其是 /var 单独分区且容量规划不足的老机器。overlay2 一旦把某个容器层写满，容器起不来、镜像拉不下，连 docker ps 都可能 hang。

这一篇把"如何把 Docker 数据目录整体搬家到大容量磁盘"的完整流程串起来，覆盖 --graph（旧）、data-root（新）、systemd 配置改写、systemd 重新加载四大关键步骤。

阅读对象：在生产环境管理 Docker 主机、被 /var/lib/docker 撑爆过的运维同学 覆盖范围：磁盘诊断 + 备份停机 + 移动 / 软链 / 修改 data-root + systemd reload 验证

一、为什么需要搬家

典型事故现场：

1
2
3
4
5
6
7
8


$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 11G 8.4G 2.0G 82% /
/dev/sda5 2.3G 2.3G 0 100% /var
/dev/sda8 82G 204M 78G 1% /home

# overlay 挂载点
overlay 2.3G 2.3G 0 100% /var/lib/docker/overlay2/f18.../merged

/var 满了，/var/lib/docker/overlay2/ 的容器可写层跟着满。容器进程写文件会 ENOSPC，dockerd 也会大量报错。

常见解法（按推荐度）：

加大 /var 分区（最干净，但需要停机 + 重新分区）
迁移到 /home 大分区（推荐，本文重点）
清理无用镜像 / 卷 / 容器（治标不治本）
LVM 动态扩容（要预先用 LVM）

优先选 2：风险可控、几分钟内完成、不需要动分区表。

二、核心机制：Docker 把数据放哪

Docker 把所有持久化数据（images、containers、volumes、networks、build cache、overlay2 层）放在一个根目录，Linux 上默认是 /var/lib/docker。

1
2
3


$ docker info | grep -i 'root dir\|storage driver'
Docker Root Dir: /var/lib/docker
Storage Driver: overlay2

Docker 1.3+（2014-10 GA）开始支持自定义根目录：

Docker 1.3 ~ 17.05：用 --graph 参数（旧）
Docker 17.05+（2017-05 GA）：用 daemon.json 的 data-root 字段（新）

两种方式二选一，不要混用。

三、搬家完整流程

3.1 第一步：停 Docker

必须先停 daemon——/var/lib/docker 在被读写时直接 mv 会损坏文件系统层。

1
2
3
4
5
6
7
8


# 停服务
systemctl stop docker

# 停 containerd（如果装了新版 Docker）
systemctl stop containerd

# 验证：进程应该没了
ps -ef | grep -E 'dockerd|containerd' | grep -v grep

不要用 kill -9：dockerd 收到 SIGKILL 不会做优雅清理，可能留下半完成的 overlay 层。

3.2 第二步：移动目录

1
2
3
4
5
6
7
8


# 假设 /home 是大容量盘
mv /var/lib/docker /home/docker-data

# 验证大小一致
du -sh /var/lib/docker /home/docker-data

# 验证空间释放
df -h

Why 必须 mv 而不是 cp：mv 在同文件系统是 rename（原子操作），跨文件系统 mv 是 copy + delete。跨盘 mv 等价于 cp——这是 Linux 文件系统层面的事，确保 mv 源和目标是同一文件系统。

1
2
3
4


# 验证是否同文件系统
stat -c '%m' /var /home
# 输出相同数字 = 同文件系统（不需要重命名）
# 输出不同 = 跨文件系统（需要走 rsync 校验）

跨文件系统的"安全搬家"姿势：

1
2
3
4
5


rsync -aHAX /var/lib/docker/ /home/docker-data/
# 验证 md5 一致
diff -r /var/lib/docker /home/docker-data # 不应有输出
# 然后删旧的
rm -rf /var/lib/docker

3.3 第三步：告诉 Docker 新位置

方式 A（推荐，新写法）：编辑 daemon.json

1

vim /etc/docker/daemon.json

1
2
3


{
 "data-root": "/home/docker-data"
}

Why 优先 data-root：JSON 配置可被 dockerd 热加载（SIGHUP 触发），版本升级时不会因为 docker.service 被包管理器重写而失效。--graph 在 docker.service 里，包升级可能被覆盖。

方式 B（旧写法，已不推荐）：改 docker.service 的 ExecStart

1
2
3
4


[Service]
ExecStart=/usr/bin/dockerd \
 -H fd:// --containerd=/run/containerd/containerd.sock \
 --graph /home/docker-data

3.4 第四步：让 systemd 重新加载

这一步 90% 的事故都出在这里。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# 1. 重新加载 systemd 的 unit 文件
systemctl daemon-reload

# 2. 重新 enable（重要！某些版本不 re-enable 会用旧路径）
systemctl disable docker
systemctl enable docker

# 3. 启动
systemctl start docker

# 4. 验证
systemctl status docker

常见错误：跳过 daemon-reload。systemd 把 unit 文件缓存在内存里，不 reload 就 start 等于用旧配置。

3.5 第五步：验证

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 1. 看根目录
docker info | grep 'Docker Root Dir'
# 期望：Docker Root Dir: /home/docker-data

# 2. 看镜像和容器还在不在
docker images
docker ps -a

# 3. 看磁盘
df -h
# /home 应该有显著使用量

完整验证输出：

1
2
3


$ docker info | grep -E 'Root Dir|Storage Driver'
Docker Root Dir: /home/docker-data
Storage Driver: overlay2

四、补充：用软链代替改配置

如果不想动 daemon.json / docker.service，最轻量的方案是软链：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


# 停 docker
systemctl stop docker

# 移动数据
mv /var/lib/docker /home/docker-data

# 创建软链
ln -s /home/docker-data /var/lib/docker

# 启动
systemctl start docker

# 验证
ls -l /var/lib/docker
# 期望：/var/lib/docker -> /home/docker-data

优缺点：

不改任何配置，包升级不会破坏

适合"快速止血"——几秒钟搞定

软链对部分工具不友好（如 realpath、监控脚本可能误判）

不能跨机器迁移

五、多机同步：批量改所有 Docker 节点

在 K8s 集群或 Docker Swarm 集群里，所有节点的 Docker 数据目录最好一致。用 SSH 批量同步：

1
2
3
4
5
6
7
8
9


# 假设 master1 已经改好
for NODE in master2 master3 worker1 worker2 worker3; do
 echo "=== $NODE ==="
 ssh root@$NODE "systemctl stop docker && \
 rsync -aHAX --delete root@master1:/home/docker-data/ /home/docker-data/ && \
 cp /etc/docker/daemon.json /etc/docker/ && \
 systemctl daemon-reload && \
 systemctl start docker"
done

或者用 scp 单文件同步（更轻量，但只适合 daemon.json 小配置）：

1
2
3
4
5
6


# 同步 daemon.json
for NODE in worker1 worker2; do
 echo $NODE
 scp /etc/docker/daemon.json $NODE:/etc/docker/
 ssh root@$NODE "systemctl daemon-reload && systemctl reload docker && systemctl restart docker"
done

生产警示：在 K8s 集群里改 data-root，需要先 drain 节点（kubectl drain <node> --ignore-daemonsets），否则上面跑的 Pod 会被 dockerd 重启打断。

六、回滚

万一新位置起不来：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# 1. 停 docker
systemctl stop docker

# 2. 改回原路径
# 方式 A：改 daemon.json 的 "data-root" 为 /var/lib/docker
# 方式 B：删软链，恢复原目录
rm /var/lib/docker
mv /home/docker-data /var/lib/docker

# 3. 重启
systemctl daemon-reload
systemctl start docker

保留原目录一段时间再删——线上至少保留 24-48h，确认新位置稳定后再清理。

七、要点回顾

停 docker → mv → 改配置 → daemon-reload → start，五步缺一不可
优先用 daemon.json 的 data-root（2017-05+），--graph 是旧写法
必须 systemctl daemon-reload，否则 systemd 用缓存的旧 unit 文件
跨文件系统搬家用 rsync -aHAX，再用 diff -r 校验
软链是快速止血方案，但不适合监控 / 巡检脚本
K8s 集群里改 data-root 要先 kubectl drain

八、小结

Docker 数据目录搬家是最朴素也最容易踩坑的运维操作——错一步可能就是"daemon 起不来 + 容器全失联"。把"停 → 移 → 配 → reload → 验"这套流程跑成肌肉记忆，比记命令更重要。

下一步：理解数据目录结构后，下一层是清理策略——docker system prune 是什么、dangling 镜像和未使用卷如何批量清，以及怎么写一个不丢数据的"安全清理"脚本。/var/lib/docker 的体积管理是一个长期工程。

参考资料

Windows 系统快捷键 + Alt 码速查：研发与运维都该会的几组组合

Sun, 15 Dec 2013 00:00:00 +0800

一、为什么"快捷键"是最低成本的提效

2013 年的 Windows 8 把开始菜单藏了、Win 键组合被大面积改写，Win 10/11 又把搜索框塞到任务栏——但最经典的几个组合始终没变。运维和研发每天面对 10+ 个窗口、PowerShell、VS Code、远程桌面，5 个手指不动到鼠标就能完成的操作才是真效率。

本文按"日常 → 窗口管理 → 文字编辑 → 特殊字符 → 系统调试"五层递进，每组都给最短路径。

二、5 个必会的"救命"组合

2.1 `Win + S` 打开搜索

全宇宙最常用的 Windows 快捷键。Win 8 开始就是打开"开始菜单 + 搜索"二合一：

输入 powershell 直接回车，启动 PowerShell
输入 cmd 直达命令提示符
输入 regedit 进注册表
输入 mstsc 远程桌面
输入 ncpa.cpl 进网络连接

2.2 `Win + D` 显示桌面

一键最小化所有窗口到任务栏，再按一次还原。比鼠标找右下角快一个量级。

2.3 `Win + I` 打开设置

替代 2013 年开始被弱化的"控制面板"（Win 10/11 上是新版"设置"），常用入口：

网络：Win + I → 网络和 Internet
蓝牙 / 设备：Win + I → 设备
主题 / 锁屏：Win + I → 个性化

2.4 `Win + L` 锁屏

离开工位一秒就锁，比 Ctrl + Alt + Del 快得多，且不需要二次确认。

2.5 `Win + E` 打开文件资源管理器

直接进入"此电脑"，比开始菜单点"我的电脑"快很多。

三、窗口管理

3.1 `Win + ←` / `Win + →` 贴靠分屏

把当前窗口吸附到屏幕左半 / 右半——再按一次就变 1/4 屏。

实测：3 个窗口分屏（左 / 右 / 右上）非常适合对照看代码 + 文档 + 日志。

3.2 `Win + ↑` / `Win + ↓` 最大化 / 最小化

在普通状态按 ↑ → 最大化
在最大化按 ↓ → 还原
还原后按 ↓ → 最小化

3.3 `Win + Shift + ←/→` 移到另一显示器

多显示器场景下，把当前窗口甩到左 / 右侧屏幕。比手动拖快 10 倍。

3.4 `Win + Tab` 任务视图 / 虚拟桌面

第一次按：打开"任务视图"
在任务视图里点 + 新建桌面 → 创建虚拟桌面
Win + Ctrl + ←/→ 切换虚拟桌面
Win + Ctrl + D 直接新建虚拟桌面
Win + Ctrl + F4 关闭当前虚拟桌面

实际用法：把"开发环境"和"沟通环境"分两个桌面，写代码时一个 Win + Ctrl + ← 就把微信 / 钉钉隔离掉。

四、文字编辑类（VS Code / Office 通用）

快捷键	功能
`Ctrl + A`	全选
`Ctrl + C` / `Ctrl + V`	复制 / 粘贴
`Ctrl + X`	剪切
`Ctrl + Z` / `Ctrl + Y`	撤销 / 重做
`Ctrl + F`	查找
`Ctrl + H`	替换
`Ctrl + S`	保存（每个工种都该改成肌肉记忆）
`Ctrl + Shift + Esc`	任务管理器（比 `Ctrl + Alt + Del` 少一次确认）
`Ctrl + Shift + N`	新建文件夹（资源管理器） / 隐身窗口（Chrome）
`Alt + Tab` / `Alt + Shift + Tab`	切换窗口
`Alt + F4`	关闭窗口（经典永不消失）

五、特殊字符：Alt 码全集

按住 Alt 键不放，在数字小键盘上输入数字序列，松开 Alt 字符出现在光标位置。中文输入法和外接键盘没切数字键盘模式时会失效。

5.1 高频 32 个

字符	Alt 码	用途
`°`	0176 / 248	度数符号
`±`	0177	正负号
`×`	0215	乘号
`÷`	0247	除号
`µ`	0181	微（10⁻⁶）
`Ω`	234	欧姆
`©`	0169	版权
`®`	0174	注册商标
`™`	0153	商标
`§`	0167	章节
`¶`	0182	段落
`¥`	0165	人民币
`€`	0128	欧元
`£`	0163	英镑
`→`	26	右箭头
`←`	27	左箭头
`↑`	24	上箭头
`↓`	25	下箭头
`★`	9733	实心星
`☆`	9734	空心星
`✓`	10003	对勾
`✗`	10007	叉
	0160	不间断空格（防换行）
`–`	0150	短破折号
`—`	0151	长破折号
`…`	0133	省略号（比输入三个句点更专业）
`·`	0183	中点
`«` / `»`	0171 / 0187	法式引号
`‹` / `›`	0139 / 0155	单法式引号
`†`	0134	剑标
`‡`	0135	双剑标
`•`	0149	项目符号

5.2 几个特别说明

Alt + 0133 = …（省略号，比手动打三个点更标准，Word 会自动判断）
Alt + 0149 = •（项目符号，比 * 更显专业）
Alt + 0160 = 不间断空格（在排版中"5 6 月"中间用，防止在 5 和 6 之间换行）
4 位 Alt 码（0256+）可以打 Unicode 字符，比如 Alt + 10003 = ✓

六、Power User 菜单 / 任务栏

6.1 `Win + X` 打开 Power User 菜单

这个是 2012 年 Win 8 引入的"高级用户开始菜单"，右手按 Win + X + 左手按字母键就能触发：

Win + X, I → 设置
Win + X, T → 任务管理器
Win + X, A → PowerShell（管理员）
Win + X, E → 资源管理器
Win + X, U, U → 关机
Win + X, U, R → 重启

6.2 `Win + 1` / `Win + 2` 切换任务栏应用

任务栏上钉的应用，按 Win + 数字 直接打开 / 切换。比鼠标找图标快 3 倍。

6.3 `Win + ,` 预览桌面

按住显示桌面，松开还原。比 Win + D 切换更精准，不会"切过去忘了怎么回来"。

七、屏幕截图 / 录屏

快捷键	功能
`PrtScn`	全屏截图（保存到剪贴板）
`Alt + PrtScn`	当前窗口截图（保存到剪贴板）
`Win + PrtScn`	全屏截图（自动保存到 `图片/屏幕截图/`）
`Win + Shift + S`	区域截图（弹出截图工具栏）
`Win + G`	Xbox Game Bar（录屏）

2019 年之后：Win 10/11 推出的 Snip & Sketch（Win + Shift + S）已经替代了老 Snipping Tool。Snipaste 是更高级的第三方替代——支持贴图 + 像素标注，几乎是开发者标配。

八、运维专用的"系统级"快捷键

快捷键	功能
`Ctrl + Shift + Esc`	任务管理器
`Win + R`	运行（输入 `mstsc` / `regedit` / `services.msc` / `ncpa.cpl` 等）
`Win + Pause`	系统属性（设备名 / 内存 / 处理器）
`Win + L`	锁屏
`Win + U`	辅助功能中心（远程协助时让用户开"讲述人"很方便）

8.1 `Win + R` 速查

运维最常用 Win + R + 命令：

命令	功能
`mstsc`	远程桌面
`regedit`	注册表
`services.msc`	服务管理
`ncpa.cpl`	网络连接
`diskmgmt.msc`	磁盘管理
`devmgmt.msc`	设备管理器
`compmgmt.msc`	计算机管理
`eventvwr.msc`	事件查看器
`gpedit.msc`	本地组策略（Win 10 家庭版没有）
`appwiz.cpl`	程序和功能
`taskmgr`	任务管理器
`powershell`	PowerShell
`cmd`	命令提示符
`msconfig`	系统配置
`cleanmgr`	磁盘清理

九、常见 5 个坑

Alt 码打不出——检查是否在中文输入法、是否有 NumLock、外接键盘没切换数字键盘模式。
Win + L 后远程桌面连不上——远程桌面会话被锁屏会显示"仅允许一个用户"，需要本地解锁。
Win + E 打开的不是"此电脑"而是"快速访问"——可以在"文件资源管理器选项"里改成"打开此电脑"。
Win 10 家庭版没有 gpedit.msc——需要手动安装 Group Policy Editor 补丁，或者用 regedit 改对应注册表。
Win + Shift + S 截图后没保存提示——截图只在剪贴板，按 Ctrl + V 粘到画图 / 微信 / 文档；想要"自动保存"还是用 Win + PrtScn。

十、总结

5 个救命键：Win + S 搜索、Win + D 桌面、Win + L 锁屏、Win + E 资源管理器、Ctrl + Shift + Esc 任务管理器
窗口分屏：Win + ←/→ 贴靠，Win + Tab 虚拟桌面
运维调试：Win + R + mstsc / services.msc / regedit / ncpa.cpl 是 4 大天王
截图录屏：Win + Shift + S 区域截图，Snipaste 是 3.0 升级版

运维 on Liangweidong's blog

K8s 节点扩容：worker 加入集群一键脚本

K8s 集群扩容的场景

1. 全新 worker 加入（推荐）

1.1 master1 上操作

设置 hosts

免密登录

推送二进制 + 证书 + 服务配置

1.2 一键脚本（推荐）

1.3 验证

2. 之前装过 kubeadm 的 worker 清理

3. 常见坑

3.1 日志采集不到

3.2 kubelet 启动报 kubelet.go:2286] "Error updating node status"

3.3 kubelet: failed to create kubelet: cgroup driver "cgroupfs" is different from docker "systemd"

3.4 kubelet: failed to start ContainerManager ... cgroup ... not found

3.5 kubelet.go:1380] "Failed to start cAdvisor" ... Failed to get cgroup stats

3.6 kubelet: node "<name>" not found

3.7 容器启动后立即退出

3.8 节点 NotReady

3.9 节点 Ready 但 Pod 起不来

4. 缩容

5. 实战：worker10 加入（带坑排查）

6. 小结

K8s 集群升级与卸载：版本升级 + finalizers 清理

升级 vs 卸载

1. 升级策略

1.1 大版本 vs 小版本

1.2 升级顺序

1.3 当前环境

2. 升级 etcd

3. 升级 K8s 控制面

3.1 升级 master1

3.2 升级 master2 + master3

3.3 升级 worker

3.4 验证

4. 升级时的节点隔离

5. 卸载 K8s 集群

5.1 停服务顺序

5.2 删 systemd 单元

5.3 删目录

5.4 清环境变量

5.5 停 etcd

5.6 停容器运行时

5.7 其他清理

5.8 验证

6. namespace 卡 Terminating 终极清理

6.1 PVC 卡 Terminating

6.2 Pod 卡 Terminating

6.3 后台强删 namespace

6.4 KubeSphere 等第三方组件

7. 排错速查

8. 小结

Watchtower 容器自动更新：守护所有容器的升级

一、为什么需要 Watchtower

二、最小化启动

三、选择性更新

3.1 通过文件列表更新

四、排除特定容器

五、调度频率

5.1 间隔模式

5.2 Cron 模式

六、私有 Registry 认证

七、远程主机升级

八、手动触发更新

九、监控与日志

9.1 看实时日志

9.2 接入 Loki / ELK

9.3 Prometheus 指标（通过 cAdvisor）

十、典型坑位

10.1 Watchtower 自己被升级

10.2 升级后容器启动失败

10.3 数据库容器被升级丢数据

10.4 大量容器同时升级

十一、生产级建议

11.1 灰度升级

11.2 升级前快照

11.3 通知集成

十二、完整生产配置示例

十三、Watchtower 替代方案

3.2 kubelet 启动报 `kubelet.go:2286] "Error updating node status"`

3.3 `kubelet: failed to create kubelet: cgroup driver "cgroupfs" is different from docker "systemd"`

3.4 `kubelet: failed to start ContainerManager ... cgroup ... not found`

3.5 `kubelet.go:1380] "Failed to start cAdvisor" ... Failed to get cgroup stats`

3.6 `kubelet: node "<name>" not found`