Kif taqsam id-DNS bejn Kubernetes u sidecar OpenVPN

Pods li jmexxu sidecar OpenVPN jonqsu fir-riżoluzzjoni tal-ismijiet b'mudell rikonoxxibbli: l-ismijiet tal-cluster jiddendlu, l-ismijiet remoti jwieġbu sakemm il-pod jerġa' jinbeda, u l-fajl resolver li editjajt jerġa' lura. Xejn f'dik is-sekwenza mhu ħsara tat-tunnel. Pod għandu fajl resolver wieħed u żewġ dinjiet ta' ismijiet, u l-fajl jista' jelenka s-servers bl-ordni iżda ma jistax jesprimi żoni. Is-soluzzjoni dejjiema hija resolver li jaħdem ġewwa l-pod u jippossjedi d-diviżjoni, sabiex il-fajl jibqa' sempliċi u l-ebda politika ma għandha raġuni biex terġa' tiktebha.

Għaliex il-bidla li għamilt tisparixxi dejjem

Il-fajl huwa tal-kubelet, mhux tiegħek. Taħt dnsPolicy: ClusterFirst il-kubelet jiġġenerah biex jipponta lejn id-DNS tal-cluster, u jerġa' jiġġenerah kull darba li jinbeda kontenitur. Kull ma tbiddel permezz ta' kubectl exec jgħix fis-saff li jista' jinkiteb tal-kontenitur, għalhekk tħaddim mill-ġdid, tkeċċija jew rollout jarmuh. L-ispeċifikazzjoni tal-pod xorta għadha ġġorr l-istess politika, u għalhekk l-istess fajl jerġa' jiġi.

L-iffissar ta' dnsPolicy: None iwaqqaf il-ġenerazzjoni mill-ġdid u jneħħi wkoll ir-riżoluzzjoni tal-cluster. Ikollok fajl li tikkontrolla u titlef l-ismijiet li kellek bżonn. Dan l-iskambju huwa l-problema kollha: resolv.conf m'għandux kunċett ta' żoni, biss servers li għandhom jiġu ppruvati bl-ordni, għalhekk ma jistax jibgħat cluster.local lil indirizz wieħed u żona privata lil ieħor.

Ħaddem resolver wieħed fil-pod, fuq loopback

Ipponta l-pod lejn nameserver wieħed fuq loopback, imbagħad ħalli l-kontenitur CoreDNS li jaqsam l-ispazju tal-ismijiet tan-netwerk tal-pod iwieġeb fuq il-port 53. Issettja l-politika għal None, agħti lill-pod dak l-indirizz wieħed, u żid il-kontenitur DNS ħdejn il-VPN u l-applikazzjoni:

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

It-tliet kontenituri jaqsmu spazju wieħed tal-ismijiet tan-netwerk, għalhekk 127.0.0.1:53 mill-kontenitur tal-applikazzjoni jilħaq CoreDNS mingħajr servizz, mingħajr port-forward u mingħajr dawra minn ġol-netwerk tal-cluster. L-immuntar tal-Corefile minn ConfigMap iżommha bħala input verżjonat minflok fajl editjat fuq il-post. Il-resolv.conf iġġenerat imbagħad iżomm nameserver wieħed u xejn ieħor, stat li tista' tirraġuna dwaru.

Żewġ dettalji jigdim hawn. L-immaġni uffiċjali torbot il-port 53 bħala root, u xi politiki tal-cluster jitolbuk tikteb dan b'mod espliċitu. Kull kontenitur fil-pod issa jiddependi mill-fatt li dak il-kontenitur wieħed ikun għaddej, għalhekk żid readiness probe kontra isem bla ħsara u ħalli l-applikazzjoni tittollera l-fallimenti tal-bidu.

Agħti lil kull żona privata l-upstream tagħha

Corefile hija lista ta' żoni, kull waħda ssemmi s-server li jista' jwieġeb għaliha. Blokk wieħed ikopri ż-żona tat-tunnel, u l-blokka li taqbad kollox tiġi l-aħħar u tieħu kull ma l-ebda blokka espliċita ma talbet. Il-blokka li taqbad kollox trid tiffoka fuq upstream reali, qatt ma terġa' lura lejn il-pod: .:53 { forward . 10.100.0.10 } juża mill-ġdid ir-resolver tal-cluster għax dan diġà jgħaddi l-ismijiet pubbliċi lir-resolvers tan-nodu stess. Xejn ieħor fil-pod m'għandu bżonn ikun jaf liema netwerk isem jappartjeni għalih.

.:53 {
  errors
  cache 30
  forward . 10.100.0.10
}

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

