Nola banatu DNSa Kubernetes eta OpenVPN sidecar baten artean

OpenVPN sidecar bat exekutatzen duten podek izen-ebazpena modu ezagugarri batean huts egiten dute: kluster-izenak blokeatu egiten dira, urruneko izek pod-a berrabiarazi arte erantzuten dute, eta zuk editatutako resolver fitxategiak atzera egiten du. Segida horretan ez dago tunelaren akatsik. Pod batek resolver fitxategi bat eta bi izendatze-mundu ditu, eta fitxategiak zerbitzariak ordenan zerrendatu ditzake, baina ezin ditu zonak adierazi. Konponbide iraunkorra pod-aren barruan exekutatzen den eta banaketa bere gain hartzen duen resolver bat da, fitxategia soila izan dadin eta inolako politikak ez dezan berridazteko arrazoirik.

Zergatik desagertzen da egindako edizioa behin eta berriz

Fitxategia kubelet-ena da, ez zurea. dnsPolicy: ClusterFirst-en pean kubelet-ek kluster DNS-era bideratzeko sortzen du, eta edukiontzi bat abiatzen den bakoitzean birsortzen du. kubectl exec bidez aldatzen duzun guztia edukiontziaren idazteko geruzan bizi da, beraz berrabiarazte batek, kanporatze batek edo rollout batek baztertu egiten du. Pod-aren zehaztapenak politika bera darama oraindik, horregatik itzultzen da fitxategi bera.

dnsPolicy: None ezartzeak birsortzea gelditzen du eta kluster-ebazpena ere kentzen du. Kontrolatzen duzun fitxategi bat irabazten duzu eta behar zenituen izenak galtzen dituzu. Truke hori da arazo osoa: resolv.conf-k ez du zona kontzepturik, ordenan probatzeko zerbitzariak baino ez, beraz ezin du cluster.local helbide batera eta zona pribatu bat bestera bidali.

Exekutatu resolver bat pod-aren barruan, loopbackean

Pod-a loopbackeko izen-zerbitzari bakar batera bideratu, gero pod-aren sare-namespacea partekatzen duen CoreDNS edukiontzi batek 53 portuan erantzun dezan utzi. Politika None ezarri, pod-ari helbide bakarra eman, eta DNS edukiontzia VPNaren eta aplikazioaren ondoan gehitu:

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

Hiru edukiontziek sare-namespace bakarra partekatzen dute, beraz aplikazioaren edukiontziko 127.0.0.1:53 CoreDNS-ra iristen da zerbitzurik, port-forwardik eta kluster-sarearen ingurubiderik gabe. Corefile ConfigMap batetik muntatzeak bertsiodun sarrera bihurtzen du, tokian bertan editatutako fitxategi izan beharrean. Sortutako resolv.conf-k izen-zerbitzari bakarra eta beste ezer ez du gordetzen, arrazoitu daitekeen egoera bat.

Bi xehetasunek hemen hozka egiten dute. Irudi ofizialak 53 portua root gisa lotzen du, eta kluster-politika batzuek hori espresuki idaztera behartzen zaituzte. Podeko edukiontzi guztiek edukiontzi hori martxan egotearen mende daude orain, beraz, prestasun-proba bat gehitu izen kaltegabe baten aurka eta utzi aplikazioari abio-hutsegiteak onartzen.

Eman zona pribatu bakoitzari bere upstream propioa

Corefile bat zonez osatutako zerrenda da, bakoitzak erantzun dezakeen zerbitzaria izendatzen du. Bloke batek tunel-zona hartzen du, eta dena hartzen duen blokea azkena dator eta bloke espliziturik jaso ez duen guztia hartzen du. Dena hartzen duen blokeak benetako upstream batera begiratu behar du, inoiz ez pod-era: .:53 { forward . 10.100.0.10 } kluster-resolverra berrerabiltzen du, resolver horrek jada izen publikoak nodoaren resolverretara birbidaltzen baititu. Podeko beste ezerk ez du jakin behar izen bat zein sareri dagokion.

.:53 {
  errors
  cache 30
  forward . 10.100.0.10
}

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

