爱番番携手基础架构部全面解锁Kubernetes
全文约4000字，预计阅读时间9分钟
前言
Linux 基金会执行董事 Jim Zemlin 曾说道：“我见证了开源圈子的两大事件：一个是 Linux 的成功，一个就是 Kubernetes 和云原生的大爆发。开源是历史上最成功的全球创新推动方式之一，Linux 已经成长为世界上最重要的软件平台，而云原生则在新时代以势如破竹之态爆发。”
2019年，随着云原生架构的相关讨论逐步热烈，云+AI已成为时代主流。在兴起的这股云原生潮流中，中国贡献巨大：中国的 Kubernetes 贡献者在全球排名第二，有超过 10% 的 CNCF 会员来自中国、26% 的 Kubernetes 认证服务供应商来自中国；云原生理念已经被国内的开发者广泛接受，进入到企业践行的阶段。
百度智能云云原生团队 2015年 开始了 Kubernetes 方向的投入，对于 Kubernetes 社区的开源贡献，百度在 2019年 进入全球前 10。但是纵观百度内部，主流服务是基于 matrix 的容器化部署，Kubernetes + Docker 尚未得到成熟应用。在企业服务领域，基于 Kubernetes + Docker 的开源生态已经成为主流技术架构。爱番番携手基础架构部云原生团队，深度合作了公司内部服务基于 Kubernetes + Docker 部署的推进，将全部爱番番线上流量切换到 Kubernetes ，经过2周多的观察，运行稳定。
如果阅读此文的你是一名研发侧的同学，正好也在计划将产品的技术栈往云原生方向去升级，那么你可能会关心爱番番为什么会选择 Kubernetes ？谁来帮我搞定 Kubernates 集群？迁移的工作量大么？有什么收益？那么接下来，我们将现身说法，针对大家可能关心的问题做个概述。
1. 爱番番为什么要选择Kubernetes
在 ToB 这个方向上，我们一直强调 “以客户为中心” 、“技术为产品服务、产品为客户服务” ，而 Kubernetes 则是技术达成为产品服务的基石。
随着爱番番业务的深化和推进的加速，原有技术框架暴露的一些问题越来越明显，我们从三个方面来阐述：
快速交付：
如何编排 200+ 模块的上线依赖并在 1个小时 内完成上线？
如何实现两周一迭代，一周两发布目标？
维稳降本：
如何实现长期保持稳定性 4个9 以上的目标？
如何减少上线期间的 pvlost ？
如何实现 2000+ 服务实例的全面可观察性与治理？
自研的部分微服务基础设施性能/稳定性/吞吐量存在不足，是该持续投入更多人力去改造还是想办法引入开源方案？
开箱即用：
如何实现爱番番( toB 产品)多样化售卖需求？
如何规模化，可复制的部署与运维，降低环境差异与心智成本？
我们的答案是采用云原生架构，建设云上爱番番，减少重复造轮子，加速客户价值点交付。
Kubernetes + Docker 的技术在业界已经非常成熟，CNCF 有非常全面的云原生技术来支撑我们对于容器化、CICD、应用编排、监控分析等方面的诉求，基于已有的开源组件和结合公司内的基础设施，我们能以较少的研发成本快速提升基础技术的能力，以达到支撑产品快速迭代的目标。
2. 爱番番和基础架构部协作方式
合作的模式为基础架构部（INF）的云原生团队提供 Kubernetes 的技术研发和支持，爱番番进行服务的升级改造和部署。我们的合作大致分为2个阶段：
第一阶段：Kubernates 的技术研发和集群部署，基础架构云原生团队完成 Kubernetes 适应内网环境的技术研发和集群部署。
第二阶段：爱番番服务部署和流量迁移，爱番番完成 100+ 个模块 Kubernetes 环境部署；按客户维度进行小流量，逐步完成 100% 正式客户流量迁移。
3. 爱番番迁移Kubernetes方案
迁移 kubernetes 面临的关键问题及解决方案。
3.1 多种类型和众多服务如何高效的部署
难点：差异化的基础设施对持续交付能力的挑战
基础设施：基础设施如何运维，保障高可用？ 镜像仓库如何管理？ 部署形态：如何零侵入业务的容器化？容器如何管理支持不同类型应用? 应用管理：k8s 平台上如何维护 10+ 资源？应用如何快速部署回滚？ CICD流：CICD流如何对接新的基础设施？CICD流如何进一步提升研发效能？
方案：标准化，自动化，云原生的CICD流程
名词解释：
适应内网环境的 Kubernetes + Docker 技术调研与方案设计，实现原平台/Kubernetes 两套同时部署，保证服务一致性，提升研发效率。
为达到快速交付的目标，首先要完成研发全生命周期的标准化，需要制定统一的标准与规范，支持多种类型应用。为了实现标准化，爱番番结合公司持续集成平台，并扩展完成三个核心环节，实现全自动化的 CICD 流程。
统一打包：基于统一的脚手架创建标准的应用包，通过统一打包服务完成应用包标准化为公司的 archer3 部署协议，可以无缝部署于其他平台。
统一容器化：将应用容器化的规则上移，避免容器化的规则散落在各个应用中，便于管理与维护。docker image build 的规则文件与业务源码完全解耦，定义到CI的流程环节中，根据应用的元数据信息，选择不同的 Dockerfile 模板文件构建镜像，docker image tag 的版本号根据 pipeline 的不同，识别 git commit log 并取前6位做镜像与源码的可追溯。
统一应用包：基于标准化的 helm chart 集成容器化镜像和管理统一应用k8s资源，在CICD侧准备统一且带版本号的 helm chart template，在应用集成时，通过上一环节容器化的名称与 image tag 进行有关联，实现了 deployment.yaml 的初步化，另一方面，借助于 helm chart 动态渲染模板和强大的配置能力，完成应用以不同的形态部署到不同的集群中。
除了关注标准化与自动化带化效率的提升，同时提供统一应用包管理，涵盖镜像、k8s 资源、以及环境等相关周边资源，进一步提升持续集成能力。
收益：业务零侵入，平均 10.6min 编译部署
实现 150+ 的应用基于流水线零成本的升级改造，完成容器化与统一应用包的部署，在应用覆盖面上，支持应用类型全覆盖，同时支持一键秒级回滚的策略，可以零成本快速扩展集群与环境。
3.2 平滑稳定的k8s迁移方案
难点：业务在高速增长，如何低成本且灰度迁移生产流量至 k8s 平台？
方案：统一流量入口、灰度引流、逐步转全和监控回切兜底
名词解释：
BFE : 百度统一应用层流量接入转发平台
BNS : 百度名字服务，用于满足服务间交互中常见的的资源定位、ip白名单维护等需求，也可以用于机器列表查询，使用场景包括机器列表查询、服务定位、白名单维护、数据库智能授权等
access gateway : 基于 OpenResty 构建的 k8s 集群的 API Gateway
BOS : 百度对象存储 BOS (Baidu Object Storage) 提供稳定、安全、高效以及高扩展存储服务
构建 k8s 统一流量入口为 access gateway，作为外部流量入 k8s 集群入口，集群内通过 k8s service 做服务发现，有计划按节奏逐步扩大灰度比例，直至转全。
通过公司统一的 BFE，实现客户粒度小流量和多版本的控制与路由，分钟级流量回滚方案以及正式流量逐步迁移的方案。
流量迁移到k8s关键步骤说明
k8s 部署预发布环境，验证通过
应用部署 k8s 和原平台同构的线上环境
配置 k8s Access gateway，将全部流量转发至原平台，Access gateway 验证通过
如果验证失败，在 k8s 环境中调试系统，直到验证通过，此过程不影响原平台流量
调整 Access gateway 的 sample 配置，将内部测试的客户 ID 流量下发至 k8s 集群，验证通过
如果验证失败，重复步骤5，直到验证通过
将 Access gateway 的 BNS 集群添加到网关BFE
增加转发规则，手动种 cookie，对于命中指定 cookie 规则的流量转发到 Access gateway，验证通过
将网关的 BFE 切换到 k8s 的 Access gateway，验证通过
如果验证失败，将 BFE 切回原平台的 API gateway 进行止损，分析原因，重复步骤7，直到验证通过
观察系统稳定性，直到验证稳定，需要确定同一用户流量，稳定落在同一集群
调整 sample 配置，进行租户粒度的小流量
逐渐扩大小流量比重，直至转全
收益：线上周稳定性保持 99.99% 以上
四个月时间内完成 150+ 应用，2K+ 服务接口改造以及线上服务全量转全。
部署架构进一步优化，统一收敛多个域名以及来源的流量，统一治理。
4. 迁移Kubernetes的收益
通过容器技术解决资源标准化，为后面服务化、自动化奠定了基础，同时业界统一的 kubernetes 平台，加速基础设计升级，具体收益主要包括：
迭代速度提升：实现两周一迭代，一周两发布目标。完成爱番番 100+ 应用及其依赖的技术组件在 Kubernetes + Docker 环境的运行改造，实现了从开发、测试、部署、运行、观察的全流程打通。
快速构建监控体系：打破之前基于 5-6 个公司内部自研产品对服务进行监控的现状，通过引入 Prometheus + grafana ，快速建设统一的产品健康度监控/观察平台。
低成本升级基础设施：云原生的微服务基础设施升级与落地，包括基于 config map 的配置中心解决方案、基于 EFK/Skywalking 的日志采集解决方案、基于 ElasticAlert 的日志预警方案，基于 Kubernetes 的统一流量入口，提高了系统稳定性和排查问题的效率。
5. 爱番番在云原生方向的规划
扩展服务类型：推进更多类型的服务迁移至 Kubernetes ，完成基于 Golang 的在线沟通、基于脚本语言的定时任务迁移至 Kubernetes。
释放红利：基于云原生架构的高可用，引入 Kubernetes 原生的服务注册、发现机制、自动扩缩容和自愈等能力。
高可用服务：多地域多集群部署，为不同地域的客户提供更好的客户体验，同时可进一步实现服务的单元化部署，提高系统的容灾能力。
高效服务治理：基于 Service Mesh 的微服务架构，可实现系统全链路的可观察，在服务的调用、重试、熔断、限流、降级等方面提供更强的控制能力。支持服务多版本，通过部署隔离、租户隔离，实现多版本发布、灰度发布。
自动化持续集成：基于 Kubernetes 的 CICD 工具链平台，实现多环境隔离、快速部署、一键发布、可视化运维管理等。
6. 基础架构部在云原生方向的规划
打造具有竞争力的云原生应用平台产品矩阵，支持更多产品接入。
他山之石，可以攻玉。爱番番始终秉持 “ 技术为产品服务 ” 的理念，拥抱开源，积极引入业界成熟、先进的技术解决方案，支撑产品的发展。在云原生方向，爱番番走出了第一步，未来，我们还将继续努力，充分利用 CNCF 开源社区的力量，持续提升产品的研发效率及系统稳定性，同时也希望看到更多的产品从云原生技术中受益。
7. 结语：拥抱云原生，加速价值创造
云原生是面向云应用设计的理念，帮助企业构建弹性可靠、松耦合、易管理可观测的应用系统，提升交付效率，降低运维复杂度，主要体现为三个方面：
k8s 平台红利的释放，充分发挥平台优势，将服务自治、故障自愈、快速弹性，自动扩缩容等能力落实到实际生产实践，降低运维复杂度。
引入与整合 service mesh 能力，打造服务治理平台，提供丰富强大的流量管控和服务路由的能力。
融合各项监控指标，建立统一的监控体系，将 metric , tracing 和 log 整合为一体，提供一站式的解决方案与服务能力。
围绕云原生体系，爱番番将继续在云原生方向上发展，基础技术不断革新演进新的技术体系，逐步打磨适合团队的基础技术产品与服务，持续引入云原生技术以支持产品的发展，秉持“技术为产品服务”的理念加速客户价值点的交付。
8. 作者介绍
chhoho , 百度爱番番基础技术负责人， 拥有多年 CRM 行业架构经验，擅长分布式系统、微服务架构、CICD、Cloud Native 等技术领域。