Si të ndash DNS-in midis Kubernetes dhe një sidecar-i OpenVPN

Pod-et që ekzekutojnë një sidecar OpenVPN dështojnë në zgjidhjen e emrave sipas një modeli të dallueshëm: emrat e cluster-it ngecin, emrat e largët përgjigjen derisa pod-i riniset, dhe skedari juaj i redaktuar i resolver-it kthehet mbrapsht. Asgjë në atë sekuencë nuk është defekt tuneli. Një pod ka një skedar resolver-i dhe dy botë emërtimi, dhe skedari mund t'i rendisë serverat me radhë, por nuk mund të shprehë zona. Rregullimi i qëndrueshëm është një resolver që ekzekutohet brenda pod-it dhe zotëron ndarjen, kështu që skedari mbetet i thjeshtë dhe asnjë politikë nuk ka arsye ta rishkruajë.

Pse redaktimi që bëtë vazhdon të zhduket

Skedari i përket kubelet-it, jo juve. Nën dnsPolicy: ClusterFirst kubelet-i e gjeneron për ta drejtuar te DNS-i i cluster-it dhe e rigjeneron sa herë që niset një kontejner. Çdo gjë që ndryshoni përmes kubectl exec jeton në shtresën e shkrueshme të kontejnerit, kështu që një rinisje, një eviktim ose një shpërndarje e hedh atë. Specifikimi i pod-it vazhdon të mbajë të njëjtën politikë, prandaj i njëjti skedar kthehet.

Vendosja e dnsPolicy: None ndalon rigjenerimin dhe gjithashtu heq zgjidhjen e cluster-it. Fitoni një skedar që e kontrolloni dhe humbni emrat që ju duheshin. Ky shkëmbim është i gjithë problemi: resolv.conf nuk ka nocion zonash, vetëm serverash për t'i provuar me radhë, kështu që nuk mund të dërgojë cluster.local te një adresë dhe një zonë private te një tjetër.

Ekzekutoni një resolver në pod, në loopback

Drejtojeni pod-in te një server i vetëm emrash në loopback, pastaj lëreni një kontejner CoreDNS që ndan hapësirën e emrave të rrjetit të pod-it të përgjigjet në portën 53. Vendosni politikën në None, jepini pod-it atë adresë të vetme dhe shtoni kontejnerin DNS pranë VPN-së dhe aplikacionit:

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

Të tre kontejnerët ndajnë një hapësirë emrash rrjeti, kështu që 127.0.0.1:53 nga kontejneri i aplikacionit arrin CoreDNS pa shërbim, pa port-forward dhe pa një devijim nëpër rrjetin e cluster-it. Montimi i Corefile-it nga një ConfigMap e mban atë një input të versionuar në vend të një skedari të redaktuar në vend. resolv.conf i gjeneruar mban pastaj një server të vetëm emrash dhe asgjë tjetër, që është një gjendje për të cilën mund të arsyetoni.

Dy detaje pickojnë këtu. Imazhi zyrtar lidh portën 53 si root, dhe disa politika cluster-i ju detyrojnë ta shkruani këtë shprehimisht. Çdo kontejner në pod tani varet nga fakti që ai kontejner i vetëm është lart, prandaj shtoni një provë gatishmërie ndaj një emri të padëmshëm dhe lëreni aplikacionin të tolerojë dështimet e nisjes.

Jepini secilës zonë private rrjedhën e vet të sipërme

Një Corefile është një listë zonash, secila emërton serverin që mund t'i përgjigjet. Një bllok mbulon zonën e tunelit, dhe kapësi i të gjithave vjen i fundit dhe merr gjithçka që asnjë bllok i shprehur nuk e kërkoi. Kapësi i të gjithave duhet të synojë një rrjedhë të sipërme reale, kurrë përsëri te pod-i: .:53 { forward . 10.100.0.10 } ripërdor resolver-in e cluster-it, sepse ai resolver tashmë i përcjell emrat publikë te resolver-ët e vetë nyjës. Asgjë tjetër në pod nuk ka nevojë të dijë se cilës rrjet i përket një emër.

.:53 {
  errors
  cache 30
  forward . 10.100.0.10
}

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

