কুবারনেটের 10টি সাধারণ ভুল

বিঃদ্রঃ. অনুবাদ: এই নিবন্ধের লেখক একটি ছোট চেক কোম্পানি, pipetail থেকে প্রকৌশলী. তারা কুবারনেটস ক্লাস্টারগুলির অপারেশন সম্পর্কিত খুব চাপা সমস্যা এবং ভুল ধারণাগুলির [কখনও কখনও সাধারণ, তবে এখনও] একটি দুর্দান্ত তালিকা তৈরি করতে সক্ষম হয়েছিল।

কুবারনেটস ব্যবহার করার কয়েক বছর ধরে, আমরা প্রচুর সংখ্যক ক্লাস্টারের সাথে কাজ করেছি (পরিচালিত এবং অব্যবস্থাপিত - GCP, AWS এবং Azure-এ)। সময়ের সাথে সাথে, আমরা লক্ষ্য করতে শুরু করেছি যে কিছু ভুল ক্রমাগত পুনরাবৃত্তি হয়। যাইহোক, এতে লজ্জার কিছু নেই: আমরা তাদের বেশিরভাগ নিজেরাই করেছি!

নিবন্ধটিতে সর্বাধিক সাধারণ ত্রুটি রয়েছে এবং সেগুলি কীভাবে সংশোধন করা যায় তাও উল্লেখ করে৷

1. সম্পদ: অনুরোধ এবং সীমা

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

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

সেরা প্রচেষ্টা (অত্যন্ত না প্রস্তাবিত):

resources: {}

অত্যন্ত কম CPU অনুরোধ (অত্যন্ত না প্রস্তাবিত):

   resources:
      Requests:
        cpu: "1m"

অন্যদিকে, নোড প্রসেসর সম্পূর্ণরূপে লোড না হওয়া সত্ত্বেও, একটি CPU সীমার উপস্থিতি পড দ্বারা ঘড়ি চক্রের অযৌক্তিক এড়িয়ে যেতে পারে। আবার, এটি বর্ধিত বিলম্ব হতে পারে। প্যারামিটার ঘিরে বিতর্ক চলতেই থাকে CPU CFS কোটা লিনাক্স কার্নেল এবং সিপিইউ থ্রটলিং সেট সীমার উপর নির্ভর করে, সেইসাথে সিএফএস কোটা নিষ্ক্রিয়... এই সম্পর্কে আরও তথ্য নীচের লিঙ্কে পাওয়া যাবে.

অত্যধিক নির্বাচন (অত্যধিক প্রতিশ্রুতিবদ্ধ) মেমরি সমস্যা বড় সমস্যা হতে পারে. সিপিইউ সীমায় পৌঁছানোর জন্য ঘড়ির চক্র এড়িয়ে যেতে হয়, যখন মেমরির সীমায় পৌঁছানোর জন্য পডকে হত্যা করা হয়। আপনি কি কখনও পর্যবেক্ষণ করেছেন OOMkill? হ্যাঁ, যে আমরা সম্পর্কে কথা বলছি ঠিক কি.

আপনি কি এই ঘটনার সম্ভাবনা কমাতে চান? মেমরি অতিরিক্ত বরাদ্দ করবেন না এবং মেমরির অনুরোধটি সীমাতে সেট করে গ্যারান্টিড QoS (পরিষেবার গুণমান) ব্যবহার করবেন না (নিচের উদাহরণের মতো)। এই সম্পর্কে আরও পড়ুন হেনিং জ্যাকবস উপস্থাপনা (লিড ইঞ্জিনিয়ার জাল্যান্ডো)।

বিস্ফোরণযোগ্য (OOM নিহত হওয়ার উচ্চ সম্ভাবনা):

   resources:
      requests:
        memory: "128Mi"
        cpu: "500m"
      limits:
        memory: "256Mi"
        cpu: 2

গ্যারান্টিযুক্ত:

   resources:
      requests:
        memory: "128Mi"
        cpu: 2
      limits:
        memory: "128Mi"
        cpu: 2

সম্পদ সেট আপ করার সময় কি সম্ভাব্য সাহায্য করবে?

