Linux on WYF 的技术博客

Linux运维 02：一台服务器再搭一套完全隔离的 Jenkins（华为云 EulerOS 实战）

Wed, 16 Sep 2026 14:59:14 +0800

场景：服务器上已经跑着一套给老项目用的 Jenkins（8080 端口），新项目（myapp）需要一套完全独立的 Jenkins——独立端口、独立 home 目录、独立插件体系，互不影响。系统：Huawei Cloud EulerOS 2.0 (x86_64)，部署方式：Docker + docker-compose。本文记录从环境调研到初始化、升级、工具配置的全过程，以及踩到的 4 个坑。（文中密码、密钥均已脱敏，请替换成自己的。）

一、先看清楚家底：环境调研

1.1 系统源里有什么 Java？——一个坏消息

新项目后端是 Spring Boot 3.x，要求 Java 17+。按惯例先查系统源：

1
2
3
4
5


cat /etc/os-release
# NAME="Huawei Cloud EulerOS"
# VERSION="2.0 (x86_64)"

yum list available 2>/dev/null | grep -iE 'openjdk'

结果只有：

1
2


java-1.8.0-openjdk 1:1.8.0.432.b06-0.hce2
java-11-openjdk 1:11.0.30.7-0.hce2

结论：HCE 2.0 的 yum/dnf 源里没有 java-21-openjdk，连 java-17 也没有，只有 1.8 和 11。直接 yum install java-21-openjdk 必然报"没有任何匹配"。

dnf 和 yum 在 HCE 上是同一个源，换命令没用。

这件事直接影响了后面的技术选型：所有 Java 都不装在系统上——Jenkins 本体用官方镜像（自带 JDK），构建用 JDK 来自 Adoptium 官方 tar.gz 解压包，应用运行用 Docker 镜像。系统层面零 Java 安装。

1.2 旧 Jenkins 是怎么部署的？

服务器上已有一套给 bid 项目用的 Jenkins，先摸清它的部署方式（照抄成熟经验，避开它的资源）：

1
2
3
4


docker ps
# jenkins 0.0.0.0:8080->8080/tcp, 0.0.0.0:50000->50000/tcp

cat /home/compose/docker-compose.yml

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


services:
 jenkins:
 image: jenkins/jenkins:lts
 container_name: jenkins
 privileged: true
 user: root
 environment:
 - TZ=Asia/Shanghai
 ports:
 - "8080:8080"
 - "50000:50000"
 volumes:
 - ./jenkins_home:/var/jenkins_home
 - /var/run/docker.sock:/var/run/docker.sock
 - /root/.m2/repository/:/root/.m2/repository/
 - ./jdk17/:/usr/local/jdk17/
 extra_hosts:
 - "git.example.com:10.10.10.15"
 restart: unless-stopped

关键信息：

项目	旧实例情况	对新实例的影响
端口	8080（Web）+ 50000（Agent）	新实例必须换端口
编排目录	`/home/compose/`	新实例用独立目录
版本	2.541.1 (LTS)，镜像 `jenkins/jenkins:lts`	可复用本地镜像，不用重新拉
运行 JDK	镜像自带 Temurin 21.0.9	不用管
构建 JDK	宿主机 `/home/compose/jdk17`（Temurin 17.0.18+8，Adoptium tar.gz 解压）	可以只读挂载复用
docker.sock + privileged	任务里能直接操作宿主机 Docker	新实例不挂，隔离
`extra_hosts`	内网 Git `git.example.com` → `10.10.10.15`，DNS 不解析	新实例必须照配，否则拉不了代码
已有任务	4 个 bid 项目任务，生产在用	一个字都不能动

另外确认宿主机资源充足（内存 15G 剩 13G，磁盘剩 76G），跑第二个 Jenkins 没压力。

二、方案设计：怎么算"完全隔离"

维度	旧实例	新实例（jenkins2）
编排目录	`/home/compose/`	`/home/compose-jenkins2/`
容器名	`jenkins`	`jenkins2`
Web 端口	8080	8082
Agent 端口	50000	50001
home 卷	`./jenkins_home`（6.4G，197 个插件）	全新空目录
运行用户	root（privileged）	镜像默认 jenkins（uid 1000）
docker.sock	挂载	不挂（任务不能直接动宿主机 Docker）
.m2 仓库	挂宿主机	不挂，独立
jdk17	读写挂载	只读挂载复用（`:ro`）

选 8082/50001 之前先查端口占用：ss -tln，确认 8080/50000/8081 都已被占，8082/50001 空闲。

三、创建 jenkins2

3.1 第一版 compose：先跑起来

1
2
3


mkdir -p /home/compose-jenkins2/jenkins_home
chown -R 1000:1000 /home/compose-jenkins2/jenkins_home # 容器内 jenkins 用户 uid=1000
cd /home/compose-jenkins2

docker-compose.yml：

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


services:
 jenkins2:
 image: jenkins/jenkins:lts
 container_name: jenkins2
 environment:
 - TZ=Asia/Shanghai
 ports:
 - "8082:8080"
 - "50001:50000"
 volumes:
 - ./jenkins_home:/var/jenkins_home
 restart: unless-stopped

1
2


docker-compose up -d
docker logs -f jenkins2