Lexojeni adresën e cluster-it nga shërbimi kube-dns në kube-system në vend që të kopjoni një nga një artikull, sepse CIDR-të e shërbimeve ndryshojnë. Adresa e tunelit vjen nga vlera dhcp-option DNS që shtyn serveri OpenVPN, ose nga serveri autoritativ për atë zonë. Nëse resolver-i i cluster-it tuaj nuk i përgjigjet emrave publikë, vendosni adresën e resolver-it të nyjës në kapësin e të gjithave, të lexuar në nyjë dhe jo brenda pod-it.

Mos e drejtoni kapësin e të gjithave te /etc/resolv.conf, që është një-rreshti joshës dhe një kurth në këtë konfigurim të saktë. Nën dnsPolicy: None skedari i vetë pod-it përmban serverin e vetëm të emrave 127.0.0.1, kështu që ai objektiv është vetë CoreDNS dhe çdo kërkesë e papërputhur përsëritet derisa të skadojë. Një bllok i quajtur svc.acme.internal përputhet me atë emër dhe çdo emër nën të, që mbulon db.svc.acme.internal dhe përjashton svc.acme.internal.example.net. Pika e fundit është kozmetike, sepse emrat e zonave normalizohen në formë plotësisht të kualifikuar; kufiri i prapashtesës është ai që vendos ku përfundon një kërkesë.

Vendosni nëse përcjellja i përket resolver-it të cluster-it

Nëse çdo ngarkesë pune në hapësirën e emrave ka nevojë për zonën e tunelit, një bllok përcjelljeje në ConfigMap-in e CoreDNS nën kube-system është më i lirë se një sidecar për pod. Ai ndryshim është në shkallë cluster-i: kërkon të drejta administratori dhe një rinisje të një vendosjeje nga e cila varen të gjithë. Kufizojeni atë te ajo zonë e vetme, kurrë te rrënja. Adresa e tunelit e një ngarkese të vetme pune bëhet pastaj resolver-i i çdo pod-i për zonën, dhe ditën që tuneli bie, i gjithë cluster-i humb emrin.

Sidecar-i e mban rrezen e shpërthimit brenda një pod-i, që është parazgjedhja më e mirë kur vetëm disa shërbime kanë nevojë për rrjetin e largët. Cilado qoftë zgjedhja, shkruani cili resolver e zotëron zonën, sepse personi i radhës që korrigjon një skadim do të pyesë.

Emra që zgjidhen ndërsa lidhjet ende dështojnë

Zgjidhja është një nga dy gjërat që tuneli duhet të mbajë; tjetra është rruga e kthimit, dhe rrjeti i pod-it e fsheh mirë. Nëse vetë serveri OpenVPN ekzekutohet si pod, rregullat që shtoni brenda atij kontejneri nuk qeverisin trafikun që del përmes nyjës. Ai dështim është i ngushtë: vetëm pod-et në nyjë që ekzekutonin gjithashtu serverin morën përgjigje, dhe gjithçka tjetër skadoi.

Ekzekutimi i serverit me hostNetwork: true e kthen atë në hapësirën e emrave të nyjës, ku një rregull FORWARD dhe përkthimi i burimit marrin efekt. Përktheni pishinën e klientëve në dalje, ose asnjë nyjë e largët nuk ka rrugë kthimi drejt një adrese tuneli si 10.8.0.6. Kontrolloni të dy drejtimet përpara se të prekni përsëri Corefile-in. Një tunel që mbart kërkesën dhe jo përgjigjen prodhon saktësisht të njëjtin skadim si një resolver që nuk e mori kurrë kërkesën.

Verifikoni nga një pod i ri, jo nga sesioni që rregulluat

Pyetni të dyja zonat shprehimisht, pastaj përsëritni kërkesën pasi pod-i të zëvendësohet. Konfigurimi që ekziston vetëm në një kontejner në punë nuk është konfigurim:

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

Nëse çifti i parë përgjigjet dhe çifti pas zëvendësimit jo, Corefile-i është në rregull dhe specifikimi i pod-it nuk është. Nëse të dy përgjigjen dhe aplikacioni ende nuk lidhet, ndaloni korrigjimin e DNS-së dhe provoni rrugën TCP me nc -vz db.svc.acme.internal 5432 nga brenda kontejnerit. Mbani daljen e dig në biletë, sepse është artefakti që ndan një problem emërtimi nga një problem rrugëtimi.