এর সাহায্যে মেট্রিক্স-সার্ভার আপনি পড (এবং তাদের ভিতরের পাত্রে) দ্বারা বর্তমান CPU সম্পদ খরচ এবং মেমরি ব্যবহার দেখতে পারেন। সম্ভবত, আপনি ইতিমধ্যে এটি ব্যবহার করছেন। শুধু নিম্নলিখিত কমান্ড চালান:

kubectl top pods
kubectl top pods --containers
kubectl top nodes

যাইহোক, তারা শুধুমাত্র বর্তমান ব্যবহার দেখায়। এটি আপনাকে বিশালতার ক্রম সম্পর্কে একটি মোটামুটি ধারণা দিতে পারে, তবে শেষ পর্যন্ত আপনার প্রয়োজন হবে সময়ের সাথে মেট্রিক্সে পরিবর্তনের ইতিহাস (প্রশ্নের উত্তর দিতে যেমন: "পিক CPU লোড কি ছিল?", "গতকাল সকালে লোড কি ছিল?", ইত্যাদি)। এই জন্য আপনি ব্যবহার করতে পারেন প্রমিথিউস, DataDog এবং অন্যান্য সরঞ্জাম। তারা কেবল মেট্রিক্স-সার্ভার থেকে মেট্রিক্স পায় এবং সেগুলি সঞ্চয় করে, এবং ব্যবহারকারী তাদের জিজ্ঞাসা করতে পারে এবং সেই অনুযায়ী সেগুলি প্লট করতে পারে।

উল্লম্ব পড অটোস্ক্যালার এটা করতে পারবেন স্বয়ংক্রিয় এই প্রক্রিয়া. এটি CPU এবং মেমরি ব্যবহারের ইতিহাস ট্র্যাক করে এবং এই তথ্যের উপর ভিত্তি করে নতুন অনুরোধ এবং সীমা সেট আপ করে।

কম্পিউটিং শক্তি দক্ষতার সাথে ব্যবহার করা সহজ কাজ নয়। এটা সব সময় Tetris খেলার মত. আপনি যদি কম গড় খরচের সাথে কম্পিউট পাওয়ারের জন্য খুব বেশি অর্থ প্রদান করেন (বলুন ~10%), আমরা AWS Fargate বা ভার্চুয়াল কুবেলেটের উপর ভিত্তি করে পণ্যগুলি দেখার পরামর্শ দিই। এগুলি একটি সার্ভারহীন/প্রতি-ব্যবহার-প্রতি-ব্যবহার বিলিং মডেলের উপর নির্মিত, যা এই ধরনের পরিস্থিতিতে সস্তা হতে পারে।

2. সজীবতা এবং প্রস্তুতি প্রোব

ডিফল্টরূপে, লাইভনেস এবং রেডিনেস চেক Kubernetes এ সক্ষম করা হয় না। এবং কখনও কখনও তারা সেগুলি চালু করতে ভুলে যায় ...

কিন্তু মারাত্মক ত্রুটির ক্ষেত্রে আপনি কীভাবে পরিষেবা পুনরায় চালু করতে পারেন? এবং কিভাবে লোড ব্যালেন্সার জানে যে একটি পড ট্রাফিক গ্রহণ করতে প্রস্তুত? বা এটি আরো ট্রাফিক পরিচালনা করতে পারে?

এই পরীক্ষাগুলি প্রায়ই একে অপরের সাথে বিভ্রান্ত হয়:

• প্রাণবন্ততা - "বেঁচে থাকার" চেক, যা ব্যর্থ হলে পড পুনরায় চালু করে;
• প্রস্তুতি — প্রস্তুতি পরীক্ষা, এটি ব্যর্থ হলে, এটি কুবারনেটস পরিষেবা থেকে পড সংযোগ বিচ্ছিন্ন করে (এটি ব্যবহার করে চেক করা যেতে পারে kubectl get endpoints) এবং পরবর্তী চেক সফলভাবে সম্পন্ন না হওয়া পর্যন্ত ট্রাফিক এতে পৌঁছায় না।

এই দুটি চেক পডের সমগ্র জীবনচক্রের সময় পারফর্ম করা হয়. এটা খুবই গুরুত্বপূর্ণ.

