Hvernig á að skipta DNS milli Kubernetes og OpenVPN-sidecars

Pod sem keyra OpenVPN sidecar mistakast í nafnaupplausn eftir þkkjanlegu munstri: nöfn klasans hanga, fjarnöfn svara þar til podið er endurræst, og uppflettiskráin sem þú breyttir fer aftur í fyrra horf. Ekkert í þeirri röð er bilun í göngunum. Pod hefur eina uppflettiskrá og tvo nafnaheima, og skráin getur talið upp netþjóna í röð en getur ekki tjáð svæði. Varanlega lausnin er uppfletting sem keyrir inni í podinu og á skiptinguna, svo skráin helst einföld og engin stefna hefur ástæðu til að endurskrifa hana.

Hvers vegna breytingin sem þú gerðir hverfur aftur og aftur

Skráin tilheyrir kubelet, ekki þér. Undir dnsPolicy: ClusterFirst býr kubelet hana til svo hún bendi á DNS klasans, og býr hana til aftur í hvert sinn sem geymir ræsist. Allt sem þú breytir í gegnum kubectl exec lifir í skrifanlega laginu geymisins, svo endurræsing, brottrekstur eða rollout henda henni. Podforskriftin ber enn sömu stefnuna, og þes vegna kemur sama skráin aftur.

Að setja dnsPolicy: None stöðvar endursköpunina og fjarlægir líka upplausn klasans. Þú færð skrá sem þú stjórnar og tapar nöfnunum sem þú þurftir. Þessi skipti eru allt vandamálið: resolv.conf þekkir ekki svæði, aðeins netþjóna sem á að prófa í röð, svo það getur ekki sent cluster.local á eitt vistfang og einkasvæði á annað.

Keyrðu eina uppflettingu í podinu, á loopback

Beindu podinu að einum nafnaþjóni á loopback, og leyfðu svo CoreDNS-geyminum sem deilir netnafnrými podsins að svara á porti 53. Stilltu stefnunni á None, gefðu podinu þetta eina vistfang, og bættu DNS-geyminum við hlið VPN og forritsins:

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

Öll þrjú geymirarnir deila einu netnafnrými, svo 127.0.0.1:53 frá forritsgeyminum nær CoreDNS án þjónustu, án port-forward og án krókaleiðar um net klasans. Að tengja Corefile frá ConfigMap heldur henni sem útgáfustýrðu inntaki í stað skrár sem er breytt á staðnum. Búna resolv.conf heldur þá einum nafnaþjóni og engu öðru, sem er ástand sem þú getur rökrætt um.

Tveir smáhlutir bíta hér. Opinbera myndin bindur port 53 sem root, og sumar klasastefnur krefjast þes að þú skrifir það skýrt. Sérhver geymir í podinu veltur nú á því að þessi eini geymir sé í gangi, svo bættu readiness-prófun við gagnvart meinlausu nafni og leyfðu forritinu að þola ræsingarbilanir.

Gefðu hverju einkasvæði sinn eigin upstream

Corefile er listi yfir svæði, hvert nefnir netþjóninn sem getur svarað því. Eitt blokk tekur yfir gangnasvæðið, og blokkin sem grípur allt kemur síðast og tekur allt sem engin skýr blokk krafðist. Blokkin sem grípur allt verður að miða á raunverulegt upstream, aldrei aftur á podið: .:53 { forward . 10.100.0.10 } endurnýtir uppflettingu klasans því hún sendir nú þegar opin nöfn á uppflettingar hnútsins sjálfs. Ekkert annað í podinu þarf að vita hvaða neti nafn tilheyrir.

.:53 {
  errors
  cache 30
  forward . 10.100.0.10
}

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

Lestu vistfang klasans af kube-dns-þjónustunni í kube-system í stað þes að afrita eitt úr grein, því CIDR þjónustunnar eru mismunandi. Vistfang gangnanna kemur frá dhcp-option DNS-gildinu sem OpenVPN-þjónninn ýtir, eða frá heimildarþjóninum fyrir það svæði. Ef uppfletting klasans svarar ekki opin nöfn, settu vistfang uppflettingar hnútsins í blokkina sem grípur allt, lesið á hnútnum og ekki inni í podinu.

Beindu ekki blokkinni sem grípur allt að /etc/resolv.conf, sem er freistandi ein lína og gildra í nákvæmlega þessari uppsetningu. Undir dnsPolicy: None inniheldur skrá podsins sjálfs eina nafnaþjóninn 127.0.0.1, svo það mark er CoreDNS sjálft og hver ósamsvarandi fyrirspurn endurtekur sig þar til tíminn rennur údt. Blokk sem heitir svc.acme.internal passar við það nafn og hvert nafn undir því, sem nær yfir db.svc.acme.internal og útilokar svc.acme.internal.example.net. Punkturinn í lokin er snyrtilegur, því nöfn svæða eru normaliseruð í fullgilt form; viðskeytamörkin ráða því hvar fyrirspurn lendir.

Ákveðu hvort framsendingin eigi heima í uppflettingu klasans

Ef hver vinnuálag í nafnrýminu þarf gangnasvæðið, er framsendingarblokk í CoreDNS ConfigMap undir kube-system ódýrari en sidecar á hvert pod. Þessi breyting er á skala klasans: hún krefst stjórnandarréttinda og endurræsingar á dreifingu sem allir velta á. Takmarkaðu hana við það eitt svæði, aldrei við rótina. Vistfang gangna eins vinnuálags verður þá uppfletting hvers pods fyrir svæðið, og daginn sem göngin falla tapar allur klasi nafninu.

Sidecar heldur sprengjuradíusnum inni í einu podi, sem er betra sjálfgefna gildið þeegar aðeins fá þjónustur þurfa fjarnetið. Hvað sem þú velur, skrifaðu niður hvaða uppfletting á svæðið, því næsta manneskja sem kembir timeout mun spyrja.

Nöfn sem leysast á meðan tengingar mistakast enn

Upplausn er annar tveggja hluta sem göngin verða að bera; hinn er bakleiðin, og net podsins felur hana vel. Ef OpenVPN-þjónninn sjálfur keyrir sem pod, stýra reglur sem þú bætir við í þéim geymi ekki umferð sem fer údt um hnútinn. Sú bilun er ýröng: aðeins pod á hnútnum sem einnig keyrði þjóninn fengu svör, og allt annað rann údt.

Að keyra þjóninn með hostNetwork: true setur hann aftur í nafnrými hnútsins, þar sem FORWARD-regla og þyðing uppruna virka. Þýddu biðlaraþungann á útleið, annars hefur enginn fjarlægur hnútur leið aftur að gangnavistfangi eins og 10.8.0.6. Athugaðu báðar áttir áður en þú snertir Corefile aftur. Göng sem bera fyrirspurnina en ekki svarið framleiða nákvæmlega sama timeout og uppfletting sem fékk aldrei fyrirspurnina.

Sannreyndu frá nýju podi, ekki frá lotunni sem þú lagaðir

Spyrðu skýrt um bæði svæðin, og endurtaktu svo fyrirspurnina eftir að podinu er skipt údt. Stilling sem er aðeins til í keyrandi geymi er ekki stilling:

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

Ef fyrsta parið svarar og parið eftir útskiptinguna ekki, er Corefile í lagi og podforskriftin ekki. Ef bæði svara og forritið nær samt ekki tengingu, hættu að kemba DNS og prófa TCP-leiðina með nc -vz db.svc.acme.internal 5432 innan úr geyminum. Geymdu dig-úttakið í miðanum, því það er gagnið sem aðgreinir nafnavandamál frá leiðavandamáli.