Container Service for Kubernetes:Kebijakan resolusi dan caching DNS

Skenario 1: Aplikasi berbasis host (non-kontainer)

Aplikasi yang berjalan langsung di instans Elastic Compute Service (ECS) menggunakan /etc/resolv.conf host, yang mengarah ke server DNS VPC.

Skenario 2: Pod kontainer standar (dnsPolicy: ClusterFirst)

Secara default, pod menggunakan kebijakan ClusterFirst. Semua kueri DNS dialihkan ke layanan CoreDNS dalam kluster.

Skenario 3: Pod dengan NodeLocal DNSCache diaktifkan

Saat NodeLocal DNSCache aktif, pod mengirim kueri ke agen caching lokal pada node yang sama. Hal ini memberikan dua manfaat:

• Latensi berkurang: Kueri DNS diselesaikan secara lokal, melewati hop jaringan ke CoreDNS.

• Perlindungan tabel conntrack: Kueri dikirim ke agen lokal tanpa membuat entri baru pada tabel conntrack, sehingga mengurangi kondisi balapan conntrack dan mencegah entri DNS UDP menghabiskan kapasitas tabel conntrack.

Sisi klien

Parameter berikut berasal dari /etc/resolv.conf dan diinterpretasikan oleh resolver glibc. Berikut adalah konfigurasi representatif untuk pod standar yang menggunakan ClusterFirst:

nameserver 10.x.x.x          # CoreDNS ClusterIP
search default.svc.cluster.local svc.cluster.local cluster.local
options ndots:5 timeout:5 attempts:2

Tabel berikut mencantumkan nilai default di semua lingkungan penerapan.

^①^ Parameter attempts hanya berlaku dalam skenario tertentu: ketika server mengembalikan SERVFAIL, NOTIMP, atau REFUSED, atau ketika server mengembalikan NOERROR tetapi tanpa hasil resolusi. Untuk detailnya, lihat Detail permintaan parameter Attempts.

^②^ Server DNS VPC adalah server DNS default yang dikonfigurasi pada instans ECS. Alamat IP-nya adalah 100.100.2.136 dan 100.100.2.138. Server ini menyelesaikan nama domain di PrivateZone dan nama domain otoritatif.

^③^ CoreDNS ClusterIP adalah alamat IP layanan kube-dns di namespace kube-system. Layanan ini menyelesaikan nama domain layanan internal dan meneruskan permintaan resolusi untuk PrivateZone dan nama domain otoritatif.

^④^ IP NodeLocal DNSCache adalah 169.254.20.10. Saat add-on NodeLocal DNSCache diterapkan, layanan ini mendengarkan pada alamat IP ini di setiap node.

Untuk opsi tambahan /etc/resolv.conf, lihat resolv.conf.

Resolver non-standar

Nilai default glibc di atas hanya berlaku ketika kontainer menggunakan glibc. Dua pengecualian umum:

• Alpine (musl libc): Pustaka bawaan musl Alpine menggantikan glibc dan berperilaku berbeda dalam beberapa hal: Untuk detail perilaku resolusi musl, lihat musl libc.

  • Tidak mematuhi opsi single-request dan single-request-reopen di /etc/resolv.conf.

  • Alpine 3.3 dan versi sebelumnya tidak mendukung parameter search atau domain pencarian, yang menyebabkan penemuan layanan gagal.

  • Permintaan konkuren ke beberapa server DNS membuat optimasi NodeLocal DNSCache tidak efektif.

  • Menggunakan socket yang sama untuk meminta rekaman A dan AAAA secara konkuren memicu kondisi balapan conntrack pada versi kernel lama, menyebabkan kehilangan paket secara intermiten.

• Bahasa dengan resolver bawaan (Go, Node.js): Waktu proses ini sering melewati /etc/resolv.conf sepenuhnya dan menunjukkan perilaku resolusi yang berbeda dari resolver sistem.

Server DNS dalam kluster

Secara default, CoreDNS membaca upstream-nya dari /etc/resolv.conf ECS dan menggunakan Plugin forward bawaan untuk meneruskan permintaan DNS. NodeLocal DNSCache menjalankan instance CoreDNS tersemat dan menggunakan konfigurasi penerusan yang sama.

