Kubernetes-এ দীর্ঘস্থায়ী সংযোগ লোড ব্যালেন্সিং এবং স্কেলিং

এই নিবন্ধটি আপনাকে বুঝতে সাহায্য করবে কিভাবে Kubernetes-এ লোড ব্যালেন্সিং কাজ করে, দীর্ঘস্থায়ী সংযোগগুলি স্কেল করার সময় কী ঘটে এবং আপনি যদি HTTP/2, gRPC, RSockets, AMQP, বা অন্যান্য দীর্ঘস্থায়ী প্রোটোকল ব্যবহার করেন তবে কেন আপনার ক্লায়েন্ট-সাইড ব্যালেন্সিং বিবেচনা করা উচিত। . 

কুবারনেটসে কীভাবে ট্রাফিক পুনরায় বিতরণ করা হয় সে সম্পর্কে একটু 

Kubernetes অ্যাপ্লিকেশন স্থাপনের জন্য দুটি সুবিধাজনক বিমূর্ততা প্রদান করে: পরিষেবা এবং স্থাপনা।

স্থাপনাগুলি বর্ণনা করে যে কোনও নির্দিষ্ট সময়ে আপনার আবেদনের কতগুলি কপি চলমান থাকবে। প্রতিটি অ্যাপ্লিকেশন একটি পড হিসাবে স্থাপন করা হয় এবং একটি IP ঠিকানা বরাদ্দ করা হয়.

পরিষেবাগুলি একটি লোড ব্যালেন্সারের ফাংশনে অনুরূপ। তারা একাধিক পড জুড়ে ট্রাফিক বিতরণ করার জন্য ডিজাইন করা হয়েছে.

দেখা যাক কেমন লাগে.

1. নীচের চিত্রে আপনি একই অ্যাপ্লিকেশনের তিনটি উদাহরণ এবং একটি লোড ব্যালেন্সার দেখতে পারেন:

   

2. লোড ব্যালেন্সারকে একটি পরিষেবা বলা হয় এবং একটি আইপি ঠিকানা বরাদ্দ করা হয়। যেকোন আগত অনুরোধ পডগুলির একটিতে পুনঃনির্দেশিত হয়:

   

3. স্থাপনার দৃশ্যকল্প অ্যাপ্লিকেশনের দৃষ্টান্তের সংখ্যা নির্ধারণ করে। আপনাকে প্রায় কখনই সরাসরি এর অধীনে প্রসারিত করতে হবে না:

   

4. প্রতিটি পডের নিজস্ব আইপি ঠিকানা বরাদ্দ করা হয়:

   

পরিষেবাগুলিকে IP ঠিকানাগুলির একটি সংগ্রহ হিসাবে বিবেচনা করা দরকারী৷ প্রতিবার আপনি পরিষেবাটি অ্যাক্সেস করার সময়, তালিকা থেকে একটি আইপি ঠিকানা নির্বাচন করা হয় এবং গন্তব্য ঠিকানা হিসাবে ব্যবহৃত হয়।

এটা এই মত দেখায়.

1. একটি কার্ল 10.96.45.152 অনুরোধ পরিষেবাটিতে গৃহীত হয়েছে:

   

2. পরিষেবাটি গন্তব্য হিসাবে তিনটি পড ঠিকানার মধ্যে একটি নির্বাচন করে:

   

3. ট্রাফিক একটি নির্দিষ্ট পডে পুনঃনির্দেশিত হয়:

   

যদি আপনার অ্যাপ্লিকেশনটিতে একটি ফ্রন্টএন্ড এবং একটি ব্যাকএন্ড থাকে, তাহলে আপনার প্রতিটির জন্য একটি পরিষেবা এবং একটি স্থাপনা উভয়ই থাকবে৷

যখন ফ্রন্টএন্ড ব্যাকএন্ডকে অনুরোধ করে, তখন ব্যাকএন্ডটি ঠিক কতগুলি পড পরিবেশন করে তা জানার প্রয়োজন নেই: এক, দশ বা একশো হতে পারে।

