用开源软件自建CaaS：创业团队容器化部署的完整指南

做了这么多年创业项目的技术支持，我见过太多团队在产品上线之后，栽在同一道坎上：服务部署还得靠手动登录服务器、拉代码、重启进程。等用户量一涨，几台机器环境不统一、版本对不上、回滚靠手工，事故跟着就来了。我跟他们说，这个阶段该认真考虑CaaS了，结果对方第一个反应就是——CaaS是什么？开源软件能自己搭一套吗？

这篇文章就是来回答这两个问题的。CaaS（Container-as-a-Service，容器即服务）在商业云平台里通常是按需购买的服务，但创业团队预算有限、数据希望留在自己手里，或者对服务商绑定有顾虑的时候，用开源软件自建一套CaaS是完全可行的路。我会结合我在几个创业项目里亲手搭过、也踩过坑的经验，把概念拆明白、把开源软件地图盘清楚、把选型和落地步骤讲透，最后把容易翻车的点一次性列出来。

1. 先把CaaS这词拆明白：它凭什么省下你的运维时间？

很多朋友把CaaS和Kubernetes划等号，这是最常见的误解。K8s是一个容器编排引擎，负责解决“容器该放到哪台机器、怎么调度、怎么保证副本数量”的问题。但CaaS的“即服务”含义要宽得多：你要有镜像仓库、要有访问控制、要有管理界面、要有资源配额、要有日志监控，甚至要能处理租户隔离。K8s只是其中一个部件，不是全部。

我用一个不算严谨但很好懂的类比：K8s是发动机，CaaS是一辆整车。发动机决定性能上限，但车还要有方向盘、仪表盘、安全气囊、倒车雷达。云厂商卖的托管Kubernetes，属于“整车租赁”，你拎包上车。而用开源软件自建CaaS，等于买了一批零配件自己组装，发动机用K8s或它的轻量版，仪表盘用Rancher或KubeSphere，后视镜用监控日志全家桶。零配件都是成熟的开源项目，关键是你得知道怎么组合在一起。

从业务价值上说，CaaS解决的其实是三个创业团队绕不开的问题。

第一个是环境一致性。传统方式下开发环境、测试环境、生产环境各有一套配置，光“在我机器上好好的”这句话就能耗掉一个下午。容器镜像把代码和运行环境一起打包，推到一个镜像站里，任何环境拉下来就是同一个样子，这是CaaS最底层的价值。

第二个是可重复交付。镜像一旦打出来就是不可变产物，这次发布用的是哪个镜像、哪个版本，是有记录的，回滚只是把Deployment里的镜像tag改回去。对没有专职运维的团队来说，这比“删了旧代码上传新代码”可靠太多了。

第三个是水平伸缩。业务量突然涨了，传统方式要么临时加机器、手动部署环境，要么在单机上榨性能。到了CaaS这层，加副本是一个声明式的动作，平台自动调度到可用节点上。不用提前预判流量，遇到活动高峰能扛得住，这本身就是省钱。

CaaS和PaaS、Serverless的边界也值得说一句。PaaS连语言运行时都给你规定好了，你得按它的框架写代码，自由度低；CaaS只需要你把应用打成镜像，平台不管你用的Java还是Go。Serverless则是连“实例”的概念都省了，按调用计费，但对常驻型业务反而不划算。创业团队最有价值的组合，其实是保留CaaS的灵活性和资源边界感——你知道自己用了多少节点多少内存，成本是可预期的。

2. 自建CaaS的开源地图：四个层次由浅入深

开源世界的CaaS相关项目非常庞杂，一上来容易看花眼。我习惯把它们分成四个层次来看。每层解决一类问题，你按需组合，不用全上。

2.1 编排层：K8s本体和轻量替代品怎么选

这一层是核心，负责容器的调度、副本控制、服务发现。

完整版Kubernetes是绕不开的基准，但“K8s本体”还有几种不同的部署和维护路径。kubeadm是官方推荐的部署工具，灵活度高，想怎么定制就怎么定制，代价是你得自己处理证书、升级、备份这些日常运维问题；RKE2是Rancher团队维护的K8s发行版，强调安全和离线部署，和Rancher平台配套很顺；k3d和minikube主要给开发机用，严格说不是生产方案。