একটি সাধারণ ভুল ধারণা হল রেডিনেস প্রোবগুলি শুধুমাত্র স্টার্টআপে চালানো হয় যাতে ব্যালেন্সার জানতে পারে যে পডটি প্রস্তুত (Ready) এবং ট্র্যাফিক প্রক্রিয়াকরণ শুরু করতে পারে। যাইহোক, এটি তাদের ব্যবহারের জন্য শুধুমাত্র একটি বিকল্প।

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

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

সাধারণ নির্ভরতা ব্যর্থ হলে উভয় ধরণের চেক ব্যর্থ হওয়া উচিত নয়, অন্যথায় এটি সমস্ত পডের ক্যাসকেডিং (তুষারপাতের মতো) ব্যর্থতার দিকে পরিচালিত করবে। অন্য কথায়, নিজের ক্ষতি করবেন না.

3. প্রতিটি HTTP পরিষেবার জন্য লোডব্যালেন্সার

সম্ভবত, আপনার ক্লাস্টারে HTTP পরিষেবা রয়েছে যা আপনি বাইরের বিশ্বে ফরোয়ার্ড করতে চান।

আপনি যদি পরিষেবা হিসাবে খুলবেন type: LoadBalancer, এর নিয়ন্ত্রক (পরিষেবা প্রদানকারীর উপর নির্ভর করে) একটি বাহ্যিক লোডব্যালেন্সার প্রদান করবে এবং আলোচনা করবে (অগত্যা L7 এ চলবে না, বরং L4 এও চলবে), এবং এটি খরচকে প্রভাবিত করতে পারে (বাহ্যিক স্ট্যাটিক IPv4 ঠিকানা, কম্পিউটিং শক্তি, প্রতি-সেকেন্ড বিলিং ) এই ধরনের বিপুল সংখ্যক সম্পদ তৈরি করার প্রয়োজনের কারণে।

এই ক্ষেত্রে, এটি একটি বহিরাগত লোড ব্যালেন্সার ব্যবহার করা অনেক বেশি যৌক্তিক, পরিষেবাগুলি খোলার হিসাবে type: NodePort. অথবা আরও ভাল, মত কিছু প্রসারিত nginx-ইনগ্রেস-কন্ট্রোলার (বা ট্রাফিক), যিনি একমাত্র হবেন নোডপোর্ট এন্ডপয়েন্ট এক্সটার্নাল লোড ব্যালেন্সারের সাথে যুক্ত এবং ব্যবহার করে ক্লাস্টারে ট্রাফিক রুট করবে প্রবেশ-কুবারনেটস সম্পদ।

অন্যান্য ইন্ট্রা-ক্লাস্টার (মাইক্রো) পরিষেবাগুলি যা একে অপরের সাথে যোগাযোগ করে যেমন পরিষেবাগুলি ব্যবহার করে "যোগাযোগ" করতে পারে ক্লাস্টারআইপি এবং DNS এর মাধ্যমে একটি অন্তর্নির্মিত পরিষেবা আবিষ্কার প্রক্রিয়া। শুধু তাদের পাবলিক DNS/IP ব্যবহার করবেন না, কারণ এটি লেটেন্সিকে প্রভাবিত করতে পারে এবং ক্লাউড পরিষেবার খরচ বাড়িয়ে দিতে পারে।

4. একটি ক্লাস্টারের বৈশিষ্ট্য বিবেচনা না করেই অটোস্কেল করা

একটি ক্লাস্টারে নোডগুলি যোগ করার এবং সেগুলিকে সরিয়ে দেওয়ার সময়, আপনার সেই নোডগুলিতে CPU ব্যবহারের মতো কিছু মৌলিক মেট্রিক্সের উপর নির্ভর করা উচিত নয়। পড পরিকল্পনা একাউন্টে অনেক নিতে হবে বিধিনিষেধ, যেমন পড/নোড অ্যাফিনিটি, কলঙ্ক এবং সহনশীলতা, সম্পদের অনুরোধ, QoS, ইত্যাদি। একটি বাহ্যিক অটোস্কেলার ব্যবহার করা যা এই সূক্ষ্মতাগুলিকে বিবেচনায় নেয় না সমস্যা হতে পারে।

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

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

