Kubernetes و Kafka: چه مسئله‌ای حل می‌کنند و چرا فعلاً نه

دو فناوری مشهور، دو مسئله‌ی متفاوت، بدون اجبار به استفاده

یک محصول سه serviceِ containerized را روی یک managed host اجرا می‌کند، هفته‌ای چند بار deploy دارد و جریان محدودی از domain event تولید می‌کند. دو consumer این eventها را از مسیر transactional outbox و managed queue می‌گیرند. SLO فعلی برقرار است، نیاز regulatory replay یا replay برای analytics وجود ندارد و یک application team مالک سیستم است. بااین‌حال proposal می‌گوید release بعدی «برای scale به Kubernetes و Kafka نیاز دارد».

این جمله دو تصمیم جدا را پنهان می‌کند. Kubernetes برای مدیریت workloadها و serviceهای containerized است. Kafka برای publish، نگه‌داری بادوام و پردازش streamِ eventهاست. هر دو capabilityهای مهمی دارند، اما capabilityِ واقعی یک محصول، شاهد نیاز همین سیستم در امروز نیست. [K8SOV] [KAFKAINTRO]

خروجی شما Kubernetes/Kafka Use-Not-Now Decision Matrix v1 است. این artifact برای هر فناوری یک row مستقل دارد و در آن problem class، symptom فعلی، trigger اندازه‌گیری‌شده، threshold مخصوص همین fixture، نیاز availability یا event، alternative ساده‌تر، operational owner، skill readiness، failure surface، migration cost، rollback path، evidence trace، decision، review date و stop/pivot condition ثبت می‌شود.

stateهای مجاز شامل USE، PILOT، NOT_NOW، UNKNOWN، EVIDENCE_INCOMPLETE، OWNER_MISSING، REVIEW_REQUIRED، HOLD، PARTIAL و DISPUTED هستند. NOT_NOW حدس مؤدبانه نیست؛ فقط وقتی تصمیم کامل است که evidence تعیین‌کننده حاضر باشد، trigger برقرار نباشد و alternative ساده‌تر نیاز فعلی را پوشش دهد. نبود evidence باید به state ناقص و تایپ‌شده منجر شود.

حدود ۴۵ دقیقه فعالیت در نظر بگیرید. ابتدا دو problem class را جدا می‌کنید، baseline synthetic را می‌سنجید، shortcutهای prestige-driven را رد می‌کنید، lab آفلاین deterministic را اجرا می‌کنید و سپس هر دو row را برای سیستمی با workloadهای زیاد، چند تیم و replay اجباری از نو محاسبه می‌کنید.

این درس برای engineer، technical lead، architect و product ownerی است که باید درباره‌ی Kubernetes یا Kafka یک تصمیم محدود و قابل‌ممیزی بگیرد؛ حتی وقتی نتیجه‌ی درست «فعلاً نه» است.

این درس راهنمای نصب، configuration، migration، capacity planning، benchmark یا approval تولید Kubernetes/Kafka نیست؛ cluster یا broker نمی‌سازد، vendor انتخاب نمی‌کند و outcome درس‌های مجاور Redis/Valkey، Temporal، search، API یا microservices را جذب نمی‌کند.

Prerequisite probe: آیا می‌توانید FACT مشاهده‌شده، INFERENCE حاصل از چند fact و DESIGN decision نیازمند authority محلی را از هم جدا کنید؟ آیا می‌توانید یک claim را به evidence visible وصل کنید، بدون اینکه توضیح یک ابزار را به مجوز تغییر architecture تبدیل کنید؟

اگر این مرز هنوز شکننده است، از bridge محدود زیر استفاده کنید: کنار چیزی که fixture یا مستند رسمی مستقیماً پشتیبانی می‌کند FACT بنویسید؛ کنار نتیجه‌ای که از چند fact گرفته‌اید INFERENCE؛ و کنار threshold، تعیین owner، adoption gate یا rollback rule مخصوص این محصول DESIGN. یک DESIGN باید authority خودش را نام ببرد و نمی‌تواند authority را از vendor documentation قرض بگیرد. این bridge فقط عادت evidence لازم برای این درس را فراهم می‌کند و completion درس FND-003 را ادعا نمی‌کند.

