我 VPS 上跑了几个小服务，部署方式从最早的手动编译、yum ，到 Docker，最近又开始折腾 k8s。每个时期都有不同需要折腾的地方，这半年在AI的帮助下我从docker compose、dockerfile逐渐迁移到了k8s\k3s，在此做一些记录。

对于没多少人访问的个人自托管应用，我认为最合适的部署方式是docker，单节点、持久化更方便部署，日志相对易读易找，遇到问题更容易排查。

小城市没有合适的岗位，技术不用会手生，索性把我自己的服务用上k8s/k3s，在AI的辅助下维护成本没有明显增加。

先尝试的k8s

1台低配vps做LB，加上3台4c8g配置的vps，一台master&worker+两台worker
使用kubeadm进行部署，etcd+calico+coredns+cert-manager+longhorn
访问请求先进入LB的HAProxy，根据我配置的roundrobin，轮询使用三台vps进行处理。
在指定给某台vps之后，traefik+ingress转发到具体的serivces，再进入服务的pod。
服务单副本，部署的时候手动进行指定，longhorn配置的三副本。

几年前我通过编译安装过，当时没有AI，编译安装需要手动同步所有的秘钥，异常繁杂，这次在chatgpt的帮助下，安装的较为顺利。

遇到过一个问题，部署traefik出现pending

日志: didn't have free ports for the requested pod ports

排查:
kubectl get pod -A -o wide | grep traefik
kubectl describe pod -n traefik

坑就是服务的端口释放顺序叠加nodeselector/affinity，导致新服务一直pending，需要先删除旧的pod释放端口，再起新的pod。

维护了几周k8s，感觉过于过程化了，对于比较小的应用没有必要上k8s，并不能发挥集群和ELK的优势，服务部署上去之后RAM捉襟见肘，排查错误只能靠手敲命令，费时费事，就退而求其次降级到了k3s。

我只用了两台vps部署的k3s，没有LB

一台做control-plane，一台做worker

安装时禁用了内置的traefik，两台节点搭建完成后再补齐的traefik、cert-manager、longhorn、crowdSec、argocd

刚开始通过helmfile模版部署应用，结构大约如下：
helmfile.yaml
charts/
web-app/
templates/
values/
服务名.yaml

后来为了方便维护，尝试使用argocd自动拉取github仓库的配置，自动同步到k3s集群，每个服务一个 ArgoCD Application
已经通过argocd管理的服务如下：
trendradar
gitea
wordpress
it-tools
searxng
filecodebox
portainer
rclone
kasten-k10
qbittorrent
emby
grafana
sillytavern

关于AI辅助部署、维护方面，我也是从chatgpt网页、chatgpt app过度到了hermes+deepseek v4 flash，这方面的心得等我另起一篇再聊。

现在两台vps的ram占用在50%-60%左右，nezha有漏洞下线了，Prometheus+grafana太重不适合我，暂时用portainer和本地的lens做集群面板，监控使用hermes。

以下是通过chatgpt生成的集群拓扑示意图