কুবারনেটস পড সংস্থানগুলি কীভাবে অ্যাক্সেস করবেন

তোহাদের পুরস্কার

Kubernetes দিয়ে শুরু করার সময়, কনটেইনার সংস্থানগুলি সেট আপ করার বিষয়ে ভুলে যাওয়া সাধারণ। এই মুহুর্তে, ডকার চিত্রটি কাজ করে এবং কুবারনেটস ক্লাস্টারে স্থাপন করা যেতে পারে তা নিশ্চিত করার জন্য এটি যথেষ্ট।

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

টীম Mail.ru থেকে Kubernetes aaS কনটেইনার রিসোর্স (সিপিইউ এবং এমইএম), রিকোয়েস্ট এবং রিসোর্স সীমাবদ্ধতা সম্পর্কে একটি নিবন্ধ অনুবাদ করেছে। আপনি এই সেটিংসের সুবিধাগুলি শিখবেন এবং আপনি সেগুলি সেট না করলে কী হবে তা শিখবেন৷

কম্পিউটিং সংস্থান

নিম্নলিখিত ইউনিটগুলির সাথে আমাদের কাছে দুটি ধরণের সংস্থান রয়েছে:

• কেন্দ্রীয় প্রক্রিয়াকরণ ইউনিট (CPU) - কোর;
• মেমরি (MEM) - বাইট।

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

• অনুরোধ করা পড রিসোর্স = সমস্ত পাত্রে অনুরোধ করা সম্পদের সমষ্টি;
• পড রিসোর্স লিমিট = সমস্ত পড রিসোর্স লিমিটের সমষ্টি।

apiVersion: v1
kind: Pod
metadata:
  name: backend-pod-name
  labels:
    application: backend
spec:
  containers:
    — name: main-container
      image: my-backend
      tag: v1
      ports:
      — containerPort: 8080
      resources:
        requests:
          cpu: 0.2 # REQUESTED CPU: 200m cores
          memory: "1Gi" # REQUESTED MEM: 1Gi
        limits:
          cpu: 1 # MAX CPU USAGE: 1 core
          memory: "1Gi" # MAX MEM USAGE:  1Gi
    — name: other-container
      image: other-app
      tag: v1
      ports:
      — containerPort: 8000
      resources:
        requests:
          cpu: "200m" # REQUESTED CPU: 200m cores
          memory: "0.5Gi" # REQUESTED MEM: 0.5Gi
        limits:
          cpu: 1 # MAX CPU USAGE: 1 core
          memory: "1Gi" # MAX MEM USAGE:  1Gi

অনুরোধ করা এবং সীমিত সম্পদের উদাহরণ

ক্ষেত্র resources.requested স্পেসিফিকেশন থেকে পড হল একটি উপাদান যা পছন্দসই নোড খুঁজে পেতে ব্যবহৃত হয়। আপনি ইতিমধ্যে এটির জন্য পড স্থাপনার পরিকল্পনা করতে পারেন। আপনি কিভাবে একটি উপযুক্ত নোড খুঁজে পাবেন?

Kubernetes একটি মাস্টার নোড বা মাস্টার নোড (Kubernetes কন্ট্রোল প্লেন) সহ বেশ কয়েকটি উপাদান নিয়ে গঠিত। মাস্টার নোডের বিভিন্ন প্রক্রিয়া রয়েছে: kube-apiserver, kube-controller-manager এবং kube-scheduler।

কুবে-শিডিউলার প্রক্রিয়াটি নতুন তৈরি করা পড পর্যালোচনা করার জন্য এবং অনুরোধ করা সংস্থানগুলির সংখ্যা সহ সমস্ত পড অনুরোধের সাথে মেলে এমন সম্ভাব্য কর্মী নোডগুলি খুঁজে বের করার জন্য দায়ী৷ কুবে-শিডিউলার দ্বারা পাওয়া নোডের তালিকাটি স্থান পেয়েছে। পড সর্বোচ্চ স্কোর সঙ্গে নোড উপর নির্ধারিত হয়.

বেগুনি পোড কোথায় স্থাপন করা হবে?