এছাড়াও, ফ্রন্টএন্ড ব্যাকএন্ড পরিবেশন করা পডগুলির ঠিকানা সম্পর্কে কিছুই জানে না।

যখন ফ্রন্টএন্ড ব্যাকএন্ডে একটি অনুরোধ করে, তখন এটি ব্যাকএন্ড পরিষেবার আইপি ঠিকানা ব্যবহার করে, যা পরিবর্তন হয় না।

এখানে কিভাবে এটি দেখায়:.

1. অধীনে 1 অভ্যন্তরীণ ব্যাকএন্ড উপাদান অনুরোধ. ব্যাকএন্ডের জন্য একটি নির্দিষ্ট নির্বাচন করার পরিবর্তে, এটি পরিষেবাটির কাছে একটি অনুরোধ করে:

   

2. পরিষেবাটি গন্তব্য ঠিকানা হিসাবে ব্যাকএন্ড পডগুলির মধ্যে একটি নির্বাচন করে:

   

3. ট্র্যাফিক পড 1 থেকে পড 5 পর্যন্ত যায়, পরিষেবা দ্বারা নির্বাচিত:

   

4. আন্ডার 1 জানে না ঠিক কতগুলি পড যেমন 5 এর নীচে পরিষেবার পিছনে লুকিয়ে আছে:

   

কিন্তু সেবা ঠিক কিভাবে অনুরোধ বিতরণ করে? মনে হচ্ছে রাউন্ড-রবিন ব্যালেন্সিং ব্যবহার করা হয়? আসুন এটা বের করা যাক। 

Kubernetes পরিষেবাগুলিতে ভারসাম্য বজায় রাখা

Kubernetes পরিষেবা বিদ্যমান নেই. একটি IP ঠিকানা এবং পোর্ট বরাদ্দ করা হয় যে পরিষেবার জন্য কোন প্রক্রিয়া নেই.

আপনি ক্লাস্টারের যেকোনো নোডে লগইন করে এবং netstat -ntlp কমান্ড চালিয়ে এটি যাচাই করতে পারেন।

এমনকি আপনি পরিষেবাতে বরাদ্দ করা IP ঠিকানাটিও খুঁজে পাবেন না।

পরিষেবার আইপি ঠিকানাটি নিয়ন্ত্রণ স্তরে, কন্ট্রোলারে অবস্থিত এবং ডাটাবেসে রেকর্ড করা হয় - etcd. একই ঠিকানা অন্য উপাদান দ্বারা ব্যবহৃত হয় - kube-প্রক্সি।
Kube-proxy সমস্ত পরিষেবার জন্য IP ঠিকানাগুলির একটি তালিকা পায় এবং ক্লাস্টারের প্রতিটি নোডে iptables নিয়মগুলির একটি সেট তৈরি করে।

এই নিয়মগুলি বলে: "যদি আমরা পরিষেবাটির আইপি ঠিকানা দেখতে পাই, তাহলে আমাদের অনুরোধের গন্তব্য ঠিকানাটি সংশোধন করতে হবে এবং এটি একটি পডে পাঠাতে হবে।"

পরিষেবা IP ঠিকানা শুধুমাত্র একটি এন্ট্রি পয়েন্ট হিসাবে ব্যবহার করা হয় এবং সেই IP ঠিকানা এবং পোর্ট শোনার কোনো প্রক্রিয়া দ্বারা পরিবেশিত হয় না।

চলুন এটি তাকান. 

1. তিনটি নোডের একটি ক্লাস্টার বিবেচনা করুন। প্রতিটি নোডে পড আছে:

   

2. বাঁধা শুঁটি আঁকা বেইজ পরিষেবার অংশ। যেহেতু পরিষেবাটি একটি প্রক্রিয়া হিসাবে বিদ্যমান নেই, এটি ধূসর রঙে দেখানো হয়েছে:

   

