Request হলো একটি container যা নিশ্চিতভাবে পায় (scheduling-এ ব্যবহৃত); limit হলো সেই সর্বোচ্চ সীমা যা এটি অতিক্রম করতে পারে না (runtime-এ প্রয়োগ করা হয়)। একসাথে এরা নির্ধারণ করে Pod কোথায় বসবে, চাপের অধীনে কীভাবে throttle বা kill হবে, এবং একটি Pod কোন Quality of Service (QoS) class পাবে।
REQUEST → the amount RESERVED for the container. The SCHEDULER uses the sum of
requests to decide if a node has room. This is your guaranteed floor.
LIMIT → the MAX the container may use. Enforced at runtime:
CPU over limit → THROTTLED (slowed down, not killed)
memory over limit → OOM-KILLED (container terminated, then restarted)
spec:
containers:
- name: app
image: myapp:1.0
resources:
requests:
cpu: "250m" # একটি core-এর 0.25, নিশ্চিত
memory: "256Mi"
limits:
cpu: "500m" # 0.5 core পর্যন্ত burst করতে পারে, তারপর throttled
memory: "512Mi" # এটি অতিক্রম করলে → OOMKilled
Node has 4 CPU / 8Gi allocatable.
Scheduler sums the REQUESTS of Pods already placed; a new Pod fits only if its
requests still fit in what remains. (Limits are NOT used for placement.)
→ Set requests too low → node overcommitted, Pods fight for resources.
→ Set requests too high → wasted capacity, Pods stuck Pending (nothing fits).
Guaranteed → requests == limits for BOTH cpu & memory (every container)
→ last to be evicted (highest priority)
Burstable → has requests but they are < limits (or partially set)
→ evicted after BestEffort
BestEffort → no requests or limits at all
→ FIRST to be evicted when the node runs low on memory
kubectl describe pod app | grep -i qos # QoS Class: Guaranteed/Burstable/BestEffort
kubectl top pods # প্রকৃত CPU/memory ব্যবহার
kubectl describe node <node> # Allocated resource বনাম capacity
✓ Always set memory requests = limits for predictable, OOM-safe behavior on critical apps
✓ Set CPU requests to the steady-state need; CPU limits are often left off to allow bursting
✓ Right-size from real usage (kubectl top / metrics) — not guesses
✓ Use LimitRange / ResourceQuota to enforce sane defaults per namespace
Request ও limit হলো যেভাবে Kubernetes সীমিত node resource ন্যায্যভাবে ও অনুমানযোগ্যভাবে ভাগ করে, তাই পার্থক্য ও এর পরিণতি বোঝা অপরিহার্য কর্মক্ষমতা ও নির্ভরযোগ্যতা জ্ঞান। মূল অন্তর্দৃষ্টি হলো এরা ভিন্ন উদ্দেশ্য সাধন করে: request হলো একটি নিশ্চিত reservation যা scheduler Pod বসাতে ব্যবহার করে (একটি node-এ জায়গা আছে কিনা তা সিদ্ধান্ত নিতে request যোগ করে, limit উপেক্ষা করে), যখন limit হলো একটি runtime সর্বোচ্চ সীমা যা প্রতিটি resource-এ ভিন্নভাবে প্রয়োগ হয় — একটি CPU limit অতিক্রম করলে আপনি throttled হন (ধীর), কিন্তু একটি memory limit অতিক্রম করলে container OOM-killed ও restart হয়। request ভুল করার উভয় দিকেই বাস্তব খরচ আছে: খুব কম হলে node overcommitted হয় তাই Pod একে অপরকে অনাহারে রাখে; খুব বেশি হলে capacity নষ্ট হয় যখন Pod Pending-এ বসে থাকে কারণ কিছুই মেলে না। তিনটি QoS class — Guaranteed (request limit-এর সমান), Burstable (request limit-এর নিচে), এবং BestEffort (কিছুই সেট নেই) — memory চাপের অধীনে eviction ক্রম নির্ধারণ করে, BestEffort প্রথমে মারা হয় ও Guaranteed শেষে, ঠিক যা আপনাকে গুরুত্বপূর্ণ workload রক্ষা করতে বুঝতে হয়। ব্যবহারিক নির্দেশনা জানা (গুরুত্বপূর্ণ অ্যাপের জন্য memory request limit-এর সমান সেট করুন, kubectl top-এর মাধ্যমে প্রকৃত ব্যবহার থেকে right-size করুন, LimitRange/ResourceQuota দিয়ে ডিফল্ট প্রয়োগ করুন) এটিকে তত্ত্ব থেকে সুষ্ঠু capacity planning-এ পরিণত করে। যেহেতু resource ভুল-কনফিগারেশন বাস্তব cluster-এ অস্থিরতা, নষ্ট খরচ, ও Pending Pod-এর সবচেয়ে সাধারণ কারণগুলোর একটি, request, limit, ও QoS আয়ত্ত করা Kubernetes-এ দক্ষ, স্থিতিশীল workload চালানোর জন্য ভিত্তিমূলক।
বিস্তারিত উত্তরসহ IT ইন্টারভিউ প্রশ্নের একটি লাইব্রেরি — জুনিয়র থেকে সিনিয়র পর্যন্ত।
দান করুন