Kubernetes টিপস এবং কৌশল: NGINX এবং PHP-FPM-এ আকর্ষণীয় শাটডাউনের বৈশিষ্ট্য

Kubernetes-এ CI/CD প্রয়োগ করার সময় একটি সাধারণ শর্ত: অ্যাপ্লিকেশনটি সম্পূর্ণরূপে বন্ধ করার আগে নতুন ক্লায়েন্টের অনুরোধগুলি গ্রহণ করতে সক্ষম হবে না এবং সবচেয়ে গুরুত্বপূর্ণভাবে, বিদ্যমানগুলি সফলভাবে সম্পূর্ণ করতে হবে।

এই শর্তের সাথে সম্মতি আপনাকে স্থাপনার সময় শূন্য ডাউনটাইম অর্জন করতে দেয়। যাইহোক, এমনকি খুব জনপ্রিয় বান্ডিল ব্যবহার করার সময়ও (যেমন NGINX এবং PHP-FPM), আপনি এমন সমস্যার সম্মুখীন হতে পারেন যা প্রতিটি স্থাপনার সাথে ত্রুটির বৃদ্ধি ঘটাবে...

তত্ত্ব। কিভাবে পোড বাস

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

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

একটি পড বন্ধ হয়ে গেলে কী ঘটে তা আরও ভালভাবে বোঝার জন্য, নীচের চিত্রটি দেখুন:

A1, B1 - চুলার অবস্থা সম্পর্কে পরিবর্তনগুলি গ্রহণ করা
A2 - প্রস্থান SIGTERM
B2 - শেষ পয়েন্ট থেকে একটি পড অপসারণ
B3 - পরিবর্তনগুলি গ্রহণ করা হচ্ছে (শেষ পয়েন্টগুলির তালিকা পরিবর্তিত হয়েছে)
B4 - iptables নিয়ম আপডেট করুন

অনুগ্রহ করে মনে রাখবেন: এন্ডপয়েন্ট পড মুছে ফেলা এবং SIGTERM পাঠানো ক্রমিকভাবে ঘটে না, কিন্তু সমান্তরালভাবে ঘটে। এবং Ingress অবিলম্বে এন্ডপয়েন্টের আপডেট করা তালিকা না পাওয়ার কারণে, ক্লায়েন্টদের কাছ থেকে নতুন অনুরোধগুলি পডে পাঠানো হবে, যা পড বন্ধ করার সময় 500 ত্রুটির কারণ হবে। (এই বিষয়ে আরো বিস্তারিত উপাদানের জন্য, আমরা অনূদিত). এই সমস্যাটি নিম্নলিখিত উপায়ে সমাধান করা প্রয়োজন:

• সংযোগ পাঠান: প্রতিক্রিয়া শিরোনাম বন্ধ করুন (যদি এটি একটি HTTP অ্যাপ্লিকেশন সম্পর্কিত হয়)।
• যদি কোডে পরিবর্তন করা সম্ভব না হয়, তাহলে নিম্নলিখিত নিবন্ধটি এমন একটি সমাধান বর্ণনা করে যা আপনাকে অনুগ্রহপূর্ণ সময়ের শেষ না হওয়া পর্যন্ত অনুরোধগুলি প্রক্রিয়া করার অনুমতি দেবে।

তত্ত্ব। কিভাবে NGINX এবং PHP-FPM তাদের প্রসেস বন্ধ করে

nginx

আসুন NGINX দিয়ে শুরু করা যাক, যেহেতু এটির সাথে সবকিছুই কমবেশি স্পষ্ট। তত্ত্বের মধ্যে ডুব দিয়ে, আমরা শিখি যে NGINX এর একটি মাস্টার প্রক্রিয়া এবং বেশ কয়েকটি "কর্মী" রয়েছে - এগুলি শিশু প্রক্রিয়া যা ক্লায়েন্টের অনুরোধগুলি প্রক্রিয়া করে। একটি সুবিধাজনক বিকল্প প্রদান করা হয়: কমান্ড ব্যবহার করে nginx -s <SIGNAL> দ্রুত শাটডাউন বা গ্রেসফুল শাটডাউন মোডে প্রক্রিয়াগুলি সমাপ্ত করুন। স্পষ্টতই, এটি পরবর্তী বিকল্প যা আমাদের আগ্রহের বিষয়।

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

       lifecycle:
          preStop:
            exec:
              command:
              - /usr/sbin/nginx
              - -s
              - quit