اول مسئله‌ها را جدا کنید، بعد نام فناوری را بیاورید

پیش از fast path به این هشت سؤال پاسخ دهید:

1. آیا مسئله‌ی Kubernetes را به‌صورت یک gap در workload management بیان می‌کنید، نه صرفاً «container داریم»؟
2. آیا مسئله‌ی Kafka را به‌صورت gap در durable event streaming بیان می‌کنید، نه صرفاً «event داریم»؟
3. آیا برای هر row وضعیت فعلی اندازه‌گیری‌شده و threshold مخصوص همین fixture دارید؟
4. آیا ثابت کرده‌اید alternative ساده‌تر همان requirement را برآورده نمی‌کند؟
5. آیا ordering درون یک topic-partition را از global ordering همه‌ی eventها جدا می‌کنید؟
6. آیا تیم مالک on-call، upgrade، capacity، recovery و تغییر schema/policy را نام می‌برید؟
7. آیا rollback path محدود و قابل‌اجرا دارید، نه فقط جمله‌ی «migration برگشت‌پذیر است»؟
8. آیا وقتی trigger، owner یا recovery evidence ناقص است state ناقص را حفظ می‌کنید؟

هشت پاسخ درست route باتجربه را فعال می‌کند. چهار تا هفت پاسخ یعنی repair promptها را نگه دارید؛ صفر تا سه یعنی field dictionary در تمام lab visible بماند. evidence bar، negative case، transfer و source boundary در هر سه route یکسان است.

Self-check: عبارت‌های «enterprise scale»، «cloud native»، «future-proof» و «event-driven» را با مشاهده‌ای قابل‌اندازه‌گیری جایگزین کنید. اگر جمله بی‌معنا شد، آن عبارت slogan بوده است نه evidence.

مدل ذهنی: capability، trigger و decision سه چیز جدا هستند

دو chain مستقل بسازید:

KUBERNETES → مسئله‌ی مدیریت workload containerized → evidence فعلی placement/release/availability → trigger اعلام‌شده → alternative مانند managed host → owner + skill + failure surfaceِ control plane → migration + rollback → state محدود

KAFKA → مسئله‌ی durable event streaming → evidence نرخ/retention/replay/ordering/consumer → trigger اعلام‌شده → alternative مانند outbox/queue → owner + skill + failure surfaceِ broker/partition → migration + rollback → state محدود

مستند رسمی Kubernetes آن را platformی portable، extensible و open source برای مدیریت workloadها و serviceهای containerized با declarative configuration و automation معرفی می‌کند و capabilityهایی مانند desired-state management، scaling، failover، service discovery و load balancing را توضیح می‌دهد. این‌ها FACTِ platform هستند؛ نیاز سه service روی یک managed host به cluster را اثبات نمی‌کنند. [K8SOV]

مقدمه‌ی رسمی Apache Kafka آن را event-streaming platformی برای publish/subscribe، نگه‌داری بادوام و پردازش streamها تعریف می‌کند. eventها در topic قرار می‌گیرند، topicها برای توزیع scale به partition تقسیم می‌شوند و ترتیب خواندن در محدوده‌ی یک topic-partition حفظ می‌شود. این factها نمی‌گویند هر application event، queue یا background job به Kafka نیاز دارد. [KAFKAINTRO]

متن مرتب بالا fallback کامل asset://AWR-001/AWR-001-ASSET-FLOW است؛ نبود diagram هیچ dependency تصمیم را حذف نمی‌کند.

Evidence Contract برای دو تصمیم مستقل

row مربوط به Kubernetes

