使用隔離資料平面的 Knative Apache Kafka Broker ¶

發布於：2023-02-07，修訂於：2024-01-17

使用隔離資料平面的 Knative Apache Kafka Broker¶

作者：Ali Ok，Red Hat 的首席軟體工程師

在本部落格文章中，您將學習如何在隔離資料平面模式下設定 Knative 的 Apache Kafka Broker。

針對 Apache Kafka 的 Knative Broker 實作是 Knative Broker API 的 Kafka 原生實作，與使用基於 Channel 的 Knative Broker 實作相比，提供了一些改進，例如減少網路躍點、支援任何 Kafka 版本，以及 Broker 和 Trigger 模型與 Apache Kafka 的更好整合。

此外，此 Broker 類別支援 2 種資料平面模式：共用和隔離。

什麼是資料平面？¶

為了提供更好的概觀，了解什麼是資料平面非常重要。

Knative 的 Apache Kafka Broker 有 2 個平面，類似於許多其他 Knative 和 Kubernetes 元件。

控制平面是控制器的元件集合。這些控制器根據使用者建立的自訂物件來管理資料平面。在此案例中，控制平面管理的自訂物件是 Broker 和 Trigger。

資料平面是與 Apache Kafka 和訂閱者（觸發器的目標）通訊的元件集合，基於控制平面給定的設定。Knative Kafka Broker 資料平面中有 2 個元件

Ingress 是透過開啟 HTTP 端點來接聽事件的元件。然後，它將事件轉發到 Apache Kafka 主題，以進行持久化和同步事件的取用和產生速度。
Dispatcher 是從 Apache Kafka 主題接收事件，並將其分派到使用 Trigger API 訂閱的訂閱者的元件。

共用資料平面¶

當使用 Kafka 的 Broker 類別時，控制平面不會建立新的資料平面。相反地，它會設定現有的資料平面以履行已建立 Broker 的 Ingress 和分派職責。

在這篇部落格文章中示範了共用資料平面模式下的 Knative Kafka Broker。

如果您遵循該文章，您將會看到 Kafka Broker 的資料平面是在 knative-eventing 命名空間中建立的

kubectl get pods -n knative-eventing
NAME                                       READY   STATUS    RESTARTS   AGE
eventing-controller-7b95f495bf-dkqtl       1/1     Running   0          2h4m
eventing-webhook-8db49d6cc-4f847           1/1     Running   0          2h4m
kafka-broker-dispatcher-859d684d7d-frw6p   1/1     Running   0          2h4m  **<-- Dispatcher**
kafka-broker-receiver-67b7ff757-rk9b6      1/1     Running   0          2h4m  **<-- Ingress**
kafka-controller-7cd9bd8649-d62dh          1/1     Running   0          2h4m
kafka-webhook-eventing-f8c975b99-vc969     1/1     Running   0          2h4m

具體而言，Knative Kafka Broker 資料平面由 kafka-broker-dispatcher 和 kafka-broker-receiver Pod 組成，它們在所有 Broker 自訂物件之間共用。當建立另一個 Broker 時，控制平面不會建立任何新的部署。

如果您使用 kubectl get 取得 Broker 物件，您將會看到它們的位址使用 knative-eventing 命名空間中名為 kafka-broker-ingress 的 Kubernetes Service。兩個 Broker 的位址都是使用主機名稱 kafka-broker-ingress.knative-eventing.svc.cluster.local。

kubectl get brokers.eventing.knative.dev -A

NAMESPACE  NAME                    URL                                                                                           AGE     READY   REASON
default    my-demo-kafka-broker    http://kafka-broker-ingress.knative-eventing.svc.cluster.local/default/my-demo-kafka-broker   2h6m    True
other      other-kafka-broker      http://kafka-broker-ingress.knative-eventing.svc.cluster.local/other/other-kafka-broker       2h6m    True

由於使用相同的 Ingress 服務和相同的 Ingress 部署，因此 URL 路徑用於識別發佈到服務的任何事件的目標 Broker。對於 default 命名空間中的 my-demo-kafka-broker Broker，會使用 /default/my-demo-kafka-broker。對於 other 命名空間中的 other-kafka-broker Broker，會使用 /other/other-kafka-broker。

隔離資料平面¶

按照這篇部落格文章中的說明建立開發環境 Apache Kafka 和 Knative Kafka Broker 之後，您就已經可以開始嘗試隔離資料平面模式中的 Knative Kafka Broker，因為此模式已開箱支援。

首先，您需要建立一個 ConfigMap，其中包含 Broker 的設定。在此案例中，我們無法依賴先前部落格文章中建立的 knative-eventing 命名空間中的叢集範圍 ConfigMap。

與該教學中建立的全域 kafka-broker-config ConfigMap 類似，我們將建立一個 ConfigMap，但位於使用者命名空間 default 中。在隔離資料平面模式下，我們需要在與 Broker 相同的命名空間中具有 Broker 的設定。

cat <<-EOF | kubectl apply -f -
apiVersion: v1
kind: ConfigMap
metadata:
  name: kafka-broker-config
  namespace: default
