/etc/resolv.conf Kubernetes pods-ისთვის, ndots:5 ვარიანტი, როგორ შეიძლება ეს უარყოფითად იმოქმედოს აპლიკაციის შესრულებაზე

ჩვენ ახლახან გავუშვით Kubernetes 1.9 AWS-ზე Kops-ის გამოყენებით. გუშინ, როდესაც შეუფერხებლად ვახორციელებდი ახალ ტრაფიკს ჩვენს Kubernetes-ის უდიდეს კლასტერებში, დავიწყე ჩვენი აპლიკაციის მიერ დარეგისტრირებული DNS-ის სახელის რეზოლუციის უჩვეულო შეცდომების შემჩნევა.

ამის შესახებ საკმაოდ ბევრია GitHub-ზე ისაუბრა, ამიტომ მეც გადავწყვიტე გამერკვია. ბოლოს მივხვდი, რომ ჩვენს შემთხვევაში ეს გამოწვეულია გაზრდილი დატვირთვით kube-dns и dnsmasq. ჩემთვის ყველაზე საინტერესო და ახალი იყო DNS მოთხოვნის ტრაფიკის მნიშვნელოვანი ზრდის მიზეზი. ჩემი პოსტი ამაზეა და რა უნდა გავაკეთო.

DNS რეზოლუცია კონტეინერის შიგნით - როგორც ნებისმიერ Linux სისტემაში - განისაზღვრება კონფიგურაციის ფაილით /etc/resolv.conf. ნაგულისხმევი Kubernetes dnsPolicy ამ ClusterFirst, რაც ნიშნავს, რომ ნებისმიერი DNS მოთხოვნა გადამისამართდება dnsmasq, გაშვებული pod kube-dns კლასტერის შიგნით, რომელიც თავის მხრივ გადააგზავნის მოთხოვნას აპლიკაციაში kube-dns, თუ სახელი მთავრდება კლასტერული სუფიქსით, ან, სხვა შემთხვევაში, უფრო მაღალი დონის DNS სერვერზე.

ფაილი /etc/resolv.conf თითოეული კონტეინერის შიგნით ნაგულისხმევი ასე გამოიყურება:

nameserver 100.64.0.10
search namespace.svc.cluster.local svc.cluster.local cluster.local 
eu-west-1.compute.internal
options ndots:5

როგორც ხედავთ, არსებობს სამი დირექტივა:

1. სახელის სერვერი არის სერვისის IP kube-dns
2. მითითებულია 4 ადგილობრივი საძიებო დომენი search
3. არის ვარიანტი ndots:5

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

რა არის სრული სახელი?

სრულად კვალიფიციური სახელი არის სახელი, რომლისთვისაც ლოკალური ძებნა არ განხორციელდება და სახელი ჩაითვლება აბსოლუტური სახელის გადაწყვეტის დროს. კონვენციით, DNS პროგრამული უზრუნველყოფა მიიჩნევს, რომ სახელი სრულად კვალიფიცირდება, თუ ის მთავრდება წერტილით (.) და სხვაგვარად არ არის სრულად კვალიფიცირებული. ანუ google.com. სრულად განსაზღვრული და google.com - არა.

როგორ ექცევა არაკვალიფიცირებული სახელი?

როდესაც აპლიკაცია უერთდება სახელში მითითებულ დისტანციურ ჰოსტს, DNS სახელის გარჩევადობა ჩვეულებრივ ხდება სისტემური ზარის გამოყენებით, მაგ. getaddrinfo(). მაგრამ თუ სახელი არაკვალიფიცირებულია (არ მთავრდება .-ით), მაინტერესებს, სისტემური ზარი შეეცდება თუ არა სახელის აბსოლუტურ სახელად გადაწყვეტას, თუ ჯერ გაივლის ადგილობრივი საძიებო დომენებს? ეს დამოკიდებულია ვარიანტზე ndots.

სახელმძღვანელოდან resolv.conf:

ndots:n

устанавливает порог для количества точек, которые должны появиться в имени, прежде чем будет сделан начальный абсолютный запрос. Значение по умолчанию для n равно 1, что означает, что если в имени есть какие-либо точки, имя будет сначала опробовано как абсолютное имя, прежде чем к нему будут добавлены какие-либо элементы списка поиска.

