GitLab.com কে Kubernetes-এ স্থানান্তরিত করার এক বছর থেকে আমাদের ফলাফল

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

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

GitLab.com এর শুরু থেকে, এর সার্ভারগুলি ভার্চুয়াল মেশিনে ক্লাউডে চলছে। এই ভার্চুয়াল মেশিনগুলি শেফ দ্বারা পরিচালিত হয় এবং আমাদের ব্যবহার করে ইনস্টল করা হয় অফিসিয়াল লিনাক্স প্যাকেজ. স্থাপনার কৌশল অ্যাপ্লিকেশনটি আপডেট করার প্রয়োজন হলে, CI পাইপলাইন ব্যবহার করে একটি সমন্বিত অনুক্রমিক পদ্ধতিতে সার্ভার ফ্লিট আপডেট করা। এই পদ্ধতি, যদিও ধীর এবং একটু বিরক্তিকর - নিশ্চিত করে যে GitLab.com স্বতন্ত্র ব্যবহারকারীদের মতো একই ইনস্টলেশন এবং কনফিগারেশন পদ্ধতি ব্যবহার করে (স্ব-পরিচালিত) এর জন্য আমাদের লিনাক্স প্যাকেজগুলি ব্যবহার করে গিটল্যাব ইনস্টলেশন।

আমরা এই পদ্ধতিটি ব্যবহার করি কারণ সম্প্রদায়ের গড় সদস্যরা যখন তাদের গিটল্যাবের কপিগুলি ইনস্টল এবং কনফিগার করে তখন যে ব্যথা এবং আনন্দের মধ্য দিয়ে যায় তা অনুভব করা গুরুত্বপূর্ণ। এই পদ্ধতিটি কিছু সময়ের জন্য ভাল কাজ করেছিল, কিন্তু যখন গিটল্যাবে প্রকল্পের সংখ্যা 10 মিলিয়ন ছাড়িয়ে যায়, তখন আমরা বুঝতে পারি যে এটি আর আমাদের স্কেলিং এবং স্থাপনার চাহিদা পূরণ করে না।

Kubernetes এবং ক্লাউড-নেটিভ গিটল্যাবের দিকে প্রথম পদক্ষেপ

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

ক্লাউড নেটিভ এবং কুবারনেটসের উপর ফোকাস আমাদের প্রকৌশলীদেরকে ধীরে ধীরে পরিবর্তনের জন্য পরিকল্পনা করার অনুমতি দিয়েছে, এই সময়ে আমরা নতুন বৈশিষ্ট্যগুলি বিকাশ করার সাথে সাথে অ্যাপ্লিকেশনের কিছু NAS নির্ভরতা বাদ দিয়েছি। যেহেতু আমরা 2019 সালের গ্রীষ্মে আমাদের মাইগ্রেশনের পরিকল্পনা শুরু করেছি, এই বিধিনিষেধগুলির মধ্যে অনেকগুলি সরানো হয়েছে এবং GitLab.com-কে Kubernetes-এ স্থানান্তরিত করার প্রক্রিয়া এখন ভালভাবে চলছে!

Kubernetes-এ GitLab.com-এর বৈশিষ্ট্য

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

ফ্রন্টএন্ডের ক্ষেত্রে, এই প্রকারগুলি ওয়েব, API, Git SSH/HTTPS এবং রেজিস্ট্রির অনুরোধে বিভক্ত। ব্যাকএন্ডের ক্ষেত্রে, আমরা বিভিন্ন বৈশিষ্ট্যের উপর নির্ভর করে সারিতে থাকা কাজগুলিকে বিভক্ত করি পূর্বনির্ধারিত সম্পদ সীমানা, যা আমাদের বিভিন্ন কাজের চাপের জন্য পরিষেবা-স্তরের উদ্দেশ্য (SLOs) সেট করতে দেয়।

এই সমস্ত GitLab.com পরিষেবাগুলি একটি অপরিবর্তিত গিটল্যাব হেলম চার্টের সাথে কনফিগার করা হয়েছে৷ কনফিগারেশন সাব-চার্টে করা হয় যা বেছে বেছে সক্রিয় করা যেতে পারে কারণ আমরা ধীরে ধীরে ক্লাস্টারে পরিষেবাগুলি স্থানান্তর করি। এমনকি আমাদের কিছু রাষ্ট্রীয় পরিষেবা যেমন Redis, Postgres, GitLab Pages এবং Gitalyকে মাইগ্রেশনে অন্তর্ভুক্ত না করার সিদ্ধান্ত নিয়েও, Kubernetes ব্যবহার করা আমাদের বর্তমানে শেফ দ্বারা পরিচালিত VM-এর সংখ্যা ব্যাপকভাবে হ্রাস করতে দেয়।

কুবারনেটসের স্বচ্ছতা এবং কনফিগারেশন ব্যবস্থাপনা

