我们有一个新客户，我们称其为X吧。尽管我们很想推荐我们的容器云整体服务，但是最后落地的还是双方都认为比较简单的人员派遣模式。我们派遣了一个有一定基础的 Kubernetes 工程师小h ，我叮嘱小h ，客户有什么任务要尽量在我们公司云原生团队里沟通，可能团队成员会提供一些帮助。
果然，不久之后团队成员便有了施展的机会。X安排小h通过 prometheus 实现所有资源的监控，包括主机和 Kubernetes 中的资源，并且有一个附加要求，希望有一个集中的 prometheus 服务保存所有数据。 小h很快便遇到了问题：一个 prometheus 能行吗？
简单的回答是“不行”。首先要考虑客户X的网络环境，客户X有自己的机房，有多个子网；也用了某公有云，存在多个 VPC。所以，第一个问题就是打通网络。prometheus 的默认模型是拉取，这与传统监控软件的推送模式并不相同。使用 prometheus， 需要保证 prometheus 访问位于各个子网和 VPC 的服务，如果没有预先规划好，这个需求可能就根本无法实现。另外，Kubernetes 中的 prometheus 也不像传统的相对静止环境里的 prometheus。Kubernetes 中的 prometheus 会根据集群中的服务的变化而动态改变监控的对象，放在 Kubernetes 之外的 prometheus 想实现这个目标还需要不少额外的工作。
根据上述情况，我们团队为客户X制定了这样的 Prometheus 部署方案：
- 每个 VPC 和内网环境，部署一套 prometheus 监控主机资源。
- 每个 k8s 集群，配置一套 prometheus operator 监控 k8s 集群资源。
- 打通 prometheus 的监听端口的网络连接。
- 配置 grafana 链接所有的 Prometheus 。
- 配置 prometheus 监控告警和事件告警。
另外，在这个问题的解决过程，中客户X也意识到对基础网络环境和 Kubernetes 集群缺乏规划，希望我们团队可以提出整改意见。如果我们真的希望将容器云当作我们主要的基础运行环境，这些问题确实需要慎重考虑的，会对今后的发展带来很大的影响。想要做好规划，对人员技能的要求会很高。一方面要了解传统网络、公有云和私有云网络，也需要精通 Kubernetes 基础组件的要求和能力，还需要知道与 Kubernetes 配合的其他产品的能力。许多私有云和公有云厂商会帮我们在基础设施层面做好规划，但是绑定在某个厂商并不是一个好的选择，况且我们客户一般都涉及多种环境，需要自己做好规划。
不过，通过对客户X认识的不断深入，我们发现客户X还有许多可以改进的地方。例如，客户的 CI/CD 流程是开发人员建设的，实现方法很质朴，而且并不符合软件工程的最佳实践。更关键的是，不同的项目采用了截然不同的流程，让发布和部署显得很不标准。对此，我能理解客户X，这有多方面的原因。首先，有了 Kubernetes 之后，开发和运维的职责界限需要重新划分。其次，确实也缺少能够总领开发和运维过程改变的人才，很难制定并实现合适的软件发布流程。对于这方面的案例，我会在后面的文章中继续介绍。