Kubernetes klasteri ilə OpenVPN sidecar arasında DNS-i necə bölmək olar

OpenVPN sidecar-ı işlədən podlarda ad həlli tanınan bir şəkildə uğursuz olur: klaster adları donur, uzaq adlar pod yenidən başlayana qədər cavab verir və redaktə etdiyiniz həlledici faylı geri qayıdır. Bu ardıcıllıqda heç nə tunel nasazlığı deyil. Podun bir həlledici faylı və iki adlandırma dünyası var, fayl serverləri sıra ilə sala bilər, amma zonaları ifadə edə bilməz. Davamlı həll podun içində işləyən və bölgünü idarə edən bir həllədicidir, beləliklə fayl sadə qalır və heç bir siyasətin onu yenidən yazmağa səbəbi olmur.

Redaktə etdiyiniz dəyişiklik niyə yox olmaqda davam edir

Fayl sizə deyil, kubelet-ə aiddir. dnsPolicy: ClusterFirst altında kubelet onu klaster DNS-inə yönəltmək üçün yaradır və hər konteyner başlayanda yenidən yaradır. kubectl exec vasitəsilə dəyişdirdiyiniz hər şey konteynerin yazıla bilən qatında yaşayır, ona görə yenidən başlama, çıxarılma və ya yayım onu silir. Pod spesifikasiyası hələ də eyni siyasəti daşıyır, buna görə eyni fayl geri qayıdır.

dnsPolicy: None təyini yenidən yaratmanı dayandırır və klaster həllini də silir. Nəzarət etdiyiniz bir fayl qazanır, lazım olan adları itirirsiniz. Bu mübadilə bütün problemdir: resolv.conf zonalar anlayışına malik deyil, yalnız sıra ilə sınanacaq serverlərə malikdir, ona görə cluster.local dəyərini bir ünvana, xüsusi zonanı isə digərinə göndərə bilməz.

Podun içində, loopback üzərində bir həlledici işlədin

Pod-u loopback üzərində tək bir ad serverinə yönəldin, sonra podun şəbəkə ad məkanını paylaşan CoreDNS konteynerinin 53 portunda cavab verməsinə icazə verin. Siyasəti None olaraq təyin edin, poda həmin tək ünvanı verin və DNS konteynerini VPN və tətbiqin yanına əlavə edin:

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

Üç konteyner də bir şəbəkə ad məkanını paylaşır, ona görə tətbiq konteynerindən 127.0.0.1:53 CoreDNS-ə xidmətsiz, port-forward-suz və klaster şəbəkəsindən yan yol olmadan çatır. Corefile-ı ConfigMap-dən montaj etmək onu yerində redaktə edilən fayl deyil, versiyalı giriş kimi saxlayır. Yaranan resolv.conf sonra tək bir ad serveri və başqa heç nə saxlamır, bu da üzərində düşünə biləcəyiniz bir vəziyyətdir.

Burada iki incəlik var. Rəsmi imic 53 portunu root kimi bağlayır və bəzi klaster siyasətləri bunu açıq şəkildə yazmağı tələb edir. Poddakı hər konteyner indi həmin bir konteynerin işləməsindən asılıdır, ona görə zərərsiz bir ada qarşı hazırlıq yoxlaması əlavə edin və tətbiqin başlama uğursuzluqlarına dözməsinə icazə verin.

Hər xüsusi zonaya öz yuxarı axınını verin

Corefile zonaların siyahısıdır, hər biri ona cavab verə bilən serveri adlandırır. Bir blok tunel zonasını əhatə edir, hər şeyi tutan blok isə sonuncu gəlir və heç bir açıq blokun iddia etmədiyi hər şeyi götürür. Hər şeyi tutan blok real yuxarı axına yönəlməlidir, heç vaxt poda qayıtmamalıdır: .:53 { forward . 10.100.0.10 } klaster həllədicisini təkrar istifadə edir, çünki o həllədici artıq ictimai adları düyünün öz həllədicilərinə ötürür. Poddakı başqa heç nəyin adın hansı şəbəkəyə aid olduğunu bilməsinə ehtiyac yoxdur.

.:53 {
  errors
  cache 30
  forward . 10.100.0.10
}

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