注意 chown 1000:1000 不能省：容器以 jenkins（uid 1000）运行，home 目录属主是 root 会起不来。

3.2 浏览器初始化

拿初始密码：docker exec jenkins2 cat /var/jenkins_home/secrets/initialAdminPassword
浏览器打开 http://<服务器IP>:8082，粘贴解锁
选 Install suggested plugins（推荐套装，含 Pipeline / Git / Credentials 等基础插件）
创建管理员账号，完成

两个提醒：

云服务器记得在安全组放行 8082。

如果插件下载慢，可以把更新中心换成清华镜像：https://mirrors.tuna.tsinghua.edu.cn/jenkins/updates/update-center.json（Manage Jenkins → Plugins → Advanced settings → Update Site）。

3.3 坑 1：git.example.com 域名解析不了

旧实例 compose 里有 extra_hosts，第一版没抄这一条——内网 GitLab 域名 git.example.com 在 DNS 里不存在，不配的话流水线 clone 代码必然失败。补上：

1
2


 extra_hosts:
 - "git.example.com:10.10.10.15"

1
2
3
4
5
6


docker-compose up -d # 重建
# 验证：
docker exec jenkins2 grep git.example.com /etc/hosts
# 10.10.10.15 git.example.com
docker exec jenkins2 curl -sk -o /dev/null -w '%{http_code}' https://git.example.com/
# 302（可达）

四、坑 2：安全警告横幅 → 顺便升级到最新 LTS

初始化完成后，Manage Jenkins 页面顶部挂着红色横幅：当前 2.541.1 core 存在多个已知安全漏洞。

因为新实例还没建任何任务，升级零成本，直接升：

1
2
3
4
5


cd /home/compose-jenkins2
docker-compose pull # 拉最新 lts
docker-compose up -d # 重建
curl -s -D- http://localhost:8082/login | grep X-Jenkins
# X-Jenkins: 2.568.3

升级到 2.568.3（当时最新 LTS），红色漏洞横幅消失。

其余几条横幅的处理：

“Pipeline: Groovy Libraries 有 CSRF 问题但无修复版本”——没修复版本，只能忽略；
built-in node 安全提示、CSP 提示——确认自己会用 built-in node 构建后，点 Dismiss 即可。

旧实例（8080）不要顺手升：它跑着 bid 项目的生产构建，升级要另约时间窗口、先备份 jenkins_home。隔离的意义就在这里——两边版本可以不一样，互不影响。

五、装插件：只装两个

推荐套装已经覆盖了 Pipeline、Git、Credentials，额外只需要：

Manage Jenkins → Plugins → Available plugins，搜索勾选：

NodeJS Plugin——前端构建用。Jenkins 本体只是调度壳子，JDK/Maven 的工具管理是核心自带的，Node 不是；没有它，流水线脚本里 tools { nodejs 'node22' } 不认识，pnpm install/build 直接 command not found。
SSH Agent Plugin——部署用。流水线 Deploy 阶段用 sshagent(['凭据ID']) { ... } 把私钥临时加载进 ssh-agent，实现免密 scp/ssh。

点 Install，勾选"安装完成后重启 Jenkins"，等半分钟自动重启（不影响 8080 的旧实例）。

后续小插曲：SSH Agent 方案后来因凭据问题被弃用（改用容器内密钥文件，见本系列第二篇），但插件装着无害。

六、全局工具配置：jdk17 / maven3.9 / node22

Manage Jenkins → Tools，配三个工具。名字必须和流水线脚本里 tools {} 引用的一字不差。

6.1 JDK——坑 3：没有 adoptium 安装器

点 JDK 新增，打算让 Jenkins 自动装 Temurin 17，结果发现 Add Installer 下拉里没有 “Install from adoptium.net”（只有 Extract zip / Batch / Shell 三项，这是部分版本/网络环境下的常见情况）。

解决办法：不自动装，复用宿主机现成的 JDK 17——当年旧实例手工解压的 Adoptium Temurin 17 就在 /home/compose/jdk17。给 jenkins2 加只读挂载（compose 第三版，也是最终版）：

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


services:
 jenkins2:
 image: jenkins/jenkins:lts
 container_name: jenkins2
 environment:
 - TZ=Asia/Shanghai
 ports:
 - "8082:8080"
 - "50001:50000"
 volumes:
 - ./jenkins_home:/var/jenkins_home
 - /home/compose/jdk17:/usr/local/jdk17:ro  # 只读复用宿主机的 JDK17
 extra_hosts:
 - "git.example.com:10.10.10.15"
 restart: unless-stopped

1
2
3


docker-compose up -d
docker exec jenkins2 /usr/local/jdk17/bin/java -version
# openjdk version "17.0.18" Temurin-17.0.18+8

Tools 页面配置：

JDK：Name 填 jdk17；取消勾选 Install automatically；JAVA_HOME 填 /usr/local/jdk17。

只读挂载（:ro）是个好习惯：新实例万一配错也伤不到旧实例在用的 JDK。

6.2 Maven

Maven：Name 填 maven3.9；勾选 Install automatically → Install from Apache → 选 3.9.x 最新（实际装到 3.9.16）。

默认走 Apache 中央仓库慢，给容器内的 Maven 配阿里云镜像（宿主机写好，jenkins_home 是绑定挂载，容器内直接生效）：

