🥇/etc/resolv.conf برای Kubernetes pods، گزینه ndots:5، چگونه می تواند بر عملکرد برنامه تأثیر منفی بگذارد

اخیراً Kubernetes 1.9 را با استفاده از Kops در AWS راه‌اندازی کردیم. دیروز، در حالی که به آرامی ترافیک جدید را به بزرگترین خوشه های Kubernetes ما ارسال می کردم، متوجه خطاهای غیرعادی وضوح نام DNS شدم که توسط برنامه ما ثبت شده بود.

در GitHub چیزهای زیادی در مورد این وجود دارد صحبت کرد، بنابراین تصمیم گرفتم که آن را نیز کشف کنم. در پایان، متوجه شدم که در مورد ما این به دلیل افزایش بار روی است kube-dns и dnsmasq. جالب ترین و جدیدترین چیز برای من دلیل افزایش چشمگیر ترافیک درخواست DNS بود. پست من در این مورد است و در مورد آن چه باید کرد.

وضوح DNS در داخل ظرف - مانند هر سیستم لینوکس - توسط فایل پیکربندی تعیین می شود /etc/resolv.conf. Kubernetes پیش فرض dnsPolicy این ClusterFirst، به این معنی که هر درخواست DNS به آن ارسال می شود dnsmasq، دویدن در غلاف 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

همانطور که می بینید، سه دستورالعمل وجود دارد:

نام سرور IP سرویس است kube-dns
4 دامنه جستجوی محلی مشخص شده است search
یک گزینه وجود دارد 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، عملکرد در حالت آلفا ظاهر شد (نسخه بتا نسخه 1.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"

منابع

همچنین سایر مقالات وبلاگ ما را بخوانید:

منبع: www.habr.com

/etc/resolv.conf برای Kubernetes pods، گزینه ndots:5، چگونه می تواند بر عملکرد برنامه تأثیر منفی بگذارد