সমস্ত সেটিংস গিটল্যাব নিজেই পরিচালনা করে। এর জন্য Terraform এবং Helm ভিত্তিক তিনটি কনফিগারেশন প্রকল্প ব্যবহার করা হয়। আমরা গিটল্যাব চালানোর জন্য যেখানেই সম্ভব গিটল্যাব ব্যবহার করার চেষ্টা করি, কিন্তু অপারেশনাল কাজের জন্য আমাদের আলাদা গিটল্যাব ইনস্টলেশন আছে। GitLab.com-এর স্থাপনা এবং আপডেটগুলি সম্পাদন করার সময় GitLab.com-এর উপলব্ধতার উপর নির্ভর না করার জন্য এটি প্রয়োজনীয়।

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

• k8s-workloads/gitlab-com — গিটল্যাব হেলম-চার্টের জন্য GitLab.com কনফিগারেশন বাইন্ডিং;
• k8s-ওয়ার্কলোডস/গিটল্যাব-হেলমফাইলস - গিটল্যাব অ্যাপ্লিকেশনের সাথে সরাসরি সম্পর্কিত নয় এমন পরিষেবাগুলির জন্য কনফিগারেশন রয়েছে৷ এর মধ্যে রয়েছে লগিং এবং ক্লাস্টার নিরীক্ষণের জন্য কনফিগারেশন, সেইসাথে PlantUML-এর মতো সমন্বিত টুল;
• gitlab-com-পরিকাঠামো - Kubernetes এবং উত্তরাধিকার VM পরিকাঠামোর জন্য Terraform কনফিগারেশন। এখানে আপনি ক্লাস্টার চালানোর জন্য প্রয়োজনীয় সমস্ত সংস্থান কনফিগার করেন, যার মধ্যে ক্লাস্টার নিজেই, নোড পুল, পরিষেবা অ্যাকাউন্ট, IP ঠিকানা সংরক্ষণ।

পরিবর্তন করা হলে, সর্বজনীন ভিউ দেখানো হয়। সংক্ষিপ্ত সারাংশ ক্লাস্টারে পরিবর্তন করার আগে SRE বিশ্লেষণ করে একটি বিস্তারিত পার্থক্যের লিঙ্ক সহ।

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

মাইগ্রেশনের সময় আমরা যা শিখেছি

সরানোর সময়, অভিজ্ঞতা অর্জন করা হয়েছিল যে আমরা কুবারনেটসে নতুন স্থানান্তর এবং স্থাপনার জন্য আবেদন করি।

1. প্রাপ্যতা অঞ্চলের মধ্যে ট্রাফিকের কারণে খরচ বেড়েছে

GitLab.com-এ গিট স্টোরেজ ফ্লিটের জন্য দৈনিক বহির্গমন পরিসংখ্যান (প্রতিদিন বাইট)

Google তার নেটওয়ার্ককে অঞ্চলে ভাগ করে। সেগুলি, ঘুরে, প্রাপ্যতা অঞ্চলে (AZ) বিভক্ত। গিট হোস্টিং প্রচুর পরিমাণে ডেটার সাথে যুক্ত, তাই নেটওয়ার্ক এগ্রেস নিয়ন্ত্রণ করা আমাদের জন্য গুরুত্বপূর্ণ। অভ্যন্তরীণ ট্র্যাফিকের ক্ষেত্রে, শুধুমাত্র একটি প্রাপ্যতা অঞ্চলের সীমানার মধ্যে থাকলেই প্রস্থান মুক্ত। এই লেখার সময়, আমরা একটি সাধারণ ব্যবসায়িক দিনে মোটামুটি 100TB ডেটা দিচ্ছি (এবং এটি শুধুমাত্র গিট সংগ্রহস্থলের জন্য)। আমাদের পুরানো VM-ভিত্তিক টপোলজিতে একই ভার্চুয়াল মেশিনে থাকা পরিষেবাগুলি এখন বিভিন্ন Kubernetes পডে চলে৷ এর মানে হল যে কিছু ট্র্যাফিক যা ভিএম-এ স্থানীয় ছিল তা সম্ভাব্যভাবে প্রাপ্যতা অঞ্চলের বাইরে যেতে পারে।

আঞ্চলিক GKE ক্লাস্টারগুলি আপনাকে রিডানড্যান্সির জন্য একাধিক প্রাপ্যতা অঞ্চলগুলিকে বিস্তৃত করার অনুমতি দেয়। আমরা সম্ভাবনা বিবেচনা করছি GKE আঞ্চলিক ক্লাস্টারকে একক-জোন ক্লাস্টারে বিভক্ত করুন পরিষেবাগুলির জন্য যা প্রচুর পরিমাণে ট্র্যাফিক তৈরি করে। এটি ক্লাস্টার স্তরে অপ্রয়োজনীয়তা বজায় রেখে বের হওয়ার খরচ কমাবে।

2. সীমা, সম্পদ অনুরোধ এবং স্কেলিং

registry.gitlab.com-এ প্রোডাকশন ট্র্যাফিক পরিচালনার প্রতিলিপির সংখ্যা। ~15:00 UTC-এ ট্রাফিক সর্বোচ্চ।

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

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

3. মেট্রিক্স এবং লগ

