কুবারনেটে রিডানড্যান্সি: এটি বিদ্যমান

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

নীতিগতভাবে, নিরীক্ষণ এবং অপ্রয়োজনীয়তা যে কোনো প্রকল্পের ত্রুটি সহনশীলতা বৃদ্ধির জন্য দুটি প্রধান হাতিয়ার। কিন্তু কিউবারে, সবকিছুই নিজেই ভারসাম্য বজায় রাখে, আপনি বলেন, সবকিছু নিজেই স্কেল করে, এবং কিছু ঘটলে, এটি নিজেই উঠে যাবে... অর্থাৎ, বিষয়টির প্রথম সুপারফিশিয়াল গবেষণার সময়, যখন জিজ্ঞাসা করা হয়েছিল কে কে 8 এর রিজার্ভেশনের সাথে যোগাযোগ করে কিভাবে , ইন্টারনেট আমাকে উত্তর দিয়েছে "কেন?"? অনেক লোক মনে করে যে কিউবার এমন একটি জাদুকরী জিনিস যা সমস্ত অবকাঠামোগত সমস্যা থেকে পরিত্রাণ পায় এবং এটি তৈরি করে যাতে প্রকল্পটি কখনই ব্যর্থ হয় না। কিন্তু... পৃথিবী যা মনে হয় তা নয়।

আগে আমরা ব্যাকআপ প্রক্রিয়াটি কীভাবে ব্যবহার করতাম? আমাদের একই রকম হোস্টিং প্ল্যাটফর্ম ছিল—হয় ভার্চুয়াল অথবা হার্ডওয়্যার। সার্ভার, যেখানে আমরা তিনটি মৌলিক অনুশীলন প্রয়োগ করেছি:

1. কোড এবং স্ট্যাটিক্সের সিঙ্ক্রোনাইজেশন
2. কনফিগারেশন সিঙ্ক্রোনাইজেশন
3. ডাটাবেস প্রতিলিপি

এবং ভয়েলা: যে কোনও মুহুর্তে আমরা রিজার্ভ সাইটে স্যুইচ করি, সবাই খুশি, আমরা উঠে চলে যাই।

আমাদের kubernetes অ্যাপ্লিকেশনের ক্রমাগত প্রাপ্যতা বাড়ানোর জন্য তারা আমাদের কী অফার করে? অনানুষ্ঠানিক ডকুমেন্টেশনে প্রথম যে জিনিসটি বলা হয়েছে তা হল প্রচুর মেশিন ইনস্টল করা, প্রচুর মাস্টার তৈরি করা - তাদের সংখ্যা অবশ্যই ক্লাস্টারের মধ্যে একটি কোরাম অর্জনের শর্ত পূরণ করতে হবে, এবং যাতে প্রতিটিতে etcd, api, MC, শিডিউলার ইনস্টল করা হয়। মাস্টার্স... এবং, মনে হচ্ছে, সবকিছু ঠিক আছে : যদি বেশ কয়েকটি কর্মী নোড বা মাস্টার ব্যর্থ হয়, আমাদের ক্লাস্টার পুনরায় ভারসাম্যপূর্ণ হবে এবং অ্যাপ্লিকেশনটি কাজ করতে থাকবে। আবার ম্যাজিক মনে হচ্ছে! কিন্তু প্রায়ই আমাদের ক্লাস্টার একই ডেটা সেন্টারের মধ্যে অবস্থিত এবং এটি কিছু প্রশ্ন উত্থাপন করতে পারে। যদি একটি খননকারী এসে তারের খনন করে, বজ্রপাত হয় এবং বিশ্বব্যাপী বন্যা হয়? সবকিছু আবৃত, আমাদের ক্লাস্টার আর বিদ্যমান নেই. সমস্যার এই দিকটি বিবেচনায় নিয়ে রিজার্ভেশনের সাথে কীভাবে যোগাযোগ করবেন?

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

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

