Dokumen ini membantu Anda memutuskan apakah Cloud DNS untuk GKE adalah solusi DNS yang tepat untuk cluster Anda. Anda dapat menggunakan Cloud DNS untuk menangani resolusi DNS Pod dan Service sebagai alternatif untuk penyedia DNS yang dihosting cluster seperti kube-dns.
Untuk cluster Autopilot, Cloud DNS sudah menjadi penyedia DNS default. Untuk cluster Standard, Anda dapat beralih dari kube-dns ke Cloud DNS.
Dokumen ini ditujukan untuk pengguna GKE, termasuk Developer, Admin, dan arsitek. Untuk mempelajari lebih lanjut peran umum dan contoh tugas di Google Cloud, lihat Peran dan tugas pengguna GKE Enterprise umum.
Dokumen ini mengasumsikan bahwa Anda sudah memahami konsep berikut:
Cara kerja Cloud DNS untuk GKE
Saat Anda menggunakan Cloud DNS sebagai penyedia DNS untuk GKE, Cloud DNS menyediakan resolusi DNS Pod dan Service tanpa memerlukan penyedia DNS yang dihosting cluster. Data DNS untuk Pod dan Service secara otomatis disediakan di Cloud DNS untuk alamat IP cluster, headless, dan Service nama eksternal.
Cloud DNS mendukung spesifikasi DNS Kubernetes lengkap dan menyediakan resolusi untuk data A, AAAA, SRV, dan PTR untuk Layanan dalam cluster GKE. Catatan PTR diimplementasikan dengan menggunakan aturan kebijakan respons. Menggunakan Cloud DNS sebagai penyedia DNS untuk GKE memberikan manfaat berikut dibandingkan DNS yang dihosting cluster:
- Mengurangi overhead: tidak perlu mengelola server DNS yang dihosting cluster. Cloud DNS tidak memerlukan penskalaan, pemantauan, atau pengelolaan instance DNS secara manual karena merupakan layanan terkelola sepenuhnya.
- Skalabilitas dan performa tinggi: menyelesaikan kueri secara lokal untuk setiap node GKE guna memberikan resolusi DNS berlatensi rendah dan sangat skalabel. Untuk performa yang optimal, terutama di cluster berskala besar, pertimbangkan untuk mengaktifkan NodeLocal DNSCache, yang menyediakan lapisan caching tambahan pada node.
- Integrasi dengan Google Cloud Observability: memungkinkan pemantauan dan logging DNS. Untuk mengetahui informasi selengkapnya, lihat Mengaktifkan dan menonaktifkan logging untuk zona terkelola pribadi.
Arsitektur
Jika Cloud DNS adalah penyedia DNS untuk GKE, pengontrol berjalan sebagai Pod yang dikelola GKE. Pod ini berjalan di node bidang kontrol cluster Anda dan menyinkronkan data DNS cluster ke zona DNS pribadi yang terkelola.
Diagram berikut menunjukkan cara bidang kontrol Cloud DNS dan bidang data menyelesaikan nama cluster:
Dalam diagram, backend Service memilih Pod backend yang sedang berjalan. clouddns-controller membuat data DNS untuk backend Layanan.
Frontend Pod mengirim permintaan DNS untuk menyelesaikan alamat IP Service bernama backend ke server metadata lokal Compute Engine di 169.254.169.254. Server metadata berjalan secara lokal di node, yang mengirimkan cache yang tidak ditemukan ke Cloud DNS.
Cloud DNS me-resolve nama Service ke alamat IP yang berbeda berdasarkan jenis Layanan Kubernetes. Untuk Layanan ClusterIP, Cloud DNS me-resolve nama Layanan ke alamat IP virtualnya; untuk Layanan headless, Cloud DNS me-resolve nama Layanan ke daftar alamat IP endpoint.
Setelah frontend Pod me-resolve alamat IP, Pod dapat mengirim traffic ke backend Service dan Pod apa pun di belakang Service.
Cakupan DNS
Cloud DNS memiliki cakupan DNS berikut. Cluster tidak dapat beroperasi dalam beberapa mode secara bersamaan.
- Cakupan cluster
GKE: Data DNS
hanya dapat di-resolve dalam cluster, yang merupakan perilaku yang sama dengan
kube-dns. Hanya node yang berjalan di cluster GKE yang dapat me-resolve nama Service. Secara default, cluster memiliki nama DNS yang diakhiri dengan*.cluster.local. Nama DNS ini hanya terlihat dalam cluster, dan tidak tumpang-tindih atau bertentangan dengan nama DNS*.cluster.localuntuk cluster GKE lainnya dalam project yang sama. Mode ini adalah mode default.- Cakupan VPC tambahan Cloud DNS: Cakupan VPC tambahan Cloud DNS adalah fitur opsional yang memperluas cakupan cluster GKE untuk membuat Service tanpa header dapat di-resolve dari resource lain di VPC, seperti VM Compute Engine atau klien lokal yang terhubung menggunakan Cloud VPN atau Cloud Interconnect. Mode ini adalah mode tambahan yang diaktifkan bersama cakupan cluster. Anda dapat mengaktifkan atau menonaktifkan mode ini di cluster Anda tanpa memengaruhi waktu aktif DNS atau kemampuan cakupan cluster.
- Cakupan VPC: Data DNS dapat di-resolve dalam seluruh VPC. VM Compute Engine dan klien lokal dapat terhubung menggunakan Cloud Interconnect atau Cloud VPN, dan dapat langsung me-resolve nama Service GKE. Anda harus menyetel domain kustom unik untuk setiap cluster, yang berarti bahwa semua data DNS Service dan Pod bersifat unik dalam VPC. Mode ini mengurangi hambatan komunikasi antara resource GKE dan non-GKE.
Tabel berikut mencantumkan perbedaan antara cakupan DNS:
| Fitur | Cakupan cluster GKE | Cakupan VPC tambahan Cloud DNS | Cakupan VPC |
|---|---|---|---|
| Cakupan visibilitas DNS | Hanya dalam cluster GKE | Khusus cluster, dengan Service headless yang dapat di-resolve di seluruh jaringan VPC | Seluruh jaringan VPC |
| Resolusi Layanan Headless | Dapat diselesaikan dalam cluster | Dapat di-resolve dalam cluster menggunakan domain `cluster.local`, dan di seluruh VPC menggunakan sufiks cluster | Dapat di-resolve dalam cluster dan di seluruh VPC dengan menggunakan akhiran cluster |
| Persyaratan domain unik | Tidak; menggunakan domain `*.cluster.local` default | Ya, Anda harus menetapkan domain kustom yang unik | Ya, Anda harus menetapkan domain kustom yang unik |
| Konfigurasi penyiapan | Default, tanpa langkah tambahan | Opsional saat pembuatan cluster Dapat diaktifkan atau dinonaktifkan kapan saja |
Harus dikonfigurasi selama pembuatan cluster |
Resource Cloud DNS
Saat Anda menggunakan Cloud DNS sebagai penyedia DNS untuk cluster GKE, pengontrol Cloud DNS membuat resource di Cloud DNS untuk project Anda. Resource yang dibuat GKE bergantung pada cakupan Cloud DNS.
| Cakupan | Zona pencarian maju | Zona pencarian balik |
|---|---|---|
| Cakupan cluster | 1 zona pribadi per cluster per zona Compute Engine (di region) | 1 zona kebijakan respons per cluster per zona Compute Engine (di region) |
| Cakupan VPC tambahan Cloud DNS | 1 zona pribadi per cluster per zona Compute Engine (di region) per cluster (zona global)
1 zona pribadi cakupan VPC per cluster (zona global) |
1 zona kebijakan respons per cluster per zona Compute Engine (di region) per cluster
(zona global)
1 zona kebijakan respons cakupan VPC per cluster (zona global) |
| Cakupan VPC | 1 zona pribadi per cluster (zona global) | 1 zona kebijakan respons per cluster (zona global) |
Konvensi penamaan yang digunakan untuk resource Cloud DNS ini adalah sebagai berikut:
| Cakupan | Zona pencarian maju | Zona pencarian balik |
|---|---|---|
| Cakupan cluster | gke-CLUSTER_NAME-CLUSTER_HASH-dns |
gke-CLUSTER_NAME-CLUSTER_HASH-rp |
| Cakupan VPC tambahan Cloud DNS | gke-CLUSTER_NAME-CLUSTER_HASH-dns
untuk zona cakupan cluster
gke-CLUSTER_NAME-CLUSTER_HASH-dns-vpc
untuk zona cakupan VPC
|
gke-CLUSTER_NAME-CLUSTER_HASH-rp
untuk zona cakupan cluster
gke-NETWORK_NAME_HASH-rp untuk
zona cakupan VPC |
| Cakupan VPC | gke-CLUSTER_NAME-CLUSTER_HASH-dns |
gke-NETWORK_NAME_HASH-rp |
Selain zona yang disebutkan dalam tabel sebelumnya, pengontrol Cloud DNS membuat zona berikut di project Anda, bergantung pada konfigurasi Anda:
| Konfigurasi DNS kustom | Jenis zona | Konvensi penamaan zona |
|---|---|---|
| Domain stub | Penerusan (zona global) | gke-CLUSTER_NAME-CLUSTER_HASH-DOMAIN_NAME_HASH |
| Server nama upstream kustom | Penerusan (zona global) | gke-CLUSTER_NAME-CLUSTER_HASH-upstream |
Untuk mengetahui informasi selengkapnya tentang cara membuat domain stub kustom atau server nama upstream kustom, lihat Menambahkan resolver kustom untuk domain stub.
Zona terkelola dan zona penerusan
Untuk cluster yang menggunakan cakupan cluster untuk melayani traffic DNS internal, pengontrol Cloud DNS membuat zona DNS terkelola di setiap zona Compute Engine dari region tempat cluster berada.
Misalnya, jika Anda men-deploy cluster di zona us-central1-c, pengontrol Cloud DNS akan membuat zona terkelola di us-central1-a, us-central1-b, us-central1-c, dan us-central1-f.
Untuk setiap stubDomain DNS, pengontrol Cloud DNS membuat satu zona penerusan.
Cloud DNS memproses setiap upstream DNS menggunakan satu zona terkelola dengan nama DNS ..
Kuota
Cloud DNS menggunakan kuota untuk membatasi jumlah resource yang dapat dibuat oleh GKE untuk entri DNS. Kuota dan batas untuk
Cloud DNS mungkin berbeda dengan batasan kube-dns
untuk project Anda.
Kuota default berikut diterapkan pada setiap zona terkelola di project Anda saat Anda menggunakan Cloud DNS untuk GKE:
| Resource DNS Kubernetes | Resource Cloud DNS yang sesuai | Kuota |
|---|---|---|
| Jumlah data DNS | Byte maks per zona terkelola | 2.000.000 (maks. 50 MB untuk zona terkelola) |
| Jumlah Pod per Service headless (IPv4 atau IPv6) | Jumlah data per kumpulan data resource | GKE 1.24 hingga 1.25: 1.000 (IPv4 atau IPv6) GKE 1.26 dan yang lebih baru: 3.500 untuk IPv4; 2.000 untuk IPv6 |
| Jumlah cluster GKE dalam sebuah project | Jumlah kebijakan respons per project | 100 |
| Jumlah data PTR per cluster | Jumlah aturan per kebijakan respons | 100.000 |
Batas resource
Resource Kubernetes yang Anda buat per cluster berkontribusi terhadap batas resource Cloud DNS, seperti dijelaskan dalam tabel berikut:
| Batas | Kontribusi terhadap batas |
|---|---|
| Kumpulan data resource per zona terkelola | Jumlah layanan ditambah jumlah endpoint layanan headless dengan nama host yang valid, per cluster. |
| Kumpulan data per kumpulan data resource | Jumlah endpoint per layanan headless. Tidak memengaruhi jenis layanan lainnya. |
| Jumlah aturan per kebijakan respons | Untuk cakupan cluster, jumlah layanan ditambah jumlah endpoint layanan headless dengan nama host yang valid per cluster. Untuk cakupan VPC, jumlah layanan ditambah jumlah endpoint headless dengan nama host dari semua cluster di VPC. |
Untuk mengetahui informasi selengkapnya tentang cara pembuatan data DNS untuk Kubernetes, lihat Penemuan Layanan Berbasis DNS Kubernetes.
Lebih dari satu cluster per project layanan
Mulai GKE versi 1.22.3-gke.700 dan 1.21.6-gke.1500, Anda dapat membuat cluster di beberapa project layanan yang mereferensikan VPC dalam project host yang sama.
Mendukung domain stub kustom dan server nama upstream
Cloud DNS untuk GKE mendukung domain stub kustom dan server nama upstream yang dikonfigurasi menggunakan kube-dns ConfigMap. Dukungan ini hanya tersedia untuk cluster GKE Standard.
Cloud DNS menerjemahkan nilai stubDomains dan upstreamNameservers menjadi zona penerusan Cloud DNS.
Ekstensi spesifikasi
Untuk meningkatkan penemuan layanan dan kompatibilitas dengan berbagai klien dan sistem, Anda dapat menggunakan tambahan di atas spesifikasi DNS Kubernetes umum.
Port bernama
Bagian ini menjelaskan pengaruh port bernama terhadap catatan DNS yang dibuat oleh Cloud DNS untuk cluster Kubernetes Anda. Kubernetes menentukan serangkaian minimum data DNS yang diperlukan, tetapi Cloud DNS dapat membuat data tambahan untuk operasinya sendiri dan untuk mendukung berbagai fitur Kubernetes. Tabel berikut menggambarkan jumlah minimum set data yang dapat Anda harapkan, dengan "E" mewakili jumlah endpoint, dan "P" mewakili jumlah port.
Cloud DNS dapat membuat data tambahan.
| IP stack type | Jenis layanan | Kumpulan data |
|---|---|---|
| Tumpukan tunggal | ClusterIP | $$2+P$$ |
| Headless | $$2+P+2E$$ |
|
| Dual stack | ClusterIP | $$3+P$$ |
| Headless | $$3+P+3E$$ |
|
| Lihat Layanan stack tunggal dan ganda untuk mengetahui informasi selengkapnya tentang layanan stack tunggal dan ganda. | ||
Data DNS tambahan yang dibuat oleh Cloud DNS
Cloud DNS dapat membuat data DNS tambahan di luar jumlah minimum kumpulan data. Data ini memiliki berbagai tujuan, termasuk:
- Data SRV: untuk penemuan layanan, Cloud DNS sering kali membuat data SRV. Catatan ini memberikan informasi tentang port dan protokol layanan.
- Data AAAA (untuk stack ganda): dalam konfigurasi stack ganda yang menggunakan IPv4 dan IPv6, Cloud DNS membuat data A (untuk IPv4) dan data AAAA (untuk IPv6) untuk setiap endpoint.
- Data internal: Cloud DNS dapat membuat data internal untuk pengelolaan dan pengoptimalannya sendiri. Biasanya, data ini tidak relevan secara langsung bagi pengguna.
- Layanan LoadBalancer: untuk layanan jenis
LoadBalancer, Cloud DNS membuat data yang terkait dengan alamat IP load balancer eksternal. - Layanan Headless: layanan headless memiliki konfigurasi DNS yang berbeda. Setiap Pod mendapatkan data DNS-nya sendiri, yang memungkinkan klien terhubung langsung ke Pod. Pendekatan ini adalah alasan mengapa nomor port tidak dikalikan dalam perhitungan record Service headless.
Contoh: Pertimbangkan Layanan yang disebut my-http-server dan berada di
namespace backend. Service ini mengekspos dua port, 80 dan 8080, untuk
deployment dengan tiga Pod. Jadi, E = 3 dan P = 2.
| IP stack type | Jenis layanan | Kumpulan data |
|---|---|---|
| Tumpukan tunggal | ClusterIP | $$2+2$$ |
| Headless | $$2+2+2*3$$ |
|
| Dual stack | ClusterIP | $$3+2$$ |
| Headless | $$3+2+3*3$$ |
Selain data minimum ini, Cloud DNS dapat membuat data SRV dan, dalam kasus jaringan dual-stack, data AAAA. Jika my-http-server adalah
Service jenis LoadBalancer, catatan tambahan untuk IP load balancer akan
dibuat. Catatan: Cloud DNS menambahkan data DNS tambahan sesuai kebutuhan. Catatan
spesifik yang dibuat bergantung pada faktor seperti jenis dan konfigurasi Layanan.
Masalah umum
Bagian ini menjelaskan masalah umum yang mungkin Anda alami saat menggunakan Cloud DNS dengan GKE, beserta kemungkinan solusinya.
Terraform mencoba membuat ulang cluster Autopilot karena perubahan dns_config
Jika menggunakan terraform-provider-google atau terraform-provider-google-beta, Anda mungkin mengalami masalah saat Terraform mencoba membuat ulang cluster Autopilot. Error ini terjadi karena cluster Autopilot yang baru dibuat dan menjalankan versi 1.25.9-gke.400, 1.26.4-gke.500, atau 1.27.1-gke.400 atau yang lebih baru menggunakan Cloud DNS sebagai penyedia DNS, bukan kube-dns.
Masalah ini di-resolve di penyedia Terraform Google Cloudversi 4.80.0.
Jika tidak dapat mengupdate versi terraform-provider-google atau
terraform-provider-google-beta, Anda dapat menambahkan setelan lifecycle.ignore_changes
ke resource untuk membantu memastikan bahwa google_container_cluster mengabaikan
perubahan pada dns_config:
lifecycle {
ignore_changes = [
dns_config,
]
}
Resolusi DNS gagal setelah bermigrasi dari kube-dns ke Cloud DNS dengan NodeLocal DNSCache diaktifkan
Bagian ini menjelaskan masalah umum untuk cluster GKE yang ada di Cloud DNS, dan yang telah mengaktifkan NodeLocal DNSCache dalam cakupan cluster.
Jika NodeLocal DNSCache diaktifkan di cluster dan Anda bermigrasi dari
kube-dns ke Cloud DNS, cluster Anda mungkin mengalami error resolusi
intermiten.
Jika Anda menggunakan kube-dns dengan NodeLocal DNSCache yang diaktifkan di cluster, NodeLocal DNSCache dikonfigurasi untuk memproses kedua alamat: alamat NodeLocal DNSCache dan alamat kube-dns.
Untuk memeriksa status NodeLocal DNSCache, jalankan perintah berikut:
kubectl get cm -n kube-system node-local-dns -o json | jq .data.Corefile -r | grep bind
Outputnya mirip dengan hal berikut ini:
bind 169.254.20.10 x.x.x.10
bind 169.254.20.10 x.x.x.10
Jika GKE Dataplane V2 diaktifkan di cluster dan cluster menggunakan kube-dns, NodeLocal DNSCache berjalan di jaringan terisolasi dan dikonfigurasi untuk memproses semua alamat IP Pod (0.0.0.0). Outputnya mirip dengan hal berikut ini:
bind 0.0.0.0
bind 0.0.0.0
Setelah cluster diupdate ke Cloud DNS, konfigurasi NodeLocal DNSCache akan diubah. Untuk memeriksa konfigurasi NodeLocal DNSCache, jalankan perintah berikut:
kubectl get cm -n kube-system node-local-dns -o json | jq .data.Corefile -r | grep bind
Outputnya mirip dengan hal berikut ini:
bind 169.254.20.10
bind 169.254.20.10
Alur kerja berikut menjelaskan entri dalam file resolv.conf sebelum dan sesudah migrasi serta pembuatan ulang node:
Sebelum migrasi
- Pod memiliki file
resolv.confyang dikonfigurasi ke alamat IPkube-dns(misalnya,x.x.x.10). - Pod NodeLocal DNSCache mencegat permintaan DNS dari Pod dan memproses permintaan berikut:
- (DPv1) kedua alamat (bind 169.254.20.10 x.x.x.10).
- (DPv2) semua alamat IP Pod (mengikat 0.0.0.0).
- NodeLocal DNSCache berfungsi sebagai cache dan beban minimal ditempatkan pada Pod
kube-dns.
Setelah migrasi
- Setelah bidang kontrol diupdate untuk menggunakan Cloud DNS, Pod masih memiliki file
resolv.confyang dikonfigurasi ke alamat IPkube-dns(misalnya,x.x.x.10). Pod mempertahankan konfigurasiresolv.confini hingga nodenya dibuat ulang. Jika Cloud DNS dengan NodeLocal DNSCache diaktifkan, Pod harus dikonfigurasi untuk menggunakan169.254.20.10sebagai server nama, tetapi perubahan ini hanya berlaku untuk Pod di node yang dibuat atau dibuat ulang setelah migrasi ke Cloud DNS. - Pod NodeLocal DNSCache hanya memproses alamat NodeLocal DNSCache (mengikat 169.254.20.10). Permintaan tidak ditujukan ke Pod NodeLocal DNSCache.
- Semua permintaan dari Pod dikirim langsung ke Pod
kube-dns. Penyiapan ini menghasilkan traffic tinggi di Pod.
Setelah pembuatan ulang node atau upgrade node pool
- Pod telah mengonfigurasi file
resolv.confuntuk menggunakan alamat IP NodeLocal DNSCache (169.254.20.10). - Pod NodeLocal DNSCache hanya memproses alamat NodeLocal DNSCache (mengikat 169.254.20.10) dan menerima permintaan DNS dari Pod pada alamat IP ini.
Jika node pool menggunakan alamat IP kube-dns dalam file resolv.conf sebelum node pool dibuat ulang, peningkatan traffic kueri DNS juga akan meningkatkan traffic pada Pod kube-dns. Peningkatan ini dapat menyebabkan kegagalan permintaan DNS secara berkala. Untuk meminimalkan error, Anda harus merencanakan migrasi ini selama periode nonaktif.