workloadهای containerized، تعداد تیم‌ها، deployment frequency، release coupling، placement constraint، scaling pattern، availability objective، incidentهای واقعی و رفتار host/scheduler فعلی را ثبت کنید. positive state باید capability مشخصی را به gap اندازه‌گیری‌شده‌ی workload management وصل کند؛ شمردن containerها کافی نیست. همچنین باید نشان دهد managed host، deployment automation یا scheduler کوچک‌تر چرا همان نیاز را پاسخ نمی‌دهد.

بار عملیات را visible کنید: lifecycleِ control plane و worker، networking و policy، identity، secret، storage integration، observability، upgrade، compatibility، capacity، incident response و تیم on-call. این درس ادعا نمی‌کند همه‌ی topologyهای Kubernetes هزینه‌ی یکسان دارند؛ می‌گوید obligationهای topology پیشنهادی نباید از evidence حذف شوند.

row مربوط به Kafka

نرخ فعلی و اوج event، تعداد producer، consumer groupهای مستقل، مدت retention، replay requirement، محدوده‌ی ordering، delivery/availability objective، schema evolution، تحمل consumer lag و gapِ outbox/queue/direct integration فعلی را ثبت کنید. volume به‌تنهایی کافی نیست: volume متوسط می‌تواند نیاز سخت replay داشته باشد و volume بالا ممکن است با service دیگری پوشش داده شود.

scopeِ ordering را دقیق نام ببرید. Kafka ترتیب را در محدوده‌ی topic-partition نگه می‌دارد و به‌طور خودکار global order میان partitionهای نامرتبط نمی‌دهد. [KAFKAINTRO] positive state باید partition/key strategy را به ordering موردنیاز ببندد و retention، replay، consumer و failure assumption را آشکار کند.

fieldهای مشترک

هر دو row به measured trigger مخصوص فناوری، threshold محلی، alternative ساده‌تر و نتیجه‌ی سنجش آن، operational owner، skill readiness، failure surface، migration cost، rollback path، evidence reference، traceِ FACT/DESIGN، rationale خود learner، review date و stop/pivot trigger نیاز دارند. state دو row می‌تواند متفاوت باشد؛ verdict ترکیبی «Kubernetes + Kafka» نامعتبر است.

ساخت Kubernetes/Kafka Use-Not-Now Decision Matrix v1

گام ۱ — proposal را دو بخش کنید. جمله‌ی «Kubernetes و Kafka می‌خواهیم» را به دو problem statement قابل‌رد تبدیل کنید. برای Kubernetes بپرسید کدام outcomeِ placement، rollout، scaling، isolation یا recovery از دست رفته است. برای Kafka بپرسید کدام outcomeِ publish، retention، replay، ordering، processing یا consumer independence از دست رفته است.

گام ۲ — مسیر فعلی را baseline کنید. خروجی واقعی managed host، CI/CD، database outbox، managed queue یا direct integration را همراه measurement و requirement اعلام‌شده ثبت کنید. مقایسه بدون baseline نمی‌تواند بهبود را ثابت کند.

گام ۳ — trigger محلی تعریف کنید. trigger از observable condition و thresholdی تشکیل می‌شود که برای همین fixture انتخاب شده است. «۲۰ workload و سه تیم» rule عمومی Kubernetes نیست؛ «چهار consumer group یا regulatory replay» هم rule رسمی Kafka نیست. هر دو را DESIGN برچسب بزنید، authority را مشخص کنید و evidence فعال‌کننده‌ی review را نگه دارید.

گام ۴ — capability fit را بسنجید. فقط capability مربوط به problem را map کنید. desired-state controllerهای Kubernetes ممکن است gap مدیریت workload را پاسخ دهند، اما جای application correctness، CI/CD، observability یا data system را نمی‌گیرند. retention و partitioned consumption در Kafka ممکن است gapِ replay/consumer را پاسخ دهد، اما هر CRUD notification را به streaming need تبدیل نمی‌کند. [K8SOV] [KAFKAINTRO]

