阿里妹导读：阿里云已经成功地规模化落地云原生，26日的 KubeCon 大会上，CNCF TOC 和阿里云资深技术专家李响发表主题演讲，分享了阿里巴巴在规模扩展、可靠性、开发效率、迁移策略等方面的经验，并探讨云原生的落地及应对若干技术挑战。

为什么要做云原生？云原生究竟能带来什么价值？从最初的独自摸索到如今拥抱开源回馈社区，阿里巴巴走过了怎样的云原生旅程？又有哪些技术心得？今天，将全部分享出来。

多年沉淀，坚持探索与落地并重

阿里巴巴从2011年开始通过容器实践云原生技术体系，在整个业界都还没有任何范例可供参考的大背境下，逐渐摸索出了一套比肩全球一线技术公司并且服务于整个阿里集团的容器化基础设施架构。这个探索历程虽然孤独，但却被始终如一的坚持至今。这正是在这个孤注一掷的技术探索与奋进的过程中，阿里巴巴的技术团队完整的经历了云原生技术浪潮里的所有关键节点，不仅成为了这次技术革命的重要见证者，也逐渐成为中国云原生技术体系当之无愧的推动者与引领者之一。

阿里的体量大、业务复杂，推动云原生要找到合适的切入点。在双十一成本压力的推动下，资源成本与效率优化成了阿里云原生的起点。

阿里从容器入手，研究低成本虚拟化与调度技术：提供灵活、标准的部署单元；将静态资源分配更换为动态按需调度，进一步提升部署效率，解决资源碎片化问题，提高部署密度；通过存储网络虚拟化和存储计算分离等技术，增强任务的可迁移性，进一步提高了资源的可靠性，降低了资源成本。

在资源成本的推动下，阿里完成了全面容器化，资源分配也被高效调度平台接管。阿里的云原生并未止步于此。提高研发效率与加快迭代周期是推动阿里业务增强的秘密武器。阿里希望通过云原生让开发者效率更高。

为了降低应用部署难度，提高部署自动化程度，阿里开始采用 Kubernetes 作为容器编排平台，并且持续推动 Kubernetes 的性能与可扩展性。具体 Kubernetes，阿里持续对研发、部署流程进行改进。为了构建更云原生化的 CI/CD，进一步做到标准化和自动化，从研发到上线流程，阿里引入了诸如 Helm 的应用标准化管理，也尝试了 GitOps 这样的部署流程，还推动了 PaaS 层的面向终态自动化改造。于此同时，阿里也开始探索服务网格，致力于进一步提高服务治理的普适性与标准性，降低开发者采用门槛，进一步推动微服务在多语言和多环境下的普及。

今年，阿里也展开了全站上云。经过云原生的探索与改造，阿里基础架构体系是现代化和标准化的。利用容器技术，应用与宿主机运行时完成了解耦；利用 Kubernetes 对 Pod 与 Volume 等的抽象，完成了对多种资源实现的统一化；通过智能调度与 PaaS 平台，让自动迁移应用，修复不稳定因素成为了可能，阿里通过云原生技术大大降低了上云的难度。

在这个提高资源和人员效率的过程中，阿里巴巴的整个基础设施也变得更加开放，连通开源生态，在交流互动中不断吸收和贡献好的理念、技术、思想。如今，阿里云不仅支撑着中国最大的云原生应用双11，而且拥有国内最大的公共云集群和镜像仓库。作为唯一入选 Gartner 的公有云容器服务竞争格局的厂商，阿里云也积累了最为丰富和宝贵的客户实践。

追求极致，优化扩展性和规模性

弹性和规模性，这是支撑阿里巴巴各种类型的复杂场景以及流量高峰的关键因素。

经过不断打磨，阿里巴巴在 Kubernetes 规模与性能上取得了显著的成果：将存储object 的数量提升25倍，支持的节点数从5000提升到上万，在端到端调度延迟从5s变为100ms等等。其中有不少工作在阿里巴巴和社区中共同开展，而这些研发成果都已经贡献给社区，我们期望其他企业及开发者也可以享受阿里巴巴规模所带来的技术红利。

