Knative 架构解析

本文涉及的产品
函数计算FC,每月15万CU 3个月
简介: 【2月更文挑战第29天】Knative作为构建无服务器产品的基础设施,建立在Kubernetes和Istio之上,提供从源代码到服务的编排、流量管理、自动扩缩容和事件绑定等功能,分为Build、Eventing和Serving三个模块,旨在确保编程模型的可移植性。

CNCF针对无服务器计算的定义为:无服务器计算是指一种构建和运行不需要服务器管理的应用程序的理念。它描述了一个更细粒度的部署模型,即将以一个或多个功能方式提供的应用程序上载到平台,然后执行、扩缩容及计费,以响应当前所需的确切要求。

一个理想的无服务器平台至少需要以下几个方面:

  • 构建和运行应用程序,需要一个用来构建和运行应用程序的平台。是的,Kubernetes就是当前最为合适的新应用程序服务器。
  • 没有服务器管理,不需要专用的应用程序服务器管理。在Kubernetes之上,所有应用程序都通过Kubernetes Deployment和Service进行容器化和部署。
  • 根据确切的需求执行、扩缩容及计费,根据业务的需求配置以及扩容缩容的比率,Kubernetes提供了自动扩容与缩容能力,并可以根据使用量计费。


毫无疑问,Kubernetes目前无法为无服务器平台提供所有的功能。在Kubernetes基础之上,无服务器技术栈需要以下原语能力的补充:

  • Build:需要一种“源代码到容器”的机制,来简化部署。
  • Routing:灵活简便的路由能力;支持各种灰度发布的能力。
  • Event Building:可插拔的事件源接入能力。
  • Auto Scaling:灵活的自动扩缩容能力,支持自动收缩,从0个到1个实例,从1个到N个实例,再回到0个实例。
  • Observability:提供可观察性能力,具备完善的跟踪、监控和日志记录能力。
  • Invocation:可插拔的调用器,让开发人员可以使用简单、符合已有语言习惯的交付代码逻辑。再往上,就是无服务器不同产品的能力,它可以复用Kubernetes的基础能力和上述无服务器原语能力,而不需要去重复发明轮子,同时也保证了可移植性。


Knative是构建多种无服务器产品的基础设施,并且会确保它们之间编程模型的可移植性。Knative是建立在Kubernetes和Istio平台之上的,使用Kubernetes提供的容器管理能力(Deployment、Service和pod等),以及Istio提供的网络管理功能(VirtualService、DestinationRule和IngressGateway等)。


Knative项目下的每个组件都尝试使用一些常见的模式,并提供一套业界验证过的基于Kubernetes的最佳实践。Knative组件专注于解决许多烦琐但有挑战的一些任务,例如:如何快速部署弹性容器,以及如下操作:

  • 在Kubernetes上如何实现从源代码到服务URL的编排流程。
  • 使用蓝/绿部署实现流量的路由和管理。
  • 根据需求自动扩缩容以及调整工作负载大小。
  • 将运行服务绑定到事件生态系统中。


Knative的开发人员可以使用熟悉的习语、语言和框架来部署任何工作负载,例如函数功能(Function)、应用程序(Application)或容器(Container)。Knative负责构建、部署和运行无服务器化的工作负载,包含三个模块:Build、Eventing、Serving。

这三个模块的功能和分工具体描述如下:

  • Build模块负责将源代码构建成容器,它基于Google的容器构建服务,提供了一个可插拔的构建模型,可扩展实现多种构建方法,Buildpacks就是Pivotal提供的一种构建容器模式。
  • Eventing模块实现函数发布和订阅事件流的能力,函数遵循CloudEvents规范来发送和接收事件,它也提供了可插拔的事件源和消息代理模型,轻松支持多种消息代理服务,如Kafka、Google Pub/Sub、RabbitMQ等。
  • Serving模块负责部署和运行无服务器化的函数负载,它支持的特性包括:函数的运行可由HTTP或Message请求驱动、弹性伸缩可至零,并可利用Istio实现集群内的路由分发以及进入集群的入口连接。


