কুবারনেটের যথাযথ তুলনা প্রয়োগ, প্রতিস্থাপন এবং প্যাচ

Kubernetes-এর কাছে রিসোর্স আপডেট করার জন্য বিভিন্ন বিকল্প রয়েছে: প্রয়োগ, সম্পাদনা, প্যাচ এবং প্রতিস্থাপন। প্রত্যেকে কী করে এবং কখন সেগুলি ব্যবহার করবে তা নিয়ে বিভ্রান্তি রয়েছে। আসুন এটা বের করা যাক।

যদি Google এ অনুসন্ধান করুন "kubernetes প্রয়োগ বনাম প্রতিস্থাপন" বাক্যাংশটি অবস্থিত StackOverflow এর উত্তর, যা সঠিক নয়। যখন অনুসন্ধান "kubernetes প্রয়োগ বনাম প্যাচ" এর জন্য প্রথম লিঙ্কটি ডকুমেন্টেশন kubectl patch, যা তুলনা অন্তর্ভুক্ত করে না apply и patch. এই নিবন্ধটি বিভিন্ন বিকল্পের পাশাপাশি প্রতিটির সঠিক ব্যবহার দেখবে।

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

কুবারনেটস সিএলআই

আপনি যদি ইতিমধ্যেই CLI এর মাধ্যমে Kubernetes ক্লাস্টারগুলির সাথে কাজ করে থাকেন তবে আপনি ইতিমধ্যেই পরিচিত apply и edit. টীম apply ফাইল থেকে রিসোর্স স্পেসিফিকেশন পড়ে এবং কুবারনেটস ক্লাস্টারে একটি "আপসার্ট" করে, যেমন এটি বিদ্যমান না থাকলে সংস্থান তৈরি করে এবং যদি এটি বিদ্যমান থাকে তবে এটি আপডেট করে। টীম edit API এর মাধ্যমে একটি সংস্থান পড়ে, তারপরে একটি স্থানীয় ফাইলে সংস্থান স্পেসিফিকেশন লেখে, যা একটি পাঠ্য সম্পাদকে খোলা হয়। আপনি ফাইল সম্পাদনা এবং সংরক্ষণ করার পরে, kubectl এপিআই-এর মাধ্যমে করা পরিবর্তনগুলিকে ফেরত পাঠাবে, যা এই পরিবর্তনগুলিকে সম্পদে সাবধানে প্রয়োগ করবে।

সবাই আদেশ জানেন না patch и replace. টীম patch কমান্ড লাইনে শুধুমাত্র পরিবর্তিত অংশ প্রদান করে আপনাকে রিসোর্স স্পেসিফিকেশনের অংশ পরিবর্তন করতে দেয়। টীম replace হিসাবে একই কাজ করে edit, কিন্তু সবকিছু ম্যানুয়ালি করা দরকার: আপনাকে রিসোর্স স্পেসিফিকেশনের বর্তমান সংস্করণ ডাউনলোড করতে হবে, উদাহরণস্বরূপ, ব্যবহার করে kubectl get -o yaml, এটি সম্পাদনা করুন, তারপর ব্যবহার করুন replace পরিবর্তিত স্পেসিফিকেশন অনুযায়ী একটি সম্পদ আপডেট করতে। টীম replace রিসোর্স পড়ার এবং প্রতিস্থাপনের মধ্যে কোনো পরিবর্তন ঘটলে কাজ করবে না।

কুবারনেটস এপিআই

আপনি সম্ভবত পদ্ধতিগুলির সাথে পরিচিত CoreV1().Pods().Update(), replaceNamespacedService বা patch_namespaced_deployment, যদি আপনি এর মাধ্যমে ক্লাস্টার নিয়ে কাজ করেন Kubernetes API-এর জন্য ক্লায়েন্ট লাইব্রেরি কিছু প্রোগ্রামিং ভাষা ব্যবহার করে। লাইব্রেরি পদ্ধতিগুলি ব্যবহার করে HTTP অনুরোধের মাধ্যমে এই পদ্ধতিগুলি পরিচালনা করে PUT и PATCH... যার মধ্যে update и replace ব্যবহার PUTএবং patch, এটি যতই তুচ্ছ হোক না কেন, ব্যবহার করে PATCH.

