DomClick-এ Kubernetes: 1000 মাইক্রোসার্ভিসের একটি ক্লাস্টার পরিচালনা করে কীভাবে শান্তিতে ঘুমানো যায়

আমার নাম ভিক্টর ইয়াগোফারভ, এবং আমি Ops (অপারেশন) দলের একজন প্রযুক্তিগত উন্নয়ন ব্যবস্থাপক হিসেবে DomClick-এ Kubernetes প্ল্যাটফর্ম তৈরি করছি। আমি আপনাকে আমাদের Dev <-> Ops প্রক্রিয়াগুলির গঠন সম্পর্কে বলতে চাই, রাশিয়ার সবচেয়ে বড় k8s ক্লাস্টারগুলির মধ্যে একটি পরিচালনার বৈশিষ্ট্য সম্পর্কে, সেইসাথে আমাদের দল যেগুলি ব্যবহার করে সেই DevOps/SRE অনুশীলনগুলি সম্পর্কে।

টিম অপস

অপস দলে বর্তমানে ১৫ জন রয়েছে। তাদের মধ্যে তিনজন অফিসের জন্য দায়ী, দু'জন আলাদা টাইম জোনে কাজ করে এবং রাতে সহ উপলব্ধ। সুতরাং, Ops থেকে কেউ সর্বদা মনিটরে থাকে এবং যেকোন জটিলতার ঘটনার প্রতিক্রিয়া জানাতে প্রস্তুত থাকে। আমাদের নাইট শিফট নেই, যা আমাদের মানসিকতা রক্ষা করে এবং প্রত্যেককে পর্যাপ্ত ঘুম এবং অবসর সময় কাটানোর সুযোগ দেয় না শুধুমাত্র কম্পিউটারে।

প্রত্যেকেরই বিভিন্ন দক্ষতা রয়েছে: নেটওয়ার্কার, ডিবিএ, ইএলকে স্ট্যাক বিশেষজ্ঞ, কুবারনেটস অ্যাডমিন/ডেভেলপার, মনিটরিং, ভার্চুয়ালাইজেশন, হার্ডওয়্যার বিশেষজ্ঞ ইত্যাদি। একটি জিনিস সবাইকে একত্রিত করে - প্রত্যেকেই আমাদের যে কোনো একটিকে কিছুটা হলেও প্রতিস্থাপন করতে পারে: উদাহরণস্বরূপ, k8s ক্লাস্টারে নতুন নোড প্রবর্তন করুন, PostgreSQL আপডেট করুন, একটি CI/CD + Ansible পাইপলাইন লিখুন, Python/Bash/Go-এ কিছু স্বয়ংক্রিয় করুন, একটি অংশ সংযুক্ত করুন ডিপিসি থেকে হার্ডওয়্যার। কোনো এলাকায় শক্তিশালী দক্ষতা কার্যকলাপের দিক পরিবর্তন এবং অন্য কোনো এলাকায় পাম্প শুরু করতে হস্তক্ষেপ করে না। উদাহরণস্বরূপ, আমি পোস্টগ্রেএসকিউএল বিশেষজ্ঞ হিসাবে একটি কোম্পানিতে চাকরি পেয়েছি এবং এখন আমার দায়িত্বের প্রধান ক্ষেত্রটি হল কুবারনেটস ক্লাস্টার। দলে, যে কোনও বৃদ্ধি শুধুমাত্র স্বাগত এবং কাঁধের অনুভূতি খুব উন্নত।

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

টুল কমান্ড

টুলস টিম অটোমেশনে গুরুত্বপূর্ণ ভূমিকা পালন করে। তাদের প্রধান কাজ হল ডেভেলপারদের জন্য সুবিধাজনক গ্রাফিক্যাল এবং CLI টুল তৈরি করা। উদাহরণ স্বরূপ, কনফারের আমাদের অভ্যন্তরীণ বিকাশ আপনাকে মাত্র কয়েকটি মাউস ক্লিকের মাধ্যমে কুবারনেটে একটি অ্যাপ্লিকেশন রোল আউট করার অনুমতি দেয়, এর সংস্থানগুলি কনফিগার করতে, ভল্ট থেকে কী ইত্যাদি। আগে Jenkins + Helm 2 ছিল, কিন্তু কপি-পেস্ট দূর করতে এবং সফ্টওয়্যার জীবনচক্রে অভিন্নতা আনতে আমাকে আমার নিজস্ব টুল তৈরি করতে হয়েছিল।

Ops টিম ডেভেলপারদের জন্য পাইপলাইন লেখে না, তবে সেগুলি লেখার ক্ষেত্রে যেকোনও বিষয়ে পরামর্শ দিতে পারে (কিছু এখনও হেলম 3 আছে)।

DevOps

DevOps হিসাবে, আমরা এটি এই মত দেখতে:

