ওভারভিউ

• 1: কুবারনেটিস কম্পোনেন্ট
• 2: কুবারনেটিসে অবজেক্ট
• 3: কুবারনেটিস API

1 - কুবারনেটিস কম্পোনেন্ট

এই পেইজটি প্রয়োজনীয় কম্পোনেন্ট গুলোর একটি হাই-লেভেলের ওভারভিউ প্রদান করে যা একটি কুবারনেটিস ক্লাস্টার তৈরি করে।

মূল কম্পোনেন্ট গুলো

একটি কুবারনেটিস ক্লাস্টার একটি কন্ট্রোল প্লেন এবং এক বা একাধিক ওয়ার্কার নোড নিয়ে গঠিত। এখানে প্রধান কম্পোনেন্ট গুলোর একটি সংক্ষিপ্ত বিবরণ রয়েছে:

কন্ট্রোল প্লেন কম্পোনেন্ট গুলো

ক্লাস্টারের সামগ্রিক অবস্থা পরিচালনা করে:

kube-apiserver

মূল কম্পোনেন্ট সার্ভার যা কুবারনেটিস HTTP API প্রকাশ করে

etcd

সকল API সার্ভার ডেটার জন্য সামঞ্জস্যপূর্ণ এবং হাইলি-এভেইলেভেল কী ভ্যালু স্টোর

kube-scheduler

একটি নোডের সাথে এখনও আবদ্ধ নয় এমন পডগুলির সন্ধান করে এবং প্রতিটি পডকে একটি উপযুক্ত নোডে বরাদ্দ করে৷

kube-controller-manager

কুবারনেটিস API আচরণ বাস্তবায়ন করতে কন্ট্রোলার চালায়।

cloud-controller-manager (অপশনাল)

অন্তর্নিহিত ক্লাউড প্রদানকারী(গুলি) এর সাথে সমন্বিত করে।

নোড কম্পোনেন্ট গুলো

চলমান পড বজায় রাখে এবং কুবারনেটিস রানটাইম এনভায়রনমেন্ট প্রদান করে প্রতিটি নোডে চালায়:

kubelet

নিশ্চিত করে যে পডগুলো চলছে, তাদের কন্টেইনার সহ।

kube-proxy (optional)

সার্ভিসগুলো বাস্তবায়নের জন্য নোডগুলিতে নেটওয়ার্ক রুলস বজায় রাখে।

কন্টেইনার রানটাইম

কন্টেইনার চালানোর জন্য দায়ী সফ্টওয়্যার। আরো জানতে কন্টেইনার রানটাইম পড়ুন।

আপনার ক্লাস্টার প্রতিটি নোডে অতিরিক্ত সফ্টওয়্যার প্রয়োজন হতে পারে; উদাহরণস্বরূপ, আপনি লোকাল কম্পোনেন্টগুলো তত্ত্বাবধান করতে একটি লিনাক্স নোডে systemd চালাতে পারেন।

অ্যাডঅন

অ্যাডঅন কুবারনেটিসের কার্যকারিতা প্রসারিত করে। কয়েকটি গুরুত্বপূর্ণ উদাহরণের মধ্যে রয়েছে:

DNS

ক্লাস্টার-ওয়াইড DNS রেজোলিউশনের জন্য

Web UI (Dashboard)

একটি ওয়েব ইন্টারফেসের মাধ্যমে ক্লাস্টার পরিচালনার জন্য

Container Resource Monitoring

কন্টেইনার মেট্রিক্স সংগ্রহ এবং সংরক্ষণের জন্য

Cluster-level Logging

একটি কেন্দ্রীয় লগ স্টোরে কন্টেইনার লগ সংরক্ষণের জন্য

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

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

প্রতিটি কম্পোনেন্টের ব্যাপারে এবং আপনার ক্লাস্টার আর্কিটেকচার কনফিগার করার বিভিন্ন উপায় সম্পর্কে আরও বিস্তারিত তথ্যের জন্য, ক্লাস্টার আর্কিটেকচার পেইজটি দেখুন।

2 - কুবারনেটিসে অবজেক্ট

এই পৃষ্ঠাটি ব্যাখ্যা করে কুবারনেটিস API-তে কুবারনেটিস অবজেক্টগুলি কীভাবে প্রতিনিধিত্ব করা হয় এবং আপনি কিভাবে তা .yaml ফরম্যাটে প্রকাশ করতে পারেন।

কুবারনেটিস অবজেক্ট বোঝা

