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