কুবারনেটে ডিএনএস লুকআপ

বিঃদ্রঃ. অনুবাদ: কুবারনেটে ডিএনএস সমস্যা, বা আরও স্পষ্টভাবে, প্যারামিটার সেটিংস ndots, আশ্চর্যজনকভাবে জনপ্রিয় এবং ইতিমধ্যেই প্রথম নয় год. এই বিষয়ে আরেকটি নোটে, এর লেখক, ভারতের একটি বড় ব্রোকারেজ কোম্পানির একজন DevOps প্রকৌশলী, কুবারনেটস পরিচালনাকারী সহকর্মীদের জানার জন্য কী দরকারী তা সম্পর্কে খুব সহজ এবং সংক্ষিপ্তভাবে কথা বলেছেন।

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

DNS নামের রেজোলিউশন ব্যবহার করে একটি Kubernetes ক্লাস্টারে কনফিগার করা হয়েছে কোরডিএনএস. কুবেলেট ফাইলগুলিতে নেমসার্ভার হিসাবে CoreDNS-এর সাথে একটি পড নিবন্ধন করে /etc/resolv.conf সব শুঁটি আপনি যদি বিষয়বস্তু দেখুন /etc/resolv.conf যেকোন পড, এটি দেখতে এরকম কিছু হবে:

search hello.svc.cluster.local svc.cluster.local cluster.local
nameserver 10.152.183.10
options ndots:5

এই কনফিগারেশনটি DNS ক্লায়েন্টরা DNS সার্ভারে অনুরোধ ফরোয়ার্ড করতে ব্যবহার করে। ফাইলে resolv.conf নিম্নলিখিত তথ্য রয়েছে:

• নাম সার্ভার: সার্ভার যেখানে DNS অনুরোধ পাঠানো হবে। আমাদের ক্ষেত্রে, এটি CoreDNS পরিষেবার ঠিকানা;
• অনুসন্ধান: একটি নির্দিষ্ট ডোমেনের জন্য অনুসন্ধান পথ সংজ্ঞায়িত করে। এটা আকর্ষণীয় যে google.com বা mrkaran.dev FQDN নয় (সম্পূর্ণরূপে যোগ্যতাসম্পন্ন ডোমেইন নাম) বেশিরভাগ DNS সমাধানকারীরা যে স্ট্যান্ডার্ড কনভেনশন অনুসরণ করে, শুধুমাত্র সেগুলিই যেগুলি একটি ডট দিয়ে শেষ হয় “.”, রুট জোনের প্রতিনিধিত্ব করে, সম্পূর্ণরূপে যোগ্য (FDQN) ডোমেন হিসাবে বিবেচিত হয়৷ কিছু সমাধানকারী নিজেরাই একটি পয়েন্ট যোগ করতে পারেন। এইভাবে, mrkaran.dev. সম্পূর্ণরূপে যোগ্যতাসম্পন্ন ডোমেইন নাম (FQDN), এবং mrkaran.dev - না;
• ndots: সবচেয়ে আকর্ষণীয় প্যারামিটার (এই নিবন্ধটি এটি সম্পর্কে)। ndots একটি "সম্পূর্ণ যোগ্য" ডোমেন নাম হিসাবে বিবেচিত হওয়ার আগে একটি অনুরোধের নামটিতে বিন্দুগুলির থ্রেশহোল্ড সংখ্যা নির্দিষ্ট করে৷ আমরা এই বিষয়ে পরে আরও কথা বলব যখন আমরা DNS লুকআপ ক্রম বিশ্লেষণ করব।

দেখা যাক আমরা জিজ্ঞাসা করলে কি হয় mrkaran.dev পডে:

$ nslookup mrkaran.dev
Server: 10.152.183.10
Address: 10.152.183.10#53

Non-authoritative answer:
Name: mrkaran.dev
Address: 157.230.35.153
Name: mrkaran.dev
Address: 2400:6180:0:d1::519:6001

