作者：张羽辰(同昭)    阿里云技术服务平台团队

企业在开始使用云之前，必须要在云上建立一个安全、合规、灵活的 Landing Zone，其中随着云原生的流行，在传统的Landing Zone设计中必须要加入云原生的设计与规划，本文就这种需求进行了讨论，阐述了部分设计。

一、Landing Zone为企业搭建安全、高效和可管理的云环境

Landing Zone是一个军事术语，表示飞行器降落的区域，类似的说法IT行业有很多，例如DMZ（Demilitarized Zone）。它也是一个阿里云企业上云框架，是企业上云前，就企业的安全、合规、网络等各方面需求进行云上环境规划的专有名词。

Landing Zone不是一个独立的云服务，而是贯穿多个云产品，为企业创造满足需求的云环境的解决方案。它所解决的问题，就是企业在上云前所必须解决的问题：如何在云计算环境中，创造一个包含身份管理、资源管理、网络规划、财务管理、合规审计、安全防护的云上IT顶层架构设计及治理落地方案。可以指导企业规划和落地云上的资源结构、访问安全、网络架构和安全合规体系，为企业搭建安全、高效和可管理的云环境。

这里对Landing Zone做一个小结：有了Zone，才能landing云上，企业要上云，Landing Zone是第一步。

在进行Landing Zone设计与实施后，我们的企业应该解决了如下问题：

• 开通多个阿里云账号，这些账号的名称、职责、管理关系、付费关系等；

• 云上的用户、角色等身份管理的实现，以及与自身SSO的集成；

• 云上的网络规划，云上云下如何实现互通，云上的网络划分，南北流量规则等；

• 在实施合规审计、操作审计、安全防护等方面，云上的资源必须符合内部的安全合规需求；

• 在云上动态的资源变化中，落实成本控制，进行账单分类，梳理付费关系；

• 其他合规、治理等方面的问题。

当然，每个客户的场景都是不同的，网络环境、管控需求、安全需求都随着企业的形态有巨大的变化，跨国500强客户与国内互联网型客户对管控有着不同的要求，所以Landing Zone方案在落地时，会根据客户的实际需求进行调整。

国内互联网客户往往看中效率，由于业务上对变化的响应，要求资源的开通、变更更加迅速并且模板化，因此在landing时，自动化基础设施设计可能更重要。而一个传统的零售跨国企业，其安全审计部门所带来的的需求往往有上百条的安全规则，这要求设计必须毫无疏漏，不仅要通过安全设计，最好是能够应对渗透测试。

正因为进行Landing Zone方案的设计、实施需要符合企业自身的特点，阿里云在2021年推出了配合最佳实践的咨询服务。作为专家服务，它可以解决企业在实施Landing Zone时的各类问题，使得方案能够匹配企业的特殊需求，并最终实现落地。

二、Landing Zone内容分解

在阿里云的最佳实践中，Landing Zone分为8个模块，或者8个明确的步骤，即：

其中，需要使用的产品有十多个，包括：资源目录、标签、费用中心、专有网络、云企业网、NAT网关、负载均衡、SLS 日志、云防火墙、WAF、RAM 访问控制等等。

这些服务都是偏基础、偏管控的服务，在进行计算资源设计时，landing往往不会考虑使用ECS或者Function Compute，这是部署在云上的应用所考虑的，Landing Zone关注的是环境的建设。

但在今年的Landing Zone场景中，有越来越多的客户要求加入云原生方面的规划，无论是出自CTO的顶层设计，或是因为业界标准的推动，企业应用已经开始向云原生演进。因此，云上的环境必须支持容器、FaaS等云原生场景，这就是服务的新趋势。

在中国开展业务的跨国企业，往往是总部或Global对中国区有明确的要求，需要尽快准备好基于Kubernetes的云原生平台，能够支持未来的应用部署。相对于国内的互联网企业，这些企业“不见兔子不撒鹰”，一定是在某项技术成熟后再进行选择，例如某客户的德国总部要求所有的供应商提供的软件必须基于helm进行封装，可运行在多家云平台的容器平台之上。统一多个ISV的交付物在过去难以实现，但如今通过基于云原生的技术栈，企业甚至能在使用较少成本的情况下完成代码库、CICD、artifact、容器平台、监控治理的统一。