3. প্রথম পডটি একটি পরিষেবার জন্য অনুরোধ করে এবং সংশ্লিষ্ট পডগুলির একটিতে যেতে হবে:

   

4. কিন্তু সেবা নেই, প্রক্রিয়া নেই। এটা কিভাবে কাজ করে?

   

5. অনুরোধটি নোড ছেড়ে যাওয়ার আগে, এটি iptables নিয়মগুলির মধ্য দিয়ে যায়:

   

6. iptables নিয়মগুলি জানে যে পরিষেবাটি বিদ্যমান নেই এবং সেই পরিষেবাটির সাথে যুক্ত পডগুলির IP ঠিকানাগুলির একটি দিয়ে তার IP ঠিকানাটি প্রতিস্থাপন করুন:

   

7. অনুরোধটি গন্তব্য ঠিকানা হিসাবে একটি বৈধ IP ঠিকানা পায় এবং সাধারণত প্রক্রিয়া করা হয়:

   

8. নেটওয়ার্ক টপোলজির উপর নির্ভর করে, অনুরোধটি শেষ পর্যন্ত পডে পৌঁছায়:

   

iptables কি ব্যালেন্স লোড করতে পারে?

না, iptables ফিল্টারিংয়ের জন্য ব্যবহৃত হয় এবং ভারসাম্য বজায় রাখার জন্য ডিজাইন করা হয়নি।

যাইহোক, এটি একটি সেট নিয়ম মত কাজ করে লেখা সম্ভব ছদ্ম-ব্যালেন্সার.

এবং এটি কুবারনেটসে বাস্তবায়িত হয়।

আপনার তিনটি পড থাকলে, কুবে-প্রক্সি নিম্নলিখিত নিয়মগুলি লিখবে:

1. 33% সম্ভাবনা সহ প্রথম সাবটি নির্বাচন করুন, অন্যথায় পরবর্তী নিয়মে যান।
2. 50% সম্ভাবনা সহ দ্বিতীয়টি বেছে নিন, অন্যথায় পরবর্তী নিয়মে যান।
3. অধীনে তৃতীয় নির্বাচন করুন.

এই সিস্টেমের ফলে প্রতিটি পড 33% সম্ভাব্যতার সাথে নির্বাচন করা হয়।

এবং পড 2 এর পরে পড 1 বেছে নেওয়া হবে এমন কোনও গ্যারান্টি নেই।

মন্তব্য: iptables এলোমেলো বিতরণ সহ একটি পরিসংখ্যান মডিউল ব্যবহার করে। সুতরাং, ব্যালেন্সিং অ্যালগরিদম এলোমেলো নির্বাচনের উপর ভিত্তি করে।

এখন যেহেতু আপনি বুঝতে পেরেছেন যে পরিষেবাগুলি কীভাবে কাজ করে, আসুন আরও আকর্ষণীয় পরিষেবা পরিস্থিতি দেখি৷

কুবারনেটে দীর্ঘস্থায়ী সংযোগগুলি ডিফল্টরূপে স্কেল করে না

ফ্রন্টএন্ড থেকে ব্যাকএন্ড পর্যন্ত প্রতিটি HTTP অনুরোধ একটি পৃথক TCP সংযোগ দ্বারা পরিবেশিত হয়, যা খোলা এবং বন্ধ করা হয়।

যদি ফ্রন্টএন্ড ব্যাকএন্ডে প্রতি সেকেন্ডে 100টি অনুরোধ পাঠায়, তাহলে 100টি ভিন্ন TCP সংযোগ খোলা এবং বন্ধ করা হয়।

আপনি একটি TCP সংযোগ খুলে এবং পরবর্তী সমস্ত HTTP অনুরোধের জন্য এটি ব্যবহার করে অনুরোধ প্রক্রিয়াকরণের সময় এবং লোড কমাতে পারেন।