ეს ნიშნავს, რომ თუ ამისთვის ndots 5-ის მნიშვნელობის გათვალისწინებით და სახელი შეიცავს 5 წერტილზე ნაკლებს, სისტემური ზარი შეეცდება გადაჭრას ის თანმიმდევრულად, ჯერ გაივლის ყველა ლოკალური საძიებო დომენს და წარუმატებლობის შემთხვევაში, საბოლოოდ გადაჭრის მას, როგორც აბსოლუტურ სახელს.

რატომ არის იგივე ndots:5 შეიძლება ეს უარყოფითად იმოქმედოს განაცხადის შესრულებაზე?

როგორც თქვენ წარმოიდგინეთ, თუ თქვენი აპლიკაცია იყენებს უამრავ გარე ტრაფიკს, თითოეული დამყარებული TCP კავშირისთვის (უფრო ზუსტად, თითოეული გადაწყვეტილი სახელისთვის), ის გასცემს 5 DNS მოთხოვნას, სანამ სახელი სწორად გადაწყდება, რადგან ის ჯერ გაივლის. 4 ადგილობრივი საძიებო დომენი, და ბოლოს გამოსცემს აბსოლუტური სახელის გადაწყვეტის მოთხოვნას.

შემდეგი დიაგრამა გვიჩვენებს მთლიან ტრაფიკს ჩვენს 3 kube-dns მოდულზე მანამდე და მას შემდეგ, რაც ჩვენს აპლიკაციაში კონფიგურირებული რამდენიმე ჰოსტის სახელი სრულად კვალიფიციურზე გადავრთეთ.

შემდეგი დიაგრამა გვიჩვენებს აპლიკაციის შეყოვნებას მანამდე და მას შემდეგ, რაც ჩვენს აპლიკაციაში კონფიგურირებული რამდენიმე ჰოსტის სახელი გადავიყვანეთ სრულ სახელებზე (ვერტიკალური ლურჯი ხაზი არის განლაგება):

გამოსავალი #1 - გამოიყენეთ სრულად კვალიფიციური სახელები

თუ თქვენ გაქვთ რამდენიმე სტატიკური გარე სახელები (ანუ განსაზღვრული აპლიკაციის კონფიგურაციაში), რომლებთანაც შექმნით კავშირების დიდ რაოდენობას, ალბათ უმარტივესი გამოსავალია მათი გადართვა სრულად კვალიფიციურზე მათი უბრალოდ მიმატებით. ბოლოს.

ეს არ არის საბოლოო გამოსავალი, მაგრამ ის ეხმარება სწრაფად, თუმცა არა სუფთად, სიტუაციის გაუმჯობესებაში. ჩვენ გამოვიყენეთ ეს პატჩი ჩვენი პრობლემის მოსაგვარებლად, რომლის შედეგები ნაჩვენებია ზემოთ მოცემულ ეკრანის სურათებში.

გამოსავალი #2 - პერსონალიზაცია ndots в dnsConfig

Kubernetes 1.9-ში ფუნქციონალობა გამოჩნდა ალფა რეჟიმში (ბეტა ვერსია v1.10), რაც საშუალებას გაძლევთ უკეთ გააკონტროლოთ DNS პარამეტრები pod თვისების მეშვეობით dnsConfig. სხვა საკითხებთან ერთად, ის საშუალებას გაძლევთ დააკონფიგურიროთ მნიშვნელობა ndots კონკრეტული პოდისთვის, ე.ი.

apiVersion: v1
kind: Pod
metadata:
  namespace: default
  name: dns-example
spec:
  containers:
    - name: test
      image: nginx
  dnsConfig:
    options:
      - name: ndots
        value: "1"

ინფორმაციის წყაროები

• რა არის DNS სახელის კვალიფიკაცია
• Kubernetes: DNS სერვისებისა და პოდებისთვის

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

• კონტექსტური პაკეტის გაგება Golang-ში
• სამი მარტივი ხრიკი დოკერის სურათების შესამცირებლად
• სახელმწიფო სარეზერვო ასლები Kubernetes-ში
• დიდი რაოდენობით ჰეტეროგენული ვებ პროექტების სარეზერვო ასლი
• Telegram-ის ბოტი Redmine-ისთვის. როგორ გავამარტივოთ ცხოვრება საკუთარი თავისთვის და სხვებისთვის

წყარო: www.habr.com