Layanan Cluster

Layanan cluster berjalan di dalam kluster EKS, tetapi itu bukan beban kerja pengguna. Jika Anda memiliki server Linux, Anda sering perlu menjalankan layanan seperti NTP, syslog, dan runtime container untuk mendukung beban kerja Anda. Layanan cluster serupa, layanan pendukung yang membantu Anda mengotomatiskan dan mengoperasikan klaster Anda. Di Kubernetes ini biasanya dijalankan di namespace kube-system dan beberapa dijalankan sebagai. DaemonSets

Layanan cluster diharapkan memiliki up-time yang tinggi dan seringkali kritis selama pemadaman dan untuk pemecahan masalah. Jika layanan cluster inti tidak tersedia, Anda mungkin kehilangan akses ke data yang dapat membantu memulihkan atau mencegah pemadaman (misalnya pemanfaatan disk yang tinggi). Mereka harus berjalan pada instance komputasi khusus seperti grup node terpisah atau AWS Fargate. Ini akan memastikan bahwa layanan klaster tidak terpengaruh pada instance bersama oleh beban kerja yang mungkin meningkatkan atau menggunakan lebih banyak sumber daya.

Skala CoreDNS

Scaling CoreDNS memiliki dua mekanisme utama. Mengurangi jumlah panggilan ke layanan CoreDNS dan meningkatkan jumlah replika.

Kurangi kueri eksternal dengan menurunkan ndots

Pengaturan ndots menentukan berapa banyak periode (alias “titik”) dalam nama domain dianggap cukup untuk menghindari kueri DNS. Jika aplikasi Anda memiliki setelan ndots 5 (default) dan Anda meminta sumber daya dari domain eksternal seperti api.example.com (2 titik) maka CoreDNS akan ditanyakan untuk setiap domain pencarian yang ditentukan dalam /etc/resolv.conf untuk domain yang lebih spesifik. Secara default domain berikut akan dicari sebelum membuat permintaan eksternal.

api.example.<namespace>.svc.cluster.local
api.example.svc.cluster.local
api.example.cluster.local
api.example.<region>.compute.internal

regionNilai namespace dan akan diganti dengan namespace beban kerja dan wilayah komputasi Anda. Anda mungkin memiliki domain penelusuran tambahan berdasarkan pengaturan klaster Anda.

Anda dapat mengurangi jumlah permintaan ke CoreDNS dengan menurunkan opsi ndots beban kerja Anda atau sepenuhnya memenuhi syarat permintaan domain Anda dengan menyertakan trailing. (misalnyaapi.example.com.). Jika beban kerja Anda terhubung ke layanan eksternal melalui DNS, kami sarankan untuk menyetel ndots ke 2 sehingga beban kerja tidak membuat kueri DNS cluster yang tidak perlu di dalam cluster. Anda dapat mengatur server DNS dan domain pencarian yang berbeda jika beban kerja tidak memerlukan akses ke layanan di dalam klaster.

spec:
  dnsPolicy: "None"
  dnsConfig:
    options:
      - name: ndots
        value: "2"
      - name: edns0

Jika Anda menurunkan ndots ke nilai yang terlalu rendah atau domain yang Anda sambungkan tidak menyertakan spesifisitas yang cukup (termasuk trailing.) maka ada kemungkinan pencarian DNS akan gagal. Pastikan Anda menguji bagaimana pengaturan ini akan memengaruhi beban kerja Anda.

Skala CoreDNS Secara Horizontal

Instance CoreDNS dapat diskalakan dengan menambahkan replika tambahan ke penerapan. Disarankan Anda menggunakan NodeLocal DNS atau autoscaler proporsional cluster untuk menskalakan CoreDNS.

NodeLocal DNS akan membutuhkan jalankan satu instance per node—sebagai DaemonSet —yang membutuhkan lebih banyak sumber daya komputasi di cluster, tetapi akan menghindari permintaan DNS yang gagal dan mengurangi waktu respons untuk kueri DNS di cluster. Autoscaler proporsional cluster akan menskalakan CoreDNS berdasarkan jumlah node atau core dalam cluster. Ini bukan korelasi langsung dengan permintaan kueri, tetapi dapat berguna tergantung pada beban kerja dan ukuran cluster Anda. Skala proporsional default adalah menambahkan replika tambahan untuk setiap 256 core atau 16 node di cluster — mana yang terjadi lebih dulu.

Skala Server Metrik Kubernetes Secara Vertikal

Kubernetes Metrics Server mendukung penskalaan horizontal dan vertikal. Dengan menskalakan Server Metrik secara horizontal, ini akan sangat tersedia, tetapi tidak akan menskalakan secara horizontal untuk menangani lebih banyak metrik cluster. Anda perlu menskalakan Server Metrik secara vertikal berdasarkan rekomendasinya saat node dan metrik yang dikumpulkan ditambahkan ke cluster.

Server Metrik menyimpan data yang dikumpulkan, dikumpulkan, dan disajikan dalam memori. Seiring pertumbuhan cluster, jumlah data yang disimpan Metrics Server meningkat. Dalam cluster besar Metrics Server akan membutuhkan lebih banyak sumber daya komputasi daripada memori dan reservasi CPU yang ditentukan dalam instalasi default. Anda dapat menggunakan Vertical Pod Autoscaler (VPA) atau Addon Resizer untuk menskalakan Server Metrik. Addon Resizer menskalakan secara vertikal sebanding dengan node pekerja dan skala VPA berdasarkan penggunaan CPU dan memori.

