Kuidas jagada DNS-i Kubernetes ja OpenVPN sidecari vahel

Sidecar-pod vajab kahte nimeruumi. Suunake üks loopback-resolver klastri ja tunnelile ning lõpetage redigeeritud resolv.conf-ile toetumine.

Podid, mis käivitavad OpenVPN sidecari, ebaõnnestuvad nimede lahendamisel äratuntava mustri järgi: klastri nimed hangivad, kaugnimed vastavad, kuni pod taaskäivitub, ja teie redigeeritud resolver-fail taastub. Selles jadas ei ole miski tunneli defekt. Podil on üks resolver-fail ja kaks nimeruumi, ning fail saab servereid järjekorras loetleda, kuid ei saa väljendada tsoone. Kestev lahendus on podi sees töötav resolver, mis omab jagunemist, nii et fail jääb triviaalseks ja ühegi poliitikal pole põhjust seda ümber kirjutada.

Miks teie tehtud muudatus pidevalt kaob

Fail kuulub kubeletile, mitte teile. dnsPolicy: ClusterFirst korral genereerib kubelet selle klastri DNS-ile osutamiseks ja genereerib selle uuesti iga kord, kui konteiner käivitub. Kõik, mida muudate kubectl exec kaudu, elab konteineri kirjutatavas kihis, seega taaskäivitamine, väljatõrjumine või rollout viskab selle ära. Podi spetsifikatsioon kannab endiselt sama poliitikat, mistõttu sama fail naaseb.

dnsPolicy: None seadmine peatab uuesti genereerimise ja eemaldab ka klastri resolvimise. Võidate faili, mida kontrollite, ja kaotate nimed, mida vajasite. See vahetus on kogu probleem: resolv.conf ei tunne tsoone, ainult servereid, mida järjekorras proovida, seega ei saa see saata cluster.local ühele aadressile ja privaatset tsooni teisele.

Käivitage üks resolver podis, loopbackil

Suunake pod ühele nimeserverile loopbackil, seejärel laske CoreDNSi konteineril, mis jagab podi võrgu nimeruumi, vastata pordil 53. Seadke poliitika None, andke podile see üks aadress ja lisage DNS-konteiner VPN-i ja rakenduse kõrvale:

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

Kõik kolm konteinerit jagavad ühte võrgu nimeruumi, seega 127.0.0.1:53 jõuab rakenduse konteinerist CoreDNSini ilma teenuseta, ilma port-forwardita ja ilma klastri võrgust ringiga minemata. Corefile'i mountimine ConfigMapist hoiab selle versioonitud sisendina, mitte kohapeal redigeeritava failina. Genereeritud resolv.conf sisaldab siis ühte nimeserverit ja mitte midagi muud, mis on olek, mille üle saate arutleda.

Kaks detaili hammustavad siin. Ametlik pilt seob pordi 53 rootina ja mõned klastri poliitikad nõuavad, et kirjutaksite selle selgesõnaliselt. Iga konteiner podis sõltub nüüd sellest, et see üks konteiner töötab, seega lisage valmisolekuproov kahjutu nime vastu ja laske rakendusel käivitustõrkeid taluda.

Andke igale privaatsele tsoonile oma upstream

Corefile on tsoonide loend, igaüks nimetab serveri, mis saab sellele vastata. Üks plokk katab tunnelitsooni ja kõike püüdev plokk tuleb viimasena ning võtab kõik, mida ükski selgesõnaline plokk ei nõudnud. Kõike püüdev plokk peab sihtima tõelist upstreami, mitte kunagi tagasi podi poole: .:53 { forward . 10.100.0.10 } kasutab klastri resolverit uuesti, sest see resolver edastab juba avalikke nimesid sõlme enda resolveritele. Semmis muu podis ei pea teadma, millisesse võrku nimi kuulub.

.:53 {
  errors
  cache 30
  forward . 10.100.0.10
}

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

