এটি এই বিভাগটির বহু পৃষ্ঠার মুদ্রণযোগ্য দর্শন। মুদ্রণ করতে এখানে ক্লিক করুন.

এই পৃষ্ঠার নিয়মিত দৃশ্যে ফিরে আসুন.

ক্লাস্টার আর্কিটেকচার

কুবারনেটিসের পিছনে আর্কিটেকচারের ধারণা ।
কুবারনেটিসের উপাদান

কুবারনেটিস ক্লাস্টার আর্কিটেকচার

1 - নোড

Kubernetes আপনার workload চালায় কন্টেইনারগুলিকে পডে রেখে নোডে চালানোর জন্য। একটি নোড ক্লাস্টারের উপর নির্ভর করে একটি ভার্চুয়াল বা ফিজিক্যাল মেশিন হতে পারে। প্রতিটি নোড control plane দ্বারা পরিচালিত হয় এবং Pods চালানোর জন্য প্রয়োজনীয় সেবা ধারণ করে।

সাধারণত একটি ক্লাস্টারে আপনার বেশ কয়েকটি নোড থাকে; একটি শেখার বা সীমিত সম্পদের পরিবেশে, আপনার কেবল একটি নোড থাকতে পারে।

একটি নোডের কম্পোনেন্ট এর মধ্যে রয়েছে kubelet, একটি container runtime, এবং kube-proxy।

ব্যবস্থাপনা

API server এ নোড যোগ করার দুটি প্রধান উপায় রয়েছে:

  1. একটি নোডের kubelet নিজেই control plane এ নিবন্ধন করে
  2. আপনি (বা অন্য কোনো মানব ব্যবহারকারী) ম্যানুয়ালি একটি নোড অবজেক্ট যোগ করেন

আপনি একটি নোড object তৈরি করার পরে, বা একটি নোডের kubelet নিজেই নিবন্ধন করার পরে, control plane পরীক্ষা করে যে নতুন নোড অবজেক্টটি বৈধ কিনা। উদাহরণস্বরূপ, আপনি যদি নিম্নলিখিত JSON ম্যানিফেস্ট থেকে একটি নোড তৈরি করার চেষ্টা করেন:

{
  "kind": "Node",
  "apiVersion": "v1",
  "metadata": {
    "name": "10.240.79.157",
    "labels": {
      "name": "my-first-k8s-node"
    }
  }
}

Kubernetes অভ্যন্তরীণভাবে একটি নোড অবজেক্ট তৈরি করে (প্রতিনিধিত্ব)। Kubernetes পরীক্ষা করে যে একটি kubelet API সার্ভারে নিবন্ধিত হয়েছে যা নোডের metadata.name ফিল্ডের সাথে মেলে। যদি নোডটি সুস্থ থাকে (অর্থাৎ সমস্ত প্রয়োজনীয় সেবা চলছে), তাহলে এটি একটি পড চালানোর যোগ্য। অন্যথায়, সেই নোডটি সুস্থ না হওয়া পর্যন্ত যেকোনো ক্লাস্টার কার্যকলাপের জন্য উপেক্ষা করা হয়।

একটি নোড অবজেক্টের নাম অবশ্যই একটি বৈধ DNS subdomain name হতে হবে।

নোড নামের অনন্যতা

name একটি নোড সনাক্ত করে। দুটি নোড একই সময়ে একই নাম থাকতে পারে না। Kubernetes এটাও ধরে নেয় যে একই নামের একটি রিসোর্স একই অবজেক্ট। একটি নোডের ক্ষেত্রে, এটি অন্তর্নিহিতভাবে ধরে নেওয়া হয় যে একই নাম ব্যবহার করে একটি ইনস্ট্যান্স একই অবস্থা (যেমন নেটওয়ার্ক সেটিংস, রুট ডিস্ক কন্টেন্ট) এবং বৈশিষ্ট্য যেমন নোড লেবেল থাকবে। এটি অসঙ্গতির দিকে নিয়ে যেতে পারে যদি একটি ইনস্ট্যান্স তার নাম পরিবর্তন না করে পরিবর্তিত হয়। যদি নোডটি প্রতিস্থাপন বা উল্লেখযোগ্যভাবে আপডেট করার প্রয়োজন হয়, তাহলে বিদ্যমান নোড অবজেক্টটি প্রথমে API সার্ভার থেকে সরিয়ে ফেলতে হবে এবং আপডেটের পরে পুনরায় যোগ করতে হবে।

নোডের স্ব-নিবন্ধন

যখন kubelet ফ্ল্যাগ --register-node সত্য থাকে (ডিফল্ট), kubelet নিজেকে API সার্ভারে নিবন্ধন করার চেষ্টা করবে। এটি পছন্দের প্যাটার্ন, যা বেশিরভাগ ডিস্ট্রো দ্বারা ব্যবহৃত হয়।

