Kubernetes মধ্যে লাইভনেস প্রোব বিপজ্জনক হতে পারে

বিঃদ্রঃ. অনুবাদ: জাল্যান্ডোর প্রধান প্রকৌশলী, হেনিং জ্যাকবস, লাইভনেস (এবং প্রস্তুতি) প্রোবের উদ্দেশ্য এবং তাদের সঠিক ব্যবহার বুঝতে কুবারনেটস ব্যবহারকারীদের মধ্যে বারবার সমস্যা লক্ষ্য করেছেন। অতএব, তিনি এই বিশাল নোটে তার চিন্তাভাবনা সংগ্রহ করেছেন, যা শেষ পর্যন্ত K8 এর ডকুমেন্টেশনের অংশ হয়ে উঠবে।

স্বাস্থ্য পরীক্ষা, কুবারনেটসে পরিচিত জীবন্ততা অনুসন্ধান (অর্থাৎ, আক্ষরিক অর্থে, "কার্যক্ষমতা পরীক্ষা" - প্রায় অনুবাদ), বেশ বিপজ্জনক হতে পারে। আমি যদি সম্ভব হয় তবে এগুলি এড়িয়ে যাওয়ার পরামর্শ দিই: একমাত্র ব্যতিক্রমগুলি যখন সেগুলি সত্যই প্রয়োজনীয় এবং আপনি তাদের ব্যবহারের সুনির্দিষ্ট এবং পরিণতি সম্পর্কে পুরোপুরি সচেতন। এই প্রকাশনাটি সজীবতা এবং প্রস্তুতি পরীক্ষা সম্পর্কে কথা বলবে এবং কোন ক্ষেত্রে আপনাকে তাও বলবে মূল্যবান এবং আপনার সেগুলি ব্যবহার করা উচিত নয়।

আমার সহকর্মী স্যান্ডর সম্প্রতি টুইটারে শেয়ার করেছেন যে তিনি সবচেয়ে সাধারণ ত্রুটির সম্মুখীন হয়েছেন, যার মধ্যে রয়েছে প্রস্তুতি/লাইভনেস প্রোবের ব্যবহার সম্পর্কিত:

ভুলভাবে কনফিগার করা হয়েছে livenessProbe উচ্চ-লোড পরিস্থিতি (স্নোবল শাটডাউন + সম্ভাব্য দীর্ঘ কন্টেইনার/অ্যাপ্লিকেশন শুরুর সময়) বাড়িয়ে তুলতে পারে এবং অন্যান্য নেতিবাচক পরিণতির দিকে নিয়ে যেতে পারে যেমন নির্ভরতা হ্রাস (আরো দেখুন আমার সাম্প্রতিক নিবন্ধ K3s+ACME সংমিশ্রণে অনুরোধের সংখ্যা সীমিত করার বিষয়ে). এটি আরও খারাপ যখন লাইভনেস প্রোবকে স্বাস্থ্য পরীক্ষার সাথে একত্রিত করা হয়, যা একটি বাহ্যিক ডাটাবেস: একটি একক ডিবি ব্যর্থতা আপনার সমস্ত কন্টেইনার পুনরায় চালু করবে!

সাধারণ বার্তা "লাইভনেস প্রোব ব্যবহার করবেন না" এই ক্ষেত্রে এটি খুব বেশি সাহায্য করে না, তাই আসুন দেখি প্রস্তুতি এবং সজীবতা পরীক্ষাগুলি কীসের জন্য।

দ্রষ্টব্য: নীচের বেশিরভাগ পরীক্ষা মূলত Zalando এর অভ্যন্তরীণ বিকাশকারী ডকুমেন্টেশনে অন্তর্ভুক্ত ছিল।

প্রস্তুতি এবং সজীবতা পরীক্ষা করে

কুবারনেটস নামে দুটি গুরুত্বপূর্ণ প্রক্রিয়া সরবরাহ করে লাইভনেস প্রোব এবং রেডিনেস প্রোব. তারা পর্যায়ক্রমে কিছু অ্যাকশন সঞ্চালন করে - যেমন একটি HTTP অনুরোধ পাঠানো, একটি TCP সংযোগ খোলা, বা কন্টেইনারে একটি কমান্ড কার্যকর করা - নিশ্চিত করতে যে অ্যাপ্লিকেশনটি প্রত্যাশা অনুযায়ী কাজ করছে।