گام ۵ — alternative ساده‌تر را challenge کنید. برای Kubernetes managed container hosting، deployment automation بهتر، autoscaling موجود و runbook صریح را تست کنید. برای Kafka transactional outbox + managed queue، change processing محدود یا direct integration را بسنجید. comparison باید روی همان availability، replay، ordering و recovery requirement باشد.

گام ۶ — ownership و failure را قیمت‌گذاری کنید. owner واقعی و skill gap را نام ببرید. failure surfaceهای تازه را روشن کنید: upgrade، networking/policy، scheduling/storage در Kubernetes؛ broker availability، partition، rebalance، retention، schema evolution، lag و poison event در Kafka. عدد مالی جعلی نسازید؛ activity و staffing assumption صریح، qualitative cost را نیز auditپذیر می‌کند.

گام ۷ — migration و rollback را هم‌زمان طراحی کنید. pilot محدود Kubernetes artifact قابل‌deploy روی host فعلی و traffic cutback دارد. pilot محدود Kafka تنها وقتی dual-publish می‌کند که duplicate effect، ordering و reconciliation کنترل شده باشد و بازگشت consumerها به مسیر outbox/queue تعریف شود. جمله‌ی «هر وقت خواستیم rollback می‌کنیم» بدون state reconciliation کافی نیست.

گام ۸ — ضعیف‌ترین state پشتیبانی‌شده را انتخاب کنید. PILOT فقط برای experiment محدود با success/stop criteria، owner و rollback کامل مناسب است. USE به adoption approval واقعی خارج از fixture synthetic نیاز دارد. NOT_NOW trigger absent و alternative sufficient می‌خواهد. evidence ناقص، conflicting، stale یا ownerless باید typed بماند.

گام ۹ — reconsideration را bind کنید. هر row review date و reopen condition قابل‌اندازه‌گیری دارد. تغییر evidence می‌تواند decision را تغییر دهد؛ مدشدن platform نباید آن را drift دهد.

Worked Example: یک سیستم، دو NOT_NOW مستدل

همه‌ی عددها و thresholdهای این بخش synthetic و مخصوص fixture هستند؛ sizing rule عمومی نیستند.

Kubernetes. محصول سه service مستقل، یک تیم و حدود سه deploy در هفته دارد. managed host، SLO اعلام‌شده‌ی 99.5% را برآورده می‌کند و breach منتسب به placement، scheduler recovery یا release coordination ثبت نشده است. trigger بازبینی fixture برابر ۲۰+ workload مستقل و سه+ تیم، یا زودتر در صورت gap اندازه‌گیری‌شده‌ی placement/availability است. application team مسیر فعلی را اداره می‌کند ولی Kubernetes on-call rotation و cluster-upgrade runbook ندارد. state برابر NOT_NOW است: evidence به‌اندازه‌ی کافی کامل است تا نبود trigger و کفایت alternative را نشان دهد.

Kafka. سیستم ۴۰ event/s با اوج ۱۲۰ دارد، دو consumer دارد، فقط ۲۴ ساعت retention برای retry عملیاتی لازم دارد و replay قانونی یا تحلیلی نمی‌خواهد. ordering فقط per business aggregate است. transactional outbox + managed queue هدف delivery را پوشش می‌دهد و تیم ظرفیت operationِ broker/partition ندارد. state باز هم NOT_NOW است: triggerِ durable streaming برقرار نیست و alternative ساده‌تر کافی است.

حالا تعداد service را به هشت افزایش دهید ولی همان یک تیم، deployment کم و بدون pressureِ placement/availability را نگه دارید. این mutation از trigger اعلام‌شده‌ی Kubernetes عبور نمی‌کند. container بیشتر ممکن است attention را بالا ببرد، اما cluster problem را ثابت نمی‌کند.

