Kā sadalīt DNS starp Kubernetes un OpenVPN sidecar

Podi, kuros darbojas OpenVPN sidecar, neizdodas atrisināt nosaukumus pēc atpazīstama modeļa: klastera nosaukumi karājas, attālie nosaukumi atbild, līdz pods tiek restartēts, un jūsu rediģētais resolver fails atgriežas atpakaļ. Nekas šajā secībā nav tuneļa defekts. Podam ir viens resolver fails un divas nosaukumu pasaules, un fails var uzskaitīt serverus secībā, bet nevar izteikt zonas. Ilgtspējīgais risinājums ir resolver, kas darbojas poda iekšienē un pārvalda sadalījumu, tāpēc fails paliek vienkāršs un nevienai politikai nav iemesla to pārrakstīt.

Kāpēc jūsu veiktā izmaiņa pastāvīgi pazūd

Fails pieder kubelet, nevis jums. Saskaņā ar dnsPolicy: ClusterFirst kubelet to ģenerē, lai norādītu uz klastera DNS, un ģenerē to no jauna katru reizi, kad startē konteiners. Viss, ko maināt caur kubectl exec, dzīvo konteinera rakstāmajā slānī, tāpēc restartēšana, izmešana vai rollout to izmet. Poda specifikācija joprojām satur to pašu politiku, tāpēc tas pats fails atgriežas.

Iestatot dnsPolicy: None, tiek apturēta atkārtota ģenerēšana un arī noņemta klastera atrisināšana. Jūs iegūstat failu, ko kontrolējat, un zaudējat nosaukumus, kas jums bija vajadzīgi. Šī maiņa ir visa problēma: resolv.conf nav zonu jēdziena, tikai serveri, kas jāizmēģina secībā, tāpēc tas nevar nosūtīt cluster.local uz vienu adresi un privātu zonu uz citu.

Palaidiet vienu resolver podā, uz loopback

Novirziet podu uz vienu nosaukumu serveri uz loopback, pēc tam ļaujiet CoreDNS konteineram, kas dala poda tīkla nosaukumu telpu, atbildēt 53 portā. Iestatiet politiku uz None, dodiet podam šo vienu adresi un pievienojiet DNS konteineru blakus VPN un lietojumprogrammai:

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

Visi trīs konteineri dala vienu tīkla nosaukumu telpu, tāpēc 127.0.0.1:53 no lietojumprogrammas konteinera sasniedz CoreDNS bez pakalpojuma, bez port-forward un bez apkārtceļa pa klastera tīklu. Corefile pievienošana no ConfigMap saglabā to kā versijotu ievadi, nevis failu, kas rediģēts uz vietas. Ģenerētais resolv.conf tad satur vienu nosaukumu serveri un neko citu, kas ir stāvoklis, par ko var spriest.

Divas detaļas šeit kod. Oficiālais attēls piesaista 53 portu kā root, un dažas klastera politikas pieprasa to skaidri uzrakstīt. Katrs poda konteiners tagad ir atkarīgs no tā, vai šis viens konteiners darbojas, tāpēc pievienojiet readiness pārbaudi pret nekaitīgu nosaukumu un ļaujiet lietojumprogrammai tolerēt starta kļūdas.

Dodiet katrai privātajai zonai savu upstream

Corefile ir zonu saraksts, katra nosauc serveri, kas tai var atbildēt. Viens bloks aptver tuneļa zonu, un visu pārtverošais bloks nāk pēdējais un ņem visu, ko neviens skaidrs bloks nav pieprasījis. Visu pārtverošajam blokam jābūt vērstam uz īstu upstream, nekad atpakaļ uz podu: .:53 { forward . 10.100.0.10 } atkārtoti izmanto klastera resolver, jo tas jau pārsūta publiskos nosaukumus uz paša mezgla resolveriem. Nekam citam podā nav jāzina, kurai tīklam pieder nosaukums.

.:53 {
  errors
  cache 30
  forward . 10.100.0.10
}

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

Lasiet klastera adresi no kube-dns pakalpojuma kube-system, nevis kopējiet to no raksta, jo pakalpojumu CIDR atšķiras. Tuneļa adrese nāk no dhcp-option DNS vērtības, ko sūta OpenVPN serveris, vai no attiecīgās zonas autoritatīvā servera. Ja jūsu klastera resolver neatbild uz publiskiem nosaukumiem, ievietojiet mezgla resolver adresi visu pārtverošajā blokā, lasītu uz mezgla, nevis podā.

Nevirziet visu pārtverošo bloku uz /etc/resolv.conf, tas ir vilinošais vienas rindas risinājums un slazds tieši šajā konfigurācijā. Saskaņā ar dnsPolicy: None paša poda fails satur vienīgo nosaukumu serveri 127.0.0.1, tāpēc šis mērķis ir pats CoreDNS, un katrs nesakrītošais vaicājums atkārtojas, līdz beidzas laiks. Bloks ar nosaukumu svc.acme.internal atbilst šim nosaukumam un katram nosaukumam zem tā, kas aptver db.svc.acme.internal un izslēdz svc.acme.internal.example.net. Beigu punkts ir kosmētisks, jo zonu nosaukumi tiek normalizēti pilnīgi kvalificētā formā; sufiksa robeža nosaka, kur vaicājums nokļūst.

Izlemiet, vai pārsūtīšana pieder klastera resolver

Ja katram nosaukumu telpas darba apjomam vajadzīga tuneļa zona, pārsūtīšanas bloks CoreDNS ConfigMap saskaņā ar kube-system ir lētāks nekā sidecar katram podam. Šī izmaiņa ir klastera mērogā: tai vajadzīgas administratora tiesības un visu atkarīgā izvietojuma restartēšana. Ierobežojiet to ar šo vienu zonu, nekad ar sakni. Viena darba apjoma tuneļa adrese tad kļūst par katra poda resolveri šai zonai, un dienā, kad tunelis nokrīt, viss klasteris zaudē nosaukumu.

Sidecar tur sprādziena rādiusu viena poda iekšienē, kas ir labāks noklusējums, kad tikai dažiem pakalpojumiem vajadzīgs attālais tīkls. Ko vien izvēlaties, pierakstiet, kurš resolver pārvalda zonu, jo nākamais cilvēks, kas atkļūdoš timeout, to jautās.

Nosaukumi, kas atrisinās, kamēr savienojumi vēl neizdodas

Atrisināšana ir viena no divām lietām, kas tunelim jānes; otra ir atgriešanās ceļš, un poda tīkls to labi slēpj. Ja pats OpenVPN serveris darbojas kā pods, noteikumi, ko pievienojat šajā konteinerā, nepārvalda satiksmi, kas iziet caur mezglu. Šī kļūda ir šaura: atbildes saņēma tikai tā mezgla podi, kas arī palaida serveri, un viss pārējais beidzās ar laika limitu.

Servera palaišana ar hostNetwork: true atgriež to mezgla nosaukumu telpā, kur darbojas FORWARD noteikums un avota tulkošana. Tulkot klientu pūlu izejā, citādi nevienam attālajam mezglam nav maršruta atpakaļ uz tuneļa adresi, piemēram, 10.8.0.6. Pārbaudiet abus virzienus pirms vēlreiz pieskarties Corefile. Tunelis, kas pārnēsā vaicājumu, bet ne atbildi, rada tieši tādu pašu timeout kā resolver, kas nekad nav saņēmis vaicājumu.

Pārbaudiet no jauna poda, nevis no sesijas, ko labojāt

Jautājiet abām zonām skaidri, pēc tam atkārtojiet vaicājumu pēc poda nomaiņas. Konfigurācija, kas pastāv tikai darbojošā konteinerā, nav konfigurācija:

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

Ja pirmais pāris atbild un pāris pēc nomaiņas ne, Corefile ir kārtībā, bet poda specifikācija nav. Ja abi atbild un lietojumprogramma joprojām nevar izveidot savienojumu, pārtrauciet DNS atkļūdošanu un pārbaudiet TCP ceļu ar nc -vz db.svc.acme.internal 5432 konteinera iekšienē. Saglabājiet dig izvadi biļetē, jo tas ir artefakts, kas atšķir nosaukumu problēmu no maršrutēšanas problēmas.