উদাহরণস্বরূপ, কুবারনেটসের মৌলিক সত্তাগুলি দিয়ে শুরু করা যাক - স্থাপনা - সেগুলি অবশ্যই অভিন্ন হতে হবে৷ অ্যাপ্লিকেশানগুলি অবশ্যই লঞ্চ করতে হবে যা যে কোনও সময় ট্র্যাফিক প্রক্রিয়াকরণকে বাধা দিতে পারে এবং আমাদের প্রকল্পকে লাইভ চালিয়ে যেতে দেয়৷ যদি আমরা কনফিগারেশন ফাইল সম্পর্কে কথা বলি, তাহলে আমাদের দেখতে হবে যে সেগুলি অভিন্ন হবে কি না। অর্থাৎ, যদি আমরা, বুদ্ধিমান ব্যক্তিরা, কোনো নিষিদ্ধ পদার্থ ব্যবহার না করি এবং K8s-এ একটি বেস না রাখি, তাহলে আমাদের কনফিগম্যাপে আমাদের যুদ্ধের বেসে অ্যাক্সেসের জন্য সেটিংস থাকা উচিত (যার জন্য সংরক্ষণ প্রক্রিয়াটি আলাদাভাবে তৈরি করা হয়েছে)। তদনুসারে, ব্যাকআপ ডাটাবেস উদাহরণে অ্যাক্সেস প্রদান করার জন্য, আমাদের অবশ্যই একটি পৃথক কনফিগারেশন ফাইল (কনফিগারেশন ম্যাপ) থাকতে হবে। আমরা গোপনীয়তার সাথে ঠিক একইভাবে কাজ করি: ডাটাবেস অ্যাক্সেস করার জন্য পাসওয়ার্ড, এপিআই কী; যে কোনো সময়ে, আমাদের হয় একটি যুদ্ধ গোপন বা একটি সংরক্ষিত একটি চলমান থাকতে পারে। মোট, আমাদের ইতিমধ্যে দুটি কুবারনেটস সত্তা রয়েছে, যার ব্যাকআপ সংস্করণগুলি উত্পাদনের সাথে অভিন্ন হওয়া উচিত নয়। ফোকাস করার মতো পরবর্তী সত্তা হল ক্রনজব। রিজার্ভের ক্রনজবগুলি কোনও অবস্থাতেই প্রোডাকশন ক্লাস্টারে ক্রোনজবগুলির সেটের সাথে অভিন্ন হওয়া উচিত নয়! যদি আমরা একটি ব্যাকআপ ক্লাস্টার উত্থাপন করি এবং সমস্ত ক্রনজব সক্ষম করে এটিকে সম্পূর্ণভাবে বাড়ায়, তাহলে, উদাহরণস্বরূপ, লোকেরা আপনার কাছ থেকে একই সময়ে একটির পরিবর্তে দুটি চিঠি পাবে। বা বাহ্যিক উত্সগুলির সাথে ডেটার এক ধরণের সিঙ্ক্রোনাইজেশন দুবার ঘটবে, সেই অনুসারে আমরা অসুস্থ, কান্নাকাটি, চিৎকার এবং শপথ ​​করতে শুরু করি।

ইন্টারনেটের লোকেরা কীভাবে আমাদের একটি অপ্রয়োজনীয় ক্লাস্টার সংগঠিত করার পরামর্শ দেয়? "কেন?" এর পরে দ্বিতীয় সর্বাধিক জনপ্রিয় উত্তর - কুবারনেটস ফেডারেশনের ব্যবহার।

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

কুবারনেটস ফেডারেশন একটি সাম্প্রতিক বিদ্যমান টুল, এবং এটি K8s নিজেই সরবরাহ করে এমন সমস্ত সংস্থানকে সমর্থন করে না: ডকুমেন্টেশনের প্রথম সংস্করণগুলির একটি প্রকাশের সময়, এটি শুধুমাত্র কনফিগার মানচিত্রকে সমর্থন করে, একটি প্রতিরূপের জন্য স্থাপনার কথা বলেছিল। সেট, এবং প্রবেশ. গোপনীয়তা সমর্থিত ছিল না, ভলিউমের সাথে কাজ করাও সমর্থিত ছিল না। খুব সীমিত সেট। বিশেষ করে যদি আমরা মজা করতে পছন্দ করি, উদাহরণস্বরূপ, একটি কাস্টম রিসোর্স সংজ্ঞার মাধ্যমে আমাদের নিজস্ব সম্পদগুলি কুবারনেটে স্থানান্তর করে, আমরা সেগুলিকে ফেডারেশনে ঠেলে দেব না। অর্থাৎ, এটি এমন... একটি সমাধান যা সত্যের সাথে খুব মিল, কিন্তু এটি আমাদের পর্যায়ক্রমে নিজেদের পায়ে গুলি করতে বাধ্য করে। অন্যদিকে, ফেডারেশন আমাদের নমনীয়ভাবে আমাদের রেপ্লিকাসেট পরিচালনা করতে দেয়। উদাহরণস্বরূপ, আমরা চাই আমাদের আবেদনের 10টি প্রতিলিপি চলমান থাকুক, ডিফল্টরূপে ফেডারেশন এই সংখ্যাটিকে ক্লাস্টারের সংখ্যার মধ্যে আনুপাতিকভাবে ভাগ করবে। এবং এই সব কনফিগার করা যেতে পারে! অর্থাৎ, আপনি নির্দিষ্ট করতে পারেন যে আপনাকে প্রোডাকশন ক্লাস্টারে আমাদের অ্যাপ্লিকেশনের 6টি প্রতিলিপি এবং ব্যাকআপ ক্লাস্টারে আমাদের অ্যাপ্লিকেশনের মাত্র 4টি প্রতিলিপি রাখতে হবে, সম্পদ বাঁচাতে বা আপনার নিজস্ব বিনোদনের জন্য। যা বেশ সুবিধাজনকও বটে। তবে ফেডারেশনের সাথে, আমাদের কিছু নতুন সমাধান ব্যবহার করতে হবে, উড়ে গিয়ে কিছু বিকাশ করতে হবে, নিজেকে আরও কিছুটা ভাবতে বাধ্য করতে হবে...