/home/compose-jenkins2/jenkins_home/.m2/settings.xml：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


<settings>
 <mirrors>
 <mirror>
 <id>aliyun</id>
 <mirrorOf>central</mirrorOf>
 <name>aliyun</name>
 <url>https://maven.aliyun.com/repository/public</url>
 </mirror>
 </mirrors>
</settings>

6.3 NodeJS

NodeJS：Name 填 node22；勾选 Install automatically → Install from nodejs.org → Node.js 22.x LTS。

如果 nodejs.org 下载不动，可以换 npmmirror 的二进制地址： https://registry.npmmirror.com/-/binary/node/v22.20.0/node-v22.20.0-linux-x64.tar.gz

七、坑 4：保存配置时报 HTTP 403

在 Tools 页面填好 JDK 的 JAVA_HOME，点 Save，弹错：

1
2


An internal error occurred during form field validation (HTTP 403).
Please reload the page and if the problem persists, ask the administrator for help.

这不是配置填错了。 原因是：当天 jenkins2 容器被反复重建过好几次、还升过一次级（2.541.1 → 2.568.3），而浏览器里还是升级前打开的旧会话页面——后台的表单校验接口需要有效的 CSRF crumb，过期会话提交就被 403 拒绝。

解决：退出登录 → 重新登录 → 重新进 Tools 填一遍 → Save。 保存后最好回进页面确认值真的存进去了。如果重新登录后仍然 403，那才需要查容器日志（docker logs jenkins2）深挖。

八、建 Git 凭据

流水线要从内网 GitLab 拉代码，先建凭据：

Manage Jenkins → Credentials → System → Global credentials (unrestricted) → Add Credentials：

Kind：Username with password
Username / Password：git.example.com 的账号密码（账号要有 myapp-safe 组的读权限）
ID 手动填 myapp-git（不填会自动生成 UUID，脚本里没法引用）
Create

九、收尾状态

1
2
3


docker ps
# jenkins 0.0.0.0:8080->8080/tcp, 0.0.0.0:50000->50000/tcp ← 旧实例，原封不动
# jenkins2 0.0.0.0:8082->8080/tcp, 0.0.0.0:50001->50000/tcp ← 新实例

项目	值
访问地址	`http://10.10.10.44:8082`
版本	2.568.3 (LTS)
编排文件	`/home/compose-jenkins2/docker-compose.yml`
工具	jdk17（JAVA_HOME=/usr/local/jdk17）、maven3.9（3.9.16）、node22（22.x）
插件（额外）	NodeJS Plugin、SSH Agent Plugin
凭据	`myapp-git`
镜像仓库	Maven 阿里云、Node npmmirror（备用）

十、经验总结

先查系统源再定方案：HCE 2.0 源里最高只有 OpenJDK 11，想"一条 yum 装 JDK 17/21"会直接卡死；全程容器化 + 官方 tar.gz 是绕开这个问题的正解。
隔离 = 端口 + 目录 + 权限三件事：换端口、独立编排目录、不挂 docker.sock、不用 root 跑，两个 Jenkins 就是真正的两套系统。
成熟实例的配置是宝藏：旧实例的 extra_hosts（内网 Git 域名）、宿主机 jdk17，都是可以只读复用的现成资产——但复用一律 :ro。
新建实例趁没任务赶紧升级，安全横幅不要拖；跑生产的实例升级另约窗口。
Jenkins 的 403 表单错误八成是会话过期，重新登录比查日志快。
工具 Name 和脚本 tools{} 引用必须一字不差（jdk17 / maven3.9 / node22），凭据 ID 要手动指定，不要用自动生成的 UUID。

下一篇：《从零到上线：用这套 Jenkins 部署前后端项目（MySQL/Redis 容器化）踩坑全记录》——包括 3306 之争、ssh-agent 凭据三连败、403 Forbidden、logo 消失之谜等 8 个实战坑。

Linux运维 01：Mac 判断服务器端口连通性方法大全（nc / curl / telnet / nmap）

Wed, 16 Sep 2026 10:30:00 +0800

环境：macOS（Apple Silicon），无需安装任何软件即可完成 90% 的排查场景：服务器部署了服务，想确认"端口到底通不通"“这台机器上还开了哪些端口” 读者定位：收藏当手册，用到时按目录查

一、先建立两个认知（不懂这两个，必误判）

1.1 ping 不通 ≠ 端口不通

ping 走的是 ICMP 协议，而业务端口走的是 TCP 协议，两者互不相干。很多服务器和内网防火墙会直接丢弃 ICMP 包，造成"ping 100% 丢包但 80 端口网页开得好好的"。

结论：不要用 ping 判断服务是否存活，要用 TCP 探测。

1.2 连上没字 ≠ 不通（“谁先说话"问题）

不同协议的"开场白"方向不一样：

协议类型	代表服务	连接建立后
服务器先说话	SSH(22)、MySQL(3306)、FTP(21)	立刻推送 banner（版本信息）
客户端先说话	HTTP(80/8080…)、Redis(6379)	一言不发，等你先发请求

所以用 telnet 测 HTTP 端口，连上后一片空白、光标干等——这不是不通，是正常等待。输入 GET / HTTP/1.0 再按两次回车，响应立刻就出来了。

