技术干货:解密最受欢迎的开源 Serverless 框架弹性技术实现

2023-10-30

Knative 是一款基于 Kubernetes 的开源 Serverless 应用编排框架,其目标是制定云原生、跨平台的 Serverless 应用编排标准。Knative 主要功能包括基于请求的自动弹性、缩容到 0、多版本管理、基于流量的灰度发布以及事件驱动等。

弹性是 Serverless 中的核心能力,那么 Knative 作为 CNCF 社区最受欢迎的开源 Serverless 应用框架,提供了哪些与众不同的弹性能力呢?本文将带你深入了解 Knative 的弹性实现。(说明:本文基于 Knative 1.8.0 版本进行分析)

Knative 提供了基于请求的自动弹性实现 KPA(Knative Pod Autoscaler),也支持 K8s 中的 HPA,此外 Knative 提供了灵活的弹性扩展机制,可以结合自身业务需要,扩展弹性实现。这里我们也会介绍与 MSE 结合实现精准弹性以及与 AHPA 结合实现基于请求的弹性预测。

首先我们介绍 Knative 原生最具吸引力的弹性:KPA。

基于请求的自动弹性 KPA

基于 CPU 或者 Memory 的弹性,有时候并不能完全反映业务的真实使用情况,而基于并发数或者每秒处理请求数 (QPS/RPS),对于 web 服务来说更能直接反映服务性能,Knative 提供了基于请求的自动弹性能力。要获得当前服务的请求数,Knative Serving 为每个 Pod 注入 QUEUE 代理容器 (queue-proxy),该容器负责收集用户容器并发数 (concurrency) 或请求数 (rps) 指标。Autoscaler 定时获取这些指标之后,会根据相应的算法,调整 Deployment 的 Pod 数量,从而实现基于请求的自动扩缩容。

图片来源:https://knative.dev/docs/serving/request-flow/

基于请求数的弹性算法

Autoscaler 基于每个 Pod 的平均请求数(或并发数)进行弹性计算。默认情况下 Knative 使用基于并发数的自动弹性, 默认 Pod 的最大并发数为 100。此外 Knative 中还提供了一个叫 target-utilization-percentage 的概念,称之为目标使用率,取值范围 0~1,默认是 :0.7。

以基于并发数弹性为例,Pod 数计算方式如下:

POD数=并发请求总数/(Pod最大并发数*目标使用率)

例如服务中 Pod 最大并发数设置了 10,这时候如果接收到了 100 个并发请求,目标使用率设置为 0.7,那么 Autoscaler 就会创建了 15 个 POD(100/(0.7*10) 约等于 15)。

缩容到 0 的实现机制

使用 KPA 时当无流量请求时,会将 Pod 数自动缩容到 0;当有请求时,会从 0 开始扩容 Pod。那么 Knative 中是如何实现这样的操作呢?答案是通过模式切换。

Knative 中定义了 2 种请求访问模式:Proxy 和 Serve。Proxy 顾名思义,代理模式,也就是请求会通过 activator 组件进行代理转发。Serve 模式是请求直达模式,从网关直接请求到 Pod,不经过 activator 代理。如下图:

模式的切换是由 autoscaler 组件负责,当请求为 0 时,autoscaler 会将请求模式切换为 Proxy 模式。这时候请求会通过网关请求到 activator 组件,activator 收到请求之后会将请求放在队列中,同时推送指标通知 autoscaler 进行扩容,当 activator 检测到由扩容 Ready 的 Pod 之后,随即将请求进行转发。而 autoscaler 也会判断 Ready 的 Pod,将模式切换为 Serve 模式。

应对突发流量

突发流量下如何快速弹资源

KPA 涉及到 2 个与弹性相关的概念:Stable(稳定模式)和 Panic(恐慌模式),基于这 2 种模式,可以让我们认识到 KPA 如何基于请求做到精细化弹性。

首先稳定模式是基于稳定窗口期,默认是 60 秒。也就是计算在 60 秒时间段内,Pod 的平均并发数。

