10人团队的私有云原生平台建设：GitLab + k3s + Rancher + Harbor 全栈自动化部署实战

10人团队的私有云原生平台建设：GitLab + k3s + Rancher + Harbor 全栈自动化部署实战

面向中小研发团队的轻量级云原生平台实践：用有限服务器，构建代码托管、镜像仓库、CI/CD、Kubernetes 编排、可观测与发布治理的一体化平台。

一、为什么中小团队也需要私有云原生平台

很多中小团队在早期都会经历类似阶段：项目最开始只有几个 Spring Boot 服务，部署方式也很朴素，开发打包 jar，运维登录服务器，停止旧进程，上传新包，修改 Nginx 配置，再手动重启服务。

这种方式在服务数量少、发布频率低时尚可接受。但一旦系统进入业务增长期，问题会迅速放大。

例如，一个中等规模的电商系统通常会拆分出用户、商品、订单、支付、营销、库存、消息、网关、后台管理等多个服务。服务数量从 3 个增长到 10 个以上后，手工部署会带来几个典型问题：

1. 测试环境与生产环境不一致，线上问题难以复现；
2. 发布依赖人工操作，容易漏步骤、发错包、配错环境；
3. 回滚依赖备份包和人工判断，故障恢复慢；
4. 服务资源没有统一约束，容易出现某个服务吃满 CPU 或内存；
5. 缺少统一日志、监控和发布审计，问题定位成本高；
6. 新人接手系统时，需要大量口口相传的部署经验。

因此，中小团队并不是“不需要云原生”，而是需要一套**足够轻、足够稳、可渐进演进**的云原生平台。

本文选择的组合是：

GitLab + GitLab Runner + Harbor + k3s + Rancher + Helm + Prometheus + Grafana + Loki

其中，k3s 作为轻量 Kubernetes 发行版，适合资源有限的中小集群。k3s 通过 containerd 拉取镜像，私有镜像仓库需要通过 /etc/rancher/k3s/registries.yaml 配置，这一点在生产环境中非常关键。(docs.k3s.io)

GitLab Runner 使用 Kubernetes Executor 后，每个 CI Job 会在 Kubernetes 集群中创建独立 Pod 执行，天然具备隔离性和资源限制能力。(GitLab Docs)

Harbor 则提供私有镜像托管、访问控制、漏洞扫描、镜像复制和制品治理能力。Harbor 官方说明其定位是具备安全策略和 RBAC 能力的开源制品仓库，并支持漏洞扫描。(goharbor.io)

需要特别说明的是，很多旧文章会使用 Kaniko 构建镜像。但 GitLab 文档已经提示 Kaniko 不再维护，并建议使用 Docker、Buildah、Podman 等替代方案。(GitLab Docs) 因此，本文将生产推荐方案调整为 BuildKit / Buildah，Kaniko 只作为历史兼容方案说明。

二、总体架构设计

2.1 平台目标

这套平台要解决的不是“把 Kubernetes 装起来”，而是建立一条完整的软件交付链路：

代码提交 ↓ 自动测试 ↓ 镜像构建 ↓ 镜像扫描 ↓ 推送 Harbor ↓ Helm 部署到 k3s ↓ 健康检查 ↓ 灰度 / 回滚 ↓ 监控告警 / 日志追踪

最终目标是让团队做到：

• 开发不直接登录服务器；
• 测试环境和生产环境使用同一套 Helm 模板；
• 每次发布都有版本、镜像、提交记录和流水线记录；
• 服务可以自动扩缩容；
• 发布失败可以快速回滚；
• 镜像进入集群前经过扫描和准入控制；
• 平台本身可备份、可恢复、可迁移。

2.2 逻辑架构

┌──────────────────────────────┐ │ Developer │ │ Git Push / Merge Request │ └───────────────┬──────────────┘ │ ▼ ┌──────────────────────────────┐ │ GitLab │ │ Code / MR / CI Pipeline │ └───────────────┬──────────────┘ │ ▼ ┌──────────────────────────────┐ │ GitLab Runner │ │ Kubernetes Executor │ │ 每个 Job 动态创建 Pod │ └───────────────┬──────────────┘ │ ┌───────┴────────┐ ▼ ▼ ┌──────────────┐ ┌────────────────┐ │ Unit Test │ │ Image Build │ │ Maven / Node │ │ BuildKit/Buildah│ └──────────────┘ └───────┬────────┘ │ ▼ ┌────────────────┐ │ Harbor │ │ Registry / Scan │ │ RBAC / GC / SBOM│ └───────┬────────┘ │ ▼ ┌────────────────────────────────────────┐ │ k3s Cluster │ │ │ │ ┌─────────────┐ ┌────────────────┐ │ │ │ Ingress │ │ Application │ │ │ │ Traefik/Nginx│ │ Spring Boot Pod│ │ │ └─────────────┘ └────────────────┘ │ │ │ │ ┌─────────────┐ ┌────────────────┐ │ │ │ Prometheus │ │ Loki/Promtail │ │ │ │ Grafana │ │ Log Pipeline │ │ │ └─────────────┘ └────────────────┘ │ │ │ │ ┌──────────────────────────────────┐ │ │ │ Rancher Manager │ │ │ │ 集群管理 / RBAC / 应用管理 / 监控 │ │ │ └──────────────────────────────────┘ │ └────────────────────────────────────────┘

2.3 组件职责划分

三、服务器规划与容量设计

3.1 最小生产拓扑

对于 10 人左右团队，推荐最小生产拓扑如下：

如果资源更少，也可以将 GitLab、Harbor、Rancher 部署在同一台服务器上，但不建议长期这样运行。原因是 GitLab 和 Harbor 都对磁盘 IO 比较敏感，业务高峰期可能影响镜像推送、CI 构建和数据库写入。

3.2 k3s 单控制面与高可用选择

k3s 有两种常见部署方式：

第一种是单 server 节点，适合开发、测试、小规模生产。部署简单，但控制面存在单点风险。

第二种是多 server 节点，使用内置 etcd 或外部数据库实现高可用。适合对可用性要求更高的生产环境。

对于 10 人团队，建议分阶段演进：

第一阶段：1 个 k3s server + 2 个 worker 第二阶段：3 个 k3s server + 2 个 worker 第三阶段：业务和平台拆分为独立集群

不要一开始就追求复杂高可用。平台建设的第一目标是让交付链路标准化，而不是堆组件。

四、k3s 集群安装与基础配置

4.1 所有节点基础初始化

所有节点执行：

sudo timedatectl set-timezone Asia/Shanghai sudo apt update sudo apt install -y curl wget vim net-tools ca-certificates gnupg lsb-release sudo swapoff -a sudo sed -i '/ swap / s/^/#/' /etc/fstab cat <<EOF | sudo tee /etc/modules-load.d/k3s.conf br_netfilter overlay EOF sudo modprobe br_netfilter sudo modprobe overlay cat <<EOF | sudo tee /etc/sysctl.d/99-k3s.conf net.bridge.bridge-nf-call-iptables=1 net.bridge.bridge-nf-call-ip6tables=1 net.ipv4.ip_forward=1 fs.inotify.max_user_instances=8192 fs.inotify.max_user_watches=524288 EOF sudo sysctl --system

4.2 安装 k3s server

在 node-1 上执行：

curl -sfL https://get.k3s.io | sudo INSTALL_K3S_EXEC="\ --tls-san 192.168.1.10 \ --node-name node-1 \ --write-kubeconfig-mode 644" sh -

复制 kubeconfig 到当前用户：

<