এটি যে মূল্যবান kubectl এছাড়াও API এর মাধ্যমে ক্লাস্টারগুলির সাথে কাজ করে। অন্য কথায়, kubectlএটি Go ভাষার জন্য ক্লায়েন্ট লাইব্রেরির উপরে একটি মোড়ক, যা সাধারণ API ক্ষমতা ছাড়াও আরও কমপ্যাক্ট এবং পঠনযোগ্য আকারে সাবকমান্ড প্রদান করার ক্ষমতা প্রদান করে। উদাহরণস্বরূপ, আপনি ইতিমধ্যে লক্ষ্য করেছেন, পদ্ধতি apply পূর্ববর্তী অনুচ্ছেদে উপরে উল্লেখ করা হয়নি। বর্তমানে (মে 2020, প্রায়. অনুবাদক) সব যুক্তি kubectl apply, অর্থাৎ অস্তিত্বহীন সংস্থান তৈরি করা এবং বিদ্যমানগুলিকে আপডেট করা, সম্পূর্ণভাবে কোডের দিকে কাজ করে kubectl. চেষ্টা চলছে যুক্তি স্থানান্তর উপর apply API এর দিকে, কিন্তু এটি এখনও বিটাতে রয়েছে। আমি নীচে আরো বিস্তারিত লিখব.

ডিফল্টরূপে প্যাচ

সবচেয়ে ভালো ব্যবহার করা হয় patch, আপনি যদি সম্পদ আপডেট করতে চান. এইভাবে উভয় ক্লায়েন্ট লাইব্রেরি Kubernetes API এর উপরে কাজ করে এবং kubectl (আশ্চর্যজনক নয়, যেহেতু এটি ক্লায়েন্ট লাইব্রেরির জন্য একটি মোড়ক, প্রায়. অনুবাদক).

কৌশলগতভাবে কাজ করুন

সব দল kubectl apply, edit и patch পদ্ধতি ব্যবহার করুন PATCH একটি বিদ্যমান সংস্থান আপডেট করার জন্য HTTP অনুরোধে। আপনি যদি আরও বিশদে কমান্ডের বাস্তবায়নের বিষয়ে অনুসন্ধান করেন, তবে তাদের সকলেই পদ্ধতিটি ব্যবহার করে কৌশলগত-একত্রীকরণ প্যাচিং সম্পদ আপডেট করতে, যদিও কমান্ড patch অন্যান্য পন্থা ব্যবহার করতে পারে (নীচে এই সম্পর্কে আরও)। কৌশলগত-একত্রীকরণ প্যাচিং পদ্ধতি বিদ্যমান স্পেসিফিকেশনের সাথে সরবরাহকৃত স্পেসিফিকেশনকে মার্জ করে "এটি সঠিকভাবে পেতে" চেষ্টা করে। আরও নির্দিষ্টভাবে, এটি বস্তু এবং অ্যারে উভয়কে একত্রিত করার চেষ্টা করে, যার অর্থ পরিবর্তনগুলি সংযোজন হতে থাকে। উদাহরণস্বরূপ, কমান্ড চালানো patch পড কন্টেইনার স্পেসিফিকেশনে একটি নতুন এনভায়রনমেন্ট ভেরিয়েবলের সাথে, সেই এনভায়রনমেন্ট ভেরিয়েবলটিকে বিদ্যমান এনভায়রনমেন্ট ভেরিয়েবলের সাথে ওভাররাইট করার পরিবর্তে যুক্ত করা হয়। এই পদ্ধতিটি ব্যবহার করে অপসারণ করতে, আপনাকে অবশ্যই প্রদত্ত স্পেসিফিকেশনে পরামিতি মানটিকে শূন্য করতে বাধ্য করতে হবে। কোন দলগুলো kubectl এটি আপডেট করার জন্য ব্যবহার করা ভাল?

