ডকার কম্পোজ বনাম কুবারনেটস: কখন প্রতিটি ব্যবহার করবেন, পার্থক্য এবং মাইগ্রেশন

ইনফরমটেক ডিজিটাল » মানে » ডকার কম্পোজ বনাম কুবারনেটস: কখন প্রতিটি ব্যবহার করবেন, পার্থক্য এবং মাইগ্রেশন

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

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

ডকার এবং ডকার কম্পোজ কী (এবং এগুলি আসলে কীসের জন্য)?

যখন আমরা ডকার নিয়ে কথা বলি, তখন আমরা আসলে একটি ইকোসিস্টেমের কথাই বলি: ডকার ইঞ্জিন, ডকার হাব, ডকারফাইল, ডকার কম্পোজ … ইঞ্জিনটি ইমেজ থেকে কন্টেইনার তৈরি করে এবং চালায়; হাব সেগুলোকে সহজে শেয়ার করার সুযোগ দেয়; এবং কম্পোজ আপনাকে একটি YAML ফাইলে স্ট্যাকের বিভিন্ন অংশ সংজ্ঞায়িত করার সুবিধা দেয়, যাতে আপনি একটিমাত্র কমান্ড দিয়ে সেগুলোকে চালু করতে পারেন।

অগণিত স্ক্রিপ্ট এবং বিচ্ছিন্ন কমান্ড থেকে আমাদের মুক্তি দিতেই কম্পোজ তৈরি করা হয়েছিল। একটিমাত্র docker-compose.yml ফাইলের মাধ্যমে আপনি সার্ভিস, নেটওয়ার্ক এবং ভলিউম বর্ণনা করতে পারেন , এবং একটিমাত্র "docker compose up" (অথবা V1-এ "docker-compose up") কমান্ড দিয়েই সবকিছু চালু করে ফেলতে পারেন। লোকাল ডেভেলপমেন্ট, ইন্টিগ্রেটেড টেস্টিং, ডেমো বা CI এনভায়রনমেন্টের জন্য এটি আদর্শ ।

Compose-এর একটি আদর্শ উদাহরণ হতে পারে এটি, যেখানে একটি API এবং একটি Postgres ডাটাবেস রয়েছে। লক্ষ্য করুন, কীভাবে ডিপেন্ডেন্সি, ভেরিয়েবল এবং পোর্টগুলো একটি পাঠযোগ্য ব্লকের মধ্যে ঘোষণা করা হয়েছে:

version: '3.8'
services:
  db:
    image: postgres:latest
    restart: always
    environment:
      - POSTGRES_USER=postgres
      - POSTGRES_PASSWORD=postgres
      - POSTGRES_DB=postgres
    ports:
      - '5432:5432'
    volumes:
      - db:/var/lib/postgresql/data
    networks:
      - mynet

  my-api:
    container_name: my-api
    build:
      context: ./
    image: my-api
    depends_on:
      - db
    ports:
      - '8080:8080'
    environment:
      DB_HOST: db
      DB_PORT: 5432
      DB_USER: postgres
      DB_PASSWORD: postgres
      DB_NAME: postgres
    networks:
      - mynet

networks:
  mynet:
    driver: bridge

volumes:
  db:
    driver: local

Compose-এ ম্যানুয়ালি স্কেল করার জন্য, আপনি সার্ভিসের স্কেলিং অপশনটি ব্যবহার করতে পারেন। Compose V2-তে, সাধারণত `up --scale` ব্যবহার করে এটি করা হয় (V1-এ `docker-compose scale` ছিল):

docker compose up -d --scale my-api=3

সীমাবদ্ধতাগুলো সম্পর্কে সতর্ক থাকুন: Compose একটিমাত্র হোস্টের জন্য ডিজাইন করা হয়েছে , এটি নোডগুলোর মধ্যে লোড ব্যালেন্সিং বা অটোস্কেলিং করে না, এবং আপডেটগুলো সাধারণত 'build' ও 'up -d' কমান্ড ব্যবহার করে কন্টেইনারগুলো ম্যানুয়ালি পুনরায় তৈরি করার মাধ্যমে করা হয়।

কুবারনেটস কী এবং এটি কম্পোজের মাধ্যমে কী অফার করে?