而恐慌模式是基于恐慌窗口期,恐慌窗口期是通过稳定窗口期与 panic-window-percentage 参数计算得到。panic-window-percentage取值是 0~1,默认是 0.1。恐慌窗口期计算方式:恐慌窗口期=稳定窗口期 *panic-window-percentage。默认情况下也就是 6 秒。计算在 6 秒时间段内,Pod 的平均并发数。

KPA 中会基于稳定模式和恐慌模式 Pod 的平均并发数分别计算所需要的 Pod 数。

那么实际根据哪个值进行弹性生效呢?这里会依据恐慌模式下计算的 Pod 数是否超过恐慌阈值 PanicThreshold 进行判断。恐慌阈值是通过 panic-threshold-percentage/100 计算出来,panic-threshold-percentage 参数默认是 200,也就是恐慌阈值默认是 2。当恐慌模式下计算出来的 Pod 数大于或等于当前 Ready Pod 数的 2 倍,那么就会使用恐慌模式 Pod 数进行弹性生效,否则使用稳定模式 Pod 数。

显然,恐慌模式的设计是为了应对突发流量场景。至于弹性敏感度,则可以通过上述的可配置参数进行调节。

突发流量下如何避免 Pod 被打爆

KPA 中可以设置突发请求容量(target-burst-capacity)应对 Pod 被超预期的流量打爆。也就是通过这个参数值的计算,来调节请求是否切换到 Proxy 模式,从而通过 activator 组件作为请求缓冲区。如果当前 ready pod 数*最大并发数-突发请求容量-恐慌模式计算出来的并发数 <0,意味着突发流量超过了容量阈值,则切换到 activator 进行请求缓冲。当突发请求容量值为 0 时,只有 Pod 缩容到 0 时,才切换到 activator。当大于 0 并且 container-concurrency-target-percentage 设置为 100 时,请求总是会通过 activator。-1 表示无限的请求突发容量。请求也总是会通过 activator。

减少冷启动的一些技巧

延迟缩容

对于启动成本较高的 Pod, KPA 中可以通过设置 Pod 延迟缩容时间以及 Pod 缩容到 0 保留期,来减少 Pod 扩缩容频率。

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/scale-down-delay: ""60s"
        autoscaling.knative.dev/scale-to-zero-pod-retention-period: "1m5s"
    spec:
      containers:
        - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/helloworld-go:73fbdd56

调低目标使用率,实现资源预热

Knative 中提供了目标阈值使用率的配置。通过调小该值可以提前扩容超过实际需要使用量的 Pod 数,在请求达到目标并发数之前进行扩容,间接的可以做到资源预热。例如,如果 containerConcurrency 设置为 10,目标利用率值设置为 70(百分比),则当所有现有 Pod 的平均并发请求数达到 7 时,Autoscaler 将创建一个新 Pod。因为 Pod 从创建到 Ready 需要一定的时间,通过调低目标利用率值可以做到提前扩容 Pod,从而减少冷启动导致的响应延迟等问题。

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/target-utilization-percentage: "70"
    spec:
      containers:
        - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/helloworld-go:73fbdd56

配置 KPA

通过上面的介绍,我们对 Knative Pod Autoscaler 工作机制有了进一步的了解,那么接下来介绍如何配置 KPA。Knative 中配置 KPA 提供了两种方式:全局模式和 Revision 模式。

全局模式

全局模式可以修改 K8s 中的 ConfigMap:config-autoscaler,查看 config-autoscaler 使用如下命令:

kubectl -n knative-serving get cm config-autoscaler
apiVersion: v1
kind: ConfigMap
metadata:
 name: config-autoscaler
 namespace: knative-serving
data:
 container-concurrency-target-default: "100"
 container-concurrency-target-percentage: "70"
 requests-per-second-target-default: "200"
 target-burst-capacity: "211"
 stable-window: "60s"
 panic-window-percentage: "10.0"
 panic-threshold-percentage: "200.0"
 max-scale-up-rate: "1000.0"
 max-scale-down-rate: "2.0"
 enable-scale-to-zero: "true"
 scale-to-zero-grace-period: "30s"
 scale-to-zero-pod-retention-period: "0s"
 pod-autoscaler-class: "kpa.autoscaling.knative.dev"
 activator-capacity: "100.0"
 initial-scale: "1"
 allow-zero-initial-scale: "false"
 min-scale: "0"
 max-scale: "0"
 scale-down-delay: "0s"

