云原生技术实践训练营：课时1：Serverless容器入门和实践案例
课时1：Serverless容器入门和实践案例
内容介绍
一、课程概述
二、复杂性下沉
三、阿里云 ASK 竞争优势
四、案例介绍
一、课程概述
Serverless 现在有三种典型的算列模式，一种是 FC，一种是 SAE。现在介绍 ASK Serverless Kubernetes 这种模式，K8S 即使已经成为企业上云通用的一种标准，但好处在于具有其自身的社区和标准，几乎是到任何一个云上或者甚至是 IDC 和云上都是相同的使用方式。这是它的优势的一个所在位置，完整的 K8S 还是要非常多的复杂度的，不管是哪一种模式的 Serverless 最核心的位置就在于把复杂度向云下沉，复杂度不可能消失，都是从最基本的物理机上面把各个资源一块块切出，再配合应用，这个过程中调度的复杂和资源的管理都是必不可少的。
开发者如果更容易的使用这些能力就要使复杂度不断往云上下沉，这些复杂度下沉到云上之后通过云上的各个系统把它屏蔽，对用户暴露出来的是通过一些标准的能力，不管到何处都可以使用相同的方式去操作。这个时候就降低了学习的成本，因为与谁交流何处使用都是一样的。这个时候学习的成本入手的门槛获企业级的门槛会变得更低。接下来会分成复杂性下沉、Serverless Kubernetes 架构、阿里云 ASK 竞争优势、案例介绍。
二、复杂性下沉
1、Serverless 和复杂性下沉
如果要自己完整的搭建一个 Kubernetes 集群的话，首先就是节点管理的复杂度，节点要做节点网络的管理，这个节点能够分配多少 Pod，10个20个60个或者是100多个。
要做一个 Pod 网络的划分。Node 上有多少资源要切出，保留其上面常驻的服务。这些都需要去提前规划好。有的节点会分成一组，这一组节点是系统的组建，另一组节点是跑应用的组件。不同的应用它也不一样，有的应用对稳定性要求比较高，它的资源的规格会更高；有的应用它的稳定性要求没有那么高，它可能追求的是效率，成本会低一点。这个时候它的节点也不一样，其中带来的节点管理的复杂度都会比较高。
另外因为 Kubernetes 是一个相当于有社区有开源的迭代在发展，所以它的很多功能是和版本相关的，所以如果要使用什么功能，就要和它的版本全相关。所以版本升级也有一定的复杂度。
使用了 Serverless Kubernetes 之后就会把这些复杂度不断的下沉到云上，给用户呈现出来的是直接部署应用。
2、Serverless Kubernetes 优势
首先是免运维，使用了 Serverless Kubernetes 之后，就不需要去维护节点了。
在云上不管是使用什么模式，服务一定都是会在 VPC内的。只要有一个 VPC 的网络，虚拟的一个网络环境。因为运行所有的算例，不单单是把服务进行起来，还要做数据的处理，可能要做用户登录的信息的处理，所以一定有数据的存储，所以它都会在一个 VPC 内。在这种情况下创建一个 ASK 集群出来不需要任何的节点，节点上的所有的维护都是免除的。
在没有节点的情况下想要部署应用的话，直接把应用部署上去，需要多少实例它就会自动创建出多少实例，不需要提前准备，减去了准备资源的复杂度。
另外就是兼容性。Serverless Kubernetes 几乎可以把标准安入云上，和云上其他所有的资源比较深的整合在一起。但是要做到有一个标准，就是要兼容社区的使用规范，社区所有的能力一定要有，否则社区的能力就会丧失。兼容社区的标准这是一个优势，Serverless Kubernetes 中的 Pod 就是一个应用的实例，这个实例它是强隔离的，用户可能是进行自己的业务。如果这个集群都是进行自己的业务，那可能是相互信任的。但有些是 ISV 的厂商进行的是三方客户的业务，或者进行的一些服务可能本身是社区的，这个时候它其实在一个强隔离的环境里是非常安全的，不会越狱出来。Serverless Kubernetes 就是这四大特点，也因为弹性扩容几乎是一个无线扩容，兼容社区的标准和它强隔离的特性。
3、ECI 弹性容器实例
Serverless Kubernetes 第一个特点就是免运维，其实首先是把nod 的管理放在云上。首先是有一个 ECI 的实例，可以认为 Pod 以前是在 ECS 的 Nod 上面创建出来，一个 Nod 上面可以创建很多 Pod。其实不需要注意 Nod，一个 Pod 直接对应到一个 ECI 的实例。ECI 和 ECS 如果比的话，可以认为安全隔离的级别是完全一样的，但是它更轻量级，所以一个 Pod 就可以在几秒内创建出一个 ECI 实例。这样的话 Pod 就和云上的资源一一这样对应起来。通过这种方式就做到了零节点，免运维。
4、ASK：Serverless Kubernetes
Serverless 的master 的环境是托管的，所以整个集群是托管的，然后节点也是免运维的。
通过这种方式做到了像 Pod，Deployment，Statefulset 等所有常见的资源以及 CRD 这些资源都是可以在上面开展的。如果把 ECI 接到 Serverless K8S中，就是中间有一个虚拟的 Kubelet，通过虚拟节点的方式接进来。但对于从 Kubernetes 的角度来看，它还都是标准的 Nod 和标准的 Pot，所有的能力和社区的玩法都是一样的，只不过底层的 Pot 是开展在一个轻量级的安全容器中，简单的理解是这样一个意思。所以通过这种方式把 Kubernetes 做成 Serverless 化。
5、虚拟节点的灵活性
在云上 Kubernetes 现在有两种主流的使用 Serverless Pot 这种方式，第一种方式就是最右边，就是 Serverless Kubernetes ASK。第二种方式就是左边，企业级的用户有些时候还是需要使用 ECS 的 Nod 的，也许是因为之前的服务就是在 ECS 的 Note上的。也许是因为有一些特殊的需求，现在 ASK 上还不能满足。
这个时候就可以把虚拟节点装在 ACK 中或者直接使用 ASK。现在提供的能力可以做到一分钟能创建3000个 Pod，这个速度是很快的，不需要准备任何资源。
对于有明显的波峰波谷或者需要经常扩容和所容的这些任务，或者是微服务和批量处理的这种场景，其实这种有典型的周期的都是非常适合的。
三、阿里云 ASK 竞争优势
1、统一资源池
接下来看阿里云上做这种 Serverless K8s 的优势在哪里。第一个就是可以认为 ECS 和 ECI 这两种模式是打通的，只是使用的路径不同。因为 ECS 是在云上发展这么多年，它的基础设施是非常完善的，比如它的融资的处理，比如它的热迁移，比如它生产链路的整个优化，这些都是完全复用的，这是第一点，它的稳定性的基础设施都是复用的。
第二 ECS 的资源池是非常丰富的，它在阿里云上全球有28个region，其中 ECS 和 ECI 是完全打通的，所以 ECS 开展到哪里 ECI 就可以用到哪里，就是相当于使用 ASK 在全域的28个人都可以去用，它的资源池也是打通的，ECS 的资源池和 ECI 的资源池是完全一样的，也就是整个阿里云上所有的资源都可以通过 ECI 的方式开展出来，这样的话对于用户使用云的能力其实是非常方便的。还有就是像 GPU 的这种能力，所有 ECS 支持的规格 ECI也都会支持。所以可以通过 ECI 开展出 GPU 这种实例，直接使用也都是可以的。
2、全球 Region 分布
全球的28个 region，其实所有的 ECS 和 ECI全都一样，这个其实对用户来说具有非常大的便利性，不管是国内的还是在海外去部署其实都是一样的，都是在 K8s 中部署，没有任何差异。
3、Serverless Kubernetes 兼容性
兼容性是 Serverless Kubernetes 中是一个非常重要的标准，如果没有兼容社区 Kubernetes 一些能力的话，那就对用户来说就是有损失的。
常见的这种 workload ，不管是 Deployment，Statefulset，Job 或者是 CRD 都是支持的。这些系统组件 CoreDNS，存储的组件也都是正式的。另外整个生态社区的好处不在于它对这个标准的提出，而是它有一套完整的社区的工具。
比如 Helm，Kustomize 这些工具，首先这批工具是第一批，第一批工具是围绕 K8S 构建出来的。
第二批工具包括大数据和 AI，现在 AI开始流行起来，所有的 AI 的开源的这种生态中都在逐渐的基于 Kubernetes 在构建 AI 部署的解决方案，所以当 Kubernetes 在今天已经非常成熟的时候，这种新兴的业务的企业级的分布式的架构几乎都是 Kubernetes 去部署的，所以比如说像 AI 这种常见点以及其他 AI 的框架，它的分布式的训练都是按 K8s 这种模式去构建。
Kubernetes 社区有一个叫 Conformence contest，就是它的一致性测试，怎么去衡量它的兼容性，就通过一致性测试的成功率来判断。现在的成功率是做到了96%，有一部分是不支持的，这种 Nod 本身是虚拟的，它不是一个真实的，所以这种是选择性不去支持它，其他的测试都是可以通过的，所以对于用户来说部署一个应用，所有的能力都是完备的。
4、ACK，ASK 弹性伸缩策略
核心的弹性的能力 APA 在容器上都是有的，因为做到了社区的兼容，所以这种弹性的能力全都是一样的。除此之外还做了一个增强的弹性，就是右上角这个 AHPA，这个 AHPA 是做的一个增强，这个部分后面会通过一个案例来详细介绍。
四、案例介绍
1、主打弹性和开发场景的业务，支持业务托管
总结起来就是 Serverless Kubernetes 它适合哪些场景的业务是比较好的。第一个是在线业务的弹性，大部分的在线业务都有它的周期性，因为很多业务其实和人的作息时间是有关系的，所以是有明显的周期的。对于这种业务它使用弹性是非常合适的。
第二个是事件的类型的处理，比如说 LoT 或者是一些视频录播的场景，它有明显的周期性的。再往下就是弹性的场景，比如一些 job 的场景有一些 job的任务去处理。
还有一些是CI/ CD，现在在 ASK 里面开展的很多用户其实是在进行 CI/CD 的，它的内部的客户，有可能是对外提供的服务，它们要做一些 CI/CD 处理的时候直接丢到 ASK 中开展，完成之后，就把资源释放掉，所以对他们来说所有社区的 CI/CD 的这些工具都有在 K8S 上的这种开源的架构，它们都支持在 Kubernetes 上面，开展起来很容易。第二个是开展起来自身基本没有任何成本，很容易上手，用完了之后资源自动的清理掉，所以其实对它们来说非常容易。
数据处理比如 Spark，现在有非常多的 Spark 的典型的用户，它们的业务就是可以认为在凌晨的时候开始使用大量的业务，开始进行数据的处理，白天的时候用的也有，但是没有那么多，所以对这种客户免去了所有的节点的运维。
接下来会有大量出现的 AI 这种框架，它们一定大概率都是 Kubernetes，因为它已经是大家通用的一个标准，在哪里都可以用起来，这是一个最大的前提。做一个企业级的框架的时候，一定是基于这个最大的前提和共识，让框架的成功率才会更高，所以 Spark 现在的客户开始逐渐的往 Kubernetes 上转移。
接下来就是 AI 开发机，如果做过 AI 开发的话，可能会有一个比较强的感觉，AI 开发和普通的应用产业开发有个非常大的不同。普通应用产业开发，比如一个微服务调用a调用b，在本地的电脑上启动起来就能开展，可是 AI 的这种开发几乎在自己的电脑上是不能开展的，因为 AI 开发去做一个测试数据集的训练在 Mike 的笔记本上几乎要跑30分钟到几个小时，取决于那个数据集的大小和训练的次数，这个其实非常值得成本，所以AI开发现在一个比较好的办法就是在云上买一个实例在上面做开发。
但是因为它是一个开发环境，其实里面有很多数据是要保留的，不是进行完把它丢掉就好了，所以这个开发环境需要有类似于关机的一个能力，需要保留数据，这些能力也是基于 ASK 提供了这样的一个功能，所以在 AI 的环境就算开发也是有这样的环境来用，就会发现它是一个完整的生态，所有人都是在生态上去构建，所以它就更容易做的更多。第二个是应用免运维，就是典型的微服务的应用，然后通过 ingress 或者是 SLB 这种网关把它暴露出去，下面的话就是workload Pod在进行。
2、案例：免运维应用托管
这里前面提到了一点就是 AHPA，左边这个图是说比较理想的情况下，那条绿色的线是供给给应用的资源，那条橙色的线是这个应用它真实需要的资源，其实理想的情况下是供给的资源比真实需要的稍微多一点，只要足够它使用就好了，因为只要多余的其实都是浪费的，假设都是在 K8S 里面或者是传统的 ECS 里面去部署一个应用的时候，大概率采用了右上角的方式，就是应用的实例数是固定的，固定的实例数是应用真正需要资源的时候，它是一个周期性的曲线，所以这里面存在巨大的浪费。使用 AHPA 的原因在于因为如果是使用社区那种弹性方案的话，社区弹性方案的思路都是这样的，比如发现CPU不够了开始弹。第一个发现 CPU 不够的时候已经晚了，第二个开始弹出来的 Pod，它变得可用的时候也是需要一段时间的，所以整个资源的供给是延后的，发现它需要资源都已经延后了，然后资源在完成供给又要延后，所以这是它的传统弹性的一个问题，这是大家在云上非常重的企业应用不太敢使用弹性的一个核心原因。
通过积极学习的方式去预测这个应用的周期性，比如如果这个应用进行了七天，就可以根据七天预测它的周期性；如果没有周期，那我给出预测值建议可能就是一条直线，如果它是有周期的话，那可能就给出一个周期性波动的曲线。今天这个事情在 Kubernetes 能做的更好的原因在于K8s里面整个系统它做了非常多的功能，把复杂度包装起来，对用户来说不需要做很多事情，做了这件事情之后有个额外的收益，它知道所有的上下文，这个 Pod 是什么时候创建的都知道。拿到应用的每个实例的生命周期之后，就知道了 Pod 从创建到开展需要多长时间，根据应用的周期性把应用的 redate 时间也知道所以就提前扩容。基于这两个前提做到了提前扩容，通过提前扩容的方式能够做到左上角的形式。当资源真正需要的时候提前把它准备好。
左下角就是在线开展的真实的一个应用，绿色的线显示它保持最大值 Pod 数不变的话，传统的应用管理部署的方式其实是一条直线，预测出来的就是周期性的也就是蓝色的线，相对于固定的实例数最大值是6，预测的方式节省了将近69.8%的资源，几乎是70%的资源，对它来说是一个巨大的收益，实例数减少一点，大部分都是3。假设它的固定实例数是三，也是一条直线的时候，预测节省的是 39.6%的资源，这个效果是非常可观的，这个是用户真实的去开展业务。
3、案例:Use Virtual Node at scale with kubernetes
使用 Severless Kubernetes 的弹性的 Pod 有两种方式，第一种是 ASK 方式，第二种是 ACK 方式。ACK 就是传统的 ECS 的 Nod，加弹性的 ECI 的Pod，这种方式也可以开展。蓝色的线表示常驻，可能有一些应用是不能弹的，大部分业务一直都能常驻。弹性 Pod 在 ECI 中，两种模式相互搭配，把虚拟节点安装在 ACK 的 K8s 指点就行了。
4、案例：面对突发流量的弹性扩容
这是突发流量，微博现在用的正是这段视频，给微博提供的能力就是3000个 Pod。ASK 能够快速的把应用弹起来。
很多客户都是使用这种典型的模式，会把任务直接提交到 K8s 中，要求就是 Kubernetes 一定要兼容社区的标准，因为现在很多第一资源包括大数据，AI 等，因为 K8s 是不会面向新兴的业务去定义 workLoad，所有的 workLoad 都是开发者自己定义的。这就是 CRD 这种方式，所以K8s 是一定要兼容 CRD 这种方式，才能让新型的业务开展起来。EMR 的架构也可以进行，K8s 也可以支持 EMR 算例，因为 EMR 算例典型的优势是成本低。
5、CI/CD Pipeline
使用 CI/CD 其实也是非常典型的，它在测试发布的时候可能同时编译很多版本，可能在很多环境同时去测试，测试完去做发布，对它来说在测试的时候需要一大批资源，测试完之后这些资源需要立刻释放掉，这个也是非常合适的场景。
6、案例：RTC 直播流转录/混流
视频直播转码的这些方式其实都是典型的，直播也是有非常强的周期性，白天直播少一点，夜间直播的多一点。
7、案例：PyTorch/TensorFlow/Caffe
AI 的训练以及它的推理在线的运行比如 Kubectl 的方式都是 Kubernetes 来监测的，这种新型模式的业务也都是 K8S 这种模式。
8、案例：执行 Job
典型的 Job 场景同样适用于 K8S，因为都是按需使用的，都是非常适合使用 Severless Kubernetes 这种模式。
