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

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

ডটক্লাউডের ইতিহাস

আমি ডটক্লাউডের ইতিহাস এবং এই প্ল্যাটফর্মের জন্য আর্কিটেকচার পছন্দ সম্পর্কে লিখেছি, কিন্তু আমি নেটওয়ার্ক স্তর সম্পর্কে বেশি কথা বলিনি। আপনি যদি পড়ার মধ্যে ডুব দিতে না চান শেষ নিবন্ধ ডটক্লাউড সম্পর্কে, এখানে সংক্ষেপে সারাংশ দেওয়া হল: এটি একটি PaaS প্ল্যাটফর্ম-এ-সার্ভিস যা গ্রাহকদের বিস্তৃত পরিসরের ডেটার সমর্থন সহ বিভিন্ন অ্যাপ্লিকেশন (জাভা, পিএইচপি, পাইথন...) চালানোর অনুমতি দেয়। পরিষেবাগুলি (মঙ্গোডিবি, মাইএসকিউএল, রেডিস...) এবং হেরোকু-এর মতো একটি ওয়ার্কফ্লো: আপনি প্ল্যাটফর্মে আপনার কোড আপলোড করেন, এটি কন্টেইনার ইমেজ তৈরি করে এবং সেগুলি স্থাপন করে।

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

হোস্ট করা অ্যাপ্লিকেশনের জন্য ট্রাফিক রাউটিং

ডটক্লাউডের অ্যাপ্লিকেশনগুলি HTTP এবং TCP এন্ডপয়েন্টগুলিকে প্রকাশ করতে পারে৷

HTTP শেষ পয়েন্ট লোড ব্যালেন্সার ক্লাস্টার কনফিগারেশনে গতিশীলভাবে যোগ করা হয়েছে হিপচে. এটি আজকের সম্পদের অনুরূপ প্রবেশ Kubernetes এবং একটি লোড ব্যালেন্সার মত ট্রাফিক.

ক্লায়েন্টরা উপযুক্ত ডোমেনের মাধ্যমে HTTP এন্ডপয়েন্টের সাথে সংযোগ স্থাপন করে, যদি ডোমেন নামটি ডটক্লাউড লোড ব্যালেন্সারকে নির্দেশ করে। বিশেষ কিছু না.

TCP শেষ পয়েন্ট একটি পোর্ট নম্বরের সাথে যুক্ত, যা তারপর পরিবেশ ভেরিয়েবলের মাধ্যমে সেই স্ট্যাকের সমস্ত পাত্রে প্রেরণ করা হয়।

ক্লায়েন্টরা উপযুক্ত হোস্টনাম (গেটওয়ে-X.dotcloud.com এর মত কিছু) এবং পোর্ট নম্বর ব্যবহার করে TCP এন্ডপয়েন্টের সাথে সংযোগ করতে পারে।

এই হোস্টনামটি "nats" সার্ভার ক্লাস্টারে সমাধান করে (এর সাথে সম্পর্কিত নয় NATS), যা সঠিক কন্টেইনারে ইনকামিং TCP সংযোগগুলিকে রুট করবে (অথবা, লোড-ব্যালেন্সড পরিষেবার ক্ষেত্রে, সঠিক পাত্রে)।

আপনি যদি কুবারনেটসের সাথে পরিচিত হন তবে এটি সম্ভবত আপনাকে পরিষেবার কথা মনে করিয়ে দেবে নোডপোর্ট.

ডটক্লাউড প্ল্যাটফর্মে কোনও সমতুল্য পরিষেবা ছিল না ক্লাস্টারআইপি: সরলতার জন্য, প্ল্যাটফর্মের ভিতরে এবং বাইরে উভয় দিক থেকেই পরিষেবাগুলি একইভাবে অ্যাক্সেস করা হয়েছিল৷

সবকিছু খুব সহজভাবে সংগঠিত হয়েছিল: HTTP এবং TCP রাউটিং নেটওয়ার্কগুলির প্রাথমিক বাস্তবায়ন সম্ভবত প্রতিটি পাইথনের মাত্র কয়েকশ লাইন ছিল। প্ল্যাটফর্মের বৃদ্ধি এবং অতিরিক্ত প্রয়োজনীয়তা উপস্থিত হওয়ার সাথে সাথে সরল (আমি নিষ্পাপ বলব) অ্যালগরিদমগুলি পরিমার্জিত হয়েছিল।