创业团队我最推荐重点考察的是K3s。它不是玩具，而是面向低资源、边缘场景的轻量K8s发行版，官方一条命令就能装好。它把K8s的控制面组件压进了一个单进程，内置了containerd、CoreDNS、本地负载均衡、Ingress控制器，默认还启用了Helm。4核8G的内存机器就能跑得很舒服。K3s的API是完整兼容K8s的，意味着你今天写的Deployment、Service、Ingress，以后换到完整版K8s也可以平移，不会锁死。

2.2 镜像与制品层：从裸Registry一路聊到Harbor

很多人把镜像仓库当成“放镜像的地方”这种配角，其实在CaaS里，镜像仓库是供应链的关键卡点。没有镜像仓库，整个容器化流程转不起来。

最基础的Docker Registry，功能就真的是存和拉，没有UI、没有权限管理，只适合个人开发时临时用。创业团队我建议直接跳过。

Harbor是目前企业级镜像仓库里最值得投入的。它基于Registry但做了大量扩展：项目隔离、RBAC权限、镜像漏洞扫描（内置Trivy）、镜像签名、不可变镜像、跨环境复制、审查日志，基本把生产需要的功能都覆盖了。Harbor对资源的要求也比裸Registry高不少，建议至少给2核4G，数据库和Redis都包含在部署里。但换来的是不用后期再补课。

如果你的场景只是边缘机房缓存镜像、资源极紧张，可以看Zot。它走OCI Distribution规范，内存占用在百兆级别，启动飞快，特别适合当Harbor和集群之间的二级缓存。但Zot的生态和周边能力还在成长中，核心镜像仓库还是用Harbor稳。

2.3 平台与管理层：Rancher、KubeSphere、Portainer谁是合适的管家

装好K8s只是有了发动机，你还得有个能操作、能观察的“方向盘”。

Rancher是老牌的多集群管理平台，背后维护着RKE2，UI成熟，有应用商店，国内外的运维群体都很广。如果你的K8s知识主要来自官方文档，Rancher能把你从频繁敲kubectl的操作里解放出来，多集群的Kubeconfig切换、权限管理、监控告警都能在网页上完成。

KubeSphere是国内团队青云出的，定位是“以应用为中心”的容器平台。它不只是管理K8s，还把DevOps流水线、日志、监控、告警、微服务治理、多租户都整合进来了。文档是中文的，对国内团队尤其友好。如果你想要一套“装完就什么都不缺”的平台，KubeSphere符合这个预期，代价是组件齐全之后资源开销也上去了，需要一台配置不错的机器。

Portainer是另一种思路，极简、够用、不到二十分钟能跑起来。它本身不仅支持K8s，也支持Docker和Swarm。对只有一两个人维护基础设施的团队来说，Portainer能看节点状态、能部署容器、能看日志，已经比ssh上服务器敲命令高出一个时代了。它不试图成为K8s全家桶，但作为创业初期的管理窗口非常称职。

三者的选型逻辑很清楚：团队小、追求最快跑通，选Portainer；团队专职运维人手有了、要管多环境多集群，选Rancher；想要集开发运维监控于一身的统一平台、且能接受资源开销，选KubeSphere。

2.4 应用交付层：GitLab、Argo CD、Tekton这些到底要不要配齐

CaaS跑起来之后的第二个关键问题是怎么把代码变成镜像、再把镜像发布到集群里。开源世界的交付工具五花八门，但并不是都要上。

GitLab CE可以承担代码仓库和CI/CD，一体化程度高，一个工具把push代码、跑流水线、出镜像都包了。Gitea或Forgejo则完全是轻量路线，三五个人用非常顺，但CI能力需要额外配Gitea Actions。

Argo CD是GitOps风格的工具，简单说就是“以Git仓库里的声明为唯一事实来源”，集群里的状态会不断向仓库里的配置看齐。它最大的价值是发布过程可审计、回滚只需改回commit。创业团队如果服务发布频率高，Argo CD值得优先考虑。

Tekton是K8s原生CI/CD框架，灵活度极高，但也意味着它不给你现成的界面，什么都得自己拼。如果团队里没有对云原生工具链极熟的人，可以先不碰Tekton。

我的观点是：交付层是CaaS里最没有标准答案的部分，不要一开始就追求全家桶。刚开始，用GitLab CE跑通“push代码->构建镜像->推Harbor”就够了，发布动作可以手动kubectl完成。等服务多了、要保证环境间一致了，再引入GitOps工具，那时你已经有了一套稳定的镜像流，过渡会很平滑。

3. 创业团队照着用的选型：不同阶段不同资源下的组合方案