কুবারনেটিস (K8s) হলো একটি ডিস্ট্রিবিউটেড কন্টেইনার অর্কেস্ট্রেশন প্ল্যাটফর্ম। এটি প্রোডাকশন ওয়ার্কলোড পরিচালনার জন্য পড, ডিপ্লয়মেন্ট এবং সার্ভিসের মতো ধারণার মাধ্যমে মাল্টি-নোড ক্লাস্টার জুড়ে বৃহৎ পরিসরে ডিপ্লয়মেন্ট পরিচালনা করে ।

কুবারনেটিসে, আপনি স্বতন্ত্র কন্টেইনার পরিচালনা করেন না; আপনি পড (Pod) পরিচালনা করেন (যার মধ্যে এক বা একাধিক কন্টেইনার থাকতে পারে)। কন্ট্রোল প্লেন প্রতিটি পডের চলার স্থান নির্ধারণ করে , সার্ভিসগুলো উন্মুক্ত করে, ট্র্যাফিক বিতরণ করে, হরাইজন্টালি স্কেল করে এবং ওয়ার্কলোডের স্বাস্থ্য পর্যবেক্ষণ করে।

একটি সাধারণ ডেপ্লয়মেন্ট দেখতে এইরকম হতে পারে, যেখানে একটি ওয়েব সার্ভিসের ৩টি রেপ্লিকা থাকবে। টেমপ্লেট, লেবেল এবং এক্সপোজড পোর্টগুলো সংজ্ঞায়িত করুন :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: my-web-image
          ports:
            - containerPort: 8000

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

apiVersion: v1
kind: Service
metadata:
  name: web-service
spec:
  selector:
    app: web
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8000
  type: LoadBalancer

প্রোডাকশনে, কুবারনেটিস হাই-পারফরম্যান্স অটোমেশন (HPA), রোলিং আপডেট এবং সেলফ-রিকভারির মতো সক্ষমতা দিয়ে বিশেষভাবে কার্যকর। HPA মেট্রিক্সের (যেমন, সিপিইউ ব্যবহার) উপর ভিত্তি করে রেপ্লিকাগুলো সমন্বয় করে ।

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: web-hpa
spec:
  minReplicas: 1
  maxReplicas: 10
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-deployment
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 50

প্রোবের মাধ্যমে কন্টেইনারের স্বাস্থ্য পর্যবেক্ষণ করা হয়; যদি সেগুলি ব্যর্থ হয়, K8s কন্টেইনারটি পুনরায় চালু করে। এটাই 'সেলফ-হিলিং'-এর ভিত্তি ।

apiVersion: v1
kind: Pod
metadata:
  name: web-pod
spec:
  containers:
    - name: web
      image: my-web-image
      ports:
        - containerPort: 8000
      livenessProbe:
        httpGet:
          path: /healthcheck
          port: 8000
        initialDelaySeconds: 15
        periodSeconds: 15

মূল মিল এবং পার্থক্য (প্রয়োজনীয় বিষয়গুলি, যা খুব বেশি কিছু নয়)

তাদের মধ্যে মিল হলো: তারা কন্টেইনার নিয়ে কাজ করে এবং YAML-এর মাধ্যমে ডেপ্লয়মেন্ট নির্ধারণ করে। উভয় সমাধানই ডেভেলপার এবং অপারেটরদের জন্য উপযোগী , এবং ডেভ→প্রোড ওয়ার্কফ্লোতে একে অপরের পরিপূরক হিসেবে খুব ভালোভাবে কাজ করে।

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

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

এছাড়াও, Kubernetes-এ এককালীন বা নির্ধারিত কাজের জন্য Jobs এবং CronJobs অন্তর্ভুক্ত রয়েছে। এর ফলে সিস্টেম ক্রন জব এবং অতিরিক্ত কন্টেইনারাইজড প্রসেসের প্রয়োজন হয় না , এবং প্ল্যাটফর্মটিই অটোমেশন সংজ্ঞায়িত করার জন্য স্বাভাবিক স্থান হিসেবে থেকে যায়।

অন-প্রিমিসেস ক্ষেত্রে, গতি এবং সরলতার দিক থেকে Compose এগিয়ে। শত শত নোড বা মাল্টি-ক্লাউড পরিবেশে স্কেল করার জন্য Kubernetes-ই যৌক্তিক পছন্দ । Compose মাল্টি-হোস্ট ডেপ্লয়মেন্টের জন্য Docker Swarm ব্যবহার করতে পারে, কিন্তু এর ব্যবহার বৃদ্ধি এবং সক্ষমতা Kubernetes-এর ইকোসিস্টেম ও পরিপক্কতার সাথে মেলে না।

