浅谈一家全球电商在Kubernetes环境上的CI/CD落地与实践

云原生技术生态近几年狂飙猛进，现已成为互联网公司的主流服务端技术栈。公司要快速响应市场变化和需求变更，就离不开自动化流水线进行编译、打包和部署，如何基于Kubernetes落地CI/CD就是DevOps团队需要解决的首要问题之一，同时也是衡量公司DevOps能力成熟度的重要指标之一。本文主要分享iHerb在Kubernetes技术栈中CI/CD落地的情况和实施过程中的一些经验总结。

背景

本人目前就职于一家全球电商公司，公司总部设在美国， 自1997年开办公司发展到现在，已经面向包括中国在内全球170多个国家和地区开放了线上购物电商业务。

对于这样的业务体量，在国内云应用才刚起步的时候公司早以开始使用一些大型云平台诸如AWS和GCP等来部署生产环境了。

而当Kubernetes问世之后，公司就开始尝试着使用Kubernetes来部署应用，并在这几年将一些原本用VM部署的应用迁移到了Kubernetes上，以适应更快的市场变化，以及以更快的速度开辟新的市场。

对于Kubernetes的特性、优点和优势在此就不做赘述了，本文着重论要论述的是我们在Kubernetes环境上的CI/CD落地和实践。

持续集成与持续交付

首先我们来温习一下CI/CD的理念。

持续集成是一种编码理念和一系列实践，可以促使开发团队实施小的更新并经常将代码检入版本控制存储库。由于大多数现代应用程序需要在不同平台和工具中开发代码，因此团队需要一种机制来集成和验证其更改。

CI的技术目标是建立一致的自动化方法来构建，打包和测试应用程序。通过集成流程的一致性，团队更有可能更频繁地提交代码更改， 更频繁、更早的集成意味着更早的发现问题。通过持续集成，可以及时发现和解决代码故障，提高代码质量，减少故障处理成本等等，从而实现更好的协作，提高软件交付质量。

CD则是在从持续集成结束的地方开始处理制品的持续交付，负责自动将应用程序交付到选定的基础架构环境。大多数团队都会使用多个非生产环境（例如开发和测试环境），所以需要CD流水线确保有一种自动化的方式将制品包推送到目标环境上。然后，CD自动化脚本可能需要重新启动Web服务器，数据库或其他服务，并执行一些必要的服务调用，或者在部署应用程序时遵循其他过程。

持续集成/持续交付（CI/CD）是一种软件开发实践。在流水线中若再加上如自动回归、性能测试等自动化测试环节，则可以帮助团队成员频繁、快速得集成代码，以测试他们的工作成果，从而尽快发现集成后产生的错误，最终为用户提供高质量的应用程序和代码。

持续集成（CI）和持续交付（CD）体现了一种文化，一系列操作原则和实践集合，使应用程序开发团队能够更频繁，更可靠地交付代码更新。所以CI/CD流水线是DevOps团队实施的最佳实践之一，也是衡量公司DevOps技术成熟度最重要的指标之一。

虽然大部分公司在使用Kubernetes之前就已经搭建了CI/CD流水线，而在业务迁移到Kubernetes环境上后，如何在Kubernetes上搭建CI/CD流水线就成了必须尽快解决的一个重要问题。

公司的Infra架构

首先给各位看下图：

Infra架构图

如上图所示是当前公司Infrastructure架构，最底层是多云平台，这样可以节省机房的运维成本。在云平台上同时在使用VM机和云厂商的Kuberneters集群，通过VPN将办公网络与云平台网络连接起来。

在每个Kubernetes集群之内，搭建了一些公用基础设施和应用比如nginx-ingress、Istio、Datadog、Promethues等等，再上面一层就是按照业务逻辑拆分成了各个namespace，以实现业务层的相互隔离。

CI

在看