Menggunakan kube-dns

Halaman ini menjelaskan cara Google Kubernetes Engine (GKE) mengimplementasikan penemuan layanan menggunakan kube-dns, penyedia DNS default untuk cluster GKE.

Untuk cluster Autopilot, Anda tidak dapat mengubah konfigurasi kube-dns default.

Arsitektur

Saat Anda membuat cluster, GKE akan otomatis men-deploy pod kube-dns dalam namespace kube-system. Pod mengakses deployment kube-dns melalui Service terkait, yang mengelompokkan pod kube-dns dan memberinya satu alamat IP (ClusterIP). Secara default, semua pod dalam cluster menggunakan Service ini untuk me-resolve kueri DNS. Diagram berikut menunjukkan hubungan antara pod dan Service kube-dns.

Hubungan Pod kube-dns dengan Service kube-dns

kube-dns melakukan penskalaan untuk memenuhi permintaan DNS cluster. Penskalaan ini dikontrol oleh kube-dns-autoscaler, Pod yang di-deploy secara default di semua cluster GKE. kube-dns-autoscaler menyesuaikan jumlah replika dalam Deployment kube-dns berdasarkan jumlah node dan core dalam cluster.

kube-dns mendukung hingga 1.000 endpoint per layanan headless.

Cara DNS Pod dikonfigurasi

Kubelet yang berjalan pada setiap Node mengonfigurasi etc/resolv.conf Pod untuk menggunakan ClusterIP layanan kube-dns. Contoh konfigurasi berikut menunjukkan bahwa alamat IP layanan kube-dns adalah 10.0.0.10. Alamat IP ini berbeda di cluster lain.

nameserver 10.0.0.10
search default.svc.cluster.local svc.cluster.local cluster.local c.my-project-id.internal google.internal
options ndots:5

kube-dns adalah server nama otoritatif untuk domain cluster (cluster.local) dan me-resolve nama eksternal secara rekursif. Nama pendek yang tidak sepenuhnya memenuhi syarat, seperti myservice, akan dilengkapi terlebih dahulu dengan jalur penelusuran lokal.

Menambahkan resolver kustom untuk domain stub

Anda dapat mengubah ConfigMap untuk kube-dns guna menetapkan domain stub sebagai bagian dari infrastruktur DNS dalam cluster Anda.

Domain stub memungkinkan Anda mengonfigurasi resolver per domain kustom, sehingga kube-dns meneruskan permintaan DNS ke server DNS upstream tertentu saat me-resolve domain ini.

Contoh manifes ConfigMap untuk kube-dns berikut mencakup konfigurasi stubDomains yang menetapkan resolver kustom untuk domain example.com.

apiVersion: v1
kind: ConfigMap
metadata:
  labels:
    addonmanager.kubernetes.io/mode: EnsureExists
  name: kube-dns
  namespace: kube-system
data:
  stubDomains: |
    {
      "example.com": [
        "8.8.8.8",
        "8.8.4.4",
        "1.1.1.1",
        "1.0.0.1"
      ]
    }

Jalankan perintah berikut untuk membuka editor teks:

kubectl edit configmap kube-dns -n kube-system

Ganti konten file dengan manifes, lalu keluar dari editor teks untuk menerapkan manifes ke cluster.

Server nama upstream

Jika Anda mengubah ConfigMap untuk kube-dns agar menyertakan upstreamNameservers, kube-dns akan meneruskan semua permintaan DNS kecuali *.cluster.local ke server tersebut. Ini mencakup metadata.internal dan *.google.internal, yang tidak dapat di-resolve oleh server upstream.

Jika Anda mengaktifkan Workload Identity Federation for GKE atau beban kerja apa pun yang mengandalkan resolusi metadata.internal, agar dapat mempertahankan resolusi nama *.internal, tambahkan stubDomain ke ConfigMap.

data:
  stubDomains: |
    {
      "internal": [
        "169.254.169.254"
      ]
    }
  upstreamNameservers: |
    ["8.8.8.8"]