কেন আপনার অর্কেস্ট্রেশনের প্রয়োজন (এবং যখন প্রতিটি সবচেয়ে ভালোভাবে ফিট করে)

একটি ভালো অর্কেস্ট্রেটর আপনাকে দেয়: সমন্বিত প্রোভিশনিং ও ডেপ্লয়মেন্ট, নির্ধারিত সময়ে স্টার্টআপ, সার্ভিসগুলোর মধ্যে যোগাযোগ , লোড ব্যালান্সিং, এবং প্রতিটি সার্ভিসের উপর অতিরিক্ত গভর্নেন্সের মাধ্যমে বাড়তি নিরাপত্তা।

কম্পোজ মৌলিক বিষয়গুলোকে একটি সুবিন্যস্ত ও সহজবোধ্য উপায়ে উপস্থাপন করে, যা এটিকে ডেভেলপমেন্ট, টেস্টিং এবং ডেমোর জন্য একটি চমৎকার টুল হিসেবে গড়ে তুলেছে। তবে, যখন একাধিক নোড, নেটিভ লোড ব্যালান্সিং ও অটোস্কেলিং , অথবা ডাউনটাইম ছাড়া ইনক্রিমেন্টাল ডেপ্লয়মেন্টের প্রয়োজন হয়, তখন এর সীমাবদ্ধতাগুলো স্পষ্ট হয়ে ওঠে।

অন্যদিকে, লোড বাড়লে কুবারনেটিসই হলো আসল প্ল্যাটফর্ম: মাল্টি-নোড, অটোস্কেলিং, হাই অ্যাভেইলেবিলিটি এবং একটি বিশাল ইকোসিস্টেম , সাথে AWS, Azure, GCP-তে নেটিভ সাপোর্ট এবং ম্যানেজড অপশনও রয়েছে।

বাস্তব-বিশ্বের ব্যবহারের ক্ষেত্রে (ডেভেলপার, ডেটা এবং আরও অনেক কিছু)

Compose নিম্নলিখিত ক্ষেত্রগুলিতে বিশেষভাবে কার্যকর: পুনরুৎপাদনযোগ্য স্থানীয় পরিবেশ, E2E টেস্টিং, CI/CD, এবং প্রশিক্ষণ । YAML-এ সম্পূর্ণ স্ট্যাকটি সংজ্ঞায়িত করা এবং একটিমাত্র কমান্ড দিয়ে এটি চালু করা অনেক অপ্রয়োজনীয় জটিলতা দূর করে।

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

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

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

নেটওয়ার্কিং, স্কেলিং এবং আপগ্রেড: একটি ব্যবহারিক তুলনা

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

কুবারনেটিসে, সার্ভিসেস ক্লাস্টারের মধ্যে ডিএনএস ডিসকভারি এবং লোড ব্যালান্সিংয়ের সুবিধা দেয়; বাইরের দিকে HTTP/S ট্র্যাফিক রাউট করার জন্য আপনি লোডব্যালান্সার, নোডপোর্ট বা ইনগ্রেস ব্যবহার করতে পারেন।

স্কেলিং: কম্পোজ ম্যানুয়ালি এবং শুধুমাত্র একটি হোস্টে স্কেল করা যায়। কুবারনেটিস HPA-এর মাধ্যমে হরাইজন্টালি এবং মেট্রিক্স ও/অথবা ইভেন্টের সাহায্যে প্রোগ্রাম্যাটিকভাবে স্কেল করে। ক্লাস্টার অনুমতি দিলে এটি আরও নোডেও সম্প্রসারিত হতে পারে।

আপডেট: কম্পোজে, এগুলি সাধারণত ম্যানুয়ালি পুনরায় করতে হয়। K8s অগ্রগতি নিয়ন্ত্রণের (kubectl rollout) সুবিধা সহ রোলিং আপডেট করে এবং কিছু ভুল হলে পূর্বাবস্থায় ফিরিয়ে আনার ক্ষমতা রাখে, যা প্রভাবকে ন্যূনতম করে তোলে।

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

ডেভেলপারের উৎপাদনশীলতা এবং পরিচালনাগত অভিজ্ঞতা