真实案例：浏览器能打开 http://10.36.35.43:8083/login，但 telnet 10.36.35.43 8083 “没响应”。用 nc 验证：TCP 秒连，手动发一行 GET 请求立刻返回 HTTP/1.1 200 OK——端口一直是通的，只是 HTTP 服务不主动打招呼。

二、判断单个端口是否通

方法 1：nc（macOS 自带，首选）

1
2


nc -vz 10.36.35.43 22
# -v 显示详情 -z 只探测不传数据 -G 2 可指定超时秒数

三种结果，语义完全不同，要能读懂：

输出	含义
`Connection to ... succeeded!`	✅ 通，且有服务在监听
`failed: Connection refused`	主机可达，但端口没服务监听（服务没起/监听别的端口）
`failed: Operation timed out`	包被防火墙丢了，或主机不可达（不是"没服务”）

方法 2：curl（HTTP 服务最方便）

1
2


curl -sI -m 5 http://10.36.35.43:8080 # 看状态行 + Server 头
curl -v telnet://10.36.35.43:22 # 冷门招：telnet:// 协议能测任意 TCP 端口，还能拿到 SSH banner

方法 3：bash 内置 /dev/tcp（零依赖应急）

1

bash -c '(echo > /dev/tcp/10.36.35.43/22) 2>/dev/null && echo 通 || echo 不通'

无需任何外部命令，是 bash 自身的特性。缺点是超时不可控（防火墙丢包场景会等很久），日常还是 nc 好用。

⚠️ 踩坑（实测）：zsh 下直接跑会得到"假阴性"。/dev/tcp 是 bash 独有的伪设备，zsh 不认识——它把 /dev/tcp/10.36.35.43/22 当普通文件路径，重定向失败的报错又被 2>/dev/null 吞掉，于是端口明明是通的也输出"不通"。macOS 从 Catalina 起默认 shell 就是 zsh，所以必须套一层 bash -c '...'。验证：curl -v telnet://IP:端口 能拿到 banner 而 /dev/tcp 报不通时，先想想自己当前在哪个 shell 里。

方法 4：telnet（新版 macOS 需自行安装）

1
2


brew install telnet
telnet 10.36.35.43 22

看到 Connected to ... 就说明 TCP 通了。后面有没有字，取决于 1.1 节说的"谁先说话"。

方法 5：nmap（装了的话）

`1`	`nmap -Pn -p 22,80,443 10.36.35.43`

-Pn 很重要：nmap 默认先 ping 探测主机死活，ping 不通直接跳过扫描。内网服务器经常禁 ping（见 1.1），不加 -Pn 会得出"主机 down"的错误结论。

方法 6：浏览器

HTTP/HTTPS 服务最直接：http://IP:端口 能打开页面就是通的。但注意它只对 Web 服务有效。

三、扫描整台服务器：哪些端口是开的

方法 1：nmap（标准答案）

1
2
3
4
5
6
7


brew install nmap

nmap -Pn 10.36.35.43 # top 1000 常用端口（最常用）
nmap -Pn -F 10.36.35.43 # top 100，更快
nmap -Pn -p- 10.36.35.43 # 全端口 1-65535（慢，几分钟）
nmap -Pn -sV 10.36.35.43 # 顺带识别服务版本
nmap -Pn -T4 --open 10.36.35.43 # 加速 + 只显示开放的

方法 2：nc + xargs 并发（不装任何东西的应急方案）

1
2
3
4
5


echo "21 22 23 25 53 80 110 143 443 445 465 587 993 995 1080 1433 1521 2181 \
2375 3000 3306 3389 4000 5000 5432 5672 5900 6379 8000 8006 8007 8080 8081 \
8086 8090 8443 8848 8888 9000 9001 9042 9090 9092 9200 9300 10000 11211 15672 27017" \
 | tr ' ' '\n' \
 | xargs -P 20 -I{} sh -c 'nc -z -G 2 10.36.35.43 {} >/dev/null 2>&1 && echo "OPEN {}"'

原理：nc -z 逐端口试探 TCP 握手，xargs -P 20 并发 20 个，50 个常见端口十几秒扫完。想扫全端口就换成 seq 1 65535 | xargs -P 50 ...，慢但可行。

注意列表覆盖：上面的清单是手挑的常见端口，像 8083 这种非典型端口就不会命中——扫不到不代表没开，只代表"不在清单里"。要穷举就上 nmap -p-。

方法 3：masscan（海量端口，需 sudo）

1
2


brew install masscan
sudo masscan -p1-65535 10.36.35.43 --rate=1000

异步发包，全端口几十秒扫完。适合大网段，单机用 nmap 足矣。

端口通只是第一步，抓 banner 才知道上面跑的是谁：

1
2
3
4
5
6
7
8
9


# SSH / MySQL：连上就读（服务器先说话）
nc -w 2 10.36.35.43 22 < /dev/null | head -1 # SSH-2.0-OpenSSH_8.8
nc -w 2 10.36.35.43 3306 < /dev/null | strings | head -1 # 5.7.44

# Redis：发 PING 看回应（客户端先说话）
printf 'PING\r\n' | nc -w 2 10.36.35.43 6379 # -NOAUTH Authentication required.

# HTTP：HEAD 请求
curl -sI -m 5 http://10.36.35.43:80 # Server: nginx/1.13.12

