Konfigurasikan jumlah pod, sumber daya, penjadwalan, dan isolasi node untuk mencegah gangguan CoreDNS dalam mode unmanaged.
Dalam mode unmanaged, ketersediaan dan kinerja CoreDNS bergantung pada jumlah pod, batas sumber daya, penjadwalan, dan distribusi node. Pengaturan default cocok untuk kluster kecil; beban kerja produksi memerlukan penyesuaian.
Dampak potensial
Konfigurasi CoreDNS yang salah atau kekurangan sumber daya menyebabkan dua kategori masalah:
-
Ketersediaan: Penjadwalan yang tidak tepat menciptakan titik kegagalan tunggal di tingkat node atau zona. Sumber daya yang tidak mencukupi menyebabkan pengusiran pod dan gangguan DNS.
-
Kinerja: Konflik sumber daya pada node bersama meningkatkan latensi respons. Beban node yang tinggi menyebabkan kehilangan paket I/O dan kegagalan permintaan DNS.
Menyesuaikan jumlah pod CoreDNS
Karena UDP tidak memiliki mekanisme pengiriman ulang, skala-masuk atau restart CoreDNS—terutama saat cacat IPVS menyebabkan kehilangan paket—dapat memicu timeout atau kegagalan resolusi DNS di seluruh kluster hingga lima menit. Lihat Pemecahan Masalah Masalah Resolusi DNS.
Jangan gunakan Penyesuaian Otomatis Pod Horizontal (HPA) atau CronHPA untuk CoreDNS. Skala-masuk yang sering menyebabkan kegagalan resolusi.
Menilai tekanan DNS
Sebelum menyesuaikan jumlah replika, nilai tekanan DNS. Alat seperti DNSPerf dapat mengukur beban DNS.
Jika Anda tidak dapat mengukur tekanan DNS secara langsung, gunakan panduan berikut:
-
Jalankan minimal 2 pod CoreDNS dengan batas sumber daya minimal 1 core dan memori 1 GB.
-
Permintaan per detik (QPS) resolusi DNS meningkat secara linear seiring konsumsi CPU. Dengan NodeLocal DNSCache, setiap core CPU menangani lebih dari 10.000 permintaan per detik (QPS). Kebutuhan QPS berbagai beban kerja sangat bervariasi, jadi pantau penggunaan CPU puncak setiap pod CoreDNS; jika ada pod yang melebihi satu core selama jam sibuk bisnis, tambah jumlah replika.
-
Tanpa data beban, mulailah dengan 1 pod per 8 node sebagai garis dasar.
Menambah replika hanya membantu jika node memiliki sumber daya yang cukup. Jika node kekurangan memori, tambahkan node atau tingkatkan sumber daya per node.
Setelah Anda mengetahui jumlah replika target, gunakan penyesuaian otomatis (disarankan) atau sesuaikan secara manual.
Konfigurasi penyesuaian otomatis (disarankan)
cluster-proportional-autoscaler menyesuaikan jumlah replika CoreDNS berdasarkan ukuran kluster. Berbeda dengan HPA, komponen ini tidak bergantung pada metrik CPU atau melakukan skala-masuk yang mengganggu. Rasio default: 1 pod per 8 node.
Rumus jumlah replika: replicas = max(ceil(cores × 1/coresPerReplica), ceil(nodes × 1/nodesPerReplica)). Parameter min dan max membatasi jumlah pada rentang 2–100.
Terapkan autoscaler:
apiVersion: apps/v1
kind: Deployment
metadata:
name: dns-autoscaler
namespace: kube-system
labels:
k8s-app: dns-autoscaler
spec:
selector:
matchLabels:
k8s-app: dns-autoscaler
template:
metadata:
labels:
k8s-app: dns-autoscaler
spec:
serviceAccountName: admin
containers:
- name: autoscaler
image: registry.cn-hangzhou.aliyuncs.com/acs/cluster-proportional-autoscaler:1.8.4
resources:
requests:
cpu: "200m"
memory: "150Mi"
command:
- /cluster-proportional-autoscaler
- --namespace=kube-system
- --configmap=dns-autoscaler
- --nodelabels=type!=virtual-kubelet
- --target=Deployment/coredns
- --default-params={"linear":{"coresPerReplica":64,"nodesPerReplica":8,"min":2,"max":100,"preventSinglePointFailure":true}}
- --logtostderr=true
- --v=9
Menyesuaikan secara manual
Untuk menetapkan jumlah replika tertentu:
kubectl scale --replicas=<target> deployment/coredns -n kube-system # Ganti <target> dengan jumlah pod target.
Menyesuaikan spesifikasi pod CoreDNS
Dalam kluster ACK Pro, konfigurasi pod CoreDNS default adalah:
| Sumber Daya | Batas default |
|---|---|
| CPU | Tidak ada batas |
| Memori | 2 GiB |
Tetapkan batas CPU menjadi 4096m (minimum 1024m) berdasarkan penggunaan puncak yang Anda amati.
Mengubah spesifikasi pod CoreDNS akan merestart pod, yang dapat menyebabkan lonjakan latensi DNS singkat atau kegagalan. Lakukan ini selama jam sepi.
-
Masuk ke Konsol ACK. Di panel navigasi kiri, klik Clusters .
-
Di halaman Clusters, klik nama kluster target. Di panel navigasi kiri, klik Add-ons.
-
Di tab Networking, temukan CoreDNS dan klik Configuration.
-
Ubah konfigurasi CoreDNS dan klik OK.
Pada kotak dialog CoreDNS Parameter Settings, konfigurasikan parameter berikut:
-
MemoryRequest: permintaan memori, misalnya
100Mi. -
CpuRequest: permintaan CPU, misalnya
100m. -
MemoryLimit: batas memori, misalnya
2Gi. Jika batas memori terlalu rendah, pod dapat mengalami OOMKilled. -
CpuLimit: batas CPU. Kami menyarankan Anda menetapkannya dua kali lipat dari nilai CpuRequest.
-
NodeSelector: label pemilih node. Misalnya, tetapkan Key menjadi
kubernetes.io/osdan Value menjadilinux.
-
Terapkan pada kelompok node khusus
Kelompok node khusus mengisolasi CoreDNS dari beban kerja lain dan mencegah konflik sumber daya.
Menjadwalkan ulang pod CoreDNS akan merestart pod tersebut, yang dapat menyebabkan lonjakan latensi DNS singkat atau kegagalan. Lakukan ini selama jam sepi.
Buat kelompok node khusus
Saat membuat kelompok node, ikuti panduan berikut:
-
CoreDNS bersifat intensif jaringan, bukan intensif komputasi. Gunakan instans peningkatan jaringan dengan ukuran yang disarankan 4 core dan memori 8 GB.
-
Kelompok node harus memiliki minimal 2 node, karena CoreDNS menjalankan 2 pod secara default.
-
Tambahkan taint dan label untuk mencegah pod lain berjalan di node ini. Misalnya, gunakan
system-addon: system-addonsebagai pasangan kunci-nilai taint sekaligus label, denganEffectdiatur keNoSchedule.
Jadwalkan pod CoreDNS ke kelompok node
-
Di halaman Add-ons, temukan kartu CoreDNS dan klik Configuration.
-
Di bagian NodeSelector, tambahkan label kelompok node khusus.
Jangan hapus label NodeSelector yang sudah ada.
-
Di bagian Tolerations, tambahkan toleransi yang sesuai dengan taint kelompok node.
Tambahkan entri toleransi di Tolerations: atur effect menjadi
NoSchedule, key menjadisystem-addon, operator menjadiEqual, dan value menjadisystem-addon. -
Klik OK, lalu verifikasi bahwa pod CoreDNS berjalan di node khusus:
kubectl -n kube-system get pod -o wide --show-labels | grep coredns
Gunakan kebijakan penjadwalan untuk ketersediaan tinggi
Untuk melindungi ketersediaan DNS, CoreDNS menggunakan dua kebijakan penjadwalan secara default:
-
Anti-afinitas pod (tingkat node): mencegah dua pod CoreDNS berjalan di node yang sama. Jika suatu node gagal, DNS tetap tersedia di node lain.
-
Penjadwalan sadar topologi (tingkat zona): mendistribusikan pod CoreDNS di berbagai zona ketersediaan, mencegah titik kegagalan tunggal di tingkat zona yang tidak dapat diatasi hanya dengan anti-afinitas pod.
Kebijakan ini hanya berlaku selama penjadwalan awal. Jika konfigurasi node atau zona berubah, temukan Penyebaran coredns di Konsol ACK dan klik Redeploy.
Anti-afinitas pod
CoreDNS menggunakan aturan anti-afinitas requiredDuringSchedulingIgnoredDuringExecution untuk mencegah dua pod CoreDNS berbagi satu node. Ini memerlukan minimal 2 node dengan sumber daya yang cukup, tidak termasuk:
-
k8s.aliyun.com: true— node dengan penyesuaian otomatis node diaktifkan -
type: virtual-kubelet— node virtual -
alibabacloud.com/lingjun-worker: true— Node Lingjun
Konfigurasi afinitas default adalah:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
# virtual nodes have this label
- key: type
operator: NotIn
values:
- virtual-kubelet
# lingjun worker nodes have this label
- key: alibabacloud.com/lingjun-worker
operator: NotIn
values:
- "true"
preferredDuringSchedulingIgnoredDuringExecution:
- preference:
matchExpressions:
# autoscaled nodes have this label
- key: k8s.aliyun.com
operator: NotIn
values:
- "true"
weight: 100
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: k8s-app
operator: In
values:
- kube-dns
topologyKey: kubernetes.io/hostname
Penjadwalan sadar topologi
Secara default, CoreDNS menggunakan penjadwalan sadar topologi untuk menyebarkan pod di berbagai zona. Pengaturan whenUnsatisfiable: DoNotSchedule menegakkan hal ini—pod tidak akan dijadwalkan jika kondisi keseimbangan zona tidak dapat dipenuhi.
Agar ini berfungsi secara andal:
-
Kluster Anda harus memiliki node di minimal 2 zona berbeda, masing-masing dengan minimal 1 node yang memiliki sumber daya cukup untuk CoreDNS.
-
Semua node harus memiliki label
topology.kubernetes.io/zone(diterapkan secara default). Label yang hilang atau tidak konsisten menyebabkan kegagalan penjadwalan atau distribusi tidak merata. -
Tingkatkan kluster Anda ke v1.27 atau lebih baru dan CoreDNS ke v1.12.1.3 atau lebih baru. Versi kluster sebelumnya tidak mendukung matchLabelKeys, sehingga pembaruan bergulir CoreDNS dapat berakhir dengan pod yang tersebar tidak merata di zona dan bahkan meninggalkan beberapa zona tanpa cakupan. Lihat konfigurasi
matchLabelKeysyang dijelaskan di bawah.
Versi CoreDNS sebelum v1.12.1.3 menggunakan kendala penyebaran topologi berikut:
topologySpreadConstraints:
- labelSelector:
matchLabels:
k8s-app: kube-dns
maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: DoNotSchedule
Selisih jumlah pod antara dua zona apa pun tidak boleh melebihi maxSkew (default 1). Elemen labelSelector menghitung pod dari Set Replika baru maupun lama, sehingga untuk memenuhi maxSkew=1, penjadwal lebih memilih zona dengan jumlah total pod lebih sedikit. Setelah pod lama dihentikan, pod baru dapat berkumpul di beberapa zona saja.
CoreDNS v1.12.1.3 dan lebih baru memperbaiki hal ini dengan matchLabelKeys (Kubernetes v1.27+):
topologySpreadConstraints:
- labelSelector:
matchLabels:
k8s-app: kube-dns
matchLabelKeys:
- pod-template-hash
nodeTaintsPolicy: Honor
maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: DoNotSchedule
Menambahkan matchLabelKeys: [pod-template-hash] membatasi kendala hanya pada Set Replika saat ini, sehingga pembaruan bergulir mendistribusikan pod secara merata di berbagai zona.