Kubernetes-এ প্রথম অ্যাপ্লিকেশন স্থাপন করার সময় পাঁচটি মিস হয়েছে

Aris Dreamer দ্বারা ব্যর্থ

অনেক লোক মনে করে যে কুবারনেটে অ্যাপ্লিকেশনটি স্থানান্তর করা যথেষ্ট (হয় হেলম ব্যবহার করে বা ম্যানুয়ালি) - এবং সেখানে সুখ থাকবে। কিন্তু সবকিছু এত সহজ নয়।

টীম Mail.ru ক্লাউড সলিউশন DevOps প্রকৌশলী জুলিয়ান Gindy দ্বারা একটি নিবন্ধ অনুবাদ. তিনি বলেন যে মাইগ্রেশন প্রক্রিয়া চলাকালীন তার কোম্পানি কী কী সমস্যার সম্মুখীন হয়েছিল যাতে আপনি একই রেকে পা না ফেলেন।

প্রথম ধাপ: পড অনুরোধ এবং সীমা সেট আপ করুন

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

পড অনুরোধ পডটিকে সর্বোত্তমভাবে স্থাপন করতে শিডিউলারের দ্বারা ব্যবহৃত প্রধান মান।

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

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

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

পড সীমা একটি পড জন্য একটি পরিষ্কার সীমা. ক্লাস্টারটি কন্টেইনারে বরাদ্দ করবে এমন সর্বাধিক পরিমাণ সম্পদের প্রতিনিধিত্ব করে।

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

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

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

দুর্ভাগ্যবশত, কোন মানগুলি সেট করতে হবে সে সম্পর্কে আমি নির্দিষ্ট নির্দেশনা দিতে পারি না, তবে আমরা নিজেরাই নিম্নলিখিত নিয়মগুলি মেনে চলি:

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

আমি লক্ষ্য করি যে উচ্চতর সংস্থান সীমা সময়সূচীকে আরও কঠিন করে তোলে কারণ পডের জন্য পর্যাপ্ত সংস্থান উপলব্ধ সহ একটি লক্ষ্য নোড প্রয়োজন।

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

ধাপ দুই: লাইভনেস এবং রেডিনেস টেস্ট সেট আপ করুন

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

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

লাইভনেস প্রোবগুলি সস্তা হওয়া উচিত, যেমন প্রচুর সংস্থান ব্যবহার করা উচিত নয়, কারণ তারা ঘন ঘন চালায় এবং কুবারনেটসকে জানানো উচিত যে অ্যাপ্লিকেশনটি চলছে৷

আপনি যদি প্রতি সেকেন্ডে চালানোর বিকল্প সেট করেন তবে এটি প্রতি সেকেন্ডে 1টি অনুরোধ যোগ করবে, তাই সচেতন থাকুন যে এই ট্র্যাফিক প্রক্রিয়া করার জন্য অতিরিক্ত সংস্থানগুলির প্রয়োজন হবে৷

আমাদের কোম্পানিতে, লাইভনেস টেস্টগুলি একটি অ্যাপ্লিকেশনের মূল উপাদানগুলি পরীক্ষা করে, এমনকি ডেটা (উদাহরণস্বরূপ, একটি দূরবর্তী ডেটাবেস বা ক্যাশে থেকে) সম্পূর্ণরূপে উপলব্ধ না হলেও৷

আমরা অ্যাপ্লিকেশনগুলিতে একটি "স্বাস্থ্য" এন্ডপয়েন্ট সেট আপ করেছি যা কেবল একটি 200 প্রতিক্রিয়া কোড প্রদান করে৷ এটি একটি ইঙ্গিত যে প্রক্রিয়াটি চলছে এবং অনুরোধগুলি পরিচালনা করতে সক্ষম (কিন্তু এখনও ট্র্যাফিক নয়)৷

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

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

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

আপনি যদি আপনার আবেদনের প্রস্তুতি পরীক্ষা করার জন্য ডাটাবেস অনুসন্ধান করার সিদ্ধান্ত নেন, তবে নিশ্চিত করুন যে এটি যতটা সম্ভব সস্তা। আসুন এই প্রশ্নটি নেওয়া যাক:

SELECT small_item FROM table LIMIT 1

কুবারনেটসে আমরা এই দুটি মান কীভাবে কনফিগার করি তার একটি উদাহরণ এখানে রয়েছে:

livenessProbe: 
 httpGet:   
   path: /api/liveness    
   port: http 
readinessProbe:  
 httpGet:    
   path: /api/readiness    
   port: http  periodSeconds: 2

আপনি কিছু অতিরিক্ত কনফিগারেশন বিকল্প যোগ করতে পারেন:

• initialDelaySeconds - কন্টেইনারের লঞ্চ এবং প্রোবের লঞ্চ শুরুর মধ্যে কত সেকেন্ড কেটে যাবে।
• periodSeconds - নমুনা রানের মধ্যে অপেক্ষার ব্যবধান।
• timeoutSeconds - সেকেন্ডের সংখ্যা যার পরে পডটিকে জরুরী হিসাবে বিবেচনা করা হয়। স্বাভাবিক সময়সীমা।
• failureThreshold পডে রিস্টার্ট সংকেত পাঠানোর আগে পরীক্ষার ব্যর্থতার সংখ্যা।
• successThreshold পড প্রস্তুত অবস্থায় রূপান্তরিত হওয়ার আগে সফল ট্রায়ালের সংখ্যা (পড শুরু হলে বা পুনরুদ্ধার করার ব্যর্থতার পরে)।

ধাপ তিন: পডের ডিফল্ট নেটওয়ার্ক নীতি সেট করা

কুবারনেটসের একটি "ফ্ল্যাট" নেটওয়ার্ক টপোগ্রাফি রয়েছে, ডিফল্টরূপে সমস্ত পড একে অপরের সাথে সরাসরি যোগাযোগ করে। কিছু কিছু ক্ষেত্রে এটা কাম্য নয়।

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

উদাহরণস্বরূপ, নিম্নলিখিত একটি সাধারণ নীতি যা একটি নির্দিষ্ট নামস্থানের জন্য সমস্ত আগত ট্র্যাফিক অস্বীকার করে:

---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:  
 name: default-deny-ingress
spec:  
 podSelector: {}  
 policyTypes:  
   - Ingress

এই কনফিগারেশনের ভিজ্যুয়ালাইজেশন:

(https://miro.medium.com/max/875/1*-eiVw43azgzYzyN1th7cZg.gif)
আরো বিশদ বিবরণ এখানে.

ধাপ চার: হুক এবং ইনিট পাত্রে কাস্টম আচরণ

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

সঙ্গে বিশেষ অসুবিধা দেখা দেয় nginx. আমরা লক্ষ্য করেছি যে এই পডগুলিকে ক্রমানুসারে স্থাপন করার সময়, সক্রিয় সংযোগগুলি সফলভাবে সম্পূর্ণ করার আগে বাধাপ্রাপ্ত হয়েছিল।

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

lifecycle: 
 preStop:
   exec:
     command: ["/usr/local/bin/nginx-killer.sh"]

এবং এখানে nginx-killer.sh:

#!/bin/bash
sleep 3
PID=$(cat /run/nginx.pid)
nginx -s quit
while [ -d /proc/$PID ]; do
   echo "Waiting while shutting down nginx..."
   sleep 10
done

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

আরেকটি সাধারণ স্কিম হল init কন্টেইনারে গোপনীয়তা অ্যাক্সেস করা, যা এই শংসাপত্রগুলিকে প্রধান মডিউলে প্রদান করে, যা মূল অ্যাপ্লিকেশন মডিউল থেকে গোপনীয়তায় অননুমোদিত অ্যাক্সেসকে বাধা দেয়।

যথারীতি, ডকুমেন্টেশন থেকে একটি উদ্ধৃতি: init কন্টেইনারগুলি নিরাপদে ব্যবহারকারী কোড বা ইউটিলিটি চালায় যা অন্যথায় অ্যাপ্লিকেশনের কন্টেইনার চিত্রের নিরাপত্তার সাথে আপস করবে। অপ্রয়োজনীয় টুলসকে আলাদা রেখে, আপনি অ্যাপ্লিকেশানের কন্টেইনার ইমেজের অ্যাটাক সারফেস সীমিত করেন।

ধাপ পাঁচ: কার্নেল কনফিগারেশন

অবশেষে, আসুন আরও উন্নত কৌশল সম্পর্কে কথা বলি।

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

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

initContainers:
  - name: sysctl
     image: alpine:3.10
     securityContext:
         privileged: true
      command: ['sh', '-c', "sysctl -w net.core.somaxconn=32768"]

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

উপসংহার ইন

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

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

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

সর্বদা নিজেকে এই প্রশ্নগুলি জিজ্ঞাসা করুন:

1. অ্যাপ্লিকেশনগুলি কতগুলি সংস্থান গ্রহণ করে এবং কীভাবে এই পরিমাণ পরিবর্তন হবে?
2. প্রকৃত স্কেলিং প্রয়োজনীয়তা কি? অ্যাপটি গড়ে কত ট্র্যাফিক পরিচালনা করবে? পিক ট্রাফিক সম্পর্কে কি?
3. কত ঘন ঘন পরিষেবা স্কেল আউট প্রয়োজন হবে? ট্র্যাফিক পেতে কত দ্রুত নতুন পড আপ এবং চলমান প্রয়োজন?
4. কিভাবে gracefully পড বন্ধ না? এটা কি আদৌ প্রয়োজনীয়? ডাউনটাইম ছাড়াই কি স্থাপনা অর্জন করা সম্ভব?
5. কিভাবে নিরাপত্তা ঝুঁকি কমানো যায় এবং কোনো আপস করা পড থেকে ক্ষতি সীমিত করা যায়? কোনো পরিষেবার কি অনুমতি বা অ্যাক্সেস আছে যা তাদের প্রয়োজন নেই?

Kubernetes একটি অবিশ্বাস্য প্ল্যাটফর্ম প্রদান করে যা আপনাকে একটি ক্লাস্টারে হাজার হাজার পরিষেবা স্থাপনের জন্য সর্বোত্তম অনুশীলন ব্যবহার করতে দেয়। যাইহোক, সব অ্যাপ্লিকেশন ভিন্ন. কখনও কখনও বাস্তবায়ন একটু বেশি কাজ প্রয়োজন.

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

আর কি পড়তে হবে:

1. উৎপাদন পরিবেশে কন্টেইনার এবং কুবারনেট চালানোর জন্য সর্বোত্তম অনুশীলন এবং সর্বোত্তম অনুশীলন.
2. কুবারনেটসের জন্য 90+ দরকারী টুল: স্থাপনা, ব্যবস্থাপনা, পর্যবেক্ষণ, নিরাপত্তা এবং আরও অনেক কিছু.
3. টেলিগ্রামে আমাদের চ্যানেল আরাউন্ড কুবারনেটস.

উত্স: www.habr.com