Kubernetes va OpenVPN sidecar o'rtasida DNS ni qanday ajratish kerak

OpenVPN sidecar ishlatadigan podlar nomlarni hal qilishda tanish naqsh bilan muvaffaqiyatsizlikka uchraydi: klaster nomlari osilib qoladi, uzoq nomlar pod qayta ishga tushguncha javob beradi va siz tahrirlagan resolver fayli qaytib keladi. Bu ketma-ketlikda hech narsa tunnel nosozligi emas. Podda bitta resolver fayli va ikkita nom dunyosi bor, fayl serverlarni tartib bilan sanab chiqadi, lekin zonalarni ifodalay olmaydi. Barqaror yechim pod ichida ishlaydigan va bo'linishga ega bo'lgan resolverdir, shuning uchun fayl oddiy qoladi va hech qanday siyosat uni qayta yozishga sabab topmaydi.

Nega siz kiritgan o'zgarish doim yo'qoladi

Fayl kubeletga tegishli, sizga emas. dnsPolicy: ClusterFirst ostida kubelet uni klaster DNS iga ishora qilish uchun yaratadi va har safar konteyner ishga tushganda qayta yaratadi. kubectl exec orqali o'zgartirganingiz konteynerning yoziladigan qatlamida yashaydi, shuning uchun qayta ishga tushirish, chiqarib yuborish yoki rollout uni tashlaydi. Pod spetsifikatsiyasi hali ham o'sha siyosatni olib yuradi, shuning uchun o'sha fayl qaytadi.

dnsPolicy: None ni o'rnatish qayta yaratishni to'xtatadi va klaster hal qilishni ham olib tashlaydi. Siz o'zingiz boshqaradigan faylga ega bo'lasiz va kerakli nomlardan ayrilasiz. Bu almashinuv butun muammo: resolv.conf zona tushunchasini bilmaydi, faqat tartib bilan sinab ko'riladigan serverlarni biladi, shuning uchun cluster.local ni bitta manzilga, xususiy zonani boshqasiga yubora olmaydi.

Podda bitta resolver ishga tushiring, loopbackda

Podni loopbackdagi bitta nom serveriga yo'naltiring, keyin podning tarmoq nom maydonini bo'lishadigan CoreDNS konteyneriga 53 portda javob berishga ruxsat bering. Siyosatni None ga o'rnating, podga o'sha yagona manzilni bering va DNS konteynerini VPN va ilova yoniga qo'shing:

spec:
  dnsPolicy: None
  dnsConfig:
    nameservers:
      - 127.0.0.1
    options:
      - name: ndots
        value: "5"
  containers:
    - name: dns
      image: coredns/coredns
      args: ["-conf", "/etc/coredns/Corefile"]
      volumeMounts:
        - {name: corefile, mountPath: /etc/coredns, readOnly: true}
    - name: vpn
      image: your-openvpn-client-image
    - name: app
      image: your-app-image
  volumes:
    - name: corefile
      configMap:
        name: split-dns-corefile

Uchala konteyner bitta tarmoq nom maydonini bo'lishadi, shuning uchun ilova konteyneridan 127.0.0.1:53 xizmatsiz, port-forwardsiz va klaster tarmog'i bo'ylab aylanmasdan CoreDNS ga yetib boradi. Corefile ni ConfigMap dan mount qilish uni joyida tahrirlanadigan fayl o'rniga versiyalangan kirish sifatida saqlaydi. Yaratilgan resolv.conf keyin bitta nom serverini saqlaydi va boshqa hech narsani, bu haqda fikr yuritish mumkin bo'lgan holat.

Bu yerda ikkita tafsilot tishlaydi. Rasmiy image 53 portni root sifatida bog'laydi va ba'zi klaster siyosatlari buni aniq yozishni talab qiladi. Poddagi har bir konteyner endi o'sha bitta konteyner ishlashiga bog'liq, shuning uchun zararsiz nomga readiness probe qo'shing va ilovaga ishga tushish xatolarini ko'tarishga ruxsat bering.

Har bir xususiy zonaga o'z upstream ini bering

Corefile zonalar ro'yxati, har biri unga javob bera oladigan serverni nomlaydi. Bitta blok tunnel zonasini qamrab oladi va hamma narsani ushlaydigan blok oxirida keladi va hech qanday aniq blok talab qilmagan hamma narsani oladi. Hamma narsani ushlaydigan blok haqiqiy upstream ga qaratilishi kerak, hech qachon podga qaytmasligi kerak: .:53 { forward . 10.100.0.10 } klaster resolverini qayta ishlatadi, chunki u allaqachon ommaviy nomlarni tugunning o'z resolverlariga yuboradi. Poddagi boshqa hech narsa nom qaysi tarmoqqa tegishli ekanini bilishi shart emas.

.:53 {
  errors
  cache 30
  forward . 10.100.0.10
}

svc.acme.internal:53 {
  errors
  cache 30
  forward . 192.168.240.1
}