Klaster ünvanını məqalədən kopyalamaq əvəzinə kube-system içindəki kube-dns xidmətindən oxuyun, çünki xidmət CIDR-ləri fərqlidir. Tunel ünvanı OpenVPN serverinin göndərdiyi dhcp-option DNS dəyərindən və ya həmin zona üçün səlahiyyətli serverdən gəlir. Klaster həllədiciiniz ictimai adlara cavab vermirsə, hər şeyi tutan bloka düyünün həllədici ünvanını qoyun, onu düyündə oxuyun, podun içində deyil.

Hər şeyi tutan bloku /etc/resolv.conf-a yönəltməyin, bu cazibədar bir sətirlik həlldir və məhz bu qurmada tələdir. dnsPolicy: None altında podun öz faylı tək ad serverini, 127.0.0.1, ehtiva edir, ona görə həmin hədəf CoreDNS-in özüdür və uyğun gəlməyən hər sorğu vaxt aşımına qədər təkrarlanır. svc.acme.internal adlı blok həmin ada və onun altındakı hər ada uyğun gəlir, bu da db.svc.acme.internal-i əhatə edir və svc.acme.internal.example.net-u istisna edir. Sondakı nöqtə kosmetikdir, çünki zona adları tam kvalifikasiyalı formaya normallaşdırılır; şəkilçi sərhədi sorğunun hara düşdüyünü müəyyən edir.

Yönləndirmənin klaster həllədicisinə aid olub-olmadığını qərar verin

Ad məkanındakı hər iş yükü tunel zonasına ehtiyac duyursa, kube-system altındakı CoreDNS ConfigMap-də yönləndirmə bloku hər pod üçün sidecar-dan daha ucuzdur. Bu dəyişiklik klaster miqyaslıdır: administrator hüquqları və hamının asılı olduğu yerləşdirmənin yenidən başladılması tələb olunur. Onu yalnız həmin zonaya məhdudlaşdırın, heç vaxt kökə yox. Tək bir iş yükünün tunel ünvanı sonra zona üçün hər podun həllədicisinə çevrilir və tunel düşdüyü gün bütün klaster adı itirir.

Sidecar partlayış radiusunu bir podun içində saxlayır, bu yalnız bir neçə xidmətin uzaq şəbəkəyə ehtiyac duyduğu halda daha yaxşı susmudur. Hansını seçsəniz də, zonanın hansı həllədiciyə aid olduğunu yazın, çünki vaxt aşımını sazlayan növbəti şəxs soruşacaq.

Bağlantılar hələ uğursuz olarkən həll olunan adlar

Həll tunelin daşımalı olduğu iki şeydən biridir; digəri geri dönüş yoludur və pod şəbəkəsi onu yaxşı gizlədir. OpenVPN serverinin özü pod kimi işləyirsə, həmin konteynerin içində əlavə etdiyiniz qaydalar düyündən çıxan trafiki idarə etmir. Bu uğursuzluq dardır: yalnız serveri də işlədən düyündəki podlar cavab aldı, qalan hər şey vaxt aşımına uğradı.

Serveri hostNetwork: true ilə işlətmək onu düyün ad məkanına qaytarır, burada FORWARD qaydası və mənbə tərcüməsi qüvvəyə minir. Çıxışda müştəri hovuzunu tərcümə edin, əks halda heç bir uzaq düyünün 10.8.0.6 kimi tunel ünvanına geri marşrutu olmur. Corefile-a yenidən toxunmadan əvvəl hər iki istiqaməti yoxlayın. Sorğunu daşıyan, cavabı daşımayan tunel, sorğunu heç vaxt almayan həllədici ilə tam eyni vaxt aşımı yaradır.

Yeni poddan yoxlayın, düzəltdiyiniz sessiyadan deyil

Hər iki zonanı açıq şəkildə soruşun, sonra pod dəyişdirildikdən sonra sorğunu təkrarlayın. Yalnız işləyən konteynerdə mövcud olan konfiqurasiya konfiqurasiya deyil:

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

Birinci cüt cavab verirsə və dəyişdirmədən sonrakı cüt vermirsə, Corefile qaydasındadır, pod spesifikasiyası deyil. Hər ikisi cavab verirsə və tətbiq hələ də qoşula bilmirsə, DNS ayarlarını dayandırın və konteynerin içindən nc -vz db.svc.acme.internal 5432 ilə TCP yolunu sınayın. dig çıxışını biletdə saxlayın, çünki bu, adlandırma problemini marşrut probleminə ayıran artefaktdır.