কুবারনেটস ব্যবহার করে প্রস্তুতি অনুসন্ধানকন্টেইনার কখন ট্রাফিক গ্রহণের জন্য প্রস্তুত তা বোঝার জন্য। একটি পড ব্যবহারের জন্য প্রস্তুত বলে মনে করা হয় যদি এর সমস্ত পাত্র প্রস্তুত থাকে। এই পদ্ধতির একটি ব্যবহার হল কুবারনেটস পরিষেবাগুলির (এবং বিশেষ করে ইনগ্রেস) ব্যাকএন্ড হিসাবে কোন পডগুলি ব্যবহার করা হয় তা নিয়ন্ত্রণ করা।

সজীবতা অনুসন্ধান কন্টেইনার রিস্টার্ট করার সময় কখন হয়েছে তা বুঝতে কুবারনেটসকে সাহায্য করুন। উদাহরণস্বরূপ, এই ধরনের চেক আপনাকে একটি অচলাবস্থা আটকানোর অনুমতি দেয় যখন একটি অ্যাপ্লিকেশন এক জায়গায় আটকে যায়। এই অবস্থায় ধারকটি পুনরায় চালু করা ত্রুটি থাকা সত্ত্বেও অ্যাপ্লিকেশনটিকে স্থল থেকে সরাতে সাহায্য করে, তবে এটি ক্যাসকেডিং ব্যর্থতার দিকেও যেতে পারে (নীচে দেখুন)।

আপনি যদি একটি অ্যাপ্লিকেশন আপডেট স্থাপন করার চেষ্টা করেন যা লাইভনেস/প্রস্তুতি পরীক্ষায় ব্যর্থ হয় তবে কুবারনেটস স্ট্যাটাসের জন্য অপেক্ষা করার কারণে এটির রোলআউট স্থগিত হয়ে যাবে Ready সব পড থেকে।

উদাহরণ

এখানে একটি পাথ পরীক্ষা করার প্রস্তুতি অনুসন্ধানের একটি উদাহরণ /health ডিফল্ট সেটিংস সহ HTTP এর মাধ্যমে (অন্তর: 10 সেকেন্ড, সময় শেষ: 1 সেকেন্ড, সাফল্যের প্রান্তিক: 1, ব্যর্থতার থ্রেশহোল্ড:3):

# часть общего описания deployment'а/стека
podTemplate:
  spec:
    containers:
    - name: my-container
      # ...
      readinessProbe:
        httpGet:
          path: /health
          port: 8080

সুপারিশ

1. HTTP এন্ডপয়েন্ট সহ মাইক্রোসার্ভিসের জন্য (REST, ইত্যাদি) সর্বদা একটি প্রস্তুতি তদন্ত সংজ্ঞায়িত করুন, যা অ্যাপ্লিকেশন (পড) ট্র্যাফিক গ্রহণ করার জন্য প্রস্তুত কিনা তা পরীক্ষা করে।
2. প্রস্তুতি তদন্ত নিশ্চিত করুন প্রকৃত ওয়েব সার্ভার পোর্টের প্রাপ্যতা কভার করে:
   • প্রশাসনিক উদ্দেশ্যে পোর্ট ব্যবহার করে, যাকে বলা হয় "প্রশাসন" বা "ব্যবস্থাপনা" (উদাহরণস্বরূপ, 9090), জন্য readinessProbe, নিশ্চিত করুন যে প্রাথমিক HTTP পোর্ট (যেমন 8080) ট্র্যাফিক* গ্রহণ করার জন্য প্রস্তুত হলেই শেষ পয়েন্টটি ঠিক আছে;

     *আমি জাল্যান্ডোতে অন্তত একটি কেস সম্পর্কে সচেতন যেখানে এটি ঘটেনি, যেমন readinessProbe আমি "ব্যবস্থাপনা" পোর্টটি পরীক্ষা করেছি, কিন্তু ক্যাশে লোড করার সমস্যার কারণে সার্ভার নিজেই কাজ শুরু করেনি।

   • একটি পৃথক পোর্টে একটি প্রস্তুতির তদন্ত সংযুক্ত করার ফলে প্রধান বন্দরে ওভারলোড স্বাস্থ্য পরীক্ষায় প্রতিফলিত হবে না (অর্থাৎ, সার্ভারে থ্রেড পুল পূর্ণ, কিন্তু স্বাস্থ্য পরীক্ষা এখনও দেখায় যে সবকিছু ঠিক আছে। )