বিদ্যমান কোডের ব্যাপক রিফ্যাক্টরিংয়ের প্রয়োজন ছিল না। নির্দিষ্টভাবে, 12 ফ্যাক্টর অ্যাপ পরিবেশ ভেরিয়েবলের মাধ্যমে প্রাপ্ত ঠিকানা সরাসরি ব্যবহার করতে পারে।

এটি একটি আধুনিক পরিষেবা জাল থেকে কীভাবে আলাদা?

লিমিটেড দৃশ্যমানতা. আমাদের কাছে TCP রাউটিং জালের জন্য কোনো মেট্রিক্স ছিল না। যখন HTTP রাউটিং আসে, পরবর্তী সংস্করণগুলি ত্রুটি কোড এবং প্রতিক্রিয়া সময় সহ বিস্তারিত HTTP মেট্রিক্স প্রবর্তন করে, কিন্তু আধুনিক পরিষেবা মেশগুলি আরও এগিয়ে যায়, উদাহরণস্বরূপ প্রমিথিউসের মতো মেট্রিক্স সংগ্রহের সিস্টেমগুলির সাথে একীকরণ প্রদান করে।

দৃশ্যমানতা শুধুমাত্র একটি অপারেশনাল দৃষ্টিকোণ থেকে নয় (সমস্যা সমাধানে সহায়তা করার জন্য), কিন্তু নতুন বৈশিষ্ট্য প্রকাশ করার সময়ও গুরুত্বপূর্ণ। এটা নিরাপদ সম্পর্কে নীল-সবুজ স্থাপনা и ক্যানারি স্থাপনা.

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

আধুনিক পরিষেবা জালগুলি এই ধরনের সমস্যাগুলি মোকাবেলায় আরও ভাল। প্রথমত, তারা চেক করে যে সংযোগগুলি রাউট করা হয়েছে উত্স মধ্যে. যৌক্তিক প্রবাহ একই: клиент → меш → сервис, কিন্তু এখন জাল স্থানীয়ভাবে কাজ করে এবং দূরবর্তী নোডগুলিতে নয়, তাই সংযোগ клиент → меш স্থানীয় এবং খুব দ্রুত (মিলিসেকেন্ডের পরিবর্তে মাইক্রোসেকেন্ড)।

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

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

প্ল্যাটফর্ম পরিষেবার জন্য ট্র্যাফিক রাউটিং

ঠিক আছে, আমরা অ্যাপ্লিকেশনগুলির মধ্যে ট্র্যাফিক নিয়ে আলোচনা করেছি, কিন্তু ডটক্লাউড প্ল্যাটফর্মের কী হবে?

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

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

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

এই পরিষেবাগুলি একটি সহজ এবং অশোধিত পদ্ধতিতে প্রকাশ করা হয়েছিল: একটি YAML ফাইল তাদের নাম এবং ঠিকানা তালিকাভুক্ত করেছে; এবং প্রতিটি ক্লায়েন্টকে স্থাপনার জন্য এই YAML ফাইলের একটি অনুলিপি নিতে হয়েছিল।

একদিকে, এটি অত্যন্ত নির্ভরযোগ্য কারণ এটির জন্য বাহ্যিক কী/মূল্যের দোকান যেমন Zookeeper (মনে রাখবেন, etcd বা কনসাল তখন বিদ্যমান ছিল না) এর সমর্থনের প্রয়োজন হয় না। অন্যদিকে, পরিষেবাগুলি সরানো কঠিন করে তুলেছে। প্রতিবার একটি সরানো হলে, সমস্ত ক্লায়েন্ট একটি আপডেট করা YAML ফাইল পাবে (এবং সম্ভাব্য রিবুট)। খুব আরামদায়ক না!

পরবর্তীকালে, আমরা একটি নতুন স্কিম বাস্তবায়ন করতে শুরু করি, যেখানে প্রতিটি ক্লায়েন্ট একটি স্থানীয় প্রক্সি সার্ভারের সাথে সংযুক্ত থাকে। ঠিকানা এবং পোর্টের পরিবর্তে, এটি শুধুমাত্র পরিষেবার পোর্ট নম্বর জানতে হবে এবং এর মাধ্যমে সংযোগ করতে হবে localhost. স্থানীয় প্রক্সি এই সংযোগটি পরিচালনা করে এবং এটি প্রকৃত সার্ভারে ফরোয়ার্ড করে। এখন, অন্য মেশিনে ব্যাকএন্ড সরানোর সময় বা স্কেলিং করার সময়, সমস্ত ক্লায়েন্ট আপডেট করার পরিবর্তে, আপনাকে শুধুমাত্র এই সমস্ত স্থানীয় প্রক্সি আপডেট করতে হবে; এবং একটি রিবুট আর প্রয়োজন নেই.