Compose হলো Docker-এর উপরে একটি পাতলা স্তর। এটি দ্রুত শেখা যায় এবং এর ফিডব্যাক লুপ তাৎক্ষণিক , যা বারবার পরিবর্তন ও পরিমার্জনের জন্য আদর্শ।

কুবারনেটিস নতুন ধারণা যোগ করে (পড, ডিপ্লয়মেন্ট, সার্ভিস, ইনগ্রেস, কনফিগম্যাপ, পিভিসি, ইত্যাদি)। এটি শিখতে কিছুটা সময় লাগে, কিন্তু এর বিনিময়ে আপনি ডিপ্লয়মেন্ট, নিরাপত্তা, পর্যবেক্ষণযোগ্যতা এবং স্কেলেবিলিটির উপর সূক্ষ্ম নিয়ন্ত্রণ লাভ করেন ।

সামঞ্জস্যতার দিক থেকে, Compose হলো “Docker-first”। Kubernetes বিভিন্ন রানটাইম সমর্থন করে এবং ক্লাউড প্রোভাইডারদের সাথে সমন্বিত হয় , যা মাল্টিক্লাউড বা হাইব্রিড কৌশল অবলম্বনকারী সংস্থাগুলোর জন্য অত্যন্ত গুরুত্বপূর্ণ।

পাগল না হয়ে ডকার কম্পোজ থেকে কুবারনেটসে স্থানান্তরিত হচ্ছে

কখন মাইগ্রেট করবেন? যখন আপনার অ্যাপ্লিকেশনটি আর "ছোট" থাকে না, আপনার মাল্টি-নোড, অবজার্ভেবিলিটি, স্কেলেবিলিটি এবং হাই অ্যাভেইলেবিলিটি প্রয়োজন হয় , অথবা আপনাকে ক্যানারি এবং ব্লু/গ্রিন ডিপ্লয়মেন্টের জন্য বলা হয়।

সাধারণ চ্যালেঞ্জগুলো হলো: সার্ভিস নেটওয়ার্কের ম্যাপিং করা, PV/PVC ব্যবহার করে স্টোরেজ ডিজাইন করা , কনফিগারেশনকে ConfigMaps/Secrets-এ বিভক্ত করা, এবং প্রতিটি কন্টেইনারের স্বাস্থ্য ও প্রস্তুতির ধরণ পর্যালোচনা করা।

আর্কিটেকচারটিও পুনর্বিবেচনা করা প্রয়োজন: ডেপ্লয়মেন্ট ইউনিট হিসেবে পড , এন্ডপয়েন্টগুলো উন্মুক্ত করার জন্য সার্ভিস, এবং প্রতিটি কন্টেইনারের জন্য রিসোর্স (সিপিইউ/মেমরি), যাতে শিডিউলার তার কাজ করতে পারে।

কম্পোজ: কয়েকটি ধাপে কম্পোজ থেকে K8s পর্যন্ত

Kompose, docker-compose.yml ফাইলগুলোকে Kubernetes বা OpenShift ম্যানিফেস্টে রূপান্তর করে। ম্যানুয়ালি সমস্ত YAML পুনরায় না লিখে মাইগ্রেশন শুরু করার এটিই সবচেয়ে সরাসরি উপায় ।

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

ইনস্টলেশন: প্রস্তাবিত পদ্ধতি হলো সর্বশেষ গিটহাব রিলিজ থেকে বাইনারিটি ডাউনলোড করা। এছাড়াও আপনি একটি টারবল, ম্যাকওএস-এ হোমব্রু, অথবা 'go get' ব্যবহার করতে পারেন (এই শেষ বিকল্পটি ডেভলপমেন্টাধীন পরিবর্তনসহ মাস্টার সংস্করণ ব্যবহার করে)।

মৌলিক রূপান্তর: docker-compose.yml ডিরেক্টরিতে যান এবং চালান :

kompose convert
kubectl apply -f <archivos-generados>

Kompose ডিফল্টরূপে Deployment এবং Services তৈরি করে। লগ-এ সাধারণত তৈরি হওয়া প্রতিটি ফাইলের তালিকা থাকে , এবং একবার প্রয়োগ করা হলে, আপনি ক্লাস্টারে Deployment এবং Services "তৈরি" হতে দেখবেন।

