kind dev集群架构

和 NGINX服务 alpine-nginx 的Docker容器不同的是:

kind 运行示意图 显示 kind 的容器和我们的物理主机隔了一层 Node Container ，也就是说 User Pod 不能直接将物理主机的 hostPath 挂载到容器内部(对应于 Docker 卷 )

最简单的方法是每次都重新制作镜像: 在 NGINX服务 alpine-nginx 基础上，每次都把 Sphinx文档 的 build 目录复制到镜 像中推送到 kind(本地docker模拟k8s集群) 集群的 kind集群本地Registry 部署(这通常是大型网站的标注部署方式)。不过，要模拟这种标准部署不是一个简单的操作(手工执行不算)，而是要集成 Jenkins 实现CI/CD的复杂架构。

备注

我在后续会尝试在 kind(本地docker模拟k8s集群) 中构建一个 持续集成 ( Jenkins )

所以，(我认为)更为简单的方式是采用 Btrfs NFS 输出 在Kubernetes中部署NFS :

  • 在 移动云架构 的物理笔记本上，只需要有任何更新，就立即通过 Btrfs NFS / ZFS NFS 直接更新 到容器内部输出

  • 不需要不断更新发布镜像，适合简单的小型部署

这种架构也是有局限性的:

  • 中心化的数据共享，如果出现中心存储故障(例如NAS故障)，会导致整个网站瘫痪

  • 中心化的存储往往是性能瓶颈，不能支持海量的容器并发访问

不过，对于目前我在笔记本电脑上运行的模拟架构中，上述NFS共享模型是一种比较简洁的模式。在模拟更为复杂的 移动云架构 中，则会采用 Ceph 来构建底层分布式存储。