স্ব-নিবন্ধনের জন্য, kubelet নিম্নলিখিত অপশনগুলির সাথে শুরু হয়:

  • --kubeconfig - API সার্ভারে নিজেকে প্রমাণীকরণ করার জন্য শংসাপত্রের পথ।

  • --cloud-provider - নিজের সম্পর্কে মেটাডেটা পড়তে cloud provider এর সাথে কীভাবে কথা বলতে হয়।

  • --register-node - স্বয়ংক্রিয়ভাবে API সার্ভারে নিবন্ধন করুন।

  • --register-with-taints - প্রদত্ত taints এর তালিকা সহ নোড নিবন্ধন করুন (কমা দ্বারা পৃথক <key>=<value>:<effect>)।

    register-node মিথ্যা হলে কোনো অপারেশন নেই।

  • --node-ip - নোডের জন্য IP ঠিকানাগুলির ঐচ্ছিক কমা-পৃথক তালিকা। আপনি প্রতিটি ঠিকানা পরিবারের জন্য শুধুমাত্র একটি একক ঠিকানা নির্দিষ্ট করতে পারেন। উদাহরণস্বরূপ, একটি একক-স্ট্যাক IPv4 ক্লাস্টারে, আপনি এই মানটি IPv4 ঠিকানা হিসাবে সেট করেন যা kubelet নোডের জন্য ব্যবহার করা উচিত। একটি ডুয়াল-স্ট্যাক ক্লাস্টার চালানোর বিস্তারিত জানতে configure IPv4/IPv6 dual stack দেখুন।

    আপনি যদি এই আর্গুমেন্ট প্রদান না করেন, kubelet নোডের ডিফল্ট IPv4 ঠিকানা ব্যবহার করে, যদি থাকে; যদি নোডের কোনো IPv4 ঠিকানা না থাকে তাহলে kubelet নোডের ডিফল্ট IPv6 ঠিকানা ব্যবহার করে।

  • --node-labels - ক্লাস্টারে নোড নিবন্ধন করার সময় যোগ করার জন্য Labels (NodeRestriction admission plugin দ্বারা প্রয়োগ করা লেবেল সীমাবদ্ধতা দেখুন)।

  • --node-status-update-frequency - kubelet কত ঘন ঘন তার নোড স্ট্যাটাস API সার্ভারে পোস্ট করে তা নির্দিষ্ট করে।

যখন Node authorization mode এবং NodeRestriction admission plugin সক্রিয় থাকে, kubelet শুধুমাত্র তাদের নিজস্ব নোড রিসোর্স তৈরি/পরিবর্তন করার জন্য অনুমোদিত।

ম্যানুয়াল নোড প্রশাসন

আপনি kubectl ব্যবহার করে নোড অবজেক্ট তৈরি এবং পরিবর্তন করতে পারেন।

যখন আপনি ম্যানুয়ালি নোড অবজেক্ট তৈরি করতে চান, kubelet ফ্ল্যাগ --register-node=false সেট করুন।

আপনি --register-node এর সেটিং নির্বিশেষে নোড অবজেক্ট পরিবর্তন করতে পারেন। উদাহরণস্বরূপ, আপনি একটি বিদ্যমান নোডে লেবেল সেট করতে পারেন বা এটিকে আনশিডিউলেবল চিহ্নিত করতে পারেন।

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

একটি নোডকে আনশিডিউলেবল হিসাবে চিহ্নিত করা শিডিউলারকে সেই নোডে নতুন পড স্থাপন করা থেকে বিরত রাখে কিন্তু নোডে বিদ্যমান পডগুলিকে প্রভাবিত করে না। এটি একটি নোড রিবুট বা অন্যান্য রক্ষণাবেক্ষণের আগে একটি প্রস্তুতিমূলক পদক্ষেপ হিসাবে উপযোগী।

একটি নোডকে আনশিডিউলেবল চিহ্নিত করতে, চালান:

kubectl cordon $NODENAME

আরও বিস্তারিত জানতে Safely Drain a Node দেখুন।

নোড স্ট্যাটাস

একটি নোডের স্ট্যাটাস নিম্নলিখিত তথ্য ধারণ করে:

আপনি একটি নোডের স্ট্যাটাস এবং অন্যান্য বিস্তারিত দেখতে kubectl ব্যবহার করতে পারেন:

kubectl describe node <insert-node-name-here>

আরও বিস্তারিত জানতে Node Status দেখুন।

নোড হার্টবিট

