Yadda za a raba DNS tsakanin Kubernetes da OpenVPN sidecar

Pod ɗin da ke gudanar da OpenVPN sidecar suna kasa warware sunaye a cikin wani tsari da ake iya gane: sunayen cluster suna rataye, sunayen nesa suna amsa har sai an sake kunna pod ɗin, kuma fayil ɗin resolver da ka gyara yana komawa baya. Babu wani abu a cikin wannan jerin da ke zama laifin tunnel. Pod ɗin yana da fayil ɗin resolver ɗaya da duniyoyin suna biyu, kuma fayil ɗin zai iya lissafa sabar a jere amma ba zai iya bayyana yankuna ba. Maganin da zai daɗe shi ne resolver da ke gudana a cikin pod ɗin kuma ya mallaki rabon, don haka fayil ɗin ya kasance mai sauƙi kuma babu wata manufa da za ta sami dalilin sake rubuta shi.

Me ya sa gyaran da ka yi yake ci gaba da ɓacewa

Fayil ɗin na kubelet ne, ba naka ba. A ƙarƙashin dnsPolicy: ClusterFirst kubelet yana ƙirƙirar shi don ya nuna zuwa DNS na cluster, kuma yana sake ƙirƙirar sa duk lokacin da container ya fara. Duk abin da ka canza ta kubectl exec yana rayuwa a cikin layin da za a iya rubutawa na container, don haka sake kunnawa, fitarwa ko rollout yana jefar da shi. Takamaiman pod ɗin har yanzu yana ɗauke da wannan manufa, shi ya sa wannan fayil ɗin yake dawowa.

Sanya dnsPolicy: None yana dakatar da sake ƙirƙira kuma yana kuma cire warwarewar cluster. Kana samun fayil da kake sarrafawa kuma ka rasa sunayen da kake buƙata. Wannan musanya ita ce dukan matsalar: resolv.conf ba ya san yankuna, sai dai sabar da za a gwada a jere, don haka ba zai iya aika cluster.local zuwa adireshi ɗaya da yanki mai zaman kansa zuwa wani ba.

Gudanar da resolver ɗaya a cikin pod ɗin, a kan loopback

Nuna pod ɗin zuwa sabar suna ɗaya a kan loopback, sannan bar container ɗin CoreDNS da ke raba sararin sunan cibiyar sadarwar pod ɗin ya amsa a tashar 53. Sanya manufar zuwa None, ba pod ɗin wannan adireshin ɗaya, kuma ƙara container ɗin DNS gefen VPN da aikace-aikacen:

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

Dukan container ɗin uku suna raba sararin sunan cibiyar sadarwa ɗaya, don haka 127.0.0.1:53 daga container ɗin aikace-aikacen yana isa CoreDNS ba tare da sabis ba, ba tare da port-forward ba kuma ba tare da kewayawa ta cibiyar sadarwar cluster ba. Manna Corefile daga ConfigMap yana riƙe da shi a matsayin shigarwa mai sigar maimakon fayil da ake gyarawa a wurin. resolv.conf da aka ƙirƙira sannan yana riƙe da sabar suna ɗaya kuma babu wani abu, wanda yanayi ne da za ka iya yin tunani a kansa.

Cikakkun bayanai biyu suna ciji a nan. Hoton hukuma yana ɗaure tashar 53 a matsayin root, kuma wasu manufofin cluster suna tilasta ka rubuta hakan a fili. Kowane container a cikin pod ɗin yanzu ya dogara da kasancewar wannan container ɗaya a raye, don haka ƙara readiness probe a kan suna marar lahani kuma bar aikace-aikacen ya jure gazawar farawa.

Ba kowane yanki mai zaman kansa nasa upstream

Corefile jerin yankuna ne, kowanne yana ambaton sabar da za ta iya amsa shi. Blok ɗaya yana rufe yankin tunnel, kuma blok ɗin da ke kama komai yana zuwa ƙarshe kuma yana ɗaukar duk abin da babu wani blok bayyananne da ya yi da'awa. Blok ɗin da ke kama komai dole ya nufi ingantaccen upstream, ba zai taɓa komawa pod ɗin ba: .:53 { forward . 10.100.0.10 } yana sake amfani da resolver ɗin cluster domin wannan resolver ɗin yana riga ya tura sunayen jama'a zuwa resolver ɗin node ɗin kansa. Babu wani abu a cikin pod ɗin da ke buƙatar sanin wace cibiyar sadarwa suna yake.

.:53 {
  errors
  cache 30
  forward . 10.100.0.10
}

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

