Not. tercüme: Kubernetes'te DNS sorunu veya daha doğrusu parametre ayarları ndots, şaşırtıcı derecede popüler ve şimdiden . Bu konuyla ilgili başka bir notta, Hindistan'daki büyük bir komisyonculuk şirketinden DevOps mühendisi olan yazarı, Kubernetes'i çalıştıran meslektaşlarının bilmesinin nelerin yararlı olduğu hakkında çok basit ve özlü bir şekilde konuşuyor.
Uygulamaları Kubernetes'te dağıtmanın temel faydalarından biri sorunsuz uygulama keşfidir. Hizmet konsepti sayesinde küme içi etkileşim büyük ölçüde basitleştirilmiştir (), bir dizi kapsül IP adresini destekleyen sanal bir IP'dir. Örneğin, eğer hizmet vanilla servisle iletişime geçmek istiyor chocolateiçin sanal IP'ye doğrudan erişebilir. chocolate. Şu soru ortaya çıkıyor: Bu durumda DNS talebini kim çözecek? chocolate ve nasıl?
DNS ad çözümlemesi bir Kubernetes kümesinde kullanılarak yapılandırılır. . Kubelet, dosyalarda ad sunucusu olarak CoreDNS'li bir bölmeyi kaydeder /etc/resolv.conf tüm kapsüller. İçeriğe bakarsanız /etc/resolv.conf herhangi bir bölme, şunun gibi görünecektir:
search hello.svc.cluster.local svc.cluster.local cluster.local
nameserver 10.152.183.10
options ndots:5
Bu yapılandırma, DNS istemcileri tarafından istekleri DNS sunucusuna iletmek için kullanılır. Dosyada resolv.conf aşağıdaki bilgileri içerir:
- nameserverın: DNS isteklerinin gönderileceği sunucu. Bizim durumumuzda bu CoreDNS hizmetinin adresidir;
- arama: Belirli bir etki alanı için arama yolunu tanımlar. İlginçtir ki
google.comveyamrkaran.devFQDN değil (). Çoğu DNS çözümleyicinin izlediği standart kurala göre, yalnızca kök bölgeyi temsil eden nokta "." ile bitenler tam nitelikli (FDQN) etki alanları olarak kabul edilir. Bazı çözümleyiciler kendileri bir nokta ekleyebilir. Böylece,mrkaran.dev.tam nitelikli alan adıdır (FQDN) vemrkaran.dev- HAYIR; - noktalar: En ilginç parametre (bu makale bununla ilgilidir).
ndotsbir istek adının "tam nitelikli" bir alan adı olarak kabul edilmesinden önceki eşik nokta sayısını belirtir. DNS arama sırasını analiz ettiğimizde bu konu hakkında daha sonra daha fazla konuşacağız.
Bakalım sorduğumuzda ne olacak? mrkaran.dev bölmede:
$ nslookup mrkaran.dev
Server: 10.152.183.10
Address: 10.152.183.10#53
Non-authoritative answer:
Name: mrkaran.dev
Address: 157.230.35.153
Name: mrkaran.dev
Address: 2400:6180:0:d1::519:6001
Bu deneme için CoreDNS günlük kaydı düzeyini şuna ayarladım: all (bu da onu oldukça ayrıntılı hale getirir). Pod'un günlüklerine bakalım coredns:
[INFO] 10.1.28.1:35998 - 11131 "A IN mrkaran.dev.hello.svc.cluster.local. udp 53 false 512" NXDOMAIN qr,aa,rd 146 0.000263728s
[INFO] 10.1.28.1:34040 - 36853 "A IN mrkaran.dev.svc.cluster.local. udp 47 false 512" NXDOMAIN qr,aa,rd 140 0.000214201s
[INFO] 10.1.28.1:33468 - 29482 "A IN mrkaran.dev.cluster.local. udp 43 false 512" NXDOMAIN qr,aa,rd 136 0.000156107s
[INFO] 10.1.28.1:58471 - 45814 "A IN mrkaran.dev. udp 29 false 512" NOERROR qr,rd,ra 56 0.110263459s
[INFO] 10.1.28.1:54800 - 2463 "AAAA IN mrkaran.dev. udp 29 false 512" NOERROR qr,rd,ra 68 0.145091744sVay be. Burada iki şey dikkatinizi çekiyor:
- İstek, yanıt kodu içerene kadar aramanın tüm aşamalarından geçer.
NOERROR(DNS istemcileri bunu anlar ve sonuç olarak saklar).NXDOMAINVerilen alan adı için herhangi bir kayıt bulunmadığı anlamına gelir. Çünkümrkaran.devbir FQDN adı değildir (görendots=5), çözümleyici arama yoluna bakar ve isteklerin sırasını belirler; - Yazılar
АиААААparalel olarak geliyoruz. Gerçek şu ki, tek seferlik istekler/etc/resolv.confVarsayılan olarak, IPv4 ve IPv6 protokolleri kullanılarak paralel aramalar gerçekleştirilecek şekilde yapılandırılmışlardır. Seçeneği ekleyerek bu davranışı iptal edebilirsiniz.single-requestвresolv.conf.
Not: glibc bu istekleri sırayla gönderecek şekilde yapılandırılabilir ve musl - hayır, bu nedenle Alpine kullanıcılarının bunu dikkate alması gerekir.
Ndot'larla denemeler yapmak
Biraz daha deneyelim ndots ve bu parametrenin nasıl davrandığını görelim. Fikir basit: ndots DNS istemcisinin etki alanını mutlak mı yoksa göreceli olarak mı ele alacağını belirler. Örneğin, basit bir Google DNS istemcisi söz konusu olduğunda, bu alan adının mutlak olup olmadığını nasıl bilebilir? Eğer ayarlarsan ndots 1'e eşitse müşteri şunu söyleyecektir: "Ah, google tek bir nokta yok; Sanırım tüm arama listesini gözden geçireceğim. Ancak sorarsanız google.comİstenen ad eşiği karşıladığından sonek listesi tamamen yok sayılacak ndots (en az bir nokta var).
Şundan emin olalım:
$ cat /etc/resolv.conf
options ndots:1
$ nslookup mrkaran
Server: 10.152.183.10
Address: 10.152.183.10#53
** server can't find mrkaran: NXDOMAINCoreDNS günlükleri:
[INFO] 10.1.28.1:52495 - 2606 "A IN mrkaran.hello.svc.cluster.local. udp 49 false 512" NXDOMAIN qr,aa,rd 142 0.000524939s
[INFO] 10.1.28.1:59287 - 57522 "A IN mrkaran.svc.cluster.local. udp 43 false 512" NXDOMAIN qr,aa,rd 136 0.000368277s
[INFO] 10.1.28.1:53086 - 4863 "A IN mrkaran.cluster.local. udp 39 false 512" NXDOMAIN qr,aa,rd 132 0.000355344s
[INFO] 10.1.28.1:56863 - 41678 "A IN mrkaran. udp 25 false 512" NXDOMAIN qr,rd,ra 100 0.034629206s
Beri mrkaran tek bir nokta yok, arama tüm ek listesi üzerinden gerçekleştirildi.
Not: pratikte maksimum değer ndots 15 ile sınırlı; Kubernetes'te varsayılan olarak 5'tir.
Üretimde uygulama
Bir uygulama çok sayıda harici ağ çağrısı yapıyorsa, ad çözümlemesi birçok gereksiz sorguya neden olduğundan (sistem doğru olana ulaşmadan önce) DNS etkin trafik durumunda bir darboğaz haline gelebilir. Uygulamalar genellikle alan adlarına kök bölge eklemez ancak bu bir hack gibi görünmektedir. Yani sormak yerine api.twitter.com, sabit kod yazabilirsiniz api.twitter.com. (noktalı) uygulamada, DNS istemcilerinin doğrudan mutlak etki alanında yetkili aramalar gerçekleştirmesini ister.
Ek olarak Kubernetes sürüm 1.14'ten itibaren uzantılar dnsConfig и dnsPolicy istikrarlı durum aldı. Böylece bir kapsülü dağıtırken değeri azaltabilirsiniz. ndots3'e kadar (ve hatta 1'e kadar!). Bu nedenle, bir düğüm içindeki her mesajın tam etki alanını içermesi gerekecektir. Bu, performans ve taşınabilirlik arasında seçim yapmak zorunda kaldığınızda yaptığınız klasik değiş-tokuşlardan biridir. Bana öyle geliyor ki, DNS sonuçları da dahili olarak önbelleğe alındığından, yalnızca ultra düşük gecikme süresi uygulamanız için hayati önem taşıyorsa bu konuda endişelenmeniz gerekir.
referanslar
Bu özelliği ilk kez şurada öğrendim 25 Ocak'ta düzenlendi. Diğer şeylerin yanı sıra bu sorun hakkında da bir tartışma vardı.
Daha fazla araştırma için bazı bağlantılar:
- , Kubernetes'te neden ndots=5;
- nddot'ları değiştirmenin uygulama performansını nasıl etkilediği;
- Musl ve glibc çözümleyicileri arasında.
Not: Kullanmamayı seçtim dig Bu makalede. dig otomatik olarak bir nokta (kök bölge tanımlayıcısı) ekleyerek etki alanını "tam nitelikli" (FQDN) yapar, hayır önce arama listesinde çalıştırarak. Bu konuda şunu yazdı: . Ancak genel olarak standart davranış için ayrı bir bayrağın belirtilmesi oldukça şaşırtıcıdır.
Mutlu DNS'ler! Sonra görüşürüz!
çevirmenden PS
Blogumuzda da okuyun:
- «";
- «";
- "Kubernetes'te Ağ Oluşturmaya Yönelik Resimli Bir Kılavuz": , .
Kaynak: habr.com