大數據批處理流處理數據工程【免費下載鏈接】beamApache Beam is a unified programming model for Batch and Streaming data processing.項目地址https://gitcode.com/gh_mirrors/beam4/beam點擊查看免費下載導讀Apache Beam 的持續(xù)集成CI與集成測試IT需要真實可用的消息中間件環(huán)境來驗證 Kafka I/O 連接器。本文基于倉庫中的 .test-infra/kafka/README.md 及其配套子模塊系統講解如何借助 Kubernetes manifests 與 Terraform 在 Google Kubernetes Engine (GKE) 上按需供給 Kafka 集群。讀完本文你將掌握 Strimzi Operator、Bitnami Helm Chart 與 GCP 私有 IP 代理三種方案的部署流程、關鍵參數與排障手段并能直接復用到 Beam 的測試環(huán)境搭建中。目錄總覽一個目錄多種 Kafka 實現.test-infra/kafka/目錄的核心設計思想是按實現方案劃分子目錄每個子目錄自包含部署所需的 Terraform 或 Kubernetes 清單。這樣既可以在不同測試場景間切換后端實現又不互相干擾。.test-infra/kafka/ ├── README.md # 總覽文檔本文主體 ├── bitnami/ # 基于 Bitnami Kafka Helm Chart 的部署方案 ├── proxy/ # GCP 私有 IP 代理bastion host方案 └── strimzi/ # 基于 Strimzi Operator 的部署方案 ├── 01-strimzi-operator/ # 通過 Terraform 部署 Strimzi Operator └── 02-kafka-persistent/ # 通過 Kustomize 部署持久化 Kafka 集群從倉庫結構看.test-infra/下還包含 dataproc、pubsub、jupyter、metrics 等同級測試基礎設施模塊Kafka 目錄只是其中一環(huán)專門服務于 Kafka 相關集成測試的中間件供給。環(huán)境要求部署前需要準備什么根據 .test-infra/kafka/README.md 中的 Requirements 小節(jié)使用這套代碼需要滿足以下前置條件依賴項說明Terraform CLI v1.2.0 及以上所有 Terraform 模塊均基于該版本語法編寫GKE 集群Ingress 配置默認假設運行在 Google Kubernetes Engine 集群上集群的創(chuàng)建可參考倉庫中的 google-kubernetes-engine 模塊kubectl CLI用于執(zhí)行 Kustomize apply 與集群狀態(tài)查詢IntelliJ 或 VS Code 的 Kubernetes 插件可選但強烈推薦便于在本地直接查看和編輯 YAML manifests其中 GKE 集群模塊位于 .test-infra/terraform/google-cloud-platform/google-kubernetes-engine是先決依賴所有 Kafka 方案都要求先有一個可連接的 Kubernetes 集群后續(xù)的 Strimzi、Bitnami 子文檔也重復強調了這一點。通用使用方式聚焦單一實現的模塊化布局總覽文檔指出每個子目錄聚焦一種特定的 Kafka 實現并給出了以 strimzi 目錄為例的用法。這意味著選擇方案 進入對應子目錄按該子目錄自帶的 README 執(zhí)行而不是在根目錄統一執(zhí)行。后文將逐一展開三種方案的完整步驟。方案一Strimzi —— Operator 持久化集群兩段式部署Strimzi 是 Kubernetes 上最主流的 Kafka Operator 之一。Beam 測試倉庫將其拆為兩個階段先用 Terraform 部署 Operator再用 Kustomize 部署由 Operator 管理的持久化 Kafka 集群。兩階段均有獨立文檔與完整配置。階段一用 Terraform Helm Provider 部署 Strimzi Operator.test-infra/kafka/strimzi/README.md 說明該模塊通過 Helm Chart 形式安裝 Strimzi Operator其核心實現位于 kafka.tf使用helm_release資源完成部署resource helm_release strimzi-helm-release { name var.name namespace var.namespace create_namespace true repository var.chart_repository chart var.chart_name version var.chart_version wait false set { name watchAnyNamespace value true } }幾個值得注意的實現細節(jié)wait falseTerraform 不會等待 Helm release 完全就緒才返回加快了 apply 速度后續(xù)可通過 kubectl 確認狀態(tài)watchAnyNamespace trueOperator 會監(jiān)聽整個集群的所有命名空間從而可以管理后續(xù)在strimzi命名空間之外創(chuàng)建的 Kafka 自定義資源create_namespace true目標命名空間不存在時自動創(chuàng)建。模塊暴露的全部變量定義在 variables.tf 中而默認值集中在 common.tfvarsname strimzi namespace strimzi kubeconfig_path ~/.kube/config chart_name strimzi-kafka-operator chart_version 0.40.0 chart_repository https://strimzi.io/charts/各變量的語義與默認值如下變量默認值含義namestrimziHelm release 名稱namespacestrimziOperator 部署的命名空間kubeconfig_path~/.kube/config連接集群用的 kubeconfig 路徑由 provider.tf 中的 Helm Provider 讀取chart_namestrimzi-kafka-operator使用的 Helm Chart 名稱chart_version0.40.0Chart 版本按當前倉庫配置為準chart_repositoryStrimzi 官方 Helm 倉庫Chart 來源倉庫地址執(zhí)行標準 Terraform 工作流即可完成 Operator 部署沿用 common.tfvars 的默認配置DIR.test-infra/kafka/strimzi/01-strimzi-operator VARScommon.tfvars # 注意該文件位于 $DIR 下使用相對文件名即可 terraform -chdir$DIR init terraform -chdir$DIR apply -var-file$VARS-chdir讓 Terraform 在指定目錄內執(zhí)行而-var-file傳入變量文件路徑這里刻意使用相對文件名正是為了讓兩個命令在任何工作目錄下都能拼出正確路徑。階段二用 Kustomize 部署持久化 Kafka 集群Operator 就緒后真正意義上的 Kafka 集群由 02-kafka-persistent 模塊提供其文檔 README.md 明確了集群清單源自 Strimzi 官方kafka-persistent.yaml示例v0.33.2 版本的再分發(fā)目錄結構采用標準的base overlays組織02-kafka-persistent/ ├── base/ │ └── v0.33.2/ │ ├── kafka-persistent.yaml # 集群主清單 │ └── kustomization.yaml └── overlays/ └── gke-internal-load-balanced/ ├── kustomization.yaml # 引用 base 并疊加補丁 └── listeners.yaml # 補丁GKE 內部 TCP LoadBalancerbase 層定義集群本體。kafka-persistent.yaml 的核心配置如下apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: name: beam-testing-cluster spec: kafka: resources: requests: cpu: 8 memory: 64Gi version: 3.6.0 replicas: 3 config: offsets.topic.replication.factor: 3 transaction.state.log.replication.factor: 3 transaction.state.log.min.isr: 2 default.replication.factor: 3 min.insync.replicas: 2 inter.broker.protocol.version: 3.4 storage: type: jbod volumes: - id: 0 type: persistent-claim size: 500Gi deleteClaim: false zookeeper: resources: requests: cpu: 1 memory: 2Gi replicas: 3 storage: type: persistent-claim size: 100Gi deleteClaim: false entityOperator: topicOperator: {} userOperator: {}對照配置逐項解讀集群規(guī)模replicas: 3的 Kafka broker 與 3 副本 Zookeeper配合entityOperatortopicOperator userOperator組成完整管控面Kafka 版本version: 3.6.0inter.broker.protocol.version: 3.4保證 broker 間協議兼容性這是升級場景中的關鍵參數可靠性配置offsets.topic.replication.factor、transaction.state.log.replication.factor、default.replication.factor均為 3min.insync.replicas與transaction.state.log.min.isr為 2 —— 保證任意單 broker 故障下集群仍可用同時滿足事務與 Exactly-Once 語義的 ISR 要求存儲Kafka 使用jbod類型掛載 500Gi 的 PersistentVolumeClaimZookeeper 使用 100Gi 的持久化卷且deleteClaim: false意味著刪除集群 CR 時 PVC 會被保留避免誤刪數據資源申請Kafka 每 broker 申請 8 核 / 64Gi 內存、Zookeeper 每節(jié)點 1 核 / 2Gi這是為 Beam 大規(guī)模集成測試準備的余量生產化時可按需下調。overlays 層則負責適配目標環(huán)境。從 overlays/gke-internal-load-balanced/kustomization.yaml 可以看出該 overlay 引用../../base/v0.33.2作為基礎并通過listeners.yaml補丁為集群追加一個GKE 內部 TCP LoadBalancer 類型的 Ingress使集群只能被 VPC 內的測試執(zhí)行者訪問而不會暴露到公網——這正是測試環(huán)境的安全基線。部署命令使用 kubectl 內建的 Kustomize 插件kubectl apply -k .test-infra/kafka/strimzi/02-kafka-persistent/overlays/gke-internal-load-balanced --namespacestrimzi等待集群進入 Ready 狀態(tài)超時 1200 秒因為需要為 PVC 和節(jié)點容量等待調度kubectl wait kafka beam-testing-cluster --forconditionReady --timeout1200s獲取連接地址逐副本查詢 LoadBalancer IP 與端口Strimzi 為每個 broker 副本各生成一個獨立的 Service命名規(guī)則為beam-testing-cluster-kafka-副本序號默認副本序號為 1 到 3。部署文檔給出了用jsonpath精確抽取連接信息的命令# 獲取第 N 個副本的負載均衡器 IP kubectl get svc beam-testing-cluster-kafka-$REPLICA_NUMBER -o jsonpath{.status.loadBalancer.ingress[0].ip} # 獲取第 N 個副本對外暴露的端口 kubectl get svc beam-testing-cluster-kafka-$REPLICA_NUMBER -o jsonpath{.spec.ports[0].port}其中$REPLICA_NUMBER取 1、2、3。將這些 IP:Port 組合填入 Beam Kafka I/O 的bootstrap.servers即可讓測試管道連入集群。方案二Bitnami —— 基于 Helm Chart 與 Terraform 的輕量方案如果希望避開 Kustomize/Operator 的復雜概念倉庫提供了基于 Bitnami Kafka Helm Chart 的第二方案見 bitnami/README.md。該方案的最大特點在于模塊內部直接使用 Terraform 的 Helm Provider因此你本機甚至不需要安裝 helm CLI。部署遵循最標準的 Terraform 工作流terraform init terraform applyGKE Autopilot 下的特殊注意點文檔特別提示當部署目標是 GKE Autopilot 集群時Pod 會先呈現Unschedulable狀態(tài)。這不是故障而是Autopilot 需要時間自動擴容節(jié)點等節(jié)點資源就緒后Kubernetes 會自動完成 Kafka 集群的調度與啟動。遇到該狀態(tài)時耐心等待即可。內置 Kafka 客戶端容器用于調試該模塊會在集群內額外部署一個kafka-clientPod基于最新 Bitnami Kafka 鏡像內置全部kafka-*.sh腳本專供排障使用。1. 查詢客戶端 Pod 名稱kubectl get po -l appkafka-client預期輸出類似NAME READY STATUS RESTARTS AGE kafka-client-cdc7c8885-nmcjc 1/1 Running 0 4m12s2. 進入容器 shellkubectl exec --stdin --tty kafka-client-cdc7c8885-nmcjc -- /bin/bash3. 執(zhí)行 Kafka 命令由于客戶端與集群同處一個 Kubernetes 集群直接借助集群 DNS 使用--bootstrap-server kafka:9092Bitnami 部署會創(chuàng)建一個名為kafka的 Service暴露 9092 端口# 獲取 cluster-id同時驗證連通性 kafka-cluster.sh cluster-id --bootstrap-server kafka:9092 # 創(chuàng)建 topic3 分區(qū)、3 副本 kafka-topics.sh --create --topic some-topic --partitions 3 --replication-factor 3 --bootstrap-server kafka:9092 # 查看 topic 詳情 kafka-topics.sh --describe --topic some-topic --bootstrap-server kafka:9092這套集群內客戶端模式非常適合 CI 場景測試管道可以在集群內直接完成 topic 預創(chuàng)建、消息注入與消費驗證無需從外部網絡訪問 broker。方案三proxy —— 為私有 IP Kafka 打通外部訪問通道Strimzi 的 GKE 內部負載均衡器方案決定了集群只對 VPC 內可見。當 Beam 測試執(zhí)行者位于集群外部如本地開發(fā)機時倉庫提供了 proxy 模塊在 Google Cloud 上創(chuàng)建一個私有 IP 的 bastion host跳板機作為訪問私有 Kafka 實例的代理詳見 proxy/README.md。前置條件使用該模塊的前提是已有一套 Kafka 集群即前文 Strimzi 或 Bitnami 方案的產出參見 .test-infra/kafka。第一步準備 bootstrap server 映射模塊的關鍵變量是bootstrap_endpoint_mapping用于把Kafka bootstrap server 主機名映射到希望代理暴露的本地端口具體定義見 variables.tf。即告訴代理broker-ip:9092這個地址請在本地用 9092 端口轉發(fā)。第二步應用模塊該模塊不使用 Terraform backend狀態(tài)文件保存在本地按典型工作流執(zhí)行DIR.test-infra/kafka/proxy terraform -chdir$DIR initterraform -chdir$DIR apply -var-filecommon.tfvars -var-filename_of_your_specific.tfvars注意這里需要同時傳入兩個變量文件common.tfvars提供通用默認值位于 .test-infra/kafka/proxy/common.tfvars后一個是你為本次集群準備的專屬 tfvars。第三步使用 gcloud SSH 隧道模塊 apply 成功后會直接輸出一條可復制的 gcloud 隧道命令格式形如gcloud compute ssh yourinstance --tunnel-through-iap --projectproject --zonezone --ssh-flag-4 -L9093:localhost:9093 --ssh-flag-4 -L9092:localhost:9092 --ssh-flag-4 -L9094:localhost:9094--tunnel-through-iap通過 Identity-Aware Proxy 建立安全隧道-L參數把本地端口逐一映射到代理上的 Kafka 端口。執(zhí)行后本地localhost:9092即可作為bootstrap.servers供 Beam 管道使用且全程不經公網直接暴露 Kafka。三種方案如何選型結合三份子文檔可以給出如下選型建議基于倉庫現狀的合理推斷對比維度Strimzi推薦主路徑Bitnamiproxy配套組件部署方式Terraform HelmOperatorKustomize集群純 Terraform Helm ProviderTerraform 計算實例集群能力持久化、3 副本、事務參數完整開箱即用的 Bitnami 默認配置不建集群僅打通訪問適用場景Beam 大規(guī)模、長時運行、需持久化的集成測試快速起停、輕量驗證、Autopilot 環(huán)境外部執(zhí)行者訪問私有集群時使用調試手段kubectl 查 CR 狀態(tài) / Service內置 kafka-client 容器gcloud SSH 隧道從倉庫結構看Strimzi 方案被組織得最完整獨立 operator 模塊 base/overlays 兩層 Kustomize是 Beam 測試基礎設施的主推實現Bitnami 方案作為輕量備選proxy 模塊則是為跨網絡訪問場景補齊的最后一塊拼圖。三者共同構成了從集群供給到外部接入的完整鏈路。結語本文圍繞 .test-infra/kafka/README.md 的骨架結合倉庫內各子模塊的 Terraform 配置與 Kubernetes 清單完整還原了 Beam 測試基礎設施中 Kafka 集群的供給全流程Strimzi 的 Operator 持久化集群兩段式部署含 3 副本、事務參數、500Gi 存儲等生產級配置細節(jié)、Bitnami 的輕量 Helm 方案含 Autopilot 注意事項與內置 kafka-client 調試容器、以及 proxy 的 IAP 隧道外部接入方案。讀者可依據測試規(guī)模與網絡環(huán)境直接套用對應命令在 GKE 上快速復現這套 Kafka 測試環(huán)境。贊分享大數據批處理流處理數據工程【免費下載鏈接】beamApache Beam is a unified programming model for Batch and Streaming data processing.項目地址https://gitcode.com/gh_mirrors/beam4/beam點擊查看免費下載相關推薦Apache Beam 測試基礎設施中的 Strimzi Kafka Operator 部署指南Terraform Helm Kustomize 全流程Apache Beam 測試基礎設施中的 Strimzi Kafka Operator 部署指南Terraform Helm Kustomize 全流大數據批處理流處理數據工程Facebook-Messenger-Bot入門30分鐘快速搭建你的個性化AI聊天助手Facebook Messenger Bot入門30分鐘快速搭建你的個性化AI聊天助手 Facebook Messenger Bot是一個基于Seq2Seq模大數據批處理流處理數據工程Apache Beam 測試基礎設施的 GCP Terraform IaC 實戰(zhàn)指南從私有 GKE 集群到 Vertex AI FeaturestoreApache Beam 測試基礎設施的 GCP Terraform IaC 實戰(zhàn)指南從私有 GKE 集群到 Vertex AI Featurestore Ap大數據批處理流處理數據工程上一篇終極指南如何使用Headlamp網絡可視化功能輕松理解Kubernetes服務通信路徑下一篇3DTopia與Stable Diffusion對比分析AI 3D生成的技術突破創(chuàng)作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考