Masalah umum

Batas domain penelusuran

Ada batas 6 domain penelusuran DNS untuk /etc/resolv.conf. Jika Anda menentukan lebih dari 6 domain penelusuran, peringatan berikut akan muncul saat Anda menjalankan perintah kubectl describe pod:

Search Line limits were exceeded, some search paths have been omitted, the applied search line is: default.svc.cluster.local svc.cluster.local cluster.local c.<project ID>.internal google.internal

Peringatan ini dicatat dalam Cloud Logging di bagian log container.

Untuk me-resolve masalah ini, hapus jalur penelusuran tambahan dari konfigurasi.

Pertimbangkan batas upstreamNameservers

Kubernetes memberlakukan batas hingga tiga nilai upstreamNameservers. Jika menentukan lebih dari tiga upstreamNameservers, Anda akan melihat error berikut pada Cloud Logging di log deployment kube-dns:

Invalid configuration: upstreamNameserver cannot have more than three entries (value was &TypeMeta{Kind:,APIVersion:,}), ignoring update

Jika hal ini terjadi, kube-dns akan berperilaku seolah-olah tidak ada upstreamNameservers yang dikonfigurasi. Untuk me-resolve masalah ini, hapus upstreamNameservers tambahan dari konfigurasi.

Batasan performa dengan kube-dns

Jika Anda mengalami latensi tinggi dengan pencarian DNS atau kegagalan resolusi DNS dengan penyedia kube-dns default, hal ini mungkin disebabkan oleh:

  • Sering melakukan pencarian DNS dalam beban kerja Anda
  • Men-deploy kepadatan Pod yang lebih tinggi per node.
  • Menjalankan kube-dns di Spot atau preemptible VM, yang dapat menyebabkan penghapusan node tidak terduga dan masalah resolusi DNS berikutnya.

Untuk mempercepat waktu pencarian DNS, Anda dapat memilih salah satu opsi berikut:

  • Hindari menjalankan komponen sistem penting seperti kube-dns di Spot atau preemptible VM. Penggunaan Spot atau preemptible VM untuk DNS dapat menyebabkan kegagalan dan mengganggu cluster Anda.
  • Sebagai praktik terbaik, buat minimal satu kumpulan node yang terdiri dari VM standar (non-Spot atau preemptible) untuk menghosting komponen sistem penting seperti kube-dns. Untuk memastikan bahwa beban kerja penting hanya dijadwalkan di kumpulan node yang andal sehingga tidak dapat berjalan di Spot atau preemptible VM, Anda dapat menggunakan taint dan toleransi untuk Spot VM.
  • Aktifkan NodeLocal DNSCache.
  • Tingkatkan skala kube-dns.
  • Pastikan aplikasi Anda menggunakan fungsi berbasis dns.resolve*, bukan fungsi berbasis dns.lookup karena dns.lookup bersifat sinkron. Fungsi dns.resolve* selalu melakukan kueri DNS asinkron di jaringan.

Data DNS layanan

kube-dns hanya membuat data DNS untuk Service yang memiliki Endpoint.

TTL besar dari server upstream DNS

Jika kube-dns menerima respons DNS dari DNS resolver upstream dengan TTL yang besar atau "tak terbatas", kube-dns akan menyimpan nilai TTL ini untuk entri DNS di dalam cache. Entri tidak akan pernah berakhir masa berlakunya dan dapat menimbulkan perbedaan antara entri dan alamat IP sebenarnya yang di-resolve untuk nama TTL.

GKE mengatasi masalah ini pada versi bidang kontrol berikut dengan menetapkan nilai TTL maksimum ke 30 detik untuk setiap respons DNS yang memiliki TTL lebih dari 30 detik:

  • 1.21.14-gke.9100
  • 1.22.15-gke.2100
  • 1.23.13-gke.500
  • 1.24.7-gke.500
  • 1.25.2-gke.500 atau yang lebih baru

Perilaku ini mirip dengan NodeLocal DNSCache.

Langkah selanjutnya