Kubernetes নোড দ্বারা পাঠানো হার্টবিট, আপনার ক্লাস্টারকে প্রতিটি নোডের উপলব্ধতা নির্ধারণ করতে এবং ব্যর্থতা সনাক্ত হলে পদক্ষেপ নিতে সাহায্য করে।

নোডের জন্য দুটি ফর্মের হার্টবিট রয়েছে:

  • একটি নোডের .status এ আপডেট।
  • kube-node-lease namespace এর মধ্যে Lease অবজেক্ট। প্রতিটি নোডের একটি সংশ্লিষ্ট Lease অবজেক্ট রয়েছে।

নোড কন্ট্রোলার

নোড controller হল একটি Kubernetes control plane কম্পোনেন্ট যা নোডের বিভিন্ন দিক পরিচালনা করে।

নোড কন্ট্রোলারের একটি নোডের জীবনে একাধিক ভূমিকা রয়েছে। প্রথমটি হল নোডটি নিবন্ধিত হলে একটি CIDR ব্লক বরাদ্দ করা (যদি CIDR বরাদ্দ চালু থাকে)।

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

তৃতীয়টি হল নোডের স্বাস্থ্য পর্যবেক্ষণ করা। নোড কন্ট্রোলার দায়ী:

  • যদি একটি নোড অপ্রাপ্য হয়ে যায়, নোডের .status ফিল্ডে Ready কন্ডিশন আপডেট করা। এই ক্ষেত্রে নোড কন্ট্রোলার Ready কন্ডিশনকে Unknown এ সেট করে।
  • যদি একটি নোড অপ্রাপ্য থাকে: অপ্রাপ্য নোডের সমস্ত পডের জন্য API-initiated eviction ট্রিগার করা। ডিফল্টভাবে, নোড কন্ট্রোলার নোডটিকে Unknown হিসাবে চিহ্নিত করার এবং প্রথম ইভিকশন অনুরোধ জমা দেওয়ার মধ্যে 5 মিনিট অপেক্ষা করে।

ডিফল্টভাবে, নোড কন্ট্রোলার প্রতি 5 সেকেন্ডে প্রতিটি নোডের অবস্থা পরীক্ষা করে। এই সময়কাল kube-controller-manager কম্পোনেন্টে --node-monitor-period ফ্ল্যাগ ব্যবহার করে কনফিগার করা যেতে পারে।

ইভিকশনে রেট লিমিট

বেশিরভাগ ক্ষেত্রে, নোড কন্ট্রোলার ইভিকশন রেট --node-eviction-rate (ডিফল্ট 0.1) প্রতি সেকেন্ডে সীমাবদ্ধ করে, যার অর্থ এটি প্রতি 10 সেকেন্ডে 1 টির বেশি নোড থেকে পড ইভিক্ট করবে না।

একটি প্রদত্ত অ্যাভেইলেবিলিটি জোনে একটি নোড অসুস্থ হয়ে গেলে নোড ইভিকশন আচরণ পরিবর্তিত হয়। নোড কন্ট্রোলার পরীক্ষা করে যে জোনে একই সময়ে কত শতাংশ নোড অসুস্থ (Ready কন্ডিশন Unknown বা False):

  • যদি অসুস্থ নোডের ভগ্নাংশ কমপক্ষে --unhealthy-zone-threshold (ডিফল্ট 0.55) হয়, তাহলে ইভিকশন রেট হ্রাস করা হয়।
  • যদি ক্লাস্টারটি ছোট হয় (অর্থাৎ --large-cluster-size-threshold নোডের সমান বা কম থাকে - ডিফল্ট 50), তাহলে ইভিকশন বন্ধ করা হয়।
  • অন্যথায়, ইভিকশন রেট --secondary-node-eviction-rate (ডিফল্ট 0.01) প্রতি সেকেন্ডে হ্রাস করা হয়।

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

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

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

রিসোর্স ক্যাপাসিটি ট্র্যাকিং

নোড অবজেক্ট নোডের রিসোর্স ক্যাপাসিটি সম্পর্কে তথ্য ট্র্যাক করে: উদাহরণস্বরূপ, উপলব্ধ মেমরির পরিমাণ এবং CPU এর সংখ্যা। নোড যা self register করে তারা নিবন্ধনের সময় তাদের ক্যাপাসিটি রিপোর্ট করে। যদি আপনি manually একটি নোড যোগ করেন, তাহলে আপনি এটি যোগ করার সময় নোডের ক্যাপাসিটি তথ্য সেট করতে হবে।

