গেটওয়ে API v1.1: সার্ভিস মেশ, GRPCRoute, এবং আরো অনেক কিছু

গেটওয়ে API লোগো

গত অক্টোবরে গেটওয়ে API-এর GA রিলিজের পর, কুবারনেটিস SIG নেটওয়ার্ক গেটওয়ে API-এর v1.1 রিলিজ ঘোষণা করতে পেরে আনন্দিত। এই রিলিজে, বেশ কিছু ফিচার Standard Channel (GA)-তে গ্র্যাজুয়েট হচ্ছে, বিশেষত সার্ভিস মেশ এবং GRPCRoute-এর জন্য সাপোর্ট সহ। আমরা কিছু নতুন এক্সপেরিমেন্টাল ফিচারও প্রবর্তন করছি, যার মধ্যে সেশনের স্থিরতা এবং ক্লায়েন্ট সার্টিফিকেট ভেরিফিকেশন।

নতুন কি

স্ট্যান্ডার্ড থেকে গ্র্যাজুয়েট

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

সার্ভিস মেশ সাপোর্ট

সার্ভিস মেশ সাপোর্ট গেটওয়ে APIতে সার্ভিস মেশ ব্যবহারকারীদের ইনগ্রেস ট্র্যাফিক এবং মেশ ট্র্যাফিক পরিচালনা করতে, একই পলিসি এবং রাউটিং ইন্টারফেসগুলি পুনরায় ব্যবহার করতে একই API ব্যবহার করতে দেয়। গেটওয়ে API v1.1-এ, রুটগুলিতে (যেমন HTTPRoute) এখন 'parentRef' হিসাবে একটি সার্ভিস থাকতে পারে, নির্দিষ্ট সার্ভিসগুলিতে ট্র্যাফিক কীভাবে আচরণ করে তা নিয়ন্ত্রণ করতে। আরও তথ্যের জন্য, [গেটওয়ে API সার্ভিস মেশ ডকুমেন্টেশন] (https://gateway-api.sigs.k8s.io/mesh/) পড়ুন বা [গেটওয়ে API বাস্তবায়নের তালিকা] (https://gateway-api.sigs.k8s.io/implementations/#service-mesh-implementation-status) দেখুন।

উদাহরণস্বরূপ, কেউ একটি HTTPRoute দিয়ে একটি অ্যাপ্লিকেশনের কল গ্রাফের গভীরে একটি ওয়ার্কলোডের একটি canary স্থাপনার কাজ করতে পারে:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: color-canary
  namespace: faces
spec:
  parentRefs:
    - name: color
      kind: Service
      group: ""
      port: 80
  rules:
  - backendRefs:
    - name: color
      port: 80
      weight: 50
    - name: color2
      port: 80
      weight: 50

এটি মূল color সার্ভিস এবং color2 সার্ভিসটির মধ্যে faces নেমস্পেস এর color সার্ভিসটিতে প্রেরিত ট্র্যাফিককে 50/50 বিভক্ত করবে, একটি পোর্টেবল কনফিগারেশন ব্যবহার করে যা এক মেশ থেকে অন্য মেশে সরানো সহজ।

GRPCRoute

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

ParentReference Port

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

উদাহরণস্বরূপ, আপনি লিসেনারের name ফিল্ডের পরিবর্তে লিসেনার port দ্বারা নির্দিষ্ট হিসাবে গেটওয়ের এক বা একাধিক নির্দিষ্ট লিসেনারের সাথে একটি HTTPRoute সংযুক্ত করতে পারেন।

আরও তথ্যের জন্য, দেখুন গেটওয়েতে সংযুক্ত করা হচ্ছে.

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

কনফর্মেন্স রিপোর্ট API mode ফিল্ড (ইমপ্লিমেন্টেশনের কাজের মোড নির্দিষ্ট করার উদ্দেশ্যে) এবং gatewayAPIChannel (স্ট্যান্ডার্ড বা এক্সপেরিমেন্টাল) দিয়ে প্রসারিত করা হয়েছে। gatewayAPIVersion এবং gatewayAPIChannel এখন টেস্টিং ফলাফলের সংক্ষিপ্ত বিবরণ সহ স্যুট মেশিনারি দ্বারা স্বয়ংক্রিয়ভাবে পূরণ করা হয়। প্রতিবেদনগুলি আরও স্ট্রাকচারড উপায়ে পুনর্গঠিত হয়েছে এবং ইমপ্লিমেন্টেশনগুলিতে এখন টেস্টগুলি কীভাবে চালানো হবে সে সম্পর্কে তথ্য যুক্ত করতে পারে এবং রিপ্রোডাকশন পদক্ষেপগুলি সরবরাহ করতে পারে।

এক্সপেরিমেন্টাল চ্যানেলে নতুন সংযোজন

গেটওয়ে ক্লায়েন্ট সার্টিফিকেট ভেরিফিকেশন

গেটওয়েগুলি এখন tls এর মধ্যে একটি নতুন frontendValidation ফিল্ড প্রবর্তন করে প্রতিটি গেটওয়ে লিস্টেনারের জন্য ক্লায়েন্ট সার্টিফিকেট ভেরিফিকেশন কনফিগার করতে পারে। এই ফিল্ডটি CA সার্টিফিকেটগুলির একটি তালিকা কনফিগার করা সমর্থন করে যা ক্লায়েন্ট দ্বারা উপস্থাপিত সার্টিফিকেটগুলি যাচাই করার জন্য ট্রাস্ট অ্যাঙ্কর হিসাবে ব্যবহার করা যেতে পারে।

নিম্নলিখিত উদাহরণটি দেখায় যে কীভাবে foo-example-com-ca-cert ConfigMap-এ সঞ্চিত CACertificate-টি foo-https গেটওয়ে লিস্টেনারের সাথে সংযুক্ত ক্লায়েন্টদের দ্বারা উপস্থাপিত সার্টিফিকেটগুলি যাচাই করতে ব্যবহার করা যেতে পারে।

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: client-validation-basic
spec:
  gatewayClassName: acme-lb
  listeners:
    name: foo-https
    protocol: HTTPS
    port: 443
    hostname: foo.example.com
  tls:
    certificateRefs:
      kind: Secret
      group: ""
      name: foo-example-com-cert
    frontendValidation:
      caCertificateRefs:
        kind: ConfigMap
        group: ""
        name: foo-example-com-ca-cert

সেশন পার্সিস্টেন্স এবং BackendLBPolicy (Session Persistence and BackendLBPolicy)

সার্ভিস-লেভেলের কনফিগারেশনের জন্য একটি নতুন পলিসি (BackendLBPolicy) এবং রুট-লেভেলের কনফিগারেশনের জন্য HTTPRoute এবং GRPCRoute এর মধ্যে ফিল্ড হিসাবে গেটওয়ে API-তে সেশন পার্সিস্টেন্স ইন্ট্রোডিউসড করা হচ্ছে। BackendLBPolicy এবং রুট-লেভেলের API-গুলি সেশন টাইমআউট, সেশনের নাম, সেশনের ধরণ এবং কুকি লাইফটাইম টাইপ সহ একই সেশন পার্সিস্টেন্স কনফিগারেশন সরবরাহ করে।

নীচে BackendLBPolicy এর একটি উদাহরণ কনফিগারেশন রয়েছে যা foo সার্ভিসের জন্য কুকি-বেসড সেশন পার্সিস্টেন্স এনাবল করে। এটি সেশনের নামটি foo-session এ সেট করে, অ্যাবসুলুট এবং আইডিএল টাইমআউটসগুলি ডিফাইন করে এবং কুকিটিকে সেশন কুকি হিসাবে কনফিগার করে:

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: BackendLBPolicy
metadata:
  name: lb-policy
  namespace: foo-ns
spec:
  targetRefs:
  - group: core
    kind: service
    name: foo
  sessionPersistence:
    sessionName: foo-session
    absoluteTimeout: 1h
    idleTimeout: 30m
    type: Cookie
    cookieConfig:
      lifetimeType: Session

বাকি সব

TLS টার্মিনোলজি ক্ল্যারিফিকেশন

API জুড়ে আমাদের TLS টার্মিনোলজিকে আরও সামঞ্জস্যপূর্ণ করার বিস্তৃত লক্ষ্যের অংশ হিসাবে, আমরা BackendTLSPolicy-তে কিছু ব্রেকিং পরিবর্তন ইন্ট্রোডিউসড করেছি। এর ফলে একটি নতুন API ভার্সন (v1alpha3) তৈরি হয়েছে এবং ভার্সন আপগ্রেড সঠিকভাবে পরিচালনা করার জন্য এই নীতির যে কোনও এক্সিস্টিং ইমপ্লিমেন্টেশনের প্রয়োজন হবে, যেমন ডেটা ব্যাক আপ করে এবং এই নতুন ভার্সনটি ইনস্টল করার আগে v1alpha2 ভার্সনটি আনইনস্টল করতে হবে।

v1alpha2 BackendTLSPolicy ফিল্ড-ত্রর যে কোনও রেফারেন্স v1alpha3 এ আপডেট করতে হবে। ফিল্ডগুলিতে নির্দিষ্ট পরিবর্তনগুলির মধ্যে রয়েছে:

  • targetRef BackendTLSPolicy-কে একাধিক লক্ষ্যবস্তুর সাথে সংযুক্ত করার অনুমতি দেওয়ার জন্য targetRefs হয়ে যায়
  • tls হয়ে যায় validation
  • tls.caCertRefs হয়ে যায় validation.caCertificateRefs
  • tls.wellKnownCACerts হয়ে যায় validation.wellKnownCACertificates

এই রিলিজে অন্তর্ভুক্ত পরিবর্তনগুলির সম্পূর্ণ তালিকার জন্য, দয়া করে v1.1.0 রিলিজ নোটগুলি দেখুন।

গেটওয়ে API ব্যাকগ্রাউন্ড

গেটওয়ে API-এর ধারণাটি প্রাথমিকভাবে 2019 KubeCon San Diego-তে Ingress API-এর পরবর্তী প্রজন্ম হিসাবে প্রপোজড করা হয়েছিল। তার পর থেকে, কুবারনেটিস ইতিহাসের সবচেয়ে সহযোগী API হয়ে ওঠার জন্য একটি অবিশ্বাস্য কমিউনিটি গঠিত হয়েছে। এখন পর্যন্ত 200 জনেরও বেশি লোক এই API-তে অবদান রেখেছে এবং এই সংখ্যাটি বাড়ছে।

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

চেষ্টা করে দেখুন

অন্যান্য কুবারনেটিস API-গুলির বিপরীতে, গেটওয়ে API-এর সর্বশেষ ভার্সন পেতে আপনাকে কুবারনেটিসের সর্বশেষ ভার্সনে আপগ্রেড করতে হবে না। যতক্ষণ না আপনি কুবারনেটিস 1.26 বা তার পরের টা চালাচ্ছেন, আপনি গেটওয়ে API-এর এই ভার্সনটি দিয়ে উঠতে এবং চালাতে সক্ষম হবেন।

API ব্যবহার করতে, আমাদের শুরু করার গাইড অনুসরণ করুন।

যুক্ত হোন

ইনগ্রেস এবং সার্ভিস মেশ উভয়ের জন্য কুবারনেটিস রাউটিং API-গুলির ভবিষ্যতকে সংজ্ঞায়িত করতে এবং সহায়তা করার প্রচুর সুযোগ রয়েছে।

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

কুবারনেটিস 1.29: পারসিস্টেন্টভলিউম গ্র্যাজুয়েটদের জন্য একক পড অ্যাক্সেস মোড

Kubernetes v1.29 প্রকাশের সাথে, ReadWriteOncePod ভলিউম অ্যাক্সেস মোড সবার জন্য গ্র্যাজুয়েট হয়েছে: এটি কুবারনেটিস এর স্থিতিশীল API এর অংশ। এই ব্লগ পোস্টে, আমি এই অ্যাক্সেস মোড এবং এটি কী করে তা আরও ঘনিষ্ঠভাবে দেখব।

ReadWriteOncePod কি?

ReadWriteOncePod হলো পারসিস্টেন্টভলিউম(PersistentVolumes (PVs)) এবং পারসিস্টেন্টভলিউমক্লেমস(PersistentVolumeClaims (PVCs)) এর জন্য একটি অ্যাক্সেস মোড যা কুবারনেটিস v1.22-এ চালু করা হয়েছে। এই অ্যাক্সেস মোড আপনাকে ক্লাস্টারে একটি একক পডে ভলিউম অ্যাক্সেস সীমাবদ্ধ করতে সক্ষম করে, এটি নিশ্চিত করে যে একটি সময়ে শুধুমাত্র একটি পড ভলিউমে লিখতে পারে। এটি স্টেটফুল ওয়ার্কলোডগুলির জন্য বিশেষভাবে উপযোগী হতে পারে যার জন্য স্টোরেজে একক-লেখকের অ্যাক্সেস প্রয়োজন।

অ্যাক্সেস মোড এবং ReadWriteOncePod কীভাবে কাজ করে সে সম্পর্কে আরও প্রসঙ্গের জন্য পড়ুন অ্যাক্সেস মোডগুলি কী এবং কেন সেগুলি গুরুত্বপূর্ণ? 2021 থেকে পারসিস্টেন্টভলিউম নিবন্ধের জন্য একক পড অ্যাক্সেস মোড প্রবর্তন করা হয়েছে ।

কিভাবে আমি ReadWriteOncePod ব্যবহার শুরু করতে পারি?

ReadWriteOncePod ভলিউম অ্যাক্সেস মোড ডিফল্টরূপে কুবারনেটিস ভার্সন v1.27 এবং তার পরে উপলব্ধ। কুবারনেটিস v1.29 এবং পরবর্তীতে, কুবারনেটিস API সর্বদা এই অ্যাক্সেস মোডকে স্বীকৃতি দেয়।

মনে রাখবেন যে ReadWriteOncePod শুধুমাত্র CSI ভলিউমগুলির জন্য সাপোর্টেড, এবং এই বৈশিষ্ট্যটি ব্যবহার করার আগে, আপনাকে নিম্নলিখিত CSI সাইডকারগুলিকে এই ভার্সনগুলিতে বা তার বেশি আপডেট করতে হবে:

ReadWriteOncePod ব্যবহার শুরু করতে, আপনাকে ReadWriteOncePod অ্যাক্সেস মোড সহ একটি PVC তৈরি করতে হবে:

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: single-writer-only
spec:
  accessModes:
  - ReadWriteOncePod # Allows only a single pod to access single-writer-only.
  resources:
    requests:
      storage: 1Gi

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

ReadWriteOncePod ব্যবহার করার জন্য বিদ্যমান ভলিউম স্থানান্তরিত করার বিশদ বিবরণের জন্য বিদ্যমান পারসিস্টেন্টভলিউম স্থানান্তর করা পড়ুন ।

আমি কীভাবে আরও শিখতে পারি?

ReadWriteOncePod অ্যাক্সেস মোড এবং CSI স্পেক পরিবর্তনের প্রেরণা সম্পর্কে আরও বিশদ বিবরণের জন্য অনুগ্রহ করে ব্লগ পোস্টগুলি alpha, beta, এবং KEP-2485 দেখুন৷

আমি কিভাবে জড়িত হতে পারি?

কুবারনেটিস #csi স্ল্যাক চ্যানেল এবং যে কোনো স্ট্যান্ডার্ড SIG স্টোরেজ কমিউনিকেশন চ্যানেল হলো SIG স্টোরেজ এবং CSI টিমের কাছে পৌঁছানোর দুর্দান্ত পদ্ধতি।

নিম্নলিখিত ব্যক্তিদের বিশেষ ধন্যবাদ যাদের চিন্তাশীল পর্যালোচনা এবং প্রতিক্রিয়া এই বৈশিষ্ট্যটি গঠনে সহায়তা করেছে:

  • Abdullah Gharaibeh (ahg-g)
  • Aldo Culquicondor (alculquicondor)
  • Antonio Ojea (aojea)
  • David Eads (deads2k)
  • Jan Šafránek (jsafrane)
  • Joe Betz (jpbetz)
  • Kante Yin (kerthcet)
  • Michelle Au (msau42)
  • Tim Bannister (sftim)
  • Xing Yang (xing-yang)

আপনি যদি CSI বা কুবারনেটিস স্টোরেজ সিস্টেমের যেকোন অংশের ডিজাইন এবং বিকাশের সাথে জড়িত হতে আগ্রহী হন, তাহলে কুবারনেটিস স্টোরেজ স্পেশাল ইন্টারেস্ট গ্রুপে (Special Interest Group(SIG)) যোগ দিন। আমরা দ্রুত বৃদ্ধি করছি এবং সবসময় নতুন অবদানকারীদের স্বাগত জানাই।