ডেভ টিম কোড লেখে, কনফার টু dev -> qa/stage -> prod এর মাধ্যমে এটি রোল আউট করে। কোডটি যাতে ধীর হয়ে না যায় এবং ত্রুটি না ফেলে তা নিশ্চিত করা দেব এবং অপস দলের দায়িত্ব। দিনের বেলায়, অপস টিমের ডিউটি ​​অফিসারকে তার আবেদনের সাথে একটি ঘটনার প্রতিক্রিয়া জানাতে হবে এবং সন্ধ্যা এবং রাতে, ডিউটি ​​অ্যাডমিনকে (অপস) ডেভেলপারকে ডেভেলপারকে জাগিয়ে দিতে হবে যদি তিনি নিশ্চিতভাবে জানেন যে সমস্যাটি হয়নি। অবকাঠামোতে পর্যবেক্ষণের সমস্ত মেট্রিক এবং সতর্কতা স্বয়ংক্রিয়ভাবে বা আধা-স্বয়ংক্রিয়ভাবে প্রদর্শিত হয়।

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

ডেভেলপাররা অ্যাডমিনদের পরামর্শ দেন যদি তাদের একটি অ্যাডমিন মাইক্রোসার্ভিস লিখতে সাহায্যের প্রয়োজন হয় (উদাহরণস্বরূপ, গো ব্যাকএন্ড + HTML5), এবং অ্যাডমিনরা ডেভেলপারদের যেকোন অবকাঠামো বা k8s সম্পর্কিত বিষয়ে পরামর্শ দেন।

যাইহোক, আমাদের কাছে মোটেও মনোলিথ নেই, শুধুমাত্র মাইক্রোসার্ভিসেস। তাদের সংখ্যা এখন পর্যন্ত 900 এবং 1000 এর মধ্যে ওঠানামা করে prod k8s ক্লাস্টারে, যদি সংখ্যা দ্বারা পরিমাপ করা হয় স্থাপনার. শুঁটির সংখ্যা 1700 এবং 2000-এর মধ্যে ওঠানামা করে। প্রোড ক্লাস্টারে এখন 2000-এর কাছাকাছি।

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

সম্পদ ব্যবস্থাপনা

পর্যবেক্ষণ

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

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

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

"কিউব" এ টিম রিসোর্স

উদাহরণগুলির সাথে এগিয়ে যাওয়ার আগে, আমাদের কাছে কীভাবে সম্পদ বরাদ্দ আছে তা ব্যাখ্যা করা মূল্যবান মাইক্রো সার্ভিস.

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

দল প্রতি সম্পদ বরাদ্দের একটি উদাহরণ:

namespaces:

  chat-team:
    pods: 23
    limits:
      cpu: 11
      memory: 20Gi
    requests:
      cpu: 11
      memory: 20Gi

অনুরোধ এবং সীমা

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

এই পরিস্থিতি থেকে বেরিয়ে আসার সঠিক উপায় হল প্রকৃত সম্পদ খরচের দিকে নজর দেওয়া এবং অনুরোধকৃত পরিমাণের (অনুরোধ) সাথে তুলনা করা।

উপরের স্ক্রিনশটগুলি দেখায় যে "অনুরোধ করা" (অনুরোধ করা) সিপিইউগুলি থ্রেডের প্রকৃত সংখ্যার জন্য নির্বাচন করা হয়েছে এবং সীমাগুলি CPU থ্রেডের প্রকৃত সংখ্যাকে অতিক্রম করতে পারে =)

এখন আসুন কিছু নামস্থানকে ঘনিষ্ঠভাবে দেখে নেওয়া যাক (আমি নামস্থান কিউব-সিস্টেম বেছে নিয়েছি - "কিউব" এর উপাদানগুলির জন্য সিস্টেম নামস্থান) এবং অনুরোধকৃতটির সাথে প্রকৃতভাবে ব্যবহৃত প্রসেসরের সময় এবং মেমরির অনুপাত দেখুন:

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

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

এবং এখানে শুঁটিগুলি রয়েছে যা তাদের ক্ষুধা নিয়ন্ত্রিত করবে:

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

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

পদ্ধতি

এখনকার মতো কোম্পানিতে ফ্যাশনেবল, আমরা DevOps- এবং মেনে চলি SRE- অনুশীলনকারী যখন একটি কোম্পানির 1000টি মাইক্রোসার্ভিস থাকে, প্রায় 350 জন ডেভেলপার এবং সম্পূর্ণ পরিকাঠামোর জন্য 15 জন প্রশাসক থাকে, তখন আপনাকে "ফ্যাশনেবল" হতে হবে: এই সমস্ত "বাজওয়ার্ড" এর পিছনে সবকিছু এবং সবকিছু স্বয়ংক্রিয় করার জরুরী প্রয়োজন রয়েছে এবং প্রশাসকদের বাধা হওয়া উচিত নয় প্রক্রিয়ায়

