Wéi DNS tëschent Kubernetes an engem OpenVPN-Sidecar opdeelen

E Sidecar-Pod brauch zwou Nummwelten. Richt een Loopback-Resolver op de Cluster an den Tunnel, a verlooss dech net méi op eng geännert resolv.conf.

Pods, déi e OpenVPN-Sidecar bedreiwen, versoen d'Nummaufléisung an engem erkennbare Muster: Clusternimm hänken, wäit Nimm äntweren, bis de Pod nei start, an deng geännert Resolver-Datei spréngt zréck. Nichts an dëser Sequenz ass en Tunneldefekt. E Pod huet eng Resolver-Datei an zwou Nummwelten, an d'Datei kann Serveren der Rei no oplëschten, awer keng Zone ausdrécken. Déi dauerhaft Léisung ass en Resolver, deen am Pod leeft an d'Aufdeelung besëtzt, sou datt d'Datei trivial bleift an keng Politik e Grond huet, se nei ze schreiwen.

Firwat déi Ännerung, déi Dir gemaach hutt, ëmmer erëm verschwënnt

D'Datei gehéiert dem kubelet, net dir. Ënner dnsPolicy: ClusterFirst generéiert de kubelet se, fir op den Cluster-DNS ze weisen, a generéiert se nei, ëmmer wann e Container start. Alles, wat Dir iwwer kubectl exec ännert, lieft an der schreiwbarer Schicht vum Container, also verwerfen en Neistart, eng Eviction oder e Rollout et. D'Pod-Spezifikatioun dréit nach ëmmer déiselwecht Politik, dofir kënnt déiselwecht Datei zréck.

dnsPolicy: None setzen hält d'Neigeneréierung op a läscht och d'Cluster-Aufléisung. Dir gewënnt eng Datei, déi Dir kontrolléiert, a verléiert d'Nimm, déi Dir gebraucht hutt. Dësen Tausch ass dat ganzt Problem: resolv.conf huet keng Ahnung vun Zonen, nëmme vu Serveren, déi der Rei no versicht ginn, also kann et cluster.local net op eng Adress schécken an eng privat Zone op eng aner.

Bedreift een Resolver am Pod, op Loopback

Richt de Pod op een eenzegen Numm-Server op Loopback, a loosst dann en CoreDNS-Container, deen den Netzwierk-Namensraum vum Pod deelt, op Port 53 äntweren. Setzt d'Politik op None, gitt dem Pod déi eenzeg Adress, a füügt den DNS-Container nieft dem VPN an der Applikatioun dobäi:

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

All dräi Container deelen een Netzwierk-Namensraum, also erreecht 127.0.0.1:53 aus dem Applikatiounscontainer den CoreDNS ouni Service, ouni Port-Forward an ouni Ëmwee iwwer d'Clusternetz. D'Corefile aus enger ConfigMap ze montéieren hält se als versionéierten Input amplaz vun enger Datei, déi op der Plaz geännert gëtt. Déi generéiert resolv.conf hält dann een Numm-Server an näischt anescht, een Zoustand, iwwer deen Dir kënnt nogrënnen.

Zwee Detailer bäissen hei. D'offiziell Image bindet Port 53 als root, an e puer Cluster-Politike verlaangen, datt Dir dat ausdrécklech schreift. All Container am Pod hänkt elo dovun of, datt deen een Container leeft, also füügt eng Readiness-Probe géint en harmlosen Numm dobäi a loosst d'Applikatioun Startfehler toleréieren.

Gitt all privater Zone hiren eegene Upstream

Eng Corefile ass eng Lëscht vun Zonen, all een nennt de Server, deen se beäntwere kann. Een Block deckt d'Tunnelzone of, an de Catch-all kënnt als Läschten an hëlt alles, wat keen explizitte Block reklaméiert huet. De Catch-all muss op en echte Upstream zielen, ni méi zréck op de Pod: .:53 { forward . 10.100.0.10 } benotzt de Cluster-Resolver erëm, well deen Resolver schonn ëffentlech Nimm un d'Resolver vum Node selwer weiderleet. Naischt anescht am Pod muss wëssen, zu wéi engem Netz en Numm gehéiert.

.:53 {
  errors
  cache 30
  forward . 10.100.0.10
}

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