Klaster manzilini maqoladan ko'chirish o'rniga kube-system dagi kube-dns xizmatidan o'qing, chunki xizmat CIDR lari farq qiladi. Tunnel manzili OpenVPN serveri yuboradigan dhcp-option DNS qiymatidan yoki o'sha zona uchun vakolatli serverdan keladi. Agar klaster resolveringiz ommaviy nomlarga javob bermasa, tugun resolverining manzilini hamma narsani ushlaydigan blokka qo'ying, u tugunda o'qilgan bo'lsin, pod ichida emas.

Hamma narsani ushlaydigan blokni /etc/resolv.conf ga qaratmang, bu vasvasaga soladigan bir qator va aynan shu konfiguratsiyada tuzoq. dnsPolicy: None ostida podning o'z fayli yagona nom serveri 127.0.0.1 ni saqlaydi, shuning uchun bu maqsad CoreDNS ning o'zi va har bir mos kelmaydigan so'rov vaqt tugaguncha takrorlanadi. svc.acme.internal nomli blok o'sha nomga va uning ostidagi har bir nomga mos keladi, bu db.svc.acme.internal ni qamrab oladi va svc.acme.internal.example.net ni istisno qiladi. Oxirgi nuqta kosmetik, chunki zona nomlari to'liq malakali shaklga normallashtiriladi; qo'shimcha chegarasi so'rov qayerga tushishini hal qiladi.

Yo'naltirish klaster resolveriga tegishlimi yoki yo'qmi, hal qiling

Agar nom maydonidagi har bir ish yuki tunnel zonasiga muhtoj bo'lsa, kube-system ostidagi CoreDNS ConfigMap ida yo'naltirish bloki har bir podga sidecardan arzonroq. Bu o'zgarish klaster darajasida: administrator huquqlari va hamma tayanadigan joylashtirishni qayta ishga tushirish kerak. Uni o'sha bitta zona bilan cheklang, hech qachon ildiz bilan emas. Bitta ish yukining tunnel manzili keyin zona uchun har bir podning resolveri bo'ladi va tunnel yiqilgan kuni butun klaster nomdan ayriladi.

Sidecar portlash radiusini bitta pod ichida saqlaydi, bu faqat bir nechta xizmatga uzoq tarmoq kerak bo'lganda yaxshiroq standart. Nima tanlasangiz ham, qaysi resolver zonaga egaligini yozib qo'ying, chunki keyingi odam timeout ni tuzatayotganda so'raydi.

Ulanishlar hali muvaffaqiyatsiz bo'lganda hal qilinadigan nomlar

Hal qilish tunnel olib yurishi kerak bo'lgan ikkita narsadan biri; ikkinchisi qaytish yo'li va pod tarmog'i uni yaxshi yashiradi. Agar OpenVPN serverining o'zi pod sifatida ishlasa, o'sha konteynerga qo'shgan qoidalaringiz tugun orqali chiqadigan trafikni boshqarmaydi. Bu nosozlik tor: faqat serverni ham ishga tushirgan tugundagi podlar javob oldi, qolgan hamma narsa vaqt tugashi bilan yakunlandi.

Serverni hostNetwork: true bilan ishga tushirish uni tugunning nom maydoniga qaytaradi, u yerda FORWARD qoidasi va manba tarjimasi ishlaydi. Chiqishda mijoz hovuzini tarjima qiling, aks holda hech bir uzoq tugunda 10.8.0.6 kabi tunnel manziliga qaytish marshruti bo'lmaydi. Corefile ga yana tegishdan oldin ikkala yo'nalishni tekshiring. So'rovni olib, javobni olib ketmaydigan tunnel so'rovni hech qachon olmagan resolver bilan aynan bir xil timeout yaratadi.

Yangi poddan tekshiring, siz tuzatgan sessiyadan emas

Ikkala zonani ham aniq so'rang, keyin pod almashtirilgandan so'ng so'rovni takrorlang. Faqat ishlab turgan konteynerda mavjud konfiguratsiya konfiguratsiya emas:

kubectl exec -it deploy/app -- dig @127.0.0.1 kubernetes.default.svc.cluster.local +short
kubectl exec -it deploy/app -- dig @127.0.0.1 db.svc.acme.internal +short
kubectl delete pod -l app=your-app
kubectl wait --for=condition=Ready pod -l app=your-app --timeout=90s
kubectl exec -it deploy/app -- dig @127.0.0.1 db.svc.acme.internal +short

Agar birinchi juftlik javob bersa va almashtirishdan keyingi juftlik bermasa, Corefile to'g'ri va pod spetsifikatsiyasi noto'g'ri. Agar ikkalasi ham javob bersa, lekin ilova hali ham ulanmasa, DNS disk raskadrovkasini to'xtating va konteyner ichidan nc -vz db.svc.acme.internal 5432 bilan TCP yo'lini sinab ko'ring. dig chiqishini chiptada saqlang, chunki bu nom muammosini marshrutlash muammosidan ajratadigan artefakt.