অ্যাক্সেস: আপনি যদি মিনিকিউব (Minikube) ব্যবহার করেন, তাহলে সহজেই সার্ভিসগুলো অ্যাক্সেস বা কোয়েরি করতে পারবেন। ক্লাউডে, লোডব্যালেন্সার (LoadBalancer) সার্ভিসের পাবলিক আইপি অ্যাড্রেস পেতে 'LoadBalancer Ingress' চেক করুন; NodePort-এর মাধ্যমে নোডগুলোতে একটি খোলা পোর্ট পাওয়া যাবে।

পরিচ্ছন্নতা: পরীক্ষা শেষ হলে, প্রয়োগ করা রিসোর্সগুলো সরিয়ে ফেলুন। পুনরাবৃত্তির মধ্যে সংঘাত এড়াতে আপনার ক্লাস্টার পরিষ্কার রাখুন ।

উন্নত বিকল্পগুলি রচনা করুন (প্রদানকারী, বস্তু এবং ট্যাগ)

Kompose কুবারনেটিস এবং ওপেনশিফট সমর্থন করে। আপনি যদি "--provider" নির্দিষ্ট না করেন, তবে এটি ডিফল্টরূপে কুবারনেটিস ব্যবহার করে । ওপেনশিফটের সাহায্যে এটি DeploymentConfig এবং ImageStream তৈরি করতে পারে, এবং বিল্ড ডিরেক্টিভ ব্যবহার করলে BuildConfig-ও তৈরি করতে পারে।

এটি বিভিন্ন আউটপুটও সমর্থন করে: "-j" সহ JSON, ReplicationControllers, DaemonSets, বা Helm Charts । "--replicas" ফ্ল্যাগটি আপনাকে RC-তে রেপ্লিকার সংখ্যা পরিবর্তন করতে দেয়; Helm-এর জন্য, এটি মৌলিক চার্ট কাঠামো তৈরি করে।

কম্পোজ প্রক্রিয়ার মধ্যে থাকা Kompose-নির্দিষ্ট ট্যাগগুলো রূপান্তরকে প্রভাবিত করে। উদাহরণস্বরূপ, আপনি সার্ভিসের ধরন নির্ধারণ করতে পারেন অথবা কোনো এন্ডপয়েন্টকে Ingress/Route-এর মাধ্যমে প্রকাশ করা হবে কিনা, তা ঠিক করতে পারেন।

ট্যাগ	মান
কম্পোজ.সার্ভিস.টাইপ	নোডপোর্ট/ক্লাস্টারিপ/লোডব্যালেন্সার
কম্পোজ.সার্ভিস.এক্সপোজ	সত্য / হোস্টনাম

মনে রাখার মতো বিষয়গুলো হলো: নামের শেষে “_” থাকলে তা “-” এ রূপান্তরিত হয় (K8s আন্ডারস্কোর অনুমোদন করে না) এবং, যদি কোনো সার্ভিস ভলিউম ব্যবহার করে, তাহলে একাধিক রাইটারের সাথে দ্বন্দ্ব এড়ানোর জন্য ডিপ্লয়মেন্ট স্ট্র্যাটেজি “Recreate”-এ পরিবর্তিত হয়।

কম্পোজ একাধিক সংস্করণ এবং ফাইল সমর্থন করে

Kompose, Compose V1, V2, এবং V3 সমর্থন করে (তবে 2.1 এবং 3.2 পরীক্ষামূলক হওয়ায় এগুলোর জন্য সীমিত সমর্থন রয়েছে)। আপনি যদি একসাথে একাধিক docker-compose ফাইল পাস করেন, তাহলে সেগুলোকে মার্জ করা হয় এবং সাধারণ উপাদানগুলো সর্বশেষ ফাইল দ্বারা ওভাররাইট হয়ে যায়, ঠিক যেমনটি একটি ওভাররাইডের ক্ষেত্রে হয়ে থাকে।

Kubernetes রূপান্তরের সময়, যদি কোনো বেমানান কী (key) থাকে, তাহলে আপনি "WARN Unsupported key build – ignoring" এর মতো বার্তা দেখতে পাবেন। চিন্তা করবেন না, টুলটি যা বুঝতে পারছে তা নিয়েই কাজ চালিয়ে যাবে এবং বাকিগুলো পরে ম্যানুয়ালি সমন্বয় করার জন্য রেখে দেবে।

কমপোজের বাইরে: মুভ২কিউব এবং ম্যানুয়াল মাইগ্রেশন