আপনি ব্যবহার করে আপনার সম্পদ তৈরি এবং পরিচালনা করলে kubectl apply, আপডেট করার সময় এটি সর্বদা ব্যবহার করা ভাল kubectl applyযাতে kubectl কনফিগারেশন পরিচালনা করতে পারে এবং অ্যাপ্লিকেশন থেকে অ্যাপ্লিকেশনে অনুরোধ করা পরিবর্তনগুলি সঠিকভাবে ট্র্যাক করতে পারে। সুবিধা সবসময় ব্যবহার করুন apply এটি একটি পূর্বে প্রয়োগকৃত স্পেসিফিকেশনের ট্র্যাক রাখে, যখন স্পেসিফিকেশন বৈশিষ্ট্য এবং অ্যারে উপাদানগুলি স্পষ্টভাবে সরানো হয় তা জানতে দেয়। এটি আপনাকে ব্যবহার করতে দেয় apply বৈশিষ্ট্য এবং অ্যারে উপাদানগুলি সরাতে, যখন একটি সাধারণ কৌশলগত একত্রীকরণ কাজ করবে না। দল edit и patch নোট আপডেট করবেন না যে kubectl apply এর পরিবর্তনগুলি ট্র্যাক করতে ব্যবহার করে, তাই যে কোনও পরিবর্তন যা ট্র্যাক করা হয় এবং Kubernetes API এর মাধ্যমে করা হয়, কিন্তু কমান্ডের মাধ্যমে করা হয় edit и patch, পরবর্তী কমান্ডে অদৃশ্য apply, যে হয় apply সেগুলির জন্য ইনপুট স্পেসিফিকেশনে উপস্থিত না হলেও সেগুলিকে সরিয়ে দেয় না৷ apply (ডকুমেন্টেশন বলে যে edit и patch ব্যবহৃত নোট আপডেট করুন apply, কিন্তু অনুশীলনে - না)।

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

ক্লায়েন্ট লাইব্রেরিতে আপডেট পদ্ধতি প্রয়োগ করতে যা উপরের কমান্ডের অনুরূপ আচরণ করে kubectl, অনুরোধ সেট করা উচিত content-type в application/strategic-merge-patch+json. আপনি যদি একটি স্পেসিফিকেশনে বৈশিষ্ট্যগুলি সরাতে চান তবে আপনাকে স্পষ্টভাবে তাদের মানগুলিকে একইভাবে শূন্য করে দিতে হবে kubectl patch. আপনি যদি অ্যারে উপাদানগুলি সরাতে চান, আপনার আপডেট স্পেসিফিকেশনে মার্জ নির্দেশাবলী অন্তর্ভুক্ত করা উচিত বা আপডেটের জন্য একটি ভিন্ন পদ্ধতি ব্যবহার করা উচিত।

আপডেটের অন্যান্য পন্থা

Kubernetes দুটি অন্যান্য আপডেট পদ্ধতি সমর্থন করে: JSON প্যাচ মার্জ и JSON প্যাচ. JSON মার্জ প্যাচ পদ্ধতি ইনপুট হিসাবে একটি আংশিক Kubernetes স্পেসিফিকেশন গ্রহণ করে এবং কৌশলগত-মার্জ প্যাচিং পদ্ধতির অনুরূপ একত্রিত বস্তুকে সমর্থন করে। উভয়ের মধ্যে পার্থক্য হল যে এটি শুধুমাত্র পড স্পেসিফিকেশনে ধারক অ্যারে সহ অ্যারে প্রতিস্থাপন সমর্থন করে। এর মানে হল যে একটি JSON মার্জ প্যাচ ব্যবহার করার সময়, কোনো কন্টেইনারের কোনো সম্পত্তি পরিবর্তন হলে আপনাকে সমস্ত কন্টেইনারের জন্য সম্পূর্ণ স্পেসিফিকেশন প্রদান করতে হবে। সুতরাং এই পদ্ধতিটি একটি BOM এ একটি অ্যারে থেকে উপাদানগুলি সরানোর জন্য দরকারী। কমান্ড লাইনে আপনি JSON মার্জ প্যাচ ব্যবহার করে নির্বাচন করতে পারেন kubectl patch --type=merge. Kubernetes API এর সাথে কাজ করার সময়, আপনার অনুরোধ পদ্ধতিটি ব্যবহার করা উচিত PATCH এবং ইনস্টলেশন content-type в application/merge-patch+json.

JSON প্যাচ পদ্ধতি, একটি সম্পদের আংশিক স্পেসিফিকেশন প্রদান করার পরিবর্তে, আপনি একটি অ্যারে হিসাবে সম্পদে যে পরিবর্তনগুলি করতে চান তা প্রদান করে, যেখানে অ্যারের প্রতিটি উপাদান সম্পদে করা পরিবর্তনের একটি বিবরণ উপস্থাপন করে। এই পদ্ধতিটি করা পরিবর্তনগুলিকে প্রকাশ করার জন্য একটি আরও নমনীয় এবং শক্তিশালী উপায়, তবে একটি আংশিক সংস্থান স্পেসিফিকেশন পাঠানোর পরিবর্তে একটি পৃথক, নন-কুবারনেট ফরম্যাটে করা পরিবর্তনগুলি তালিকাভুক্ত করার খরচে। ভিতরে kubectl আপনি ব্যবহার করে JSON প্যাচ নির্বাচন করতে পারেন kubectl patch --type=json. Kubernetes API ব্যবহার করার সময়, এই পদ্ধতি অনুরোধ পদ্ধতি ব্যবহার করে কাজ করে PATCH এবং ইনস্টলেশন content-type в application/json-patch+json.

আমাদের আত্মবিশ্বাস দরকার - প্রতিস্থাপন ব্যবহার করুন

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

• A এবং B API থেকে সম্পদের বর্তমান অবস্থা পায়
• প্রত্যেকে স্থানীয়ভাবে কাউন্টারটিকে একটি করে বৃদ্ধি করে এবং "আপডেট-বাই" নোটে যথাক্রমে "A" বা "B" যোগ করে স্পেসিফিকেশন আপডেট করে।
• এবং এটি রিসোর্সটিকে একটু দ্রুত আপডেট করে
• B সম্পদ আপডেট করে

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

• A এবং B API থেকে সম্পদের বর্তমান অবস্থা পায়
• প্রত্যেকে স্থানীয়ভাবে কাউন্টারটিকে একটি করে বৃদ্ধি করে এবং "আপডেট-বাই" নোটে যথাক্রমে "A" বা "B" যোগ করে স্পেসিফিকেশন আপডেট করে।
• এবং এটি রিসোর্সটিকে একটু দ্রুত আপডেট করে
• B সম্পদ আপডেট করার চেষ্টা করে, কিন্তু আপডেটটি API দ্বারা প্রত্যাখ্যান করা হয় কারণ রিসোর্স সংস্করণটি স্পেসিফিকেশনে রয়েছে replace Kubernetes-এ রিসোর্সের বর্তমান সংস্করণের সাথে মেলে না কারণ A-এর রিপ্লেস অপারেশনের মাধ্যমে রিসোর্সের সংস্করণ বৃদ্ধি করা হয়েছে।

উপরের ক্ষেত্রে, B-কে রিসোর্সটি পুনরায় আনতে হবে, নতুন অবস্থায় পরিবর্তন করতে হবে এবং আবার চেষ্টা করতে হবে replace. এর ফলে কাউন্টারটিকে দুই দ্বারা বৃদ্ধি করা হবে এবং "আপডেট-বাই" নোটের শেষে "AB" অন্তর্ভুক্ত করা হবে।

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

$ kubectl get deployment my-deployment -o json 
    | jq '.spec.template.spec.containers[0].env[1].value = "new value"' 
    | kubectl replace -f -

এটি লক্ষণীয় যে নিম্নলিখিত দুটি কমান্ড, ক্রমিকভাবে কার্যকর করা হয়েছে, সফলভাবে কার্যকর হবে, যেহেতু deployment.yaml সম্পত্তি ধারণ করে না .metadata.resourceVersion

$ kubectl create -f deployment.yaml
$ kubectl replace -f deployment.yaml

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

আপনি একটি প্যাচ করতে পারবেন না - আমরা একটি প্রতিস্থাপন করি