ছবিতে আপনি দেখতে পাচ্ছেন যে কুবে-শিডিউলারের একটি নতুন বেগুনি পড নির্ধারণ করা উচিত। কুবারনেটস ক্লাস্টারে দুটি নোড রয়েছে: A এবং B। আপনি দেখতে পাচ্ছেন, kube-শিডিউলার নোড A-তে একটি পড নির্ধারণ করতে পারে না - উপলব্ধ (অনিবেদিত) সংস্থানগুলি বেগুনি পডের অনুরোধের সাথে মেলে না। সুতরাং, বেগুনি পড দ্বারা অনুরোধ করা 1 জিবি মেমরি নোড A-তে ফিট হবে না, যেহেতু উপলব্ধ মেমরিটি 0,5 GB। কিন্তু নোড বি-তে যথেষ্ট সম্পদ রয়েছে। ফলস্বরূপ, কুবে-নির্ধারক সিদ্ধান্ত নেয় যে বেগুনি পডের গন্তব্য নোড বি।

এখন আমরা জানি কিভাবে অনুরোধ করা সম্পদ পড চালানোর জন্য নোডের পছন্দকে প্রভাবিত করে। কিন্তু প্রান্তিক সম্পদের প্রভাব কী?

সম্পদ সীমা হল একটি সীমানা যা CPU/MEM অতিক্রম করতে পারে না। যাইহোক, সিপিইউ রিসোর্স নমনীয়, তাই যে কন্টেইনারগুলি তাদের সিপিইউ সীমাতে পৌঁছেছে সেগুলি পড থেকে প্রস্থান করবে না। পরিবর্তে, CPU থ্রটলিং শুরু হবে। MEM ব্যবহারের সীমা পৌঁছে গেলে, OOM-Killer-এর কারণে কন্টেইনারটি বন্ধ হয়ে যাবে এবং RestartPolicy সেটিংস দ্বারা অনুমোদিত হলে পুনরায় চালু করা হবে।

অনুরোধ করা হয়েছে এবং বিস্তারিত সর্বাধিক সম্পদ

ডকার এবং কুবারনেটসের মধ্যে সম্পদ যোগাযোগ

রিসোর্স রিকোয়েস্ট এবং রিসোর্স লিমিট কিভাবে কাজ করে তা ব্যাখ্যা করার সর্বোত্তম উপায় হল কুবারনেটস এবং ডকারের মধ্যে সম্পর্ক প্রবর্তন করা। উপরের ছবিতে আপনি দেখতে পাচ্ছেন কিভাবে কুবারনেটস ক্ষেত্র এবং ডকার স্টার্টআপ পতাকা সম্পর্কিত।

মেমরি: অনুরোধ এবং সীমাবদ্ধতা

containers:
...
 resources:
   requests:
     memory: "0.5Gi"
   limits:
     memory: "1Gi"

উপরে উল্লিখিত হিসাবে, মেমরি বাইটে পরিমাপ করা হয়। উপর ভিত্তি করে কুবারনেটস ডকুমেন্টেশন, আমরা একটি সংখ্যা হিসাবে মেমরি নির্দিষ্ট করতে পারেন. সাধারণত এটি একটি পূর্ণসংখ্যা, উদাহরণস্বরূপ 2678 - অর্থাৎ 2678 বাইট। আপনি প্রত্যয় ব্যবহার করতে পারেন G и Gi, প্রধান জিনিস মনে রাখা হয় যে তারা সমতুল্য নয়। প্রথমটি দশমিক এবং দ্বিতীয়টি বাইনারি। k8s ডকুমেন্টেশনে উল্লিখিত উদাহরণের মতো: 128974848, 129e6, 129M, 123Mi - তারা কার্যত সমতুল্য।

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

আপনি একটি অনুরোধের জন্য অপর্যাপ্ত মেমরি সেট করলে কি হবে?

যদি ধারকটি অনুরোধকৃত মেমরির সীমাতে পৌঁছে যায়, তাহলে পডটিকে পডের একটি গ্রুপে স্থাপন করা হয় যা নোডে পর্যাপ্ত মেমরি না থাকলে বন্ধ হয়ে যায়।