光有软件地图还不够，关键是“我现在这个阶段到底该上哪套组合”。我按照创业团队最常见的三个发展阶段，给出可以直接照抄的选型方案。

3.1 冷启动阶段（1-3人）：一切从简，但底线不能破

这个阶段的特征是：没有专职运维，开发后端兼任所有基础设施，机器就一两台，业务刚上线，流量可预期地不会太大。我推荐的组合是：

这个组合可以在4核8G的单机上跑起来。Harbor的镜像扫描会在推送时消耗一点CPU，但完全可以接受。Portainer让不熟悉kubectl的同事也能直观看到服务是否存活。底线是什么？镜像仓库和etcd是所有状态的源头，不备份等于裸奔，这个阶段再忙也要先把快照脚本挂上。

3.2 产品验证阶段（5-15人）：你要的是一套可控的“小生产环境”

这个时候业务已经有了真实用户，可能同时有开发环境、测试环境、生产环境。后端团队里总有人需要花三成精力维护基础设施。我推荐的组合往“正规军”靠半步：

在这个阶段有个建议：把Harbor的项目按业务模块划分，比如pay、user、center，每个项目设置不同的拉取权限，机器人账号只给最小权限。这套权限体系早建早省事，等项目多了再去收口权限，会牵一发而动全身。

3.3 规模化阶段（20+人，专职DevOps 1-2人）：追求效率，但别盲目堆组件

到了这个阶段，你有专职运维或DevOps同学了，可以考虑把平台往“自动化”和“可观测”推进。除了上一阶段的组件，我会加上：

• 网络层换Cilium，用eBPF实现网络策略和可观测性，比Flannel高级一个档位。
• 存储按场景选Longhorn或Rook-Ceph。单机数据盘场景Longhorn更省心，多节点分布式存储再看Rook。
• 监控用Prometheus Operator和Grafana，日志用Loki，至少做到“任何一个Pod崩溃，告警能先于用户通知到人”。
• Keda可以加，让自动伸缩不再只看CPU，还能按消息队列积压量伸缩。

还有一类“低代码容器平台”值得看一眼：Sealos和Rainbond都在做“让开发者少关心底层”的事。Sealos的定位是云操作系统，把K8s管理、存储、应用商店都包进一套安装里；Rainbond强调“以应用为中心”，中文文档全，适合研发力量强但运维团队很薄的情况。如果你觉得Rancher加一大堆组件还是太重，可以拿这两个做评估。

4. 实操：从零搭一个最小可用的私有CaaS环境

理论说多了没用，我实际跑一套给你看。这个环境的组件是K3s + Harbor + Portainer + 一个Nginx示例服务。在4核8G的Ubuntu 22.04服务器上，按我的经验，四个小时足够，熟练的话更快。

4.1 准备阶段：服务器的域名规划

首先明确一件事：Harbor作为镜像仓库，推荐使用域名而不是IP。原因不是玄学，而是镜像的tag里如果有IP加端口，以后更换服务器或迁移域名，旧镜像的地址全部要重新打tag。提前用一个registry.example.com域名（内网DNS能解析即可），后面会少很多麻烦。

服务器准备时预留这些端口：

• 80/443：K3s自带的Traefik Ingress用
• 30002：Harbor的HTTP访问端口（特意避开80，避免和Traefik冲突）
• 30080：示例服务的NodePort访问端口
• 9443：Portainer的Web访问端口

实际生产环境建议把Harbor放到Ingress后面走HTTPS，但内网测试阶段先NodePort跑通，不要因为证书问题卡住流程。

4.2 安装K3s：一条命令背后的逻辑

在服务器上执行：

curl -sfL https://get.k3s.io | sh -

这是K3s官方的一键安装脚本。安装完成后，验证一下：

sudo k3s kubectl get nodes

之后所有kubectl操作可以走系统路径。K3s默认把kubeconfig放在 /etc/rancher/k3s/k3s.yaml，如果要从别的工作机远程管集群，拷贝它并把server地址改成服务器IP即可。

为什么选K3s而不是kubeadm在这套最小环境里？因为K3s一个命令就把containerd、CoreDNS、负载均衡、Ingress、甚至本地路径存储都内置了。我不用单独装容器运行时，不用配置额外的负载均衡器，省掉的是最容易被新手卡住的环节，换来的是一个完整可用的K8s主节点。

4.3 部署Harbor并让K3s信任私有仓库

去Github下载Harbor的离线安装包：

