应云而生，幽灵的威胁 – 云原生应用交付与运维的思考

为了更好地加速业务创新和解决互联 规模的挑战，云原生应用架构与开发方式应运而生，与传统单体应用架构相比，分布式微服务架构具备更好的、更快的迭代速度、更低的开发复杂性，更好的可扩展性和弹性。然而，正如星战宇宙中，原力既有光明也有黑暗的一面。微服务应用在部署、运维和管理的复杂性却大大增加，DevOps 文化和背后支撑的自动化工具与平台能力成为关键。

Kubernetes 成为了通用的、统一的云控制平面

Kubernetes 架构的核心就是控制器循环，也是一个典型的”负反馈”控制系统。当控制器观察到期望状态与当前状态存在不一致，就会持续调整资源，让当前状态趋近于期望状态。比如，根据应用副本数变化进行扩缩容，节点宕机后自动迁移应用等。

正因如此，Kubernetes 管理的资源和基础设施范围已经远超容器应用。下面是几个例子：

1. 基础架构管理：与开源的 Terraform 或者云供应商自身提供的 Infrastructure as Code(IaC)工具如阿里云 ROS、AWS CloudFormation 不同，Crossplane（https://crossplane.io/）和 AWS Controllers for Kubernetes 在 Kubernetes 基础之上扩展了对基础设施的管理和抽象。这样可以采用一致的方式进行管理和变更 K8s 应用和云基础设施。

2. 虚拟机管理：K8s 通过 KubeVirt 可以实现对虚拟机和容器的统一调度与管理，可以利用虚拟化弥补容器技术的一些局限性，比如在 CI/CD 场景中，可以结合 Windows 虚拟机进行自动化测试。

3. IoT 设备管理：KubeEdge 和 OpenYurt 等边缘容器技术都提供了对海量边缘设备的管理能力。

4. K8s 集群管理：阿里云容器服务 ACK 的节点池管理，集群管理等完全都是采用 Kubernetes 方式进行自动化管理与运维的。ACK Infra 支撑了部署在全球各地数万个 Kubernetes 集群，基于 K8s 完成自动化了扩缩容、故障发现/自愈等能力。

工作负载自动化升级

K8s 控制器 “把复杂留给自己，把简单交给别人”的理想非常美好，然而实现一个高效、健壮的控制器却充满技术挑战。

• 由于 K8s 内置工作负载的局限性，一些需求无法满足企业应用迁移的需求，通过Operator framework 进行扩展成为了常见的解决方案。但是一方面对重复的需求重复造轮子，会造成了资源的浪费；也会导致技术的碎片化，降低可移植性。

• 随着越来越多的企业 IT 架构，从 on Kubernetes 到 in Kubernetes，大量的  CRD、自定义 Controller 给 Kubernetes 的稳定性和性能带来大量的挑战。面向终态的自动化是一把 “双刃剑”，它既为应用带来了声明式的部署能力，同时也潜在地会将一些误操作行为被终态化放大。在发生操作故障时副本数维持、版本一致性、级联删除等机制反而很可能导致爆炸半径扩大。

OpenKruise 是阿里云开源的云原生应用自动化管理引擎，也是当前托管在 Cloud Native Computing Foundation (CNCF) 下的 Sandbox 项目。它来自阿里巴巴多年来容器化、云原生的技术沉淀，是阿里内部生产环境大规模应用的基于 Kubernetes 之上的标准扩展组件，一套紧贴上游 区标准、适应互联 规模化场景的技术理念与最佳实践。以开源项目 OpenKruise 方式与 区开放、共建。一方面帮助企业客户在云原生的探索的过程中，少走弯路，减少技术碎片，提升稳定性；一方面推动上游技术 区，逐渐完善和丰富 Kubernetes的应用周期自动化能力。

更多信息可以参考：OpenKruise 2021 规划曝光：More than workloads

开发与运维新协作界面浮现

云原生技术出现也带来了企业 IT 组织结构的变化。为了更好应对业务敏捷性的需要，微服务应用架构催生了 “双比萨团队”（Two-pizza teams) 。较小的、独立的、自包含的开发团队可以更好达成共识，加速业务创新。SRE 团队成为了水平支撑团队，支撑上层研发效率提升和系统稳定性。而随着 Kubernetes 的发展，让 SRE 团队可以基于 K8s 构建自己企业的应用平台，推进标准化和自动化，让上层应用开发团队通过自服务的方式进行资源管理和应用生命周期管理。我们看到组织方式进一步发生了变化，新的平台工程团队开始浮现。

KubeVela/OAM 提供了面向 Kubernetes 的服务抽象和服务组装能力，可以将不同实现的工作负载和运维特征进行统一抽象和描述，并提供插件式的注册与发现机制，进行动态组装。平台工程团队可以采用一致的方式进行新功能扩展，并且保持与 Kubernetes 上新的应用框架良好的互操作性。对于应用开发和运维团队，实现了关注点分离（Separation of Concerns），可以将应用定义、运维能力与基础设施实现解构，让应用交付过程变得更加高效、可靠和自动化。

在云原生应用模型定义领域，业界也在不同方向进行探索。比如 AWS 新发布的 Proton 是面向云原生应用交付的服务，通过 Proton，可以降低容器和 Serverless 部署、运维复杂性，并且可以和 GitOps 结合起来，提升整个应用交付流程的自动化和可管理性。

