kubectl get pods চালালে সবকিছু ঠিক দেখায়। STATUS কলামে Running, RESTARTS কলামে 0। কিন্তু ব্রাউজারে সাইট খুললে 502, আর লগে নতুন কোনো এরর নেই — কারণ অ্যাপটা তো ক্র্যাশই করেনি।
এই একটা লাইন বোঝা গেলে সমস্যাটা এক মিনিটে সমাধান হয়ে যায়: Running মানে শুধু কন্টেইনারের প্রসেস চালু আছে। অ্যাপটা যে রিকোয়েস্ট নেওয়ার জন্য প্রস্তুত, সেটার কোনো গ্যারান্টি এতে নেই।
দুটো আলাদা প্রশ্ন
Kubernetes একটা Pod সম্পর্কে দুটো সম্পূর্ণ আলাদা প্রশ্ন জিজ্ঞেস করতে পারে, আর দুটোর উত্তর দুই জায়গায় ব্যবহার হয়।
লাইভনেস (liveness): প্রসেসটা কি বেঁচে আছে, নাকি ডেডলক হয়ে গেছে? উত্তর "না" হলে kubelet কন্টেইনারটা রিস্টার্ট করে দেয়।
রেডিনেস (readiness): প্রসেসটা কি এখন রিকোয়েস্ট নেওয়ার মতো অবস্থায় আছে? উত্তর "না" হলে Pod-টাকে Service-এর endpoint লিস্ট থেকে সরিয়ে দেওয়া হয় — কিন্তু রিস্টার্ট করা হয় না।
এই দ্বিতীয়টাই বেশিরভাগ ডিবাগিং সেশনে মিসিং থাকে। একটা অ্যাপ চালু হতে ১৫ সেকেন্ড লাগে — DB কানেকশন পুল বানায়, ক্যাশ ওয়ার্ম করে। সেই ১৫ সেকেন্ডে প্রসেসটা "জীবিত" ঠিকই, কিন্তু রিকোয়েস্ট নেওয়ার জন্য প্রস্তুত না। readiness probe না থাকলে Service সেই Pod-টাকেই ট্রাফিক পাঠাতে শুরু করে দেয়, আর ইউজার 502 পায়।
কনফিগে পার্থক্য
শুধু liveness
livenessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 5
periodSeconds: 10
liveness + readiness
livenessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 5
periodSeconds: 10
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 5
periodSeconds: 5
failureThreshold: 3
দুটো আলাদা এন্ডপয়েন্ট রাখাটা ইচ্ছাকৃত। /health শুধু বলে প্রসেসটা বেঁচে আছে কি না — সাধারণত একটা স্ট্যাটিক 200 OK। /ready আসল কাজ করে: DB কানেকশন আছে কি না, প্রয়োজনীয় ক্যাশ লোড হয়েছে কি না, সেটা চেক করে তারপর উত্তর দেয়। দুটো একই এন্ডপয়েন্টে বেঁধে ফেললে DB কানেকশন সাময়িকভাবে হারালে পুরো Pod-টাই রিস্টার্ট হতে থাকবে — যেটার দরকার ছিল না, শুধু ট্রাফিক সরিয়ে রাখলেই চলত।
স্লো-স্টার্ট অ্যাপের জন্য আরেকটা প্রোব
যেসব অ্যাপ চালু হতে বেশি সময় নেয় — বড় Java অ্যাপ্লিকেশন, ভারী মাইগ্রেশন চালায় এমন সার্ভিস — তাদের জন্য startupProbe আলাদা রাখা ভালো। এটা পাস না হওয়া পর্যন্ত liveness আর readiness প্রোব শুরুই হয় না, তাই স্টার্টআপের ধীর গতিকে "ক্র্যাশ" ভেবে ভুল করার সুযোগ থাকে না।
Quick check
একটা Pod-এর readinessProbe তিনবার ফেইল করেছে, কিন্তু livenessProbe পাস করছে। Kubernetes কী করবে?
Pod ট্রাফিক না পেলে যা চেক করবেন
Running অথচ ট্রাফিক পাচ্ছে না — ডিবাগিং অর্ডার
0/5 শেষ
এরপর থেকে Running দেখলেই আর ভরসা করার দরকার নেই। প্রশ্নটা হবে — কোন প্রোব, কী বলছে।
সম্পর্কিত লেখা
Deployment আপডেট করলে সাইট ডাউন হয় না কেন — Rolling Update ভেতরে ভেতরে কী করে
kubectl apply চালানোর পর সাইট একবারও ডাউন হয় না, অথচ পুরনো কোড সরে গিয়ে নতুন কোড চলে আসে। জাদু না — maxSurge আর maxUnavailable নামের দুটো সংখ্যা এটা সম্ভব করে।
ConfigMap বনাম Secret — কোনটায় কী রাখবেন
দুটোরই কাজ প্রায় একই রকম দেখতে — key-value ডেটা কন্টেইনারে ইনজেক্ট করা। কিন্তু একটাতে DB পাসওয়ার্ড রাখলে সেটা টিমের সবাই plaintext-এ পড়ে ফেলতে পারবে, আরেকটাতেও আসলে পারবে — যদি না আপনি সেটা জানেন।
মানুষ কেন অচেনা কারো কাছ থেকে কিনতে দ্বিধা করে — Trust Signal যেভাবে সেল বাড়ায়
একই ল্যান্ডিং পেজ, একই দাম, একই প্রোডাক্ট — শুধু নিচে তিনটা রিভিউ যোগ করলেই কনভার্শন বদলে যায়। এটা কাকতালীয় না, মানুষ সিদ্ধান্ত নেওয়ার সময় অন্যদের আচরণ দেখেই ভরসা করে।
মাসে একটা কাজের ইমেইল
ডিজাইন সিস্টেম প্যাটার্ন, ফ্রন্ট-এন্ড টেকনিক আর লার্ন প্ল্যাটফর্মের নোট। কোনো প্রচার নেই, অন্যের লিংকের সংকলনও নেই।