Karanta adireshin cluster daga sabis ɗin kube-dns a cikin kube-system maimakon kwafa ɗaya daga labarin, domin CIDR ɗin sabis sun bambanta. Adireshin tunnel yana zuwa daga ƙimar dhcp-option DNS da sabar OpenVPN ke turawa, ko daga sabar mai iko don wannan yankin. Idan resolver ɗin cluster ɗinka ba ya amsa sunayen jama'a, sanya adireshin resolver ɗin node a cikin blok ɗin da ke kama komai, wanda aka karanta a kan node ba a cikin pod ɗin ba.

Kada ka nuna blok ɗin da ke kama komai zuwa /etc/resolv.conf, wanda shi ne layi ɗaya mai jaraba kuma tarko a cikin wannan daidaitaccen saitin. A ƙarƙashin dnsPolicy: None fayil ɗin pod ɗin kansa yana ɗauke da sabar suna ɗaya 127.0.0.1, don haka wannan manufar ita ce CoreDNS kanta kuma kowace tambaya da ba ta dace ba tana maimaitawa har sai ta ƙare. Blok mai suna svc.acme.internal yana dacewa da wannan suna da kowane suna a ƙarƙashinsa, wanda ke rufe db.svc.acme.internal kuma ya ware svc.acme.internal.example.net. Digo na ƙarshe kawai na ado ne, domin ana daidaita sunayen yankuna zuwa cikakkiyar siffa; iyakar suffix ce ke yanke shawarar inda tambaya za ta faɗi.

Yanke shawara ko turawa ta kasance cikin resolver ɗin cluster

Idan kowane aiki a cikin namespace yana buƙatar yankin tunnel, blok ɗin turawa a cikin CoreDNS ConfigMap a ƙarƙashin kube-system ya fi arha fiye da sidecar ga kowane pod. Wannan canjin yana da matakin cluster: yana buƙatar haƙƙin mai gudanarwa da sake kunna deployment ɗin da kowa ya dogara da shi. Iyakance shi ga wannan yanki ɗaya, ba zuwa tushen ba. Adireshin tunnel ɗin aiki ɗaya sannan ya zama resolver ɗin kowane pod don yankin, kuma ranar da tunnel ɗin ya faɗi dukan cluster ɗin zai rasa sunan.

Sidecar ɗin yana riƙe da nisan fashewa a cikin pod ɗaya, wanda shine mafi kyawun tsoho lokacin da sabis kaɗan ne kawai ke buƙatar cibiyar sadarwar nesa. Duk abin da ka zaɓa, rubuta wane resolver ne ya mallaki yankin, domin mutum na gaba da zai gyara timeout zai tambaya.

Sunayen da ake warwarewa yayin da haɗin kai har yanzu yana kasawa

Warwarewa ɗaya ce daga cikin abubuwa biyu da tunnel ɗin dole ya ɗauka; ɗayan kuma ita ce hanyar dawowa, kuma cibiyar sadarwar pod tana ɓoye ta da kyau. Idan sabar OpenVPN kanta tana gudana a matsayin pod, dokokin da ka ƙara a cikin wannan container ba sa sarrafa zirga-zirgar da ke fita ta node ɗin. Wannan gazawar ƙunci ce: pod ɗin da ke kan node ɗin da kuma ke gudanar da sabar ne kawai suka sami amsoshi, kuma duk sauran sun ƙare.

Gudanar da sabar da hostNetwork: true yana mayar da ita cikin sararin sunan node ɗin, inda dokar FORWARD da fassarar tushe suke aiki. Fassara tafkin abokin ciniki a kan hanyar fita, in ba haka ba babu node mai nisa da ke da hanyar dawowa zuwa adireshin tunnel kamar 10.8.0.6. Duba duka biyun kafin ka sake taɓa Corefile. Tunnel ɗin da ke ɗaukar tambaya amma ba amsa yana haifar da daidai wannan timeout ɗin da resolver ɗin da bai taɓa karɓar tambayar ba.

Tabbatar daga sabon pod, ba daga zaman da ka gyara ba

Tambayi duka yankunan a fili, sannan sake maimaita tambayar bayan an maye gurbin pod ɗin. Tsarin da ke wanzu kawai a cikin container mai gudana ba tsari ba ne:

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

Idan biyun farko sun amsa kuma biyun bayan maye gurbin ba su amsa ba, Corefile ɗin yana da kyau kuma takamaiman pod ɗin ba haka ba. Idan duka biyun sun amsa kuma aikace-aikacen har yanzu ba zai iya haɗawa ba, daina gyara DNS kuma gwada hanyar TCP da nc -vz db.svc.acme.internal 5432 daga cikin container ɗin. Riƙe fitarwar dig a cikin tikit ɗin, domin ita ce kayan aikin da ke raba matsalar suna da matsalar hanya.