阿里巴巴持续优化性能，可以分为以下四个维度：工作负载追踪、性能分析、定制化调度、大规模镜像分发。首先对工作负载调度有完整的追踪、重放机制，其次将所有性能问题的进行细致分析，逐一攻克技术瓶颈。Kubernetes 本身的可定制性很强，阿里巴巴针对自身业务场景沉淀了定制化的调度能力和镜像分发系统。开源Dragonfly 项目脱胎于双十一，具备极强的镜像分发能力。数十个超级集群，每个超级集群具有数万节点，数百万的容器。

阿里巴巴落地 Kubernetes 可以分为三个阶段：首先通过 Kubernetes 提供资源供给，但是不过多干扰运维流程，这系统容器是富容器，将镜像标准化与轻量级虚拟化能力带给了上面的 PaaS 平台。第二步，通过 Kubernetes controller 的形式改造PaaS 平台的运维流程，给 PaaS 带来更强的面向终态的自动化能力。最后把运行环境等传统重模式改成原生容器与 pod 的轻量模式，同时将 PaaS 能力完全移交给Kubernetes controller，从而形成一个完全云原生的架构体系。

如何解决云原生的关键难点

阿里巴巴云原生的探索，起步于自研容器和调度系统，到如今拥抱开源的标准化技术。对于当下开发者的建议是：如果想构建云原生架构，建议直接从 Kubernetes 入手即可。一方面，Kubernetes 为平台建设者而生，已经成为云原生生态的中流砥柱，它不仅向下屏蔽了底层细节，而且向上支撑各种周边业务生态；另一方面，更重要的是社区中有着越来越多围绕 Kubernetes 构建的开源项目，比如Service Mesh、Kubeflow。

那么作为过来人，阿里有哪些“避坑指南”呢？

云原生技术架构演进中最为艰难的挑战，其实来自于 Kubernetes 本身的管理。因为 Kubernetes 相对年轻，其自身的运维管理系统生态尚不完善。对于阿里而言，数以万计的集群管理至关重要，我们探索并总结了四个方法：Kubernetes on Kubernetes，利用 K8s 来管理 K8s 自身；节点发布回滚策略，按规则要求灰度发布；将环境进行镜像切分，分为模拟环境和生产环境；并且在监控侧下足功夫，将Kubernetes 变得更白盒化和透明化，及早发现问题、预防问题、解决问题。

另外一个关键技术问题是 Kubernetes 的多租户管理。相比于 namespace 扩展性差和命名冲突等限制，可以在 Kubernetes 之上建立虚拟集群。在提高扩展性的同时，能够做到 API 层面的强隔离，通过 syncer 链接虚拟集群和真实集群，在 node添加 agent，达到更好的多租管理和更好的利用。

此次 KubeCon 大会上，阿里云重磅公布了两个项目：Cloud Native App Hub —— 面向所有开发者的 Kubernetes 应用管理中心，OpenKruise —— 源自全球顶级互联网场景的 Kubernetes 自动化开源项目集。

云原生应用中心（Cloud Native App Hub），可以简单理解为 Helm 应用中国镜像站，方便用户获得应用资源，并大大简化了 Kubernetes 部署安装一个应用的步骤；OpenKruise/Kruise 项目致力于成为“云原生应用自动化引擎”，解决大规模应用场景下的诸多运维痛点。这次沙龙首秀，开发者们体验了从云原生应用中心快速下载应用，并通过带状态pod 原地升级、sidecar 容器注入、节点镜像预热等三个场景，实际体验了 Kruise 强大的自动化运维能力。

值得一提的是，OpenKruise 项目源自于阿里巴巴经济体过去多年的大规模应用部署、发布与管理的最佳实践；源于容器平台团队对集团应用规模化运维，规模化建站的能力；源于阿里云 Kubernetes 服务数千客户的需求沉淀。从不同维度解决了 Kubernetes 之上应用的自动化问题，包括部署、升级、弹性扩缩容、QoS 调节、健康检查，迁移修复等等。

原文链接
本文为云栖社区原创内容，未经允许不得转载。