data:
  default.topic.partitions: "10"
  default.topic.replication.factor: "1"
  bootstrap.servers: "my-cluster-kafka-bootstrap.kafka:9092"
EOF

現在，我們建立使用 KafkaNamespaced 類別的 Broker，並使用我們剛剛建立的設定

cat <<-EOF | kubectl apply -f -
apiVersion: eventing.knative.dev/v1
kind: Broker
metadata:
  annotations:
    eventing.knative.dev/broker.class: KafkaNamespaced
  name: broker-isolated-data-plane
  namespace: default
spec:
  config:
    apiVersion: v1
    kind: ConfigMap
    name: kafka-broker-config
    namespace: default
EOF

當我們檢查建立 Broker 物件的使用者命名空間時，我們會看到建立的資料平面 Pod

kubectl get pods -n default

NAME                                       READY   STATUS    RESTARTS   AGE
kafka-broker-dispatcher-8497dd6fb6-h8kdg   1/1     Running   0          15s
kafka-broker-receiver-84ff47fcd9-cv8j8     1/1     Running   0          15s

與資料平面部署類似，我們也會看到用於 Broker 物件的不同服務。因此，Broker 的位址將使用與 knative-eventing 命名空間中的 kafka-broker-ingress 服務不同的服務。

kubectl get brokers.eventing.knative.dev broker-isolated-data-plane -n default

NAME                         URL                                                                                        AGE   READY   REASON
broker-isolated-data-plane   http://kafka-broker-ingress.default.svc.cluster.local/default/broker-isolated-data-plane   37s   True

在隔離資料平面模式下，是針對每個命名空間建立新的資料平面，而不是針對每個 Broker 物件。如果我們在相同的命名空間中建立另一個 Broker 物件，它將使用相同的資料平面

cat <<-EOF | kubectl apply -f -
apiVersion: eventing.knative.dev/v1
kind: Broker
metadata:
  annotations:
    eventing.knative.dev/broker.class: KafkaNamespaced
  name: other-broker-isolated-data-plane
  namespace: default
spec:
  config:
    apiVersion: v1
    kind: ConfigMap
    name: kafka-broker-config
    namespace: default
EOF

不會建立新的資料平面 Pod

kubectl get pods -n default

NAME                                       READY   STATUS    RESTARTS   AGE
kafka-broker-dispatcher-8497dd6fb6-h8kdg   1/1     Running   0          72s
kafka-broker-receiver-84ff47fcd9-cv8j8     1/1     Running   0          72s

最後，當刪除命名空間中具有 KafkaNamespaced 類別的所有 Broker 物件時，資料平面將被移除

kubectl delete brokers.eventing.knative.dev -n default --all

kubectl get pods -n default

No resources found in default namespace.

使用案例¶

雖然共用資料平面方法適用於大多數案例，但在某些情況下，您可能不希望共用資料平面。

一個使用案例是當您不希望 knative-eventing 命名空間中的 Dispatcher 與其他命名空間中的訂閱者通訊，或者，同樣地，如果您不希望單一 Ingress 部署與多個 Apache Kafka 系統通訊。顯然，隔離資料平面模式會在使用者命名空間中建立 Dispatcher 和接收器，因此通訊僅限於命名空間。

另一種情況是當您看到吵雜鄰居問題的潛在可能性時。可能會有訊息代理程式實例接收到大量的負載，這可能會降低其他訊息代理程式的效能。由於資料平面是針對每個命名空間建立的，因此您可以建立多個命名空間，並在每個命名空間中部署訊息代理程式。這樣一來，您就可以隔離每個訊息代理程式實例的負載。

最後，另一個使用案例是當您希望使用 Istio 以自助服務的方式限制流量時。如使用 JSON Web Token (JWT) 和 Istio 保護 Knative 訊息代理程式中所述，您可以使用 Istio 根據訊息代理程式位址的 URL 路徑來限制流量。然而，對於共享資料平面的方法，需要將 Istio 注入標籤 istio-injection=enabled 新增至 knative-eventing 命名空間。同樣地，AuthorizationPolicy 物件也需要在 knative-eventing 命名空間中建立，因為訊息代理程式服務是在那裡建立的。使用者可能沒有權限修改 knative-eventing 命名空間。然而，在隔離的資料平面模式下，使用者可以在自己的命名空間中以自助服務的方式執行必要的標籤和物件建立。

結論¶

在這篇部落格文章中，我們已經了解如何使用新的 KafkaNamespaced 訊息代理程式類別，該類別讓 Knative 的 Apache Kafka 訊息代理程式為每個命名空間建立隔離的資料平面。我們也看到了一些隔離資料平面模式可能有用的使用案例。

同樣重要的是要了解，雖然隔離的資料平面方法在某些情況下很有用，但它會消耗更多的資源。因此，建議使用共享資料平面方法，除非您有充分的理由使用隔離的資料平面方法。

有關 KafkaNamespaced 訊息代理程式類別、其限制及其組態選項的更多資訊，請參閱文件。