কুবারনেটস সম্প্রদায়ের মধ্যে খুব জনপ্রিয় ক্লাস্টার-অটোস্কেলার. এটি একটি ক্লাস্টারে চলে, প্রধান ক্লাউড সরবরাহকারীদের থেকে API সমর্থন করে, সমস্ত বিধিনিষেধ বিবেচনা করে এবং উপরের ক্ষেত্রে স্কেল করতে পারে। এটি সমস্ত সেট সীমা বজায় রেখে স্কেল-ইন করতে সক্ষম, যার ফলে অর্থ সাশ্রয় হয় (যা অন্যথায় অব্যবহৃত ক্ষমতার জন্য ব্যয় করা হবে)।

5. IAM/RBAC ক্ষমতাকে অবহেলা করা

IAM ব্যবহারকারীদের ক্রমাগত গোপনীয়তার সাথে ব্যবহার করার বিষয়ে সতর্ক থাকুন মেশিন এবং অ্যাপ্লিকেশন. ভূমিকা এবং পরিষেবা অ্যাকাউন্ট ব্যবহার করে অস্থায়ী অ্যাক্সেস সংগঠিত করুন (পরিষেবা অ্যাকাউন্ট).

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

kube2iam সম্পর্কে ভুলে যান এবং পরিষেবা অ্যাকাউন্টগুলির জন্য সরাসরি IAM ভূমিকাগুলিতে যান (যেমন বর্ণনা করা হয়েছে একই নামের নোট স্টেপান ভরানি):

apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/my-app-role
  name: my-serviceaccount
  namespace: default

এক টীকা। যে কঠিন না, তাই না?

এছাড়াও, পরিষেবা অ্যাকাউন্ট এবং ইনস্ট্যান্স প্রোফাইল বিশেষাধিকার মঞ্জুর করবেন না admin и cluster-adminযদি তাদের প্রয়োজন না হয়। এটি বাস্তবায়ন করা একটু বেশি কঠিন, বিশেষ করে RBAC K8s-এ, তবে অবশ্যই প্রচেষ্টার মূল্য।

6. পডের জন্য স্বয়ংক্রিয় অ্যান্টি-অ্যাফিনিটির উপর নির্ভর করবেন না

কল্পনা করুন যে আপনার কাছে একটি নোডে কিছু স্থাপনার তিনটি প্রতিলিপি রয়েছে। নোড পড়ে, এবং তার সাথে সমস্ত প্রতিলিপি। অপ্রীতিকর পরিস্থিতি, তাই না? কিন্তু কেন একই নোডে সব প্রতিলিপি ছিল? Kubernetes কি উচ্চ প্রাপ্যতা (HA) প্রদান করার কথা নয়?!

দুর্ভাগ্যবশত, Kubernetes সময়সূচী, তার নিজস্ব উদ্যোগে, পৃথক অস্তিত্বের নিয়ম মেনে চলে না (সম্পর্ক-বিরোধী) শুঁটি জন্য তাদের অবশ্যই স্পষ্টভাবে বলা উচিত:

// опущено для краткости
      labels:
        app: zk
// опущено для краткости
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchExpressions:
                  - key: "app"
                    operator: In
                    values:
                    - zk
              topologyKey: "kubernetes.io/hostname"

এখানেই শেষ. এখন পডগুলি বিভিন্ন নোডে নির্ধারিত হবে (এই শর্তটি শুধুমাত্র সময় নির্ধারণের সময় পরীক্ষা করা হয়, কিন্তু তাদের অপারেশনের সময় নয় - তাই requiredDuringSchedulingIgnoredDuringExecution).

এখানে আমরা সম্পর্কে কথা বলা হয় podAntiAffinity বিভিন্ন নোডের উপর: topologyKey: "kubernetes.io/hostname", - এবং বিভিন্ন প্রাপ্যতা অঞ্চল সম্পর্কে নয়। একটি পূর্ণাঙ্গ HA বাস্তবায়ন করতে, আপনাকে এই বিষয়ে আরও গভীরভাবে খনন করতে হবে।

7. PodDisruption Budgets উপেক্ষা করা

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