আপনার যদি আরও বেশি নিয়ন্ত্রণের প্রয়োজন হয়, তবে Move2Kube-এর মতো টুল রয়েছে যা আপনার Compose বিশ্লেষণ করে আরও নিখুঁত Kubernetes আর্টিফ্যাক্ট তৈরি করে। আপনার প্ল্যাটফর্ম থেকে ব্যবসায়িক প্যাটার্ন বা টেমপ্লেট গ্রহণ করার ক্ষেত্রে এগুলি কার্যকর।

প্রাথমিক মাইগ্রেশনের পর ম্যানুয়াল মাইগ্রেশন সম্পূর্ণ বৈধ এবং প্রায় সবসময়ই সুপারিশ করা হয়। এর সাধারণ ধাপগুলোর মধ্যে রয়েছে: সার্ভিসগুলোকে Deployments/StatefulSets-এ , নেটওয়ার্কগুলোকে Services/Ingress-এ এবং ভলিউমগুলোকে স্টোরেজ ক্লাসসহ PV/PVC-তে রূপান্তর করা।

একটি Compose সার্ভিসকে Deployment-এ রূপান্তর করার একটি সংক্ষিপ্ত উদাহরণ দেখতে এইরকম হতে পারে: Pod টেমপ্লেটে পোর্ট, ইমেজ এবং লেবেল স্থানান্তর করুন :

# docker-compose.yml
version: '3'
services:
  web:
    build: .
    ports:
      - '8000:8000'
    depends_on:
      - db

# Kubernetes
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: my-web-image
          ports:
            - containerPort: 8000

স্টেটের (ডাটাবেস, কিউ) জন্য StatefulSets এবং PersistentVolumes ব্যবহার করার কথা ভাবতে পারেন। Compose-এ যা কিছু একসাথে করা হয়েছিল, তার সবকিছু একই Pod-এ রাখা উচিত নয় ; দায়িত্বগুলো আলাদা রাখুন এবং কম্পোনেন্টগুলোর মধ্যে যোগাযোগের জন্য Services ব্যবহার করুন।

ডেটা পরিস্থিতি: স্ট্রিমিং, ব্যাচ এবং গভর্নেন্স

জটিল ডেটা পাইপলাইনে K8s একেবারে নিখুঁতভাবে খাপ খায়: ব্যাচ প্রসেসের জন্য জবস, নির্দিষ্ট সময়সীমার জন্য ক্রনজবস , এপিআই-এর জন্য ডিপ্লয়মেন্টস এবং কাফকা, স্পার্ক বা ফ্লিংকের মতো সিস্টেমের জন্য অপারেটরস।

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

ডেটা গভর্নেন্স এবং সুরক্ষার ক্ষেত্রে, কুবারনেটিস এনভায়রনমেন্ট অডিট ও পৃথক করার জন্য নেমস্পেস, পলিসি এবং আরবিএসি (RBAC) কন্ট্রোল প্রদান করে । কম্পোজের লোকাল পদ্ধতির তুলনায় এটি একটি বাস্তব সুবিধা।

সেরা অনুশীলন এবং ছোট ছোট পরিচালনার কৌশল

Compose-এ: আপনার YAML ছোট এবং মডিউলার রাখুন ; এনভায়রনমেন্ট ভেরিয়েবল এবং .env ফাইল ব্যবহার করুন; পোর্ট এবং ডিপেন্ডেন্সিগুলোর ডকুমেন্টেশন তৈরি করুন; এবং স্থানীয়ভাবে যা চালান, CI-তে তার প্রতিফলন ঘটান।

কুবারনেটিসে: সিপিইউ এবং মেমরি রিকোয়েস্ট/লিমিট নির্ধারণ করুন , রেডিনেস/লাইভনেস প্রোব ব্যবহার করুন, কনফিগারেশনকে কনফিগম্যাপ/সিক্রেট-এ বিভক্ত করুন এবং প্রতিটি সার্ভিসে উপযুক্ত ডেপ্লয়মেন্ট স্ট্র্যাটেজি প্রয়োগ করুন।

Kubeck-এর আপডেটের জন্য: অগ্রগতি নিরীক্ষণ করতে এবং কোনো সমস্যা হলে পূর্বাবস্থায় ফিরে যেতে `kubectl set image` এবং `kubectl rollout status` ব্যবহার করুন । এটি প্রোডাকশনে ডাউনটাইম প্রতিরোধ করবে।

