Kiel dividi DNS inter Kubernetes kaj OpenVPN-sidecar

Sidecar-podo bezonas du nomajn mondojn. Direktu unu loopback-risolvilon al la klastro kaj la tunelo, kaj ĉesu dependi de redaktita resolv.conf.

Podoj, kiuj funkciigas OpenVPN-sidecar, malsukcesas je nomadresado laŭ rekonebla ŝablono: klasteraj nomoj haltas, malproksimaj nomoj respondas ĝis la podo restartiĝas, kaj via redaktita risolvila dosiero revenas. Nenio en tiu sinsekvo estas tunela difekto. Podo havas unu risolvilan dosieron kaj du nomajn mondojn, kaj la dosiero povas listigi servilojn laŭ ordo sed ne povas esprimi zonojn. La daŭra solvo estas risolvilo, kiu funkcias ene de la podo kaj posedas la dividon, do la dosiero restas trivia kaj neniu politiko havas kialon reverki ĝin.

Kial la redakto, kiun vi faris, daŭre malaperas

La dosiero apartenas al kubelet, ne al vi. Sub dnsPolicy: ClusterFirst la kubelet generas ĝin por montri al la klastera DNS kaj regeneras ĝin ĉiufoje, kiam ujo startas. Ĉio, kion vi ŝanĝas per kubectl exec, vivas en la skribebla tavolo de la ujo, do restarto, forigo aŭ rollout forĵetas ĝin. La poda specifo ankoraŭ portas la saman politikon, kaj tial la sama dosiero revenas.

Agordi dnsPolicy: None haltigas la regeneradon kaj ankaŭ forigas la klasteran adresadon. Vi gajnas dosieron, kiun vi kontrolas, kaj perdas la nomojn, kiujn vi bezonis. Tiu interŝanĝo estas la tuta problemo: resolv.conf ne konas zonojn, nur servilojn provendajn laŭ ordo, do ĝi ne povas sendi cluster.local al unu adreso kaj privatan zonon al alia.

Funkciigu unu risolvilon en la podo, sur loopback

Direktu la podon al unu sola noma servilo sur loopback, poste lasu CoreDNS-ujon, kiu kunhavas la retan nomspacon de la podo, respondi sur pordo 53. Agordu la politikon al None, donu al la podo tiun unu adreson, kaj aldonu la DNS-ujon apud la VPN kaj la aplikaĵo:

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

Ĉiuj tri ujoj kunhavas unu retan nomspacon, do 127.0.0.1:53 el la aplikaĵa ujo atingas CoreDNS sen servo, sen port-forward kaj sen ĉirkaŭvojo tra la klastera reto. Munti la Corefile el ConfigMap tenas ĝin versiigita enigo anstataŭ dosiero redaktata surloke. La generita resolv.conf tiam tenas unu noman servilon kaj nenion alian, kio estas stato, pri kiu vi povas rezonadi.

Du detaloj mordas ĉi tie. La oficiala bildo ligas pordon 53 kiel root, kaj iuj klasteraj politikoj postulas, ke vi skribu tion eksplicite. Ĉiu ujo en la podo nun dependas de tio, ke tiu unu ujo funkcias, do aldonu pretecan sondadon kontraŭ sendanĝera nomo kaj lasu la aplikaĵon toleri startajn malsukcesojn.

Donu al ĉiu privata zono sian propran upstream

Corefile estas listo de zonoj, ĉiu nomas la servilon, kiu povas respondi al ĝi. Unu bloko kovras la tunelan zonon, kaj la bloko, kiu kaptas ĉion, venas laste kaj prenas ĉion, kion neniu eksplicita bloko postulis. La bloko, kiu kaptas ĉion, devas celi veran upstream, neniam reen al la podo: .:53 { forward . 10.100.0.10 } reuzas la klasteran risolvilon, ĉar tiu risolvilo jam plusendas publikajn nomojn al la risolviloj de la nodo mem. Nenio alia en la podo bezonas scii, al kiu reto nomo apartenas.

.:53 {
  errors
  cache 30
  forward . 10.100.0.10
}

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

