擅长容器, Kubernetes 技术领域
Kubernetes 作为当今云原生业界标准,具备良好的生态以及跨云厂商能力。Kubernetes 很好的抽象了 IaaS 资源交付标准,使得云资源交付变的越来越简单,与此同时用户期望更多的聚焦于业务自身,做到面向应用交付,Serverless 理念也因此而生。 那么如何通过原生 k8s 提供Serverless 能力?如何实现GPU等异构资源按需使用?这里给大家介绍一下我们在Serverless Kubernetes 开发实践:异构资源,按需使用。
背景随着生成型AI技术的能力提升,越来越多的注意力放在了通过AI模型提升研发效率上。作为 AIGC (AI Gererative Content)领域的知名项目 Stable Diffusion , 可以帮助用户快速、准确地生成想要的场景及图片。不过当前使用 Stable Diffusion 面临如下问题:单个Pod处理请求的吞吐率有限,如果多个请求转发到同一个Pod,会导致服务端过载异常,因此需
背景Knative是一款基于Kubernetes的 Serverless 框架。其目标是制定云原生、跨平台的 Serverless 容器编排标准。Knative通过整合容器构建(或者函数)、工作负载管理(动态扩缩)以及事件驱动这三者来实现的这一Serverless标准。Knative 提供了简单的应用模型,并且支持流量管理能力可以根据百分比进行灰度发布。那么如何在 Knative 提供产品化的方式
背景Knative是一款基于Kubernetes的 Serverless 框架。其目标是制定云原生、跨平台的 Serverless 容器编排标准。Knative通过整合容器构建(或者函数)、工作负载管理(动态扩缩)以及事件驱动这三者来实现的这一Serverless标准。Knative 提供了简单的应用模型,并且支持流量管理能力可以根据百分比进行灰度发布。那么如何在 Knative 提供产品化的方式
Knative是一款基于Kubernetes的 Serverless 框架。其目标是制定云原生、跨平台的 Serverless 容器编排标准。Knative通过整合容器构建(或者函数)、工作负载管理(动态扩缩)以及事件驱动这三者来实现的这一Serverless标准。那么如何给 Knative 提供生产级别的事件驱动能力?这里我们可以通过事件总线 EventBridge 来实现.事件总线EventB
在云原生场景下,资源容量往往难以预估,而使用 K8s 原生的 HPA,往往要面对弹性滞后以及配置复杂问题。阿里云容器服务与达摩院决策智能时序团队合作推出的 AHPA(Advanced Horizontal Pod Autoscaler)弹性预测,可以根据业务历史指标,自动识别弹性周期并对容量进行预测,帮你提前进行弹性规划,解决弹性滞后的问题。 AHPA 如何配置才能解锁最佳使用姿势?本文给你带来 AHPA 弹性预测最佳实践
Knative 是基于Kubernetes之上提供的一款开源Serverless应用框架,帮助您部署和管理现代化的Serverless工作负载,打造企业级Serverless平台。阿里云容器服务 Knative 集成云产品ALB, 提供超强弹性及大规模七层流量处理能力,同时支持Header、Cookie灰度发布。
在云原生容器时代,用户需要面对不同的业务场景:周期性的业务,Serverless 按需使用等。在使用自动弹性中, 会发现这样或那样的问题,其中最需要关注的是弹性滞后、冷启动问题。阿里巴巴云原生团队和阿里达摩院决策智能时序团队合作开发 AHPA 弹性预测产品,该产品主要出发点是基于检测到的周期做“定时规划”,通过规划实现提前扩容的目的,在保证业务稳定的情况下,让你真正实现按需使用。
Kubernetes 作为当今云原生业界标准,具备良好的生态以及跨云厂商能力。Kubernetes 很好的抽象了 IaaS 资源交付标准,使得云资源交付变的越来越简单,与此同时用户期望更多的聚焦于业务自身,做到面向应用交付,Serverless 理念也因此而生。 那么如何通过原生 k8s 提供 Serverless 能力? 如何借力丰富的云原生社区生态?这里给大家介绍一下我们在 Serverless Kubernetes 上的落地实践
Knative 是基于 Kubernetes 之上提供的一款开源 Serverless 应用框架,帮助用户部署和管理现代化的 Serverless 工作负载,打造企业级 Serverless 平台。近期 Knative 发布了 1.0 版本,达到了一个重要的里程碑。而随着 Knative 1.0 的发布,相信有更多的用户去拥抱 Knative.
阿里云容器服务 ALB Ingress Controller 基于应用型负载均衡 ALB(Application Load Balancer) 之上提供全托管免运维的 Ingress 流量管理。依托阿里云容器服务 Kubernetes 产品,兼容 Nginx Ingress 语义,具备配置以及管理复杂业务路由的能力,证书自动发现,流量入口可观测,同时支持多种应用层协议(QUIC等),具备大规模七层流量处理能力,让用户轻松应对云原生应用流量管理。
阿里云 Knative 基于 ASK 之上,在完全兼容社区 Knaitve 的同时对 FC、ECI 工作负载进行统一应用编排,支持事件驱动、自动弹性,为您提供统一的 Serverless 应用编程模型。
Knative 是基于 Kubernetes 的开源 Serverless 应用编排框架。阿里云 Knative 在社区Knative基础之上,与阿里云产品进行了深度的融合,给你带来最纯粹的容器化 Serverless 体验。
微服务和容器化带来了将应用程序分解成可重复使用的小型单元的诉求,这些单元通常作为单独的进程运行,或者在单独的容器运行。 Kubernetes的Pod模型允许用户创建一个部署单元,该单元可以打包多个容器作为应用程序的单个实例。 Knative 用户当前同样存在将多个容器部署到一个Pod中对诉求。支持多个容器的能力将有利于把更广泛的工作负载部署到Knative Serving模型中。因此 Knative 从 0.16.0 版本开始提供多个容器的能力。
在 Knative 可以基于流量比例进行灰度发布,但有时候我们需要将确切的请求灰度到指定的版本上进行验证,在 Knative 0.18 版本并结合Kourier网关可以实现基于Header的灰度验证。
Knative 作为主流的开源 Serverless Framework,除了提供应用部署、自动弹性之外,还提供事件驱动能力。在面对 AI 场景时,用户对事件对精细化处理以及节省资源成本都有较高对要求,这里介绍通过Knative实现事件驱动、事件分发与资源自动弹性,很好的满足用户场景的诉求
作为 Severless Framework 就离不开按需分配资源的能力,Knative 提供了基于流量的自动扩缩容能力,可以根据应用的请求量在高峰时期自动扩容实例数,当请求量减少以后自动缩容实例数,做到自动化的帮助您节省成本。此外 Knative 还提供了基于流量的灰度发布能力,可以根据流量百分比进行灰度发布。
随着云计算技术的发展,云资源交付变的越来越简单,按需使用已经成为可能。在按需使用资源的模式下,用户更多的聚焦于业务自身,而减少了对基础设施的关注,Serverless 理念也因此应运而生。Knative 在 K8s 之上又做了进一步的简化,大大降低了应用生命周期管控复杂度,同时提供了自动弹性和灰度发布等能力,同时基于阿里云 Severless Kubernetes (ASK)提供的极致容器化 Serverless,给您带来云原生 Serverless 应用完全体。
Kourier 是一个基于Envoy实现的轻量级网关,是专门对于 Knative Serving 服务访问提供的一个网关实现。本文做个简单的介绍
kn 是 Knative 命令行操作客户端。 通过 kn 可以方便的操作Knative 相关的资源。
Knative 是一款基于 Kubernetes 之上的开源 Serverless 框架,其目标之一是降低用户服务部署及使用门槛。在此基础上提还供了其它丰富的功能,如自动扩缩容,路由流量,金丝雀发布以及事件驱动等。在本文中,我们首先 Kubernetes 上部署应用并进行服务访问,然后在 Knative 中部署同样的服务并访问,以此对比来看Knative如何降低了服务部署及访问的门槛。
Knative 0.17.0 版本已于近期发布,对于 Knative v0.17.0 版本新特性,我们进行解读,让大家对 Knative 新版本快速了解。
Knative 0.16.0 版本已于近期发布,针对 Knative v0.16.0 版本对这些新功能特性进行解读,让你快速对新版本特性有所深入了解。
Knative 0.15.0 版本已于近期发布,针对 Knative Serving v0.15.0 版本对这些新功能特性进行解读,让你快速对新版本特性有所深入了解。
Knative Eventing v0.14.0 版本已于近期发布,新版本带来了哪些特性呢?本文会进行相关的解读
想必大家都比较了解 RocketMQ 消息服务,那么RocketMQ 与 Serverless 结合会碰撞怎样的火花呢?那我们今天介绍一下如何基于 RocketMQ + Knative 驱动云原生 Serverless 应用 。
Knative Eventing v0.13.0 发布了,猜一下这个版本有没有惊喜特性,本文给你带来解读。
本文针对 Knative Eventing v0.12.0 版本新功能特性进行解读,让你快速对 v0.12.0 版本有所了解。
Knative 中提供了自动扩缩容灵活的实现机制,本文从 `三横两纵` 的维度带你深入了解 KPA 自动扩缩容的实现机制。让你轻松驾驭 Knative 自动扩缩容。
Knative Eventing v0.11.0 版本已经于 12 月 10 号正式发布。本次发布围绕 Eventing 事件源接入及事件可用性等相关功能展开。本文通过解读这些功能特性,让你快速对 v0.11.0 版本有所了解。
在 Istio 中提供了一个 Bookinfo 的示例,用于演示微服务之间的调用,那么如何在 Knative 中部署这个示例呢?本文将会介绍一下在 Knative 中部署 Bookinfo 微服务以及查看调用链追踪信息。
Knative Eventing v0.10.0 版本已经于 10 月 29 号正式发布。本次发布继续围绕完善 Eventing 中相关功能展开。本篇文章通过解读这些功能特性,让你快速对 v0.10.0 版本有所了解。
Knative 中如何指定域名和路径访问,在阿里云 Knative 中提供了这样的能力,用户可以通过控制台配置域名,并基于 Path 和 Header 进行转发规则设置,本文给你进行如下介绍。
在 Knative 中已经提供了对 Kafka 事件源的支持,那么如何在阿里云上基于 Kafka 实现消息推送,本文给大家解锁这一新的姿势。
提到天气预报服务,我们第一反应是很简单的一个服务,但实际做好天气预报服务其实并没有那么简单,本文通过 Knative Serverless 角度出发,给你介绍如何基于新一代 Serverless 技术玩转天气服务
Knative Eventing v0.9 版本已经于 9 月 18 号正式发布。本次发布 Eventing 中相关功能更新并不多。本篇文章带你简单了解这些功能新特性。
在 Knative 中部署的服务异常了怎么办?不要担心,本文教你在 Knative 中一步步排查问题。
在实际应用中,通过 APIGateway(即 API 网关),可以为内部服务提供保护,提供统一的鉴权管理,限流、监控等能力,开发人员只需要关注内部服务的业务逻辑即可。本文就会介绍一下如何通过阿里云 API 网关结合内网 SLB,将 Knative 服务对外发布,以打造生产级别的 Knative 服务。
从 Knative Eventing 0.8 开始,支持根据不同的过滤条件对事件进行选择处理。通过 Parallel 提供了这样的能力。本文就给大家介绍一下这个特性。
Knative Eventing v0.8 版本已经于 8 月 6 号正式发布。本次发布主要围绕完善 Eventing 中相关功能展开。本篇文章通过解读这些功能特性,希望能让你快速对 0.8 新版本有所了解。
在处理数据时,往往会涉及到一个数据需要进行多次加工,这时候我们一般是通过Pipeline的方式进行处理。那么在Knative Eventing中是否也能支持对一个事件进行分步骤多次处理? 这个还真有。从 0.7 版本开始,Knative Eventing中提供了一个 Sequence 资源模型,可用于事件Pipeline处理。
In-memory Channel是当前Knative Eventing中默认的Channel, 也是一般刚接触Knative Eventing首先了解到的Channel。本文通过分析 In-memory Channel 来进一步了解 Knative Eventing 中Broker/Trigger事件处理机制。
Knative Eventing 0.7 版本已经于 6 月 26 号正式发布。本次发布主要围绕重构 Channel 特性展开。本篇文章重点解读了这些特性,并且以此展望一下 Knative Eventing 后续版本的发展。
从本次 KubeCon 会议上 Serverless 及 Knative 的议题及观众来看,关于无服务器(Serverless) 标准的制定、实际场景的应用以及未来的发展正在引起更多的关注,而作为 CNCF 标准 Serverless 编排——Knative,也开始初露锋芒。
标准 Serverless 框架和人脸识别服务结合会产生怎样的火花?本文介绍如何通过 Knative 实现人脸识别服务,看看能否给你带来不一样的体验。
在 Knative Serving 中默认使用 `example.com` 作为默认域名,如果想使用自定义的域名该如何做呢?本文会介绍一下如何在 Knative Serving 中使用自定义域名。
Knative 主要由 Build、Serving 和 Eventing 三大核心组件构成。Knative 正是依靠这三个核心组件,驱动着 Knative 这艘 Serverless 巨轮前行。本文主要介绍这三个核心组件。
Knative Serving builds on Kubernetes and Istio to support deploying and serving of serverless applications and functions.
Event 事件无处不在,然而如果没有一套事件统一的定义标准,那么对于事件处理的开发者来说无疑是痛苦的。CloudEvent 的出现统一了事件的标准,本篇文章简要介绍了这一标准规范协议,以及实际场景中使用的方式。
在最新的 Knative Eventing 0.6 版本中新增了 Registry 特性, 为什么要增加这个特性, 该特性是如何实现的。针对这些问题,希望通过本篇文章给出答案。