一、我的服务器基础画像如下
1.1、系统基础信息
| 项目 | 值 | 说明 |
|---|---|---|
| 实例规格 | ecs.e-c1m4.2xlarge | 8核 CPU / 32GB 内存，适合运行 k3s + GitLab |
| 公网 IP | 39.107.52.178 (EIP) | 按流量计费，带宽上限 5Mbps |
| 内网 IP | 172.22.182.143 | VPC 内通信地址，k3s/GitLab 内部交互用此 IP |
| 操作系统 | Alibaba Cloud Linux 4 LTS | 阿里云定制 Linux，兼容 CentOS/RHEL 生态 |
| 安全组 | sg-2ze27ckxl31wcblm2u4r | 控制出入站流量，后续开放端口需修改此处 |
| 付费方式 | 按量付费 (PostPaid) | 注意及时释放或转包年包月，避免意外扣费 |
| 可用区 | cn-beijing-h | 北京 H 区 |
| 项目 | 值 |
|---|---|
| 主机名 | iZ2ze9lq5rt17ufbrhjef8Z |
| 操作系统 | Alibaba Cloud Linux 4.0.5 (OpenAnolis) |
| 内核 | 6.6.102-7.alnx4.x86_64 |
| 虚拟化 | KVM (阿里云 ECS) |
| 运行时长 | 46 分钟（刚重启不久） |
| 负载 | 0.17 / 0.24 / 0.28（低负载，健康） |
1.2、计算资源
| 资源 | 规格 | 使用情况 |
|---|---|---|
| CPU | Intel Xeon Platinum, 4核8线程 | 低负载 |
| 内存 | 30 GiB | 已用 10G / 可用 19G（33%） |
| Swap | 未配置 | ⚠️ 建议配置 2-4G swap 作为内存溢出保护 |
1.3、网络
| 接口 | IP | 说明 |
|---|---|---|
| eth0 | 172.22.182.143/20 | 主网卡 |
| flannel.1 | 10.42.0.0/32 | k3s CNI overlay |
| cni0 | 10.42.0.1/24 | Pod 网桥 |
| docker0 | 172.17.0.1/16 | Docker 残留（DOWN 状态） |
1.4、对外暴露端口
| 端口 | 服务 | 风险 |
|---|---|---|
| 22 | SSH | ✅ 正常 |
| 6379 | Redis | ⚠️ 绑定 0.0.0.0，无认证风险高 |
| 8060 | Nginx (GitLab) | ✅ Web 服务 |
| 8080 | Nginx | ✅ Web 服务 |
1.5、运行的核心服务
| 服务 | 进程 | CPU% | 内存 | 说明 |
|---|---|---|---|---|
| GitLab | puma + sidekiq + gitaly | ~18% | ~2.2G | 自建 GitLab（非容器化） |
| k3s | k3s-server | 7.1% | 724M | K8s 控制平面 |
| Jenkins | java (jenkins.war) | 1.5% | 1G | CI/CD（k3s Pod 内） |
| 业务应用 | java (app.jar) | 3.0% | 644M | yudao-server（k3s Pod 内） |
| containerd | containerd | 0.9% | 185M | k3s 容器运行时 |
| 云监控 | argusagent | 0.9% | 38M | 阿里云云监控插件 |
1.6、发现的问题与建议
| 优先级 | 问题 | 建议 |
|---|---|---|
| 🔴 高 | Redis 6379 监听 0.0.0.0 | 立即改为 bind 127.0.0.1 或配置密码认证 |
| 🟡 中 | 未配置 Swap | 添加 2-4G swap 防止 OOM |
| 🟡 中 | docker0 网卡残留 | 如不使用 Docker，可卸载清理 |
| 🟢 低 | 系统刚重启 46 分钟 | 确认是否为计划内重启，检查重启原因 |
| 🟢 低 | 多个 Pod 有重启记录 | 已在上一轮检查中提示，建议排查日志 |
二、磁盘与存储
磁盘与存储开始。这是服务器的"地基"，了解数据存在哪里，后续排查问题、备份迁移才不会迷路。
| 分区 | 大小 | 已用 | 用途 |
|---|---|---|---|
| /dev/vda3 (ext4) | 40G | 22G (59%) | 根分区 + k3s Pod PVC 数据 |
| /dev/vda2 (vfat) | 200M | 6.3M (4%) | EFI 引导分区 |
查询当前实例下所有磁盘的挂载信息：
调用工具：describe_ecs_disks · 已完成
你的服务器目前只有 1 块系统盘，没有额外挂载数据盘：
| 项目 | 值 | 说明 |
|---|---|---|
| 磁盘类型 | ESSD Entry（云盘入门级） | 性能满足基础开发测试，IOPS 2120 |
| 容量 | 40 GB | ⚠️ 偏小，GitLab + k3s + Jenkins 容易占满 |
| 设备名 | /dev/xvda | 系统盘，挂载为根目录 / |
| 随实例释放 | 是 | 实例删除时磁盘同步删除，注意备份 |
| 自动快照 | 已开启 | 有基础数据保护，但需确认快照保留策略 |
⚠️ 关键风险提示
40GB 对当前架构非常紧张：
- GitLab 自身数据 + 仓库存储通常占用 10~20GB+
- k3s 容器镜像 + Pod 持久化卷也会快速增长
- 系统日志、临时文件持续累积
建议后续考虑挂载一块独立数据盘专门存放 GitLab 数据和 k3s 存储，避免系统盘爆满导致服务崩溃。
三、查看实际磁盘使用率，确认当前系统盘的真实占用情况
df -h
| 挂载点 | 总容量 | 已用 | 可用 | 使用率 | 说明 |
|---|---|---|---|---|---|
/ (根分区) |
40G | 22G | 16G | 59% | ⚠️ 已进入警戒区间，剩余空间有限 |
/boot/efi |
200M | 6.3M | 194M | 4% | 正常 |
| tmpfs (内存盘) | - | - | - |
四、定位空间占用大户，找出到底是哪些目录在消耗磁盘
du -sh /* 2>/dev/null | sort -rh | head -10
空间占用 TOP3 目录如下：
| 排名 | 目录 | 占用 | 可能内容 |
|---|---|---|---|
| 🥇 | /var |
14G | GitLab 数据、k3s 容器存储、系统日志、缓存 |
| 🥈 | /usr |
4.5G | 系统程序、k3s 二进制、GitLab 依赖包 |
| 🥉 | /opt |
3.8G | 第三方软件（可能是 GitLab 安装目录） |
🔍 关键发现
/var占 14G（63% of used）：这是绝对大头，几乎可以确定是 GitLab 仓库数据 + k3s 容器镜像/存储卷的叠加。
/opt占 3.8G ：很可能是 GitLab Omnibus 安装目录（默认/opt/gitlab）。两者合计 17.8G ，占已用空间 22G 的 81%，印证了"GitLab + k3s 是主要消费者"的判断。
💡 新手知识点
/var：可变数据目录，存放运行时产生的数据（数据库、日志、容器存储等），最容易膨胀。
/opt：可选软件包安装目录，GitLab Omnibus 默认装在这里，相对静态。
/usr：系统核心程序，一般不应手动清理。
五、查询当前安全组的所有入方向和出方向规则，了解端口开放情况
调用工具：describe_ecs_security_group_attribute · 已完成
当前安全组入方向规则整理如下（出方向默认全放行，未列出）：
| 端口 | 协议 | 源地址 | 用途推测 | 风险等级 |
|---|---|---|---|---|
| 22 | TCP | 100.104.0.0/16, 60.247.72.98 | SSH 远程登录 | ✅ 低（已限制来源） |
| 80 | TCP | 0.0.0.0/0, 182.48.101.50, 60.247.72.98 | GitLab Web / HTTP | ⚠️ 中（公网开放） |
| 3306 | TCP | 0.0.0.0/0 | MySQL 数据库 | 🔴 高（公网完全开放） |
| 5432 | TCP | 182.48.101.50 | PostgreSQL（GitLab 依赖） | ✅ 低（已限制来源） |
| 6379 | TCP | 0.0.0.0/0, 182.48.101.50 | Redis 缓存 | 🔴 高（公网完全开放） |
| 8080 | TCP | 0.0.0.0/0 | Jenkins Web / 备用 HTTP | ⚠️ 中（公网开放） |
| 30325 | TCP | 0.0.0.0/0 | k3s NodePort 服务 | ⚠️ 中（k3s 暴露端口） |
| 30500 | TCP | 0.0.0.0/0 | k3s NodePort 服务 | ⚠️ 中（k3s 暴露端口） |
| 30730 | TCP | 0.0.0.0/0 | k3s NodePort 服务 | ⚠️ 中（k3s 暴露端口） |
| 30880 | TCP | 0.0.0.0/0 | k3s NodePort 服务 | ⚠️ 中（k3s 暴露端口） |
| 30881 | TCP | 0.0.0.0/0 | k3s NodePort 服务 | ⚠️ 中（k3s 暴露端口） |
| ICMP | ALL | 60.247.72.98 | Ping 测试 | ✅ 低 |
🚨 严重安全风险提醒
3306 (MySQL) 和 6379 (Redis) 对 0.0.0.0/0 开放 ：这意味着任何人 都可以从公网尝试连接你的数据库和缓存。即使有密码保护，也极易遭受暴力破解、未授权访问或数据泄露。强烈建议立即收紧为仅允许内网或指定 IP 访问。
80/8080 公网开放：GitLab 和 Jenkins 暴露在公网，需确保已启用 HTTPS、强密码及双因素认证。
💡 新手知识点
安全组 = 云上防火墙：控制"谁能通过哪个端口访问你的服务器"。
0.0.0.0/0：代表"所有 IP"，即公网完全开放。
NodePort (30xxx) ：k3s 将集群内部服务映射到宿主机端口的方式，外部通过
公网IP:30xxx访问。
六、检查宿主机上 GitLab 的运行状态
gitlab-ctl status
GitLab 所有组件运行正常
七、检查 k3s 节点与 Pod 健康状态
k3s kubectl get nodes -o wide
节点状态正常（Ready），接下来检查所有命名空间下的 Pod 健康状态。
k3s kubectl get pods -A -o wide
检查结果：k3s 集群整体健康
| 检查项 | 状态 | 说明 |
|---|---|---|
| 节点 | ✅ Ready | 1个控制平面节点，运行正常 |
| Pod | ✅ 全部正常 | 所有业务Pod和系统Pod均为Running/Completed状态 |