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

企业在开始使用云之前,必须要在云上建立一个安全、合规、灵活的 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

更多推荐