Knative v0.16.0更新

I finally got around to updating my Knative Tutorial from Knative v0.14.0 to the latest Knative v0.16.0 release. Since I skipped v0.15.0, I'm not sure which changes are due to v0.15.0 vs. v0.16.0. Regardless, there have been some notable changes that I want to outline in this blog post. This is not meant to be an exhaustive list. Feel free to let me know in the comments if there are other notable changes that I should be aware of.

我终于将Knative教程从Knative v0.14.0更新到了最新的Knative v0.16.0 版本 。 由于我跳过了v0.15.0 ，所以我不确定哪些更改是由于v0.15.0与v0.16.0 。 无论如何，在本博客中，我想概述一些显着的变化。 这并不是详尽的清单。 如果还有其他值得注意的变化，请随时在评论中让我知道。

糖控制器 (Sugar Controller)

Once I updated to v0.16.0, I realized the Broker injection into the default namespace did not work. Turns out, there's a new Sugar Controller you need to install to have Broker injection. Installing Knative page has more details and my setup scripts have been updated to install this controller. This is how you install it:

更新到v0.16.0 ，我意识到将Broker注入默认名称空间不起作用。 原来，您需要安装一个新的Sugar Controller才能进行Broker注入。 “安装Knative”页面具有更多详细信息，并且我的安装脚本已更新以安装此控制器。 这是您的安装方式：

kubectl apply -f \ https://github.com/knative/eventing/releases/download/v0.16.0/eventing-sugar-controller.yaml

This allows you to:

这使您可以：

1. When a Namespace is labeled with eventing.knative.dev/injection=enabled, the controller will create a defaultBroker in that namespace.

   当命名空间带有eventing.knative.dev/injection=enabled标记时，控制器将在该命名空间中创建一个默认Broker 。

2. When a Trigger is annotated witheventing.knative.dev/injection=enabled, the controller will create aBroker named by that Trigger in theTrigger's namespace.

   当使用eventing.knative.dev/injection=enabled注释触发器时，控制器将在Trigger的命名空间中创建由该Trigger命名的Broker 。

代理注入的命名空间标签 (Namespace label for Broker injection)

If you were careful, you already realized that the namespace label for Broker injection used to be:

如果您小心点，您已经意识到用于Broker注入的名称空间标签曾经是：

knative-eventing-injection

Now, it changed to:

现在，它更改为：

eventing.knative.dev/injection

You have to label your namespace as follows now for Broker injection into that namespace (default in this case):

您现在必须按照以下方式标记名称空间，以便将Broker注入该名称空间(在这种情况下为default )：

kubectl label ns default eventing.knative.dev/injection=enabled

默认经纪人网址 (Default Broker URL)

Once the Broker is up and running, you'll also realize that the default Broker URL also changed. If the Broker is injected into the default namespace, the URL used to be this:

Broker启动并运行后，您还将意识到默认的Broker URL也已更改。 如果将Broker注入default名称空间，则URL以前是这样的：

http://default-broker.default.svc.cluster.local

Now, the new URL is:

现在，新的URL为：

http://broker-ingress.knative-eventing.svc.cluster.local/default/default

It’s good to remember if you need to send messages to the Broker.

记住如果您需要将消息发送给Broker那是一件好事。

Knative-GCP API版本 (Knative-GCP API version)

As you might know, Knative-GCP project is useful to read Google Cloud events into Knative cluster. It also has a v0.16.0 release. With that, you can now move from v1alpha1 to v1beta1 API. This affects when you define a source, for example CloudStorageSource. You can use the newer API:

如您所知， Knative-GCP项目对于将Google Cloud事件读入Knative集群很有用。 它还具有v0.16.0 版本 。 这样，您现在可以从v1alpha1到v1beta1 API。 这会影响您定义源(例如CloudStorageSource 。 您可以使用较新的API：

apiVersion: events.cloud.google.com/v1beta1
kind: CloudStorageSource
...

Google CloudEvents (Google CloudEvents)

Another notable change in v0.16.0 is that Knative-GCP now uses new CloudEvent attributes and data schemas and all sources now emit these CloudEvents. You can see the list of CloudEvents in google-cloudevents repository.

v0.16.0另一个显着变化是Knative-GCP现在使用新的CloudEvent属性和数据模式，并且所有源现在都发出这些CloudEvent。 您可以在google-cloudevents存储库中查看CloudEvents列表。

As an example, if you wanted to listen for file updates in a storage bucket in Cloud Storage, you’d create a trigger with com.google.cloud.storage.object.finalize filter:

例如，如果您想在Cloud Storage的存储桶中监听文件更新，则可以使用com.google.cloud.storage.object.finalize过滤器创建触发器：

apiVersion: eventing.knative.dev/v1beta1
kind: Trigger
metadata:
  name: trigger
spec:
  filter:
    attributes:
      type: com.google.cloud.storage.object.finalize

Now, you need to use the new CloudEvents listed in google-cloudevents. The same trigger needs to filter on google.cloud.storage.object.v1.finalized instead:

现在，您需要使用google-cloudevents中列出的新CloudEvents 。 相同的触发器需要在google.cloud.storage.object.v1.finalized上进行过滤：

apiVersion: eventing.knative.dev/v1beta1
kind: Trigger
metadata:
  name: trigger
spec:
  filter:
    attributes:
      type: google.cloud.storage.object.v1.finalized

CloudSchedulerSource更改 (CloudSchedulerSource changes)

Last but not least, I’ve realized that the CloudSchedulerSource events changed slightly. For example, take a look at the following CloudSchedulerSource:

最后但并非最不重要的一点是，我已经意识到CloudSchedulerSource事件发生了轻微的变化。 例如，看看下面的CloudSchedulerSource ：

apiVersion: events.cloud.google.com/v1beta1
kind: CloudSchedulerSource
metadata:
  name: schedulersource-cy
spec:
  location: "europe-west1"
  data: "Cyprus"
  schedule: "0 17 * * *"
  sink:
    ref:
      apiVersion: eventing.knative.dev/v1beta1
      kind: Broker
      name: default

In the past, you’d get a CloudEvents with Cyprus in its Data field. In v0.16.0, you'd get a Data field with the value {"custom_data":"Q3lwcnVz"}. This is basically Cyprus Base64 encoded and saved under custom_data. You need to take this into account as you're parsing the CloudEvent in your code.

过去，您会在“ Data字段中获得Cyprus的CloudEvents。 在v0.16.0 ，您将获得一个值为{"custom_data":"Q3lwcnVz"}的Data字段。 这基本上是Cyprus Base64编码并保存在custom_data下。 在代码中解析CloudEvent时，需要考虑到这一点。

These are the changes to look out for in v0.16.0. Did I miss anything? If so, let me know in the comments or reach out to me on Twitter (@meteatamel).

这些是v0.16.0需要注意的更改。 我想念什么吗？ 如果是这样，请在评论中让我知道，或在Twitter( @meteatamel )上与我联系 。

Originally published at https://atamel.dev.

最初发布于 https://atamel.dev 。

翻译自: https://medium.com/google-cloud/knative-v0-16-0-update-5a5690e5354c