Istio এবং Kubernetes উৎপাদনে। পার্ট 2. ট্রেসিং

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

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

ভুল ধারণা নম্বর এক: আমরা বিনামূল্যে অনলাইন হাইকিং ডেটা পেতে পারি।

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

প্রথমে, ইস্টিওতে স্থাপত্যের দৃষ্টিকোণ থেকে পাঠানো ট্রেসিং স্প্যানগুলি কেমন দেখায় তা দেখা যাক। যেমনটি আমরা প্রথম অংশ থেকে মনে রাখি, টেলিমেট্রি সংগ্রহের জন্য ইস্টিওর মিক্সার নামে একটি পৃথক উপাদান রয়েছে। যাইহোক, বর্তমান সংস্করণ 1.0.* এ, প্রক্সি সার্ভার থেকে সরাসরি পাঠানো হয়, যথা, দূত প্রক্সি থেকে। দূত প্রক্সি বাক্সের বাইরে জিপকিন প্রোটোকল ব্যবহার করে ট্রেসিং স্প্যান পাঠানোকে সমর্থন করে। অন্যান্য প্রোটোকল সংযোগ করা সম্ভব, কিন্তু শুধুমাত্র একটি প্লাগইনের মাধ্যমে। Istio-এর সাথে আমরা অবিলম্বে একত্রিত এবং কনফিগার করা দূত প্রক্সি পাই, যা শুধুমাত্র জিপকিন প্রোটোকল সমর্থন করে। আমরা যদি ব্যবহার করতে চাই, উদাহরণস্বরূপ, Jaeger প্রোটোকল এবং UDP-এর মাধ্যমে ট্রেসিং স্প্যান পাঠাতে, তাহলে আমাদের নিজস্ব ইস্টিও-প্রক্সি ইমেজ তৈরি করতে হবে। istio-proxy-এর জন্য কাস্টম প্লাগইনগুলির জন্য সমর্থন রয়েছে, তবে এটি এখনও আলফা সংস্করণে রয়েছে। অতএব, যদি আমরা প্রচুর পরিমাণে কাস্টম সেটিংস ছাড়া করতে চাই, তবে ট্রেসিং স্প্যানগুলি সংরক্ষণ এবং গ্রহণ করার জন্য ব্যবহৃত প্রযুক্তির পরিসর হ্রাস করা হয়। মূল সিস্টেমগুলির মধ্যে, আসলে, এখন আপনি নিজেই জিপকিন বা জাইগার ব্যবহার করতে পারেন, তবে জিপকিন সামঞ্জস্যপূর্ণ প্রোটোকল (যা অনেক কম কার্যকর) ব্যবহার করে সেখানে সবকিছু পাঠান। জিপকিন প্রোটোকলের মধ্যেই HTTP প্রোটোকলের মাধ্যমে সংগ্রাহকদের কাছে সমস্ত ট্রেসিং তথ্য পাঠানো জড়িত, যা বেশ ব্যয়বহুল।

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

apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  ports:
  - port: 80
    targetPort: 80
    name: http
  selector:
    app: nginx

আপনি http-magic এর মতো যৌগিক নামগুলিও ব্যবহার করতে পারেন (Istio HTTP দেখতে পাবে এবং সেই পোর্টটিকে HTTP শেষ পয়েন্ট হিসাবে চিনবে)। বিন্যাস হল: প্রোটো-অতিরিক্ত।

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

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

--serviceCluster ${POD_NAMESPACE}.$(echo ${POD_NAME} | sed -e 's/-[a-z0-9]*-[a-z0-9]*$//g')

দূতে ট্রেসিং কীভাবে কাজ করে তা বোঝার একটি ভাল উদাহরণ এখানে.

ট্রেসিং স্প্যান পাঠানোর জন্য এন্ডপয়েন্টটিও অবশ্যই দূত প্রক্সি লঞ্চ ফ্ল্যাগে উল্লেখ করতে হবে, উদাহরণস্বরূপ: --zipkinAddress tracing-collector.tracing:9411

ভুল ধারণা নম্বর দুই: আমরা কম খরচে সিস্টেমের মাধ্যমে অনুরোধের সম্পূর্ণ চিহ্ন পেতে পারি

দুর্ভাগ্যবশত, এটা না. বাস্তবায়নের জটিলতা নির্ভর করে কিভাবে আপনি ইতিমধ্যে পরিষেবার মিথস্ক্রিয়া বাস্তবায়ন করেছেন তার উপর। কেন এমন হল?

আসল বিষয়টি হল যে istio-proxy একই পরিষেবা ছেড়ে যাওয়া ব্যক্তিদের সাথে একটি পরিষেবাতে আগত অনুরোধের চিঠিপত্র বুঝতে সক্ষম হওয়ার জন্য, কেবল সমস্ত ট্র্যাফিককে বাধা দেওয়া যথেষ্ট নয়। আপনার কিছু ধরনের যোগাযোগ শনাক্তকারী থাকতে হবে। HTTP দূত প্রক্সি বিশেষ শিরোনাম ব্যবহার করে, যার দ্বারা দূত বুঝতে পারে কোন পরিষেবার নির্দিষ্ট অনুরোধ অন্যান্য পরিষেবার জন্য নির্দিষ্ট অনুরোধ তৈরি করে। এই ধরনের হেডারের তালিকা:

• এক্স-রিকোয়েস্ট-আইডি,
• x-b3-traceid,
• x-b3-স্প্যানিড,
• x-b3-parentspanid,
• x-b3-নমুনা,
• x-b3-পতাকা,
• x-ot-span-প্রসঙ্গ।

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

উপসংহার

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

সার্ভিস মেশ সম্পর্কে পরবর্তী নিবন্ধে, আমরা Istio-এর সবচেয়ে বড় সমস্যাগুলির মধ্যে একটি দেখব - প্রতিটি সাইডকার প্রক্সি কন্টেইনারে RAM-এর বৃহৎ ব্যবহার এবং আপনি কীভাবে এটি মোকাবেলা করতে পারেন তা নিয়ে আলোচনা করব।

উত্স: www.habr.com