Skip to content

管理员配置选项

如果您对 Knative 安装具有集群管理员权限，则可以修改 ConfigMaps 以更改集群上代理的全局默认配置选项。

Knative 事件提供了一个config-br-defaults ConfigMap，其中包含管理默认代理创建的配置设置。

默认的config-br-defaults ConfigMap 如下:

apiVersion: v1
kind: ConfigMap
metadata:
  name: config-br-defaults
  namespace: knative-eventing
  labels:
    eventing.knative.dev/release: devel
data:
  # Configures the default for any Broker that does not specify a spec.config or Broker class.
  default-br-config: |
    clusterDefault:
      brokerClass: MTChannelBasedBroker
      apiVersion: v1
      kind: ConfigMap
      name: config-br-default-channel
      namespace: knative-eventing

通道实现选项

下面的示例显示了一个代理对象，其中spec.config配置在config-br-default-channel ConfigMap 中指定:

apiVersion: eventing.knative.dev/v1
kind: Broker
metadata:
  annotations:
    eventing.knative.dev/broker.class: MTChannelBasedBroker
  name: default
spec:
  # Configuration specific to this broker.
  config:
    apiVersion: v1
    kind: ConfigMap
    name: config-br-default-channel
    namespace: knative-eventing

A Broker object that does not have a spec.config specified uses the config-br-default-channel ConfigMap dy default because this is specified in the config-br-defaults ConfigMap.

However, if you have installed a different Channel implementation, for example, Kafka, and would like this to be used as the default Channel implementation for any Broker that is created, you can change the config-br-defaults ConfigMap to look as follows:

apiVersion: v1
kind: ConfigMap
metadata:
  name: config-br-defaults
  namespace: knative-eventing
  labels:
    eventing.knative.dev/release: devel
data:
  # Configures the default for any Broker that does not specify a spec.config or Broker class.
  default-br-config: |
    clusterDefault:
      brokerClass: MTChannelBasedBroker
      apiVersion: v1
      kind: ConfigMap
      name: kafka-channel
      namespace: knative-eventing

Now every Broker created in the cluster that does not have a spec.config will be configured to use the kafka-channel ConfigMap.

For more information about creating a kafka-channel ConfigMap to use with your Broker, see the Kafka Channel ConfigMap documentation.

更改名称空间的默认通道实现

You can modify the default Broker creation behavior for one or more namespaces.

For example, if you wanted to use the kafka-channel ConfigMap for all other Brokers created, but wanted to use config-br-default-channel ConfigMap for namespace-1 and namespace-2, you would use the following ConfigMap settings:

apiVersion: v1
kind: ConfigMap
metadata:
  name: config-br-defaults
  namespace: knative-eventing
  labels:
    eventing.knative.dev/release: devel
data:
  # Configures the default for any Broker that does not specify a spec.config or Broker class.
  default-br-config: |
    clusterDefault:
      brokerClass: MTChannelBasedBroker
      apiVersion: v1
      kind: ConfigMap
      name: config-kafka-channel
      namespace: knative-eventing
    namespaceDefaults:
      namespace-1:
        apiVersion: v1
        kind: ConfigMap
        name: config-br-default-channel
        namespace: knative-eventing
      namespace-2:
        apiVersion: v1
        kind: ConfigMap
        name: config-br-default-channel
        namespace: knative-eventing

配置交付规范默认值

You can configure default event delivery parameters for Brokers that are applied in cases where an event fails to be delivered:

apiVersion: v1
kind: ConfigMap
metadata:
  name: config-br-defaults
  namespace: knative-eventing
  labels:
    eventing.knative.dev/release: devel
data:
  # Configures the default for any Broker that does not specify a spec.config or Broker class.
  default-br-config: |
    clusterDefault:
      brokerClass: MTChannelBasedBroker
      apiVersion: v1
      kind: ConfigMap
      name: config-kafka-channel
      namespace: knative-eventing
      delivery:
        retry: 10
        backoffDelay: PT0.2S
        backoffPolicy: exponential
    namespaceDefaults:
      namespace-1:
        apiVersion: v1
        kind: ConfigMap
        name: config-br-default-channel
        namespace: knative-eventing
        delivery:
          deadLetterSink:
            ref:
              kind: Service
              namespace: example-namespace
              name: example-service
              apiVersion: v1
            uri: example-uri
          retry: 10
          backoffPolicy: exponential
          backoffDelay: "PT0.2S"