এখন, যখন পডটি বন্ধ হয়ে যায়, আমরা NGINX কন্টেইনার লগগুলিতে নিম্নলিখিতগুলি দেখতে পাব:

2018/01/25 13:58:31 [notice] 1#1: signal 3 (SIGQUIT) received, shutting down
2018/01/25 13:58:31 [notice] 11#11: gracefully shutting down

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

এবং এই পর্যায়ে আমরা NGINX এর সাথে সম্পন্ন করেছি: অন্তত লগগুলি থেকে আপনি বুঝতে পারবেন যে সবকিছু যেমন উচিত তেমন কাজ করছে।

PHP-FPM এর সাথে চুক্তি কি? এটা কিভাবে সুন্দর শাটডাউন পরিচালনা করে? আসুন এটা বের করা যাক।

পিএইচপি-FPM

PHP-FPM এর ক্ষেত্রে তথ্য একটু কম। যদি আপনি মনোযোগ দেন অফিসিয়াল ম্যানুয়াল PHP-FPM অনুসারে, এটি বলবে যে নিম্নলিখিত POSIX সংকেতগুলি গ্রহণ করা হয়েছে:

1. SIGINT, SIGTERM - দ্রুত শাটডাউন;
2. SIGQUIT - করুণ শাটডাউন (আমাদের যা প্রয়োজন)।

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

        lifecycle:
          preStop:
            exec:
              command:
              - /bin/kill
              - -SIGQUIT
              - "1"

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

অনুশীলন করা. করুণাময় শাটডাউনের সাথে সম্ভাব্য সমস্যা

nginx

প্রথমত, এটি মনে রাখা দরকারী: কমান্ডটি কার্যকর করার পাশাপাশি nginx -s quit আরও একটি পর্যায় রয়েছে যা মনোযোগ দেওয়ার মতো। আমরা একটি সমস্যার সম্মুখীন হয়েছি যেখানে NGINX এখনও SIGQUIT সংকেতের পরিবর্তে SIGTERM পাঠাবে, যার ফলে অনুরোধগুলি সঠিকভাবে সম্পূর্ণ হয়নি৷ অনুরূপ ক্ষেত্রে পাওয়া যেতে পারে, উদাহরণস্বরূপ, এখানে. দুর্ভাগ্যবশত, আমরা এই আচরণের জন্য নির্দিষ্ট কারণ নির্ধারণ করতে অক্ষম ছিলাম: NGINX সংস্করণ সম্পর্কে একটি সন্দেহ ছিল, কিন্তু এটি নিশ্চিত করা হয়নি। লক্ষণটি ছিল যে এনজিআইএনএক্স কন্টেইনার লগগুলিতে বার্তাগুলি পরিলক্ষিত হয়েছিল: "ওপেন সকেট #10 সংযোগ 5 এ বাকি আছে", যার পরে পড বন্ধ.

আমরা এই ধরনের সমস্যা পর্যবেক্ষণ করতে পারি, উদাহরণস্বরূপ, ইনগ্রেসে আমাদের প্রয়োজনীয় প্রতিক্রিয়াগুলি থেকে:

স্থাপনার সময় স্ট্যাটাস কোডের সূচক

এই ক্ষেত্রে, আমরা ইনগ্রেস থেকে মাত্র একটি 503 ত্রুটি কোড পাই: এটি NGINX কন্টেইনার অ্যাক্সেস করতে পারে না, যেহেতু এটি আর অ্যাক্সেসযোগ্য নয়৷ আপনি যদি NGINX এর সাথে কন্টেইনার লগগুলি দেখেন তবে সেগুলিতে নিম্নলিখিতগুলি রয়েছে:

[alert] 13939#0: *154 open socket #3 left in connection 16
[alert] 13939#0: *168 open socket #6 left in connection 13

স্টপ সিগন্যাল পরিবর্তন করার পরে, ধারকটি সঠিকভাবে থামতে শুরু করে: এটি এই সত্য দ্বারা নিশ্চিত করা হয়েছে যে 503 ত্রুটিটি আর পরিলক্ষিত হয় না।

আপনি যদি একই ধরনের সমস্যার সম্মুখীন হন, তাহলে কনটেইনারে কোন স্টপ সিগন্যাল ব্যবহার করা হয়েছে এবং প্রিস্টপ হুকটি দেখতে ঠিক কেমন তা বোঝা যায়। এটা খুব সম্ভব যে কারণটি এর মধ্যেই রয়েছে।

PHP-FPM... এবং আরও অনেক কিছু

পিএইচপি-এফপিএম-এর সমস্যাটি একটি তুচ্ছ উপায়ে বর্ণনা করা হয়েছে: এটি শিশু প্রক্রিয়াগুলি সম্পূর্ণ হওয়ার জন্য অপেক্ষা করে না, এটি তাদের সমাপ্ত করে, যার কারণে স্থাপনা এবং অন্যান্য ক্রিয়াকলাপের সময় 502 ত্রুটি ঘটে। 2005 সাল থেকে bugs.php.net-এ বেশ কয়েকটি বাগ রিপোর্ট রয়েছে (যেমন এখানে и এখানে), যা এই সমস্যাটি বর্ণনা করে। কিন্তু আপনি সম্ভবত লগগুলিতে কিছুই দেখতে পাবেন না: PHP-FPM কোনো ত্রুটি বা তৃতীয় পক্ষের বিজ্ঞপ্তি ছাড়াই তার প্রক্রিয়াটি সম্পূর্ণ করার ঘোষণা দেবে।

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

এটা যে সক্রিয় আউট lifecycle পাত্রের জন্য এই মত দেখাবে:

    lifecycle:
      preStop:
        exec:
          command:
          - /bin/sleep
          - "30"

তবে ৩০ সেকেন্ডের কারণে sleep আমরা হলাম প্রবলভাবে আমরা স্থাপনার সময় বৃদ্ধি করব, যেহেতু প্রতিটি পড বন্ধ করা হবে সর্বনিম্ন 30 সেকেন্ড, যা খারাপ। এই সম্পর্কে কি করা যেতে পারে?

আসুন সরাসরি আবেদনটি কার্যকর করার জন্য দায়ী দলের দিকে ফিরে যাই। আমাদের ক্ষেত্রে এটা হয় পিএইচপি-FPM, যা ডিফল্টরূপে এর চাইল্ড প্রসেস নির্বাহের নিরীক্ষণ করে না: মাস্টার প্রক্রিয়া অবিলম্বে বন্ধ করা হয়. আপনি নির্দেশ ব্যবহার করে এই আচরণ পরিবর্তন করতে পারেন process_control_timeout, যা মাস্টারের কাছ থেকে সংকেতগুলির জন্য অপেক্ষা করার জন্য শিশু প্রক্রিয়াগুলির জন্য সময়সীমা নির্দিষ্ট করে৷ আপনি যদি মানটি 20 সেকেন্ডে সেট করেন, তাহলে এটি কন্টেইনারে চলমান বেশিরভাগ প্রশ্নের কভার করবে এবং সেগুলি সম্পূর্ণ হয়ে গেলে মাস্টার প্রক্রিয়াটি বন্ধ করে দেবে।

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

অতএব, সর্বমোট ইতিমধ্যে উল্লিখিত নির্দেশ সহ process_control_timeout আপনি নিম্নলিখিত নির্মাণ ব্যবহার করতে পারেন lifecycle:

lifecycle:
  preStop:
    exec:
      command: ["/bin/bash","-c","/bin/sleep 1; kill -QUIT 1"]