一条命令全搞定的懒人方案：nmap -Pn -sV 目标IP。

五、实战案例：扫描内网服务器 10.36.35.43

用方法三·2 的 nc 并发扫描 + 方法四的 banner 抓取，实测结果：

端口	服务	识别详情
22	SSH	OpenSSH 8.8
80	HTTP	nginx/1.13.12，首页 200
443	开放但未知	TCP 通，不回应 HTTPS 握手
3306	MySQL	5.7.44（版本号 banner 直接暴露）
6379	Redis	有密码（NOAUTH）
8080/8081	HTTP	根路径 404，未暴露 Server 头
8083	HTTP	nginx 反代的前端登录页（后补扫发现）

顺带两个安全观察：

MySQL 版本号在 banner 里裸奔——等于告诉攻击者该打哪些 CVE，3306 应只对需要的网段开放
nginx 1.13.12 是 2017 年的版本，已知漏洞不少（如 CVE-2017-7529），正式服务建议升级

六、速查表

需求	命令
测单个端口	`nc -vz IP 端口`
测 HTTP 服务	`curl -sI -m 5 http://IP:端口`
任意 TCP 端口看 banner	`curl -v telnet://IP:端口` 或 `nc -w 2 IP 端口`
扫常用端口	`nmap -Pn IP`（无 nmap 时用 nc+xargs 脚本）
扫全端口	`nmap -Pn -p- IP`
识别服务版本	`nmap -Pn -sV IP`
ping 不通还想扫	nmap 务必加 `-Pn`

合规提醒：端口扫描只用于自己的服务器或获得明确授权的目标。对陌生主机扫描在多数公司和云厂商守则里属于攻击行为。

K8s 从零到实战 00（下）：内核参数与容器运行时（containerd 三关）

Sun, 13 Sep 2026 10:10:00 +0800

目标：完成 k8s 安装前的最后两项准备——内核网络参数（k8s 的神经网络）和容器运行时（k8s 的手）。前置：已完成阶段 0（上）：虚拟机与系统初始化。步骤编号延续上篇（从第 5 步开始）；所有命令在 Rocky 机器上以 root 执行。

5. 加载内核模块并开启 iptables 桥接流量（必须）

为什么必须——k8s 的 Service 网络（阶段 3 主角）依赖三样底层能力：

overlay：容器镜像分层存储的文件系统，containerd 启动容器必备
br_netfilter + bridge-nf-call-iptables=1：强制网桥流量经过 iptables。Service 虚拟 IP 靠 iptables 规则转换（kube-proxy 写入），桥内流量若绕过 iptables，Service 全部失灵
ip_forward=1：允许节点转发数据包，跨节点 Pod 通信的前提

缺了任何一样，阶段 1 的 kubeadm init 预检会直接报错拒绝安装。

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


cat > /etc/modules-load.d/k8s.conf <<EOF
overlay
br_netfilter
EOF

modprobe overlay
modprobe br_netfilter

cat > /etc/sysctl.d/k8s.conf <<EOF
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
net.ipv4.ip_forward = 1
EOF

sysctl --system

验证：lsmod | grep br_netfilter 应有输出，例如：

1
2


br_netfilter 32768 0
bridge 315392 1 br_netfilter

输出读法（四列 = 模块名 / 大小(字节) / 引用计数 / 被谁引用）：引用计数 0 不等于没用——br_netfilter 靠 sysctl 开关起作用，不靠被谁引用； bridge 行尾出现 br_netfilter，说明它是 bridge 网桥驱动的"扩展插件"，专门给网桥加 netfilter（iptables）钩子。两行都在 = 这对搭档都在岗。（/etc/modules-load.d/ 管开机自动加载，modprobe 管立即生效，缺一不可。）

6. 安装容器运行时 containerd

k8s 自己不会跑容器——它只是调度大脑（决定 Pod 放哪台机器），真正拉镜像、起容器的是容器运行时。kubelet 通过标准接口 CRI 指挥 containerd 干活：kubectl 命令 → apiserver → scheduler → kubelet → containerd → 容器进程。 Kubernetes 从 1.24 起不再直接支持 Docker（它对 k8s 来说太重），containerd 是主流选择。

6.1 安装

1
2
3
4
5
6
7
8


# download.docker.com 国内不可达，使用阿里云 docker-ce 源（只借用它里面的 containerd 包）
dnf config-manager --add-repo https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo

# 安装 containerd
dnf -y install containerd.io

# 生成默认配置
containerd config default > /etc/containerd/config.toml

containerd 的官方发布渠道是 Docker 公司的软件源 download.docker.com（国内不可达）。阿里把它整个镜像了一份，我们借仓库只取 containerd.io 这一个包，不装 docker-ce 本身——虚拟机里不会有 Docker
包名是 containerd.io（不带 .io 的是另一个老包，别搞混）
containerd 没有开箱即用的配置文件，必须先用 config default 生成底版再修改

6.2 关键修改 1：SystemdCgroup = true（与 kubelet 统一资源管理）

1

sed -i 's/SystemdCgroup = false/SystemdCgroup = true/' /etc/containerd/config.toml