参数说明:

参数 说明
container-concurrency-target-default 默认Pod最大并发数,默认值100
container-concurrency-target-percentage 并发数目标使用率,70实际表示0.7
requests-per-second-target-default 默认每秒请求数(rps),默认值200
target-burst-capacity 突发请求容量
stable-window 稳定窗口,默认60s
panic-window-percentage 恐慌窗口比例,默认值为10,则表示默认恐慌窗口期为6秒(60*0.1=6)
panic-threshold-percentage 恐慌阈值比例,默认值200
max-scale-up-rate 最大扩缩容速率,表示一次扩容最大数,实际计算方式:math.Ceil(MaxScaleUpRate * readyPodsCount)
max-scale-down-rate 最大缩容速率,表示一次缩容最大数,实际计算方式:math.Floor(readyPodsCount / MaxScaleDownRate)。默认值2表示,每次缩容一半。
enable-scale-to-zero 是否开始缩容到0,默认开启
scale-to-zero-grace-period 优雅缩容到0的时间,也就是延迟多久缩容到0,默认30s
scale-to-zero-pod-retention-period pod缩容到0保留期,该参数适用于Pod启动成本较高的情况
pod-autoscaler-class 弹性插件类型,当前支持的弹性插件包括:kpa、hpa、ahpa以及mpa(ask场景下配合mse支持缩容到 0)
activator-capacity activator请求容量
initial-scale 创建revision时,初始化启动的Pod数,默认1
allow-zero-initial-scale 是否允许创建revision时,初始化0个Pod, 默认false,表示不允许
min-scale revision级别最小保留的Pod数量。默认0表示最小值可以为0
max-scale revision级别最大扩容的Pod数量。默认0表示无最大扩容上限
scale-down-delay 表示延迟缩容时间,默认0表示立即缩容

Revision 版本模式

在 Knative 中可以为每一个 Revision 配置弹性指标,部分配置参数如下:

  • 指标类型
    • 每个 revision 指标注解:autoscaling.knative.dev/metric
    • 支持的指标:"concurrency","rps","cpu","memory"以及其它自定义指标
    • 默认指标:"concurrency"
  • 目标阈值
    • autoscaling.knative.dev/target
    • 默认值:"100"
  • pod 缩容到 0 保留期
    • autoscaling.knative.dev/scale-to-zero-pod-retention-period
  • 目标使用率
    • autoscaling.knative.dev/target-utilization-percentage

配置示例如下:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/metric: "concurrency"
        autoscaling.knative.dev/target: "50"
        autoscaling.knative.dev/scale-to-zero-pod-retention-period: "1m5s"
        autoscaling.knative.dev/target-utilization-percentage: "80"

对 HPA 的支持

对于 K8s HPA, Knative 也提供天然的配置支持,可以在 Knative 使用基于 CPU 或者 Memory 的自动弹性能力。

  • 基于 CPU 弹性配置
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/class: "hpa.autoscaling.knative.dev"
        autoscaling.knative.dev/metric: "cpu"
  • 基于 Memory 的弹性配置
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/class: "hpa.autoscaling.knative.dev"
        autoscaling.knative.dev/metric: "memory"

弹性能力增强

Knative 提供了灵活的插件机制(pod-autoscaler-class),可以支持不同的弹性策略。阿里云容器服务 Knative 当前支持的弹性插件包括:kpa、hpa、精准弹性扩缩容 mpa 以及 具有预测能力的 ahpa。

保留资源池

