摘要： 在 Knative Eventing 中创建 Broker 时，如果不指定 provisioner， 系统会自动创建默认的 provisioner， 那么这个机制是如何实现的呢？ 本文基于 Knative Eventing 0.5 版本，介绍了这个实现机制。
场景
通常的在创建Broker时，我们需要通过 spec.ChannelTemplate 指定使用某个具体的 Channel Provisioner。例如这样的Broker:
apiVersion: eventing.knative.dev/v1alpha1
kind: Broker
metadata:
name: pubsub-channel
spec:
channelTemplate:
provisioner:
apiVersion: eventing.knative.dev/v1alpha1
kind: ClusterChannelProvisioner
name: 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-8ml79
namespace: default
ownerReferences:
- apiVersion: eventing.knative.dev/v1alpha1
blockOwnerDeletion: true
controller: true
kind: Broker
name: default
uid: 2e4c3332-6755-11e9-a81f-00163f005e02
spec:
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 = 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/v1alpha1
kind: ClusterChannelProvisioner
name: in-memory
namespacedefaults:
some-namespace:
apiversion: eventing.knative.dev/v1alpha1
kind: ClusterChannelProvisioner
name: some-other-provisioner
kind: ConfigMap
metadata:
name: default-channel-webhook
namespace: knative-eventing那么分析到此，我们梳理一下整个注入的流程：
结论
通过上面的分析， 我们现在了解了默认provisioner的注入机制， 同时我们也可以通过 webhook 修改默认的provisioner。
本文作者：元毅
阅读原文
本文为云栖社区原创内容，未经允许不得转载。