【DevOps实战篇】原生Docker集群项目向Kubernetes移行
@TOC
推荐超级课程：
本篇博文，我将介绍我们的一个容器微服务架构方案下的项目从Docker Cluster移行到Kubernetes集群的实施步骤。 为了方便介绍，我将隐去项目名称，姑且叫这个项目为：X项目。
项目介绍
X项目是一个原生的 Docker CI/CD 平台，可以构建和运行成千上万个 Docker 镜像。
我们操作着数百个拥有复杂业务逻辑的 Docker 集群。作为一个平台，X项目 使用数十个微服务，每个微服务都可以独立更新，有时一天可更新多次。
为什么我们决定转向 Kubernetes？
Kubernetes（简称 k8s）是我们的首选，因为我们是 Google Cloud、GCR、Firebase 和其他服务的重度用户。 我们的产品完全与云解耦，这使我们可以在 AWS 和 Google 上运行客户集群。 从一开始，我们就得到了来自 Google 和 K8s 社区的大力支持。经过研究社区、功能和路线图，我们决定选择 Kubernetes，因为它具有强大的扩展性、稳定性和网络功能。 除此之外，我们还有一些特定的考虑。
我们希望有一个标准的部署机制
我们使用 Chef 和 Ansible 自动化了我们的微服务部署，但很快就显而易见，一些我们想要的功能，比如零停机、健康检查、自动扩展等，在实施时经常遇到 bug，经常阻碍我们推送代码并导致延迟。
我们不想让我们的 DevOps 团队成为唯一能够管理部署的人——在 X项目，我们一天推送十次，依赖 DevOps 团队很难。我们不希望只有我们的 DevOps 能够定制部署，而希望拥有一个灵活的 DevOps 环境，因为我们的开发人员不熟悉 Chef 和 Ansible。
我们希望通过一个标准 API 实现扩展 对于任何基于微服务的平台来说，在微服务级别能够实现扩展/自动修复至关重要。Kubernetes 提供了一个很好的通过 API 和命令行实现的方式。
我们还希望能够监控微服务 虽然我们使用 New Relic 监控代码，但是在微服务级别上并没有。另一方面，K8s 有一个易于使用的仪表板。
每个新的微服务都需要定制 由于部署是在 Chef 脚本中定义的这个事实，每个新的微服务都需要实际编码，这主要是由 DevOps 工程师完成的。
我们希望能够获得部署历史记录 这样我们就可以用它来执行回滚、问题隔离和其他活动。
我们希望能够轻松重新创建一个生产环境 以前，我们使用的是 docker compose，这与我们的生产实际情况非常不同。虽然在某些情况下它可能会有帮助，但通常效果并不理想；它对于分级环境来说并不够好。 我们希望使用一个标准且简单的 API 根据需求创建新的环境。 我们现在可以为每个功能分支创建一个完全独立的 X项目 版本，这消除了在一个环境上进行集成测试的瓶颈。
我们是如何做到的？
准备：
我们在 GCE 中创建了一个 K8s 集群，并进行了实际培训和部署演示微服务，以涵盖所有用户案例并学习术语。
第一步——微服务定义
我们审查了我们所有的部署架构、现有的微服务、配置和安全规则，并决定如何将它们映射到 K8s Pod 和服务上。 Kubernetes 富有的部署选项（如对部署策略、就绪探查等的细粒度控制）帮助我们用一个更简单和可读性更好的配置替换了用于实现零停机部署的复杂内部解决方案
第二步——定义部署脚本
对于每个微服务，我们添加了一个包含服务和 POD 定义的 K8s 部署描述文件。
第三步——密钥和配置
配置管理——我们检查了应用程序配置，并将其拆分为两个部分；使用 Kubernetes 的密钥存储的敏感数据，以及使用 ConfigMaps 存储的常规数据。
我们希望有一个追踪所有配置更改的选项，并有一个快速恢复到之前版本的途径。为了实现这一点，我们决定加密并将所有配置存储在一个集中的存储库中，并使用 X项目 的流水线自动化推送更改到 Kubernetes。
我们的团队不会直接通过 Kubernetes 的 API 或 CLI 更改 Secrets 或 ConfigMaps。相反，我们使用 git 来追踪和加密更改，并使用 X项目 的流水线将它们发布到生产环境。
第四步——负载均衡
我们用一个简单的 ingress 控制器描述文件替换了以前的负载均衡复杂解决方案。
第五步——自动化和测试：
X项目 团队使用 X项目 来构建、测试和部署 X项目（自己动手吃自己的狗粮！），因此我们建立了一个 Kubernetes 部署流水线，将来自主分支的微服务推送到一个专用的命名空间。我们使用相同的机制在内部部署，提供给我们的用户直接使用的 K8s 部署。
我们进行了负载测试，并在向我们的客户公开之前将自己迁移到了 K8s。
第六步——培训 KT
所有开发人员进行了一次 Kubernetes 实践会议，这样他们就可以轻松推送并执行回滚、热更新等操作。 一旦我们测试过所有东西，我们就将所有客户管道和环境后端迁移到了 K8s。
结语
将我们的部署迁移到与 K8s 配合使用的结果中最积极的一点是，我们几乎没有部署问题。一切都是标准的和稳定的。控制我们的生产环境保持在一个可预测状态的能力得到了显著提高。
我们能够在几秒内创建一个完整的 X项目 环境，实现了100% 的自动化。这显著提高了我们及时获取反馈、运行集成测试等的能力。