এইচটিটিপি প্রোটোকলের একটি বৈশিষ্ট্য রয়েছে যার নাম HTTP কিপ-লাইভ, বা সংযোগ পুনঃব্যবহার। এই ক্ষেত্রে, একাধিক HTTP অনুরোধ এবং প্রতিক্রিয়া পাঠাতে এবং গ্রহণ করতে একটি একক TCP সংযোগ ব্যবহার করা হয়:

এই বৈশিষ্ট্যটি ডিফল্টরূপে সক্রিয় করা হয় না: সার্ভার এবং ক্লায়েন্ট উভয়কেই সেই অনুযায়ী কনফিগার করতে হবে।

বেশিরভাগ প্রোগ্রামিং ভাষা এবং পরিবেশের জন্য সেটআপ নিজেই সহজ এবং অ্যাক্সেসযোগ্য।

এখানে বিভিন্ন ভাষায় উদাহরণের কিছু লিঙ্ক রয়েছে:

• Node.js-এ জীবিত রাখুন
• বসন্ত বুটে জীবিত রাখুন
• পাইথনে জীবিত রাখুন
• .NET-এ জীবিত রাখুন

কুবারনেটস পরিষেবায় আমরা কিপ-অ্যালাইভ ব্যবহার করলে কী হবে?
ধরা যাক যে ফ্রন্টএন্ড এবং ব্যাকএন্ড উভয় সমর্থনই বেঁচে থাকে।

আমাদের সামনে ফ্রন্টএন্ডের একটি কপি এবং ব্যাকএন্ডের তিনটি কপি রয়েছে। ফ্রন্টএন্ড প্রথম অনুরোধ করে এবং ব্যাকএন্ডে একটি TCP সংযোগ খোলে। অনুরোধটি পরিষেবাতে পৌঁছায়, ব্যাকএন্ড পডগুলির মধ্যে একটি গন্তব্য ঠিকানা হিসাবে নির্বাচিত হয়। ব্যাকএন্ড একটি প্রতিক্রিয়া পাঠায়, এবং ফ্রন্টএন্ড এটি গ্রহণ করে।

সাধারণ পরিস্থিতির বিপরীতে যেখানে প্রতিক্রিয়া পাওয়ার পরে TCP সংযোগ বন্ধ হয়ে যায়, এটি এখন আরও HTTP অনুরোধের জন্য খোলা রাখা হয়।

ফ্রন্টএন্ড ব্যাকএন্ডে আরও অনুরোধ পাঠালে কী হবে?

এই অনুরোধগুলি ফরোয়ার্ড করার জন্য, একটি খোলা TCP সংযোগ ব্যবহার করা হবে, সমস্ত অনুরোধ একই ব্যাকএন্ডে যাবে যেখানে প্রথম অনুরোধটি গিয়েছিল।

iptables ট্র্যাফিক পুনরায় বিতরণ করা উচিত নয়?

এ ক্ষেত্রে নয়।

যখন একটি TCP সংযোগ তৈরি করা হয়, এটি iptables নিয়মের মধ্য দিয়ে যায়, যা একটি নির্দিষ্ট ব্যাকএন্ড নির্বাচন করে যেখানে ট্রাফিক যাবে।

যেহেতু সমস্ত পরবর্তী অনুরোধগুলি ইতিমধ্যেই খোলা TCP সংযোগে রয়েছে, তাই iptables নিয়মগুলি আর বলা হয় না।

দেখা যাক কেমন লাগে.

1. প্রথম পড পরিষেবাটিতে একটি অনুরোধ পাঠায়:

   

2. আপনি ইতিমধ্যে জানেন পরবর্তী কি হবে. পরিষেবাটি বিদ্যমান নেই, তবে iptables নিয়ম রয়েছে যা অনুরোধটি প্রক্রিয়া করবে:

   

3. ব্যাকএন্ড পডগুলির মধ্যে একটি গন্তব্য ঠিকানা হিসাবে নির্বাচন করা হবে:

   

4. অনুরোধ পোদের কাছে পৌঁছে যায়। এই মুহুর্তে, দুটি পডের মধ্যে একটি স্থায়ী TCP সংযোগ স্থাপন করা হবে:

   

