Kubernetes: Pod, Deployment, Service ও resource limit

এই পাঠে যা শিখবেন

• Pod, Deployment ও Service আলাদা করা
• Readiness বনাম liveness ঠিক করা
• Resource requests, limits ও graceful termination বোঝা

সমস্যা দিয়ে শুরু

Sale-এর সময় Laravel replica বাড়াতে গিয়ে দল manual container start করছে। কোনো process crash করলে replacement দেরি হচ্ছে, release-এ কিছু request কেটে যাচ্ছে। Orchestration desired replica count বজায় রাখতে পারে। কিন্তু unhealthy database দেখলেই সব application restart করলে বিপদ আরও বাড়ে। তাই controller-এর কাজ ও health signal-এর অর্থ বুঝে configuration দিতে হবে।

সহজ করে বুঝি

Pod একসঙ্গে scheduled হওয়া container-এর unit। Deployment replica ও rollout পরিচালনা করে। Service নির্বাচিত ready Pod-এ স্থিতিশীল network access দেয়। Request scheduler-কে resource reservation জানায়; limit runtime ব্যবহার সীমিত করে। Readiness traffic নেওয়ার যোগ্যতা, liveness process আটকে আছে কি না, startup probe ধীর initialization-এর সময় দেয়। Kubernetes application business correctness নিজে যাচাই করে না।

পরিচিত একটি উপমা

রেস্তোরাঁর manager প্রয়োজনীয় সংখ্যক রান্নার station রাখেন। নতুন station প্রস্তুত না হলে waiter সেখানে order দেয় না। চালের সরবরাহ বন্ধ হলে সব chef-কে বরখাস্ত করা যেমন ভুল, database outage-এ সব Pod restart করাও তেমন ভুল হতে পারে।

নকশাটি দেখুন

flowchart TD
 D[Deployment desired replicas] --> P1[Pod A]
 D --> P2[Pod B]
 S[Service ready endpoints] --> P1
 S --> P2
 P1 --> DB[(Database)]
 P2 --> DB

Deployment Pod তৈরি করে, Service label দিয়ে তাদের খুঁজে পায়। Ready Pod-এ traffic যায়; terminating Pod drain করার সুযোগ পায়। Database আলাদা dependency। Pod সংখ্যা বাড়ালে database connection-ও বাড়ে, তাই replica count-এর সঙ্গে connection budget হিসাব করতে হবে। Web ও queue workload-এর scaling signal আলাদা হতে পারে।

PHP ও Laravel-এ প্রয়োগ

routes/web.php-তে minimal liveness-style route fragment। এটি process request serve করছে কি না দেখায়; database readiness নয়। Laravel-এর standard /up route-ও বিবেচ্য। Probe authentication ছাড়া হলে response-এ environment, credentials বা dependency details ফেরাবেন না।

use Illuminate\Support\Facades\Route;
Route::get('/health/live', function () {
    return response()->json(['status' => 'alive']);
});

সুবিধা, সীমাবদ্ধতা ও trade-off

Kubernetes replacement, service discovery ও rollout automation দেয়, কিন্তু cluster administration ও debugging-এর জটিলতা বাড়ায়। ছোট app-এর জন্য managed application platform যথেষ্ট হতে পারে। Too-small memory limit OOM kill ঘটায়; অযথা বড় requests cluster cost বাড়ায়। Probe threshold খুব tight হলে সাময়িক চাপকে permanent failure ভেবে restart loop তৈরি হতে পারে।

সাধারণ ভুল

• Liveness route-এ সব external dependency পরীক্ষা করা।
• Readiness-এর আগে traffic পাঠানো।
• Queue job-এর সময়ের চেয়ে termination grace ছোট রাখা।

আরও একটু গভীরে

PodDisruptionBudget voluntary disruption-এ কিছু replica রক্ষা করতে সাহায্য করে; node crash বন্ধ করে না। Topology spread বা anti-affinity দিয়ে independent node/zone-এ placement করুন। Long-running worker stop signal পেলে current কাজ শেষ করার সময় চাই। Job timeout, visibility/retry settings এবং termination behavior না মিললে duplicate execution হতে পারে, তাই idempotencyও দরকার।

মনে রাখুন

Orchestrator replica রাখে; সঠিক probes, placement ও graceful shutdown application owner-কে design করতে হয়।

নিজে চেষ্টা করুন

একটি staging deployment-এ দুই Pod রাখুন। একটিকে terminate করে চলমান request ও endpoint removal পর্যবেক্ষণ করুন। Database বন্ধ করে দেখুন liveness অকারণে restart করে কি না; recovery-র timeline লিখুন।

নিজের বোঝা যাচাই করুন

1. Pod ও Deployment এক?

Pod execution unit; Deployment desired state বজায় রাখা controller। Pod delete হলে Deployment replacement তৈরি করতে পারে।

2. Readiness failure-এ কী হয়?

Pod traffic endpoint থেকে বাদ পড়তে পারে; container restart হওয়া readiness-এর উদ্দেশ্য নয়। Restart decision liveness ও process exit-এর সঙ্গে সম্পর্কিত।

3. Request ও limit কেন আলাদা?

Request scheduling-এর resource budget; limit runtime ceiling। ভুল মান performance ও placement দুটোতেই সমস্যা আনে।

4. আরও Pod মানেই বেশি throughput?

Database, lock বা downstream bottleneck থাকলে নয়। Connection সংখ্যা ও resource contention বাড়তে পারে।

5. Kubernetes কি প্রতিটি ছোট app-এ দরকার?

না। Operational skill ও concrete scaling requirement দিয়ে সিদ্ধান্ত নিন; platform complexity-এর দামও capacity planning-এর অংশ।

আরও পড়ুন

• Kubernetes probes
• Kubernetes resource management