Kubernetes scheduler নিশ্চিত করে যে একটি নোডে সমস্ত পডের জন্য পর্যাপ্ত রিসোর্স রয়েছে। শিডিউলার পরীক্ষা করে যে নোডে কন্টেইনারের অনুরোধের সমষ্টি নোডের ক্যাপাসিটির চেয়ে বেশি নয়। সেই অনুরোধের সমষ্টিতে kubelet দ্বারা পরিচালিত সমস্ত কন্টেইনার অন্তর্ভুক্ত, কিন্তু কন্টেইনার রানটাইম দ্বারা সরাসরি শুরু করা কোনো কন্টেইনার বাদ দেয়, এবং kubelet এর নিয়ন্ত্রণের বাইরে চলমান যেকোনো প্রসেসও বাদ দেয়।

নোড টপোলজি

ফিচার স্টেট: কুবারনেটিস v1.27 [stable]

আপনি যদি TopologyManager feature gate সক্রিয় করে থাকেন, তাহলে kubelet রিসোর্স বরাদ্দ সিদ্ধান্ত নেওয়ার সময় টপোলজি হিন্ট ব্যবহার করতে পারে। আরও তথ্যের জন্য Control Topology Management Policies on a Node দেখুন।

সোয়াপ মেমরি ব্যবস্থাপনা

ফিচার স্টেট: কুবারনেটিস v1.30 [beta]

একটি নোডে সোয়াপ সক্রিয় করতে, kubelet এ NodeSwap ফিচার গেট অবশ্যই সক্রিয় থাকতে হবে (ডিফল্ট সত্য), এবং --fail-swap-on কমান্ড লাইন ফ্ল্যাগ বা failSwapOn configuration setting অবশ্যই মিথ্যা সেট করতে হবে। পডগুলিকে সোয়াপ ব্যবহার করার অনুমতি দিতে, kubelet কনফিগে swapBehavior NoSwap (যা ডিফল্ট আচরণ) এ সেট করা উচিত নয়।

একজন ব্যবহারকারী ঐচ্ছিকভাবে memorySwap.swapBehavior কনফিগার করতে পারেন একটি নোড কীভাবে সোয়াপ মেমরি ব্যবহার করবে তা নির্দিষ্ট করতে। উদাহরণস্বরূপ,

memorySwap:
  swapBehavior: LimitedSwap
  • NoSwap (ডিফল্ট): Kubernetes ওয়ার্কলোড সোয়াপ ব্যবহার করবে না।
  • LimitedSwap: Kubernetes ওয়ার্কলোড দ্বারা সোয়াপ মেমরির ব্যবহার সীমাবদ্ধতার অধীন। শুধুমাত্র Burstable QoS এর পড সোয়াপ ব্যবহার করার অনুমতি পায়।

যদি memorySwap এর জন্য কনফিগারেশন নির্দিষ্ট না করা হয় এবং ফিচার গেট সক্রিয় থাকে, ডিফল্টভাবে kubelet NoSwap সেটিংয়ের মতো একই আচরণ প্রয়োগ করবে।

LimitedSwap এর সাথে, পড যা Burstable QoS শ্রেণীবিভাগের অধীনে পড়ে না (অর্থাৎ BestEffort/Guaranteed Qos পড) সোয়াপ মেমরি ব্যবহার করা থেকে নিষিদ্ধ। পূর্বোক্ত নিরাপত্তা এবং নোড স্বাস্থ্য গ্যারান্টি বজায় রাখতে, এই পডগুলি LimitedSwap কার্যকর থাকাকালীন সোয়াপ মেমরি ব্যবহার করার অনুমতি নেই।

সোয়াপ সীমা গণনার বিস্তারিত বর্ণনা করার আগে, নিম্নলিখিত পদগুলি সংজ্ঞায়িত করা প্রয়োজন:

  • nodeTotalMemory: নোডে উপলব্ধ ফিজিক্যাল মেমরির মোট পরিমাণ।
  • totalPodsSwapAvailable: নোডে সোয়াপ মেমরির মোট পরিমাণ যা পড দ্বারা ব্যবহারের জন্য উপলব্ধ (কিছু সোয়াপ মেমরি সিস্টেম ব্যবহারের জন্য সংরক্ষিত হতে পারে)।
  • containerMemoryRequest: কন্টেইনারের মেমরি অনুরোধ।

সোয়াপ সীমা এভাবে কনফিগার করা হয়: (containerMemoryRequest / nodeTotalMemory) * totalPodsSwapAvailable।

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

সোয়াপ শুধুমাত্র cgroup v2 এর সাথে সমর্থিত, cgroup v1 সমর্থিত নয়।

আরও তথ্যের জন্য, এবং পরীক্ষা এবং প্রতিক্রিয়া প্রদানে সহায়তা করতে, অনুগ্রহ করে Kubernetes 1.28: NodeSwap graduates to Beta1 সম্পর্কে ব্লগ-পোস্ট, KEP-2400 এবং এর design proposal দেখুন।

এর পরের কি

নিম্নলিখিত সম্পর্কে আরও জানুন: