যাওয়া? বাশ ! শেল-অপারেটরের সাথে দেখা করুন (KubeCon EU'2020 থেকে পর্যালোচনা এবং ভিডিও প্রতিবেদন)

এই বছর, প্রধান ইউরোপীয় কুবারনেটস সম্মেলন - KubeCon + CloudNativeCon Europe 2020 - ভার্চুয়াল ছিল। যাইহোক, ফরম্যাটে এই ধরনের পরিবর্তন আমাদের দীর্ঘ পরিকল্পিত রিপোর্ট প্রদান করতে বাধা দেয়নি “যাও? বাশ ! আমাদের ওপেন সোর্স প্রকল্পে নিবেদিত শেল-অপারেটরের সাথে দেখা করুন শেল-অপারেটর.

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

পরিচয় করিয়ে দিচ্ছে প্রতিবেদনের ভিডিও (ইংরেজিতে ~23 মিনিট, নিবন্ধের চেয়ে লক্ষণীয়ভাবে আরও তথ্যপূর্ণ) এবং পাঠ্য আকারে এটি থেকে মূল নির্যাস। যাওয়া!

ফ্লান্টে আমরা ক্রমাগত সবকিছু অপ্টিমাইজ এবং স্বয়ংক্রিয়ভাবে করি। আজ আমরা আরেকটি উত্তেজনাপূর্ণ ধারণা সম্পর্কে কথা বলব। সম্মেলন: ক্লাউড-নেটিভ শেল স্ক্রিপ্টিং!

যাইহোক, আসুন সেই প্রসঙ্গে শুরু করা যাক যেখানে এই সব ঘটে: কুবারনেটস।

কুবারনেটস এপিআই এবং কন্ট্রোলার

Kubernetes-এ API-কে প্রতিটি ধরনের বস্তুর জন্য ডিরেক্টরি সহ এক ধরনের ফাইল সার্ভার হিসাবে উপস্থাপন করা যেতে পারে। এই সার্ভারে বস্তু (সম্পদ) YAML ফাইল দ্বারা প্রতিনিধিত্ব করা হয়। এছাড়াও, সার্ভারের একটি মৌলিক API রয়েছে যা আপনাকে তিনটি জিনিস করতে দেয়:

• গ্রহণ করা সম্পদ তার প্রকার এবং নাম দ্বারা;
• পরিবর্তন রিসোর্স (এই ক্ষেত্রে, সার্ভার শুধুমাত্র "সঠিক" বস্তু সঞ্চয় করে - সমস্ত ভুলভাবে গঠিত বা অন্যান্য ডিরেক্টরির জন্য উদ্দেশ্য বাতিল করা হয়);
• ট্র্যাক সম্পদের জন্য (এই ক্ষেত্রে, ব্যবহারকারী অবিলম্বে তার বর্তমান/হালনাগাদ সংস্করণ গ্রহণ করে)।

এইভাবে, Kubernetes তিনটি মৌলিক পদ্ধতির সাথে (YAML ম্যানিফেস্টের জন্য) এক ধরনের ফাইল সার্ভার হিসাবে কাজ করে (হ্যাঁ, আসলে অন্যান্য আছে, কিন্তু আমরা এখন সেগুলি বাদ দেব)।

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

দুটি প্রধান ধরনের কন্ট্রোলার আছে। প্রথমটি Kubernetes থেকে তথ্য নেয়, নেস্টেড লজিক অনুযায়ী এটি প্রক্রিয়া করে এবং K8s এ ফেরত দেয়। দ্বিতীয়টি Kubernetes থেকে তথ্য নেয়, কিন্তু, প্রথম ধরনের থেকে ভিন্ন, কিছু বাহ্যিক সম্পদের অবস্থা পরিবর্তন করে।

আসুন কুবারনেটসে একটি স্থাপনা তৈরির প্রক্রিয়াটি ঘনিষ্ঠভাবে দেখে নেওয়া যাক:

• স্থাপনা নিয়ন্ত্রক (অন্তর্ভুক্ত kube-controller-manager) স্থাপনার বিষয়ে তথ্য পায় এবং একটি ReplicaSet তৈরি করে।
• ReplicaSet এই তথ্যের উপর ভিত্তি করে দুটি রেপ্লিকা (দুটি পড) তৈরি করে, কিন্তু এই পডগুলি এখনও নির্ধারিত হয়নি।
• শিডিউলকারী পডের সময়সূচী নির্ধারণ করে এবং তাদের YAML-এ নোড তথ্য যোগ করে।
• কুবেলেটগুলি একটি বাহ্যিক সংস্থানে পরিবর্তন করে (ডকার বলুন)।

তারপর এই পুরো ক্রমটি বিপরীত ক্রমে পুনরাবৃত্তি হয়: কুবেলেট পাত্রগুলি পরীক্ষা করে, পডের অবস্থা গণনা করে এবং এটি ফেরত পাঠায়। ReplicaSet কন্ট্রোলার স্ট্যাটাস পায় এবং রেপ্লিকা সেটের অবস্থা আপডেট করে। ডিপ্লয়মেন্ট কন্ট্রোলারের সাথে একই জিনিস ঘটে এবং ব্যবহারকারী অবশেষে আপডেট (বর্তমান) অবস্থা পায়।

শেল-অপারেটর

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

সহজ উদাহরণ: গোপনীয়তা অনুলিপি করা

এর একটি সহজ উদাহরণ তাকান.

ধরা যাক আমাদের একটি Kubernetes ক্লাস্টার আছে। এটি একটি নামস্থান আছে default সাথে কিছু সিক্রেট mysecret. এছাড়াও, ক্লাস্টারে অন্যান্য নামস্থান রয়েছে। তাদের কিছু তাদের সাথে সংযুক্ত একটি নির্দিষ্ট লেবেল আছে. আমাদের লক্ষ্য হল সিক্রেটকে একটি লেবেল সহ নামস্থানে অনুলিপি করা।

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

এখন যেহেতু কাজটি প্রণয়ন করা হয়েছে, এটি শেল-অপারেটর ব্যবহার করে এটি বাস্তবায়ন শুরু করার সময়। তবে প্রথমে শেল-অপারেটর নিজেই সম্পর্কে কয়েকটি শব্দ বলা মূল্যবান।

শেল-অপারেটর কিভাবে কাজ করে

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

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

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

ব্যাশে একজন অপারেটর তৈরি করা হচ্ছে

এখন আমরা বাস্তবায়নের জন্য প্রস্তুত। এটি করার জন্য, আমাদের দুটি ফাংশন লিখতে হবে (যাইহোক, আমরা সুপারিশ করি গ্রন্থাগার shell_lib, যা বাশে লেখার হুকগুলিকে ব্যাপকভাবে সহজ করে তোলে):

• কনফিগারেশন পর্যায়ের জন্য প্রথমটি প্রয়োজন - এটি বাঁধাই প্রসঙ্গ প্রদর্শন করে;
• দ্বিতীয়টিতে হুকের প্রধান যুক্তি রয়েছে।

#!/bin/bash

source /shell_lib.sh

function __config__() {
  cat << EOF
    configVersion: v1
    # BINDING CONFIGURATION
EOF
}

function __main__() {
  # THE LOGIC
}

hook::run "$@"

পরবর্তী পদক্ষেপ হল আমাদের কোন বস্তুর প্রয়োজন তা নির্ধারণ করা। আমাদের ক্ষেত্রে, আমাদের ট্র্যাক করতে হবে:

• পরিবর্তনের জন্য উৎস গোপন;
• ক্লাস্টারের সমস্ত নামস্থান, যাতে আপনি জানেন যে কোনটির সাথে একটি লেবেল সংযুক্ত আছে;
• লক্ষ্য গোপন নিশ্চিত করুন যে তারা সমস্ত উৎস গোপনের সাথে সিঙ্ক হয়।

গোপন সূত্রে সদস্যতা নিন

এটির জন্য বাঁধাই কনফিগারেশন বেশ সহজ। আমরা ইঙ্গিত করি যে আমরা নামের সাথে গোপনে আগ্রহী mysecret নামস্থানে default:

function __config__() {
  cat << EOF
    configVersion: v1
    kubernetes:
    - name: src_secret
      apiVersion: v1
      kind: Secret
      nameSelector:
        matchNames:
        - mysecret
      namespace:
        nameSelector:
          matchNames: ["default"]
      group: main
EOF

ফলস্বরূপ, উৎস গোপন পরিবর্তন হলে হুক ট্রিগার হবে (src_secret) এবং নিম্নলিখিত বাধ্যতামূলক প্রসঙ্গটি পান:

আপনি দেখতে পাচ্ছেন, এতে নাম এবং সম্পূর্ণ বস্তু রয়েছে।

নামস্থান ট্র্যাক রাখা

এখন আপনাকে নামস্থানে সদস্যতা নিতে হবে। এটি করার জন্য, আমরা নিম্নলিখিত বাঁধাই কনফিগারেশন নির্দিষ্ট করি:

- name: namespaces
  group: main
  apiVersion: v1
  kind: Namespace
  jqFilter: |
    {
      namespace: .metadata.name,
      hasLabel: (
       .metadata.labels // {} |  
         contains({"secret": "yes"})
      )
    }
  group: main
  keepFullObjectsInMemory: false

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

এটিতে একটি অ্যারে রয়েছে filterResults ক্লাস্টারের প্রতিটি নামস্থানের জন্য। বুলিয়ান পরিবর্তনশীল hasLabel একটি প্রদত্ত নামস্থানে একটি লেবেল সংযুক্ত কিনা তা নির্দেশ করে৷ নির্বাচক keepFullObjectsInMemory: false ইঙ্গিত করে যে মেমরিতে সম্পূর্ণ বস্তু রাখার প্রয়োজন নেই।

লক্ষ্য গোপন ট্র্যাকিং

আমরা একটি টীকা নির্দিষ্ট আছে যে সমস্ত গোপন সদস্যতা managed-secret: "yes" (এগুলো আমাদের লক্ষ্য dst_secrets):

- name: dst_secrets
  apiVersion: v1
  kind: Secret
  labelSelector:
    matchLabels:
      managed-secret: "yes"
  jqFilter: |
    {
      "namespace":
        .metadata.namespace,
      "resourceVersion":
        .metadata.annotations.resourceVersion
    }
  group: main
  keepFullObjectsInMemory: false

এই ক্ষেত্রে jqFilter নেমস্পেস এবং প্যারামিটার ছাড়া সমস্ত তথ্য ফিল্টার করে resourceVersion. গোপন তৈরি করার সময় শেষ প্যারামিটারটি টীকাতে পাস করা হয়েছিল: এটি আপনাকে গোপনীয়তার সংস্করণগুলি তুলনা করতে এবং সেগুলি আপ টু ডেট রাখতে দেয়।

এইভাবে কনফিগার করা একটি হুক, কার্যকর করা হলে, উপরে বর্ণিত তিনটি বাঁধাই প্রসঙ্গ প্রাপ্ত হবে। এগুলিকে এক ধরণের স্ন্যাপশট হিসাবে ভাবা যেতে পারে (স্ন্যাপশট) ক্লাস্টার।

এই সমস্ত তথ্যের উপর ভিত্তি করে, একটি মৌলিক অ্যালগরিদম তৈরি করা যেতে পারে। এটি সমস্ত নামস্থানে পুনরাবৃত্তি করে এবং:

• যদি hasLabel বিষয় true বর্তমান নামস্থানের জন্য:
  • স্থানীয় গোপন সঙ্গে বৈশ্বিক গোপন তুলনা:
    • যদি তারা একই হয়, এটি কিছুই করে না;
    • যদি তারা ভিন্ন হয় - চালায় kubectl replace বা create;
• যদি hasLabel বিষয় false বর্তমান নামস্থানের জন্য:
  • নিশ্চিত করে যে গোপন প্রদত্ত নামস্থানে নেই:
    • স্থানীয় গোপনীয়তা উপস্থিত থাকলে, এটি ব্যবহার করে মুছে ফেলুন kubectl delete;
    • স্থানীয় গোপনীয়তা সনাক্ত করা না হলে, এটি কিছুই করে না।

ব্যাশে অ্যালগরিদম বাস্তবায়ন আপনি আমাদের ডাউনলোড করতে পারেন উদাহরণ সহ সংগ্রহস্থল.

এভাবেই আমরা YAML কনফিগারেশনের 35 লাইন এবং প্রায় একই পরিমাণ ব্যাশ কোড ব্যবহার করে একটি সাধারণ Kubernetes কন্ট্রোলার তৈরি করতে সক্ষম হয়েছি! শেল-অপারেটরের কাজ তাদের একসাথে লিঙ্ক করা।

যাইহোক, গোপনীয়তা অনুলিপি করা ইউটিলিটির প্রয়োগের একমাত্র ক্ষেত্র নয়। তিনি কী করতে সক্ষম তা দেখানোর জন্য এখানে আরও কয়েকটি উদাহরণ রয়েছে।

উদাহরণ 1: কনফিগম্যাপে পরিবর্তন করা

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

এখন ধরা যাক কনফিগম্যাপ পরিবর্তিত হয়েছে (v.2)। যাইহোক, পডগুলি ConfigMap (v.1) এর পূর্ববর্তী সংস্করণ ব্যবহার করবে:

কিভাবে আমি তাদের নতুন ConfigMap (v.2) এ স্যুইচ করতে পারি? উত্তরটি সহজ: একটি টেমপ্লেট ব্যবহার করুন। বিভাগে একটি চেকসাম টীকা যোগ করা যাক template স্থাপনার কনফিগারেশন:

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

ব্যবহারকারী কনফিগম্যাপে পরিবর্তন করলে, শেল-অপারেটর তাদের লক্ষ্য করবে এবং চেকসাম পুনরায় গণনা করবে। এর পরে কুবারনেটসের যাদুটি কার্যকর হবে: অর্কেস্ট্রেটর পডটিকে মেরে ফেলবে, একটি নতুন তৈরি করবে, এটি হওয়ার জন্য অপেক্ষা করুন Ready, এবং পরবর্তীতে চলে যায়। ফলস্বরূপ, ডিপ্লয়মেন্ট সিঙ্ক্রোনাইজ হবে এবং কনফিগম্যাপের নতুন সংস্করণে স্যুইচ করবে।

উদাহরণ 2: কাস্টম রিসোর্স সংজ্ঞার সাথে কাজ করা

আপনি জানেন, কুবারনেটস আপনাকে কাস্টম ধরনের অবজেক্ট তৈরি করতে দেয়। উদাহরণস্বরূপ, আপনি ধরনের তৈরি করতে পারেন MysqlDatabase. ধরা যাক এই ধরনের দুটি মেটাডেটা পরামিতি আছে: name и namespace.

apiVersion: example.com/v1alpha1
kind: MysqlDatabase
metadata:
  name: foo
  namespace: bar

আমাদের কাছে বিভিন্ন নামস্থান সহ একটি কুবারনেটস ক্লাস্টার রয়েছে যেখানে আমরা মাইএসকিউএল ডেটাবেস তৈরি করতে পারি। এই ক্ষেত্রে শেল-অপারেটর রিসোর্স ট্র্যাক করতে ব্যবহার করা যেতে পারে MysqlDatabase, সেগুলিকে MySQL সার্ভারের সাথে সংযুক্ত করে এবং ক্লাস্টারের পছন্দসই এবং পর্যবেক্ষিত অবস্থাগুলিকে সিঙ্ক্রোনাইজ করে৷

উদাহরণ 3: ক্লাস্টার নেটওয়ার্ক মনিটরিং

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

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

configVersion: v1
kubernetes:
- name: nodes
  apiVersion: v1
  kind: Node
  jqFilter: |
    {
      name: .metadata.name,
      ip: (
       .status.addresses[] |  
        select(.type == "InternalIP") |
        .address
      )
    }
  group: main
  keepFullObjectsInMemory: false
  executeHookOnEvent: []
schedule:
- name: every_minute
  group: main
  crontab: "* * * * *"

স্থিতিমাপ executeHookOnEvent: [] যে কোনো ইভেন্টের প্রতিক্রিয়ায় হুককে চলতে বাধা দেয় (অর্থাৎ নোড পরিবর্তন, যোগ, মুছে ফেলার প্রতিক্রিয়ায়)। যাইহোক, তিনি চলবে (এবং নোডের তালিকা আপডেট করুন) তালিকাভুক্ত - প্রতি মিনিটে, ক্ষেত্র দ্বারা নির্ধারিত হিসাবে schedule.

এখন প্রশ্ন জাগে, প্যাকেট লসের মতো সমস্যা সম্পর্কে আমরা ঠিক কীভাবে জানব? আসুন কোডটি দেখে নেওয়া যাক:

function __main__() {
  for i in $(seq 0 "$(context::jq -r '(.snapshots.nodes | length) - 1')"); do
    node_name="$(context::jq -r '.snapshots.nodes['"$i"'].filterResult.name')"
    node_ip="$(context::jq -r '.snapshots.nodes['"$i"'].filterResult.ip')"
    packets_lost=0
    if ! ping -c 1 "$node_ip" -t 1 ; then
      packets_lost=1
    fi
    cat >> "$METRICS_PATH" <<END
      {
        "name": "node_packets_lost",
        "add": $packets_lost,
        "labels": {
          "node": "$node_name"
        }
      }
END
  done
}

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

এখানে তাই আপনি একটি ক্লাস্টারে সাধারণ নেটওয়ার্ক পর্যবেক্ষণের জন্য একটি অপারেটর তৈরি করতে পারেন।

সারিবদ্ধ প্রক্রিয়া

শেল-অপারেটরে নির্মিত আরেকটি গুরুত্বপূর্ণ প্রক্রিয়া বর্ণনা না করে এই নিবন্ধটি অসম্পূর্ণ হবে। কল্পনা করুন যে এটি ক্লাস্টারে একটি ইভেন্টের প্রতিক্রিয়া হিসাবে কিছু ধরণের হুক কার্যকর করে।

• কি হবে যদি, একই সময়ে, ক্লাস্টারে কিছু ঘটে? আরো একটা ঘটনা?
• শেল-অপারেটর হুকের আরেকটি উদাহরণ চালাবে?
• যদি বলুন, ক্লাস্টারে একবারে পাঁচটি ঘটনা ঘটবে?
• শেল-অপারেটর কি তাদের সমান্তরালভাবে প্রক্রিয়া করবে?
• মেমরি এবং সিপিইউ এর মতো ক্ষয়প্রাপ্ত সংস্থান সম্পর্কে কী?

ভাগ্যক্রমে, শেল-অপারেটরের একটি অন্তর্নির্মিত সারিবদ্ধ প্রক্রিয়া রয়েছে। সমস্ত ইভেন্ট সারিবদ্ধ এবং ক্রমানুসারে প্রক্রিয়া করা হয়।

উদাহরণ দিয়ে এটি ব্যাখ্যা করা যাক। ধরা যাক আমাদের দুটি হুক আছে। প্রথম ঘটনা প্রথম হুক যায়. এর প্রক্রিয়াকরণ সম্পূর্ণ হলে, সারিটি এগিয়ে যায়। পরবর্তী তিনটি ইভেন্ট দ্বিতীয় হুকে পুনঃনির্দেশিত হয় - সেগুলি সারি থেকে সরানো হয় এবং একটি "বান্ডেল" এ প্রবেশ করা হয়। এটাই হুক ইভেন্টের একটি অ্যারে পায় — অথবা, আরও স্পষ্টভাবে, বাঁধাই প্রসঙ্গগুলির একটি অ্যারে।

এছাড়াও এই ইভেন্ট একটি বড় মধ্যে মিলিত করা যেতে পারে. প্যারামিটার এর জন্য দায়ী group বাঁধাই কনফিগারেশনে।

আপনি যেকোনো সংখ্যক সারি/হুক এবং তাদের বিভিন্ন সমন্বয় তৈরি করতে পারেন। উদাহরণস্বরূপ, একটি সারি দুটি হুক দিয়ে কাজ করতে পারে, বা তদ্বিপরীত।

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

উপসংহার

আমরা একটি শেল-অপারেটর কী তা ব্যাখ্যা করেছি, দেখিয়েছি কিভাবে এটি দ্রুত এবং অনায়াসে কুবারনেটস অপারেটর তৈরি করতে ব্যবহার করা যেতে পারে, এবং এর ব্যবহারের কয়েকটি উদাহরণ দিয়েছি।

শেল-অপারেটর সম্পর্কে বিস্তারিত তথ্য, সেইসাথে এটি কীভাবে ব্যবহার করবেন তার একটি দ্রুত টিউটোরিয়াল, সংশ্লিষ্ট এ উপলব্ধ GitHub এ সংগ্রহস্থল. প্রশ্ন সঙ্গে আমাদের সাথে যোগাযোগ করতে দ্বিধা করবেন না: আপনি একটি বিশেষ আলোচনা করতে পারেন টেলিগ্রাম গ্রুপ (রাশিয়ান ভাষায়) বা এই ফোরাম (ইংরেজীতে).

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

ভিডিও এবং স্লাইড

পারফরম্যান্স থেকে ভিডিও (~23 মিনিট):

প্রতিবেদনের উপস্থাপনা:

দ্রষ্টব্য

আমাদের ব্লগেও পড়ুন:

• «শেল-অপারেটর সহ কুবারনেটস অপারেটরদের সহজ তৈরি: বছরের পর বছর ধরে প্রকল্পের অগ্রগতি";
• «শেল-অপারেটর প্রবর্তন করা হচ্ছে: Kubernetes-এর জন্য অপারেটর তৈরি করা আরও সহজ হয়েছে";
• «একটি Kubernetes ক্লাস্টার প্রস্তুত করা কি সহজ এবং সুবিধাজনক? অ্যাডঅন-অপারেটর ঘোষণা করা হচ্ছে";
• «Kubernetes সম্প্রসারণ এবং পরিপূরক" (পর্যালোচনা এবং ভিডিও প্রতিবেদন).

উত্স: www.habr.com