কুবারনেটিস অবজেক্ট হল কুবারনেটিস সিস্টেমের সত্তা সংরক্ষিত এন্টিটিগুলি। কুবারনেটিস এই এন্টিটিগুলি ব্যবহার করে আপনার ক্লাস্টারের অবস্থা প্রকাশ করতে। বিশেষভাবে, তারা বর্ণনা করতে পারে:

• কোন কন্টেনার অ্যাপ্লিকেশন কি রান করছে (এবং কোন নোডগুলিতে)
• ঐ অ্যাপ্লিকেশনগুলির জন্য রিসোর্স
• ঐ অ্যাপ্লিকেশনগুলির কিভাবে ব্যবহার করতে হবে, উদাহরণস্বরূপ রিস্টার্ট নীতি, আপগ্রেড, এবং ফল্ট-টলারেন্স

একটি কুবারনেটিস অবজেক্ট হল একটি "উদ্দেশ্যের রেকর্ড" - একবার আপনি অবজেক্ট তৈরি করে দিলে, কুবারনেটিস সিস্টেম সরাসরি এই অবজেক্টটি থাকার নিশ্চয়তার জন্য কাজ করবে। অবজেক্ট তৈরি করে আপনি সাধারণত কুবারনেটিস সিস্টেমকে বলে দিচ্ছেন যে আপনার ক্লাস্টারের ওয়ার্কলোড কি হবে; এটা হল আপনার ক্লাস্টারের কাঙ্ক্ষিত অবস্থা।

কুবারনেটিস অবজেক্টগুলির সাথে কাজ করতে - তা তৈরি, পরিবর্তন করতে বা মুছতে - আপনার কুবারনেটিস API ব্যবহার করতে হবে। উদাহরণস্বরূপ, যখন আপনি kubectl কমান্ড-লাইন ইন্টারফেস ব্যবহার করেন, তখন CLI আপনার জন্য প্রয়োজনীয় কুবারনেটিস API কল করে। আপনি একটি Client Libraries ব্যবহার করে নিজের প্রোগ্রামে কুবারনেটিস API সরাসরি ব্যবহার করতে পারেন।

অবজেক্ট স্পেক এবং স্ট্যাটাস

প্রায় সব কুবারনেটিস অবজেক্টের একটি spec এবং একটি status নেস্টেড অবজেক্ট ফিল্ড রয়েছে যা অবজেক্টের কনফিগারেশন নিয়ন্ত্রণ করে: অবজেক্টের spec এবং status। যে অবজেক্টগুলির spec থাকে, আপনার অবজেক্ট তৈরি করতে এটা নির্ধারণ করতে হবে যখন অবজেক্ট তৈরি করবেন, যে রিসোর্সের বৈশিষ্ট্য বর্ণনা প্রদান করবেন: এর কাঙ্ক্ষিত অবস্থা।

status অবজেক্টের বর্তমান অবস্থা বর্ণনা করে, যা কুবারনেটিস সিস্টেম এবং এর উপাদানগুলি প্রদান এবং আপডেট করে। কুবারনেটিস control plane সরাসরি এবং সক্রিয়ভাবে প্রতিটি অবজেক্টের বর্তমান অবস্থা পরিচালনা করে যাতে আপনার প্রদত্ত অবস্থা মিলে।

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

বিস্তারিত তথ্যের জন্য অবজেক্ট স্পেক, স্ট্যাটাস এবং মেটাডেটা দেখুন, Kubernetes API Conventions.

একটি কুবারনেটিস অবজেক্ট বর্ণনা

যখন আপনি কুবারনেটিসে একটি অবজেক্ট তৈরি করবেন, আপনাকে অবজেক্ট spec প্রদান করতে হবে যা দরকার তার কাঙ্ক্ষিত অবস্থা বর্ণনা করে এবং অবজেক্ট সম্পর্কে কিছু মৌলিক তথ্য (যেমন নাম) প্রদান করতে হবে। যখন আপনি অবজেক্ট তৈরি করতে কুবারনেটিস API ব্যবহার করেন (এটা সরাসরি বা kubectl এর মাধ্যমে), তখন ঐ API অনুরোধটি এই তথ্যকে একটি JSON রিকোয়েস্ট বডি হিসেবে অন্তর্ভুক্ত করতে হবে। সাধারণত, আপনি একটি manifest নামে পরিচিত ফাইলে kubectl কে তথ্য প্রদান করেন। নিয়ম অনুসারে, ম্যানিফেস্ট হল YAML (আপনি JSON ফরম্যাটও ব্যবহার করতে পারেন)। HTTP-এর মাধ্যমে API অনুরোধ করার সময় টুল যেমন kubectl একটি ম্যানিফেস্ট থেকে তথ্যকে JSON বা অন্য সমর্থিত সিরিয়ালাইজেশন ফরম্যাটে রূপান্তর করে।

এখানে একটি উদাহরণ ম্যানিফেস্ট দেওয়া হল একটি কুবারনেটিস ডিপ্লয়মেন্টের জন্য প্রয়োজনীয় ক্ষেত্রগুলি এবং অবজেক্ট স্পেকের জন্যের একটি নমুনা:

application/deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2 # ডিপ্লয়মেন্টকে টেমপ্লেটের সাথে মিলে যাওয়া 2টি পড চালাতে বলে
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

একটি উপরের মতো ম্যানিফেস্ট ফাইল ব্যবহার করে একটি ডিপ্লয়মেন্ট তৈরি করার একটি উপায় হল kubectl apply কমান্ড ব্যবহার করা, kubectl এর কমান্ড-লাইন ইন্টারফেসে yaml ফাইলটি আর্গুমেন্ট হিসেবে পাঠানো। একটি উদাহরণ:

kubectl apply -f https://k8s.io/examples/application/deployment.yaml

আউটপুট এর অনুরূপ:

deployment.apps/nginx-deployment created

প্রয়োজনীয় ক্ষেত্র

আপনার কুবারনেটিস অবজেক্ট এর জন্য ম্যানিফেস্ট (YAML বা JSON ফাইল) এ নিম্নলিখিত ক্ষেত্রগুলির জন্য মান নির্ধারণ করতে হবে:

• apiVersion - আপনি কোন ভার্সনের কুবারনেটিস API ব্যবহার করছেন তা উল্লেখ করতে হবে
• kind - আপনি কোন ধরনের অবজেক্ট তৈরি করতে চান তা উল্লেখ করতে হবে
• metadata - অবজেক্ট যে সাহায্য করে অনন্যভাবে সনাক্ত করা যায়, যেমন name স্ট্রিং, UID, এবং ঐচ্ছিক namespace
• spec - অবজেক্টের জন্য আপনি কি অবস্থা চান

অবজেক্ট spec সুনির্দিষ্ট ফরম্যাট প্রতিটি কুবারনেটিস অবজেক্টের জন্য আলাদা, এবং সেই বস্তুর জন্য নির্দিষ্ট নেস্টেড ক্ষেত্র রয়েছে। Kubernetes API রেফারেন্স ব্যবহার করে আপনি যে সমস্ত অবজেক্ট তৈরি করতে পারেন তার জন্য নির্দিষ্ট ফরম্যাট খুঁজে পেতে সাহায্য করতে পারে।

উদাহরণস্বরূপ, দেখুন spec ফিল্ড Pod API রেফারেন্স এর জন্য। প্রতিটি Pod এর জন্য, .spec ক্ষেত্রটি পড এবং তার কাঙ্ক্ষিত অবস্থা (যেমন সেই পডের মধ্যে প্রতিটি কন্টেইনারের জন্য কন্টেইনার ইমেজের নাম) নির্দিষ্ট করে৷ আরও একটি অবজেক্ট স্পেসিফিকেশনের উদাহরণ হল spec ফিল্ড StatefulSet API এর জন্য। StatefulSet এর জন্য, .spec ফিল্ড নির্দিষ্ট করে এবং সেট করে এর অবস্থা। StatefulSet এর .spec এর মধ্যে একটি টেমপ্লেট পড অবজেক্টের জন্য । সেই টেমপ্লেটটি Pods বর্ণনা করে যা StatefulSet কন্ট্রোলার স্টেটফুলসেট স্পেসিফিকেশন সন্তুষ্ট করার জন্য তৈরি করবে। অন্যান্য প্রকারের অবজেক্ট গুলির জন্য বিভিন্ন .status থাকতে পারে; আবার, API রেফারেন্স পৃষ্ঠাগুলি এই .status ফিল্ডের গঠন এবং এর প্রত্যেক বিভিন্ন প্রকারের অবজেক্টের জন্য তার বিষয়বস্তু বিবরণ করে।

সার্ভার সাইড ফিল্ড ভেরিফিকেশন

কুবারনেটিস v1.25 থেকে শুরু করে, API সার্ভার সার্ভার সাইড field validation যা অব্যক্ত বা পুনরায় ফিল্ড অনুমান করে একটি অবজেক্টে। এটি সমস্ত কার্যকারিতা প্রদান করে kubectl --validate এর সার্ভার সাইড এ কর্মক্ষমতা।

kubectl টুলটি ব্যবহার করে --validate ফ্ল্যাগ ব্যবহার করে ফিল্ড ভেরিফিকেশনের স্তর সেট করে। এটি গ্রহণ করে মান ignore, warn, এবং strict এবং এটি true (strict এর সমান) এবং false ( ignore এর সমান) মান গ্রহণ করে। kubectl এর ডিফল্ট ভেরিফিকেশন সেটিং হল --validate=true।

Strict

Strict ফিল্ড ভেরিফিকেশন, ভেরিফিকেশন ব্যর্থ হওয়ায় errors দেখায়

Warn

ফিল্ড ভেরিফিকেশন করা হয়, কিন্তু errors গুলি অনুরোধ ব্যর্থ হওয়ার পরিবর্তে সতর্কতা হিসাবে প্রকাশ করা হয়

Ignore

কোনো সার্ভার সাইড ফিল্ড ভেরিফিকেশন করা হয় না

যখন kubectl এর একটি API সার্ভারে সংযোগ করতে পারে না যে কোন ফিল্ড ভেরিফিকেশন সাপোর্ট করে তখন এটি ফেলে যায় ক্লায়েন্ট-সাইড ভেরিফিকেশন ব্যবহার করা হয়। কুবারনেটিস 1.27 এবং তারপরের সংস্করণ সবসময় ফিল্ড ভেরিফিকেশন প্রদান করে; পুরাতন কুবারনেটিস রিলিসেগুলিতে এটি হতে পারে না। যদি আপনার ক্লাস্টার v1.27 এর চেয়ে পুরানো হয় তবে এপনার কুবারনেটিস সংস্করণের জন্য ডকুমেন্টেশন চেক করুন।

এর পরের কি

যদি আপনি নতুন কুবারনেটিসে এসেছেন, তাহলে নিম্নলিখিত বিষয়গুলি সম্পর্কে আরো পড়ুন:

• Pods যা হলে সবচেয়ে গুরুত্বপূর্ণ মৌলিক কুবারনেটিস অবজেক্ট।
• Deployment অবজেক্টগুলি।
• Controllers কুবারনেটিসে।
• kubectl এবং kubectl কমান্ড।

কুবারনেটিস অবজেক্ট ম্যানেজমেন্ট kubectl ব্যবহার করে অবজেক্ট পরিচালনা করার উপায়গুলি বিস্তারিত ভাবে বর্ণনা করে। আপনার কাছে যদি আগে থেকে না থাকে তাহলে kubectl ইনস্টল করুন।

কুবারনেটিস API সাধারণভাবে সম্পর্কে জানতে, পড়ুন:

• Kubernetes API overview

কুবারনেটিসে অবজেক্টগুলির বিস্তারিত জানতে, এই বিভাগে অন্যান্য পৃষ্ঠাগুলি পড়ুন:

3 - কুবারনেটিস API

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

কুবারনেটিস API আপনাকে কুবারনেটিসে API অবজেক্টের স্টেট কোয়েরি এবং ম্যানিপুলেট করতে দেয় (উদাহরণস্বরূপ: Pod, Namespace, ConfigMap, এবং Event)।

বেশিরভাগ অপারেশন kubectl কমান্ড-লাইন ইন্টারফেস বা অন্যান্য কমান্ড-লাইন টুল যেমন kubeadm এর মাধ্যমে সম্পাদন করা যেতে পারে, যা পরিবর্তে API ব্যবহার করে। তবে, আপনি REST কল ব্যবহার করে সরাসরি API অ্যাক্সেস করতে পারেন। কুবারনেটিস কুবারনেটিস API ব্যবহার করে অ্যাপ্লিকেশন লিখতে চাওয়া ব্যক্তিদের জন্য ক্লায়েন্ট লাইব্রেরি এর একটি সেট প্রদান করে।

প্রতিটি কুবারনেটিস ক্লাস্টার ক্লাস্টার যে API গুলি সার্ভ করে তার স্পেসিফিকেশন প্রকাশ করে। কুবারনেটিস এই API স্পেসিফিকেশন প্রকাশ করতে দুটি মেকানিজম ব্যবহার করে; উভয়ই স্বয়ংক্রিয় ইন্টারঅপারেবিলিটি সক্ষম করতে উপযোগী। উদাহরণস্বরূপ, kubectl টুল কমান্ড-লাইন কমপ্লিশন এবং অন্যান্য ফিচার সক্ষম করার জন্য API স্পেসিফিকেশন ফেচ এবং ক্যাশ করে। দুটি সমর্থিত মেকানিজম নিম্নরূপ:

• Discovery API কুবারনেটিস API সম্পর্কে তথ্য প্রদান করে: API নাম, রিসোর্স, ভার্সন এবং সমর্থিত অপারেশন। এটি একটি কুবারনেটিস নির্দিষ্ট টার্ম কারণ এটি কুবারনেটিস OpenAPI থেকে একটি পৃথক API। এটি উপলব্ধ রিসোর্সের একটি সংক্ষিপ্ত সারাংশ হওয়ার উদ্দেশ্যে এবং এটি রিসোর্সের জন্য নির্দিষ্ট স্কিমা বিস্তারিত করে না। রিসোর্স স্কিমা সম্পর্কে রেফারেন্সের জন্য, অনুগ্রহ করে OpenAPI ডকুমেন্ট দেখুন।

• Kubernetes OpenAPI Document সমস্ত কুবারনেটিস API এন্ডপয়েন্টের জন্য (সম্পূর্ণ) OpenAPI v2.0 এবং 3.0 স্কিমা প্রদান করে। OpenAPI v3 হল OpenAPI অ্যাক্সেস করার পছন্দের পদ্ধতি কারণ এটি API এর আরও ব্যাপক এবং নির্ভুল দৃশ্য প্রদান করে। এটি সমস্ত উপলব্ধ API পাথ, সেইসাথে প্রতিটি এন্ডপয়েন্টে প্রতিটি অপারেশনের জন্য ব্যবহৃত এবং উৎপাদিত সমস্ত রিসোর্স অন্তর্ভুক্ত করে। এটি একটি ক্লাস্টার সমর্থন করে এমন যেকোনো এক্সটেনসিবিলিটি কম্পোনেন্টও অন্তর্ভুক্ত করে। ডেটা একটি সম্পূর্ণ স্পেসিফিকেশন এবং Discovery API থেকে প্রাপ্ত ডেটার চেয়ে উল্লেখযোগ্যভাবে বড়।

Discovery API

কুবারনেটিস Discovery API এর মাধ্যমে সমর্থিত সমস্ত গ্রুপ ভার্সন এবং রিসোর্সের একটি তালিকা প্রকাশ করে। এতে প্রতিটি রিসোর্সের জন্য নিম্নলিখিত অন্তর্ভুক্ত রয়েছে:

• নাম
• ক্লাস্টার বা নেমস্পেসড স্কোপ
• এন্ডপয়েন্ট URL এবং সমর্থিত ভার্ব
• বিকল্প নাম
• গ্রুপ, ভার্সন, কাইন্ড

API অ্যাগ্রিগেটেড এবং আনঅ্যাগ্রিগেটেড উভয় ফর্মে উপলব্ধ। অ্যাগ্রিগেটেড ডিসকভারি দুটি এন্ডপয়েন্ট সার্ভ করে, যখন আনঅ্যাগ্রিগেটেড ডিসকভারি প্রতিটি গ্রুপ ভার্সনের জন্য একটি পৃথক এন্ডপয়েন্ট সার্ভ করে।

অ্যাগ্রিগেটেড ডিসকভারি

কুবারনেটিস অ্যাগ্রিগেটেড ডিসকভারির জন্য স্থিতিশীল সমর্থন প্রদান করে, দুটি এন্ডপয়েন্টের (/api এবং /apis) মাধ্যমে একটি ক্লাস্টার দ্বারা সমর্থিত সমস্ত রিসোর্স প্রকাশ করে। এই এন্ডপয়েন্ট অনুরোধ করা ক্লাস্টার থেকে ডিসকভারি ডেটা ফেচ করতে পাঠানো অনুরোধের সংখ্যা ব্যাপকভাবে হ্রাস করে। আপনি একটি Accept হেডার নির্দেশ করে অ্যাগ্রিগেটেড ডিসকভারি রিসোর্স সহ সংশ্লিষ্ট এন্ডপয়েন্ট অনুরোধ করে ডেটা অ্যাক্সেস করতে পারেন: Accept: application/json;v=v2;g=apidiscovery.k8s.io;as=APIGroupDiscoveryList।

Accept হেডার ব্যবহার করে রিসোর্স টাইপ নির্দেশ না করে, /api এবং /apis এন্ডপয়েন্টের জন্য ডিফল্ট রেসপন্স একটি আনঅ্যাগ্রিগেটেড ডিসকভারি ডকুমেন্ট।