কখনও কখনও আপনাকে কিছু পরিবর্তন করতে হবে যা API দ্বারা পরিচালনা করা যায় না। এই ক্ষেত্রে, আপনি রিসোর্সটি মুছে এবং পুনরায় তৈরি করে প্রতিস্থাপন করতে বাধ্য করতে পারেন। এটি ব্যবহার করে করা হয় kubectl replace --force. কমান্ডটি চালানো অবিলম্বে সংস্থানগুলিকে সরিয়ে দেয় এবং তারপরে সরবরাহকৃত স্পেসিফিকেশন থেকে পুনরায় তৈরি করে। API তে কোন "ফোর্স রিপ্লেস" হ্যান্ডলার নেই, এবং API এর মাধ্যমে এটি করার জন্য, আপনাকে দুটি অপারেশন করতে হবে। প্রথমে আপনাকে এটির জন্য সেট করে সংস্থানটি মুছতে হবে gracePeriodSeconds থেকে শূন্য (0) এবং propagationPolicy "ব্যাকগ্রাউন্ড"-এ এবং তারপরে পছন্দসই স্পেসিফিকেশন সহ এই সংস্থানটি পুনরায় তৈরি করুন।

সতর্কতা: এই পদ্ধতিটি সম্ভাব্য বিপজ্জনক এবং একটি অনির্ধারিত অবস্থার দিকে নিয়ে যেতে পারে।

সার্ভার সাইডে আবেদন করুন

উপরে উল্লিখিত হিসাবে, Kubernetes বিকাশকারীরা যুক্তি বাস্তবায়নে কাজ করছে apply থেকে kubectl Kubernetes API-এ। যুক্তিবিদ্যা apply Kubernetes 1.18 এর মাধ্যমে উপলব্ধ kubectl apply --server-side অথবা পদ্ধতি ব্যবহার করে API এর মাধ্যমে PATCH с content-type application/apply-patch+YAML.

দ্রষ্টব্য: JSON বৈধ YAML, তাই আপনি JSON হিসাবেও স্পেসিফিকেশন পাঠাতে পারেন content-type হতে হবে application/apply-patch+yaml.

যে যুক্তি ছাড়াও kubectl API এর মাধ্যমে সকলের কাছে উপলব্ধ হয়, apply সার্ভারের দিকে, স্পেসিফিকেশনে ক্ষেত্রগুলির জন্য কে দায়ী তা ট্র্যাক রাখে, এইভাবে এর দ্বন্দ্ব-মুক্ত সম্পাদনার জন্য নিরাপদ একাধিক অ্যাক্সেসের অনুমতি দেয়। অন্য কথায়, যদি apply সার্ভারের দিকে আরও ব্যাপক হয়ে উঠবে, একটি সার্বজনীন নিরাপদ সম্পদ ব্যবস্থাপনা ইন্টারফেস বিভিন্ন ক্লায়েন্টদের জন্য প্রদর্শিত হবে, উদাহরণস্বরূপ, kubectl, Pulumi বা Terraform, GitOps, সেইসাথে ক্লায়েন্ট লাইব্রেরি ব্যবহার করে স্ব-লিখিত স্ক্রিপ্ট।

ফলাফল

আমি আশা করি ক্লাস্টারে সংস্থানগুলি আপডেট করার বিভিন্ন উপায়ের এই সংক্ষিপ্ত ওভারভিউ আপনার জন্য সহায়ক ছিল। এটি জেনে রাখা ভালো যে এটি শুধুমাত্র প্রয়োগ বনাম প্রতিস্থাপন নয়; প্রয়োগ, সম্পাদনা, প্যাচ বা প্রতিস্থাপন ব্যবহার করে একটি সংস্থান আপডেট করা সম্ভব। সর্বোপরি, নীতিগতভাবে, প্রতিটি পদ্ধতির প্রয়োগের নিজস্ব ক্ষেত্র রয়েছে। পারমাণবিক পরিবর্তনের জন্য, প্রতিস্থাপন পছন্দনীয়; অন্যথায়, আপনার প্রয়োগের মাধ্যমে কৌশলগত-মার্জ প্যাচ ব্যবহার করা উচিত। অন্ততপক্ষে, আমি আশা করি আপনি বুঝতে পারবেন যে "kubernetes apply vs replace" অনুসন্ধান করার সময় আপনি Google বা StackOerflow কে বিশ্বাস করতে পারবেন না। অন্তত যতক্ষণ না এই নিবন্ধটি বর্তমান উত্তর প্রতিস্থাপন করে।

উত্স: www.habr.com