背景

私有部署在一些 TOB 的工具型企业中很常见，例如 神策、gitlab 、jira 、飞书 等等。

要私有部署服务，首先要解决运行环境的问题。

各企业的情况不同，能提供的环境也不一样。例如，有些企业只能提供物理机，系统随你装；有些企业只能提供特定操作系统的机器；有些企业希望提供 k8s 集群；有些企业提供的硬盘很拉胯；有些网络安全限制得特别严……

如果我们希望自己的实施同学轻松点，最好是提供一种统一的、不选择平台的部署方案。

简单场景下，我们可能会想到 docker； 如果有简单的编排需求，我们可能会想到 docker-compose。

在大多数场景下，我们通过一台硬件条件不错的机器，使用 docker-compose 几乎都能满足需求。

但如果，客户希望你的服务保证高可用、希望服务具有扩展性、希望…… 好吧，如果你的服务确实很复杂，又不是很稳定(资源抢占……)，确实需要横向扩机器的话……

那么可以考虑 k8s 集群。

部署一套 k8s 集群

简单的集群部署

之前在 网络受限环境k3s安装记录 中记录过离线环境的 k3s 的安装，这只是简单的单个机器的 k3s server 安装，如果要安装集群，还需要在其他节点也做同样的操作，只是最后的命令需要改成 join。

这种场景，使用 autok3s 还是很有优势的。

稍微复杂一点的集群部署

当创建的集群节点比较多，且部署必须为离线部署时，则会遇到镜像多处拷贝的问题。解决的思路有两个：

1. 使用 ansible 工具，将 copy 的过程自动化
2. 使用 docker-registry 的方式

这里推荐使用 docker-registry，因为更容易理解。在使用时，先把 docker-registry 的镜像放到 containerd 默认的镜像目录，再把 docker-registry 的 manifest 放到默认的 manifest 下。

这样就能解决镜像一处更新的问题了。

将部署分成两个步骤： ① 创建基础集群 ② 部署业务应用

sealer 的理念还是不错的，把集群进行打包，处处运行。 整体类似于 kubeadm 和 helm charts 的集合，以及做了镜像的管理。在一些场景下也是不错的方式。但目前来看，稍微有点 黑盒 了，没有直接使用 helm charts 来得清晰，或者说对实施同学而言，掌控感 略微不足。 对于一些希望使用自由 k8s 集群等情况时，就显得灵活性不足。

在部署了集群之后，就需要解决 集群管理、应用基础设施、应用部署 的问题。

集群管理

集群的管理主要是指：

1. 节点增删
2. 集群资源修改
3. 集群基本信息查看

这类问题，可以通过一系列的 dashboard 解决，参考 记一次k3s环境搭建记录 和 网络受限环境k3s安装记录

应用基础设施

应用基础设施，主要指 存储、监控、日志。
存储可以参考 nfs、localpath作为k8s-storage-class

监控的方案主要有两类， promethues 类 和 elastic 类，可以参考 简单的集群监控方案

日志的方案，主要有 ELK 和 EFK 两种常用的 ( logki 体系也可)，我选择 fluentbit，更多信息可以参考 简单的集群日志采集方案

应用部署

终于到了业务应用的部署环节。如果业务是无状态服务，那么很简单，直接找个业务低峰时进行镜像更新即可。如果为有状态服务，没有版本兼容问题还好处理，如果遇到版本不兼容就比较麻烦一点了，需要进行状态清洗或转换的操作。

私有部署中，针对不同的企业一般有一些独特的配置项，这些配置项需要独立出来。
一个常规的 helm charts 编写方式可以参考 常规的charts编写方式

对于 helm 的操作，可以参考 helm的一些简单使用

---

Don’t settle for a relationship that won’t let you be yourself.
— Oprah Winfrey