DNS ძიება Kubernetes-ში

Შენიშვნა. თარგმნა: DNS პრობლემა Kubernetes-ში, უფრო ზუსტად, პარამეტრის პარამეტრებში ndots, საოცრად პოპულარულია და უკვე არა პირველი წელი. სხვა ჩანაწერში ამ თემაზე, მისი ავტორი, DevOps ინჟინერი ინდოეთის დიდი საბროკერო კომპანიისგან, საუბრობს ძალიან მარტივად და ლაკონურად იმის შესახებ, თუ რა არის სასარგებლო Kubernetes-ის მოქმედი კოლეგებისთვის.

Kubernetes-ზე აპლიკაციების განლაგების ერთ-ერთი მთავარი უპირატესობაა აპლიკაციების უწყვეტი აღმოჩენა. კლასტერული ურთიერთქმედება მნიშვნელოვნად გამარტივებულია სერვისის კონცეფციის წყალობით (სამსახურის), რომელიც არის ვირტუალური IP, რომელიც მხარს უჭერს pod IP მისამართების კომპლექტს. მაგალითად, თუ მომსახურება vanilla სურს დაუკავშირდეს სერვისს chocolate, მას შეუძლია პირდაპირ წვდომა ვირტუალურ IP-ზე chocolate. ჩნდება კითხვა: ვის გადაწყვეტს ამ შემთხვევაში DNS მოთხოვნას chocolate Და როგორ?

DNS სახელის გარჩევადობა კონფიგურირებულია Kubernetes კლასტერზე გამოყენებით CoreDNS. Kubelet არეგისტრირებს პოდს 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 გადამწყვეტების უმეტესობა, მხოლოდ ის, რომელიც მთავრდება წერტილით ".", რომელიც წარმოადგენს root ზონას, განიხილება სრულად კვალიფიციური (FDQN) დომენები. ზოგიერთ გადამწყვეტს შეუძლია საკუთარი პუნქტის დამატება. ამრიგად, mrkaran.dev. არის სრულად კვალიფიციური დომენის სახელი (FQDN) და mrkaran.dev - არა;
• წერტილები: ყველაზე საინტერესო პარამეტრი (ამ სტატიაში არის ამის შესახებ). 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 - არა, ამიტომ Alpine მომხმარებლებმა უნდა გაითვალისწინონ.

ექსპერიმენტები წერტილებით

მოდით, ცოტა მეტი ექსპერიმენტი გავაკეთოთ ndots და ვნახოთ, როგორ იქცევა ეს პარამეტრი. იდეა მარტივია: ndots განსაზღვრავს, განიხილავს თუ არა DNS კლიენტი დომენს აბსოლუტურად თუ ფარდობითად. მაგალითად, მარტივი google 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

მას შემდეგ, რაც mrkaran არ არის ერთი წერტილი, ძიება განხორციელდა სუფიქსების მთელ სიაში.

შენიშვნა: პრაქტიკაში მაქსიმალური მნიშვნელობა ndots შეზღუდულია 15; ნაგულისხმევად Kubernetes-ში არის 5.

გამოყენება წარმოებაში

თუ აპლიკაცია უამრავ გარე ქსელში ზარს აკეთებს, DNS შეიძლება გახდეს ბარიერი აქტიური ტრაფიკის შემთხვევაში, რადგან სახელის გარჩევადობა ბევრ არასაჭირო მოთხოვნას აყენებს (სანამ სისტემა სწორს მიაღწევს). აპლიკაციები, როგორც წესი, არ ამატებენ ძირეულ ზონას დომენის სახელებს, მაგრამ ეს ჰაკივით ჟღერს. ანუ კითხვის ნაცვლად api.twitter.com, შეგიძლიათ მისი "მყარი კოდირება". api.twitter.com. (წერტილით) აპლიკაციაში, რომელიც უბიძგებს DNS კლიენტებს შეასრულონ ავტორიტეტული ძიება პირდაპირ აბსოლუტურ დომენზე.

გარდა ამისა, დაწყებული Kubernetes ვერსიით 1.14, გაფართოებებით dnsConfig и dnsPolicy მიიღო სტაბილური სტატუსი. ამგვარად, პოდის განლაგებისას, შეგიძლიათ შეამციროთ მნიშვნელობა ndotsვთქვათ, 3-მდე (და თუნდაც 1-მდე!). ამის გამო, კვანძის შიგნით ყველა შეტყობინება უნდა შეიცავდეს სრულ დომენს. ეს არის ერთ-ერთი კლასიკური გარიგება, როდესაც თქვენ უნდა აირჩიოთ შესრულება და პორტაბელურობას შორის. მეჩვენება, რომ ამაზე უნდა ინერვიულოთ მხოლოდ იმ შემთხვევაში, თუ ულტრა დაბალი შეყოვნება სასიცოცხლოდ მნიშვნელოვანია თქვენი აპლიკაციისთვის, რადგან DNS შედეგები ასევე შიგნიდან არის ქეშირებული.

ლიტერატურა

პირველად გავიგე ამ ფუნქციის შესახებ K8s-შეხვედრა25 იანვარს გაიმართა. იყო დისკუსია ამ პრობლემასთან ერთად.

აქ არის რამოდენიმე ბმული შემდგომი შესწავლისთვის:

• განმარტება, რატომ ndots=5 Kubernetes-ში;
• Კარგი რამ როგორ მოქმედებს წერტილების შეცვლა აპლიკაციის შესრულებაზე;
• შეუსაბამობები musl და glibc გადამწყვეტებს შორის.

შენიშვნა: მე ვარჩიე არ გამომეყენებინა dig ამ სტატიაში. dig ავტომატურად ამატებს წერტილს (ძირეული ზონის იდენტიფიკატორი), რაც დომენს "სრულად კვალიფიციურს" ხდის (FQDN), არარის ჯერ გაუშვით საძიებო სიაში. ამის შესახებ წერდა ერთ-ერთი წინა პუბლიკაცია. თუმცა, საკმაოდ გასაკვირია, რომ ზოგადად, ცალკე დროშა უნდა იყოს მითითებული სტანდარტული ქცევისთვის.

ბედნიერი DNSing! Მოგვიანებით გნახავ!

PS მთარგმნელისგან

ასევე წაიკითხეთ ჩვენს ბლოგზე:

• «Calico კუბერნეტში ქსელისთვის: შესავალი და მცირე გამოცდილება";
• «CoreDNS - DNS სერვერი ღრუბლის მშობლიური სამყაროსთვის და სერვისის აღმოჩენა Kubernetes-ისთვის";
• "ილუსტრირებული გზამკვლევი ქსელში Kubernetes-ში": ნაწილები 1 და 2 (ქსელის მოდელი, გადაფარვის ქსელები), ნაწილი 3 (მომსახურება და ტრაფიკის დამუშავება).

წყარო: www.habr.com