Liest d'Clusteradress vum kube-dns-Service an kube-system, amplaz eng aus engem Artikel ze kopéieren, well d'Service-CIDRen ënnerschiddlech sinn. D'Tunneladress kënnt vum dhcp-option DNS-Wäert, deen den OpenVPN-Server schéckt, oder vum autoritative Server fir déi Zone. Wann ären Cluster-Resolver keng ëffentlech Nimm beäntwert, setzt d'Resolveradress vum Node an de Catch-all, gelies um Node an net am Pod.

Richt de Catch-all net op /etc/resolv.conf, dat ass den ugeleckten Een-Zeil an eng Falle an genau dëser Konfiguratioun. Ënner dnsPolicy: None enthält d'Datei vum Pod selwer den eenzegen Numm-Server 127.0.0.1, also ass dat Zil den CoreDNS selwer an all net passend Ufro rekurséiert, bis se ofleeft. En Block mam Numm svc.acme.internal passt op deen Numm an all Numm drënner, wat db.svc.acme.internal deckt an svc.acme.internal.example.net ausschléisst. Den Endpunkt ass kosmetesch, well Zonen-Nimm a vollqualifizéiert Form normaliséiert ginn; d'Suffix-Grenz entscheet, wou eng Ufro lant.

Entscheet, ob d'Weiderleedung an de Cluster-Resolver gehéiert

Wann all Workload am Namespace d'Tunnelzone brauch, ass e Weiderleedungsblock an der CoreDNS-ConfigMap ënner kube-system méi bëlleg wéi e Sidecar pro Pod. Déi Ännerung ass um Clusterniveau: se brauch Administrateursrechter an en Neistart vun engem Deployment, vun deem alleguer ofhänken. Begrenzt se op déi eng Zone, ni op d'Wuerzel. D'Tunneladress vun enger eenzeger Workload gëtt dann den Resolver vun all Pod fir d'Zone, an den Dag, wou den Tunnel fält, verléiert de ganzen Cluster den Numm.

De Sidecar hält de Sprengradius an engem Pod, wat den besseren Standard ass, wann nëmmen e puer Servicer dat wäit Netz brauchen. Wat Dir och wielt, schreift op, wéi en Resolver d'Zone besëtzt, well déi nächst Persoun, déi en Timeout debuggt, wäert froen.

Nimm, déi sech opléisen, während d'Verbindungen nach versoen

D'Aufléisung ass eng vun den zwou Saachen, déi den Tunnel muss droen; déi aner ass de Retourwee, an d'Pod-Netz verstoppt en gutt. Wann den OpenVPN-Server selwer als Pod leeft, regelen d'Reegelen, déi Dir an deem Container dobäisetzt, den Trafic net, deen iwwer den Node erausgeet. Dee Feeler ass schmuel: nëmmen d'Poden um Node, deen och de Server bedriwwen huet, kruten Äntwerten, an alles anescht ass ofgelaf.

De Server mat hostNetwork: true bedreiwen setzt en zréck an den Namensraum vum Node, wou eng FORWARD-Reegel an d'Quelltranslatioun wierken. Iwwersetzt de Clientpool beim Erausgoen, soss huet keen wäiten Node eng Route zréck op eng Tunneladress wéi 10.8.0.6. Iwwerpréift béid Richtungen, ier Dir d'Corefile erëm beréiert. En Tunnel, deen d'Ufro dréit an net d'Äntwert, produzéiert genau deeselwechten Timeout wéi en Resolver, deen d'Ufro ni kritt huet.

Iwwerpréift aus engem neie Pod, net aus der Sitzung, déi Dir reparéiert hutt

Frot béid Zone ausdrécklech, a widderhëlt dann d'Ufro, nodeems de Pod ersat gouf. Eng Konfiguratioun, déi nëmmen an engem lafenden Container existéiert, ass keng Konfiguratioun:

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

Wann dat éischt Paar äntwert an dat Paar no der Ersetzung net, ass d'Corefile an der Rei an d'Pod-Spezifikatioun net. Wann béid äntweren an d'Applikatioun sech nach ëmmer net verbannen kann, hällt op DNS ze debuggen a testt de TCP-Wee mam nc -vz db.svc.acme.internal 5432 vun bannen am Container. Halt de dig-Output am Ticket, well en dat Artefakt ass, deen e Nummproblem vun engem Routingproblem trennt.

Ähnlech Artikelen