আপনি মেমরি সীমা খুব কম সেট করলে কি হবে?

যদি ধারকটি মেমরির সীমা অতিক্রম করে তবে এটি OOM-Killed এর কারণে বন্ধ হয়ে যাবে। এবং রিস্টার্ট পলিসির উপর ভিত্তি করে সম্ভব হলে পুনরায় চালু হবে যেখানে ডিফল্ট মান রয়েছে Always.

আপনি অনুরোধ করা মেমরি নির্দিষ্ট না হলে কি হবে?

Kubernetes সীমা মান নেবে এবং এটিকে ডিফল্ট মান হিসাবে সেট করবে।

আপনি একটি মেমরি সীমা নির্দিষ্ট না হলে কি ঘটতে পারে?

ধারকটির কোন বিধিনিষেধ নেই; এটি যতটা চায় ততটা মেমরি ব্যবহার করতে পারে। যদি সে নোডের সমস্ত উপলব্ধ মেমরি ব্যবহার করা শুরু করে, তাহলে OOM তাকে হত্যা করবে। RestartPolicy এর উপর ভিত্তি করে সম্ভব হলে কন্টেইনারটি পুনরায় চালু করা হবে।

আপনি মেমরির সীমা নির্দিষ্ট না করলে কি হবে?

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

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

এটি সাধারণত জন্য একই মান সেট করার সুপারিশ করা হয় request.memory и limit.memory. এটি নিশ্চিত করে যে কুবারনেটস পড চালানোর জন্য যথেষ্ট মেমরি আছে কিন্তু এটি চালানোর জন্য যথেষ্ট নয় এমন একটি নোডে একটি পড নির্ধারণ করবে না। মনে রাখবেন: Kubernetes Pod পরিকল্পনা শুধুমাত্র অ্যাকাউন্টে নেয় requests.memoryএবং limits.memory বিবেচনায় নেয় না।

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

containers:
...
 resources:
   requests:
     cpu: 1
   limits:
     cpu: "1200m"

একটি CPU এর সাথে সবকিছু একটু বেশি জটিল। কুবারনেটস এবং ডকারের মধ্যে সম্পর্কের ছবিতে ফিরে আপনি তা দেখতে পারেন request.cpu অনুরূপ --cpu-sharesযেখানে limit.cpu পতাকার সাথে মিলে যায় cpus ডকারে

কুবারনেটস যে সিপিইউকে অনুরোধ করে সেটিকে 1024 দ্বারা গুণ করা হয়, যা CPU চক্রের অনুপাত। আপনি 1 সম্পূর্ণ কোর অনুরোধ করতে চান, আপনি যোগ করতে হবে cpu: 1উপরে প্রদর্শিতভাবে.

একটি সম্পূর্ণ কার্নেল (অনুপাত = 1024) অনুরোধ করার অর্থ এই নয় যে আপনার ধারক এটি গ্রহণ করবে৷ যদি আপনার হোস্ট মেশিনে শুধুমাত্র একটি কোর থাকে এবং আপনি একাধিক কন্টেইনার চালাচ্ছেন, তাহলে সমস্ত কন্টেইনারকে অবশ্যই তাদের মধ্যে উপলব্ধ CPU শেয়ার করতে হবে। এটা কিভাবে হয়? চলুন ছবিটা দেখি।

CPU অনুরোধ - একক কোর সিস্টেম

আসুন কল্পনা করুন যে আপনার একটি একক-কোর হোস্ট সিস্টেম চলমান পাত্রে আছে। মা (কুবারনেটস) একটি পাই (সিপিইউ) বেক করেছেন এবং এটি শিশুদের (পাত্রে) মধ্যে ভাগ করতে চান। তিনটি শিশু একটি আস্ত পাই (অনুপাত = 1024) চায়, আরেকটি শিশু হাফ পাই (512) চায়। মা ন্যায্য হতে চায় এবং একটি সহজ হিসাব করে।