有人会有疑问，这不是做了个PaaS吗？没错，这里再推荐一篇好文《Talk write-up: "How to build a PaaS for 1500 engineers"》[1]。

三、企业上云时需提前规划云原生部分

随着容器、Kubernetes、Serverless、FaaS技术的演进，CNCF（云原生计算基金会）将云原生的概念更广泛的定义为“让应用更有弹性、容错性、观测性的基础技术，让应用更容易部署、管理的基础软件、让应用更容易编写、编排的运行框架等”，希望能够让开发者最好地利用云的资源、产品和交付能力。

现代企业应用需要具有“弹性、容错性、观测性、易部署”这些特性，围绕ACK或是基于Kubernetes实施云原生，是比较广泛的做法。大多数业务程序已经完成了容器化改造，进行云原生演进，需要Kubernetes这样的容器平台作为必备条件，它们一般都有如下特点：

1. 它们往往使用微服务架构，每个“微服务”有独立的计算、存储资源，甚至有独立的数据库依赖；

2. 这些应用的内部耦合较小，往往使用高级的RPC或RESTful进行通信，不需要部署在一台ECS实例中；

3. 每个独立的微服务都需要灵活变化，根据负载调整资源，根据业务频繁部署；

4. 企业再也无法使用多台虚拟机、ECS来设置这些微服务的边界，它们几乎是动态的。

从逻辑上来说，使用Kubernetes不仅仅是它足够优秀，能够支持企业的复杂环境需求，更关键的是它符合企业在云上的部分利益：与云计算供应商保持足够的距离避免绑定。毕竟Kubernetes提供了中间层，让应用耦合Kubernetes总好于与云平台强绑定，有朝一日这些企业应用可能会部署到更合适的地方，从而避免过大的改造成本。

很多IT负责人或者云平台管理者都希望供应商的软件能够符合一定标准，这个标准包括应用架构、数据库等依赖选型、部署方式、交付方式、可观测性接入等，而在CNCF的生态圈中，这些都有非常好的解决方案，例如：

1. 可以要求供应商使用Helm进行应用打包与发布，这样可以快速安装到任何一个Kubernetes集群中。

2. 对于日志、性能监控等，除了使用SLS，还有大量的开源产品，而且Grafana和Prometheus的组合已经可以解决很多可观测性问题。

3. 应用程序部署至Kubernetes，而存储、数据库、Redis等使用PaaS产品，避免自己管理容灾、快照，要求落盘加密确保数据安全。

4. 对于应用部署后的更新、扩容，这些都可以接入企业已有的CICD平台，通过 Kube OpenAPI或其他自动化工具进行自动化调整，彻底告别手动。

5. 对于Kubernetes集群的运维，则往往需要与云平台进行联动考虑，比如在阿里云上使用节点池可以控制集群的容量和水位，利用ACK的升级功能，可以做到主版本轻松升级。

上图描述一般DevOps流程与可观测性到ACK集群之间的配合。构建从代码到集群的部署流程，并通过各层级的可观测性产品时时关注应用细节。

四、Landing Zone中落地云原生设计

如同在其他Landing Zone服务中一样，引入云原生还要关注规划、管控与治理，并且ACK上的管控规则既要符合企业一贯的需求，下面我们将分别进行讨论。

首先需要明确未来在云上企业会使用多少个集群？一般来说，我们建议在每个业务账号下，如果有业务需要就要建设一个ACK集群，大多数情况下使用“托管版”集群将Master节点让阿里云托管使用，这样除了有较好的SLA之外，还可以降低每个集群的管理费用，避免购买过多的 ECS。

同构不同量

一般情况下，资源目录所提供的多账号功能允许我们按照业务、环境来规划账号，如果按照环境来规划，我们每个账号内的资源应该是同构的，他们都应该有ACK集群，只是测试、预发环境的集群容量较小，不需要像生产环境使用上百个worker node。同时，对于应用程序的pod template，建议request、limit可以作为参数传递，在不同的环境中使用合适的资源。

不要在一个集群内混合研发、测试、生产环境

如果企业打算这样实施，这将是一个非常严重的错误。由于Kubernetes本身的特性，即使应用部署的deployment、stateful这类资源可以隔离，但对于storage、network、config、secrets这类资源进行隔离就不好做到，此外，对于这个集群的权限设计也会是一个非常复杂的问题。