阿里云 Serverless K8s 支持的 Knative 可以同时支持 Serverless 容器和函数来实现事件驱动的应用，让开发者使用一个编程模型，可以高效选择底层不同 Serverless 化算力进行优化执行等。

无处不在的安全风险催生安全架构变革

DevSecOps 成为关键因素

当代码提交之后，可以通过阿里云镜像服务 ACR 主动扫描应用，并对镜像进行签名，当容器服务 K8s 集群开始部署应用时，安全策略可以对镜像进行验签，可以拒绝未通过验签的应用镜像。同理，如果我们利用 Infrastructure as Code 的方式对基础设施进行变更，我们可以通过扫描引擎在变更之前就进行风险扫描，如果发现相关的安全风险可以终止并告警。

此外，当应用部署到生产环境之后，任何变更都需通过上述自动化流程。这样的方式最小化了人为的错误配置引发的安全风险。Gartner 预测，到 2025年 60% 的企业会采纳 DevSecOps 和不可变基础设施实践，与 2020 年相比降低 70% 安全事件。

服务 格加速零信任安全架构落地

分布式微服务应用不但部署和管理复杂性提升，其安全攻击面也被放大。在传统的三层架构中，安全防护主要在南北向流量，而在微服务架构中，东西向流量防护会有更大的挑战。在传统的边界防护方式下，如果一个应用因为安全缺陷被攻陷，缺乏安全控制机制来阻止内部威胁“横向移动”。

其中：

1. 既可以利用现有身份服务提供身份标识，也支持 SPIFFE 格式的身份标识。身份标识可以通过 X.509 证书或者 JWT 格式进行传递。

2. 通过服务 格控制平面 API 来统一管理，认证、授权、服务命名等安全策略。

3. 通过 Envoy Sidecar 或者边界代理服务器作为策略执行点（PEP）来执行安全策略，可以为东西向和南北向的服务访问提供安全访问控制。而且 Sidecar 为每个微服务提供了应用级别的防火墙， 络微分段最小化了安全攻击面。

服务 格让 络安全架构与应用实现解耦，可以独立演进，独立管理，提升安全合规保障。此外利用其对服务调用的遥测能力，可以进一步通过数据化、智能化方法对服务间通信流量进行风险分析、自动化防御。云原生零信任安全还在早期，我们期待未来更多的安全能力下沉到基础设施之中。

新一代软件交付方式开始浮现

从 Infrastructure as Code 到 Everything as Code

基础架构即代码（Infrastructure-as-Code， IaC）是一种典型的声明式 API，它改变了云上企业IT架构的管理、配置和协同方式。利用 IaC 工具，我们可以将云服务器、 络和数据库等云端资源，进而实现完全自动化的创建、配置和组装。

我们可以将 IaC 概念进行延伸，可以覆盖整个云原生软件的交付、运维流程，即  Everything as Code。下图中涉及了应用环境中各种模型，从基础设施到应用模型定义到全局性的交付方式和安全体系，我们都可以通过声明式方式对应用配置进行创建、管理和变更。

GitOps 提升了交付效率，改进了开发者的体验，也提升了分布式应用交付的稳定性。

GitOps 在过去两年时间里，在阿里集团和蚂蚁都被广泛使用，成为云原生应用标准化的交付方式。目前 GitOps 还在发展初期，开源 区还在不断完善相关的工具和最佳实践。2020年，Weaveworks 的 Flagger 目并入 Flux，开发者可以通过 GitOps 的方式实现灰度发布、蓝绿发布、A/B 测试等渐进的交付策略，可以控制发布的爆炸半径，提升发布的稳定性。在 2020 年末，CNCF 应用交付领域小组正式宣布了 GitOps Working Group 的组建，我们期待未来 区将进一步推动相关领域标准化过程和技术落地。

• 日常业务：对于可预测的、相对不变的负载，我们可以利用包年包月的裸金属或者大规格虚拟机来提升资源利用率，降低成本。

• 计划内的短期或周期性业务：比如双十一大促，跨年活动等短期业务峰值，或者月底结算等周期性业务负载变化，我们可以利用虚拟机或者弹性容器实例来应对业务高峰。

• 非预期的突发弹性业务：比如突发新闻热点，或者临时的计算任务。弹性容器实例可以轻松实现每分钟上千实例的扩容。

更多关于 Kubernetes 规划问题，可以参考：关于Kubernetes规划的灵魂n问。

总结

过去十年，基础架构上云，互联 应用架构升级，研发流程敏捷化几个技术大趋势相交汇，与容器、Serverless、服务 格等技术创新相结合，共同催生了云原生的理念诞生和发展。云原生正在重新定义的计算基础设施、应用架构和组织流程，是云计算发展的历史的必然。感谢所有一起在云原生时代的同行者，让我们共同探索和定义云原生的未来。

片尾彩蛋，本系列三篇文章的名称向星战系列致敬，你发现了吗/p>

团队招聘

阿里云容器服务团队招聘啦！欢迎转岗、 招推荐! 一起创造云原生激情澎湃的未来！杭州、北京、深圳均有机会哦。简历发送至：yaowei.cyw@alibaba-inc.com。

﹀

﹀

﹀

阿里云原生2020年成绩单：云原生已成为企业快速发展的核心动力

2021-02-10

爱奇艺体育：体验Serverless极致扩缩容，资源利用率提升40%

2021-02-10

点个在看，让更多人看见

文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览91462 人正在系统学习中