Tabel berikut mencantumkan parameter yang mengontrol kebijakan resolusi Plugin forward. Untuk referensi lengkap, lihat Forward.

Sisi klien

Caching sisi klien bervariasi tergantung pada gambar kontainer dan aplikasi. Kebijakan efektif bergantung pada konfigurasi spesifik Anda.

Server DNS dalam kluster

Tabel berikut mencantumkan parameter cache untuk CoreDNS dan NodeLocal DNSCache di ACK.

Tingkatkan toleransi kesalahan

Saat dnsPolicy: Default diatur pada pod, kontainer mewarisi pengaturan server DNS VPC dari /etc/resolv.conf instans ECS. Namun, kontainer tersebut tidak mewarisi opsi rotate, single-request-reopen, timeout:2, dan attempts:3. Tanpa opsi ini, fluktuasi jaringan dapat menyebabkan kegagalan resolusi DNS secara intermiten.

Berikut adalah konfigurasi yang diwariskan:

apiVersion: v1
kind: Pod
metadata:
  name: example
  namespace: default
spec:
  containers:
  - image: registry.cn-hangzhou.aliyuncs.com/example-ns/example:v1
    name: example
  # Nilai dnsPolicy dalam YAML Pod adalah Default.
  dnsPolicy: Default

# File /etc/resolv.conf dalam kontainer saat ini.
# cat /etc/resolv.conf
nameserver 100.100.2.136
nameserver 100.100.2.138

Tambahkan dnsConfig untuk mengembalikan opsi toleransi kesalahan yang hilang:

apiVersion: v1
kind: Pod
metadata:
  name: example
  namespace: default
spec:
  containers:
  - image: registry.cn-hangzhou.aliyuncs.com/example-ns/example:v1
    name: example
  # Nilai dnsPolicy dalam YAML pod adalah Default.
  dnsPolicy: Default
  # Tambahkan konfigurasi toleransi kesalahan berikut.
  dnsConfig:
    options:
    - name: timeout
      value: "2"
    - name: attempts
      value: "3"
    - name: rotate
    - name: single-request-reopen

# Setelah modifikasi, redeploy pod. Parameter options ditambahkan ke /etc/resolv.conf dalam kontainer.
# cat /etc/resolv.conf
nameserver 100.100.2.136
nameserver 100.100.2.138
options rotate single-request-reopen timeout:2 attempts:3

Ketersediaan tinggi dengan serve_stale

Fitur serve_stale memungkinkan CoreDNS mengembalikan entri cache yang telah kadaluarsa saat server DNS upstream tidak dapat dijangkau. Hal ini mencegah kegagalan resolusi akibat gangguan sementara pada upstream.

serve_stale diaktifkan secara default di edisi unmanaged CoreDNS v1.12.1 dan versi selanjutnya. Untuk spesifikasi RFC, lihat RFC-8767.

Format konfigurasi

serve_stale [DURATION] [REFRESH_MODE]

• DURATION: Durasi entri yang telah kadaluarsa tetap memenuhi syarat untuk disajikan setelah masa berlakunya habis. Nilai default adalah 1h. Jika entri telah kadaluarsa lebih lama dari durasi ini tanpa refresh yang berhasil, CoreDNS berhenti menyajikannya.

• REFRESH_MODE: Mengontrol cara CoreDNS menangani entri yang telah kadaluarsa:

  • verify: Pertama-tama memverifikasi bahwa layanan DNS upstream dapat dijangkau, lalu mengembalikan hasil ke klien — menggunakan entri segar jika upstream merespons, atau kembali ke entri yang telah kadaluarsa jika tidak. Hal ini meningkatkan latensi pada respons kadaluarsa tetapi mencegah penyajian entri usang saat entri segar tersedia.

  • immediate: Mengembalikan entri yang telah kadaluarsa ke klien segera, lalu memeriksa upstream di latar belakang. Hal ini memberikan respons lebih cepat tetapi mungkin menyajikan data usang jika upstream telah diperbarui.

Contoh

Konfigurasi berikut adalah default di edisi unmanaged CoreDNS v1.12.1.2 dan versi selanjutnya:

cache 30 {
  ...
  serve_stale 30s verify
}

cache 30 {
  ...
  serve_stale 1h immediate
}