কুবারনেট কন্টেইনারগুলির জন্য সর্বোত্তম অনুশীলন: স্বাস্থ্য পরীক্ষা

TL; ডিআর

• কন্টেইনার এবং মাইক্রোসার্ভিসের উচ্চ পর্যবেক্ষণযোগ্যতা অর্জনের জন্য, লগ এবং প্রাথমিক মেট্রিক্স যথেষ্ট নয়।
• দ্রুত পুনরুদ্ধার এবং বর্ধিত স্থিতিস্থাপকতার জন্য, অ্যাপ্লিকেশনগুলিকে উচ্চ পর্যবেক্ষণের নীতি (HOP) প্রয়োগ করা উচিত।
• অ্যাপ্লিকেশন স্তরে, NOP-এর প্রয়োজন: সঠিক লগিং, নিবিড় পর্যবেক্ষণ, স্যানিটী চেক এবং কর্মক্ষমতা/ট্রানজিশন ট্রেসিং।
• NOR এর একটি উপাদান হিসাবে চেক ব্যবহার করুন প্রস্তুতিপ্রবণ и লাইভনেস প্রোব কুবারনেটস।

একটি স্বাস্থ্য পরীক্ষা টেমপ্লেট কি?

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

উচ্চ পর্যবেক্ষণের নীতি (HOP)

উচ্চ পর্যবেক্ষণের নীতি হল একটি কন্টেইনারাইজড অ্যাপ্লিকেশন ডিজাইন করার নীতি. একটি মাইক্রোসার্ভিসেস আর্কিটেকচারে, পরিষেবাগুলি তাদের অনুরোধ কীভাবে প্রক্রিয়া করা হয় তা বিবেচনা করে না (এবং সঠিকভাবে তাই), তবে কী গুরুত্বপূর্ণ তা হল তারা প্রাপ্ত পরিষেবাগুলি থেকে কীভাবে প্রতিক্রিয়া পায়৷ উদাহরণস্বরূপ, একজন ব্যবহারকারীকে প্রমাণীকরণ করার জন্য, একটি ধারক অন্যকে একটি HTTP অনুরোধ পাঠায়, একটি নির্দিষ্ট বিন্যাসে একটি প্রতিক্রিয়া আশা করে - এটাই সব। PythonJS এছাড়াও অনুরোধ প্রক্রিয়া করতে পারে, এবং Python Flask সাড়া দিতে পারে। কনটেইনারগুলি একে অপরের কাছে লুকানো বিষয়বস্তু সহ কালো বাক্সের মতো। যাইহোক, NOP নীতির জন্য প্রতিটি পরিষেবাকে একাধিক API এন্ডপয়েন্ট প্রকাশ করতে হবে যা নির্দেশ করে যে এটি কতটা স্বাস্থ্যকর, সেইসাথে এর প্রস্তুতি এবং ত্রুটি সহনশীলতার অবস্থা। কুবারনেটস রাউটিং এবং লোড ব্যালেন্সিংয়ের জন্য পরবর্তী ধাপগুলি চিন্তা করার জন্য এই সূচকগুলিকে অনুরোধ করে।

একটি ভাল ডিজাইন করা ক্লাউড অ্যাপ্লিকেশন স্ট্যান্ডার্ড I/O স্ট্রীম STDERR এবং STDOUT ব্যবহার করে তার প্রধান ইভেন্টগুলি লগ করে। এরপরে একটি সহায়ক পরিষেবা আসে, উদাহরণস্বরূপ ফাইলবিট, লগস্ট্যাশ বা সাবলীল, একটি কেন্দ্রীভূত মনিটরিং সিস্টেমে (উদাহরণস্বরূপ প্রমিথিউস) এবং একটি লগ সংগ্রহের সিস্টেম (ELK সফ্টওয়্যার স্যুট) লগ সরবরাহ করে। নীচের চিত্রটি দেখায় যে কীভাবে একটি ক্লাউড অ্যাপ্লিকেশন স্বাস্থ্য পরীক্ষার প্যাটার্ন এবং উচ্চ পর্যবেক্ষণের নীতি অনুসারে কাজ করে।

কুবারনেটে স্বাস্থ্য পরীক্ষার প্যাটার্ন কীভাবে প্রয়োগ করবেন?

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

আমাদের উদাহরণে, k8s করে কার্যকারিতা পরীক্ষা. এই ধরনের যাচাইকরণে, কুবেলেট ক্রমাগত পাত্রে প্রক্রিয়াটির অবস্থা পরীক্ষা করে। একবার তিনি বুঝতে পারেন যে প্রক্রিয়াটি বন্ধ হয়ে গেছে, তিনি এটি পুনরায় চালু করবেন। যদি কেবলমাত্র অ্যাপ্লিকেশনটি পুনরায় চালু করার মাধ্যমে ত্রুটিটি সমাধান করা যায়, এবং প্রোগ্রামটি যে কোনও ত্রুটির জন্য বন্ধ করার জন্য ডিজাইন করা হয়েছে, তাহলে NOP এবং স্বাস্থ্য পরীক্ষার প্যাটার্ন অনুসরণ করার জন্য আপনাকে একটি প্রক্রিয়া স্বাস্থ্য পরীক্ষা করতে হবে। একমাত্র দুঃখের বিষয় হল যে সমস্ত ত্রুটি পুনরায় চালু করার মাধ্যমে মুছে ফেলা হয় না। এই ক্ষেত্রে, k8s পডের সমস্যা চিহ্নিত করার জন্য 2টি গভীর উপায় অফার করে: লাইভনেস প্রোব и প্রস্তুতিপ্রবণ.

লাইভনেস প্রোব

সময় লাইভনেস প্রোব কুবেলেট 3 ধরনের পরীক্ষা করে: শুধুমাত্র পড চলছে কিনা তা নির্ধারণ করে না, তবে এটি অনুরোধগুলি গ্রহণ করতে এবং পর্যাপ্তভাবে প্রতিক্রিয়া জানাতে প্রস্তুত কিনা তাও:

• পডে একটি HTTP অনুরোধ সেট আপ করুন। প্রতিক্রিয়াটিতে 200 থেকে 399 এর মধ্যে একটি HTTP প্রতিক্রিয়া কোড থাকতে হবে। এইভাবে, 5xx এবং 4xx কোডগুলি নির্দেশ করে যে পডের সমস্যা হচ্ছে, এমনকি প্রক্রিয়াটি চলমান থাকলেও।
• নন-HTTP পরিষেবাগুলির সাথে পড পরীক্ষা করতে (উদাহরণস্বরূপ, পোস্টফিক্স মেল সার্ভার), আপনাকে একটি TCP সংযোগ স্থাপন করতে হবে।
• একটি পডের (অভ্যন্তরীণভাবে) জন্য একটি নির্বিচারী কমান্ড চালান। কমান্ড কমপ্লিশন কোড 0 হলে চেকটি সফল বলে বিবেচিত হয়।

এই কাজ কিভাবে একটি উদাহরণ. পরবর্তী পড সংজ্ঞাটিতে একটি NodeJS অ্যাপ্লিকেশন রয়েছে যা HTTP অনুরোধে একটি 500 ত্রুটি নিক্ষেপ করে৷ এই ধরনের ত্রুটি পাওয়ার সময় কন্টেইনারটি পুনরায় চালু হয়েছে তা নিশ্চিত করতে, আমরা livenessProbe প্যারামিটার ব্যবহার করি:

apiVersion: v1
kind: Pod
metadata:
 name: node500
spec:
 containers:
   - image: magalix/node500
     name: node500
     ports:
       - containerPort: 3000
         protocol: TCP
     livenessProbe:
       httpGet:
         path: /
         port: 3000
       initialDelaySeconds: 5

এটি অন্য কোনো পড সংজ্ঞা থেকে ভিন্ন নয়, কিন্তু আমরা একটি বস্তু যোগ করি .spec.containers.livenessProbe. প্যারামিটার httpGet যে পথে HTTP GET অনুরোধ পাঠানো হয়েছে তা গ্রহণ করে (আমাদের উদাহরণে এটি /, কিন্তু যুদ্ধের পরিস্থিতিতে এরকম কিছু হতে পারে /api/v1/status) আরেকটি livenessProbe একটি প্যারামিটার গ্রহণ করে initialDelaySeconds, যা যাচাইকরণ অপারেশনকে একটি নির্দিষ্ট সংখ্যক সেকেন্ড অপেক্ষা করার নির্দেশ দেয়। বিলম্বের প্রয়োজন কারণ কন্টেইনারটি শুরু করার জন্য সময় প্রয়োজন এবং পুনরায় চালু হলে এটি কিছু সময়ের জন্য অনুপলব্ধ হবে৷

একটি ক্লাস্টারে এই সেটিং প্রয়োগ করতে, ব্যবহার করুন:

kubectl apply -f pod.yaml

কয়েক সেকেন্ড পরে, আপনি নিম্নলিখিত কমান্ড ব্যবহার করে পডের বিষয়বস্তু পরীক্ষা করতে পারেন:

kubectl describe pods node500

আউটপুট শেষে, খুঁজুন তাতে কি.

আপনি দেখতে পাচ্ছেন, livenessProbe একটি HTTP GET অনুরোধ শুরু করেছে, ধারকটি একটি ত্রুটি 500 তৈরি করেছে (যা এটি করার জন্য প্রোগ্রাম করা হয়েছিল), এবং কুবেলেট এটি পুনরায় চালু করেছে।

আপনি যদি ভাবছেন যে কীভাবে NideJS অ্যাপ্লিকেশনটি প্রোগ্রাম করা হয়েছিল, এখানে app.js এবং Dockerfile ব্যবহার করা হয়েছিল:

app.js

var http = require('http');

var server = http.createServer(function(req, res) {
    res.writeHead(500, { "Content-type": "text/plain" });
    res.end("We have run into an errorn");
});

server.listen(3000, function() {
    console.log('Server is running at 3000')
})

Dockerfile

FROM node
COPY app.js /
EXPOSE 3000
ENTRYPOINT [ "node","/app.js" ]

এটি লক্ষ্য করা গুরুত্বপূর্ণ: livenessProbe শুধুমাত্র ধারকটি পুনরায় চালু করবে যদি এটি ব্যর্থ হয়। যদি পুনঃসূচনা ত্রুটিটি সংশোধন না করে যা কন্টেইনারটিকে চলতে বাধা দিচ্ছে, কুবেলেট সমস্যাটি সংশোধন করতে পদক্ষেপ নিতে সক্ষম হবে না।

প্রস্তুতিপ্রবণ

ReadinessProbe একইভাবে কাজ করে livenessProbes (GET অনুরোধ, TCP কমিউনিকেশন এবং কমান্ড এক্সিকিউশন), সমস্যা সমাধানের ক্রিয়া ছাড়া। যে ধারকটিতে ব্যর্থতা সনাক্ত করা হয়েছে সেটি পুনরায় চালু করা হয় না, তবে আগত ট্রাফিক থেকে বিচ্ছিন্ন হয়। কল্পনা করুন যে কন্টেইনারগুলির মধ্যে একটি অনেকগুলি গণনা করছে বা ভারী বোঝার মধ্যে রয়েছে, যার ফলে প্রতিক্রিয়ার সময় বৃদ্ধি পাচ্ছে। লাইভনেসপ্রোবের ক্ষেত্রে, প্রতিক্রিয়া প্রাপ্যতা পরীক্ষাটি ট্রিগার করা হয় (টাইমআউট সেকেন্ড চেক প্যারামিটারের মাধ্যমে), যার পরে কুবেলেট ধারকটি পুনরায় চালু করে। শুরু হলে, ধারকটি সম্পদ-নিবিড় কাজগুলি করতে শুরু করে এবং আবার পুনরায় চালু করা হয়। এটি এমন অ্যাপ্লিকেশনগুলির জন্য গুরুত্বপূর্ণ হতে পারে যেগুলির প্রতিক্রিয়া গতির প্রয়োজন৷ উদাহরণস্বরূপ, রাস্তায় থাকাকালীন একটি গাড়ি সার্ভার থেকে প্রতিক্রিয়ার জন্য অপেক্ষা করছে, প্রতিক্রিয়া আসতে দেরি হয় - এবং গাড়িটি দুর্ঘটনায় পড়ে।

আসুন একটি রেডিনেসপ্রোব সংজ্ঞা লিখি যা GET অনুরোধের প্রতিক্রিয়া সময়কে দুই সেকেন্ডের বেশি সেট করবে না এবং অ্যাপ্লিকেশনটি 5 সেকেন্ড পরে GET অনুরোধের প্রতিক্রিয়া জানাবে। pod.yaml ফাইলটি এইরকম হওয়া উচিত:

apiVersion: v1
kind: Pod
metadata:
 name: nodedelayed
spec:
 containers:
   - image: afakharany/node_delayed
     name: nodedelayed
     ports:
       - containerPort: 3000
         protocol: TCP
     readinessProbe:
       httpGet:
         path: /
         port: 3000
       timeoutSeconds: 2

আসুন kubectl এর সাথে একটি পড স্থাপন করি:

kubectl apply -f pod.yaml

আসুন কয়েক সেকেন্ড অপেক্ষা করি এবং তারপরে দেখুন কিভাবে প্রস্তুতিপ্রবণ কাজ করেছে:

kubectl describe pods nodedelayed

আউটপুট শেষে আপনি দেখতে পারেন যে কিছু ঘটনা একই রকম এইটা.

আপনি দেখতে পাচ্ছেন, চেকের সময় 2 সেকেন্ড অতিক্রম করলে কুবেক্টল পডটি পুনরায় চালু করেনি। পরিবর্তে, তিনি অনুরোধ বাতিল করেছেন। ইনকামিং কমিউনিকেশনগুলি অন্য, কাজের পডগুলিতে পুনঃনির্দেশিত হয়।

মনে রাখবেন যে এখন পডটি অফলোড করা হয়েছে, kubectl এটিতে আবার অনুরোধ করে: GET অনুরোধের প্রতিক্রিয়া আর বিলম্বিত হয় না।

তুলনা করার জন্য, নীচে পরিবর্তিত app.js ফাইল আছে:

var http = require('http');

var server = http.createServer(function(req, res) {
   const sleep = (milliseconds) => {
       return new Promise(resolve => setTimeout(resolve, milliseconds))
   }
   sleep(5000).then(() => {
       res.writeHead(200, { "Content-type": "text/plain" });
       res.end("Hellon");
   })
});

server.listen(3000, function() {
   console.log('Server is running at 3000')
})

TL; ডিআর
ক্লাউড অ্যাপ্লিকেশনের আবির্ভাবের আগে, লগগুলি ছিল অ্যাপ্লিকেশনের স্বাস্থ্য পর্যবেক্ষণ এবং পরীক্ষা করার প্রাথমিক মাধ্যম। তবে কোনো সংশোধনমূলক ব্যবস্থা নেওয়ার উপায় ছিল না। লগগুলি আজও কার্যকর; জরুরী পরিস্থিতি বিশ্লেষণ এবং সিদ্ধান্ত নেওয়ার জন্য সেগুলি সংগ্রহ করে একটি লগ সংগ্রহ সিস্টেমে প্রেরণ করা দরকার। [এই সবই মনিট ব্যবহার করে ক্লাউড অ্যাপ্লিকেশন ছাড়াই করা যেতে পারে, উদাহরণস্বরূপ, কিন্তু k8s এর সাথে এটি অনেক সহজ হয়ে গেছে :) - সম্পাদকের নোট। ]

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

Kubernetes ডিফল্টরূপে 2 ধরনের স্বাস্থ্য পরীক্ষা অফার করে: ReadinessProbe এবং livenessProbe। উভয়ই একই ধরণের চেক ব্যবহার করে (HTTP GET অনুরোধ, TCP যোগাযোগ এবং কমান্ড এক্সিকিউশন)। পডের সমস্যাগুলির প্রতিক্রিয়া হিসাবে তারা কী সিদ্ধান্ত নেয় তাতে তাদের পার্থক্য রয়েছে। livenessProbe কন্টেইনারটিকে পুনরায় আরম্ভ করে এই আশায় যে ত্রুটিটি আর ঘটবে না, এবং readinessProbe সমস্যাটির কারণ সমাধান না হওয়া পর্যন্ত ইনকামিং ট্র্যাফিক থেকে পডটিকে বিচ্ছিন্ন করে।

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

উত্স: www.habr.com