এই পরীক্ষার জন্য, আমি CoreDNS লগিং স্তর সেট করেছি all (যা এটিকে বেশ শব্দচয়ন করে তোলে)। এর পড এর লগ তাকান coredns:

[INFO] 10.1.28.1:35998 - 11131 "A IN mrkaran.dev.hello.svc.cluster.local. udp 53 false 512" NXDOMAIN qr,aa,rd 146 0.000263728s
[INFO] 10.1.28.1:34040 - 36853 "A IN mrkaran.dev.svc.cluster.local. udp 47 false 512" NXDOMAIN qr,aa,rd 140 0.000214201s
[INFO] 10.1.28.1:33468 - 29482 "A IN mrkaran.dev.cluster.local. udp 43 false 512" NXDOMAIN qr,aa,rd 136 0.000156107s
[INFO] 10.1.28.1:58471 - 45814 "A IN mrkaran.dev. udp 29 false 512" NOERROR qr,rd,ra 56 0.110263459s
[INFO] 10.1.28.1:54800 - 2463 "AAAA IN mrkaran.dev. udp 29 false 512" NOERROR qr,rd,ra 68 0.145091744s

ওফ দুটি জিনিস এখানে আপনার দৃষ্টি আকর্ষণ করে:

• অনুরোধটি অনুসন্ধানের সমস্ত পর্যায়ে যায় যতক্ষণ না প্রতিক্রিয়াটিতে কোড থাকে NOERROR (DNS ক্লায়েন্টরা এটি বোঝে এবং ফলস্বরূপ এটি সংরক্ষণ করে)। NXDOMAIN মানে প্রদত্ত ডোমেইন নামের জন্য কোনো রেকর্ড পাওয়া যায়নি। কারন mrkaran.dev একটি FQDN নাম নয় (এর মতে ndots=5), সমাধানকারী অনুসন্ধানের পথ দেখে এবং অনুরোধের ক্রম নির্ধারণ করে;
• রেকর্ডিং А и АААА সমান্তরালভাবে পৌঁছান। সত্য যে এক সময় অনুরোধ ইন /etc/resolv.conf ডিফল্টরূপে, সেগুলি এমনভাবে কনফিগার করা হয় যাতে IPv4 এবং IPv6 প্রোটোকল ব্যবহার করে সমান্তরাল অনুসন্ধান করা হয়। আপনি বিকল্প যোগ করে এই আচরণ বাতিল করতে পারেন single-request в resolv.conf.

দ্রষ্টব্য: glibc এই অনুরোধগুলিকে ক্রমানুসারে পাঠাতে কনফিগার করা যেতে পারে, এবং musl - না, তাই আলপাইন ব্যবহারকারীদের নোট করা উচিত।

ndots সঙ্গে পরীক্ষা

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

আসুন এটি নিশ্চিত করি:

$ cat /etc/resolv.conf
options ndots:1
$ nslookup mrkaran
Server: 10.152.183.10
Address: 10.152.183.10#53

** server can't find mrkaran: NXDOMAIN

CoreDNS লগ:

[INFO] 10.1.28.1:52495 - 2606 "A IN mrkaran.hello.svc.cluster.local. udp 49 false 512" NXDOMAIN qr,aa,rd 142 0.000524939s
[INFO] 10.1.28.1:59287 - 57522 "A IN mrkaran.svc.cluster.local. udp 43 false 512" NXDOMAIN qr,aa,rd 136 0.000368277s
[INFO] 10.1.28.1:53086 - 4863 "A IN mrkaran.cluster.local. udp 39 false 512" NXDOMAIN qr,aa,rd 132 0.000355344s
[INFO] 10.1.28.1:56863 - 41678 "A IN mrkaran. udp 25 false 512" NXDOMAIN qr,rd,ra 100 0.034629206s

১ Since সাল থেকে mrkaran একটি একক বিন্দু নেই, অনুসন্ধানটি প্রত্যয়গুলির সম্পূর্ণ তালিকা জুড়ে করা হয়েছিল।