Lugege klastri aadress kube-dns teenusest kube-system-s, selle asemel et see artiklist kopeerida, sest teenuse CIDR-id erinevad. Tunneli aadress tuleb väärtusest dhcp-option DNS, mille OpenVPN server saadab, või selle tsooni autoriteetsest serverist. Kui teie klastri resolver ei vasta avalikele nimedele, pange sõlme resolveri aadress kõike püüdvasse plokki, loetuna sõlmel, mitte podi sees.

Ärge suunake kõike püüdvat plokki /etc/resolv.conf-le, see on ahvatlev üherealine lahendus ja lõks just selles seadistuses. dnsPolicy: None korral sisaldab podi enda fail ainsat nimeserverit 127.0.0.1, seega on see sihtmärk CoreDNS ise ja iga mittevastav päring kordub, kuni aegub. Plokk nimega svc.acme.internal vastab sellele nimele ja igale nimele selle all, mis katab db.svc.acme.internal ja välistab svc.acme.internal.example.net. Lõpp-punkt on kosmeetiline, sest tsooninimed normaliseeritakse täielikult kvalifitseeritud kujule; sufiksi piir otsustab, kuhu päring maandub.

Otsustage, kas edastamine kuulub klastri resolverile

Kui iga töökoormus nimeruumis vajab tunnelitsooni, on edastusplokk CoreDNSi ConfigMapis kube-system all odavam kui sidecar podi kohta. See muudatus on klastri ulatusega: see nõuab administraatoriõigusi ja sellise deploymenti taaskäivitamist, millest kõik sõltuvad. Piirake see selle ühe tsooniga, mitte kunagi juurega. Ühe töökoormuse tunneli aadressist saab siis iga podi resolver selle tsooni jaoks ja päeval, mil tunnel langeb, kaotab kogu klaster nime.

Sidecar hoiab plahvatusraadiuse ühe podi sees, mis on parem vaikevalik, kui kaugvõrku vajavad vaid üksikud teenused. Mida iganes valite, kirjutage üles, milline resolver tsooni omab, sest järgmine inimene, kes timeout'i silub, küsib.

Nimed, mis lahendatakse, kui ühendused veel ebaõnnestuvad

Lahendamine on üks kahest asjast, mida tunnel peab kandma; teine on tagasitee ja podi võrk varjab seda hästi. Kui OpenVPN server ise töötab podina, ei juhi sellesse konteinerisse lisatud reeglid liiklust, mis väljub sõlme kaudu. See tõrge on kitsas: vastuseid said ainult sõlme podid, mis käitasid ka serverit, ja kõik muu aegus.

Serveri käitamine hostNetwork: true-ga paneb selle tagasi sõlme nimeruumi, kus FORWARD reegel ja allika tõlkimine mõjuvad. Tõlkige kliendipool väljumisel või ei ole ühegi kaugsõlmel tagasiteed tunneliaadressile nagu 10.8.0.6. Kontrollige mõlemat suunda enne, kui Corefile'i uuesti puudutate. Tunnel, mis kannab päringut, kuid mitte vastust, tekitab täpselt sama timeout'i kui resolver, mis päringut kunagi ei saanud.

Kontrollige uuest podist, mitte sessioonist, mille parandasite

Küsige mõlemat tsooni selgesõnaliselt, seejärel korrake päringut pärast podi asendamist. Konfiguratsioon, mis eksisteerib ainult töötavas konteineris, ei ole konfiguratsioon:

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

Kui esimene paar vastab ja paar pärast asendamist mitte, on Corefile korras ja podi spetsifikatsioon mitte. Kui mõlemad vastavad ja rakendus ei saa ikka ühendust, lõpetage DNS-i silumine ja testige TCP-teed nc -vz db.svc.acme.internal 5432-ga konteineri seest. Hoidke dig-i väljund piletil, sest see on artefakt, mis eraldab nimeprobleemi marsruutimisprobleemist.

Seotud artiklid