نوټ. ژباړه: په دې مقاله کې، بنزای کلاوډ یو مثال شریکوي چې څنګه د دې دودیز وسیلې کارول کیدی شي ترڅو کافکا په کوبرنیټس کې کارول اسانه کړي. لاندې لارښوونې په ګوته کوي چې تاسو څنګه کولی شئ د خپل زیربنا مطلوب اندازه وټاکئ او کافکا پخپله ترتیب کړئ ترڅو اړین ټرپټ ترلاسه کړي.
اپاچی کافکا د اعتبار وړ، پیمانه وړ او لوړ فعالیت ریښتیني وخت سټیمینګ سیسټمونو رامینځته کولو لپاره توزیع شوی سټیمینګ پلیټ فارم دی. د دې اغیزمن وړتیاوې د Kubernetes په کارولو سره پراخ کیدی شي. د دې لپاره موږ پرمختګ کړی دی او یوه وسیله نومیږي . دوی تاسو ته اجازه درکوي چې کافکا په کبرنیټس چل کړئ او د هغې مختلف ب featuresې وکاروئ ، لکه د بروکر ترتیب ښه تنظیم کول ، د بیا توازن سره د میټریک پراساس اندازه کول ، د ریک پوهاوی ، "نرم" (ښکلی) تازه کول، او داسې نور
په خپل کلستر کې Supertubes هڅه وکړئ:
curl https://getsupertubes.sh | sh и supertubes install -a --no-democluster --kubeconfig <path-to-eks-cluster-kubeconfig-file>یا اړیکه ونیسئ . تاسو کولی شئ د کافکا د ځینو وړتیاو په اړه هم ولولئ، هغه کار چې د سوپرټیوب او کافکا آپریټر په کارولو سره اتومات کیږي. موږ لا دمخه په بلاګ کې د دوی په اړه لیکلي دي:
- ;
- ;
- ;
- ;
- ;
- ;
- .
کله چې تاسو پریکړه وکړئ چې په کبرنیټس کې د کافکا کلستر ځای په ځای کړئ، نو تاسو به احتمال د زیربناوو د غوره اندازې ټاکلو ننګونې سره مخ شئ او اړتیا ولرئ چې ستاسو د کافکا ترتیب د ټرپټ اړتیاو پوره کولو لپاره ښه تنظیم کړئ. د هر بروکر اعظمي فعالیت د لاندې زیربناوو اجزاو فعالیت لخوا ټاکل کیږي ، لکه حافظه ، پروسیسر ، د ډیسک سرعت ، د شبکې بینډ ویت او داسې نور.
په عین حال کې، د بروکر ترتیب باید داسې وي چې ټول زیربنا عناصر د دوی اعظمي ظرفیتونو لپاره کارول کیږي. په هرصورت، په ریښتینې ژوند کې دا ترتیب خورا پیچلی دی. ډیر احتمال شته چې کاروونکي به د بروکرونو ترتیب کړي ترڅو د یوې یا دوه برخو (ډیسک، حافظې، یا پروسیسر) کارول اعظمي کړي. په عموم کې ، یو بروکر اعظمي فعالیت ښیې کله چې د دې ترتیب خورا ورو برخې ته اجازه ورکوي چې خپل بشپړ حد ته وکارول شي. پدې توګه موږ کولی شو د بار په اړه دقیق نظر ترلاسه کړو چې یو بروکر یې اداره کولی شي.
په تیوریکي توګه، موږ کولی شو د ورکړل شوي بار اداره کولو لپاره د بروکرانو شمیر هم اټکل کړو. په هرصورت، په عمل کې په مختلفو کچو کې د ترتیب کولو ډیری اختیارونه شتون لري چې دا خورا ستونزمن کار دی (که ناممکن نه وي) د یو ځانګړي ترتیب احتمالي فعالیت ارزونه. په بل عبارت، دا خورا ستونزمن کار دی چې د ځینې ورکړل شوي فعالیت پراساس یو ترتیب پلان کړئ.
د سوپرټیوب کاروونکو لپاره، موږ معمولا لاندې طریقه اخلو: موږ د یو څه ترتیب سره پیل کوو (بنسټیز + ترتیبات)، بیا د هغې فعالیت اندازه کوو، د بروکر ترتیبات تنظیم کړئ او پروسه بیا تکرار کړئ. دا تر هغه وخته پورې واقع کیږي چې د زیربنا ترټولو ورو برخه په بشپړه توګه کارول کیږي.
په دې توګه، موږ روښانه مفکوره ترلاسه کوو چې څو کلستر د یو ځانګړي بار اداره کولو لپاره څومره بروکرانو ته اړتیا لري (د بروکرانو شمیر هم په نورو فکتورونو پورې اړه لري، لکه د لیوالتیا ډاډ ترلاسه کولو لپاره د پیغام نقلونو لږترلږه شمیر، د ویش شمیره مشران، او داسې نور). برسېره پردې، موږ په دې اړه بصیرت ترلاسه کوو چې د زیربناوو برخې عمودی اندازه کولو ته اړتیا لري.
دا مقاله به د هغه ګامونو په اړه وغږیږي چې موږ یې په ابتدايي تشکیلاتو کې د خورا ورو برخو څخه د ترلاسه کولو لپاره اخلو او د کافکا کلستر له لارې اندازه کول. یو ډیر انعطاف لرونکی ترتیب لږترلږه درې چلونکي بروکرانو ته اړتیا لري (min.insync.replicas=3)، د لاسرسي په دریو مختلف زونونو کې ویشل شوي. د Kubernetes زیربنا تنظیمولو، اندازه کولو او څارلو لپاره، موږ د هایبرډ بادلونو لپاره خپل د کانټینر مدیریت پلیټ فارم کاروو - . دا آن پریمیس (ننګ فلزي ، VMware) او پنځه ډوله بادل (علی بابا ، AWS ، Azure ، ګوګل ، اوریکل) ملاتړ کوي ، او همدارنګه د دوی هر ترکیب.
د کافکا کلستر زیربنا او ترتیب په اړه فکرونه
د لاندې مثالونو لپاره، موږ AWS د کلاوډ چمتو کونکي او EKS د Kubernetes توزیع په توګه غوره کړ. یو ورته ترتیب په کارولو سره پلي کیدی شي - د بنزای کلاوډ څخه د کبرنیټ توزیع، د CNCF لخوا تصدیق شوی.
ټيکلی
ایمیزون مختلف وړاندیز کوي . په اصلي gp2 и io1 د SSD ډرایو شتون لري، په هرصورت، د لوړ تولید ډاډ ترلاسه کولو لپاره gp2 جمع شوي کریډیټ مصرفوي (I/O کریډیټ)نو موږ ډول ته ترجیح ورکړه io1، کوم چې په دوامداره توګه لوړ تولید وړاندیز کوي.
د بېلګې ډولونه
د کافکا فعالیت په عملیاتي سیسټم کې د پاڼې کیچ پورې اړه لري، نو موږ د بروکرز (JVM) او پاڼې کیچ لپاره د کافي حافظې سره مثالونو ته اړتیا لرو. مثال c5.2x لوی - یو ښه پیل، ځکه چې دا د 16 GB حافظه لري او . د دې نیمګړتیا دا ده چې دا یوازې د دې وړتیا لري چې په هرو 30 ساعتونو کې له 24 دقیقو څخه ډیر لپاره اعظمي فعالیت چمتو کړي. که ستاسو د کار بار د اوږدې مودې لپاره لوړ فعالیت ته اړتیا ولري، تاسو ممکن د نورو مثالونو ډولونه په پام کې ونیسئ. دا په حقیقت کې هغه څه دي چې موږ یې وکړل، په لاره کې ودرېدل c5.4x لوی. دا په اعظمي توګه د ننوتلو لپاره چمتو کوي 593,75 Mbps. د EBS حجم اعظمي حد io1 د مثال په پرتله لوړ c5.4x لوی، نو د زیربنا ترټولو ورو عنصر احتمال لري د دې مثال ډول I/O throughput وي (کوم چې زموږ د بار ازموینې هم باید تایید کړي).
شبکه
د شبکې انډول پیټ باید د VM مثال او ډیسک فعالیت په پرتله کافي لوی وي ، که نه نو شبکه یو خنډ کیږي. زموږ په قضیه کې، د شبکې انٹرفیس c5.4x لوی تر 10 Gb/s سرعت ملاتړ کوي، کوم چې د VM مثال د I/O له لارې د پام وړ لوړ دی.
د بروکر ګمارل
بروکران باید وقف شوي نوډونو ته وګمارل شي (په کبرنیټس کې مهالویش شوي) ترڅو د CPU ، حافظې ، شبکې او ډیسک سرچینو لپاره د نورو پروسو سره سیالي کولو مخه ونیسي.
جاوا نسخه
منطقي انتخاب جاوا 11 دی ځکه چې دا د ډاکر سره په دې معنی کې مطابقت لري چې JVM په سمه توګه کانټینر ته موجود پروسیسرونه او حافظه ټاکي چیرې چې بروکر روان وي. پدې پوهیدل چې د CPU حدود مهم دي، JVM په داخلي او شفاف ډول د GC تارونو او JIT تارونو شمیر ټاکي. موږ د کافکا انځور وکاروو banzaicloud/kafka:2.13-2.4.0، چې په جاوا 2.4.0 کې د کافکا نسخه 2.13 (Scala 11) لري.
که تاسو غواړئ په Kubernetes کې د Java/JVM په اړه نور معلومات زده کړئ، زموږ لاندې پوسټونه وګورئ:
- ;
- .
د بروکر حافظه تنظیمات
د بروکر حافظې تنظیم کولو لپاره دوه کلیدي اړخونه شتون لري: د JVM لپاره تنظیمات او د Kubernetes پوډ لپاره. د پوډ لپاره ټاکل شوی د حافظې حد باید د اعظمي هپ اندازې څخه ډیر وي ترڅو JVM د جاوا میټا اسپیس لپاره ځای ولري چې په خپله حافظه کې اوسیږي او د عملیاتي سیسټم پاڼې کیچ لپاره چې کافکا په فعاله توګه کاروي. زموږ په ازموینو کې موږ د کافکا بروکرز د پیرامیټونو سره پیل کړل -Xmx4G -Xms2G، او د پوډ لپاره د حافظې حد و 10 Gi. مهرباني وکړئ په یاد ولرئ چې د JVM لپاره د حافظې تنظیمات په اتوماتيک ډول په کارولو سره ترلاسه کیدی شي -XX:MaxRAMPercentage и -X:MinRAMPercentage، د پوډ لپاره د حافظې محدودیت پراساس.
د بروکر پروسیسر ترتیبات
په عموم کې ، تاسو کولی شئ د کافکا لخوا کارول شوي تارونو شمیر په زیاتولو سره موازي کولو سره فعالیت ښه کړئ. د کافکا لپاره څومره پروسیسرونه شتون لري، ښه. زموږ په ازموینه کې، موږ د 6 پروسیسرونو محدودیت سره پیل کړ او په تدریجي ډول (د تکرارونو له لارې) د دوی شمیر 15 ته لوړ شو. سربیره پردې، موږ ټاکلی شو num.network.threads=12 د بروکر تنظیماتو کې د تارونو شمیر زیاتولو لپاره چې له شبکې څخه ډیټا ترلاسه کوي او لیږل کیږي. سمدلاسه وموندله چې پیروونکي بروکران نشي کولی په کافي اندازه عکسونه ترلاسه کړي ، دوی راپورته کړل num.replica.fetchers تر 4 پورې د سرعت زیاتولو لپاره چې د پیروانو بروکرانو د مشرانو څخه پیغامونه نقل کړي.
د بارولو تولید وسیله
تاسو باید ډاډ ترلاسه کړئ چې د کافکا کلستر (چې بنچمارک شوی) خپل اعظمي بار ته رسیدو دمخه د ټاکل شوي بار جنریټر ظرفیت نه تیریږي. په بل عبارت، دا اړینه ده چې د بار تولید وسیلې د وړتیاوو لومړنۍ ارزونه ترسره کړئ، او همدارنګه د کافي شمیر پروسیسرونو او حافظې سره د مثال ډولونه غوره کړئ. په دې حالت کې، زموږ وسیله به د کافکا کلستر په پرتله ډیر بار تولید کړي. د ډیرو تجربو وروسته، موږ په دریو نقلونو کې میشت شو c5.4x لوی، چې هر یو یې جنراتور چلولی و.
بنچمارک کول
د فعالیت اندازه کول یو تکراري پروسه ده چې لاندې مرحلې پکې شاملې دي:
- د زیربنا جوړول (EKS کلستر، کافکا کلستر، د بار تولید وسیله، او همدارنګه پرومیتیس او ګرافانا)؛
- د راټول شوي فعالیت شاخصونو کې د تصادفي انحرافاتو فلټر کولو لپاره د یوې ټاکلې مودې لپاره د بار تولید کول؛
- د بروکر زیربنا تنظیم کول او تنظیم کول د مشاهده شوي فعالیت شاخصونو پراساس؛
- د پروسې بیا تکرار کول تر هغه چې د کافکا کلستر له لارې اړین کچې ته ورسیږي. په ورته وخت کې، دا باید په دوامداره توګه د تولید وړ وي او په ټرپټ کې لږترلږه توپیرونه وښيي.
بله برخه هغه مرحلې بیانوي چې د ازموینې کلستر بینچمارکینګ پروسې په جریان کې ترسره شوي.
توکي
لاندې وسیلې په چټکۍ سره د اساسی ترتیب تنظیم کولو لپاره کارول شوي، بارونه تولیدوي، او د فعالیت اندازه کول:
- د ایمیزون څخه د EKS کلستر تنظیم کولو لپاره c (د کافکا او زیربناوو میټریکونو راټولول) او (د دې میټریکونو لیدلو لپاره). موږ ګټه پورته کړه مدغم شوی в هغه خدمتونه چې د فدرالي څارنې، مرکزي لاګ راټولول، د زیان مننې سکینګ، د ناورین بیا رغونه، د تصدۍ درجې امنیت او نور ډیر څه چمتو کوي.
- - د کافکا کلستر د بار ازموینې لپاره وسیله.
- د کافکا میټریکونو او زیربنا لیدلو لپاره د ګرافانا ډشبورډونه: , .
- په کبرنیټس کې د کافکا کلستر تنظیم کولو ترټولو اسانه لار لپاره سوپرټیوب CLI. زوکیپر، کافکا آپریټر، سفیر او نور ډیری برخې نصب شوي او په سمه توګه ترتیب شوي ترڅو په کوبرنیټس کې د تولید لپاره چمتو کافکا کلستر چل کړي.
- د نصب لپاره سوپرټیوب CLI ورکړل شوي لارښوونې وکاروئ .
د EKS کلستر
د وقف شوي کارګر نوډونو سره د EKS کلستر چمتو کړئ c5.4x لوی د کافکا بروکرز سره د پوډونو لپاره د شتون مختلف زونونو کې ، په بیله بیا د بار جنراتور او څارنې زیربنا لپاره وقف شوي نوډونه.
banzai cluster create -f https://raw.githubusercontent.com/banzaicloud/kafka-operator/master/docs/benchmarks/infrastructure/cluster_eks_202001.jsonیوځل چې د EKS کلستر جوړ او روان وي، خپل مدغم فعال کړئ - هغه به پرومیټیوس او ګرافانا په یوه کلستر کې ځای په ځای کړي.
د کافکا سیسټم اجزا
په EKS کې د سوپرټیوب CLI په کارولو سره د کافکا سیسټم اجزا (زوکیپر، کافکا-آپریټر) نصب کړئ:
supertubes install -a --no-democluster --kubeconfig <path-to-eks-cluster-kubeconfig-file>د کافکا کلستر
په ډیفالټ ډول، EKS د EBS حجم ډولونه کاروي gp2، نو تاسو اړتیا لرئ د حجمونو پراساس د ذخیره کولو جلا ټولګي رامینځته کړئ io1 د کافکا کلستر لپاره:
kubectl create -f - <<EOF
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: fast-ssd
provisioner: kubernetes.io/aws-ebs
parameters:
type: io1
iopsPerGB: "50"
fsType: ext4
volumeBindingMode: WaitForFirstConsumer
EOF
د بروکرانو لپاره پیرامیټر تنظیم کړئ min.insync.replicas=3 او د بروکر پوډونه په نوډونو کې په دریو مختلف شتون زونونو کې ځای په ځای کړئ:
supertubes cluster create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f https://raw.githubusercontent.com/banzaicloud/kafka-operator/master/docs/benchmarks/infrastructure/kafka_202001_3brokers.yaml --wait --timeout 600موضوعات
موږ په موازي ډول درې بار جنراتور مثالونه چل کړل. دوی هر یو په خپله موضوع لیکي، دا دی، موږ په مجموع کې درې موضوعاتو ته اړتیا لرو:
supertubes cluster topic create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f -<<EOF
apiVersion: kafka.banzaicloud.io/v1alpha1
kind: KafkaTopic
metadata:
name: perftest1
spec:
name: perftest1
partitions: 12
replicationFactor: 3
retention.ms: '28800000'
cleanup.policy: delete
EOF
supertubes cluster topic create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f -<<EOF
apiVersion: kafka.banzaicloud.io/v1alpha1
kind: KafkaTopic
metadata:
name: perftest2
spec:
name: perftest2
partitions: 12
replicationFactor: 3
retention.ms: '28800000'
cleanup.policy: delete
EOF
supertubes cluster topic create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f -<<EOF
apiVersion: kafka.banzaicloud.io/v1alpha1
kind: KafkaTopic
metadata:
name: perftest3
spec:
name: perftest3
partitions: 12
replicationFactor: 3
retention.ms: '28800000'
cleanup.policy: delete
EOFد هرې موضوع لپاره، د نقل کولو فکتور 3 دی - د تولیدي سیسټمونو لپاره لږ تر لږه وړاندیز شوی ارزښت.
د بارولو تولید وسیله
موږ د بار جنراتور درې کاپي پیل کړې (هر یو یې په جلا موضوع کې لیکلي). د بار جنریټر پوډونو لپاره ، تاسو اړتیا لرئ د نوډ تړاو تنظیم کړئ ترڅو دوی یوازې د دوی لپاره ځانګړي شوي نوډونو کې مهالویش وي:
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
labels:
app: loadtest
name: perf-load1
namespace: kafka
spec:
progressDeadlineSeconds: 600
replicas: 1
revisionHistoryLimit: 10
selector:
matchLabels:
app: loadtest
strategy:
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
type: RollingUpdate
template:
metadata:
creationTimestamp: null
labels:
app: loadtest
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: nodepool.banzaicloud.io/name
operator: In
values:
- loadgen
containers:
- args:
- -brokers=kafka-0:29092,kafka-1:29092,kafka-2:29092,kafka-3:29092
- -topic=perftest1
- -required-acks=all
- -message-size=512
- -workers=20
image: banzaicloud/perfload:0.1.0-blog
imagePullPolicy: Always
name: sangrenel
resources:
limits:
cpu: 2
memory: 1Gi
requests:
cpu: 2
memory: 1Gi
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
dnsPolicy: ClusterFirst
restartPolicy: Always
schedulerName: default-scheduler
securityContext: {}
terminationGracePeriodSeconds: 30د یادولو وړ څو ټکي:
- د بارولو جنراتور د 512 بایټ اوږد پیغامونه تولیدوي او کافکا ته یې د 500 پیغامونو په بسته کې خپروي.
- د استدلال په کارولو سره
-required-acks=allخپرونه بریالۍ ګڼل کیږي کله چې د پیغام ټول ترکیب شوي نقلونه د کافکا بروکرانو لخوا ترلاسه او تایید شي. دا پدې مانا ده چې په بنچمارک کې موږ نه یوازې د پیغامونو ترلاسه کولو مشرانو سرعت اندازه کړی ، بلکه د دوی پیروان هم د پیغامونو نقل کوي. د دې ازموینې هدف د مصرف کونکي لوستلو سرعت ارزول ندي (مصرف) پدې وروستیو کې ترلاسه شوي پیغامونه چې لاهم د OS پا pageې زیرمه کې پاتې دي ، او دا په ډیسک کې ذخیره شوي پیغامونو لوستلو سرعت سره پرتله کوي. - د بار جنراتور په موازي توګه 20 کارګران چلوي (
-workers=20). هر کارګر پنځه تولیدونکي لري چې د کافکا کلستر سره د کارګر اړیکه شریکوي. د پایلې په توګه، هر جنراتور 5 تولیدونکي لري، او دوی ټول د کافکا کلستر ته پیغامونه لیږي.
د کلستر روغتیا څارنه
د کافکا کلستر د بار ازموینې په جریان کې، موږ د هغې روغتیا هم وڅارله ترڅو ډاډ ترلاسه شي چې هیڅ پوډ بیا پیل نه دی، د همغږي څخه بهر نقلونه شتون نلري، او د لږ تر لږه بدلونونو سره اعظمي جریان:
- د بار جنریټر د خپرو شویو پیغامونو شمیر او د خطا کچه په اړه معیاري احصایې لیکي. د تېروتنې کچه باید ورته پاتې شي
0,00%. - د کافکا آپریټر لخوا ګمارل شوی، یو ډشبورډ چمتو کوي چیرې چې موږ کولی شو د کلستر حالت وڅیړو. د دې پینل لیدلو لپاره دا وکړئ:
supertubes cluster cruisecontrol show -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> - د ISR کچه (د "همغږي" نقلونو شمیر) کمول او پراخول د 0 سره مساوي دي.
د اندازه کولو پایلې
3 بروکرز، د پیغام اندازه - 512 بایټ
د تقسیمونو سره په مساوي ډول په دریو بروکرانو کې توزیع شوي ، موږ وکولی شو فعالیت ترلاسه کړو ~ 500 Mb/s (په هره ثانیه کې نږدې 990 زره پیغامونه):
د JVM مجازی ماشین د حافظې مصرف د 2 GB څخه ډیر نه و:
د ډیسک تروپوټ په ټولو دریو مثالونو کې د I/O نوډ تروپوټ اعظمي حد ته رسیدلی چیرې چې بروکران روان وو:
د نوډونو لخوا د حافظې کارولو په اړه د معلوماتو څخه، دا تعقیبوي چې د سیسټم بفرینګ او کیشینګ ~ 10-15 GB اخیستی:
3 بروکرز، د پیغام اندازه - 100 بایټ
لکه څنګه چې د پیغام اندازه کمیږي، د 15-20٪ څخه تروپوټ راټیټیږي: د هر پیغام پروسس کولو وخت په دې اغیزه کوي. سربیره پردې ، د پروسیسر بار نږدې دوه چنده شوی.
څنګه چې د بروکر نوډونه لاهم نه کارول شوي کورونه لري ، د کافکا ترتیب بدلولو سره فعالیت ښه کیدی شي. دا یو اسانه کار نه دی، نو د ټرپټ زیاتولو لپاره دا غوره ده چې د لوی پیغامونو سره کار وکړو.
4 بروکرز، د پیغام اندازه - 512 بایټ
تاسو کولی شئ په اسانۍ سره د کافکا کلستر فعالیت په ساده ډول د نوي بروکرانو په اضافه کولو او د برخو توازن ساتلو سره لوړ کړئ (دا د بروکرانو ترمینځ حتی د بار ویش ډاډمن کوي). زموږ په قضیه کې، د بروکر اضافه کولو وروسته، د کلستر ټرپوټ ته وده ورکړه ~580 Mb/s (~ 1,1 ملیون پیغامونه په یوه ثانیه کې). وده د تمې څخه کمه وه: دا په عمده توګه د ویشونو د عدم توازن له امله ده (ټول بروکران د دوی د وړتیاوو په سر کې کار نه کوي).
د JVM ماشین د حافظې مصرف د 2 GB څخه ښکته پاتې شو:
د ډرایو سره د بروکرانو کار د برخو د عدم توازن لخوا اغیزمن شوی:
موندنو
پورته وړاندې شوي تکراري کړنلاره پراخه کیدی شي د ډیرو پیچلو سناریو ګانو پوښلو لپاره چې په سلګونو مصرف کونکي پکې شامل وي، بیا ویشل، تازه کول، د پوډ بیا پیل کول، او نور. دا ټول موږ ته اجازه راکوي چې په مختلفو شرایطو کې د کافکا کلستر د وړتیاوو محدودیتونه و ارزوو، د هغې په عملیاتو کې خنډونه وپیژنو او د هغوی سره د مبارزې لپاره لارې چارې ولټوو.
موږ سوپرټیوب ډیزاین کړی ترڅو په چټکۍ او اسانۍ سره یو کلستر ځای په ځای کړي، هغه یې تنظیم کړي، بروکرز او موضوعات اضافه/لرې کړي، خبرتیاو ته ځواب ووایي، او ډاډ ترلاسه کړي چې کافکا په عمومي توګه په Kubernetes کې په سمه توګه کار کوي. زموږ هدف دا دی چې تاسو سره په اصلي دنده تمرکز وکړئ (د کافکا پیغامونه "پیدا کړئ" او "خرچ کړئ")، او ټول سخت کار سوپرټیوب او کافکا آپریټر ته پریږدئ.
که تاسو د بنزی کلاوډ ټیکنالوژیو او خلاصې سرچینې پروژې سره علاقه لرئ ، نو شرکت کې ګډون وکړئ , او یا .
PS د ژباړونکي څخه
زموږ په بلاګ کې هم ولولئ:
- «»
- «»
- «".
سرچینه: www.habr.com