# Сколько пирогов хотят дети?
# 3 ребенка хотят по целому пирогу и еще один хочет половину пирога
cakesNumberKidsWant = (3 * 1) + (1 * 0.5) = 3.5
# Выражение получается так:
3 (ребенка/контейнера) * 1 (целый пирог/полное ядро) + 1 (ребенок/контейнер) * 0.5 (половина пирога/половина ядра)
# Сколько пирогов испечено?
availableCakesNumber = 1
# Сколько пирога (максимально) дети реально могут получить?
newMaxRequest = 1 / 3.5 =~ 28%

গণনার উপর ভিত্তি করে, তিনটি শিশু কোরের 28% পাবে, পুরো কোর নয়। চতুর্থ শিশুটি সম্পূর্ণ কার্নেলের 14% পাবে, অর্ধেক নয়। আপনার যদি মাল্টি-কোর সিস্টেম থাকে তবে জিনিসগুলি আলাদা হবে।

CPU অনুরোধ - মাল্টি-কোর (4) সিস্টেম

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

সিপিইউ কীভাবে পাত্রে বিতরণ করা হয় তা বোঝার জন্য উপরের গণনাগুলি সরল করা হয়েছে। অবশ্যই, কন্টেইনারগুলি ছাড়াও, অন্যান্য প্রক্রিয়া রয়েছে যা CPU সংস্থানগুলিও ব্যবহার করে। যখন একটি পাত্রে প্রক্রিয়াগুলি নিষ্ক্রিয় থাকে, অন্যরা এর সংস্থান ব্যবহার করতে পারে। CPU: "200m" অনুরূপ CPU: 0,2, যার অর্থ একটি কোরের প্রায় 20%।

এখন এর সম্পর্কে কথা বলা যাক limit.cpu. কুবারনেটস যে CPU সীমাবদ্ধ করে তা 100 দ্বারা গুণিত হয়। ফলাফল হল প্রতি 100 µs (cpu-period).

limit.cpu ডকার পতাকার সাথে মেলে --cpus. এটি পুরানো একটি নতুন সমন্বয় --cpu-period и --cpu-quota. এটি সেট করে, আমরা থ্রটলিং শুরু করার আগে কন্টেইনারটি সর্বাধিক কতগুলি উপলব্ধ CPU সংস্থান ব্যবহার করতে পারে তা নির্দেশ করি:

• সিপিইউ - সংমিশ্রণ cpu-period и cpu-quota. cpus = 1.5 সেটিং এর সমতুল্য cpu-period = 100000 и cpu-quota = 150000;
• CPU-কাল - সময়কাল CPU CFS সময়সূচী, ডিফল্ট 100 মাইক্রোসেকেন্ড;
• cpu-কোটা - ভিতরে মাইক্রোসেকেন্ডের সংখ্যা cpu-period, যা ধারক দ্বারা আবদ্ধ হয়.

আপনি অপর্যাপ্ত অনুরোধকৃত CPU ইনস্টল করলে কি হবে?

কন্টেইনারটি ইনস্টল করার চেয়ে বেশি প্রয়োজন হলে, এটি অন্যান্য প্রক্রিয়া থেকে CPU চুরি করবে।

আপনি CPU সীমা খুব কম সেট করলে কি হবে?

যেহেতু CPU রিসোর্স সামঞ্জস্যযোগ্য, তাই থ্রটলিং চালু হবে।

আপনি একটি CPU অনুরোধ নির্দিষ্ট না করলে কি হবে?

মেমরির মতো, অনুরোধের মান সীমার সমান।

আপনি একটি CPU সীমা নির্দিষ্ট না করলে কি হবে?

কন্টেইনার যতটা প্রয়োজন ততটা সিপিইউ ব্যবহার করবে। যদি একটি ডিফল্ট CPU নীতি (LimitRange) নামস্থানে সংজ্ঞায়িত করা হয়, তাহলে এই সীমাটি কন্টেইনারের জন্যও ব্যবহৃত হয়।

আপনি একটি অনুরোধ বা একটি CPU সীমা নির্দিষ্ট না হলে কি হবে?