wget https://github.com/goharbor/harbor/releases/download/v2.11.0/harbor-offline-installer-v2.11.0.tgz tar xzf harbor-offline-installer-v2.11.0.tgz cd harbor cp harbor.yml.tmpl harbor.yml

编辑harbor.yml，关键配置改成：

hostname: registry.example.com http: port: 30002 harbor_admin_password: Harbor12345 database: password: root123

注意这里我把http端口改成了30002。默认的80端口会被K3s的Traefik占用，直接冲突。然后执行：

sudo ./install.sh

install脚本会检测docker-compose，没有的话需要先装。完成后，浏览器访问 http://你的IP:30002，用admin加刚才设置的密码登录。首先建一个library项目，再设置一个开发者账号或机器人账号，用于推送镜像。

接下来关键一步：让K3s里的containerd能够用这个私有仓库拉镜像。创建 /etc/rancher/k3s/registries.yaml：

mirrors: "registry.example.com": endpoint: - "http://192.168.1.100:30002" configs: "registry.example.com": auth: username: admin password: "Harbor12345"

把IP换成你自己的服务器地址，然后重启K3s：

sudo systemctl restart k3s

这个文件的机制是：containerd在拉取registry.example.com下的镜像时，先走mirrors里配置的endpoint地址，再用configs里的账号密码认证。很多人第一次搭自建仓库，最后卡在“kubectl拉镜像时X509证书错误”或“access denied”，根源都是registry配置没写对，或者低压环境里默认不信任非标准端口。

4.4 用Portainer接管可视化入口

Portainer的部署极其简单，服务器上执行：

docker volume create portainer_data docker run -d -p 9443:9443 -p 8000:8000 --name portainer \ --restart=always \ -v /var/run/docker.sock:/var/run/docker.sock \ -v portainer_data:/data \ portainer/portainer-ce:latest

这里有个细节：Portainer默认通过Docker socket管理Docker，但要管理K8s，需要让Portainer读取前面提到的k3s.yaml。方法是：启动Portainer后，浏览器访问 https://你的IP:9443，初始化管理员账号，在Environment添加Kubernetes环境时，把k3s.yaml内容粘贴进去，并填上API服务器的地址。Portainer会通过这份kubeconfig认证并接管K3s。

这一步做完，团队里不熟kubectl的同事就有了可视化操作界面，看Pod状态、查日志、改Deployment副本数，都像操作一个网页后台。

4.5 部署第一个业务服务的完整验证

先在Harbor里建好项目，然后在构建Nginx镜像的机器上登录Harbor并推送：

docker login registry.example.com:30002 -u admin -p Harbor12345 docker tag nginx:1.27 registry.example.com/library/nginx:1.27 docker push registry.example.com/library/nginx:1.27

如果登录时出现“insecure registry”报错，是因为Docker默认不信任HTTP非标准端口，在Docker daemon配置里加入insecure-registries：

{ "insecure-registries": ["registry.example.com:30002"] }

然后写一个Deployment和Service：

apiVersion: apps/v1 kind: Deployment metadata: name: demo-web spec: replicas: 2 selector: matchLabels: app: demo-web template: metadata: labels: app: demo-web spec: containers: - name: demo-web image: registry.example.com/library/nginx:1.27 ports: - containerPort: 80 --- apiVersion: v1 kind: Service metadata: name: demo-web spec: type: NodePort ports: - port: 80 nodePort: 30080 selector: app: demo-web

保存为demo.yaml，执行：

kubectl apply -f demo.yaml

浏览器访问 http://你的IP:30080，看到Nginx欢迎页，整套CaaS的最小闭环就通了。从代码变成镜像，到镜像被集群拉取，到服务对外提供访问，整条链路全部掌握在自己手里。

5. 我在创业项目里踩过的CaaS相关的坑

这套东西我搭了不止一遍，踩过的坑也算集中。挑五个对创业团队影响最大的写出来，每一个都是真实发生过的教训。

5.1 坑1：高估团队运维能力，全家桶一个月后无人维护

第一个项目我按“标准生产环境”给一个6人团队搭了完整K8s + Rancher + 一堆CNCF组件，花了足足一周。结果呢？业务需求一来，没人有空研究证书轮换、升级兼容性，半年后集群连小版本都不敢升，成了“爸爸级资产”。后来痛定思痛，重构成了K3s + Harbor，运维活两个小时内能理清。