为什么必改：cgroup 是 Linux 给进程分配/限制资源（CPU、内存）的机制，k8s 的 requests/limits 全靠它。 cgroup 有两种"管理员"：cgroupfs（传统写法）和 systemd（Rocky 9 等现代发行版由 systemd 统一管理）。 一台机器只能有一个管理员——kubelet 用 systemd，containerd 默认却是 cgroupfs（false），两个管理员各记一套账，会导致资源统计错乱、节点不稳定。这行 sed 把 containerd 也划归 systemd 阵营。

6.3 关键修改 2：certs.d 镜像代理（国内拉镜像的生存指南）

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


# Docker Hub 国内被墙，给 docker.io 配置镜像代理（daocloud）
# containerd 的 registry 配置采用 certs.d 目录（类似 docker 的 registry-mirrors）
mkdir -p /etc/containerd/certs.d/docker.io
cat > /etc/containerd/certs.d/docker.io/hosts.toml <<EOF
server = "https://docker.io"
[host."https://docker.m.daocloud.io"]
 capabilities = ["pull", "resolve"]
EOF
# 同理给 registry.k8s.io 配代理：它的 CDN 是 Google 的，国内同样被墙
#（kubeadm 装集群时我们改用阿里云源规避；但 ingress-nginx、metrics-server 等
# 第三方组件的镜像也在 registry.k8s.io，阶段 6/8 会用到这个代理）
mkdir -p /etc/containerd/certs.d/registry.k8s.io
cat > /etc/containerd/certs.d/registry.k8s.io/hosts.toml <<EOF
server = "https://registry.k8s.io"
[host."https://k8s.m.daocloud.io"]
 capabilities = ["pull", "resolve"]
EOF
# 启用 certs.d 目录（containerd 2.x 默认配置里 config_path 为空，指过去即可）
sed -i "/^\s*config_path = ''\s*$/s/''/'\/etc\/containerd\/certs.d'/" /etc/containerd/config.toml

原理：certs.d 是 containerd 的"仓库导航改写本"。它拉镜像时的决策过程是：

1
2
3
4
5
6


要拉 nginx:1.27
 ↓ 补全为完整地址 docker.io/library/nginx:1.27
 ↓ 查导航本：/etc/containerd/certs.d/ 下有没有叫 docker.io 的目录？
 ↓ 有！读里面的 hosts.toml：docker.io 的请求改走 docker.m.daocloud.io
 ↓
实际从 daocloud 下载，但镜像在本地的"户口本"仍登记为 docker.io/library/nginx:1.27

目录结构就是映射关系——要拉哪个仓库的镜像，就用哪个目录下的 hosts.toml：

1
2
3


/etc/containerd/certs.d/
├── docker.io/hosts.toml ← 拉 nginx 等 Docker Hub 镜像时生效
└── registry.k8s.io/hosts.toml ← 拉 k8s 官方组件镜像时生效

hosts.toml 三行的含义：

1
2
3


server = "https://docker.io" # 这份配置管哪个仓库（"户主"）
[host."https://docker.m.daocloud.io"] # 实际去哪拉（"代取点"，可写多个按顺序试）
 capabilities = ["pull", "resolve"] # 代取点只允许"解析+拉取"，禁止 push（安全）

最后那条 sed 是总开关：containerd 2.x 默认配置里 config_path = ''（空 = 根本不看 certs.d 目录），把它指向该目录，导航本才生效。

为什么这样设计，而不是别的办法：

❌ 直接改镜像名（把 nginx 写成 docker.m.daocloud.io/library/nginx）：镜像名写在全世界的 YAML、Helm Chart、kubeadm 生成的清单里，改不完也改不到；换代理时还要全局替换
❌ 配 HTTP 代理：多一个要维护的中间故障点，且企业环境未必有代理可用
✅ certs.d：只在一个地方声明映射，全世界照常用官方镜像名，拉取被悄悄改道； daocloud 挂了改两行 hosts.toml 换一家即可，业务零改动。本质是逻辑地址（镜像名）与物理地址（镜像站）解耦，对 kubelet/YAML/Helm 完全透明

registry.k8s.io 那份的必要性：阶段 1 装集群时核心组件可以换阿里云源，但 ingress-nginx（阶段 6）、metrics-server（阶段 8）等第三方组件的官方清单里写死了 registry.k8s.io 地址，不便改也没法改。配上这条，届时 kubectl apply 官方清单直接跑通。

6.4 关键修改 3：pause（sandbox）镜像指向阿里云（国内搭集群第一坑）

1
2
3


# kubelet 1.34 起改为从 containerd 获取 pause 镜像地址（旧的 --pod-infra-container-image 已失效），
# 而 containerd 默认的 registry.k8s.io/pause 的 CDN 国内被墙，不改会导致所有 Pod 卡在创建阶段
sed -i "/^ \[plugins.'io.containerd.cri.v1.images'\]$/a\ sandbox_image = \"registry.aliyuncs.com/google_containers/pause:3.10.2\"" /etc/containerd/config.toml

pause 容器是什么：一个 Pod 可以装多个容器，它们共享同一个网络命名空间（同一个 IP）。这个"共享"需要一个先行者先把网络命名空间创建好、占住位置——就是 pause 容器（沙箱容器）。每个 Pod 里都有一个看不见的 pause，几乎不占资源，但没它 Pod 无法创建。

