K8S মাল্টিক্লাস্টার জার্নি

হে হাবর!

আমরা Exness প্ল্যাটফর্ম টিমের প্রতিনিধিত্ব করি। পূর্বে, আমাদের সহকর্মীরা ইতিমধ্যে একটি নিবন্ধ লিখেছেন k8s-এর জন্য উৎপাদন-প্রস্তুত ছবি. আজ আমরা Kubernetes-এ স্থানান্তরিত পরিষেবার আমাদের অভিজ্ঞতা শেয়ার করতে চাই।

শুরুতে, কী আলোচনা করা হবে তা আরও ভালভাবে বোঝার জন্য আমরা আপনাকে কিছু সংখ্যা অফার করি:

• স্বয়ংসম্পূর্ণ QA, DevOps এবং Scrum প্রক্রিয়া সহ 100 টিরও বেশি ভিন্ন দল সহ আমাদের উন্নয়ন বিভাগ 10+ লোক নিয়ে গঠিত। ডেভেলপমেন্ট স্ট্যাক - পাইথন, পিএইচপি, সি++, জাভা এবং গোলং। 
• পরীক্ষা এবং উত্পাদন পরিবেশের আকার প্রায় 2000 পাত্রে প্রতিটি। তারা তাদের নিজস্ব ভার্চুয়ালাইজেশন এবং VMware এর অধীনে Rancher v1.6 চালাচ্ছে। 

প্রেরণা

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

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

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

প্রথম ধাপ

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

পরবর্তীতে ক্লাস্টার তৈরির জন্য একটি টুল বেছে নেওয়ার প্রশ্ন এসেছিল। আমরা সবচেয়ে জনপ্রিয় সমাধানগুলির সাথে তুলনা করেছি: কপস, কুবেস্প্রে, কুবিএডম।

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

এবং বিজয়ী ছিল:

আমরা আমাদের নিজস্ব ভার্চুয়ালাইজেশন এবং AWS নিয়ে পরীক্ষা-নিরীক্ষা শুরু করেছি, আমাদের আগের রিসোর্স ম্যানেজমেন্ট প্যাটার্নের মতো মোটামুটি একই রকম কিছু পুনরায় তৈরি করার চেষ্টা করছি, যেখানে প্রত্যেকে একই "ক্লাস্টার" ভাগ করেছে। এবং এখন আমাদের 10টি ছোট ভার্চুয়াল মেশিনের প্রথম ক্লাস্টার রয়েছে, যার মধ্যে কয়েকটি AWS এ অবস্থিত। আমরা সেখানে দলগুলিকে স্থানান্তরিত করার চেষ্টা শুরু করেছিলাম, সবকিছু "ভাল" বলে মনে হয়েছিল, এবং গল্পটি শেষ করা যেতে পারে, কিন্তু...

প্রথম সমস্যা

kubespray যা তৈরি করা হয়েছে তা উত্তরযোগ্য, এটি এমন কোনও সরঞ্জাম নয় যা আপনাকে IaC অনুসরণ করতে দেয়: নোডগুলি কমিশন/ডিকমিশন করার সময়, ক্রমাগত কিছু ভুল হয়ে যায় এবং কিছু ধরণের হস্তক্ষেপের প্রয়োজন হয় এবং বিভিন্ন OS ব্যবহার করার সময়, প্লেবুকটি ভিন্নভাবে আচরণ করে। ভিন্নভাবে . ক্লাস্টারে দল এবং নোডের সংখ্যা বাড়ার সাথে সাথে, আমরা লক্ষ্য করতে শুরু করেছি যে প্লেবুকটি সম্পূর্ণ হতে আরও বেশি সময় নিচ্ছে এবং ফলস্বরূপ, আমাদের রেকর্ড ছিল 3,5 ঘন্টা, আপনার কী হবে? 🙂

এবং মনে হচ্ছে kubespray ঠিক উত্তরযোগ্য, এবং সবকিছু প্রথম নজরে পরিষ্কার, কিন্তু:

যাত্রার শুরুতে, কাজটি ছিল কেবলমাত্র AWS এবং ভার্চুয়ালাইজেশনে সক্ষমতা চালু করা, কিন্তু তারপরে, প্রায়শই ঘটে, প্রয়োজনীয়তা পরিবর্তিত হয়।
 


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

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

একটি পৃথক গল্প ছিল কর্মচারীদের অধিকার প্রদান করা: প্রতিটি দল ক্লাস্টারের "মাথায়" থাকতে এবং এটি সম্পূর্ণরূপে পরিচালনা করতে চেয়েছিল, যা সম্পূর্ণ পতনের কারণ হতে পারে, যেহেতু দলগুলি মূলত একে অপরের থেকে স্বাধীন।

কিভাবে হতে হবে?

উপরের বিষয়গুলি এবং দলগুলির আরও স্বাধীন হওয়ার ইচ্ছাকে বিবেচনায় রেখে, আমরা একটি সহজ উপসংহারে পৌঁছেছি: একটি দল - একটি ক্লাস্টার৷ 

তাই আমরা একটি দ্বিতীয় পেয়েছি:

এবং তারপর তৃতীয় ক্লাস্টার: 

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

পূর্ণ কুবেরনেট আসতো! এটি এক ধরণের মাল্টিকুবারনেটস, দেখা যাচ্ছে। 

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

Kubernetes এর জগতে আমাদের যাত্রা শুরুর পর কিছু সময় অতিবাহিত হয়েছে, এবং আমরা উপলব্ধ সমাধানগুলি পুনরায় পরীক্ষা করার সিদ্ধান্ত নিয়েছি। দেখা গেল যে এটি ইতিমধ্যেই বাজারে বিদ্যমান - Rancher 2.2।

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

র‍্যাঞ্চার 2.2 সংস্করণ ইতিমধ্যেই আরও কার্যকরী চেহারা ছিল এবং পূর্ববর্তীগুলির সাথে একত্রে অনেকগুলি আকর্ষণীয় বৈশিষ্ট্য রয়েছে, যেমন অনেকগুলি বহিরাগত সরবরাহকারীর সাথে একীকরণ, অধিকার বিতরণের একক পয়েন্ট এবং kubeconfig ফাইলগুলি, একটি kubectl চালু করা। UI-তে আপনার অধিকার সহ ছবি, নেস্টেড নেমস্পেস ওরফে প্রজেক্ট। 

Rancher 2 এর আশেপাশে ইতিমধ্যেই একটি সম্প্রদায় তৈরি হয়েছিল, এবং এটি পরিচালনা করার জন্য HashiCorp Terraform নামে একটি প্রদানকারী তৈরি করা হয়েছিল, যা আমাদের সবকিছু একত্রিত করতে সাহায্য করেছিল।

কি হলো

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

gitlab-ci এবং Terraform ব্যবহার করে, একটি সিস্টেম তৈরি করা হয়েছিল যা আপনাকে ক্লাউড প্রদানকারী বা আমাদের নিজস্ব অবকাঠামোতে যেকোন কনফিগারেশনের একটি ক্লাস্টার তৈরি করতে এবং সেগুলিকে Rancher এর সাথে সংযুক্ত করতে দেয়। এই সব IaC শৈলীতে করা হয়, যেখানে প্রতিটি ক্লাস্টার একটি সংগ্রহস্থল দ্বারা বর্ণনা করা হয়, এবং এর অবস্থা সংস্করণ করা হয়। একই সময়ে, বেশিরভাগ মডিউলগুলি বাহ্যিক সংগ্রহস্থল থেকে সংযুক্ত থাকে যাতে যা অবশিষ্ট থাকে তা হল ভেরিয়েবল পাস করা বা উদাহরণের জন্য আপনার কাস্টম কনফিগারেশন বর্ণনা করা, যা কোড পুনরাবৃত্তির শতাংশ হ্রাস করতে সহায়তা করে।

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

নিবন্ধটি লিখেছেন A. Antipov, A. Ganush, Platform Engineers. 

উত্স: www.habr.com