5. প্রথম পড থেকে পরবর্তী যেকোনো অনুরোধ ইতিমধ্যেই প্রতিষ্ঠিত সংযোগের মাধ্যমে যাবে:

   

ফলাফল হল দ্রুত প্রতিক্রিয়া সময় এবং উচ্চতর থ্রুপুট, কিন্তু আপনি ব্যাকএন্ড স্কেল করার ক্ষমতা হারাবেন।

এমনকি যদি আপনার ব্যাকএন্ডে দুটি পড থাকে, একটি ধ্রুবক সংযোগ সহ, ট্র্যাফিক সবসময় তাদের একটিতে যাবে।

এটা কি ঠিক করা যাবে?

যেহেতু কুবারনেটস অবিরাম সংযোগগুলিকে ভারসাম্য বজায় রাখতে জানেন না, তাই এই কাজটি আপনার হাতে পড়ে৷

পরিষেবাগুলি হল আইপি ঠিকানা এবং পোর্টগুলির একটি সংগ্রহ যাকে শেষ পয়েন্ট বলে।

আপনার অ্যাপ্লিকেশন পরিষেবা থেকে শেষ পয়েন্টগুলির একটি তালিকা পেতে পারে এবং তাদের মধ্যে অনুরোধগুলি কীভাবে বিতরণ করতে হবে তা নির্ধারণ করতে পারে৷ আপনি রাউন্ড-রবিন ব্যবহার করে প্রতিটি পডের সাথে একটি অবিরাম সংযোগ খুলতে পারেন এবং এই সংযোগগুলির মধ্যে ভারসাম্যের অনুরোধ রাখতে পারেন।

অথবা আরও আবেদন করুন জটিল ব্যালেন্সিং অ্যালগরিদম.

ভারসাম্য রক্ষার জন্য দায়ী ক্লায়েন্ট-সাইড কোডের এই যুক্তি অনুসরণ করা উচিত:

1. পরিষেবা থেকে শেষ পয়েন্টগুলির একটি তালিকা পান।
2. প্রতিটি শেষ পয়েন্টের জন্য একটি অবিরাম সংযোগ খুলুন।
3. যখন একটি অনুরোধ করা প্রয়োজন, খোলা সংযোগগুলির একটি ব্যবহার করুন৷
4. নিয়মিতভাবে শেষ পয়েন্টের তালিকা আপডেট করুন, নতুন তৈরি করুন বা তালিকা পরিবর্তন হলে পুরানো অবিরাম সংযোগ বন্ধ করুন।

এটা কি মত হবে.

1. পরিষেবাতে অনুরোধ পাঠানোর প্রথম পডের পরিবর্তে, আপনি ক্লায়েন্টের পক্ষ থেকে অনুরোধের ভারসাম্য রাখতে পারেন:

   

2. আপনাকে কোড লিখতে হবে যা জিজ্ঞাসা করে কোন পডগুলি পরিষেবার অংশ:

   

3. একবার আপনার তালিকা হয়ে গেলে, এটি ক্লায়েন্টের পাশে সংরক্ষণ করুন এবং পডের সাথে সংযোগ করতে এটি ব্যবহার করুন:

   

4. আপনি লোড ব্যালেন্সিং অ্যালগরিদমের জন্য দায়ী:

   

এখন প্রশ্ন উঠছে: এই সমস্যাটি কি শুধুমাত্র HTTP কিপ-লাইভের ক্ষেত্রে প্রযোজ্য?

ক্লায়েন্ট-সাইড লোড ব্যালেন্সিং

HTTP একমাত্র প্রোটোকল নয় যা স্থায়ী TCP সংযোগ ব্যবহার করতে পারে।

যদি আপনার অ্যাপ্লিকেশনটি একটি ডাটাবেস ব্যবহার করে, তাহলে প্রতিবার আপনাকে অনুরোধ করতে বা ডাটাবেস থেকে একটি নথি পুনরুদ্ধার করার জন্য একটি TCP সংযোগ খোলা হয় না। 