দ্রষ্টব্য: অনুশীলনে সর্বাধিক মান ndots 15 পর্যন্ত সীমাবদ্ধ; Kubernetes-এ ডিফল্টরূপে এটি 5।

উৎপাদনে আবেদন

যদি একটি অ্যাপ্লিকেশন প্রচুর বাহ্যিক নেটওয়ার্ক কল করে, তবে সক্রিয় ট্র্যাফিকের ক্ষেত্রে DNS একটি বাধা হয়ে দাঁড়াতে পারে, যেহেতু নামের রেজোলিউশন অনেকগুলি অপ্রয়োজনীয় প্রশ্ন তৈরি করে (সিস্টেমটি সঠিকটিতে পৌঁছানোর আগে)। অ্যাপ্লিকেশনগুলি সাধারণত ডোমেন নামের সাথে একটি রুট জোন যোগ করে না, তবে এটি একটি হ্যাক মত শোনাচ্ছে। অর্থাৎ চাওয়ার বদলে api.twitter.com, আপনি হার্ডকোড করতে পারেন api.twitter.com. অ্যাপ্লিকেশনে (একটি বিন্দু সহ), যা ডিএনএস ক্লায়েন্টদেরকে সরাসরি পরম ডোমেনে প্রামাণিক লুকআপ করতে অনুরোধ করবে।

উপরন্তু, Kubernetes সংস্করণ 1.14, এক্সটেনশন দিয়ে শুরু dnsConfig и dnsPolicy স্থিতিশীল অবস্থা পেয়েছে। এইভাবে, একটি পড স্থাপন করার সময়, আপনি মান কমাতে পারেন ndots, বলুন, 3 পর্যন্ত (এবং এমনকি 1 পর্যন্ত!) এই কারণে, একটি নোডের মধ্যে প্রতিটি বার্তা সম্পূর্ণ ডোমেন অন্তর্ভুক্ত করতে হবে। এটি একটি ক্লাসিক ট্রেড-অফ যখন আপনাকে পারফরম্যান্স এবং বহনযোগ্যতার মধ্যে বেছে নিতে হবে। আমার কাছে মনে হচ্ছে যে আপনার কেবলমাত্র এই বিষয়ে চিন্তা করা উচিত যদি আপনার অ্যাপ্লিকেশনের জন্য অতি-নিম্ন বিলম্বিতা অত্যাবশ্যক হয়, যেহেতু DNS ফলাফলগুলিও অভ্যন্তরীণভাবে ক্যাশ করা হয়।

রেফারেন্স

আমি প্রথম এই বৈশিষ্ট্য সম্পর্কে শিখেছি K8s-মিটআপ, 25 জানুয়ারী অনুষ্ঠিত। সেখানে তারা অন্যান্য বিষয়ের সাথে এই সমস্যা নিয়ে আলোচনা করেন।

আরও অন্বেষণের জন্য এখানে কিছু লিঙ্ক রয়েছে:

• ব্যাখ্যা, কেন কুবারনেটসে ndots=5;
• চমৎকার উপাদান কিভাবে ndots পরিবর্তন অ্যাপ্লিকেশন কর্মক্ষমতা প্রভাবিত করে;
• অমিল musl এবং glibc সমাধানকারীদের মধ্যে।

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

শুভ DNSing! পরে দেখা হবে!

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

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

• «কুবারনেটসে নেটওয়ার্কিংয়ের জন্য ক্যালিকো: ভূমিকা এবং সামান্য অভিজ্ঞতা";
• «CoreDNS - ক্লাউড নেটিভ ওয়ার্ল্ডের জন্য DNS সার্ভার এবং কুবারনেটসের জন্য পরিষেবা আবিষ্কার";
• "কুবারনেটসে নেটওয়ার্কিং এর একটি সচিত্র নির্দেশিকা": অংশ 1 এবং 2 (নেটওয়ার্ক মডেল, ওভারলে নেটওয়ার্ক), অংশ 3 (পরিষেবা এবং ট্রাফিক প্রক্রিয়াকরণ).

উত্স: www.habr.com