سپس با volume متوسط، retention هفت‌ساله برای audit/replay و شش consumer group مستقل اضافه کنید. trigger را volume نساخته؛ retention، replay و consumerها ساخته‌اند. row Kafka باید recompute شود. اگر owner، skill، schema، reconciliation، migration و rollback کامل باشند شاید PILOT پشتیبانی شود؛ اگر owner وجود ندارد state درست OWNER_MISSING است.

نسخه‌ی structured در asset://AWR-001/AWR-001-ASSET-TABLE قرار دارد و JSON و fallbackهای هر locale تمام fieldهای تعیین‌کننده را حفظ می‌کنند.

Failure Modeهای رایج

1. Prestige جای requirement می‌نشیند. «سیستم جدی Kubernetes/Kafka دارد» جای evidence را می‌گیرد. repair: یک outcome محلیِ ازدست‌رفته و measurement آن را نام ببرید.
2. دو تصمیم به هم قفل می‌شوند. triggerِ Kubernetes، Kafka را هم مثبت می‌کند یا برعکس. repair: دو row را مستقل recompute کنید.
3. داشتن container یعنی Kubernetes. packaging با orchestration gap اشتباه می‌شود. repair: workload، team، release، placement، availability و host فعلی را بررسی کنید.
4. داشتن event یعنی Kafka. notification با durable streaming اشتباه می‌شود. repair: rate، retention، replay، ordering، consumer independence و queue limit را بسنجید.
5. ordering بیش از حد claim می‌شود. ترتیب partition به global order تبدیل می‌شود. repair: topic، key، partition و consumer boundary را نام ببرید. [KAFKAINTRO]
6. threshold به نام vendor نوشته می‌شود. trigger synthetic به official guidance تبدیل می‌شود. repair: آن را DESIGN و authority آن را محلی اعلام کنید.
7. feature list جای comparison می‌گیرد. مسیر فعلی اندازه‌گیری نمی‌شود. repair: alternative را با همان requirement بسنجید.
8. operations حذف می‌شود. on-call، upgrade، capacity، recovery، schema، policy و observability مالک ندارند. repair: تا پذیرش owner واقعی در OWNER_MISSING بمانید.
9. PILOT به adoption پنهان تبدیل می‌شود. stop criteria یا rollback وجود ندارد. repair: traffic، duration، evidence، reconciliation و cutback را محدود کنید.
10. Unknown به NOT_NOW تبدیل می‌شود. نبود evidence با نبود trigger اشتباه می‌شود. repair: UNKNOWN، EVIDENCE_INCOMPLETE، PARTIAL یا state تایپ‌شده‌ی مناسب بدهید.
11. baseline به oracle تبدیل می‌شود. transfer هر دو NOT_NOW را کپی می‌کند. repair: labelها را پنهان و از evidence جدید محاسبه کنید.
12. capability به authority تبدیل می‌شود. مستند رسمی approval محصول تلقی می‌شود. repair: FACT خارجی، DESIGN محلی و human adoption authority را جدا کنید.

Bridge افراد باتجربه: platform capability را با product need یکی نکنید

اگر Kubernetes را operated کرده‌اید، تعریف مقدماتی را کوتاه کنید اما evidence را حذف نکنید: desired workload state، scheduling/placement need، rollout/scaling pattern، availability gap، comparison با platform فعلی، cluster lifecycle، storage/network/policy، owner و rollback. familiarity شاید training cost را کم کند؛ trigger محصول را ایجاد نمی‌کند.

اگر Kafka را operated کرده‌اید، event contract را نگه دارید: producer/consumer identity، rate/burst، retention، replay، ordering scope، partition/key assumption، delivery semantics، schema ownership، lag tolerance، current queue comparison، owner، migration، reconciliation و rollback. تجربه‌ی قبلی Kafka را default transport نمی‌کند.