教训是：基础设施的复杂度要和团队的实际运维精力匹配。创业早期的任务是活下来，不是建设“完美平台”。你选的技术即使看起来不够“工业标准”，只要它能让团队每天有精力投入业务，就是正确的选择。

5.2 坑2：镜像仓库没有漏洞扫描，差点带着CVE上线

Harbor默认安装了Trivy扫描器，但需要在项目中启用自动扫描策略。我有一次图省事没有开启，结果客户渗透测试时发现基础镜像里带了一个中危漏洞，虽然实际利用条件苛刻，但交付报告上写着就非常难看。从那以后，我的Harbor项目强制启用扫描，并在CI流水线里加了一道“扫描结果有高危漏洞就阻断构建”的检查。

Harbor的扫描本身会消耗一些CPU，但这点成本比起供应链风险完全可以忽略。不要等到出事才觉得扫描重要，它在安全上是真正的性价比之王。

5.3 坑3：etcd和镜像数据没有备份，一场误删教做人

有一次我排查问题时，误执行了删除整个namespace的命令，当时没注意那个namespace里还有一套服务的数据。K8s的etcd成了唯一的救赎，但因为没做etcd快照，只能靠代码重新部署，数据库数据直接丢失了一部分。那一次之后，我做了三件事：

• 每台服务器挂cron，凌晨对etcd做快照并保留最近7天；
• Harbor开启“复制”，把镜像同时复制到一台异地小机器上；
• 用Velero对关键namespace做定时备份。

恢复能力才是创业团队的真正保险。你不需要搞多复杂的备份体系，etcd快照加镜像异地复制已经能覆盖90%的灾难场景。

5.4 坑4：一开始就追高可用，反而拖慢了产品节奏

另一个项目，团队一上来就要求“必须高可用”，我搭了三节点K8s HA。结果就是：高可用集群的升级、网络、存储都比单机复杂两个档次，出问题时排查链路也长得多。对于日活几千的业务，三节点HA带来的价值远远抵不上它消耗的维护精力。

后来我把话跟团队讲清楚：早期单主节点加严格备份，能接受15分钟恢复时间，效果反而更好。什么时候值得上HA？当单节点故障造成的损失真实可感的时候。别让高可用成为一种解题思路，先解决业务验证的问题再说。

5.5 坑5：监控日志欠账，故障发生时全靠猜

最小化部署时我经常省略监控，省下来的资源后来都变成加班还了。有一个晚上服务突然响应变慢，我没有P99延迟曲线、没有错误率面板，只能一台台机器ssh上去看日志，花了一个多小时才大致定位到是数据库连接池爆了。如果当时有一个Prometheus加Grafana，五分钟就能把状态看穿。

创业团队最简单的可观测方案是：node-exporter看服务器CPU内存、cAdvisor看容器资源、Loki收日志、Grafana出面板，一套组合拳下来资源开销在1核2G以内。这笔账算下来绝对划算。

6. 面向创业场景的CaaS开源软件速查清单

最后给一份可以直接打出来贴工位上的速查表。所有软件我都结合“适合阶段、上手难度、维护活跃度”做了标注，方便你按当前处境做决策。

这张表怎么用？我的建议是：先找到你的阶段列，横向组合出最小闭环，其他一律后置。比如你现在只有三个人，那就K3s + Harbor + Portainer先跑通，Grafana和Loki有时间就加，Argo CD完全可以等发布频率上来了再谈。别怕以后迁移，K3s的API和K8s一致，你的YAML文件积累下来就是最宝贵的资产，换平台只是换运行底座。

过了热度，再回头聊一点个人体会。我在几个创业项目的过程中，最大的感受是：CaaS不是一个“技术名词”，它是一种把基础设施从成本项变成可重复资产的管理方式。开源软件给了你一个很低的起点，不用预付费、不用签合同、能在自己的机器上搭出接近云平台体验的容器服务。但它不免费——它收的是你的学习和维护时间。这也是我一直劝人的那句话：别一开始就追求最好的，先追求够用且能持续维护的。

如果你现在手里只有一台服务器，业务刚从“手工部署时代”往容器化过渡，我觉得最务实的起点就是K3s加Harbor。先把镜像流跑顺，把备份做好，把监控的基本盘铺上，后面的路自然就清楚了。一个小技巧：Harbor的垃圾回收任务，记得安排在周末凌晨低峰时段执行，否则清镜像的时候碰上业务高峰，IO抖动会直接体现在线上响应时间上。这行字看着小，遇到的时候就明白它是救命用的了。