未来,通过Knative可以完成跨云单一平台的理想,任何支持Kubernetes地方,企业都可以在其间自由移动工作负载,选择在最适合的地方执行任务,这为企业提供了极大的控制灵活性,可以依照需求调整系统部署。

相关文章
|
17天前
|
运维 负载均衡 微服务
|
2月前
|
人工智能 JavaScript 前端开发
LangGraph架构解析
本文深入解析了传统Agent开发的三大痛点:状态管理碎片化、流程控制复杂及扩展性差,提出使用LangGraph通过有向图模型重构工作流,将LLM调用与工具执行抽象为节点,实现动态流程跳转。文中详述LangGraph四大核心组件——状态机引擎、节点设计、条件边与工具层集成,并结合生产环境最佳实践,如可视化调试、状态持久化与人工干预机制,最终对比LangGraph与传统方案的性能差异,给出选型建议。
264 0
|
6天前
|
机器学习/深度学习 人工智能 搜索推荐
从零构建短视频推荐系统:双塔算法架构解析与代码实现
短视频推荐看似“读心”,实则依赖双塔推荐系统:用户塔与物品塔分别将行为与内容编码为向量,通过相似度匹配实现精准推送。本文解析其架构原理、技术实现与工程挑战,揭秘抖音等平台如何用AI抓住你的注意力。
126 6
从零构建短视频推荐系统:双塔算法架构解析与代码实现
|
8天前
|
存储 监控 NoSQL
Redis高可用架构全解析:从主从复制到集群方案
Redis高可用确保服务持续稳定,避免单点故障导致数据丢失或业务中断。通过主从复制实现数据冗余,哨兵模式支持自动故障转移,Cluster集群则提供分布式数据分片与水平扩展,三者层层递进,保障读写分离、容灾切换与大规模数据存储,构建高性能、高可靠的Redis架构体系。
|
17天前
|
Java 数据库 数据安全/隐私保护
Spring Boot四层架构深度解析
本文详解Spring Boot四层架构(Controller-Service-DAO-Database)的核心思想与实战应用,涵盖职责划分、代码结构、依赖注入、事务管理及常见问题解决方案,助力构建高内聚、低耦合的企业级应用。
292 0
|
24天前
|
机器学习/深度学习 负载均衡 网络架构
Mixture of Experts架构的简要解析
Mixture of Experts(MoE)架构起源于1991年,其核心思想是通过多个专门化的“专家”网络处理输入的不同部分,并由门控网络动态组合输出。这种架构实现了稀疏激活,仅激活部分专家,从而在模型规模与计算成本之间取得平衡。MoE的关键在于门控机制的设计,如线性门控、噪声Top-K门控等,确保模型能根据输入特征自适应选择专家。
151 8
|
23天前
|
JSON 供应链 监控
1688商品详情API技术深度解析:从接口架构到数据融合实战
1688商品详情API(item_get接口)可通过商品ID获取标题、价格、库存、SKU等核心数据,适用于价格监控、供应链管理等场景。支持JSON格式返回,需企业认证。Python示例展示如何调用接口获取商品信息。
|
24天前
|
机器学习/深度学习 存储 资源调度
Transformer架构的简要解析
Transformer架构自2017年提出以来,彻底革新了人工智能领域,广泛应用于自然语言处理、语音识别等任务。其核心创新在于自注意力机制,通过计算序列中任意两个位置的相关性,打破了传统循环神经网络的序列依赖限制,实现了高效并行化与长距离依赖建模。该架构由编码器和解码器组成,结合多头注意力、位置编码、前馈网络等模块,大幅提升了模型表达能力与训练效率。从BERT到GPT系列,几乎所有现代大语言模型均基于Transformer构建,成为深度学习时代的关键技术突破之一。
239 7
|
2月前
|
消息中间件 缓存 Java
医院信息系统(HIS)的开发架构解析,代码示例
医院信息系统(HIS)是现代医院的核心,其架构设计直接影响系统稳定性、扩展性与用户体验。本文解析HIS架构演进历程,从单机、C/S、B/S到微服务与云原生架构,结合代码示例,深入讲解现代HIS系统的分层架构、核心模块与关键技术实践。
357 1

热门文章

最新文章

推荐镜像

更多
  • DNS