凌云时刻
编者按：2021年7月2日，阿里云用户组（AUG）首次线下活动在济南召开。阿里云原生专家禹杨杨现场跟数十家山东企业介绍了容器基础及周边生态，并结合案例重点分享了如何进行云原生迁移。本文根据作者的现场演讲整理而成。
今天给大家带来的是容器上云最佳实践的分享，包括两部分：第一部分是容器基础及周边生态的介绍；第二部分是云原生迁移的过程，将结合客户案例，看看他们如何从VM的场景到K8S场景，然后把周边的生态怎么用起来。容器是云原生的基石
容器之于云原生这个时代，实际上就相当于集装箱基于全球化这个时代，没有容器就没有云原生。
容器是云原生的基石，是云原生最基础的东西。整个容器的发展过程，大家可以简单的等同于云原生的发展过程，主要分三段：
第一个阶段是容器化，最开始的时候大家实际上没有编排的概念。主要通过Docker命令跑起来后，最多再加一些Docker Compose之类的东西，做一些相对简单的交付。随后，大家渐渐做了两个标准，第一个是images镜像标准，第二个是容器运行时，这两个标准实际上是给进入下个阶段做了一个基础。因为容器化阶段存在一些问题，比如，我们在做Docker Run，或者Docker Compose时，对大部分场景来说还是在一个单一的环境里，这在研发测试环境是没有问题的，但到生产环境后，我们想再通过单机维护去完成这个事情实际上就非常复杂。于是后续就出现容器的编排调度标准之争，也就是第二个阶段。实际上是发生在Docker这家公司的Swarm跟Google的K8S之间，标准之争持续时间是比较久的，然后一直到2018年、2019年才完全定下来，最后就以K8S作为我们的核心标准交付。K8S之所以能成功，实际上在于它对我们本身POD的抽象非常好，把优雅上下线、弹性伸缩、Deployment自带的控制器等标准化做得很好。接着就到了目前我们所在的阶段。第二阶段其实已经比较完善了，创建K8S是一个标准动作，不管是在公共云、专有云还是其它云上，大家实际上都支持K8S这个标准体系。CNCF正是这个时候出现的，他们把这些东西做到一起，就变成所谓的镜像的标准。从我们刚才讲的CRI标准、运行时标准，到传统的基于K8S之上的传统微服务迁移，基于Service Mesh的体系，再往上到Knative Service、Faas、大数据的Kube Flow、IoT设备、边缘集群的体系。把云边端连到一块儿，把边缘集群和边缘节点跟云上的节点作为一个统一的K8S集群来管理。慢慢地，K8S的覆盖范围就从仅在服务端管理一些微服务这种简单的应用，到AI、大数据、边缘，乃至整个生态完全重构的过程。
Kubernetes逐渐成为云原生时代的基础设施
就目前来看，大家最常见的是最上面这一层（下图），也是K8S比较多的状态。最左侧是无状态应用，支持的最典型的就是我们的微服务，也是大家最常见的场景。有些研发会担心自己的应用比较老，比如Bigstone应用，是否还适合？实际上是适合的。因为它可以当成是只有一个应用的微服务，是比较适合我们也是大家目前用得最多的一类。至于状态呢，有些研发认为有不同的应用程序不一样，或者有一些日志，这些应该算状态，但实际上这些不算。这就像配置不同但我们可以在远端操作来做配置的道理是一样的。日志实际上是一个非硬性的状态。首先，它完全可以随时生成、随时采集走。其次，它的状态我们都可以通过保留在比如说Mysql 、Redis或其他系列数据库里面，来把应用本身做成无状态。无状态后，我们就可以充分利用K8S或云计算提供的弹性伸缩能力来配合周边（如数据库的架构和出口的架构等），通过这种架构配合来实现某些业务场景。比如，某公司业务初期体量很小，采用这种架构配合后，可以一直扩到一定程度（几百万QPS或几千万QPS之内），而整个架构都不变。这样才能利用弹性架构真正给公司创造价值，而不是隔一年重构一次。最右侧是Tensorflow、Spark、Flink，就是AI、大数据场景。像Hadoop的这种结构，目前在云上的占比会慢慢降低。虽然它说自身是数据和算力分离，但实际上还是在一台机器上，所以肯定无法把弹性做起来。Spark、Flink和TensorFlow在把算力和数据分离之后，才能真正地把算力弹起来，才能充分地利用弹性能力来降低业务成本。以教育培训行业为例，他们的峰值主要在周一到周五晚上和周末，而平时我们的上班时间对他们来说是一个低峰期，可以充分利用对AI的GPU管理能力弹性承载来降低他们的成本。 云上 Kubernetes 部署要求
如果要做一套K8S体系需要做什么事情呢？最核心是做跟周边的对接。在阿里云上，最典型的就是跟底层的计算资源对接，包含大家常见的虚拟机、GPU、裸金属，以及云下IDC机房里的物理机。然后跟底层的网络资源对接，如果集群要有一个对外提供服务的能力，就需要有一些负载均衡能力的对接，在阿里云对应的就是SLB。接着，就是跟左侧的存储资源对接，包含云上存储的主机磁盘、云盘、NAS存储和对象存储等，如果业务应用要用到云下存储设备里的数据，可以通过CSI标准插件去做对接。再往右，对接的就不是偏底层的资源，而是我们原来在应用层都有的设施，如Sky Walking、ARMS、日志服务等。等完成这几类对接后再将业务切到云上，就会发现大部分的使用跟原来差异不大。 计算对接
云上最大的特征就是弹性，弹性能帮业务降低资源的采购周期。在云的Cloud Hosting阶段，大家使用的是云上虚机。如果要用到它的弹性，需要事先做很多准备，比如，给应用打镜像、做启动脚本的设计、弹性指标的设计等。这些工作在Cloud Hosting阶段门槛较高且不标准，不标准带给大家千差万别的体验。而K8S的好处就是通过标准化的API把底层的东西覆盖掉，给它装起来，对外输出的就是标准的K8S能力。基于CPU Memory ，用的资源多了就弹，等到资源下来就缩，这是最典型的例子。还是以教育行业为例，去年我们给他们做了一个东西Cronhpa，Cronhpa就类似于大家用Cronjob、Crontab的场景，当业务在时间轴上很有规律，业务就可以定点资源弹出来，过了时间点就释放资源。
图上左边的虚拟机、神龙裸金属服务器都比较常见，GPU实例是专门针对AI场景做的。抢占实例是将平时闲置的资源以低价售出，进一步降低成本给大家去使用。虚拟节点是我们跟底层合作的特殊资源，专门为容器做的虚拟化设计，就是因为容器是大的发展趋势。除了底层虚机的弹性资源，现在也有专门针对K8S做的POD实例，可以弹得特别快。微博常常会有突发的新闻事件，需要资源迅速扩展，这个POD实例就可以帮助他们快速弹出来。实际上，我们不仅仅要在应用层控制住，另一方面，底层资源也会自动地根据我们应用的突然变化去做底层，而且不同资源的弹性速度不一样，需要尽可能地去匹配各自的业务场景。 网络对接
K8S的流量入口通常要配合一些负载均衡设备来做。因为K8S的POD尤其是开源的K8S网络组件是以Overlay为主，其网络特点是集群内的POD，集群外的ECS间是不通的。开源体系里面做得较多的是Nodeport，然后用SLB做绑定关系，但实际上我们不太推荐这种做法。因为这种做法的问题是node跟SLB是硬绑定关系，不能随着服务本身的变化而变化，所以当集群扩了或缩了，都需要手动去做这些绑定关系。所以我们（包括K8S的标准）选取一个单独的组件CCM来做这种绑定关系，CCM做的就是负载均衡跟自己的Service之间的挂载关系同步。这是第一种做法，实际上就是最左边的LoadBalancer模式，通过CCM做绑定。第二种模式是在第一种模式之上，把入口做一个网关，到了这一层再往后才是真正的转到业务Service上去。大家可以把网关理解为Nginx体系或K8S标准里的IngressController，即所谓的入口网关。在这个体系里，实现是非常多的，包括Kong、Traefik等，大家有兴趣都可以去了解下。这么做的好处是有一个公共的入口，可以把一些比较复杂的转发逻辑（如黑白名单）都往里面放，实际上对接VM的场景。第三种模式是第一种模式的一种变式。比如，原来用的Spring Cloud Geway可以接着往下用。 日志对接
我们前面讲到，上云后有些内容，我们不认为是有状态的，其中之一就是日志。日志一般在K8S里面体系分两类，第一类是审计日志，即通过K8S的API Server做的这些动作的审计日志；第二类是产品的业务日志。在K8S在这个领域，这两类通常都要求大家做一个中心化的日志服务，如开源的ELK或阿里的SLS。因为K8S的POD重启后日志就没有了，所以一定要实时采集走。一般来说，我们评价日志系统会关注采集的时效性，是不是紧跟着追，如果堆积很严重，那证明这个日志系统有问题。另外，我们会关注存储周期，不管用什么方式采集，一定要做一个长周期的存储。尤其是有些行业，国家有规定日志必须保留180天或360天等明确的时间标准。 监控对接
在K8S这个领域，监控比原来多做了一部分，主要是事件中心、Prometheus。
事件中心是K8S本身的一个事件体系。一般K8S本身为了保证它的ETCD量不要特别大，导致其性能下降，通常只会保留1到2个小时。在测试环节这个时间OK，但生产环境可能需要保留更长的时间。
我们的做法是把这些事件也导出来，放到日志里去。通过日志的查询去支撑我们的事件更长久保留，避免查一个问题查一下事件就没了，不知道当时集群里面具体发生了什么事情。
K8S本身核心事件的监控就是Prometheus，通常都会自动装上，比如说node的监控、POD的监控，当然要配合做Coredns、IngressController、APIserver ETCD等功能，这些监控做起来后能清楚地告诉我们K8S是否处于健康状态。
往上是应用层的监控。如果是Java体系可以用Sky Walking或阿里云ARMS等应用本身APM的产品；如果是非Java类的可以用业内较多的链路追踪，如Opentracing做Trcing监控，或Prometheus做Metrics监控等较常见的手段。再往上是做业务监控的SLS日志性。这几个东西在K8S使用的场景里几乎是一个必选项，我们建议大家都要做起来，否则就可能有监控盲点。容器监控没有做到位，日志没有把握到，资源没有……这些情况不知道的话，就会出现好的部分过于密集，可能就把Request写得特别小，或者不写Request，单部署没有问题，一旦业务量上来了，就会发生驱逐。POD驱逐是指当流量上来后，资源水平高，就会在业务中一起去重启核心业务，这实际上是非常非常危险的事情。 监控衡量标准
监控是一种手段，我们给大家提供一个标准去检查，衡量这个监控做得好不好。要从最前端的用户页面（如PC端或IOS安卓端）开始到公网入口（要考虑到CDN或WAF），到SLB（如Nginx Ingress Controller的网关），再往后到微服务的体系、泛存储泛数据库（如OSS、Redis、Mysql）等体系，梳理清楚后，我们要在每个点上去问几个问题。- 第一，这个点上的Metrics监控，各种各样的QPS、RT、包括错误率等。
- 第三，是否有Tracing类的监控，当有一些很小概率但是会出问题的这种场景能不能监测到。比如说有一些小概率的很长RT的请求能监测到，当性能不好的时候，能很快定位到性能损耗在哪一块是最大、耗时最长，也就是微服务器里分锅的问题。
如果这些体系的回答都是Yes，那就证明这个监控相对来说比较完善。但哪一块回答不清楚或不知道，甚至也不知道去哪看，那么这块监控可能需要去增强。
下图是告警的一些例子。一般来说，告警会分为通用的告警、事件里的Warning、Error等Iaas层监控（即资源类的监控）、应用层本身在里面的存储、网络、安全告警，实际上跟RT的划分是相似的东西。
从虚拟机迁移到云原生
迁移场景
讲一个云原生迁移的案例，Spring Cloud往K8S的场景做迁移。首先，没有容器化的产品，原来在虚拟机上跑得好好的产品要做K8S迁移，要做的第一步实际上就是容器化，先通过Dockerfile打成各种镜像，再通过Docker的Docker Build命令把它构建起来。这部分有个开源的工具叫Derrick，能帮助大家去生成Yaml。其次，现在可以暂时跳过业务，编写Yaml文件，说明应用需要哪些配置，如应用有多少个副本，服务接入方式是什么……然后根据这些内容去做K8S部署，包括配置管理、秘钥管理（Config、Secret等）、监控和日志、链路追踪相关以及存储管理及权限控制等都要做。
迁移准备
刚才是从应用的角度来讲迁移，从另一角度来看，迁移之前要把K8S建好，自建或通过云平台托管都OK。- 第一步是把集群建好。首先，要分清楚这种集群是Master在哪儿、Worker在哪儿。其次要做节点的选型，若在线业务是Java体系就比较适合买1:4的比例（如CPU Worker 、CPU:Memory=1:4）的机器，若是AI场景更适合的是GPU机器。若是算力集中场景，可以买裸金属机器。总之，底层设施要跟应用匹配。
- 第二步是做网络规划。规划集群要预期到上限大概有多少个节点、Service，预期放多少个POD，因为它会对网段有要求。比如POD要放1024个IP地址，那最多也不会超过1024个POD。
- 第三步是应用访问。我们前面讲到集群要对外提供服务，要通过哪种接口做流量都要做选型，比如，对RT比较敏感的就用TCP模式；对访问控制的要求比较高可能就放NginxIngressController；如果有传统的Spring Cloud Gateway，可以还用原来的网关。
- 下一步是流量切换。新老体系都在的时候，要考虑老体系怎么一步一步一点一点地往新体系切。像阿里上的DNS、GTM的流量管理，就要控制两个IP入口。
- 再往后是底层的数据迁移。如果数据没有变动地方，就不需要迁移。如果数据从一个地方迁到另一个地方，比如说我的数据的全量迁移增量迁移，怎么去进行迁移这个可能大家都要考量。再往后与运维相关的包含日志监控、链路追踪、权限管理、镜像本身的选择。
民生银行的例子是CNCF官网上比较有名的一个案例。民生银行的架构通过云原生做了一次优化，整体上资源利用率提升了百分之百。但这个利用率大家作为参考就可以，原来的使用水平会决定这个利用率，而且不同行业提升的百分比也是不太一样的。另外一个教育行业的客户，每天晚上和周末的峰值需要大量的这种GPU资源来去做弹性，加上我们底层GPU管理的能力，充分地把它的成本降到比较低的水平，这样才能作为一个比较高的性价比去跟它的同行竞争。（完）