Legu la klasteran adreson el la servo kube-dns en kube-system anstataŭ kopii unu el artikolo, ĉar servaj CIDR-oj malsamas. La tunela adreso venas el la valoro dhcp-option DNS, kiun puŝas la OpenVPN-servilo, aŭ el la aŭtoritata servilo por tiu zono. Se via klastera risolvilo ne respondas publikajn nomojn, metu la risolvilan adreson de la nodo en la blokon, kiu kaptas ĉion, legitan sur la nodo kaj ne ene de la podo.

Ne direktu la blokon, kiu kaptas ĉion, al /etc/resolv.conf, kio estas la alloga unulinia solvo kaj kaptilo en ĝuste ĉi tiu agordo. Sub dnsPolicy: None la dosiero de la podo mem enhavas la solan noman servilon 127.0.0.1, do tiu celo estas CoreDNS mem kaj ĉiu neakordigita demando rekursias ĝis ĝi tempolimas. Bloko nomita svc.acme.internal kongruas kun tiu nomo kaj ĉiu nomo sub ĝi, kio kovras db.svc.acme.internal kaj ekskludas svc.acme.internal.example.net. La fina punkto estas kosmetika, ĉar zonaj nomoj normaliĝas al plene kvalifikita formo; la sufiksa limo decidas, kie demando surteriĝas.

Decidu, ĉu la plusendo apartenas al la klastera risolvilo

Se ĉiu laborŝarĝo en la nomspaco bezonas la tunelan zonon, plusenda bloko en la CoreDNS ConfigMap sub kube-system estas pli malmultekosta ol sidecar po podo. Tiu ŝanĝo estas klaster-nivela: ĝi postulas administrajn rajtojn kaj restarton de deplojo, de kiu ĉiuj dependas. Limigu ĝin al tiu unu zono, neniam al la radiko. La tunela adreso de unu laborŝarĝo tiam fariĝas la risolvilo de ĉiu podo por la zono, kaj en la tago, kiam la tunelo falas, la tuta klastero perdas la nomon.

La sidecar tenas la eksplodradiuson ene de unu podo, kio estas la pli bona defaŭlto, kiam nur kelkaj servoj bezonas la malproksiman reton. Kion ajn vi elektas, skribu, kiu risolvilo posedas la zonon, ĉar la sekva persono, kiu sencimigos tempolimon, demandos.

Nomoj, kiuj adresiĝas dum konektoj ankoraŭ malsukcesas

Adresado estas unu el la du aferoj, kiujn la tunelo devas porti; la alia estas la revena vojo, kaj la poda reto bone kaŝas ĝin. Se la OpenVPN-servilo mem funkcias kiel podo, reguloj, kiujn vi aldonas en tiu ujo, ne regas trafikon, kiu eliras tra la nodo. Tiu malsukceso estas mallarĝa: nur podoj sur la nodo, kiu ankaŭ funkciigis la servilon, ricevis respondojn, kaj ĉio alia tempolimis.

Funkciigi la servilon kun hostNetwork: true metas ĝin reen en la nodan nomspacon, kie regulo FORWARD kaj fonta tradukado efikas. Traduku la klientan naĝejon sur la eliro, alie neniu malproksima nodo havas vojon reen al tunela adreso kiel 10.8.0.6. Kontrolu ambaŭ direktojn antaŭ ol vi denove tuŝi la Corefile. Tunelo, kiu portas la demandon kaj ne la respondon, produktas ĝuste la saman tempolimon kiel risolvilo, kiu neniam ricevis la demandon.

Kontrolu el nova podo, ne el la sesio, kiun vi riparis

Demandu eksplicite ambaŭ zonojn, poste ripetu la demandon post kiam la podo anstataŭiĝis. Agordo, kiu ekzistas nur en funkcianta ujo, ne estas agordo:

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

Se la unua paro respondas kaj la paro post la anstataŭigo ne, la Corefile estas en ordo kaj la poda specifo ne. Se ambaŭ respondas kaj la aplikaĵo ankoraŭ ne povas konekti, ĉesu sencimigi DNS kaj testu la TCP-vojon per nc -vz db.svc.acme.internal 5432 el interne de la ujo. Konservu la eligon de dig en la bileto, ĉar ĝi estas la artefakto, kiu apartigas nomproblemon de itinera problemo.

Rilataj artikoloj