问题链条：pause 镜像默认在 registry.k8s.io/pause（Google CDN，国内被墙）→ 老办法是 kubelet 参数 --pod-infra-container-image，但 kubelet 1.34 起该参数失效，改为从 containerd 的 sandbox_image 读取 → 不改的后果是所有 Pod 永远卡在 ContainerCreating。这条 sed 在该插件节下追加一行，指向阿里云镜像站（a\ = 在匹配行之后追加）。

三关总结：SystemdCgroup 让 containerd 与 kubelet 和平共处； certs.d 让 Docker Hub / k8s 官方镜像拉得到；sandbox_image 让 Pod 能创建。少任何一个，阶段 1 都会以不同的姿势翻车。

6.5 （按需）虚拟机直连出网被拦时：给 containerd 配代理

containerd 是系统服务，不读你终端里 export 的代理变量，必须用 systemd drop-in 单独配置（192.168.5.2 是 Lima 内置的"Mac 本机"地址，长期有效，排查思路见阶段 0（上）附录 A）：

1
2
3
4
5
6
7


mkdir -p /etc/systemd/system/containerd.service.d
cat > /etc/systemd/system/containerd.service.d/proxy.conf <<EOF
[Service]
Environment="HTTP_PROXY=http://192.168.5.2:7897"
Environment="HTTPS_PROXY=http://192.168.5.2:7897"
Environment="NO_PROXY=localhost,127.0.0.1,192.168.5.0/24,192.168.64.0/24,192.168.0.0/16,10.96.0.0/12"
EOF

⚠️ 配了这个代理后，将来直连恢复或 Clash 关闭时必须删掉它并重启 containerd （rm 该文件 && systemctl daemon-reload && systemctl restart containerd），否则 containerd 拉镜像全部失败。原则：代理配置和代理软件同开同关。

6.6 启动与验证

1
2
3
4
5


# 启动并设为开机自启
systemctl daemon-reload
systemctl enable --now containerd
systemctl restart containerd
systemctl status containerd --no-pager

验证：

1

ctr version # 能看到 Client/Server 版本号即成功

💡 镜像代理说明：配置后，所有 nginx、mysql 这类来自 Docker Hub 的镜像会经由 docker.m.daocloud.io 代理拉取，对 Kubernetes 完全透明（镜像名不用改）。如果 daocloud 将来失效，换其他可用代理地址改 hosts.toml 即可。 k8s 官方镜像仓库 registry.k8s.io 本教程网络实测可达，无需代理；如果你的网络不行，阶段 1 有阿里云替代方案。

7. 检查清单

进入下一阶段前确认：

1
2
3
4
5


swapon --show # 无输出（swap 已关）
getenforce # Permissive
systemctl is-active containerd # active
sysctl net.ipv4.ip_forward # = 1
lsmod | grep br_netfilter # 有输出

常见问题

Q: 第 6 步装 containerd / 拉镜像时网络不通？ containerd 是系统服务，不读终端环境变量。先按上篇附录 A 的分层法确认是不是"虚拟机直连被拦"，是的话用第 6.5 节的 systemd drop-in 给 containerd 配代理；将来 Pod 出现 ImagePullBackOff 也先怀疑这层。

Q: containerd 配置文件里的插件名为什么和网上旧教程不一样？ containerd 2.x 使用了新版配置格式（如 io.containerd.cri.v1.images），旧教程里的 io.containerd.grpc.v1.cri 是 1.x 的写法。本教程的 sed 命令两种都兼容。

附录 B：集群装好后如何验证（阶段 1 完成后使用）

进程活着 ≠ 集群可用，能跑起一个真 Pod 才是终极证明。按三层验证（虚拟机里、root 执行）：

第一层：节点状态

1
2


kubectl get nodes
# 期望：STATUS 是 Ready

第二层：系统组件 Pod 全部 Running（最关键）

1
2
3
4
5
6


kubectl get pods -n kube-system
# 期望：etcd、kube-apiserver、kube-scheduler、kube-controller-manager、
# coredns（2个）、calico-node 全部 Running 且 READY 是 1/1

kubectl get pods -A
# 不能有 Pending / CrashLoopBackOff / ImagePullBackOff

第三层：跑一个真容器（终极证明）

1
2
3
4
5


kubectl run nginx-test --image=nginx
kubectl get pods -w # 看到 Running 后 Ctrl+C（这步同时验证了调度、镜像拉取、pause 镜像、CNI）
kubectl get pods -o wide # Pod 拿到 IP = Calico 网络正常
kubectl exec -it nginx-test -- curl -sI localhost | head -1 # 期望：HTTP/1.1 200 OK
kubectl delete pod nginx-test # 清理

辅助定位（上面不正常时查）：

1
2


systemctl is-active kubelet containerd # 都应为 active
crictl ps | head # containerd 层面的容器（应有 pause 和业务容器）

判断标准速记：get nodes Ready → 集群成立；kube-system 全 Running → 控制面健康；自建 Pod 到 Running 且能 exec → 端到端真通了（也是本阶段 containerd 三个关键修改的验收）。若 kubectl 报 “connection to localhost:8080 refused”，说明 kubeconfig 没配，先做阶段 1 的 mkdir -p $HOME/.kube && cp /etc/kubernetes/admin.conf $HOME/.kube/config。

动手练习