Compose-এ আপনার যদি নির্দিষ্ট কাজের প্রয়োজন হয়, তবে আপনি সেগুলো সিমুলেট করতে পারেন, কিন্তু Kubernetes-এ CronJobs/Jobs ব্যবহার করা আরও পরিচ্ছন্ন ; এতে অতিরিক্ত প্রসেস বা হোস্ট ক্রন দিয়ে কন্টেইনারগুলো ভারাক্রান্ত হয় না।

বিভ্রান্তি এড়াতে দ্রুত প্রায়শই জিজ্ঞাসিত প্রশ্নাবলী

কম্পোজ কি কুবারনেটিসের বিকল্প? না। কম্পোজ একটিমাত্র হোস্টে একাধিক কন্টেইনার স্ট্যাককে সহজ করে; কুবারনেটিস উচ্চ প্রাপ্যতা সহ ক্লাস্টার স্কেলে অর্কেস্ট্রেশন করে ।

কম্পোজ কি এখনও ব্যবহৃত হয়? হ্যাঁ, প্রচুর পরিমাণে। মাত্র কয়েকটি কমান্ডের সাহায্যে সম্পূর্ণ এনভায়রনমেন্ট সেট আপ করার জন্য এটি একটি আদর্শ ডেভেলপমেন্ট এবং টেস্টিং টুল ।

কুবারনেটিস কি ডকারের চেয়ে 'ভালো'? এ দুটি ভিন্ন জিনিস: ডকার হলো কন্টেইনার প্ল্যাটফর্ম ; আর কুবারনেটিস একটি ক্লাস্টারে সেগুলোকে সমন্বয় করে এবং উন্নত অপারেশন যুক্ত করে।

আমি কি আমার Compose কোডটি ম্যানুয়ালি পুনরায় না লিখে Kubernetes-এ আনতে পারি? হ্যাঁ, Kompose বা Docker Desktop ইন্টিগ্রেশনের মাধ্যমে। এটি আপনাকে একটি দ্রুত প্রাথমিক পদক্ষেপ দেয়, যা আপনি পরবর্তীতে আরও উন্নত করতে পারেন।

সূক্ষ্ম বিবরণ: প্রোগ্রামিং, ওপেনশিফ্ট এবং বিকল্প রূপান্তর

K8s মানে শুধু নিরবচ্ছিন্ন ডেপ্লয়মেন্টই নয়: এর জবস (Jobs) এবং ক্রনজবস (CronJobs) এককালীন বা পরিকল্পিত কাজগুলোও সম্পন্ন করে, যার জন্য আপনাকে সিস্টেম ক্রন (system cron) পরিচালনা করতে হয় না।

OpenShift-এ, Kompose DeploymentConfigs এবং ImageStreams তৈরি করতে পারে, এমনকি BuildConfigs-ও তৈরি করতে পারে যদি Compose-এর কোনো বিল্ড একটি Git রিপোজিটরির সাথে যুক্ত থাকে। সোর্স পরিবর্তন করার জন্য “--build-repo” এবং “--build-branch” ফ্ল্যাগগুলো ব্যবহার করা হয়।

আপনি যদি ভিন্ন আউটপুট চান, তাহলে Kompose ডিফল্ট Deployments এবং Services-এর পরিবর্তে DaemonSets, ReplicationControllers, বা Helm Charts ব্যবহারের সুযোগ দেয়। এটি শুধু YAML-ই নয়, JSON-ও তৈরি করতে পারে।

সামঞ্জস্যতা, সতর্কতা এবং ছোটখাটো সমস্যা

Kompose V1/V2/V3 সমর্থন করে (২.১ এবং ৩.২ সংস্করণে কিছু সীমাবদ্ধতা রয়েছে)। অসমর্থিত কী-গুলো একটি WARN বার্তা দিয়ে উপেক্ষা করা হয় , ফলে ম্যানুয়াল সমন্বয়ের সুযোগ থাকে।

আপনার সার্ভিসে ভলিউম থাকলে, একই ভলিউমে কনকারেন্সি এড়ানোর জন্য Kompose স্ট্র্যাটেজি পরিবর্তন করে "Recreate" করে দেয় । স্টেটফুল সার্ভিসগুলোর জন্য এটি একটি স্বাভাবিক বিষয়।

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

