您好,登錄后才能下訂單哦!
這期內容當中小編將會給大家帶來有關Knative Eventing中Channel怎么注入默認 Provisioner,文章內容豐富且以專業的角度為大家分析和敘述,閱讀完這篇文章希望大家可以有所收獲。
在 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。
上述就是小編為大家分享的Knative Eventing中Channel怎么注入默認 Provisioner了,如果剛好有類似的疑惑,不妨參照上述分析進行理解。如果想知道更多相關知識,歡迎關注億速云行業資訊頻道。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。