স্মৃতির মতো, এটি সবচেয়ে খারাপ-কেস পরিস্থিতি। সময়সূচী জানেন না আপনার ধারকটির কতগুলি সংস্থান প্রয়োজন এবং এটি নোডে গুরুতর সমস্যা সৃষ্টি করতে পারে। এটি এড়ানোর জন্য, আপনাকে নামস্থানের জন্য ডিফল্ট সীমা সেট করতে হবে (LimitRange)।

মনে রাখবেন: আপনি যদি নোডগুলি সরবরাহ করতে পারে তার চেয়ে বেশি CPU অনুরোধ করেন, পড নির্ধারিত হবে না। Requests.cpu - ন্যূনতম মান নয়, পড শুরু করতে এবং ব্যর্থতা ছাড়াই কাজ করার জন্য যথেষ্ট মান। অ্যাপ্লিকেশন জটিল গণনা সঞ্চালন না হলে, সেরা বিকল্প ইনস্টল করা হয় request.cpu <= 1 এবং প্রয়োজন হিসাবে অনেক প্রতিলিপি চালু করুন.

অনুরোধ করা সম্পদ বা সম্পদ সীমা আদর্শ পরিমাণ

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

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

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

উদাহরণ হিসেবে এটি দেখুন গ্রাফানা ড্যাশবোর্ড. এটি অনুরোধ করা সংস্থান বা সংস্থান সীমা এবং বর্তমান সংস্থান ব্যবহারের মধ্যে পার্থক্য প্রদর্শন করে।

উপসংহার

রিসোর্স অনুরোধ করা এবং সীমিত করা আপনার Kubernetes ক্লাস্টারকে সুস্থ রাখতে সাহায্য করে। সঠিক সীমা কনফিগারেশন খরচ কমিয়ে দেয় এবং অ্যাপ্লিকেশনগুলিকে সর্বদা চলমান রাখে।

সংক্ষেপে, মনে রাখতে কয়েকটি বিষয় রয়েছে:

1. অনুরোধ করা সম্পদ হল একটি কনফিগারেশন যা স্টার্টআপের সময় বিবেচনা করা হয় (যখন কুবারনেটস অ্যাপ্লিকেশন হোস্ট করার পরিকল্পনা করে)। বিপরীতে, রানটাইমে সংস্থান সীমিত করা গুরুত্বপূর্ণ - যখন অ্যাপ্লিকেশনটি ইতিমধ্যে নোডে চলছে।
2. মেমরির তুলনায়, CPU একটি নিয়ন্ত্রিত সম্পদ। পর্যাপ্ত CPU না থাকলে, আপনার পড বন্ধ হবে না এবং থ্রটলিং মেকানিজম চালু হবে।
3. অনুরোধ করা সম্পদ এবং সম্পদ সীমা সর্বনিম্ন এবং সর্বোচ্চ মান নয়! অনুরোধ করা সংস্থানগুলি সংজ্ঞায়িত করে, আপনি নিশ্চিত করুন যে অ্যাপ্লিকেশনটি সমস্যা ছাড়াই চলবে।
4. একটি ভাল অভ্যাস হল মেমরি অনুরোধ মেমরি সীমার সমান সেট করা।
5. ঠিক আছে ইন্সটল করার অনুরোধ করা হলো CPU <=1, যদি অ্যাপ্লিকেশনটি জটিল গণনা না করে।
6. আপনি যদি একটি নোডে উপলব্ধের চেয়ে বেশি সংস্থানগুলির জন্য অনুরোধ করেন তবে পড কখনই সেই নোডে নির্ধারিত হবে না।
7. অনুরোধকৃত সম্পদ/সম্পদ সীমার সঠিক পরিমাণ নির্ধারণ করতে, লোড পরীক্ষা এবং পর্যবেক্ষণ ব্যবহার করুন।

আমি আশা করি এই নিবন্ধটি আপনাকে সম্পদ সীমাবদ্ধতার মৌলিক ধারণা বুঝতে সাহায্য করবে। এবং আপনি আপনার কাজে এই জ্ঞান প্রয়োগ করতে সক্ষম হবেন।

সৌভাগ্য কামনা করছি!

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

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

উত্স: www.habr.com