Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Pemantauan Pesawat Kontrol
## Server API
Saat melihat server API kami, penting untuk diingat bahwa salah satu fungsinya adalah untuk membatasi permintaan masuk untuk mencegah kelebihan beban bidang kontrol. Apa yang tampak seperti hambatan di tingkat server API mungkin sebenarnya melindunginya dari masalah yang lebih serius. Kita perlu memperhitungkan pro dan kontra dari meningkatkan volume permintaan yang bergerak melalui sistem. Untuk menentukan apakah nilai server API harus ditingkatkan, berikut adalah contoh kecil dari hal-hal yang perlu kita perhatikan:
1. Berapa latensi permintaan yang bergerak melalui sistem?
1. Apakah latensi itu server API itu sendiri, atau sesuatu yang “hilir” seperti etcd?
1. Apakah kedalaman antrian server API merupakan faktor dalam latensi ini?
1. Apakah antrian Priority and Fairness (APF) API diatur dengan benar untuk pola panggilan API yang kita inginkan?
## Di mana masalahnya?
Untuk memulai, kita dapat menggunakan metrik untuk latensi API untuk memberi kita wawasan tentang berapa lama waktu yang dibutuhkan server API untuk melayani permintaan. Mari gunakan heatmap PromQL dan Grafana di bawah ini untuk menampilkan data ini.
```
max(increase(apiserver_request_duration_seconds_bucket{subresource!="status",subresource!="token",subresource!="scale",subresource!="/healthz",subresource!="binding",subresource!="proxy",verb!="WATCH"}[$__rate_interval])) by (le)
```
**catatan**
Untuk tulisan mendalam tentang cara memantau server API dengan dasbor API yang digunakan dalam artikel ini, silakan lihat [ blog berikut ](https://aws.amazon.com/blogs/containers/troubleshooting-amazon-eks-api-servers-with-prometheus/)
Semua permintaan ini berada di bawah tanda satu detik, yang merupakan indikasi yang baik bahwa pesawat kontrol menangani permintaan secara tepat waktu. Tetapi bagaimana jika itu tidak terjadi?
Format yang kami gunakan dalam Durasi Permintaan API di atas adalah heatmap. Apa yang menyenangkan tentang format heatmap, adalah bahwa ia memberi tahu kita nilai batas waktu untuk API secara default (60 detik). Namun, yang benar-benar perlu kita ketahui adalah pada ambang batas berapa nilai ini harus menjadi perhatian sebelum kita mencapai ambang batas waktu. Untuk pedoman kasar tentang ambang batas yang dapat diterima, kita dapat menggunakan Hulu Kubernetes SLO, yang dapat ditemukan di sini [https://github.com/kubernetes/community/blob/master/sig-scalability/slos/slos.md#steady-state-slisslos](https://github.com/kubernetes/community/blob/master/sig-scalability/slos/slos.md#steady-state-slisslos)
**catatan**
Perhatikan fungsi max pada pernyataan ini? Saat menggunakan metrik yang menggabungkan beberapa server (secara default dua server API di EKS), penting untuk tidak merata-ratakan server tersebut bersama-sama.
### Pola lalu lintas asimetris
Bagaimana jika satu server API [pod] dimuat dengan ringan, dan yang lainnya dimuat dengan berat? Jika kita merata-ratakan kedua angka itu bersama-sama, kita mungkin salah menafsirkan apa yang terjadi. Misalnya, di sini kita memiliki tiga server API tetapi semua beban ada di salah satu server API ini. Sebagai aturan, apa pun yang memiliki banyak server seperti server etcd dan API harus dipecahkan saat menginvestasikan masalah skala dan kinerja.
Dengan perpindahan ke API Priority and Fairness, jumlah total permintaan pada sistem hanyalah satu faktor untuk memeriksa apakah server API kelebihan langganan. Karena sistem sekarang bekerja dari serangkaian antrian, kita harus melihat apakah salah satu dari antrian ini penuh dan apakah lalu lintas untuk antrian itu turun.
Mari kita lihat antrian ini dengan kueri berikut:
```
max without(instance)(apiserver_flowcontrol_nominal_limit_seats{})
```
**catatan**
Untuk informasi lebih lanjut tentang cara kerja API A&F, silakan lihat panduan praktik [ terbaik berikut ](https://docs.aws.amazon.com/eks/latest/best-practices/scale-control-plane.html#_api_priority_and_fairness)
Di sini kita melihat tujuh grup prioritas berbeda yang datang secara default di cluster
Selanjutnya kita ingin melihat berapa persentase dari grup prioritas itu yang digunakan, sehingga kita dapat memahami apakah tingkat prioritas tertentu sedang jenuh. Permintaan pembatasan di tingkat beban kerja rendah mungkin diinginkan, namun penurunan tingkat pemilihan pemimpin tidak akan terjadi.
Sistem API Priority and Fairness (APF) memiliki sejumlah opsi kompleks, beberapa opsi tersebut dapat memiliki konsekuensi yang tidak diinginkan. Masalah umum yang kita lihat di lapangan adalah meningkatkan kedalaman antrian hingga mulai menambahkan latensi yang tidak perlu. Kita dapat memantau masalah ini dengan menggunakan `apiserver_flowcontrol_current_inqueue_request` metrik. Kita dapat memeriksa tetesan menggunakan`apiserver_flowcontrol_rejected_requests_total`. Metrik ini akan menjadi nilai bukan nol jika ada bucket yang melebihi konkurensinya.
Meningkatkan kedalaman antrian dapat membuat Server API menjadi sumber latensi yang signifikan dan harus dilakukan dengan hati-hati. Sebaiknya bijaksana dengan jumlah antrian yang dibuat. Misalnya, jumlah saham pada sistem EKS adalah 600, jika kita membuat terlalu banyak antrian, ini dapat mengurangi saham dalam antrian penting yang membutuhkan throughput seperti antrian pemilihan pemimpin atau antrian sistem. Membuat terlalu banyak antrian tambahan dapat mempersulit ukuran antrian ini dengan benar.
Untuk fokus pada perubahan sederhana yang berdampak yang dapat Anda lakukan di APF, kami cukup mengambil saham dari bucket yang kurang dimanfaatkan dan meningkatkan ukuran bucket yang digunakan secara maksimal. Dengan mendistribusikan kembali saham secara cerdas di antara ember ini, Anda dapat mengurangi kemungkinan penurunan.
Untuk informasi selengkapnya, kunjungi pengaturan Prioritas dan Keadilan [ API ](https://docs.aws.amazon.com/eks/latest/best-practices/scale-control-plane.html#_api_priority_and_fairness) di Panduan Praktik Terbaik EKS.
### Latensi API vs etcd
Bagaimana kita bisa menggunakan server API untuk menentukan apakah ada masalah dengan server API, atau masalah yang berasal upstream/downstream dari server API, atau kombinasi keduanya. metrics/logs Untuk memahami hal ini dengan lebih baik, mari kita lihat bagaimana API Server dan etcd dapat terkait, dan betapa mudahnya memecahkan masalah sistem yang salah.
Pada bagan di bawah ini kita melihat latensi server API, tetapi kita juga melihat banyak latensi ini berkorelasi dengan server etcd karena bilah dalam grafik yang menunjukkan sebagian besar latensi pada tingkat etcd. Jika ada 15 detik latensi etcd pada saat yang sama ada 20 detik latensi server API, maka sebagian besar latensi sebenarnya pada tingkat etcd.
Dengan melihat seluruh aliran, kita melihat bahwa bijaksana untuk tidak fokus hanya pada Server API, tetapi juga mencari sinyal yang menunjukkan bahwa etcd berada di bawah tekanan (yaitu penghitung penerapan lambat meningkat). Mampu dengan cepat pindah ke area masalah yang tepat hanya dengan sekilas adalah apa yang membuat dasbor kuat.
**catatan**
Dasbor di bagian dapat ditemukan di https://github.com/RiskyAdventure/Troubleshooting-Dashboards/blob/main/api-troubleshooter.json
### Pesawat kontrol vs masalah sisi klien
Dalam bagan ini kami mencari panggilan API yang membutuhkan waktu paling banyak untuk diselesaikan untuk periode itu. Dalam hal ini kita melihat sumber daya khusus (CRD) memanggil fungsi APPLY yang merupakan panggilan paling laten selama kerangka waktu 05:40.
Berbekal data ini, kita dapat menggunakan kueri Ad-Hoc PromQL atau CloudWatch Insights untuk menarik permintaan LIST dari log audit selama jangka waktu tersebut untuk melihat aplikasi mana yang mungkin terjadi.
### Menemukan sumbernya dengan CloudWatch
Metrik paling baik digunakan untuk menemukan area masalah yang ingin kita lihat dan mempersempit kerangka waktu dan parameter pencarian masalah. Setelah kami memiliki data ini, kami ingin beralih ke log untuk waktu dan kesalahan yang lebih rinci. Untuk melakukan ini, kami akan mengubah log kami menjadi metrik menggunakan [ CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html).
Misalnya, untuk menyelidiki masalah di atas, kami akan menggunakan kueri Log CloudWatch s Insights berikut untuk menarik userAgent dan requestURI sehingga kami dapat menentukan aplikasi mana yang menyebabkan latensi ini.
**catatan**
Hitungan yang sesuai perlu digunakan agar tidak menarik List/Resync perilaku normal pada Jam Tangan.
```
fields @timestamp, @message
| filter @logStream like "kube-apiserver-audit"
| filter ispresent(requestURI)
| filter verb = "list"
| parse requestReceivedTimestamp /\d+-\d+-(?\d+)T(?\d+):(?\d+):(?\d+).(?\d+)Z/
| parse stageTimestamp /\d+-\d+-(?\d+)T(?\d+):(?\d+):(?\d+).(?\d+)Z/
| fields (StartHour * 3600 + StartMinute * 60 + StartSec + StartMsec / 1000000) as StartTime, (EndHour * 3600 + EndMinute * 60 + EndSec + EndMsec / 1000000) as EndTime, (EndTime - StartTime) as DeltaTime
| stats avg(DeltaTime) as AverageDeltaTime, count(*) as CountTime by requestURI, userAgent
| filter CountTime >=50
| sort AverageDeltaTime desc
```
Dengan menggunakan kueri ini, kami menemukan dua agen berbeda menjalankan sejumlah besar operasi daftar latensi tinggi. Splunk dan CloudWatch agen. Berbekal data, kita dapat membuat keputusan untuk menghapus, memperbarui, atau mengganti pengontrol ini dengan proyek lain.
**catatan**
Untuk detail lebih lanjut tentang hal ini silakan lihat [ blog berikut ](https://aws.amazon.com/blogs/containers/troubleshooting-amazon-eks-api-servers-with-prometheus/)
## Penjadwal
Karena instance pesawat kontrol EKS dijalankan di akun AWS terpisah, kami tidak akan dapat mengikis komponen tersebut untuk metrik (Server API menjadi pengecualian). Namun, karena kami memiliki akses ke log audit untuk komponen-komponen ini, kami dapat mengubah log tersebut menjadi metrik untuk melihat apakah ada sub-sistem yang menyebabkan hambatan penskalaan. Mari gunakan CloudWatch Logs Insights untuk melihat berapa banyak pod tak terjadwal yang ada dalam antrian penjadwal.
### Pod tak terjadwal di log penjadwal
Jika kami memiliki akses untuk mengikis metrik penjadwal secara langsung pada Kubernetes yang dikelola sendiri (seperti Kops), kami akan menggunakan PromQL berikut untuk memahami backlog penjadwal.
```
max without(instance)(scheduler_pending_pods)
```
Karena kami tidak memiliki akses ke metrik di atas di EKS, kami akan menggunakan kueri Logs Insights di bawah ini CloudWatch untuk melihat backlog dengan memeriksa berapa banyak pod yang tidak dapat dibatalkan selama jangka waktu tertentu. Kemudian kita bisa menyelam lebih jauh ke dalam pesan pada kerangka waktu puncak untuk memahami sifat kemacetan. Misalnya, node tidak berputar cukup cepat, atau pembatas laju di penjadwal itu sendiri.
```
fields timestamp, pod, err, @message
| filter @logStream like "scheduler"
| filter @message like "Unable to schedule pod"
| parse @message /^.(?\d{4})\s+(?\d+:\d+:\d+\.\d+)\s+\S*\s+\S+\]\s\"(.*?)\"\s+pod=(?\"(.*?)\")\s+err=(?\"(.*?)\")/
| count(*) as count by pod, err
| sort count desc
```
Di sini kita melihat kesalahan dari penjadwal yang mengatakan pod tidak digunakan karena PVC penyimpanan tidak tersedia.
**catatan**
Audit logging harus diaktifkan pada bidang kontrol untuk mengaktifkan fungsi ini. Ini juga merupakan praktik terbaik untuk membatasi retensi log agar tidak menaikkan biaya dari waktu ke waktu yang tidak perlu. Contoh untuk mengaktifkan semua fungsi logging menggunakan alat EKSCTL di bawah ini.
```
cloudWatch:
clusterLogging:
enableTypes: ["*"]
logRetentionInDays: 10
```
## Manajer Pengontrol Kube
Kube Controller Manager, seperti semua pengontrol lainnya, memiliki batasan berapa banyak operasi yang dapat dilakukan sekaligus. Mari kita tinjau apa beberapa bendera itu dengan melihat konfigurasi KOPS di mana kita dapat mengatur parameter ini.
```
kubeControllerManager:
concurrentEndpointSyncs: 5
concurrentReplicasetSyncs: 5
concurrentNamespaceSyncs: 10
concurrentServiceaccountTokenSyncs: 5
concurrentServiceSyncs: 5
concurrentResourceQuotaSyncs: 5
concurrentGcSyncs: 20
kubeAPIBurst: 30
kubeAPIQPS: "20"
```
Pengontrol ini memiliki antrian yang terisi selama waktu churn tinggi pada cluster. Dalam hal ini kita melihat pengontrol set replicaset memiliki backlog besar dalam antriannya.
Kami memiliki dua cara berbeda untuk mengatasi situasi seperti itu. Jika menjalankan mandiri, kami hanya dapat meningkatkan goroutine bersamaan, namun ini akan berdampak pada etcd dengan memproses lebih banyak data di KCM. Pilihan lainnya adalah mengurangi jumlah objek replicaset yang digunakan `.spec.revisionHistoryLimit` pada penerapan untuk mengurangi jumlah objek replicaset yang dapat kita kembalikan, sehingga mengurangi tekanan pada pengontrol ini.
```
spec:
revisionHistoryLimit: 2
```
Fitur Kubernetes lainnya dapat disetel atau dimatikan untuk mengurangi tekanan pada sistem tingkat churn tinggi. Misalnya, jika aplikasi di pod kami tidak perlu berbicara dengan API k8s secara langsung, maka mematikan rahasia yang diproyeksikan ke dalam pod tersebut akan mengurangi beban. ServiceaccountTokenSyncs Ini adalah cara yang lebih diinginkan untuk mengatasi masalah seperti itu jika memungkinkan.
```
kind: Pod
spec:
automountServiceAccountToken: false
```
Dalam sistem di mana kita tidak bisa mendapatkan akses ke metrik, kita dapat kembali melihat log untuk mendeteksi pertikaian. Jika kami ingin melihat jumlah permintaan yang sedang diproses pada tingkat per pengontrol atau agregat, kami akan menggunakan Logs Insights Query berikut CloudWatch .
### Total Volume Diproses oleh KCM
```
# Query to count API qps coming from kube-controller-manager, split by controller type.
# If you're seeing values close to 20/sec for any particular controller, it's most likely seeing client-side API throttling.
fields @timestamp, @logStream, @message
| filter @logStream like /kube-apiserver-audit/
| filter userAgent like /kube-controller-manager/
# Exclude lease-related calls (not counted under kcm qps)
| filter requestURI not like "apis/coordination.k8s.io/v1/namespaces/kube-system/leases/kube-controller-manager"
# Exclude API discovery calls (not counted under kcm qps)
| filter requestURI not like "?timeout=32s"
# Exclude watch calls (not counted under kcm qps)
| filter verb != "watch"
# If you want to get counts of API calls coming from a specific controller, uncomment the appropriate line below:
# | filter user.username like "system:serviceaccount:kube-system:job-controller"
# | filter user.username like "system:serviceaccount:kube-system:cronjob-controller"
# | filter user.username like "system:serviceaccount:kube-system:deployment-controller"
# | filter user.username like "system:serviceaccount:kube-system:replicaset-controller"
# | filter user.username like "system:serviceaccount:kube-system:horizontal-pod-autoscaler"
# | filter user.username like "system:serviceaccount:kube-system:persistent-volume-binder"
# | filter user.username like "system:serviceaccount:kube-system:endpointslice-controller"
# | filter user.username like "system:serviceaccount:kube-system:endpoint-controller"
# | filter user.username like "system:serviceaccount:kube-system:generic-garbage-controller"
| stats count(*) as count by user.username
| sort count desc
```
Kuncinya di sini adalah ketika melihat masalah skalabilitas, untuk melihat setiap langkah di jalur (API, penjadwal, KCM, etcd) sebelum pindah ke fase pemecahan masalah terperinci. Seringkali dalam produksi Anda akan menemukan bahwa diperlukan penyesuaian pada lebih dari satu bagian Kubernetes untuk memungkinkan sistem bekerja dengan kinerja paling baik. Sangat mudah untuk secara tidak sengaja memecahkan masalah apa yang hanya merupakan gejala (seperti batas waktu simpul) dari leher botol yang jauh lebih besar.
## ETCD
etcd menggunakan file yang dipetakan memori untuk menyimpan pasangan nilai kunci secara efisien. Ada mekanisme perlindungan untuk mengatur ukuran ruang memori yang tersedia ini ditetapkan secara umum pada batas 2, 4, dan 8GB. Lebih sedikit objek dalam database berarti lebih sedikit pembersihan yang perlu dilakukan etcd ketika objek diperbarui dan versi yang lebih lama perlu dibersihkan. Proses pembersihan versi lama dari suatu objek ini disebut sebagai pemadatan. Setelah sejumlah operasi pemadatan, ada proses selanjutnya yang memulihkan ruang yang dapat digunakan yang disebut defragging yang terjadi di atas ambang batas tertentu atau pada jadwal waktu yang tetap.
Ada beberapa item terkait pengguna yang dapat kita lakukan untuk membatasi jumlah objek di Kubernetes dan dengan demikian mengurangi dampak dari proses pemadatan dan de-fragmentasi. Misalnya, Helm tetap tinggi`revisionHistoryLimit`. Ini membuat objek yang lebih tua seperti ReplicaSets pada sistem untuk dapat melakukan rollback. Dengan menetapkan batas riwayat menjadi 2 kita dapat mengurangi jumlah objek (seperti ReplicaSets) dari sepuluh menjadi dua yang pada gilirannya akan mengurangi beban pada sistem.
```
apiVersion: apps/v1
kind: Deployment
spec:
revisionHistoryLimit: 2
```
Dari sudut pandang pemantauan, jika lonjakan latensi sistem terjadi dalam pola yang ditetapkan yang dipisahkan oleh jam, memeriksa untuk melihat apakah proses defragmentasi ini adalah sumbernya dapat membantu. Kita bisa melihat ini dengan menggunakan CloudWatch Log.
Jika Anda ingin melihat start/end waktu defrag gunakan kueri berikut:
```
fields @timestamp, @message
| filter @logStream like /etcd-manager/
| filter @message like /defraging|defraged/
| sort @timestamp asc
```