PDB আপনাকে নোডের অভাবের কারণে পরিষেবা বাধাগুলি এড়াতে অনুমতি দেয়:

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: zk-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: zookeeper

এই উদাহরণে, আপনি, ক্লাস্টারের একজন ব্যবহারকারী হিসাবে, প্রশাসকদের বলেন: "আরে, আমার একটি চিড়িয়াখানার পরিষেবা আছে, এবং আপনি যাই করুন না কেন, আমি এই পরিষেবাটির কমপক্ষে 2টি প্রতিলিপি সবসময় উপলব্ধ রাখতে চাই।"

আপনি এই সম্পর্কে আরো পড়তে পারেন এখানে.

8. একটি সাধারণ ক্লাস্টারে একাধিক ব্যবহারকারী বা পরিবেশ

কুবারনেটেস নামস্থান (নামস্থান) শক্তিশালী নিরোধক প্রদান করবেন না.

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

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

9. বহিরাগত ট্রাফিক নীতি: ক্লাস্টার

প্রায়শই আমরা দেখি যে ক্লাস্টারের ভিতরে সমস্ত ট্র্যাফিক আসে NodePort এর মতো একটি পরিষেবার মাধ্যমে, যার জন্য ডিফল্ট নীতি সেট করা থাকে externalTrafficPolicy: Cluster... এর অর্থ নোডপোর্ট ক্লাস্টারের প্রতিটি নোডে খোলা আছে, এবং আপনি পছন্দসই পরিষেবা (পডের সেট) এর সাথে ইন্টারঅ্যাক্ট করতে তাদের যেকোনও ব্যবহার করতে পারেন।

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

অন্যদিকে, যদি একটি নির্দিষ্ট Kubernetes পরিষেবার একটি নীতি সেট থাকে externalTrafficPolicy: Local, তারপর NodePort শুধুমাত্র সেই নোডগুলিতে খোলে যেখানে প্রয়োজনীয় পডগুলি আসলে চলছে৷ একটি বাহ্যিক লোড ব্যালেন্সার ব্যবহার করার সময় যা অবস্থা পরীক্ষা করে (স্বাস্থ্য পরীক্ষা) endpoints (এটা কিভাবে করে AWS ELB), তিনি শুধুমাত্র প্রয়োজনীয় নোডগুলিতে ট্র্যাফিক পাঠাবে, যা বিলম্ব, কম্পিউটিং প্রয়োজন, প্রস্থান বিলের উপর একটি উপকারী প্রভাব ফেলবে (এবং সাধারণ জ্ঞান একই নির্দেশ করে)।

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

В এই প্রকাশনা আপনি externalTrafficPolicy, এর সুবিধা এবং অসুবিধা সম্পর্কে আরও জানতে পারেন।

10. ক্লাস্টারে আবদ্ধ হবেন না এবং কন্ট্রোল প্লেনের অপব্যবহার করবেন না

পূর্বে, সার্ভারকে সঠিক নামে কল করার প্রথা ছিল: আন্তন, HAL9000 এবং Colossus... আজ তারা এলোমেলোভাবে তৈরি শনাক্তকারী দ্বারা প্রতিস্থাপিত হয়েছে। যাইহোক, অভ্যাস রয়ে গেছে, এবং এখন সঠিক নামগুলি ক্লাস্টারে যায়।

একটি সাধারণ গল্প (বাস্তব ঘটনার উপর ভিত্তি করে): এটি সমস্ত ধারণার প্রমাণ দিয়ে শুরু হয়েছিল, তাই ক্লাস্টারটির একটি গর্বিত নাম ছিল পরীক্ষামূলক… বছর কেটে গেছে এবং এটি এখনও উৎপাদনে ব্যবহৃত হয়, এবং সবাই এটি স্পর্শ করতে ভয় পায়।

ক্লাস্টারগুলি পোষা প্রাণীতে পরিণত হওয়ার বিষয়ে মজার কিছু নেই, তাই অনুশীলন করার সময় আমরা পর্যায়ক্রমে সেগুলি সরানোর পরামর্শ দিই দুর্যোগ পুনরুদ্ধার (এইটা সাহায্য করবে বিশৃঙ্খলা প্রকৌশল - প্রায়. অনুবাদ।). উপরন্তু, এটি নিয়ন্ত্রণ স্তরে কাজ করতে আঘাত করবে না (নিয়ন্ত্রণ সমতল). তাকে স্পর্শ করতে ভয় পাওয়া ভালো লক্ষণ নয়। ইত্যাদি মৃত? বন্ধুরা, আপনি সত্যিই সমস্যায় আছেন!

