Knative Eventing 中 Channel 如何注入默认 Provisioner

场景

通常的在创建Broker时，我们需要通过 spec.ChannelTemplate 指定使用某个具体的 Channel Provisioner。例如这样的Broker:

apiVersion: eventing.knative.dev/v1alpha1
kind: Broker
metadata:name: pubsub-channel
spec:channelTemplate:provisioner:apiVersion: eventing.knative.dev/v1alpha1kind: ClusterChannelProvisionername: gcp-pubsub

这里通过spec.ChannelTemplate 指定了名称为gcp-pubsub的provisioner。那么我们也遇到过这样的Broker：

apiVersion: eventing.knative.dev/v1alpha1
kind: Broker
metadata:name: default

并没有指定使用某个具体的 channel, 但创建完Broker之后会发现已经创建出来了Channel:

apiVersion: eventing.knative.dev/v1alpha1
kind: Channel
metadata:...name: default-broker-8ml79namespace: defaultownerReferences:- apiVersion: eventing.knative.dev/v1alpha1blockOwnerDeletion: truecontroller: truekind: Brokername: defaultuid: 2e4c3332-6755-11e9-a81f-00163f005e02
spec:provisioner:apiVersion: eventing.knative.dev/v1alpha1kind: ClusterChannelProvisionername: in-memory
...

分析

我们知道 Broker创建之后，会通过 reconcile controller 会创建相应的Channel, 也就是下面这段代码：

// newChannel creates a new Channel for Broker 'b'.
func newChannel(b *v1alpha1.Broker, l map[string]string) *v1alpha1.Channel {var spec v1alpha1.ChannelSpecif b.Spec.ChannelTemplate != nil {spec = *b.Spec.ChannelTemplate}return &v1alpha1.Channel{ObjectMeta: metav1.ObjectMeta{Namespace:    b.Namespace,GenerateName: fmt.Sprintf("%s-broker-", b.Name),Labels:       l,OwnerReferences: []metav1.OwnerReference{*metav1.NewControllerRef(b, schema.GroupVersionKind{Group:   v1alpha1.SchemeGroupVersion.Group,Version: v1alpha1.SchemeGroupVersion.Version,Kind:    "Broker",}),},},Spec: spec,}
}

分析上面这段代码，我们可以很清楚得出这样的结论：如果Broker中设置了Spec.ChannelTemplate, 那么Channel中会直接使用ChannelTemplate所对应的provisioner。
但如果没有设置的话，那么Channel中的spec应该设置为nil。但事实上设置了in-memory provisioner，那么这个是在哪里注入的呢？

注入机制

经过定位源代码，我们发现在channel_defaults.go中，发现下面这段代码：