有时候企业的多账号规划会和这一点产生冲突，例如某集团倾向于给每个应用规划独立的成员账号（便于与ISV的管理），那该应用的研发、测试、生产环境都会位于成员账号中，如果不想混合研发、测试、生产环境在同一ACK中，那就需要在该账号中设计三个ACK集群，造成相当大的管理成本。

集群内的应用隔离

Kubernetes原生提供的隔离能力并不强，可以使用NetworkPolicy以Namespace为单位隔离在一个集群内的多个应用，使用Namespace部署一个业务领域内的应用也是常见的做法。除原生能力外，还有其他三方产品可以提供更好的隔离效果。

集群的网络架构

目前使用Terway网络插件作为ACK建设已成为首选，在使用Terway时，必须要考虑 Pod网段的问题，即专门为Pod设计VSwitch。一般集群建设都需要考虑高可用，可跨两个可用区进行部署，同时Pod网络也需要考虑跨可用区，例如下图中的案例。对于Dev、Staging这样的集群，也可以使用Flannel简化网络部分。

Terway网络插件是ACK自研的网络插件，将原生的弹性网卡分配给Pod实现Pod网络，支持基于Kubernetes标准的网络策略（Network Policy）来定义容器间的访问策略，并兼容Calico的网络策略。

灵活的入口设计

Kubernetes的Ingress设计接入外部流量，不同云厂商有不同的实现，以阿里云的ACK为例，可以灵活部署多个Ingress来符合网络上的需求，比如我们希望隔离开外网访问与内网访问，那就可以创建两个Ingress，同时让它们负责将流量导入到不同service中，这些service自然属于不同的Namespace。对于集群的OpenAPI的管控入口，强烈建议将其SLB设为内网，这样就只允许IDC或者Workspace的设备进行访问。

使用多个Ingress Controller与SLB灵活绑定，区分内网、外网、不同Namespace中的流量。

身份、权限与管控

在Landing Zone的身份权限设计中，一般会定义多个RAM Role来描述云上的权限，比如Admin、ReadOnly、CloudContributor等等，这些Role与SSO集成，当工作人员完成认证后，会获得相应的Role来操作云上的资源，而现在这个资源扩大为ACK集群中的Namespace、service、deployment 与pod。定义ClusterRole可以设置集群内的权限，同时在Landing中我们也会设计RAM Role与ClusterRole的对应关系，例如ClusterManagement这个RAM Role可以操作集群相关的ECS、SLB等资源，这样就可以完成扩容操作，同时也可以访问OpenAPI中的storageclasses，worker node，networking这些与应用不强相关的资源，避免这个角色访问到service、deployment、pod等。

与SSO、RAM Role完成集成的ClusterRole设计。

完全开放的可观测性

一般来说IaaS层的可观测性由云平台供应商来提供，我们建议企业在每个成员账号中使用模板化的云监控设置，比如CPU利用率60%就进行WARN报警，监控EIP的流量等等，这些配置可以通过Terraform Code直接在成员账号中一键配置。

但是云原生中的可观测性就是完全开放了。对于Kubernetes，除了可使用阿里云提供的Prometheus与Grafana，客户也可以部署任意能在Kubernetes上运行的可观测性软件。对于日志，使用阿里云SLS与其他日志中心都是可行的，无论是使用sidecar还是daemonset，完全取决于客户的实际情况。

应用为核心

在云原生时代，核心就是应用程序而非底层计算资源、中间件或是数据库，我们的可观测性也需要围绕应用来进行设计，现代的APM系统可以精确的感知应用进程内的情况，使用ARMS、AHAS可进行应用进程内、链路调用的全部监控，引入它们也非常简单，在deployment中使用annotation就可以避免应用内的改动。

五、小结

云原生已经来了，使用云原生已经是如何去做的问题了，在企业开始使用云服务前，设计好云上的环境就必须要考虑云原生的实施。回到Landing Zone的架构中，进行身份管理、资源管理、网络规划等这些设计时都需要考虑清楚。

参考阅读

[1] Talk write-up: "How to build a PaaS for 1500 engineers"

英文版：

https://srvaroa.github.io/paas/infrastructure/platform/kubernetes/cloud/2020/01/02/talk-how-to-build-a-paas-for-1500-engineers.html

中文版：

https://www.infoq.cn/article/tuczf6pvwjncxlla29gj