Ops হিসাবে, আমরা পরিষেবাগুলির প্রতিক্রিয়া সময় এবং তাদের ত্রুটিগুলির সাথে সম্পর্কিত বিকাশকারীদের জন্য বিভিন্ন মেট্রিক্স এবং ড্যাশবোর্ড সরবরাহ করি।

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

আমি এখন এক মাস ধরে গ্রাফিক্স আঁকিনি। এটি সম্ভবত একটি ভাল লক্ষণ: এর মানে হল যে বেশিরভাগ "চাই" ইতিমধ্যেই বাস্তবায়িত হয়েছে৷ এটা ঘটেছে যে এক সপ্তাহের জন্য আমি দিনে অন্তত একবার কিছু নতুন চার্ট আঁকলাম।

ফলস্বরূপ ফলাফলটি মূল্যবান যে এখন বিকাশকারীরা খুব কমই "কোন ধরণের মেট্রিক্স কোথায় দেখতে হবে" প্রশ্ন নিয়ে প্রশাসকদের কাছে যান৷

প্রবর্তনের সার্ভিস মেশ একেবারে কোণায় রয়েছে এবং প্রত্যেকের জন্য জীবনকে আরও সহজ করে তুলতে হবে, টুলস-এর সহকর্মীরা ইতিমধ্যেই বিমূর্ত "একজন সুস্থ ব্যক্তির ইসটিও" বাস্তবায়নের কাছাকাছি: প্রতিটি HTTP(গুলি) অনুরোধের জীবনচক্র পর্যবেক্ষণে দৃশ্যমান হবে, এবং ইন্টারসার্ভিস (এবং শুধুমাত্র নয়) ইন্টারঅ্যাকশনে "কোন পর্যায়ে সবকিছু ভেঙে গেছে" তা বোঝা সবসময় সম্ভব হবে। DomClick হাব থেকে খবরের সদস্যতা নিন। =)

Kubernetes পরিকাঠামো সমর্থন

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

সমস্ত k8s ক্লাস্টারগুলির জন্য আপগ্রেড প্রক্রিয়াটি এইরকম দেখাচ্ছে:

• গ্রহণ করা কুবেস্প্রে সাউথব্রিজ থেকে, আমাদের শাখার সাথে চেক করুন, মারজিম।
• আপডেট রোল আউট জোর- "কিউব"।
• আমরা একবারে একটি নোড আপডেট করি (অনুসন্ধানে এটি "সিরিয়াল: 1") দেব- "কিউব"।
• আপডেট করা হচ্ছে শঙ্কু শনিবার সন্ধ্যায়, এক সময়ে একটি নোড।

ভবিষ্যতে প্রতিস্থাপনের পরিকল্পনা রয়েছে কুবেস্প্রে কিছু দ্রুত এবং যান kubeadm.

মোট, আমাদের তিনটি "কিউব" আছে: স্ট্রেস, দেব এবং প্রোড। আমরা আরেকটি চালু করার পরিকল্পনা করছিগরম স্ট্যান্ডবাই) প্রোড- দ্বিতীয় ডেটা সেন্টারে "কিউব"। জোর и দেব ভার্চুয়াল মেশিনে বাস করুন (স্ট্রেসের জন্য oVirt এবং দেবের জন্য VMWare ক্লাউড)। শঙ্কু- "কিউব" "বেয়ার মেটাল" (বেয়ার মেটাল) এর উপর বাস করে: এগুলি একই নোড যার 32টি CPU থ্রেড, 64-128 GB মেমরি এবং 300 GB SSD RAID 10 রয়েছে - এর মধ্যে মোট 50টি রয়েছে৷ তিনটি "পাতলা" নোড "মাস্টারদের" জন্য উত্সর্গীকৃত শঙ্কু- "কিউবা": 16 জিবি মেমরি, 12টি CPU থ্রেড।

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

CI/CD কিউবিক এবং অন্যান্য অবকাঠামো উপাদানগুলির জন্য আমরা একটি পৃথক GIT সার্ভার ব্যবহার করি, Helm 3 পারমাণবিক), জেনকিন্স, অ্যানসিবল এবং ডকার। আমরা বৈশিষ্ট্য শাখা পছন্দ করি এবং একই সংগ্রহস্থল থেকে বিভিন্ন পরিবেশে স্থাপন করি।

উপসংহার

এইভাবে, সাধারণ পরিভাষায়, DomClick-এ DevOps প্রক্রিয়াটি একজন অপারেশন ইঞ্জিনিয়ারের দিক থেকে দেখায়। নিবন্ধটি আমার প্রত্যাশার চেয়ে কম প্রযুক্তিগত বলে প্রমাণিত হয়েছে: তাই, Habré-এ DomClick সংবাদ অনুসরণ করুন: কুবারনেটস এবং আরও অনেক কিছু সম্পর্কে আরও "হার্ডকোর" নিবন্ধ থাকবে।

উত্স: www.habr.com