func (c *Channel) SetDefaults(ctx context.Context) {if c != nil && c.Spec.Provisioner == nil {// The singleton may not have been set, if so ignore it and validation will reject the// Channel.if cd := ChannelDefaulterSingleton; cd != nil {prov, args := cd.GetDefault(c.DeepCopy())c.Spec.Provisioner = provc.Spec.Arguments = args}}c.Spec.SetDefaults(ctx)
}

分析一下，我们可以看到当c.Spec.Provisioner==nil时，会设置默认的Provisioner。
进一步分析ChannelDefaulterSingleton, 我们可以在webhook中赋予了实现设置：

...
// Watch the default-channel-webhook ConfigMap and dynamically update the default
// ClusterChannelProvisioner.
channelDefaulter := channeldefaulter.New(logger.Desugar())
eventingv1alpha1.ChannelDefaulterSingleton = channelDefaulter
configMapWatcher.Watch(channeldefaulter.ConfigMapName, channelDefaulter.UpdateConfigMap)
...

接着分析发现 ChannelDefaulter 实现了 GetDefault 方法：

// GetDefault determines the default provisioner and arguments for the provided channel.
func (cd *ChannelDefaulter) GetDefault(c *eventingv1alpha1.Channel) (*corev1.ObjectReference, *runtime.RawExtension) {// Because we are treating this as a singleton, be tolerant to it having not been setup at all.if cd == nil {return nil, nil}if c == nil {return nil, nil}config := cd.getConfig()if config == nil {return nil, nil}// TODO Don't use a single default, instead use the Channel's arguments to determine the type of// Channel to use (e.g. it can say whether it needs to be persistent, strictly ordered, etc.).dp := getDefaultProvisioner(config, c.Namespace)cd.logger.Info("Defaulting the ClusterChannelProvisioner", zap.Any("defaultClusterChannelProvisioner", dp))return dp, nil
}

并且这里是通过一个ConfigMap设置使用的默认provisioner, 这个ConfigMap名称为default-channel-webhook, 没错可以在 Knative Eventing 安装文件中发现这个资源：

apiVersion: v1
data:default-channel-config: |clusterdefault:apiversion: eventing.knative.dev/v1alpha1kind: ClusterChannelProvisionername: in-memorynamespacedefaults:some-namespace:apiversion: eventing.knative.dev/v1alpha1kind: ClusterChannelProvisionername: some-other-provisioner
kind: ConfigMap
metadata:name: default-channel-webhooknamespace: knative-eventing

那么分析到此，我们梳理一下整个注入的流程：

结论

通过上面的分析，我们现在了解了默认provisioner的注入机制，同时我们也可以通过 webhook 修改默认的provisioner。

原文链接
本文为云栖社区原创内容，未经允许不得转载。

Knative Eventing 中 Channel 如何注入默认 Provisioner相关推荐

透过 In-memory Channel 看 Knative Eventing 中 Broker/Trigger 工作机制
In-memory Channel是当前Knative Eventing中默认的Channel, 也是一般刚接触Knative Eventing首先了解到的Channel.本文通过分析 In-memo ...
Knative Eventing 中如何实现 Registry 事件注册机制
背景作为事件消费者,之前是无法事先知道哪些事件可以被消费,如果能通过某种方式获得哪些 Broker 提供哪些事件,那么事件消费者就能很方便通过这些 Broker 消费事件.Registry 就是在这 ...
OpenShift 4 - Knative教程 (6) Eventing之Channel和Subscription
<OpenShift 4.x HOL教程汇总> 说明:本文已经在OpenShift 4.10环境中验证文章目录概念操作参考概念 Knative Eventing中的Channel ...
Knative 基本功能深入剖析：Knative Eventing 之 Sequence 介绍
作者 | 元毅,阿里云容器平台高级开发工程师,负责阿里云容器平台 Knative 相关工作. 导读:在实际的开发中我们经常会遇到将一条数据需要经过多次处理的场景,称为 Pipeline.那么在 Kna ...
Knative Eventing 之 Sequence 介绍
在处理数据时,往往会涉及到一个数据需要进行多次加工,这时候我们一般是通过Pipeline的方式进行处理.那么在Knative Eventing中是否也能支持对一个事件进行分步骤多次处理? 这个还真有. ...
o oia ospf 路由优先_动态路由OSPF中注入默认路由，原来都是这么玩的，进去看看...
一 .OSPF网络注入默认路由二. 实战步骤 1.本实验用 R1 的环回接口 1 来模拟 Internet. (1)步骤 1:配置路由器 R1 R1(config)# interface loopb ...
深入解读 Knative Eventing 0.7 版本新特性
前言 Knative Eventing 0.7 版本已经于 6 月 26 号正式发布.本次发布主要围绕重构 Channel 特性展开.本篇文章重点解读了这些特性,并且以此展望一下 Knative Ev ...
全面剖析 Knative Eventing 0.6 版本新特性
前言 Knative Eventing 0.6 版本已经于5月15号正式发布.相比于0.5版本,此次发布包含了一些重要特性及更新.针对这些新特性以及更新,我们如何快速.精准的定位主要技术点.本篇文章针 ...
解读 Knative Eventing v0.10.0 最新版本特性
前言 Knative Eventing v0.10.0 版本已经于 10 月 29 号正式发布.本次发布继续围绕完善 Eventing 中相关功能展开.本篇文章通过解读这些功能特性,让你快速对 v0. ...

Knative Eventing 中 Channel 如何注入默认 Provisioner

场景

分析

注入机制

结论

Knative Eventing 中 Channel 如何注入默认 Provisioner相关推荐

最新文章

热门文章