在原生的 KPA 能力之上,我们提供了保留资源池的能力。该功能可以应用在如下场景:

  • ECS 与 ECI 混用。如果希望常态情况下使用 ECS 资源,突发流量使用 ECI, 那么我们可以通过保留资源池来实现。如单个 Pod 处理的并发 10,保留资源池 Pod 数为 5,那么常态下通过 ECS 资源可以应对不超过 50 的并发请求。如果并发数超过 50,那么 Knative 就会扩容新的 Pod 数来满足需求,新扩容出来的资源使用 ECI。

  • 资源预热。对于完全使用 ECI 的场景,也可以通过保留资源池实现资源预热。当在业务波谷时使用保留实例替换默认的计算型实例,当第一个请求来临时使用保留实例提供服务,同时也会触发默认规格实例的扩容。当默认规格实例扩容完成以后所有新请求就会都转发到默认规格上,同时保留实例则不会接受新的请求,并且等保留实例所有接收到的请求处理完成以后就会被下线。通过这种无缝替换的方式实现了成本和效率的平衡,即降低了常驻实例的成本又不会有显著的冷启动时长。

精准弹性扩缩容

单个 Pod 处理请求的吞吐率有限,如果多个请求转发到同一个 Pod,会导致服务端过载异常,因此需要精准的控制单个 Pod 请求并发处理数。尤其对一些 AIGC 场景下,单个请求会占用较多的 GPU 资源,需要严格的限制每个 Pod 并发处理的请求数。

Knative 与 MSE 云原生网关结合,提供基于并发数精准控制弹性的实现:mpa 弹性插件。

mpa 会从 MSE 网关获取并发数,并计算所需要的 Pod 数进行扩缩容,而 MSE 网关可以做到基于请求精准转发。

配置示例如下:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/class: mpa.autoscaling.knative.dev
        autoscaling.knative.dev/max-scale: '20'
    spec:
      containerConcurrency: 5
      containers:
      - image: registry-vpc.cn-beijing.aliyuncs.com/knative-sample/helloworld-go:73fbdd56
        env:
        - name: TARGET
          value: "Knative"

参数说明:

参数 说明
autoscaling.knative.dev/class: mpa.autoscaling.knative.dev mpa表明使用MSE指标进行扩缩容,支持缩容到0
autoscaling.knative.dev/max-scale: '20' 扩容Pod数上限是20
containerConcurrency: 5 表示单个Pod能处理的最大并发数是5

弹性预测 AHPA

容器服务 AHPA(Advanced Horizontal Pod Autoscaler)可以根据业务历史指标,自动识别弹性周期并对容量进行预测,解决弹性滞后的问题。

当前 Knative 支持 AHPA(Advanced Horizontal Pod Autoscaler)的弹性能力,当请求具有周期性时,可通过弹性预测,实现预热资源。相比于调低阈值进行资源预热,通过 AHPA 可以最大程度的提升资源利用率。

此外由于 AHPA 支持自定义指标配置,Knative 与 AHPA 结合可以做到基于消息队列以及响应延迟 rt 的自动弹性。

基于 rps 使用 AHPA 配置示例如下:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: autoscale-go
  namespace: default
spec:
  template:
    metadata:
      labels:
        app: autoscale-go
      annotations:
        autoscaling.knative.dev/class: ahpa.autoscaling.knative.dev
        autoscaling.knative.dev/target: "10"
        autoscaling.knative.dev/metric: "rps"
        autoscaling.knative.dev/minScale: "1"
        autoscaling.knative.dev/maxScale: "30"
        autoscaling.alibabacloud.com/scaleStrategy: "observer"
    spec:
      containers:
        - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/autoscale-go:0.1

参数说明:

参数 说明
autoscaling.knative.dev/class: ahpa.autoscaling.knative.dev 指定弹性插件AHPA。
autoscaling.knative.dev/metric: "rps" 设置AHPA指标。目前支持concurrency、rps以及响应时间rt。
autoscaling.knative.dev/target: "10" 设置AHPA指标的阈值,本示例rps阈值为10,表示单个Pod每秒最大处理请求数10。
autoscaling.knative.dev/minScale: "1" 设置弹性策略实例数的最小值为1。
autoscaling.knative.dev/maxScale: "30" 设置弹性策略实例数的最大值为30。
http://autoscaling.alibabacloud.com/scaleStrategy: "observer" 设置弹性伸缩模式,默认值是observer。observer:表示只观察,但不做真正的伸缩动作。您可以通过这种方式观察AHPA的工作是否符合预期。由于预测需要历史7天的数据,因此创建服务默认是observer模式。auto:表示由AHPA负责扩容和缩容,把AHPA指标和阈值输入到AHPA,AHPA最终决定是否生效。
  • ta-draft-node="block" data-draft-type="table" data-size="normal" data-row-style="normal">
    参数 说明
    autoscaling.knative.dev/class: ahpa.autoscaling.knative.dev 指定弹性插件AHPA。
    autoscaling.knative.dev/metric: "rps" 设置AHPA指标。目前支持concurrency、rps以及响应时间rt。
    autoscaling.knative.dev/target: "10" 设置AHPA指标的阈值,本示例rps阈值为10,表示单个Pod每秒最大处理请求数10。
    autoscaling.knative.dev/minScale: "1" 设置弹性策略实例数的最小值为1。
    autoscaling.knative.dev/maxScale: "30" 设置弹性策略实例数的最大值为30。
    http://autoscaling.alibabacloud.com/scaleStrategy: "observer" 设置弹性伸缩模式,默认值是observer。observer:表示只观察,但不做真正的伸缩动作。您可以通过这种方式观察AHPA的工作是否符合预期。由于预测需要历史7天的数据,因此创建服务默认是observer模式。auto:表示由AHPA负责扩容和缩容,把AHPA指标和阈值输入到AHPA,AHPA最终决定是否生效。
  • e data-draft-node="block" data-draft-type="table" data-size="normal" data-row-style="normal">

小结

本文从 Knative 典型弹性实现 KPA 出发进行介绍,包括如何实现基于请求的自动弹性、缩容到 0、应对突发流量以及我们在 Knative 弹性功能上的扩展增强,包括保留资源池,精准弹性以及弹性预测能力。

作者:元毅

点击立即免费试用云产品 开启云上实践之旅!

原文链接

本文为阿里云原创内容,未经允许不得转载。

本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)

技术干货:解密最受欢迎的开源 Serverless 框架弹性技术实现 的相关文章