(এটি TLS সংযোগগুলিতে ট্র্যাফিককে এনক্যাপসুলেট করার এবং প্রাপ্তির পাশে অন্য একটি প্রক্সি সার্ভার রাখার পাশাপাশি প্রাপ্তি পরিষেবার অংশগ্রহণ ছাড়াই TLS শংসাপত্রগুলি যাচাই করার পরিকল্পনা করা হয়েছিল, যা শুধুমাত্র সংযোগগুলি গ্রহণ করার জন্য কনফিগার করা হয়েছে localhost. এই বিষয়ে পরে আরও)।

এই খুব অনুরূপ স্মার্টস্ট্যাক Airbnb থেকে, কিন্তু উল্লেখযোগ্য পার্থক্য হল SmartStack প্রয়োগ করা হয় এবং উৎপাদনে মোতায়েন করা হয়, যখন ডটক্লাউড ডকার হয়ে ওঠে তখন ডটক্লাউড-এর অভ্যন্তরীণ রাউটিং সিস্টেম বন্ধ হয়ে যায়।

আমি ব্যক্তিগতভাবে SmartStack কে Istio, Linkerd এবং Consul Connect এর মতো সিস্টেমের পূর্বসূরি হিসেবে বিবেচনা করি কারণ তারা সবাই একই প্যাটার্ন অনুসরণ করে:

• প্রতিটি নোডে একটি প্রক্সি চালান।
• ক্লায়েন্টরা প্রক্সির সাথে সংযোগ করে।
• ব্যাকএন্ড পরিবর্তন হলে কন্ট্রোল প্লেন প্রক্সি কনফিগারেশন আপডেট করে।
• ...লাভ!

একটি পরিষেবা জাল আধুনিক বাস্তবায়ন

আজ যদি আমাদের একটি অনুরূপ গ্রিড বাস্তবায়নের প্রয়োজন হয় তবে আমরা একই নীতিগুলি ব্যবহার করতে পারি। উদাহরণস্বরূপ, স্থানের ঠিকানাগুলিতে পরিষেবার নাম ম্যাপ করে একটি অভ্যন্তরীণ DNS জোন কনফিগার করুন 127.0.0.0/8. তারপর ক্লাস্টারের প্রতিটি নোডে HAProxy চালান, প্রতিটি পরিষেবার ঠিকানায় সংযোগ গ্রহণ করে (সেই সাবনেটে 127.0.0.0/8) এবং উপযুক্ত ব্যাকএন্ডে লোডকে পুনঃনির্দেশ/ভারসাম্য করা। HAProxy কনফিগারেশন নিয়ন্ত্রণ করা যেতে পারে confd, আপনাকে etcd বা Consul-এ ব্যাকএন্ড তথ্য সঞ্চয় করার অনুমতি দেয় এবং প্রয়োজনে স্বয়ংক্রিয়ভাবে আপডেট করা কনফিগারেশনকে HAProxy-এ পুশ করে।

এই ইস্টিও কাজ করে অনেকটা! কিন্তু কিছু পার্থক্য সহ:

• ব্যবহারসমূহ দূত প্রক্সি HAProxy এর পরিবর্তে।
• etcd বা Consul এর পরিবর্তে Kubernetes API এর মাধ্যমে ব্যাকএন্ড কনফিগারেশন সঞ্চয় করে।
• পরিষেবাগুলি 127.0.0.0/8 এর পরিবর্তে অভ্যন্তরীণ সাবনেটে (Kubernetes ClusterIP ঠিকানা) ঠিকানা বরাদ্দ করা হয়।
• ক্লায়েন্ট এবং সার্ভারের মধ্যে পারস্পরিক TLS প্রমাণীকরণ যোগ করার জন্য একটি অতিরিক্ত উপাদান (সিটাডেল) রয়েছে।
• সার্কিট ব্রেকিং, ডিস্ট্রিবিউটেড ট্রেসিং, ক্যানারি ডিপ্লয়মেন্ট ইত্যাদির মতো নতুন বৈশিষ্ট্যগুলিকে সমর্থন করে।

চলুন কিছু পার্থক্য দ্রুত কটাক্ষপাত করা যাক.

দূত প্রক্সি