বাইরে থেকে অ্যাক্সেস করার জন্য, সার্ভিসের ধরণটি পরীক্ষা করুন: ক্লাস্টারআইপি (অভ্যন্তরীণ), নোডপোর্ট (নোডের পোর্ট), অথবা লোডব্যালেন্সার (ক্লাউডের পাবলিক আইপি)। ইনগ্রেসের মাধ্যমে আপনি ত্রুটিমুক্ত HTTP/S রাউট এবং কেন্দ্রীভূত TLS পাবেন।

আপনি যদি মিনিকিউবে পরীক্ষা করেন, তাহলে “minikube service <svc> –url”-এর মতো কমান্ড একটি দ্রুত URL ফেরত দেবে । ক্লাউডে, সার্ভিসটি বর্ণনা করার সময় “LoadBalancer Ingress” ফিল্ডটি দেখুন।

একটি আকর্ষণীয় বিষয় হলো: এই কমিউনিটির মধ্যে আপনি কুবারনেটিস প্রোফাইলের বেতন এবং প্রোডাকশন এনভায়রনমেন্টে এর ব্যবহারের হার প্রায় ৮৮%-এর কাছাকাছি থাকার উল্লেখ পাবেন । এতে অস্বাভাবিক কিছু নেই: এটিই এখানকার অলিখিত নিয়ম।

পুরো বিষয়টি পরিষ্কার করতে গেলে বলতে হয়, Kubernetes মানে শুধু HTTP নয়, এর বাইরেও আরও অনেক কিছু আছে: Service Mesh, অপারেটর এবং CRD-এর মতো বিষয়গুলো Kubernetes-এর পরিধিকে আরও প্রসারিত করে। আপনি যদি Compose ব্যবহার করে থাকেন, তবে প্রথমে কিছুটা দিশেহারা বোধ করাটা স্বাভাবিক, কিন্তু এই অতিরিক্ত ক্ষমতা আরও শক্তিশালী অপারেশনে রূপান্তরিত হয়।

নীতিগুলি পুনরায় সেট করুন: দরকারী সমতুল্যতা

Compose-এ “restart: always/on-failure/no” বিকল্পটি রয়েছে। Kubernetes-এ, ক্ষেত্রবিশেষে, উপযুক্ত রিস্টার্ট পলিসি সহ স্বতন্ত্র Pod বা কন্ট্রোলার (Deployment বা RC) থাকবে।

ডকার-রচনা পুনঃসূচনা	K8s-এ বস্তু	পুনঃসূচনা নীতি
«» / সর্বদা	নিয়ন্ত্রক (স্থাপনা/আরসি)	সর্বদা
ব্যর্থতার উপর	শুঁটি	অনফেল্যুর
না।	শুঁটি	না

Compose-এ যদি আপনার "ক্যালকুলেশন" কন্টেইনার বা ক্ষণস্থায়ী টাস্ক (যেমন একটি দ্রুত "pi") থেকে থাকে, তবে সেটিকে K8s-এ উপযুক্ত পলিসি সহ একটি Job বা CronJob হিসেবে প্রয়োগ করলেই আপনার কাজ হয়ে যাবে।

দ্রুত লোকাল ডেপ্লয়মেন্টের জন্য Compose বেছে নিন এবং যখন আপনার এনভায়রনমেন্টের আরও বেশি শক্তির প্রয়োজন হয় তখন Kubernetes ব্যবহার করুন: মাল্টি-নোড সাপোর্ট, অটোস্কেলিং, নির্বিঘ্ন ডেপ্লয়মেন্ট এবং সত্যিকারের স্থিতিস্থাপকতা । Compose, Move2Kube এবং সামান্য যত্নের সাথে এই রূপান্তরটি মসৃণ হয়।

শেষ পর্যন্ত, পছন্দটি নির্ভর করে পরিধি এবং জটিলতার উপর: ডেভেলপমেন্ট, টেস্টিং এবং সিঙ্গেল-হোস্ট স্ট্যাকের জন্য Compose খুবই উপযুক্ত ; অন্যদিকে এন্টারপ্রাইজ, মাল্টি-ক্লাউড ডেপ্লয়মেন্ট এবং যেসব টিমের উন্নত অটোমেশন, হাই অ্যাভেইলেবিলিটি ও হাজার হাজার ইন্টিগ্রেশন সমৃদ্ধ একটি ইকোসিস্টেম প্রয়োজন, তাদের জন্য Kubernetes-ই সেরা উপায়।