অন্যদিকে, আপনার এটিকে কারসাজি করে দূরে থাকা উচিত নয়। সময়ের সাথে সাথে নিয়ন্ত্রণ স্তর ধীর হতে পারে. সম্ভবত, এটি তাদের ঘূর্ণন ছাড়াই প্রচুর পরিমাণে অবজেক্ট তৈরি হওয়ার কারণে (ডিফল্ট সেটিংস সহ হেলম ব্যবহার করার সময় একটি সাধারণ পরিস্থিতি, যার কারণে কনফিগারম্যাপ/সিক্রেটসে এর অবস্থা আপডেট করা হয় না - ফলস্বরূপ, হাজার হাজার বস্তু জমা হয় নিয়ন্ত্রণ স্তর) অথবা kube-api অবজেক্টের ধ্রুবক সম্পাদনার সাথে (স্বয়ংক্রিয় স্কেলিং এর জন্য, CI/CD এর জন্য, পর্যবেক্ষণের জন্য, ইভেন্ট লগ, কন্ট্রোলার ইত্যাদি)।

উপরন্তু, আমরা পরিচালিত Kubernetes প্রদানকারীর সাথে SLA/SLO চুক্তিগুলি পরীক্ষা করার এবং গ্যারান্টিগুলিতে মনোযোগ দেওয়ার পরামর্শ দিই। বিক্রেতা গ্যারান্টি দিতে পারেন নিয়ন্ত্রণ স্তর প্রাপ্যতা (অথবা এর সাবকম্পোনেন্ট), কিন্তু আপনার পাঠানো অনুরোধের p99 বিলম্ব নয়। অন্য কথায়, আপনি প্রবেশ করতে পারেন kubectl get nodes, এবং শুধুমাত্র 10 মিনিট পরে একটি উত্তর পাবেন, এবং এটি পরিষেবা চুক্তির শর্তাবলী লঙ্ঘন হবে না।

11. বোনাস: সর্বশেষ ট্যাগ ব্যবহার করে

কিন্তু এটি ইতিমধ্যে একটি ক্লাসিক। ইদানীং আমরা এই কৌশলটি কম প্রায়ই পেয়েছি, যেহেতু অনেকেই তিক্ত অভিজ্ঞতা থেকে শিখে ট্যাগ ব্যবহার করা বন্ধ করে দিয়েছে :latest এবং সংস্করণগুলি পিন করা শুরু করে। হুররে!

ECR ইমেজ ট্যাগের অপরিবর্তনীয়তা বজায় রাখে; আমরা সুপারিশ করি যে আপনি এই অসাধারণ বৈশিষ্ট্যটির সাথে নিজেকে পরিচিত করুন।

সারাংশ

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

আপনি বিভিন্ন দলের ব্যর্থ অভিজ্ঞতার সাথে পরিচিত হতে পারেন গল্পের এই সংগ্রহ হেনিং জ্যাকবস দ্বারা।

যারা এই নিবন্ধে দেওয়া ত্রুটির তালিকায় যোগ করতে চান তারা টুইটারে আমাদের সাথে যোগাযোগ করতে পারেন (@মারেকবার্টিক, @MstrsObserver).

অনুবাদক থেকে PS

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

• «কুবারনেটস ক্লাস্টার ডিজাইন করা: কয়টি হওয়া উচিত?";
• «কুবারনেটসে নিরাপত্তার এবিসি: প্রমাণীকরণ, অনুমোদন, অডিটিং";
• «কুবারনেটসে অটোস্কেলিং এবং রিসোর্স ম্যানেজমেন্ট"(পর্যালোচনা এবং ভিডিও প্রতিবেদন);
• «Kubernetes-এ কনফিগম্যাপস: সূক্ষ্মতা সম্পর্কে জানার মতো».

উত্স: www.habr.com