Kluster-helbidea kube-system-ko kube-dns zerbitzutik irakurri, artikulu batetik kopiatu beharrean, zerbitzu-CIDRak desberdinak baitira. Tunel-helbidea OpenVPN zerbitzariak bidaltzen duen dhcp-option DNS baliotik dator, edo zona horretako zerbitzari autoritatiotik. Zure kluster-resolverrak izen publikoei erantzuten ez badie, jarri nodoaren resolver helbidea dena hartzen duen blokean, nodoan irakurrita eta ez pod-aren barruan.

Ez bideratu dena hartzen duen blokea /etc/resolv.conf-ra, hori da tentagarria den lerro bakarrekoa eta eraketa zehatz honetan tranpa bat. dnsPolicy: None-en pean pod-aren fitxategiak 127.0.0.1 izen-zerbitzari bakarra dauka, beraz helburu hori CoreDNS bera da eta bat ez datozen kontsulta guztiak errepikatu egiten dira denbora-muga arte. svc.acme.internal izeneko blokea izen horri eta haren azpiko izen guztiei dagokie, db.svc.acme.internal estaltzen du eta svc.acme.internal.example.net baztertzen du. Amaierako puntua kosmetikoa da, zona-izenak forma guztiz kualifikatura normalizatzen baitira; atzizki-muga da kontsulta non lurreratzen den erabakitzen duena.

Erabaki birbidalketa kluster-resolverrean dagokion

Namespaceko karga-lan guztiek tunel-zona behar badute, kube-system-peko CoreDNS ConfigMap-en birbidalketa-bloke bat pod bakoitzeko sidecar bat baino merkeagoa da. Aldaketa hori kluster mailakoa da: administratzaile-eskubideak eta denek menpe duten deployment baten berrabiaraztea behar ditu. Mugatu zona horretara, inoiz ez errora. Karga-lan bakar baten tunel-helbidea pode bakoitzaren resolver bihurtzen da orduan zonarako, eta tunela erortzen den egunean kluster osoak izena galtzen du.

Sidecarrak leherketa-erradioa pod baten barruan mantentzen du, eta hori da lehenetsi hobea zerbitzu gutxi batzuek soilik urruneko sarea behar dutenean. Zein aukeratu ere, idatzi zein resolverren den zona, denbora-muga bat arazten duen hurrengo pertsonak galdetuko baitu.

Konexioek huts egiten duten bitartean ebazten diren izenak

Ebazpena tunelak eraman behar duen bi gauzetako bat da; bestea itzulera-bidea da, eta pod-sareak ondo ezkutatzen du. OpenVPN zerbitzaria bera pod gisa exekutatzen bada, edukiontzi horren barruan gehitzen dituzun arauek ez dute nodotik ateratzen den trafikoa gobernatzen. Hutsegite hori estua da: zerbitzaria ere exekutatzen zuen nodoko pod-ek bakarrik jaso zituzten erantzunak, eta gainerako guztiek denbora-muga izan zuten.

Zerbitzaria hostNetwork: true-ekin exekutatzeak nodoaren namespace-ra itzultzen du, eta han FORWARD arau batek eta iturriaren itzulpenak eragiten dute. Itzuli bezero-poola irteeran, edo urruneko nodo batek ere ez du atzeraerroterik 10.8.0.6 bezalako tunel-helbide batera. Egiaztatu bi noranzkoak Corefile-a berriro ukitu aurretik. Kontsulta eramaten duen baina erantzuna eramaten ez duen tunelak kontsulta inoiz jaso ez zuen resolverrak adina denbora-muga sortzen du.

Egiaztatu pod berri batetik, konpondu zenuen saiotik ez

Galdetu bi zonen berariaz, eta gero errepikatu kontsulta pod-a ordezkatu ondoren. Edukiontzi batean bakarrik bizi den konfigurazioa ez da konfigurazioa:

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

Lehen pareak erantzuten badu eta ordezkapenaren ondorengo pareak ez, Corefile-a ondo dago eta pod-aren zehaztapena ez. Biek erantzuten badute eta aplikazioak oraindik konektatzen ez badu, utzi DNSa arazten eta probatu TCP bidea nc -vz db.svc.acme.internal 5432 erabiliz edukiontziaren barruan. Gorde dig-en irteera txartelean, izendatze-arazo bat bideratze-arazotik bereizten duen artefaktua baita.