برای هر row reversal test انجام دهید: کدام مشاهده‌ی دقیق NOT_NOW را به PILOT می‌برد و کدام مشاهده pilot را متوقف می‌کند؟ اگر جواب «growth» یا «complexity» است، آن را measurable کنید. اگر جواب «جای دیگری این platform را داریم» است، service boundary، capacity، tenancy، support agreement و incremental cost واقعی را evidence کنید.

problem fit هنوز distribution، cloud vendor، managed service، topology، operator، partition count، storage class، security architecture یا rollout plan را انتخاب نمی‌کند. آن‌ها تصمیم‌های بعدی با evidence و authority جدا هستند.

قبل از platform جدید، alternative ساده‌تر را بسنجید

managed container host در برابر Kubernetes

managed container host همراه CI/CD، health check، autoscaling موجود و runbook صریح ممکن است نیاز محصول کوچکِ تک‌تیمی را پوشش دهد. Kubernetes می‌تواند control plane declarative یکدستی برای workloadها بدهد، اما lifecycle، networking، policy، storage، observability، capacity، compatibility و incident obligation هم اضافه می‌کند. [K8SOV] سؤال درست «ساده در برابر حرفه‌ای» نیست؛ آیا control plane تازه gap اندازه‌گیری‌شده را با ownership cost قابل‌قبول می‌بندد؟

transactional outbox و managed queue در برابر Kafka

outbox می‌تواند تغییر database را به publication متصل کند و managed queue برای تعداد محدود consumer، delivery/retry بدهد. Kafka stream بادوام، خواندن دوباره، partitioned scale و stream processing فراهم می‌کند. [KAFKAINTRO] در مقابل event model، retention/schema governance، partition/key، lag monitoring، recovery، consumer behavior و operations owner لازم است. وجود کلمه‌ی event در architecture دلیل انتخاب Kafka نیست.

managed service در برابر self-managed

managed offering بخشی از infrastructure work را کم می‌کند، اما partition/schema/permission، observability، cost، incident coordination و migration riskِ application را حذف نمی‌کند. shared platform موجود نیز فقط وقتی burden را کم می‌کند که capacity، tenancy، SLO، support owner و chargeback روشن باشد. «managed» و «از قبل موجود» evidence قابل‌بررسی‌اند، نه approval خودکار.

alternative ساده‌تر فقط وقتی کافی است که همان requirement را برآورده کند. رد ابزار بدون measurement alternative، به همان اندازه‌ی adoption بدون trigger ضعیف است.

Guided Practice و Independent Practice

lab آفلاین lab://AWR-001/AWR-001-LAB1 فقط Python استاندارد می‌خواهد. تمام recordها synthetic و read-only هستند؛ account، credential، customer data، network call، cluster، broker یا infrastructure mutation وجود ندارد. starter تمام fieldها و check ruleها را نشان می‌دهد ولی decision، rationale، review date و stop condition را خالی می‌گذارد.

Guided pass:

1. fixture AWR001-BASELINE-001 را انتخاب کنید.
2. دقیقاً دو record با axisهای KUBERNETES و KAFKA بسازید.
3. evidence object متناظر را بدون تغییر کپی کنید؛ missing field را کامل نکنید.
4. هر row را مستقل و با ضعیف‌ترین state پشتیبانی‌شده تصمیم بگیرید.
5. rationale، review date و stop/pivot trigger خودتان را بنویسید.
6. python run_checks.py evidence/decision_matrix.template.json را اجرا کنید.

Repair pass:

• service-count mutation را اجرا کنید و توضیح دهید چرا count تنها trigger Kubernetes نیست.
• replay mutation را اجرا و Kafka را از retention/replay/ordering/consumer evidence recompute کنید.
• owner-missing mutation را اجرا و OWNER_MISSING را حفظ کنید.
• missing-evidence fixture را اجرا و state ناقص تایپ‌شده بدهید.

Independent pass:

transfer/transfer_fixture.json را در transfer template بگذارید، labelهای baseline را فراموش کنید و هر دو row را از نو محاسبه کنید. checker سبز، rule consistency و exact evidence binding را ثابت می‌کند؛ problem fit، authority boundary، trade-off و transfer rationale همچنان human-reviewed است.