Aqra l-indirizz tal-cluster mis-servizz kube-dns f'kube-system minflok ma tikkupjah minn artiklu, għax is-CIDRs tas-servizzi jvarjaw. L-indirizz tat-tunnel ġej mill-valur dhcp-option DNS li jtella' s-server OpenVPN, jew mis-server awtorevoli għal dik iż-żona. Jekk ir-resolver tal-cluster tiegħek ma jwieġibx ismijiet pubbliċi, poġġi l-indirizz tar-resolver tan-nodu fil-blokka li taqbad kollox, moqri fuq in-nodu u mhux fil-pod.

Tippontax il-blokka li taqbad kollox lejn /etc/resolv.conf, li hija l-linja waħda li tħajjar u nassa f'dan l-istess setup. Taħt dnsPolicy: None il-fajl tal-pod innifsu fih l-uniku nameserver 127.0.0.1, għalhekk dak il-mira huwa CoreDNS innifsu u kull query li ma taqbilx tirrepeti sakemm tiskadi. Blokka msejħa svc.acme.internal taqbel ma' dak l-isem u ma' kull isem taħtu, li tkopri db.svc.acme.internal u teskludi svc.acme.internal.example.net. Il-punt fl-aħħar huwa kosmetiku, għax l-ismijiet taż-żoni jiġu normalizzati għal forma kompletament kwalifikata; il-konfini tas-suffiss jiddeċiedi fejn tinżel query.

Iddeċiedi jekk il-forwarding huwiex tar-resolver tal-cluster

Jekk kull workload fl-ispazju tal-ismijiet jeħtieġ iż-żona tat-tunnel, blokka ta' forwarding fil-ConfigMap ta' CoreDNS taħt kube-system tiswa inqas minn sidecar għal kull pod. Dik il-bidla hija fil-livell tal-cluster: teħtieġ drittijiet ta' amministratur u tħaddim mill-ġdid ta' deployment li kulħadd jiddependi fuqu. Illimitalha għal dik iż-żona waħda, qatt għall-għerq. L-indirizz tat-tunnel ta' workload wieħed imbagħad isir ir-resolver ta' kull pod għaż-żona, u fil-jum li jaqa' t-tunnel il-cluster kollu jitlef l-isem.

Is-sidecar iżomm ir-raġġ tal-isplużjoni fil-pod wieħed, li huwa l-aħjar default meta ftit servizzi biss jeħtieġu n-netwerk remot. X'ikun li tagżel, innota liema resolver jippossjedi ż-żona, għax il-persuna li jmiss li tiddibaggja timeout se tistaqsi.

Ismijiet li jiġu riżolti waqt li l-konnessjonijiet għadhom ifallu

Ir-riżoluzzjoni hija waħda miż-żewg affarijiet li t-tunnel irid iġorr; l-oħra hija it-triq lura, u n-netwerk tal-pod jaħbiha tajjeb. Jekk is-server OpenVPN innifsu jaħdem bħala pod, ir-regoli li żżid f'dak il-kontenitur ma jikkontrollawx it-traffiku li joħroġ min-nodu. Dak il-falliment huwa dejjaq: biss il-pods fuq in-nodu li ħaddem ukoll is-server kisbu tweġibiet, u kull ħaġa oħra skadiet.

It-tħaddim tas-server b'hostNetwork: true iġib lura fl-ispazju tal-ismijiet tan-nodu, fejn regola FORWARD u t-traduzzjoni tas-sors jaħdmu. Ittraduċi l-pool tal-klijenti meta toħroġ, inkella l-ebda nod remot m'għandu rotta lura lejn indirizz tat-tunnel bħal 10.8.0.6. Iċċekkja ż-żewg direzzjonijiet qabel ma terġa' tmiss il-Corefile. Tunnel li jġorr il-query u mhux it-tweġiba jipproduċi eżattament l-istess timeout bħal resolver li qatt ma rċieva l-query.

Ivverifika minn pod ġdid, mhux mis-sessjoni li ssewwejt

Staqsi liż-żewg żoni b'mod espliċitu, imbagħad erġa' għamel il-query wara li l-pod jinbidel. Konfigurazzjoni li teżisti biss f'kontenitur li qed jaħdem mhijiex konfigurazzjoni:

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

Jekk l-ewwel par iwieġeb u l-par wara s-sostituzzjoni le, il-Corefile hija sew u l-ispeċifikazzjoni tal-pod mhijiex. Jekk it-tnejn iwieġbu u l-applikazzjoni xorta ma tistax tikkonnettja, waqqaf id-debug tad-DNS u pprova t-triq TCP b'nc -vz db.svc.acme.internal 5432 minn ġewwa l-kontenitur. Żomm l-output ta' dig fit-ticket, għax dak huwa l-artefatt li jifrid il-problema tal-ismijiet mill-problema tar-routing.