摘要: 在 Knative Eventing 中创建 Broker 时,如果不指定 provisioner, 系统会自动创建默认的 provisioner, 那么这个机制是如何实现的呢? 本文基于 Knative Eventing 0.5 版本,介绍了这个实现机制。

场景

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

apiVersion: eventing.knative.dev/v1alpha1kind: Brokermetadata:  name: pubsub-channelspec:  channelTemplate:    provisioner:      apiVersion: eventing.knative.dev/v1alpha1      kind: ClusterChannelProvisioner      name: gcp-pubsub

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

apiVersion: eventing.knative.dev/v1alpha1kind: Brokermetadata:  name: default

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

apiVersion: eventing.knative.dev/v1alpha1kind: Channelmetadata:  ...  name: default-broker-8ml79  namespace: default  ownerReferences:  - apiVersion: eventing.knative.dev/v1alpha1    blockOwnerDeletion: true    controller: true    kind: Broker    name: default    uid: 2e4c3332-6755-11e9-a81f-00163f005e02spec:  provisioner:    apiVersion: eventing.knative.dev/v1alpha1    kind: ClusterChannelProvisioner    name: 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.ChannelSpec    if 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 = prov            c.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 = channelDefaulterconfigMapWatcher.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: v1data:  default-channel-config: |    clusterdefault:      apiversion: eventing.knative.dev/v1alpha1      kind: ClusterChannelProvisioner      name: in-memory    namespacedefaults:      some-namespace:        apiversion: eventing.knative.dev/v1alpha1        kind: ClusterChannelProvisioner        name: some-other-provisionerkind: ConfigMapmetadata:  name: default-channel-webhook  namespace: knative-eventing

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

结论

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



本文作者:元毅

阅读原文

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