Durasi lameduck CoreDNS

Pod menggunakan kube-dns Service untuk resolusi nama. Kubernetes menggunakan NAT tujuan (DNAT) untuk mengarahkan kube-dns lalu lintas dari node ke pod backend CoreDNS. Saat Anda menskalakan Deployment CoreDNSkube-proxy, memperbarui aturan dan rantai iptables pada node untuk mengarahkan lalu lintas DNS ke pod CoreDNS. Menyebarkan titik akhir baru saat Anda meningkatkan dan menghapus aturan saat Anda menurunkan CoreDNS dapat memakan waktu antara 1 hingga 10 detik tergantung pada ukuran cluster.

Penundaan propagasi ini dapat menyebabkan kegagalan pencarian DNS ketika pod CoreDNS dihentikan namun aturan iptables node belum diperbarui. Dalam skenario ini, node dapat terus mengirim kueri DNS ke Pod CoreDNS yang dihentikan.

Anda dapat mengurangi kegagalan pencarian DNS dengan menyetel durasi lameduck di pod CoreDNS Anda. Saat dalam mode lameduck, CoreDNS akan terus menanggapi permintaan dalam penerbangan. Menyetel durasi lameduck akan menunda proses shutdown CoreDNS, memungkinkan node waktu yang mereka butuhkan untuk memperbarui aturan dan rantai iptables mereka.

Sebaiknya atur durasi lameduck CoreDNS menjadi 30 detik.

Penyelidikan kesiapan CoreDNS

Kami merekomendasikan penggunaan /ready bukan /health untuk probe kesiapan CoreDNS.

Sejalan dengan rekomendasi sebelumnya untuk menyetel durasi lameduck menjadi 30 detik, memberikan waktu yang cukup untuk aturan iptables node diperbarui sebelum penghentian pod, menggunakan alih-alih /ready untuk probe kesiapan CoreDNS memastikan bahwa pod CoreDNS sepenuhnya siap saat startup untuk /health segera menanggapi permintaan DNS.

readinessProbe:
  httpGet:
    path: /ready
    port: 8181
    scheme: HTTP

Untuk informasi lebih lanjut tentang plugin CoreDNS Ready, silakan merujuk ke https://coredns. io/plugins/ready/

Agen penebangan dan pemantauan

Agen logging dan monitoring dapat menambahkan beban signifikan ke bidang kontrol klaster Anda karena agen menanyakan server API untuk memperkaya log dan metrik dengan metadata beban kerja. Agen pada node hanya memiliki akses ke sumber daya node lokal untuk melihat hal-hal seperti wadah dan nama proses. Menanyakan server API, ia dapat menambahkan lebih banyak detail seperti nama dan label penerapan Kubernetes. Ini bisa sangat membantu untuk pemecahan masalah tetapi merugikan penskalaan.

Karena ada begitu banyak opsi berbeda untuk pencatatan dan pemantauan, kami tidak dapat menunjukkan contoh untuk setiap penyedia. Dengan fluentbit, kami merekomendasikan untuk mengaktifkan Use_Kubelet untuk mengambil metadata dari kubelet lokal alih-alih Kubernetes API Server dan disetel ke nomor yang mengurangi panggilan berulang saat data dapat di-cache (misalnya Kube_Meta_Cache_TTL 60).

Pemantauan penskalaan dan pencatatan memiliki dua opsi umum:

• Nonaktifkan integrasi

• Pengambilan sampel dan penyaringan

Menonaktifkan integrasi seringkali bukan pilihan karena Anda kehilangan metadata log. Ini menghilangkan masalah penskalaan API, tetapi akan menimbulkan masalah lain dengan tidak memiliki metadata yang diperlukan saat diperlukan.

Pengambilan sampel dan penyaringan mengurangi jumlah metrik dan log yang dikumpulkan. Ini akan menurunkan jumlah permintaan ke Kubernetes API, dan ini akan mengurangi jumlah penyimpanan yang dibutuhkan untuk metrik dan log yang dikumpulkan. Mengurangi biaya penyimpanan akan menurunkan biaya untuk keseluruhan sistem.

Kemampuan untuk mengkonfigurasi sampling tergantung pada perangkat lunak agen dan dapat diimplementasikan pada berbagai titik konsumsi. Penting untuk menambahkan sampling sedekat mungkin dengan agen karena kemungkinan di situlah panggilan server API terjadi. Hubungi penyedia Anda untuk mengetahui lebih lanjut tentang dukungan pengambilan sampel.

Jika Anda menggunakan CloudWatch dan CloudWatch Log, Anda dapat menambahkan pemfilteran agen menggunakan pola yang dijelaskan dalam dokumentasi.

Untuk menghindari kehilangan log dan metrik, Anda harus mengirim data ke sistem yang dapat menyangga data jika terjadi pemadaman pada titik akhir penerima. Dengan fluentbit, Anda dapat menggunakan Amazon Kinesis Data Firehose untuk menyimpan data sementara yang dapat mengurangi kemungkinan kelebihan beban lokasi penyimpanan data akhir Anda.