解读 Knative v0.13.0版本特性

本文涉及的产品
容器镜像服务 ACR,镜像仓库100个 不限时长
简介: Knative Eventing v0.13.0 发布了,猜一下这个版本有没有惊喜特性,本文给你带来解读。

前言

针对 Knative Eventing v0.13.0 版本对这些新功能特性进行解读,让你快速对 v0.13.0 版本有所了解。

新特性

v1beta1 版本

从 v0.13.0 开始引入了 v1beta1 版本,包括如下资源: Broker, Trigger, Channel, Subscription, Sequence, Parallel, EventType, InMemoryChannel

支持通过configmap配置event dispatch 策略

之前通过event dispatch 转发事件时,默认超时时间是1分钟,并且是默认设置不能配置,显然在某些长时间请求的情况下1分钟不够。在v0.13.版本中,支持通过configmap配置相关的策略,包括超时时间,MaxIdleConns等

新增 PingSource 资源

其实是将原来的 CronJobSource 改名了,以与k8s 中的CronJob进行区分。

in-mem channel 事件分发作用范围

in-mem channel 支持通过 eventing.knative.dev/scope: namespace 注释来判断 In-memory dispatcher 是否部署在相同的命名空间中

HA支持

Knative 从0.13.0版本开始对核心的controller提供 HA 支持(包括Serving),Knative Eventing 中可以通过 config-leader-election configmap进行配置。

kind: ConfigMap
metadata:
  name: config-leader-election
  namespace: knative-eventing
  labels:
    eventing.knative.dev/release: "v0.13.0"
data:
  # An inactive but valid configuration follows; see example.
  resourceLock: "leases"
  leaseDuration: "15s"
  renewDeadline: "10s"
  retryPeriod: "2s"
  _example: |
    ################################
    #                              #
    #    EXAMPLE CONFIGURATION     #
    #                              #
    ################################

    # This block is not actually functional configuration,
    # but serves to illustrate the available configuration
    # options and document them in a way that is accessible
    # to users that `kubectl edit` this config map.
    #
    # These sample configuration options may be copied out of
    # this example block and unindented to be in the data block
    # to actually change the configuration.

    # resourceLock controls which API resource is used as the basis for the
    # leader election lock. Valid values are:
    #
    # - leases -> use the coordination API
    # - configmaps -> use configmaps
    # - endpoints -> use endpoints
    resourceLock: "leases"

    # leaseDuration is how long non-leaders will wait to try to acquire the
    # lock; 15 seconds is the value used by core kubernetes controllers.
    leaseDuration: "15s"
    # renewDeadline is how long a leader will try to renew the lease before
    # giving up; 10 seconds is the value used by core kubernetes controllers.
    renewDeadline: "10s"
    # retryPeriod is how long the leader election client waits between tries of
    # actions; 2 seconds is the value used by core kuberntes controllers.
    retryPeriod: "2s"
    # enabledComponents is a comma-delimited list of component names for which
    # leader election is enabled. Valid values are:
    #
    # - controller
    # - broker-controller
    # - inmemorychannel-dispatcher
    # - inmemorychannel-controller
    enabledComponents: "controller"

其它关键信息

  • 设置 Broker Filter/Ingress pods 默认 Prometheus Port: 9092
  • 在Broker中支持通过configmap 配置 Channel

总结

个人认为本次 Knative Eventing v0.13.0 版本最大的惊喜是支持了组件的 HA 部署,极大的提高了生产可用性。相信接下来社区会继续完善可用性方面的功能。欢迎对 Knative 有兴趣的一起交流。

欢迎加入 Knative 交流群

image

目录
相关文章
|
8月前
|
Kubernetes 容器
在Kubernetes(k8s)中部署Higress时,查看Wasm插件日志的方法如下
在Kubernetes(k8s)中部署Higress时,查看Wasm插件日志的方法如下
165 1
|
Kubernetes API 索引
k8s 1.28重磅发布,Sidecar Containers等45个特性来了!
k8s 1.28重磅发布,Sidecar Containers等45个特性来了!
663 1
|
运维 Kubernetes Cloud Native
OpenKruise V1.4 版本解读:新增 Job Sidecar Terminator 能力
OpenKruise V1.4 版本解读:新增 Job Sidecar Terminator 能力
|
Prometheus 监控 Cloud Native
Istio生态系统ON ASM(2):在阿里云服务网格ASM中集成Argo Rollouts进行金丝雀发布
背景ArgoCD职责主要是监听Git仓库中的应用编排的变化,并集群中应用真实运行状态进行对比,自动/手动去同步拉取应用编排的变更到部署集群中。Argo Rollouts提供了更强大的蓝绿、金丝雀部署能力。在实践中可以将两者结合来提供基于GitOps 的渐进式交付能力。前提条件创建Istio版本为1.12.4.50或更高版本的阿里云服务网格 (ASM) 企业版实例。
394 0
Istio生态系统ON ASM(2):在阿里云服务网格ASM中集成Argo Rollouts进行金丝雀发布
|
存储 缓存 Kubernetes
与 Kubernetes 共存:集群升级的4种方式
与 Kubernetes 共存:集群升级的4种方式
627 0
与 Kubernetes 共存:集群升级的4种方式
|
运维 Kubernetes 网络协议
Rainbond 5.5 发布,支持Istio和扩展第三方Service Mesh框架
Rainbond 5.5 版本主要优化扩展性。服务治理模式可以扩展第三方 ServiceMesh 架构,兼容kubernetes 管理命令和第三方管理平台。
Rainbond 5.5 发布,支持Istio和扩展第三方Service Mesh框架
|
存储 Kubernetes API
Kubernetes CRD多版本与升级机制
介绍 在K8s世界,CRD就像是api定义,CRD配套的Operator则是对应的api实现,在系统迭代过程中api会不断的发展,同样的,CRD也会不断的发展,v1alpha1 -> v1alpha2 -> v1beta1 -> v1 -> v2alpha2...,如何在K8s里面让用户轻易得地从低版本升级到高版本是一个十分通用的问题,而正好K8s CRD提供了引入并升
|
Kubernetes Serverless API
解读Knative 0.17.0版本特性
Knative 0.17.0 版本已于近期发布,对于 Knative v0.17.0 版本新特性,我们进行解读,让大家对 Knative 新版本快速了解。
2001 0
解读Knative 0.17.0版本特性
|
Kubernetes Serverless API
解读Knative 0.16.0版本特性
Knative 0.16.0 版本已于近期发布,针对 Knative v0.16.0 版本对这些新功能特性进行解读,让你快速对新版本特性有所深入了解。
1404 0
解读Knative 0.16.0版本特性