查看 containerd 配置文件 /etc/containerd/config.toml，找到你刚改的 SystemdCgroup 和 config_path 两行。
查看 /etc/containerd/certs.d/docker.io/hosts.toml，理解镜像代理的配置结构。

下一步

➡️ 阶段 1：搭建集群（系列第 1 篇，即将发布——从这里开始正式安装 Kubernetes）

建站运维 02：服务器防爆破实战——fail2ban 部署全记录

Fri, 11 Sep 2026 16:25:54 +0800

环境：腾讯云轻量服务器 / Rocky Linux 9.4 / 2C4G 日期：2026-09-11 背景：服务器 iptables 里有一串 REJECT 名单（云主机安全组件在拦截恶意 IP），查日志发现过去 24 小时有 397 次 SSH 密码爆破尝试——说明我的服务器一直在被人扫。是时候上 fail2ban 了。

一、fail2ban 是什么

一句话：盯着登录日志，谁试错 N 次就把谁关进小黑屋。

工作机制分两半：

Filter（侦察兵）：实时监控日志（SSH、nginx 等），用正则抓「登录失败」事件，按 IP 计数
Action（执法队）：某 IP 在 findtime 窗口内失败达到 maxretry 次 → 自动往 iptables 写一条 REJECT 规则，封禁 bantime 时长

整个过程全自动，不需要人盯着。

二、安装（Rocky 9 / dnf 系）

1
2


dnf install -y fail2ban fail2ban-firewalld
fail2ban-client --version # 装到 v1.1.0

三、配置（/etc/fail2ban/jail.local）

不要改自带的 jail.conf（升级会被覆盖），新建 jail.local：

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


[DEFAULT]
# 本机 IP 永不封禁（防误伤自己）
ignoreip = 127.0.0.1/8 ::1
bantime = 24h # 封多久
findtime = 10m # 多长的观察窗口
maxretry = 5 # 窗口内失败几次就封
backend = systemd # 关键！见下方踩坑
banaction = iptables-multiport

[sshd]
enabled = true
port = ssh

[nginx-http-auth]
enabled = true

[nginx-botsearch]
enabled = true

踩坑：Rocky 9 上必须 `backend = systemd`

传统教程都写监控 /var/log/secure，但 Rocky 9 / RHEL 9 的 SSH 日志默认进 systemd journal，/var/log/secure 是空的或不完整。不改 backend 的话 fail2ban 会显示「No file is currently monitored」——看似在跑，其实在梦游。

启动

1
2


systemctl enable --now fail2ban
systemctl restart fail2ban

四、验证：别只看「启动成功」

服务 active ≠ 在干活。要验证三件事：

1. 日志源有没有盯上

`1`	`fail2ban-client status sshd`

关键看输出里的 Journal matches：

`1`	`Journal matches: _SYSTEMD_UNIT=sshd.service + _COMM=sshd + _COMM=sshd-session`

有这行 = 侦察兵真的在盯 sshd 的 journal。如果显示 No file is currently monitored，就是上面的 backend 坑。

2. 封禁链路端到端实测（重要！）

光看 status 不够，手动封一个测试 IP 验证整条链路：

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


# 203.0.113.99 是 TEST-NET-3 保留地址，随便用不会误伤真人
fail2ban-client set sshd banip 203.0.113.99

# 看 fail2ban 认账了
fail2ban-client status sshd
# Currently banned: 1 / Banned IP list: 203.0.113.99

# 关键：确认 iptables 里真的出现了拦截规则
iptables -L -n | grep -A2 f2b-sshd
# Chain f2b-sshd (1 references)
# REJECT 0 -- 203.0.113.99 0.0.0.0/0 reject-with icmp-port-unreachable

# 测完放出来
fail2ban-client set sshd unbanip 203.0.113.99

只有 iptables 里亲眼看到 REJECT 规则，才算部署完成。

3. status 输出字段怎么看

1
2
3
4
5
6
7
8
9


Status for the jail: sshd
├─ Filter
│ ├─ Currently failed: 0 ← 当前观察窗内正在试错的 IP 数
│ ├─ Total failed: 0 ← 启动以来抓到的失败总数（不追溯启动前的）
│ └─ Journal matches: ... ← 盯的日志源
└─ Actions
 ├─ Currently banned: 0 ← 此刻小黑屋里关着几个
 ├─ Total banned: 1 ← 历史累计（含手动测试那个）
 └─ Banned IP list: ... ← 当前名单

五、日常运维

1
2
3
4


fail2ban-client status # 看有几个 jail 在跑
fail2ban-client status sshd # 看战果（封了几个、是谁）
fail2ban-client set sshd unbanip <IP> # 误封了手动放人
tail -f /var/log/fail2ban.log # 看实时动态

六、后续加固路线

fail2ban 只是第一道防线，后面还排着：

SSH 密钥登录 + 关密码登录——做完这个，爆破直接归零（釜底抽薪）
安全组收敛——22 端口只对常用 IP 段开放
dnf-automatic 自动安全更新
登录成功告警——有人登上服务器立刻通知我

七、总结

部署成本：10 分钟
维护成本：零（全自动）
收益：397 次/天的爆破尝试，从「全靠密码强度硬扛」变成「试错 5 次关 24 小时」

公网服务器第一课：你以为是安静的小站，扫描器眼里是嗷嗷待宰的肉鸡。fail2ban 该装就早点装。