場(chǎng)景

通常的在創(chuàng)建Broker時(shí)，我們需要通過(guò)?spec.ChannelTemplate?指定使用某個(gè)具體的 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

這里通過(guò)spec.ChannelTemplate?指定了名稱(chēng)為gcp-pubsub的provisioner。那么我們也遇到過(guò)這樣的Broker：

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

并沒(méi)有指定使用某個(gè)具體的 channel, 但創(chuàng)建完Broker之后會(huì)發(fā)現(xiàn)已經(jīng)創(chuàng)建出來(lái)了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創(chuàng)建之后，會(huì)通過(guò) reconcile controller 會(huì)創(chuàng)建相應(yīng)的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,} }

分析上面這段代碼，我們可以很清楚得出這樣的結(jié)論：如果Broker中設(shè)置了Spec.ChannelTemplate, 那么Channel中會(huì)直接使用ChannelTemplate所對(duì)應(yīng)的provisioner。
但如果沒(méi)有設(shè)置的話(huà)， 那么Channel中的spec應(yīng)該設(shè)置為nil。但事實(shí)上設(shè)置了in-memory provisioner， 那么這個(gè)是在哪里注入的呢？

注入機(jī)制

經(jīng)過(guò)定位源代碼，我們發(fā)現(xiàn)在channel_defaults.go中，發(fā)現(xiàn)下面這段代碼：

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) }

分析一下，我們可以看到當(dāng)c.Spec.Provisioner==nil時(shí)， 會(huì)設(shè)置默認(rèn)的Provisioner。
進(jìn)一步分析ChannelDefaulterSingleton, 我們可以在webhook中賦予了實(shí)現(xiàn)設(shè)置：

... // 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) ...

接著分析發(fā)現(xiàn) ChannelDefaulter 實(shí)現(xiàn)了 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 }

并且這里是通過(guò)一個(gè)ConfigMap設(shè)置使用的默認(rèn)provisioner, 這個(gè)ConfigMap名稱(chēng)為default-channel-webhook, 沒(méi)錯(cuò)可以在 Knative Eventing 安裝文件中發(fā)現(xiàn)這個(gè)資源：

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

那么分析到此，我們梳理一下整個(gè)注入的流程：

結(jié)論

通過(guò)上面的分析， 我們現(xiàn)在了解了默認(rèn)provisioner的注入機(jī)制， 同時(shí)我們也可以通過(guò) webhook 修改默認(rèn)的provisioner。

原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的Knative Eventing 中 Channel 如何注入默认 Provisioner的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。