死信槽

You can configure the deadLetterSink delivery parameter so that if an event fails to be delivered it is sent to the specified event sink.

重试

You can set a minimum number of times that the delivery must be retried before the event is sent to the dead letter sink, by configuring the retry delivery parameter with an integer value.

后退延迟

You can set the backoffDelay delivery parameter to specify the time delay before an event delivery retry is attempted after a failure. The duration of the backoffDelay parameter is specified using the ISO 8601 format.

退出政策

The backoffPolicy delivery parameter can be used to specify the retry back off policy. The policy can be specified as either linear or exponential. When using the linear back off policy, the back off delay is the time interval specified between retries. When using the exponential backoff policy, the back off delay is equal to backoffDelay*2^<numberOfRetries>.

代理类选项

When a Broker is created without a specified BrokerClass annotation, the default MTChannelBasedBroker Broker class is used, as specified in the config-br-defaults ConfigMap.

The following example creates a Broker called default in the default namespace, and uses MTChannelBasedBroker as the implementation:

  1. Create a YAML file for your Broker using the following example:

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

  2. Apply the YAML file by running the command:

    kubectl apply -f <filename>.yaml

    Where <filename> is the name of the file you created in the previous step.

配置代理类

To configure a Broker class, you can modify the eventing.knative.dev/broker.class annotation and spec.config for the Broker object. MTChannelBasedBroker is the Broker class default.

  1. Modify the eventing.knative.dev/broker.class annotation. Replace MTChannelBasedBroker with the class type you want to use:

    ```yaml
apiVersion: eventing.knative.dev/v1
kind: Broker
metadata:
  annotations:
    eventing.knative.dev/broker.class: MTChannelBasedBroker
  name: default
  namespace: default
```

  2. Configure the spec.config with the details of the ConfigMap that defines the backing Channel for the Broker class:

    ```yaml
apiVersion: eventing.knative.dev/v1
kind: Broker
metadata:
  annotations:
    eventing.knative.dev/broker.class: MTChannelBasedBroker
  name: default
  namespace: default
spec:
  config:
    apiVersion: v1
    kind: ConfigMap
    name: config-br-default-channel
    namespace: knative-eventing
```

为集群配置默认的 BrokerClass

You can configure the clusterDefault Broker class so that any Broker created in the cluster that does not have a BrokerClass annotation uses this default class.

Example

apiVersion: v1
kind: ConfigMap
metadata:
  name: config-br-defaults
  namespace: knative-eventing
  labels:
    eventing.knative.dev/release: devel
data:
  # Configures the default for any Broker that does not specify a spec.config or Broker class.
  default-br-config: |
    clusterDefault:
      brokerClass: MTChannelBasedBroker

为名称空间配置默认的 BrokerClass

You can modify the default Broker class for one or more namespaces.

For example, if you want to use a KafkaBroker class for all other Brokers created on the cluster, but you want to use the MTChannelBasedBroker class for Brokers created in namespace-1 and namespace-2, you would use the following ConfigMap settings:

apiVersion: v1
kind: ConfigMap
metadata:
  name: config-br-defaults
  namespace: knative-eventing
  labels:
    eventing.knative.dev/release: devel
data:
  # Configures the default for any Broker that does not specify a spec.config or Broker class.
  default-br-config: |
    clusterDefault:
      brokerClass: KafkaBroker
    namespaceDefaults:
      namespace1:
        brokerClass: MTChannelBasedBroker
      namespace2:
        brokerClass: MTChannelBasedBroker

将 Istio 与 Knative 代理集成

通过使用 JSON Web Token (JWT)和 Istio 来保护 Knative 代理

先决条件

  • You have installed Knative Eventing.
  • You have installed Istio.

过程

  1. Label the knative-eventing namespace, so that Istio can handle JWT-based user authentication, by running the command:
kubectl label namespace knative-eventing istio-injection=enabled
  1. Restart the broker ingress pod, so that the istio-proxy container can be injected as a sidecar, by running the command:
kubectl delete pod <broker-ingress-pod-name> -n knative-eventing

