Kubernetes CoreDNS Sorun Giderme
Kubernetes ortaminda control plane uzerinde yasayan bircok pod ve servis sahibi oldugu yetkinliklerine gore aslinda bulundugu sunucuya bagimlidir.
Bu bagimliliga ornek verecek olursak bir calico podu network uzerinde node uzerinde bircok noktaya mudahale edebiliyor, ancak bu ozelligini SECCOMP uzerinden kapatirsak calico podlarimiz calismayabilir.
SECCOMP : Konteynir dedigimiz arkadaslarimizin kendi bulundugu ilgili IPC namespace uzerinden bulundugu sunucuda yapabilecegi syscallari kisitlamamizi saglayan bir Linux kernelde bulunan bir ozelliktir.
Yukarida sadece bu bagimliligi anlatmak icin bir ornek vermek istedim, bizim bu yazida inceleyecegimiz ana problem COREDNS ozelinde ve ornegimizden tamamen bagimsizdir .
Kubernetes ozelinde DNS
Ilk olarak bildigim ve uyguladigim kadariyla kubernetes uzerinde bir podun cluster disinda bir dns sorgusu attiginda nasil bir sorgu yapitigindan bahsedecegim.
Ilk olarak her DNS sorgulamak istediklerinde /etc/hosts dosyasinin altina bakar akabinde eger DNS /etc/hosts altinda bulamadigi zaman ise upstream bir dns sorgusunu kubernetes cored-dns’e yonlendiriyor .
Buradaki dns servisimiz eger ki cluster disi ise ve kaydi core-dns tarafinda cozulemez ise core-dns’in forward` ozelligi devreye girer
Yani ;
kubectl get configmap coredns -n kube-system -o yamlBu komut ciktisinda CoreFile kisminda karisimiza cikiyor ve forward ile /etc/resolv.conf altina route etmektedir . Loop plugin sayesinde bulundugu sunucu uzerindeki resolv.conf altindaki nameserver’a forward ediyor .
Corefile: |
.:53 {
errors
health {
lameduck 5s
}
ready
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
fallthrough in-addr.arpa ip6.arpa
ttl 30
}
prometheus :9153
forward . /etc/resolv.conf
loop
}Yani biz bir debian reposuna ya da external dns kaydina ulasmak istersek bu sekilde node uzerinden cikabiliyoruz.
CoreDNS ozelinde /etc/resolv.conf altinda bir local adresin yazmasi durumunda ise loop plugin sonsuz bir donguye giderek surekli kendisine bu dns sorgusunu yonlendirmekte.
Peki ya sorun neydi?
Sorunun ta kendisi benim coredns ‘i uzerinde konumlandirmis oldugum worker ile alakaliydi . Worker uzerinde bulunan /etc/resolv.conf ‘taki upstream dns server olarak 127.0.0.53`u barindiriyordu ki bu nedenle coredns podlarimi infinite loop’a girmekteydi.
Bu durumu cozebilmek icin sunucudaki /etc/resolv.conf`daki nameserver adresini degistirmemiz gerekiyordu .
Bunun icin iki yol var birincisi resolv.conf dosyasini geri dondurmemiz gerekiyor, resolvconf paketini silip tekrar yuklemek veya /run/resolvconf/resolv.conf dosyasini var olan /etc/resolv.conf`a icerik olarak guncellemek gerekiyor .
Benim kullandigim sunucuda ilk olarak 127.0.0.53 olarak belirtilen upstream dns server /run/resolvconf/resolv.conf altinda 172.’li bir internal dns adresi olarak belirtilmistir.
Yani, /etc/resolv.conf ile /run/resolvconf/resolv.conf arasinda bir link olmasi gerekiyor bu link olmasi gereken dosya ile degilse resolvconf ile veya link tekrardan yapilandirilmasi ile cozulebilir.