3. নিশ্চিত করো যে রেডিনেস প্রোব ডাটাবেস ইনিশিয়ালাইজেশন/মাইগ্রেশন সক্ষম করে;
   • এটি অর্জন করার সবচেয়ে সহজ উপায় হল শুরু করার পরেই HTTP সার্ভারের সাথে যোগাযোগ করা (উদাহরণস্বরূপ, থেকে একটি ডাটাবেস স্থানান্তর করা ফ্লাইওয়ে এবং তাই।); অর্থাৎ, স্বাস্থ্য পরীক্ষার স্থিতি পরিবর্তন করার পরিবর্তে, ডাটাবেস মাইগ্রেশন সম্পূর্ণ না হওয়া পর্যন্ত ওয়েব সার্ভার চালু করবেন না*।

     * আপনি পডের বাইরে init কন্টেইনার থেকে ডাটাবেস মাইগ্রেশনও চালাতে পারেন। আমি এখনও স্বয়ংসম্পূর্ণ অ্যাপ্লিকেশনগুলির একজন অনুরাগী, অর্থাৎ, যেগুলিতে অ্যাপ্লিকেশন কন্টেইনারটি জানে কিভাবে বহিরাগত সমন্বয় ছাড়াই ডাটাবেসটিকে পছন্দসই অবস্থায় আনতে হয়।