এই ক্ষেত্রে, আমরা আদেশের মাধ্যমে বিলম্বের জন্য ক্ষতিপূরণ দেব sleep এবং স্থাপনার সময়কে খুব বেশি বাড়াবেন না: 30 সেকেন্ড এবং একের মধ্যে একটি লক্ষণীয় পার্থক্য আছে কি?... আসলে, এটি হল process_control_timeoutএবং lifecycle ব্যবধানের ক্ষেত্রে শুধুমাত্র একটি "নিরাপত্তা জাল" হিসাবে ব্যবহৃত হয়।

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

অনুশীলন করা. পডের অপারেশন চেক করতে লোড টেস্টিং

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

এখানে সবচেয়ে গুরুত্বপূর্ণ বিষয় হল ধাপে ধাপে পরিবর্তন চেক করুন. একটি নতুন ফিক্স যোগ করার পরে, পরীক্ষা চালান এবং শেষ রানের তুলনায় ফলাফল পরিবর্তিত হয়েছে কিনা তা দেখুন। অন্যথায়, অকার্যকর সমাধানগুলি সনাক্ত করা কঠিন হবে এবং দীর্ঘমেয়াদে এটি শুধুমাত্র ক্ষতি করতে পারে (উদাহরণস্বরূপ, স্থাপনার সময় বৃদ্ধি)।

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

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

Yandex.Tank তথ্য প্যানেল 502 ত্রুটির একটি স্পাইক দেখায়, যা স্থাপনের সময় ঘটেছিল এবং গড়ে 5 সেকেন্ড পর্যন্ত স্থায়ী হয়েছিল। সম্ভবত এটি ছিল কারণ পুরানো পডের বিদ্যমান অনুরোধগুলি বন্ধ হয়ে যাওয়ার সময় এটি বন্ধ করা হয়েছিল। এর পরে, 503টি ত্রুটি দেখা দেয়, যা একটি এনজিআইএনএক্স কন্টেইনার বন্ধ হওয়ার ফলাফল ছিল, যা ব্যাকএন্ডের কারণে সংযোগও বাদ দেয় (যা ইনগ্রেসকে এটির সাথে সংযোগ করতে বাধা দেয়)।

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

500 তম স্থাপনার সময় আর কোন ত্রুটি নেই! স্থাপনা সফল হয়েছে, করুণাময় শাটডাউন কাজ করে।

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

উপসংহার

প্রক্রিয়াটি সুন্দরভাবে শেষ করতে, আমরা অ্যাপ্লিকেশন থেকে নিম্নলিখিত আচরণ আশা করি:

1. কয়েক সেকেন্ড অপেক্ষা করুন এবং তারপরে নতুন সংযোগ গ্রহণ করা বন্ধ করুন।
2. সমস্ত অনুরোধগুলি সম্পূর্ণ করার জন্য অপেক্ষা করুন এবং সমস্ত রক্ষাকারী সংযোগগুলি বন্ধ করুন যা অনুরোধগুলি কার্যকর করছে না।
3. আপনার প্রক্রিয়া শেষ করুন।

যাইহোক, সব অ্যাপ্লিকেশন এই ভাবে কাজ করতে পারে না। কুবারনেটস বাস্তবতায় সমস্যার একটি সমাধান হল:

• একটি প্রি-স্টপ হুক যোগ করা যা কয়েক সেকেন্ড অপেক্ষা করবে;
• উপযুক্ত পরামিতিগুলির জন্য আমাদের ব্যাকএন্ডের কনফিগারেশন ফাইল অধ্যয়ন করা হচ্ছে।

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

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

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

দ্রষ্টব্য

K8s টিপস এবং ট্রিক্স সিরিজের অন্যান্য:

• «NGINX ইনগ্রেসে কাস্টম ত্রুটি পৃষ্ঠা";
• «একটি ওয়েব অ্যাপ্লিকেশনে নোড বরাদ্দ এবং লোড সম্পর্কে";
• «ডেভ সাইটগুলিতে অ্যাক্সেস";
• «বড় ডাটাবেসের জন্য বুটস্ট্র্যাপ দ্রুত করা».

উত্স: www.habr.com