Rekonsiliasi DNS Active Directory dan Kubernetes dalam penyebaran Kluster Big Data
Artikel ini menjelaskan beberapa tantangan dan solusi untuk mengakomodasi integrasi Direktori Aktif saat menyebarkan Kluster Big Data.
Penting
Add-on Kluster Big Data Microsoft SQL Server 2019 akan dihentikan. Dukungan untuk Kluster Big Data SQL Server 2019 akan berakhir pada 28 Februari 2025. Semua pengguna SQL Server 2019 yang ada dengan Jaminan Perangkat Lunak akan didukung penuh pada platform dan perangkat lunak akan terus dipertahankan melalui pembaruan kumulatif SQL Server hingga saat itu. Untuk informasi selengkapnya, lihat posting blog pengumuman dan opsi Big data di platform Microsoft SQL Server.
Gambaran Umum
Ketika kluster big data tidak disebarkan dengan integrasi Direktori Aktif, kami mengandalkan layanan Kubernetes CoreDNS untuk resolusi DNS internal. Kubernetes menggunakan domain internal seperti <namespace>.svc.cluster.local. Ini membuat catatan A (pencarian maju) dan PTR (pencarian terbalik) di server DNS dengan nama di domain ini.
Namun, ketika mode Direktori Aktif diaktifkan, domain baru masuk ke gambar dengan sekumpulan server DNS-nya sendiri. Selama resolusi nama internal, ini dapat mengakibatkan kebingungan di mana set server DNS yang akan dituju untuk pencarian maju dan terbalik.
Tantangan
- Ketika pod Kubernetes baru disebarkan, entri DNS perlu ditambahkan di kedua set server DNS. Kubernetes mengurus perekaman entri di CoreDNS-nya, namun, alur kerja penyebaran BDC bertanggung jawab untuk menambahkan entri yang diperlukan di server DNS Pengendali Domain Direktori Aktif. Demikian pula, ketika kluster big data dihapus, alur kerja harus memastikan entri ini dihapus.
- Server DNS Direktori Aktif berada di luar kluster Kubernetes. Tetapi BDC memiliki ruang IP sendiri di dalam Kubernetes dan tidak dapat membuat rekaman untuk ruang IP ini di server DNS yang terletak secara eksternal karena ruang IP ini tidak terlihat di luar batas kluster.
- Ketika peristiwa failover terjadi dalam kluster Kubernetes, rekaman di server DNS AD juga harus diperbarui.
- Selain nama pod, nama layanan Kubernetes juga harus dapat diatasi melalui pencarian nama domain AD. Ini menciptakan tantangan tambahan di DNS Direktori Aktif karena satu nama layanan dapat dipetakan ke beberapa alamat IP pod.
- Mencatat propagasi pembaruan dan penundaan replikasi di server DNS Direktori Aktif organisasi bisa signifikan dan di luar kendali alur kerja manajemen BDC. Ini dapat berdampak pada fungsionalitas BDC segera setelah penyebaran dan failover. Sebaliknya, Kubernetes CoreDNS lebih cepat dan efisien karena lokalitasnya.
Solusi
Untuk mengatasi tantangan tersebut, solusi yang diterapkan di BDC melibatkan layanan CoreDNS internal baru yang dikelola di dalam namespace layanan BDC. Ini adalah satu-satunya layanan DNS yang akan dijangkau pod di namespace BDC untuk resolusi nama. Kompleksitas beberapa domain tersembunyi di balik layanan CoreDNS baru.
Misalnya, dalam diagram berikut pod menggunakan server BDC CoreDNS untuk mengatasi nama. Pod tidak berinteraksi langsung dengan server Kubernetes CoreDNS atau Server DNS AD.
Berikut adalah beberapa detail implementasi yang mengklarifikasi cara kerja desain ini di BDC:
Manajemen terpusat dari beberapa domain
Kompleksitas apa yang terjadi pada pencarian nama tetap tersembunyi di belakang layanan DNS internal dengan cara terpusat. Ini menghindari beban mengelola beberapa domain ke pod individu dan menyederhanakan desain.
Tidak ada rekaman untuk pod internal di server DNS eksternal
Akibat prinsip desain ini, BDC tidak perlu membuat dan mengelola catatan A dan PTR untuk pod di ruang IP Kubernetes di server DNS eksternal.
Tidak ada duplikasi rekaman
Rekaman DNS internal di beberapa tempat. Satu-satunya penyimpanan untuk rekaman ini adalah Kubernetes CoreDNS. CoreDNS internal BDC akan melakukan penulisan ulang komputasi dan penerusan kueri DNS ke Kubernetes CoreDNS.
Penulisan ulang komputasi
Karena BDC tidak menyimpan catatan apa pun, BDC bertanggung jawab atas terjemahan kueri pencarian maju yang masuk dengan nama yang memiliki domain AD ke nama dengan domain Kubernetes, dan meneruskan kueri ini ke Kubernetes CoreDNS.
Sebagai contoh, kueri masuk untuk compute-0-0.contoso.local akan ditulis compute-0-0.compute-0-svc.contoso.svc.cluster.local ulang dan permintaan ini akan diteruskan ke Kubernetes CoreDNS.
Dalam kasus pencarian terbalik, permintaan diteruskan dengan IP internal apa adanya ke Kubernetes CoreDNS, dan menulis ulang respons dari sana ke nama domain AD sebelum merespons klien.
Kesederhanaan dalam konfigurasi pod
Karena hanya BDC CoreDNS internal yang direferensikan dalam /etc/resolv.conf dari semua pod BDC, ini menyederhanakan tampilan jaringan dari pod. Kompleksitas akan disembunyikan di CoreDNS internal sebagai gantinya.
Alamat IP Statis dan Andal untuk Layanan DNS
Layanan CoreDNS yang disebarkan BDC, akan memiliki IP internal statis terdaftar yang dapat diakses dari semua pod. Ini akan memastikan bahwa nilai dalam /etc/resolv.conf tidak perlu diperbarui.
Manajemen keseimbangan beban layanan dipertahankan oleh Kubernetes
Ketika pencarian terjadi untuk layanan alih-alih pod individual, mereka masih akan pergi ke Kubernetes CoreDNS, sehingga BDC tidak bertanggung jawab untuk menerapkan penyeimbangan beban khusus untuk domain AD.
Sebagai contoh, jika permintaan pencarian maju datang untuk compute-0-svc.contoso.local, permintaan tersebut akan ditulis ulang ke.local compute-0-svc.contoso.svc.cluster. Permintaan ini akan diteruskan ke Kubernetes CoreDNS dan penyeimbangan beban akan terjadi di sana. Respons akan menjadi alamat IP untuk salah satu dari beberapa instans kumpulan komputasi (replika pod).
Skalabilitas
Karena BDC tidak menyimpan catatan apa pun, BDC CoreDNS internal dapat diskalakan tanpa retensi status dan replikasi rekaman di beberapa replika. Jika rekaman DNS akan disimpan dalam BDC, mereplikasi status di semua pod juga harus diurus BDC.
Entri layanan yang terlihat secara eksternal tetap berada di AD DNS
Untuk titik akhir layanan yang perlu dapat diakses oleh klien di luar kluster Kubernetes, entri DNS akan dibuat di server DNS AD saat BDC sedang disebarkan. Pengguna akan memasukkan nama DNS untuk mendaftar melalui profil konfigurasi penyebaran.
Deprovisi mandiri
Setelah BDC dihapus, tidak ada pekerjaan dinamis tambahan untuk menghapus entri DNS saat kluster sedang dideprovisi. Satu-satunya entri dalam DNS Direktori Aktif jarak jauh yang perlu dibersihkan adalah untuk layanan eksternal dan berjumlah statis. Entri DNS internal akan secara otomatis dihapus dengan kluster.