Where <broker-ingress-pod-name> is the name of your broker ingress pod.

The pod now has two containers:

knative-eventing     <broker-ingress-pod-name>           2/2     Running   1              175m
  1. Create a broker, then use get the URL of your broker by running the command:
kubectl get broker <broker-name>

Example output:

NAMESPACE   NAME        URL                                                                          AGE   READY   REASON
default     my-broker   http://broker-ingress.knative-eventing.svc.cluster.local/default/my-broker   6s    True
  1. Start a curl pod:
kubectl -n default run curl --image=radial/busyboxplus:curl -i --tty
  1. Send a CloudEvent with an HTTP POST against the broker URL:
curl -X POST -v \
-H "content-type: application/json"  \
-H "ce-specversion: 1.0"  \
-H "ce-source: my/curl/command"  \
-H "ce-type: my.demo.event"  \
-H "ce-id: 0815"  \
-d '{"value":"Hello Knative"}' \
<broker-URL>

Where <broker-URL> is the URL of your broker. For example:

curl -X POST -v \
-H "content-type: application/json"  \
-H "ce-specversion: 1.0"  \
-H "ce-source: my/curl/command"  \
-H "ce-type: my.demo.event"  \
-H "ce-id: 0815"  \
-d '{"value":"Hello Knative"}' \
http://broker-ingress.knative-eventing.svc.cluster.local/default/my-broker
  1. You will receive a 202 HTTP response code, that the broker did accept the request:
...
* Mark bundle as not supporting multiuse
< HTTP/1.1 202 Accepted
< allow: POST, OPTIONS
< date: Tue, 15 Mar 2022 13:37:57 GMT
< content-length: 0
< x-envoy-upstream-service-time: 79
< server: istio-envoy
< x-envoy-decorator-operation: broker-ingress.knative-eventing.svc.cluster.local:80/*
  1. Apply a AuthorizationPolicy object in the knative-eventing namespace to describe that the path to the Broker is restricted to a given user:
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: require-jwt
  namespace: knative-eventing
spec:
  action: ALLOW
  rules:
    - from:
        - source:
            requestPrincipals: ["testing@secure.istio.io/testing@secure.istio.io"]
      to:
        - operation:
            methods: ["POST"]
            paths: ["/default/my-broker"]
  1. Create a RequestAuthentication object for the user requestPrincipal in the istio-system namespace:
apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
  name: "jwt-example"
  namespace: istio-system
spec:
  jwtRules:
    - issuer: "testing@secure.istio.io"
      jwksUri: "https://raw.githubusercontent.com/istio/istio/release-1.13/security/tools/jwt/samples/jwks.json"
  1. Now retrying the curl command results in a 403 - Forbidden response code from the server:
...
* Mark bundle as not supporting multiuse
< HTTP/1.1 403 Forbidden
< content-length: 19
< content-type: text/plain
< date: Tue, 15 Mar 2022 13:47:53 GMT
< server: istio-envoy
< connection: close
< x-envoy-decorator-operation: broker-ingress.knative-eventing.svc.cluster.local:80/*
  1. To access the Broker, add the Bearer JSON Web Token as part of the request:
TOKEN=$(curl https://raw.githubusercontent.com/istio/istio/release-1.13/security/tools/jwt/samples/demo.jwt -s)

curl -X POST -v \
-H "content-type: application/json"  \
-H "Authorization: Bearer ${TOKEN}"  \
-H "ce-specversion: 1.0"  \
-H "ce-source: my/curl/command"  \
-H "ce-type: my.demo.event"  \
-H "ce-id: 0815"  \
-d '{"value":"Hello Knative"}' \
<broker-URL>

The server now responds with a 202 response code, indicating that it has accepted the HTTP request:

* Mark bundle as not supporting multiuse
< HTTP/1.1 202 Accepted
< allow: POST, OPTIONS
< date: Tue, 15 Mar 2022 14:05:09 GMT
< content-length: 0
< x-envoy-upstream-service-time: 40
< server: istio-envoy
< x-envoy-decorator-operation: broker-ingress.knative-eventing.svc.cluster.local:80/*
Back to top

We use analytics and cookies to understand site traffic. Information about your use of our site is shared with Google for that purpose. Learn more.

× OK