কিউবার রিজার্ভেশন প্রক্রিয়ার কাছে যাওয়ার একটি সহজ উপায় আছে কি? আমরা এমনকি কি সরঞ্জাম আছে?

প্রথমত, আমাদের সর্বদা কিছু ধরণের ci/cd সিস্টেম থাকে, অর্থাৎ, আমরা সার্ভার তৈরি/প্রয়োগ করতে ম্যানুয়ালি যাই না বা লিখি না। সিস্টেম আমাদের পাত্রে জন্য yamls তৈরি করে.

দ্বিতীয়ত, বেশ কয়েকটি ক্লাস্টার রয়েছে, আমাদের হয় এক বা একাধিক (যদি আমরা স্মার্ট হই) রেজিস্ট্রি, যা আমরা গ্রহণ করেছি এবং সংরক্ষিত করেছি। এবং kubectl নামে একটি বিস্ময়কর ইউটিলিটি রয়েছে, যা একই সময়ে বেশ কয়েকটি ক্লাস্টারের সাথে কাজ করতে পারে।

সুতরাং: আমার মতে, একটি ব্যাকআপ ক্লাস্টার তৈরির জন্য সবচেয়ে সহজ এবং সবচেয়ে সঠিক সমাধান হল একটি আদিম সমান্তরাল স্থাপনা। ci/cd সিস্টেমে কিছু ধরনের পাইপলাইন আছে; প্রথমত, আমরা আমাদের কন্টেইনার তৈরি করি, পরীক্ষা করি এবং অ্যাপ্লিকেশনগুলিকে কয়েকটি স্বাধীন ক্লাস্টারে kubectl এর মাধ্যমে রোল আউট করি। আমরা বেশ কয়েকটি ক্লাস্টারের জন্য একযোগে গণনা তৈরি করতে পারি। তদনুসারে, আমরা এই পর্যায়ে কনফিগারেশন সরবরাহের বিষয়েও সিদ্ধান্ত নিই। আমরা আমাদের যুদ্ধ ক্লাস্টারের জন্য কনফিগারেশনের একটি সেট, একটি ব্যাকআপ ক্লাস্টারের জন্য কনফিগারেশনের একটি সেট এবং ci/cd সিস্টেম স্তরে আমরা খাদ্য পরিবেশকে একটি খাদ্য ক্লাস্টারে এবং ব্যাকআপ পরিবেশকে একটি ব্যাকআপে রোল আউট করতে পারি। ক্লাস্টার ফেডারেশনের তুলনায়, একটি ফেডারেটেড রিসোর্স সংজ্ঞায়িত করার পরে, আপনাকে প্রতিটি চাইল্ড ক্লাস্টারে যেতে হবে না এবং কিছু নতুন করে সংজ্ঞায়িত করতে হবে। আমরা এটা আগেই করেছি। আমরা কি মহান বন্ধু.

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

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

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

আচ্ছা, আসলে, এই সব থেকে কি উপসংহার টানা যায়?

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

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

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

এবং পরিশেষে: আমি "কিউব" পছন্দ করি, সেইসাথে এটির সাথে পরীক্ষাও করি। আমি এই পরীক্ষার ফলাফল এবং সাধারণভাবে আমার ব্যক্তিগত অভিজ্ঞতা শেয়ার করতে চাই। এই কারণেই আমি K8s সম্পর্কে ওয়েবিনারের একটি সিরিজ রেকর্ড করেছি, স্বাগতম আমাদের ইউটিউব চ্যানেল বিস্তারিত জানার জন্য.

উত্স: www.habr.com