K3s 站群架构设计
K3s 和面板刚装完，挂在免费空间的导航网就挂了……所以现在不得不先研究如何用 K3s 搭建站群了。
之前搭建网站一直是用 CyberPanel 或者宝塔面板，一键安装 Nginx、PHP、Mysql 和 Memcached 等等。但现在需要换到 K3s 集群来了，这和服务器是完全不一样的“底层逻辑”，所以结合 K3s 的特性，我对站群架构的设计有如下几个方向。
老套路：还是使用 CyberPanel 面板
还是使用面板，那么就很简单，只需要在 K3s 集群中开一个 Pod 装上 CyberPanel 的面板就行了，然后如何建站一切照旧。接下来只要考虑公网访问的 IP 和端口映射的问题了。
当然这个架构还要考虑数据库持久化的问题，数据库肯定不能装在 Pod 里，否则分分钟就无了……
新玩法：使用 K3s 部署各种服务
这个呢无疑是最优方案，使用 K3s 自己部署 Nginx、PHP、Mysql 等等，但这也无疑是最难学习和操作的，博主只能结合以下官方教程和 K3s 原理来逐步的深入推进
- 部署 Nginx 可以参考 Kuboard 官方教程：实战：部署 nginx Deployment
- 部署 Mysql 可以参考 Kuboard 官方教程：在K8S上部署mysql
- 部署 Wordpress 可以参考 Kubernetes 官方教程：示例：使用 Persistent Volumes 部署 WordPress 和 MySQL
俄罗斯套娃：在 K3s 集群中安装 CyberPanel 面板，然后在面板中使用 Docker 部署站群
因为不想还是用“老套路”，在短期内又玩不转“新玩法”，所以出此下策就想到了这种套娃式的架构……
翻译一下就是
- 首先在 K3s 集群中创建一个 Pod（可以理解为“容器”）
- 接着在 Pod 中安装 CyberPanel 面板
- 然后在 CyberPanel 面板中再使用 Docker（容器）
- 最后在 Docker 中再安装网站
由此就形成了一个俄罗斯套娃架构……
直观上看，就感觉这样会产生很多无用的资源浪费，例如我们只是使用了 CyberPanel 的 Docker 功能，但却需要安装整个面板。
还有就是这样完全违背了 K3s 的用途，在“容器”中安装“容器”，效率肯定低下不说，K3s 本身就是容器为什么还要套容器呢？
当然这也有一个好处且提供了一个新的思路，那就是：可以将静态网站和安装完成运行后不会产生新数据的动态网站（例如导航站）打包成 Docker 镜像，往后均以 Docker 的方式部署（其实博主早有此想法，只是一直没有很刚需就懒得弄了……）。
由此一来，往后网站服务器再出问题，或者需要迁移网站时，只需要拉取 Docker 镜像再部署就完事了，不用每次再配置 Wordpress 等等（没错博主的导航站就是 WP 的），可以省去大量配置时间并且也降低了出错的可能性，而且万一有什么问题（例如被渗透了）也可以随时删除容器重建。
此种方式也需考虑数据库持久化的问题，原因同第一个架构。
俄罗斯套娃引申出的“非套娃版”：每个网站部署一个 Pod
这个架构呢由上述架构的思路而来，意思就是每个网站都部署各自的 Pod，互不干扰。简单的将整个 K3S 当作一个 Docker 管理器，然后为每个网站创建一个 Docker，这样做呢也是利用了上一个架构的思路，即将网站制成 Docker。但是很明显存在几个问题
- 首先也是资源的浪费，假如有多个动态网站，无法共用同一个 PHP，每一个 Pod 中都需要安装 PHP
- 其次是违背了 K3s 的初心，如此使用和安装 Docker 管理器没有太大差异了，也就是差一个 Docker 不支持 Agent 的区别了
- 还有一个技术问题，因为前端没有 Nginx 作网站的“分流”，所有网站都共用一个 443 https 端口，所以得要给不同的 Pod 设置不同的公网 IP（这个能否实现博主还未考证）
但是这个架构可以快速的搭建起站群，弱化 K3s 的深层原理和运行机制，将 K3s 与 Docker 的优势相结合，既能便捷的拉取 Docker 镜像部署，又能利用 K3s 的节点调度资源，能在初学 K3s 还不清楚其机制时，完成快速部署并满足一定程度上的“高可用”。
但是由于之前提到的几个问题，这个架构可能也只能算是一个初学者的临时解决方案，并不适合深入研究和实现。
此种方式也需考虑数据库持久化的问题，原因同第一个架构。