Evidence package قابل‌قبول چه دارد؟

reviewer باید بدون hidden model reasoning هر دو تصمیم را بازتولید کند. بنابراین package شامل این موارد است:

• fixture identity دقیق و evidence object بدون تغییر برای هر فناوری؛
• problem class، current symptom، measurement و threshold محلی؛
• availability و در صورت ارتباط event rate، retention، replay، ordering و consumer؛
• alternative سنجیده‌شده، نه فقط نام آن؛
• operational owner و skill readiness؛
• failure surface، migration cost، rollback path و review trigger؛
• source reference با جداسازی official FACT از MAKNOW DESIGN؛
• stateی که از evidence قوی‌تر نیست؛
• یک negative mutation و یک changed-context transfer؛
• خروجی checker deterministic و rationale قابل‌بررسی انسانی.

AI می‌تواند evidence داده‌شده را مرتب و comparison deterministic را اجرا کند، اما حق invent کردن replay need، scale pressure، owner، skill readiness، adoption approval یا migration success را ندارد. checker سبز ضروری است اما کافی نیست: inconsistency ساختاری را می‌گیرد، درحالی‌که human reviewer مسئول architecture decision محدود می‌ماند.

Assessment و Transfer

AWR-001-F1: owned boundary و یک adjacent non-goal را بیان کنید و workload orchestration را از durable event streaming جدا نگه دارید.

AWR-001-F2: mutation افزایش service count همراه یک تیم، release کم و بدون availability pressure را diagnose کنید. field زیر threshold و evidence لازم برای reopen را نام ببرید.

AWR-001-F3: پس از افزودن replay سخت و چند consumer مستقل، Kafka را recompute کنید و state baseline را کپی نکنید.

AWR-001-S1: lesson boundary و یک non-goal را با بیان خودتان توضیح دهید.

AWR-001-S2: Kubernetes/Kafka Use-Not-Now Decision Matrix v1 را برای baseline synthetic بسازید.

AWR-001-S3: shortcut «هشت service یعنی Kubernetes» را تحلیل کنید. workload، team، release، placement، availability، alternative، ownership و rollback باید به هم وصل شوند.

AWR-001-S4: سیستم دوم ده‌ها workload مستقل، چند تیم، release پرتکرار، traffic bursty، چند consumer و regulatory replay/audit requirement دارد. هر دو row را مستقل recompute کنید. evidence کامل شاید PILOT محدود را پشتیبانی کند؛ USE را خودکار نمی‌کند.

Transfer فقط وقتی پاس است که state جدید به evidence جدید trace شود و مرز capability fact رسمی با adoption design محلی حفظ گردد.

منابع و Freshness Boundary

K8SOV — overview رسمی Kubernetes از claim محدود «platform portable، extensible و open source برای مدیریت workload/service containerized با declarative configuration و automation» و capabilityهای workload management پشتیبانی می‌کند. نیاز این محصول به Kubernetes را اثبات نمی‌کند. [K8SOV]

KAFKAINTRO — مقدمه‌ی رسمی Apache Kafka از claim محدود publish، نگه‌داری بادوام و پردازش event stream و partition شدن topicها همراه ordering درون topic-partition پشتیبانی می‌کند. نیاز این محصول به Kafka یا نیاز هر event به streaming platform را اثبات نمی‌کند. [KAFKAINTRO]

صفحه‌های primary در 2026-09-12 دوباره بررسی شدند و تغییر مادی‌ای که claim boundary قفل‌شده را گسترش دهد دیده نشد. review برنامه‌ریزی‌شده همچنان 2026-12-02 است، یا زودتر اگر semantics cited Kubernetes/Kafka تغییر مادی کند. thresholdها، state labelها، owner requirement، migration gate و adoption authority همگی MAKNOW DESIGN هستند، نه claim این دو پروژه.