🥇/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, запушчаны ў подзе 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 у альфа рэжыме з'явіўся функцыянал (бэта-версія v1.10), які дазваляе лепш кантраляваць параметры DNS праз уласцівасць пода ў dnsConfig. Сярод іншага, ён дазваляе наладзіць значэнне ndots для канкрэтнага пода, г.зн.

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

крыніцы

Таксама чытайце іншыя артыкулы ў нашым блогу:

Крыніца: habr.com

/etc/resolv.conf для Kubernetes pods, опцыя ndots:5, як гэта можа негатыўна адбіцца на прадукцыйнасці прыкладання