4. ব্যবহার httpGet সাধারণ স্বাস্থ্য পরীক্ষার শেষ পয়েন্টগুলির মাধ্যমে প্রস্তুতি পরীক্ষা করার জন্য (উদাহরণস্বরূপ, /health).
5. ডিফল্ট চেক পরামিতি বুঝুন (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
   • ডিফল্ট অপশন মানে পড হয়ে যাবে প্রস্তুত নয় প্রায় 30 সেকেন্ডের পরে (3 ব্যর্থ স্বাস্থ্য পরীক্ষা)।
6. "প্রশাসন" বা "ব্যবস্থাপনা" এর জন্য একটি পৃথক পোর্ট ব্যবহার করুন যদি প্রযুক্তি স্ট্যাক (যেমন জাভা/স্প্রিং) এটিকে অনুমতি দেয়, স্বাস্থ্য এবং মেট্রিক্স ব্যবস্থাপনাকে নিয়মিত ট্রাফিক থেকে আলাদা করতে:
   • কিন্তু পয়েন্ট 2 সম্পর্কে ভুলবেন না।
7. প্রয়োজনে, ক্যাশে গরম করতে/লোড করার জন্য রেডিনেস প্রোব ব্যবহার করা যেতে পারে এবং কন্টেইনার গরম না হওয়া পর্যন্ত একটি 503 স্ট্যাটাস কোড ফেরত দেওয়া যেতে পারে:
   • আমি আপনাকে নতুন চেক পড়ার পরামর্শ দিচ্ছি startupProbe, সংস্করণ 1.16 এ উপস্থিত হয়েছে (আমরা এটি সম্পর্কে রাশিয়ান ভাষায় লিখেছি এখানে - প্রায়. অনুবাদ।).

সাবধানতা অবলম্বন করা

1. বাহ্যিক নির্ভরতার উপর নির্ভর করবেন না (যেমন ডেটা গুদাম) প্রস্তুতি/জীবন্ত পরীক্ষা চালানোর সময় - এটি ক্যাসকেডিং ব্যর্থতার কারণ হতে পারে:
   • একটি উদাহরণ হিসাবে, আসুন একটি পোস্টগ্রেস ডাটাবেসের উপর নির্ভর করে 10টি পড সহ একটি স্টেটফুল REST পরিষেবা নেওয়া যাক: যখন চেকটি ডিবি-তে একটি কার্যকরী সংযোগের উপর নির্ভর করে, নেটওয়ার্ক/ডিবি দিকে দেরি হলে সমস্ত 10টি পড ব্যর্থ হতে পারে - সাধারণত এটি সব শেষ এটা পারে চেয়ে খারাপ;
   • অনুগ্রহ করে মনে রাখবেন স্প্রিং ডেটা ডিফল্টরূপে ডাটাবেস সংযোগ পরীক্ষা করে*;

     * এটি স্প্রিং ডেটা রেডিসের ডিফল্ট আচরণ (অন্তত এটি আমি শেষবার পরীক্ষা করেছিলাম), যা একটি "বিপর্যয়কর" ব্যর্থতার দিকে পরিচালিত করেছিল: যখন রেডিস অল্প সময়ের জন্য অনুপলব্ধ ছিল, তখন সমস্ত পড "ক্র্যাশ" হয়েছিল।

   • এই অর্থে "বহিরাগত" একই অ্যাপ্লিকেশনের অন্যান্য পডকেও বোঝাতে পারে, অর্থাৎ, আদর্শভাবে চেকটি ক্যাসকেডিং ক্র্যাশ প্রতিরোধ করতে একই ক্লাস্টারের অন্যান্য পডের অবস্থার উপর নির্ভর করবে না:
     • ডিস্ট্রিবিউটেড স্টেট সহ অ্যাপ্লিকেশনগুলির জন্য ফলাফল পরিবর্তিত হতে পারে (উদাহরণস্বরূপ, পডগুলিতে ইন-মেমরি ক্যাশিং)।
2. লাইভনেস প্রোব ব্যবহার করবেন না পডগুলির জন্য (ব্যতিক্রমগুলি এমন ক্ষেত্রে যখন সেগুলি সত্যিই প্রয়োজনীয় এবং আপনি তাদের ব্যবহারের সুনির্দিষ্ট এবং পরিণতি সম্পর্কে পুরোপুরি সচেতন):
   • একটি লাইভনেস প্রোব হ্যাং কন্টেনারগুলি পুনরুদ্ধার করতে সাহায্য করতে পারে, কিন্তু যেহেতু আপনার অ্যাপ্লিকেশনের উপর আপনার সম্পূর্ণ নিয়ন্ত্রণ আছে, তাই হ্যাং প্রসেস এবং অচলাবস্থার মতো জিনিসগুলি আদর্শভাবে ঘটবে না: সর্বোত্তম বিকল্প হল ইচ্ছাকৃতভাবে অ্যাপ্লিকেশনটিকে ক্র্যাশ করা এবং এটিকে আগের স্থির অবস্থায় ফিরিয়ে আনা;
   • একটি ব্যর্থ লাইভনেস প্রোব কন্টেইনারটিকে পুনরায় চালু করবে, যার ফলে লোডিং-সম্পর্কিত ত্রুটির পরিণতিগুলিকে আরও বাড়িয়ে দেবে: কন্টেইনারটি পুনরায় চালু করার ফলে ডাউনটাইম হবে (অন্তত অ্যাপ্লিকেশন শুরুর সময়কালের জন্য, বলুন 30-বিজোড় সেকেন্ড), নতুন ত্রুটি সৃষ্টি করবে , অন্যান্য পাত্রে লোড বৃদ্ধি এবং তাদের ব্যর্থতার সম্ভাবনা বৃদ্ধি, ইত্যাদি;
   • বাহ্যিক নির্ভরতার সাথে মিলিত সজীবতা পরীক্ষাগুলি হল সবচেয়ে খারাপ সম্ভাব্য সংমিশ্রণ, ক্যাসকেডিং ব্যর্থতার হুমকি: ডাটাবেসের দিকে সামান্য বিলম্ব আপনার সমস্ত কন্টেইনার পুনরায় চালু করবে!
3. সজীবতা এবং প্রস্তুতি পরীক্ষা করার পরামিতি ভিন্ন হতে হবে:
   • আপনি একই স্বাস্থ্য পরীক্ষা সহ একটি লাইভনেস প্রোব ব্যবহার করতে পারেন, তবে একটি উচ্চতর প্রতিক্রিয়া থ্রেশহোল্ড (failureThreshold), উদাহরণস্বরূপ, স্থিতি বরাদ্দ করুন প্রস্তুত নয় 3টি প্রচেষ্টার পরে এবং বিবেচনা করুন যে 10টি প্রচেষ্টার পরে জীবন্ততা অনুসন্ধান ব্যর্থ হয়েছে;
4. exec চেক ব্যবহার করবেন না, যেহেতু তারা পরিচিত সমস্যার সাথে যুক্ত যা জম্বি প্রক্রিয়াগুলির উপস্থিতির দিকে পরিচালিত করে:
   • বিস্তারিত: দেখুন ডেটাডগ বিশেষজ্ঞদের দ্বারা উপস্থাপনা.

সারাংশ

• একটি পড কখন ট্র্যাফিক পাওয়ার জন্য প্রস্তুত তা নির্ধারণ করতে প্রস্তুতি প্রোব ব্যবহার করুন।
• লাইভনেস প্রোব ব্যবহার করুন শুধুমাত্র যখন তাদের সত্যিই প্রয়োজন হয়।
• প্রস্তুতি/লাইভনেস প্রোবের অনুপযুক্ত ব্যবহার প্রাপ্যতা হ্রাস এবং ক্যাসকেডিং ব্যর্থতার দিকে পরিচালিত করতে পারে।

বিষয়ে অতিরিক্ত উপকরণ

• কুবারনেটস ডক্স: লাইভনেস এবং রেডিনেস প্রোব কনফিগার করুন;
• কুবারনেটস লাইভনেস এবং রেডিনেস প্রোবগুলি পুনরালোচিত হয়েছে: কীভাবে অন্য পায়ে নিজেকে গুলি করা এড়ানো যায়;
• এনআরই ল্যাবস বিভ্রাট পোস্ট-মর্টেম (তিনি livenessProbe সম্পর্কেও কথা বলেন)।

1-2019-09 থেকে আপডেট নং 29

ডাটাবেস মাইগ্রেশনের জন্য init কন্টেনার সম্পর্কে: পাদটীকা যোগ করা হয়েছে।

ইজে আমাকে মনে করিয়ে দিল PDB সম্পর্কে: জীবন্ততা যাচাইয়ের সমস্যাগুলির মধ্যে একটি হল পডগুলির মধ্যে সমন্বয়ের অভাব। কুবারনেটস আছে পড ডিসপ্রেশন বাজেট (PDB) সমসাময়িক ব্যর্থতার সংখ্যা সীমিত করতে একটি অ্যাপ্লিকেশন অনুভব করতে পারে, তবে চেকগুলি পিডিবিকে বিবেচনায় নেয় না। আদর্শভাবে, আমরা K8s কে বলতে পারি "একটি পড পুনরায় চালু করতে যদি এটির পরীক্ষা ব্যর্থ হয়, তবে জিনিসগুলিকে আরও খারাপ না করার জন্য সেগুলিকে পুনরায় চালু করবেন না।"

ব্রায়ান এটি নিখুঁতভাবে রেখেছেন: “যখন আপনি ঠিক কি জানেন তখন জীবন্ততা অনুসন্ধান ব্যবহার করুন সবচেয়ে ভালো কাজ হল অ্যাপ্লিকেশনটিকে মেরে ফেলা"(আবার, দূরে নিয়ে যাবেন না)।

2-2019-09 থেকে আপডেট নং 29

ব্যবহারের আগে ডকুমেন্টেশন পড়া সংক্রান্ত: আমি সংশ্লিষ্ট অনুরোধ তৈরি করেছি (বৈশিষ্ট্য অনুরোধ) জীবন্ততা অনুসন্ধান সম্পর্কে ডকুমেন্টেশন যোগ করতে।

অনুবাদক থেকে PS

আমাদের ব্লগেও পড়ুন:

• «কুবারনেটস: পড লাইফ";
• «Google-এর 7টি কন্টেইনার সেরা অভ্যাস";
• «কনটেইনার-ভিত্তিক অ্যাপ্লিকেশন ডিজাইন করার জন্য 7 নীতি».

উত্স: www.habr.com