Kubernetes যারা এটি চালাতে বাধ্য তাদের জন্য

Kubernetes টিউটোরিয়াল আপনাকে একটি pod স্থাপন করতে শেখায়। সকাল তিনটায় যখন একটি নোড নীরবে Ready অবস্থা থেকে বেরিয়ে আসে এবং আপনার on-call ফোন বাজতে থাকে তখন কী করতে হবে তা কেউ শেখায় না। এটি দ্বিতীয় অংশটি সম্পর্কে।

সম্পদের অনুরোধ এবং সীমা ঐচ্ছিক নয়

যদি আপনি আপনার কন্টেইনারে resources.requests এবং resources.limits বাদ দেন, তাহলে স্কেডিউলার অনুমান করছে, এবং kubelet এর কোনো ধারণা নেই যে কোনটি প্রথমে বের করতে হবে যখন কোনো নোড মেমরি সীমায় পৌঁছায়। অনুরোধ সেট করুন যা কন্টেইনার স্বাভাবিক লোডের অধীনে প্রকৃতপক্ষে ব্যবহার করে, আপনি যা আশা করেন তা নয়। মেমরি সীমা অনুরোধের কাছাকাছি সেট করুন কারণ OOM-killed pods পরিষ্কারভাবে পুনরায় চালু হয়, কিন্তু CPU সীমা সাধারণত আরও ঢিলা হওয়া উচিত বা অনুপস্থিত থাকা উচিত যদি না আপনি noisy neighbors এর সাথে লড়াই করছেন, কারণ হার্ড সীমার অধীনে CPU থ্রটলিং latency স্পাইক তৈরি করে যা ডিবাগ করা খুবই কঠিন। kubectl top pods -n your-namespace নিয়মিত চালান এবং যা আপনি ঘোষণা করেছেন তার বিপরীতে তুলনা করুন। বেমানান দ্রুত সঞ্চয় হয় একাধিক সেবা সহ ক্লাস্টারে।

etcd সম্পূর্ণ ক্লাস্টার, এটি সেভাবে আচরণ করুন

সবকিছু যা Kubernetes জানে তা etcd তে বাস করে। এটি হারিয়ে ফেলুন এবং আপনি আপনার ক্লাস্টার অবস্থা হারিয়ে ফেলুন, শুধুমাত্র কিছু মেটাডেটা নয়। etcdctl snapshot save /backup/etcd-snapshot.db একটি সময়সূচীতে চালান, এবং সত্যিকারের এটি একটি scratch ক্লাস্টারে কমপক্ষে একবার পুনরুদ্ধার করে পরীক্ষা করুন। আমি এমন দলগুলি দেখেছি যাদের রাতের ব্যাকআপ ছিল যা তিন মাস ধরে বিকৃত হয়ে উঠেছিল কারণ কেউ তাদের যাচাই করেনি। যদি আপনি কোনো managed control plane (EKS, GKE, AKS) এর উপর থাকেন, তাহলে আপনি সরাসরি etcd পরিচালনা করবেন না, কিন্তু আপনি এখনও আপনার প্রদানকারীর ব্যাকআপ এবং পুনরুদ্ধার গল্প জানতে পারবেন যেকোনো ঘটনার আগে, অনুপ্রবেশের সময় নয়।

Liveness এবং readiness probes কখনও কখনও একমত নয়

একটি সাধারণ ভুল হল liveness এবং readiness probes উভয় ক্ষেত্রেই একই endpoint ব্যবহার করা। Liveness উত্তর দেওয়া উচিত