অবকাঠামো বিভাগ লেটেন্সি, ত্রুটির হার এবং প্রতিষ্ঠিত সহ স্যাচুরেশনের উপর দৃষ্টি নিবদ্ধ করে সেবা স্তরের লক্ষ্য (SLO) এর সাথে সংযুক্ত আমাদের সিস্টেমের সামগ্রিক প্রাপ্যতা.

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

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

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

4. নতুন ক্লাস্টারে ট্রাফিক পরিবর্তন করা

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

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

5. শুঁটির অতিরিক্ত শক্তি এবং তাদের ব্যবহার

প্রায় অবিলম্বে, নিম্নলিখিত সমস্যাটি চিহ্নিত করা হয়েছিল: রেজিস্ট্রি পরিষেবার জন্য পডগুলি দ্রুত শুরু হয়েছিল, কিন্তু Sidekiq-এর জন্য পডগুলি চালু হতে সময় নেয় দুই মিনিট. Sidekiq-এর দীর্ঘ চলমান পডগুলি একটি সমস্যা হয়ে দাঁড়ায় যখন আমরা কুবারনেটে কাজের চাপগুলি স্থানান্তরিত করা শুরু করি যাদের কাজগুলি দ্রুত প্রক্রিয়া করা এবং দ্রুত স্কেল করা দরকার।

এই ক্ষেত্রে, পাঠটি ছিল যখন Kubernetes-এর Horizontal Pod Autoscaler (HPA) ট্র্যাফিক বৃদ্ধিকে ভালভাবে পরিচালনা করে, তখন কাজের চাপের বৈশিষ্ট্যগুলিকে বিবেচনায় নেওয়া এবং অতিরিক্ত পডের ক্ষমতা বরাদ্দ করা গুরুত্বপূর্ণ (বিশেষত যখন চাহিদা অসম হয়)। আমাদের ক্ষেত্রে, হঠাৎ করে চাকরির বিস্ফোরণ ঘটেছিল, যার ফলে দ্রুত স্কেলিং হয়েছিল, যার ফলে আমরা নোড পুল স্কেল করার আগে CPU সংস্থানগুলির স্যাচুরেশনের দিকে পরিচালিত করে।

এটি সর্বদা একটি ক্লাস্টার থেকে যতটা সম্ভব চেপে নেওয়ার জন্য প্রলুব্ধ হয়, তবে আমরা প্রাথমিকভাবে পারফরম্যান্সের সমস্যায় পড়েছি এবং এখন একটি উদার পড বাজেট দিয়ে শুরু করেছি এবং SLO-তে গভীর নজর রেখে পরে এটিকে কমিয়ে আনছি। Sidekiq পরিষেবার জন্য পড চালু করা উল্লেখযোগ্যভাবে ত্বরান্বিত হয়েছে এবং এখন গড়ে প্রায় 40 সেকেন্ড সময় নেয়৷ পড স্টার্টআপ সময় হ্রাস থেকে GitLab.com এবং অফিসিয়াল গিটল্যাব হেলম চার্ট চলমান স্ব-পরিচালিত ইনস্টলেশনের ব্যবহারকারী উভয়ই জিতেছে।

উপসংহার

প্রতিটি পরিষেবা স্থানান্তরিত করার পরে, আমরা উৎপাদনে কুবারনেটস ব্যবহারের সুবিধাগুলিতে আনন্দিত হয়েছি: দ্রুত এবং নিরাপদ অ্যাপ্লিকেশন স্থাপনা, স্কেলিং, এবং আরও দক্ষ সম্পদ বরাদ্দ। অধিকন্তু, মাইগ্রেশনের সুবিধাগুলি GitLab.com পরিষেবার বাইরেও যায়৷ অফিসিয়াল হেলম চার্টে প্রতিটি উন্নতির সাথে, এর ব্যবহারকারীরাও উপকৃত হয়।

আমি আশা করি আপনি আমাদের Kubernetes মাইগ্রেশন অ্যাডভেঞ্চারের গল্পটি উপভোগ করেছেন। আমরা ক্লাস্টারে সমস্ত নতুন পরিষেবা স্থানান্তর করা চালিয়ে যাচ্ছি। নিম্নলিখিত প্রকাশনাগুলিতে অতিরিক্ত তথ্য পাওয়া যাবে:

• «কেন আমরা কুবারনেটে স্থানান্তরিত হচ্ছি?";
• «Kubernetes-এ GitLab.com";
• GitLab.com কে Kubernetes-এ স্থানান্তরিত করার মহাকাব্য.

অনুবাদক থেকে PS

আমাদের ব্লগেও পড়ুন:

• «কুবারনেটসের সাথে 3 বছর উৎপাদনে: আমরা যা বের করেছি তা এখানে";
• «কুবারনেটের 10টি সাধারণ ভুল";
• «উত্পাদনে কুবারনেটসের সাফল্যের গল্প। পার্ট 3: গিটহাব";
• «কুবারনেটসে টিন্ডারের রূপান্তর».

উত্স: www.habr.com