背景
最近应用写的差不多了，该要部署了，准备搞个 k8s 集群去部署，学习一下新技术。
集群选择
回想起之前搞 k8s 多节点部署的痛苦，用 kubeadm，配置半天，难得搞好了，启动集群还有同时启动多个虚拟机。然后访问应用还有各种要注意的点。
这次就轻松一点吧，只要能实现集群部署目的就可以了。
-
首先，反正就在一台机器上面部署，搞多个虚拟机然后搞个“高可用”架构没啥意义，所以单机部署即可，也就是控制平面和工作节点都是同一台机器。
-
然后是集群的发行版的选择，目前大概有这么几个选择
- k8s
- k3s
- minikube
- kind
其中 kind 是在 docker 里面跑集群，由于不方便暴露服务（因为还要手动开放端口），所以先 pass 掉。
其次，minikube，比 kind 好一点，但还是同样的原因，所以没有选择。
然后是官方的 k8s 发行版，感觉啥都要手动来，其次有之前的心理阴影，所以最后选择了 k3s（
主要是因为这玩意有个很好用的界面）
集群搭建
我选择的方案是先搭建 k3s 平台，然后再在平台上面部署 rancher 平台。
k3s 搭建
这方面 官方文档 非常详细，文档有中文版本的，甚至安装源有专门的国内镜像，为 k3s 的团队点赞。
|
|
使用一行命令即可完成，安装非常迅速，不到一分钟服务就可用了。
rancher 部署
官方文档，这里使用 helm 部署，可能需要先安装一下 helm。
先安装依赖
|
|
然后就可以部署 rancher
|
|
记得要设置 hostname 为你将要访问的域名
访问 rancher 控制面板
访问之前 hostname 设置的地址，就可以打开控制面板了。
这里留意到，访问控制面板需要使用特定的域名，并且只绑定了默认的 80 和 443 端口，也就是说，在入口方面，集群有做一个根据请求的域名来路由到不同服务的功能。类似于 nginx 的反向代理，可以做到同一个 ip 地址，访问不同的域名返回不同的页面的。
Enjoy~~
碎碎念
起初是想部署在云上面的，想着用我买的垃圾的 99 一年的服务器做个控制平面，然后在家和在学校的电脑都做一个工作节点，统一在控制平面的管理下，并且相互备份，这样如果一边因为网络或者其他原因挂掉了，另一边也能补上。这样控制平面在云上，工作节点在本地，既保留了服务的高可用性，也充分利用了本地硬件的高性价比，算是个比较完美的方案。
然后现实很残酷，虽然文档上讲我的 2 核 2g 的垃圾满足 k3s 的最小需求，但是直接部署 k3s，cpu 直接接近 100%，然后硬盘也满载，估计是内存不足了，在狂刷交换文件了。也尝试过直接在 docker 里面部署 rancher，不过好像也是要部署一个 k3s 在容器里面，但 k3s 一直拉不起来，一直在不断重试，最后放弃掉这个方案了。
然后看了下给服务器加配置的价格，虽然 2 核 4g 也就两百块一年，估摸着就能跑集群了，甚至还能跑一点服务。但就凭我能不花钱就不花钱的精神，怎么能这么轻松的让云服务厂商把钱赚走了，所以加钱也是不可能滴。
如果不搞云，不搞公网访问，就自己一个人自己玩，着实没啥意思。所以还是用那个垃圾搞个了内网穿透。
就只用了学校里的一台机器，搭建了集群，然后对外提供服务。
内网穿透的方案选择上，就用了很熟悉的 frp，按照 frp 的 官方文档，很顺利的把 frp 注册成系统服务。
然后是外部的访问了，这边使用了 Caddy 做了前端，直接监听 80 和 443 端口，然后根据不同的路径转发到不同的后端上面去。
用 Caddy 主要用两点，一是希望不同的服务能够通过不同的域名访问，而不是通过 /<service>/api 这样的路径区分开来，这样以后有服务要迁移只需要改域名解析的地址就行了，不需要牵扯到原来的架构；二是需要 Caddy 提供的全自动的 Let’s Encrypt 证书续签功能，因为这一套下来搞的域名到好几层子域名了，好几个域，就算是通配符域名也不够用了，并且还要定期更新证书，每一两个月就搞一次，弄得人心烦意乱的。现在集群提供的 http 服务，通过 frp 加密中转到服务器，然后通关 Caddy 转发成 https 请求，也算是全程加密了。
目前整个系统也算是搭建好了，个人还是非常满意的，目前整个系统唯一的瓶颈就只有垃圾的 3m 的带宽限制了，不过经过测试，还是能跑到 300-400 左右的 QPS 的，大部分使用场景下都够用了。
在本地环境下，也做了一下极端测试，把 jmeter 的线程数拉到 4000，最多跑到了 1w-2w 的 QPS，当然了，这些都是没有数据库的情况下测出来的数据，绝大多数情况下，先遇到瓶颈的，肯定是数据库了。