পরিবর্তে, ডাটাবেসের সাথে একটি স্থায়ী TCP সংযোগ খোলা এবং ব্যবহার করা হয়।

যদি আপনার ডাটাবেস Kubernetes-এ স্থাপন করা হয় এবং অ্যাক্সেস একটি পরিষেবা হিসাবে প্রদান করা হয়, তাহলে আপনি পূর্ববর্তী বিভাগে বর্ণিত একই সমস্যার সম্মুখীন হবেন।

একটি ডাটাবেস প্রতিলিপি অন্যদের চেয়ে বেশি লোড হবে। Kube-proxy এবং Kubernetes সংযোগ ভারসাম্য সাহায্য করবে না. আপনার ডাটাবেসে প্রশ্নগুলির ভারসাম্য বজায় রাখার জন্য আপনাকে অবশ্যই যত্ন নিতে হবে।

ডাটাবেসের সাথে সংযোগ করতে আপনি কোন লাইব্রেরি ব্যবহার করেন তার উপর নির্ভর করে, এই সমস্যা সমাধানের জন্য আপনার কাছে বিভিন্ন বিকল্প থাকতে পারে।

নীচে Node.js থেকে একটি MySQL ডাটাবেস ক্লাস্টার অ্যাক্সেস করার একটি উদাহরণ রয়েছে:

var mysql = require('mysql');
var poolCluster = mysql.createPoolCluster();

var endpoints = /* retrieve endpoints from the Service */

for (var [index, endpoint] of endpoints) {
  poolCluster.add(`mysql-replica-${index}`, endpoint);
}

// Make queries to the clustered MySQL database

আরও অনেক প্রোটোকল রয়েছে যা স্থায়ী TCP সংযোগ ব্যবহার করে:

• WebSockets এবং সুরক্ষিত WebSockets
• HTTP- র / 2
• gRPC
• RSockets
• এএমকিউপি

এই প্রোটোকলগুলির বেশিরভাগের সাথে আপনার ইতিমধ্যেই পরিচিত হওয়া উচিত।

কিন্তু যদি এই প্রোটোকলগুলি এত জনপ্রিয় হয় তবে কেন একটি মানসম্মত ভারসাম্য সমাধান নেই? কেন ক্লায়েন্ট যুক্তি পরিবর্তন করতে হবে? একটি নেটিভ Kubernetes সমাধান আছে?

Kube-proxy এবং iptables কে Kubernetes-এ স্থাপন করার সময় সবচেয়ে সাধারণ ব্যবহারের ক্ষেত্রে কভার করার জন্য ডিজাইন করা হয়েছে। এই সুবিধার জন্য.

আপনি যদি এমন একটি ওয়েব পরিষেবা ব্যবহার করেন যা একটি REST API প্রকাশ করে, তাহলে আপনার ভাগ্য ভালো - এই ক্ষেত্রে, স্থায়ী TCP সংযোগগুলি ব্যবহার করা হয় না, আপনি যেকোন কুবারনেটস পরিষেবা ব্যবহার করতে পারেন৷

কিন্তু একবার আপনি ক্রমাগত TCP সংযোগ ব্যবহার করা শুরু করলে, আপনাকে ব্যাকএন্ড জুড়ে সমানভাবে লোড কীভাবে বিতরণ করতে হবে তা বের করতে হবে। Kubernetes এই ক্ষেত্রে প্রস্তুত-তৈরি সমাধান ধারণ করে না।

যাইহোক, অবশ্যই এমন বিকল্প রয়েছে যা সাহায্য করতে পারে।

Kubernetes-এ দীর্ঘস্থায়ী সংযোগের ভারসাম্য বজায় রাখা

কুবারনেটসে চার ধরনের পরিষেবা রয়েছে:

1. ক্লাস্টারআইপি
2. নোডপোর্ট
3. লোডব্যালেন্সার
4. মস্তিষ্কহীন