Envoy Proxy লিখেছিলেন Lyft [ট্যাক্সি বাজারে উবারের প্রতিযোগী - প্রায়। গলি]। এটি অন্যান্য প্রক্সির (যেমন HAProxy, Nginx, Traefik...) সাথে অনেক উপায়ে একই রকম, কিন্তু Lyft তাদের লিখেছে কারণ তাদের এমন বৈশিষ্ট্যগুলির প্রয়োজন ছিল যা অন্যান্য প্রক্সিগুলির অভাব ছিল, এবং বিদ্যমান প্রক্সিগুলিকে প্রসারিত করার পরিবর্তে একটি নতুন তৈরি করা আরও স্মার্ট বলে মনে হয়েছিল।

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

কিন্তু দূত হিসেবেও কাজ করতে সক্ষম তথ্য সমতল (ডেটা প্লেন) পরিষেবা জালের জন্য। এর মানে হল যে Envoy এখন এই পরিষেবা জালের জন্য কনফিগার করা হয়েছে নিয়ন্ত্রণ সমতল (নিয়ন্ত্রণ সমতল)।

কন্ট্রোল প্লেন

কন্ট্রোল প্লেনের জন্য, Istio Kubernetes API এর উপর নির্ভর করে। এটি confd ব্যবহার করার থেকে খুব আলাদা নয়, যা ডেটা স্টোরে কীগুলির সেট দেখতে etcd বা কনসালের উপর নির্ভর করে। Istio Kubernetes সম্পদের একটি সেট দেখতে Kubernetes API ব্যবহার করে।

এর মাঝে এবং তারপরেও: আমি ব্যক্তিগতভাবে এটি দরকারী খুঁজে পেয়েছি Kubernetes API বিবরণযা পড়ে:

Kubernetes API সার্ভার হল একটি "বোবা সার্ভার" যা API সংস্থানগুলির জন্য স্টোরেজ, সংস্করণ, বৈধতা, আপডেট এবং শব্দার্থবিদ্যা অফার করে।

Istio কুবারনেটসের সাথে কাজ করার জন্য ডিজাইন করা হয়েছে; এবং যদি আপনি এটি কুবারনেটসের বাইরে ব্যবহার করতে চান, তাহলে আপনাকে কুবারনেটস এপিআই সার্ভারের (এবং etcd সহায়ক পরিষেবা) একটি উদাহরণ চালাতে হবে।

পরিষেবার ঠিকানা

Istio ClusterIP ঠিকানাগুলির উপর নির্ভর করে যেগুলি Kubernetes বরাদ্দ করে, তাই Istio পরিষেবাগুলি একটি অভ্যন্তরীণ ঠিকানা পায় (সীমার মধ্যে নয় 127.0.0.0/8).

Istio ছাড়া Kubernetes ক্লাস্টারে একটি নির্দিষ্ট পরিষেবার জন্য ClusterIP ঠিকানায় ট্র্যাফিক kube-proxy দ্বারা আটকানো হয় এবং সেই প্রক্সির ব্যাকএন্ডে পাঠানো হয়। আপনি যদি প্রযুক্তিগত বিবরণে আগ্রহী হন, kube-proxy ClusterIP ঠিকানায় যাওয়া সংযোগগুলির গন্তব্য আইপি ঠিকানাগুলি পুনরায় লেখার জন্য iptables নিয়ম (বা IPVS লোড ব্যালেন্সার, এটি কীভাবে কনফিগার করা হয়েছে তার উপর নির্ভর করে) সেট আপ করে।

একবার কুবারনেটস ক্লাস্টারে ইস্টিও ইনস্টল হয়ে গেলে, একটি প্রদত্ত ভোক্তার জন্য বা এমনকি সম্পূর্ণ নামস্থানের জন্য একটি ধারক প্রবর্তনের মাধ্যমে স্পষ্টভাবে সক্ষম না হওয়া পর্যন্ত কিছুই পরিবর্তন হয় না। sidecar কাস্টম পড মধ্যে. এই কন্টেইনারটি এনভয়-এর একটি উদাহরণ তৈরি করবে এবং অন্যান্য পরিষেবাগুলিতে যাওয়া ট্রাফিককে বাধা দিতে এবং সেই ট্র্যাফিককে দূতের কাছে পুনঃনির্দেশিত করতে iptables নিয়মগুলির একটি সেট আপ করবে।