বিল্ট-ইন রিসোর্সের জন্য ডিসকভারি ডকুমেন্ট কুবারনেটিস GitHub রিপোজিটরিতে পাওয়া যাবে। যদি একটি কুবারনেটিস ক্লাস্টার কোয়েরি করার জন্য উপলব্ধ না থাকে তবে এই Github ডকুমেন্টটি উপলব্ধ রিসোর্সের বেস সেটের রেফারেন্স হিসাবে ব্যবহার করা যেতে পারে।

এন্ডপয়েন্ট ETag এবং protobuf এনকোডিং সমর্থন করে।

আনঅ্যাগ্রিগেটেড ডিসকভারি

ডিসকভারি অ্যাগ্রিগেশন ছাড়া, ডিসকভারি লেভেলে প্রকাশিত হয়, রুট এন্ডপয়েন্ট ডাউনস্ট্রিম ডকুমেন্টের জন্য ডিসকভারি তথ্য প্রকাশ করে।

একটি ক্লাস্টার দ্বারা সমর্থিত সমস্ত গ্রুপ ভার্সনের একটি তালিকা /api এবং /apis এন্ডপয়েন্টে প্রকাশিত হয়। উদাহরণ:

{
  "kind": "APIGroupList",
  "apiVersion": "v1",
  "groups": [
    {
      "name": "apiregistration.k8s.io",
      "versions": [
        {
          "groupVersion": "apiregistration.k8s.io/v1",
          "version": "v1"
        }
      ],
      "preferredVersion": {
        "groupVersion": "apiregistration.k8s.io/v1",
        "version": "v1"
      }
    },
    {
      "name": "apps",
      "versions": [
        {
          "groupVersion": "apps/v1",
          "version": "v1"
        }
      ],
      "preferredVersion": {
        "groupVersion": "apps/v1",
        "version": "v1"
      }
    },
    ...
}

/apis/<group>/<version> এ প্রতিটি গ্রুপ ভার্সনের জন্য ডিসকভারি ডকুমেন্ট পেতে অতিরিক্ত অনুরোধ প্রয়োজন (উদাহরণস্বরূপ: /apis/rbac.authorization.k8s.io/v1alpha1), যা একটি নির্দিষ্ট গ্রুপ ভার্সনের অধীনে সার্ভ করা রিসোর্সের তালিকা বিজ্ঞাপন করে। এই এন্ডপয়েন্টগুলি kubectl দ্বারা একটি ক্লাস্টার দ্বারা সমর্থিত রিসোর্সের তালিকা ফেচ করতে ব্যবহৃত হয়।

OpenAPI স্পেসিফিকেশন সম্পর্কে বিস্তারিত জানতে, OpenAPI ডকুমেন্টেশন দেখুন।

কুবারনেটিস OpenAPI v2.0 এবং OpenAPI v3.0 উভয়ই সার্ভ করে। OpenAPI v3 হল OpenAPI অ্যাক্সেস করার পছন্দের পদ্ধতি কারণ এটি কুবারনেটিস রিসোর্সের আরও ব্যাপক (লসলেস) উপস্থাপনা প্রদান করে। OpenAPI ভার্সন 2 এর সীমাবদ্ধতার কারণে, নির্দিষ্ট ফিল্ড প্রকাশিত OpenAPI থেকে বাদ দেওয়া হয় যার মধ্যে রয়েছে কিন্তু সীমাবদ্ধ নয় default, nullable, oneOf।

OpenAPI V2

কুবারনেটিস API সার্ভার /openapi/v2 এন্ডপয়েন্টের মাধ্যমে একটি অ্যাগ্রিগেটেড OpenAPI v2 স্পেক সার্ভ করে। আপনি নিম্নরূপ রিকোয়েস্ট হেডার ব্যবহার করে রেসপন্স ফর্ম্যাট অনুরোধ করতে পারেন:

OpenAPI V3

কুবারনেটিস তার API গুলির একটি বর্ণনা OpenAPI v3 হিসাবে প্রকাশ করতে সমর্থন করে।

একটি ডিসকভারি এন্ডপয়েন্ট /openapi/v3 উপলব্ধ সমস্ত গ্রুপ/ভার্সনের একটি তালিকা দেখতে প্রদান করা হয়। এই এন্ডপয়েন্ট শুধুমাত্র JSON রিটার্ন করে। এই গ্রুপ/ভার্সনগুলি নিম্নলিখিত ফর্ম্যাটে প্রদান করা হয়:

{
    "paths": {
        ...,
        "api/v1": {
            "serverRelativeURL": "/openapi/v3/api/v1?hash=CC0E9BFD992D8C59AEC98A1E2336F899E8318D3CF4C68944C3DEC640AF5AB52D864AC50DAA8D145B3494F75FA3CFF939FCBDDA431DAD3CA79738B297795818CF"
        },
        "apis/admissionregistration.k8s.io/v1": {
            "serverRelativeURL": "/openapi/v3/apis/admissionregistration.k8s.io/v1?hash=E19CC93A116982CE5422FC42B590A8AFAD92CDE9AE4D59B5CAAD568F083AD07946E6CB5817531680BCE6E215C16973CD39003B0425F3477CFD854E89A9DB6597"
        },
        ....
    }
}

রিলেটিভ URL গুলি ইমিউটেবল OpenAPI বর্ণনার দিকে নির্দেশ করছে, ক্লায়েন্ট-সাইড ক্যাশিং উন্নত করার জন্য। সেই উদ্দেশ্যে API সার্ভার দ্বারা যথাযথ HTTP ক্যাশিং হেডারও সেট করা হয় (ভবিষ্যতে 1 বছরের জন্য Expires, এবং Cache-Control থেকে immutable)। যখন একটি অপ্রচলিত URL ব্যবহার করা হয়, API সার্ভার নতুনতম URL এ একটি রিডাইরেক্ট রিটার্ন করে।

কুবারনেটিস API সার্ভার /openapi/v3/apis/<group>/<version>?hash=<hash> এন্ডপয়েন্টে প্রতি কুবারনেটিস গ্রুপ ভার্সনের জন্য একটি OpenAPI v3 স্পেক প্রকাশ করে।

গৃহীত রিকোয়েস্ট হেডারের জন্য নীচের টেবিলটি দেখুন।

OpenAPI V3 ফেচ করার জন্য একটি Golang ইমপ্লিমেন্টেশন প্যাকেজ k8s.io/client-go/openapi3 এ প্রদান করা হয়েছে।

কুবারনেটিস 1.31 OpenAPI v2.0 এবং v3.0 প্রকাশ করে; নিকট ভবিষ্যতে 3.1 সমর্থন করার কোন পরিকল্পনা নেই।

Protobuf সিরিয়ালাইজেশন

কুবারনেটিস একটি বিকল্প Protobuf ভিত্তিক সিরিয়ালাইজেশন ফর্ম্যাট ইমপ্লিমেন্ট করে যা প্রাথমিকভাবে ইন্ট্রা-ক্লাস্টার যোগাযোগের জন্য উদ্দিষ্ট। এই ফর্ম্যাট সম্পর্কে আরও তথ্যের জন্য, Kubernetes Protobuf serialization ডিজাইন প্রস্তাব এবং API অবজেক্ট সংজ্ঞায়িত করে এমন Go প্যাকেজে অবস্থিত প্রতিটি স্কিমার জন্য Interface Definition Language (IDL) ফাইল দেখুন।

পার্সিস্টেন্স

কুবারনেটিস অবজেক্টের সিরিয়ালাইজড স্টেট সংরক্ষণ করে সেগুলি etcd এ লিখে।

API গ্রুপ এবং ভার্সনিং

ফিল্ড বাদ দেওয়া বা রিসোর্স উপস্থাপনা পুনর্গঠন করা সহজ করতে, কুবারনেটিস একাধিক API ভার্সন সমর্থন করে, প্রতিটি একটি ভিন্ন API পাথে, যেমন /api/v1 বা /apis/rbac.authorization.k8s.io/v1alpha1।

ভার্সনিং রিসোর্স বা ফিল্ড লেভেলের পরিবর্তে API লেভেলে করা হয় যাতে নিশ্চিত করা যায় যে API সিস্টেম রিসোর্স এবং আচরণের একটি স্পষ্ট, সামঞ্জস্যপূর্ণ দৃশ্য উপস্থাপন করে, এবং এন্ড-অফ-লাইফ এবং/অথবা এক্সপেরিমেন্টাল API গুলিতে অ্যাক্সেস নিয়ন্ত্রণ সক্ষম করতে।

তার API বিকশিত এবং প্রসারিত করা সহজ করতে, কুবারনেটিস API গ্রুপ ইমপ্লিমেন্ট করে যা সক্রিয় বা নিষ্ক্রিয় করা যেতে পারে।

API রিসোর্স তাদের API গ্রুপ, রিসোর্স টাইপ, নেমস্পেস (নেমস্পেসড রিসোর্সের জন্য), এবং নাম দ্বারা আলাদা করা হয়। API সার্ভার API ভার্সনের মধ্যে রূপান্তর স্বচ্ছভাবে পরিচালনা করে: সমস্ত ভিন্ন ভার্সন আসলে একই পার্সিস্টেড ডেটার উপস্থাপনা। API সার্ভার একাধিক API ভার্সনের মাধ্যমে একই অন্তর্নিহিত ডেটা সার্ভ করতে পারে।

উদাহরণস্বরূপ, ধরুন একই রিসোর্সের জন্য দুটি API ভার্সন আছে, v1 এবং v1beta1। যদি আপনি মূলত তার API এর v1beta1 ভার্সন ব্যবহার করে একটি অবজেক্ট তৈরি করেন, আপনি পরে v1beta1 বা v1 API ভার্সন ব্যবহার করে সেই অবজেক্টটি পড়তে, আপডেট করতে বা মুছতে পারেন, যতক্ষণ না v1beta1 ভার্সন ডেপ্রিকেটেড এবং সরানো হয়। সেই সময়ে আপনি v1 API ব্যবহার করে অবজেক্ট অ্যাক্সেস এবং পরিবর্তন করা চালিয়ে যেতে পারেন।

API পরিবর্তন

যেকোনো সিস্টেম যা সফল তার বৃদ্ধি এবং পরিবর্তন প্রয়োজন যখন নতুন ব্যবহারের ক্ষেত্রে আবির্ভূত হয় বা বিদ্যমানগুলি পরিবর্তিত হয়। অতএব, কুবারনেটিস কুবারনেটিস API ক্রমাগত পরিবর্তন এবং বৃদ্ধি করার জন্য ডিজাইন করেছে। কুবারনেটিস প্রজেক্টের লক্ষ্য বিদ্যমান ক্লায়েন্টদের সাথে সামঞ্জস্য না ভাঙা, এবং সেই সামঞ্জস্য একটি দৈর্ঘ্যের সময়ের জন্য বজায় রাখা যাতে অন্যান্য প্রজেক্টের খাপ খাওয়ানোর সুযোগ থাকে।

সাধারণভাবে, নতুন API রিসোর্স এবং নতুন রিসোর্স ফিল্ড প্রায়ই এবং ঘন ঘন যোগ করা যেতে পারে। রিসোর্স বা ফিল্ড বাদ দেওয়ার জন্য API ডেপ্রিকেশন পলিসি অনুসরণ করা প্রয়োজন।

কুবারনেটিস অফিসিয়াল কুবারনেটিস API গুলির জন্য সামঞ্জস্য বজায় রাখার জন্য একটি শক্তিশালী প্রতিশ্রুতি দেয় একবার তারা সাধারণ উপলব্ধতা (GA) পৌঁছালে, সাধারণত API ভার্সন v1 এ। অতিরিক্তভাবে, কুবারনেটিস অফিসিয়াল কুবারনেটিস API গুলির beta API ভার্সনের মাধ্যমে পার্সিস্ট করা ডেটার সাথে সামঞ্জস্য বজায় রাখে, এবং নিশ্চিত করে যে ফিচার স্থিতিশীল হলে ডেটা রূপান্তরিত এবং GA API ভার্সনের মাধ্যমে অ্যাক্সেস করা যেতে পারে।

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

API ভার্সন লেভেল ডেফিনিশনের আরও বিস্তারিত জানতে API ভার্সনিং রেফারেন্স দেখুন।

API এক্সটেনশন

কুবারনেটিস API দুটি উপায়ের একটিতে প্রসারিত করা যেতে পারে:

1. কাস্টম রিসোর্স আপনাকে ঘোষণামূলকভাবে সংজ্ঞায়িত করতে দেয় যে API সার্ভার কীভাবে আপনার নির্বাচিত রিসোর্স API প্রদান করবে।
2. আপনি একটি অ্যাগ্রিগেশন লেয়ার ইমপ্লিমেন্ট করে কুবারনেটিস API প্রসারিত করতে পারেন।

এর পরের কি

• আপনার নিজস্ব CustomResourceDefinition যোগ করে কুবারনেটিস API কীভাবে প্রসারিত করবেন তা শিখুন।
• Controlling Access To The Kubernetes API বর্ণনা করে ক্লাস্টার কীভাবে API অ্যাক্সেসের জন্য অথেনটিকেশন এবং অথরাইজেশন পরিচালনা করে।
• API এন্ডপয়েন্ট, রিসোর্স টাইপ এবং নমুনা সম্পর্কে জানুন API Reference পড়ে।
• একটি সামঞ্জস্যপূর্ণ পরিবর্তন কী গঠন করে এবং API কীভাবে পরিবর্তন করতে হয় তা সম্পর্কে জানুন, API changes থেকে।