প্রথম তিনটি পরিষেবা একটি ভার্চুয়াল আইপি ঠিকানার উপর ভিত্তি করে কাজ করে, যা iptables নিয়ম তৈরি করতে kube-proxy দ্বারা ব্যবহৃত হয়। কিন্তু সকল সেবার মূল ভিত্তি হলো মাথাবিহীন সেবা।

হেডলেস সার্ভিসটির সাথে যুক্ত কোনো আইপি ঠিকানা নেই এবং এটি শুধুমাত্র আইপি ঠিকানার একটি তালিকা এবং এর সাথে যুক্ত পডের পোর্ট (এন্ডপয়েন্ট) পুনরুদ্ধার করার জন্য একটি প্রক্রিয়া প্রদান করে।

সমস্ত পরিষেবা মাথাবিহীন পরিষেবার উপর ভিত্তি করে।

ClusterIP পরিষেবাটি কিছু সংযোজন সহ একটি মাথাবিহীন পরিষেবা: 

1. ম্যানেজমেন্ট লেয়ার এটিকে একটি আইপি অ্যাড্রেস বরাদ্দ করে।
2. Kube-proxy প্রয়োজনীয় iptables নিয়ম তৈরি করে।

এইভাবে আপনি kube-proxy উপেক্ষা করতে পারেন এবং আপনার অ্যাপ্লিকেশনের ভারসাম্য লোড করতে সরাসরি হেডলেস পরিষেবা থেকে প্রাপ্ত শেষ পয়েন্টের তালিকা ব্যবহার করতে পারেন।

কিন্তু কিভাবে আমরা ক্লাস্টারে স্থাপন করা সমস্ত অ্যাপ্লিকেশনের অনুরূপ যুক্তি যোগ করতে পারি?

আপনার অ্যাপ্লিকেশন ইতিমধ্যেই স্থাপন করা হলে, এই কাজটি অসম্ভব বলে মনে হতে পারে। যাইহোক, একটি বিকল্প বিকল্প আছে।

সার্ভিস মেশ আপনাকে সাহায্য করবে

আপনি সম্ভবত ইতিমধ্যে লক্ষ্য করেছেন যে ক্লায়েন্ট-সাইড লোড ব্যালেন্সিং কৌশলটি বেশ মানসম্পন্ন।

অ্যাপ্লিকেশন শুরু হলে, এটি:

1. পরিষেবা থেকে IP ঠিকানাগুলির একটি তালিকা পায়।
2. একটি সংযোগ পুল খোলে এবং বজায় রাখে।
3. পর্যায়ক্রমে শেষ পয়েন্ট যোগ বা অপসারণ করে পুল আপডেট করে।

একবার অ্যাপ্লিকেশন একটি অনুরোধ করতে চায়, এটি:

1. কিছু যুক্তি ব্যবহার করে একটি উপলব্ধ সংযোগ নির্বাচন করে (যেমন রাউন্ড-রবিন)।
2. অনুরোধটি কার্যকর করে।

এই পদক্ষেপগুলি WebSockets, gRPC এবং AMQP সংযোগ উভয়ের জন্যই কাজ করে।

আপনি এই যুক্তিটিকে একটি পৃথক লাইব্রেরিতে আলাদা করতে পারেন এবং এটি আপনার অ্যাপ্লিকেশনগুলিতে ব্যবহার করতে পারেন।

যাইহোক, আপনি পরিবর্তে Istio বা Linkerd এর মত পরিষেবা মেশ ব্যবহার করতে পারেন।

সার্ভিস মেশ আপনার আবেদনকে একটি প্রক্রিয়ার মাধ্যমে বৃদ্ধি করে যা:

1. স্বয়ংক্রিয়ভাবে পরিষেবা আইপি ঠিকানাগুলি অনুসন্ধান করে।
2. WebSockets এবং gRPC এর মতো সংযোগ পরীক্ষা করে।
3. সঠিক প্রোটোকল ব্যবহার করে অনুরোধের ভারসাম্য বজায় রাখে।

সার্ভিস মেশ ক্লাস্টারের মধ্যে ট্রাফিক পরিচালনা করতে সাহায্য করে, তবে এটি বেশ সম্পদ-নিবিড়। অন্যান্য বিকল্পগুলি নেটফ্লিক্স রিবনের মতো তৃতীয় পক্ষের লাইব্রেরি বা এনভয়-এর মতো প্রোগ্রামেবল প্রক্সি ব্যবহার করছে।

আপনি ভারসাম্য বিষয়ক উপেক্ষা করলে কি হবে?

আপনি লোড ব্যালেন্সিং ব্যবহার না করা বেছে নিতে পারেন এবং এখনও কোনো পরিবর্তন লক্ষ্য করেন না। চলুন কয়েকটি কাজের দৃশ্য দেখি।

আপনার যদি সার্ভারের চেয়ে বেশি ক্লায়েন্ট থাকে তবে এটি এত বড় সমস্যা নয়।

ধরা যাক পাঁচটি ক্লায়েন্ট আছে যা দুটি সার্ভারের সাথে সংযোগ করে। এমনকি যদি কোন ভারসাম্য না থাকে, উভয় সার্ভার ব্যবহার করা হবে:

সংযোগগুলি সমানভাবে বিতরণ নাও হতে পারে: সম্ভবত চারটি ক্লায়েন্ট একই সার্ভারের সাথে সংযুক্ত, তবে উভয় সার্ভার ব্যবহার করার একটি ভাল সুযোগ রয়েছে।

যেটা বেশি সমস্যা তা হল বিপরীত দৃশ্য।

আপনার যদি কম ক্লায়েন্ট এবং আরও সার্ভার থাকে, তাহলে আপনার সংস্থানগুলি কম ব্যবহার করা হতে পারে এবং একটি সম্ভাব্য বাধা দেখা দেবে।

ধরা যাক দুটি ক্লায়েন্ট এবং পাঁচটি সার্ভার রয়েছে। সর্বোত্তম ক্ষেত্রে, পাঁচটির মধ্যে দুটি সার্ভারে দুটি স্থায়ী সংযোগ থাকবে।

অবশিষ্ট সার্ভার নিষ্ক্রিয় হবে:

যদি এই দুটি সার্ভার ক্লায়েন্ট অনুরোধগুলি পরিচালনা করতে না পারে, অনুভূমিক স্কেলিং সাহায্য করবে না।

উপসংহার

Kubernetes পরিষেবাগুলি বেশিরভাগ মানক ওয়েব অ্যাপ্লিকেশন পরিস্থিতিতে কাজ করার জন্য ডিজাইন করা হয়েছে।

যাইহোক, একবার আপনি অ্যাপ্লিকেশান প্রোটোকলগুলির সাথে কাজ শুরু করলে যেগুলি স্থায়ী TCP সংযোগগুলি ব্যবহার করে, যেমন ডেটাবেস, gRPC বা WebSockets, পরিষেবাগুলি আর উপযুক্ত নয়৷ Kubernetes অবিরাম TCP সংযোগের ভারসাম্যের জন্য অভ্যন্তরীণ প্রক্রিয়া প্রদান করে না।

এর মানে আপনাকে অবশ্যই ক্লায়েন্ট-সাইড ব্যালেন্সিং মাথায় রেখে অ্যাপ্লিকেশন লিখতে হবে।

দল দ্বারা প্রস্তুত অনুবাদ Mail.ru থেকে Kubernetes aaS.

টপিক আর কি পড়া:

1. কুবারনেটসে অটোস্কেলিংয়ের তিনটি স্তর এবং কীভাবে সেগুলি কার্যকরভাবে ব্যবহার করা যায়. 
2. বাস্তবায়নের জন্য একটি টেমপ্লেট সহ জলদস্যুতার চেতনায় কুবারনেটস.
3. ডিজিটাল রূপান্তর সম্পর্কে আমাদের টেলিগ্রাম চ্যানেল.

উত্স: www.habr.com