Kubernetes DNS এর সাথে একত্রিত হলে, এর অর্থ হল আমাদের কোড পরিষেবার নাম এবং সবকিছু "শুধু কাজ করে" দ্বারা সংযুক্ত হতে পারে। অন্য কথায়, আমাদের কোড ইস্যু যেমন প্রশ্ন http://api/v1/users/4242তারপর api জন্য অনুরোধ সমাধান 10.97.105.48, iptables নিয়মগুলি 10.97.105.48 থেকে সংযোগগুলিকে বাধা দেবে এবং সেগুলিকে স্থানীয় এনভয় প্রক্সিতে ফরোয়ার্ড করবে এবং সেই স্থানীয় প্রক্সি প্রকৃত ব্যাকএন্ড API-এ অনুরোধটি ফরোয়ার্ড করবে৷ উফফ!

অতিরিক্ত frills

Istio এন্ড-টু-এন্ড এনক্রিপশন এবং mTLS (মিউচুয়াল TLS) এর মাধ্যমে প্রমাণীকরণ প্রদান করে। একটি উপাদান বলা হয় দুর্গ.

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

এবং, অবশ্যই, আমরা দৃশ্যমানতা উল্লেখ করেছি: দূত বিতরণ ট্রেসিং প্রদান করার সময় বিপুল পরিমাণ মেট্রিক্স সংগ্রহ করে। একটি মাইক্রোসার্ভিসেস আর্কিটেকচারে, যদি একটি একক API অনুরোধ মাইক্রোসার্ভিসেস A, B, C, এবং D এর মধ্য দিয়ে যেতে হয়, তাহলে লগইন করার পরে, বিতরণ করা ট্রেসিং অনুরোধে একটি অনন্য শনাক্তকারী যোগ করবে এবং এই সমস্ত মাইক্রোসার্ভিসে সাব-রিকোয়েস্টের মাধ্যমে এই শনাক্তকারীকে সংরক্ষণ করবে, অনুমতি দেবে সমস্ত সম্পর্কিত কল ক্যাপচার করা হবে। বিলম্ব, ইত্যাদি।

বিকাশ বা কিনুন

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

যদি আমাদের পরিমিত চাহিদা থাকে (আমাদের দৃশ্যমানতা, একটি সার্কিট ব্রেকার এবং অন্যান্য সূক্ষ্মতার প্রয়োজন নেই), তাহলে আমাদের নিজস্ব সরঞ্জাম তৈরি করার চিন্তা আসে। কিন্তু যদি আমরা কুবারনেটস ব্যবহার করি, তাহলে এটির প্রয়োজনও নাও হতে পারে কারণ কুবারনেটস ইতিমধ্যেই পরিষেবা আবিষ্কার এবং লোড ব্যালেন্সিংয়ের জন্য মৌলিক সরঞ্জাম সরবরাহ করে।

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

আমার কি Istio, Linkerd বা Consul Connect বেছে নেওয়া উচিত?

এখন পর্যন্ত আমরা শুধুমাত্র ইস্টিও সম্পর্কে কথা বলেছি, তবে এটি একমাত্র পরিষেবা জাল নয়। জনপ্রিয় বিকল্প - লিংকার্ড, এবং আরো আছে কনসাল কানেক্ট.

কি নির্বাচন?

সত্যি বলছি, আমি জানি না। এই মুহূর্তে আমি নিজেকে এই প্রশ্নের উত্তর দেওয়ার মতো যথেষ্ট যোগ্য মনে করি না। একটি কয়েক আছে মজাদার নিবন্ধ এই টুলস এবং এমনকি একটি তুলনা সঙ্গে বেঞ্চমার্ক.

একটি প্রতিশ্রুতিশীল পদ্ধতির মত একটি টুল ব্যবহার করা হয় সুপারগ্লু. এটি পরিষেবা মেশ দ্বারা উন্মুক্ত APIগুলিকে সরল এবং একীভূত করতে একটি বিমূর্ত স্তর প্রয়োগ করে। বিভিন্ন সার্ভিস মেশের নির্দিষ্ট (এবং, আমার মতে, তুলনামূলকভাবে জটিল) API শেখার পরিবর্তে, আমরা SuperGloo-এর সহজ গঠন ব্যবহার করতে পারি - এবং সহজেই একটি থেকে অন্যটিতে সুইচ করতে পারি, যেন আমাদের একটি মধ্যবর্তী কনফিগারেশন বিন্যাস রয়েছে যা HTTP ইন্টারফেস এবং ব্যাকএন্ডগুলিকে বর্ণনা করতে সক্ষম। Nginx, HAProxy, Traefik, Apache এর জন্য প্রকৃত কনফিগারেশন তৈরি করার...

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

উত্স: www.habr.com