随机推荐

  • 如何在内存中执行二进制代码之win平台

    大家可能会很好奇 我们的任意exe程序 不就是在内存中执行的二进制机器码吗 不 今天我要说的是 我们如何把实现指定功能的一段二进制机器码 放到我们的程序中 然后在需要的时候 直接调用它 当然 这段代码也有其他用途 故而有了shell cod
  • 公众号分享

    配置 gt 登录公众号 gt 设置与开发 gt 公众号设置 gt 功能设置 gt js安全域名域名 gt 网页授权域名 1 先拿集成微信 js 路径写自己的 import wxshare from common js wxShareModu
  • 【树莓派之旅】第01期:一根网线搞定树莓派可视化界面

    一次偶然的机会接触到了树莓派 于是就购了一个板子 入手快两个月了 由于一直忙于工作的事情 所以也就没折腾 今天拿出来的时候发现要想把树莓派运行起来还需要一些其他外接设备 一时也没去某宝或某东上采购 就利用手头现有的资源玩一下 于是就有了此文
  • Sentinel实现动态配置的集群流控的方法

    这篇文章主要介绍了Sentinel实现动态配置的集群流控 本文给大家介绍的非常详细 对大家的学习或工作具有一定的参考借鉴价值 需要的朋友可以参考下 介绍 为什么要使用集群流控呢 相对于单机流控而言 我们给每台机器设置单机限流阈值 在理想情况
  • 部署 - 前端部署https服务,并配置安全证书

    项目中要实现跨tab复制 剪切 粘贴 所以涉及到操作剪切板的操作 选用了navigator clipboard 但是该api有必须在https的服务下才能用 所以就需要把项目部署城https服务 vue cli中可以配置webpack达到启
  • Android OkHttp源码阅读详解一

    博主前些天发现了一个巨牛的人工智能学习网站 通俗易懂 风趣幽默 忍不住也分享一下给大家 点击跳转到教程 前言 源码阅读基于okhttp 3 10 0 Android中OkHttp源码阅读二 责任链模式 implementation com
  • 注解实现CRUD

    CRUD 我们可以在工具类创建的时候实现自动提交事务 这个是在MybatisUtils工具类里面的弄的 public static SqlSession getSqlSession return sqlSessionFactory open
  • react 加粗_React入门的家庭作业(1-2)

    作业前准备 React在他的官网上挂了一个入门教程 是做一个xxoo棋的小游戏 在教程的最后留下了6个作业题 现在就来完成一下 准备材料 作业是在已完成教程的基础上做的 所以这里预设已经做好了环境部署 写好了游戏代码 如果没有 可以把这个复
  • 深聊性能测试,从入门到放弃之:性能测试技术栈,看完这篇,保证刷新你对性能测试的认知~~

    性能测试技术栈 1 引言 2 性能测试基础 2 1 性能测试理论 2 2 测试开发技能 3 性能监听诊断 3 1 前端监听诊断 3 2 服务器监听诊断 3 2 1 Linux 3 2 2 Windows Server 3 3 中间件监听诊断
  • 实现http到https的重定向

    vim etc httpd conf httpd conf DocumentRoot var www html redirect temp https www a com RewriteEngine on RewriteRule https
  • tensorflow笔记【9】深度学习-几个经典网络的基本结构

    tensorflow笔记 9 深度学习 几个经典网络的基本结构 文章目录 前言 一 卷积神经网络 二 经典网络结构 1 自制CNN 2 LeNet 3 AlexNet 4 VGGNet 5 InceptionNet 6 ResNet 总结
  • Java - Java基础(一)

    一 计算机基础知识 1 计算机简介 第一台通用计算机 ENIAC 2 数据的存储和运算 计算机中对于数据的存储和运算 都是通过二进制数据来完成 3 人机交互方式 图形化界面 DOS命令行 D 切换盘符 dir 查看当前路径下的文件信息 cd
  • Android中的drawable像素密度适配详解

    本文大纲 1 为什么要分drawable xxx目录 2 Bitmap的介绍 3 不同drawable xxx中的图片内存测试 1 为什么要分drawable xxx目录 android项目资源中对于drawable文件夹可以分为以下类型的
  • 【Transformer】10、HRFormer:High-Resolution Transformer for Dense Prediction

    文章目录 一 背景 二 方法 三 效果 论文链接 https arxiv org abs 2110 09408 代码链接 https github com HRNet HRFormer 一 背景 ViT 的提出让人们看到了 Transfor
  • 一文弄懂神经网络中的BP反向传播算法

    注 本文转自 一文弄懂神经网络中的BP反向传播算法 Charlotte77 博客园 安利 Charlotte77 的深度学习系列博客 最近在看深度学习的东西 一开始看的吴恩达的UFLDL教程 英文版 有中文版就直接看了 后来发现有些地方总是
  • 网卡中断优化

    1 中断的配置 root zxinos etc init d irq balancer status Checking for service irqbalance running etc init d irq balancer 是linu
  • 浅谈sleep、wait、yield、join区别

    sleep sleep 方法是属于 Thread 类中的 sleep 过程中线程不会释放锁 只会阻塞线程 让出cpu给其他线程 但是他的监控状态依然保持着 当指定的时间到了又会自动恢复运行状态 可中断 sleep 给其他线程运行机会时不考虑
  • 小甲鱼学python学习笔记

    一 序章 1 python缩进问题 if a 0 else while a 0 2 字符串拼接与控制台输入输出 input 可从控制台读入数据 括号内地字符串为输入时的提示 输入结果可通过变量保存 print 控制台输出 s input p
  • Linux 常用指令大全

    我是目录 1 指令格式 2 Windows 和 Linux 通用内容 3 路径的命令 1 cd 切换到某个目录 相对路径 绝对路径 2 pwd 显示当前路径 3 ls 列出目录下的所有子目录与文件 或 文件的信息 4 目录 文件的指令 1
  • 技术干货:解密最受欢迎的开源 Serverless 框架弹性技术实现

    Knative 是一款基于 Kubernetes 的开源 Serverless 应用编排框架 其目标是制定云原生 跨平台的 Serverless 应用编排标准 Knative 主要功能包括基于请求的自动弹性 缩容到 0 多版本管理 基于流量