Memecahkan masalah pertentangan resource

Halaman ini menjelaskan cara mengidentifikasi dan memecahkan masalah pertentangan resource di lingkungan GKE di VMware. Jika Anda memerlukan bantuan lebih lanjut, lihat Mendapatkan dukungan.

Ringkasan

Terkadang GKE di VMware mungkin mengalami pertentangan resource, yang menyebabkan container Anda melambat, berperforma buruk, atau dihentikan. Hal ini dapat terjadi karena tingginya pemakaian CPU atau memori oleh container.

Cara kerja pengelolaan CPU dan memori

CPU:
- Pod dijadwalkan ke node berdasarkan permintaan CPU yang ditentukan oleh container di Pod.
- Container dalam Pod tidak dapat menggunakan lebih banyak CPU daripada batas yang ditentukan oleh container
- Penggunaan CPU untuk container dibatasi hingga batas CPU.
- Jika penggunaan CPU dibatasi di level node, container akan otomatis diberi siklus CPU yang proporsional dengan permintaan.
Pelajari lebih lanjut cara penjadwalan Pod dengan permintaan resource.
Memori:
- Pod dijadwalkan ke node berdasarkan permintaan memori yang ditentukan oleh container di Pod.
- Memori tidak boleh melebihi batas yang ditentukan oleh container.
- Jika tidak ada batas memori yang ditentukan, container mungkin akan menggunakan semua memori yang tersedia pada sebuah node. Kemudian, sistem mungkin memicu OOM-Killer (Out Of Memory Killer) dan mengeluarkan Pod prioritas rendah.

Untuk mengetahui informasi selengkapnya, lihat Menetapkan resource CPU, Menetapkan resource memori di Kubernetes, dan metrik GKE Enterprise.

Masalah

Penampung menjadi lambat

Masalah pertentangan CPU dapat menyebabkan container menjadi lambat. Berikut adalah beberapa kemungkinan alasannya:

Pemakaian CPU yang tinggi pada container:

Container dapat menjadi lambat jika tidak mendapatkan siklus CPU yang proporsional dengan permintaan CPU, atau permintaan CPU telah ditetapkan ke terlalu rendah dari yang dibutuhkan container. Jadi periksa rasio batas CPU terhadap pemakaian CPU untuk container tersebut.

Di Konsol Google Cloud > Monitoring > Metrics Explorer, di editor MQL, jalankan kueri berikut:

  fetch k8s_container
  | metric 'kubernetes.io/anthos/container/cpu/limit_utilization'
  | group_by 1m, [value_limit_utilization_mean: mean(value.limit_utilization)]
  | filter resource.cluster_name == 'CLUSTER_NAME'
  | filter resource.container_name == 'CONTAINER_NAME'
  | filter resource.pod_name == 'POD_NAME'
  | filter resource.namespace_name == 'NAMESPACE_NAME'
  | every 1m

Kemudian lakukan salah satu hal berikut:

Jika rasio ini tinggi (>=0,8), berarti batas CPU pada container rendah, dan Kubernetes membatasi siklus CPU container untuk menjaga penggunaan CPU tetap sesuai batas. Untuk mengatasi masalah ini, tingkatkan batas CPU pada container.
Jika rasio ini tidak tinggi (<0,8), periksa apakah pemakaian CPU tinggi pada node.

Pemakaian CPU yang tinggi pada node

Jika rasio batas CPU terhadap pemakaian tidak tinggi untuk setiap container Pod, mungkin node tidak memiliki cukup siklus CPU untuk dialokasikan ke kumpulan container yang berjalan di node. Jadi, ikuti langkah-langkah berikut untuk memeriksa rasio penggunaan CPU sebenarnya terhadap CPU yang dapat dialokasikan pada node:

Dapatkan node untuk Pod yang bekerja lambat:

kubectl get pod –kubeconfig CLUSTER_KUBECONFIG --namespace NAMESPACE POD --output wide

Di Konsol Google Cloud > Monitoring > Metrics Explorer, di editor MQL, jalankan kueri berikut:

fetch k8s_node
| metric 'kubernetes.io/anthos/node/cpu/allocatable_utilization'
| group_by 1m,
    [value_allocatable_utilization_mean: mean(value.allocatable_utilization)]
| filter resource.cluster_name == 'CLUSTER_NAME'
| filter resource.node_name == 'NODE_NAME'
| every 1m

Jika rasio ini tinggi (>=0,8), maka itu berarti bahwa {i>node<i} tidak memiliki siklus CPU yang cukup, dan kelebihan berlangganan. Jadi, ikuti langkah-langkah berikut untuk memeriksa penggunaan CPU semua Pod lain di node tersebut, dan selidiki apakah ada container lain yang menggunakan lebih banyak CPU.

Dapatkan semua Pod di node:

kubectl get pods --all-namespaces -o wide --field-selector spec.nodeName=NODE_NAME

Periksa pemakaian CPU di setiap container:

fetch k8s_container
| metric 'kubernetes.io/anthos/container/cpu/limit_utilization'
| group_by 1m, [value_limit_utilization_mean: mean(value.limit_utilization)]
| filter resource.cluster_name == 'CLUSTER_NAME'
| filter resource.container_name == 'CONTAINER_NAME'
| filter resource.pod_name == 'POD_NAME'
| filter resource.namespace_name == 'NAMESPACE_NAME'
| every 1m

Jika ada container lain yang menggunakan CPU tinggi pada node, tingkatkan permintaan CPU dan batas container yang bekerja lambat. Tindakan ini akan membuat ulang Pod di node lain untuk mendapatkan siklus CPU yang diperlukan.

Jika Pod sistem yang bekerja lambat, hubungi dukungan Google.

Kelebihan langganan CPU pada level vSphere

Jika konsumsi CPU di node atau Pod tidak tinggi, dan container masih lambat, VM mungkin kelebihan permintaan di level vSphere. Oleh karena itu, node tidak bisa mendapatkan siklus CPU yang diharapkan dari virtualisasi yang mendasarinya.

Ikuti langkah-langkah ini untuk memeriksa apakah VM sudah kelebihan langganan atau tidak. Jika kelebihan langganan terdeteksi, coba langkah berikut:

Memindahkan beberapa VM ke host lain.
Mengevaluasi dan mengurangi jumlah vCPU per VM untuk host.
Alokasikan lebih banyak resource ke VM GKE Enterprise.
Meningkatkan permintaan dan batas CPU untuk container. Tindakan ini akan membuat ulang Pod di node lain untuk mendapatkan siklus CPU yang diperlukan.

Pod mengalami OOMkill (Kehabisan Memori)

Pod dapat mengalami OOMKilled karena kebocoran memori, atau konfigurasi permintaan dan batas memori yang buruk pada container. Berikut adalah beberapa kemungkinan alasannya:

Penggunaan memori tinggi pada container

Pod dapat mengalami OOMkill jika ada container dalam Pod yang menggunakan total memori yang dialokasikan. Jadi, periksa rasio permintaan memori terhadap batas memori pada container.

Di Konsol Google Cloud > Monitoring > Metrics Explorer, di editor MQL, jalankan kueri berikut:

fetch k8s_container
| metric 'kubernetes.io/anthos/container/memory/limit_utilization'
| filter (metric.memory_type == 'non-evictable')
| group_by 1m, [value_limit_utilization_mean: mean(value.limit_utilization)]
| filter resource.cluster_name == 'CLUSTER_NAME'
| filter resource.container_name == 'CONTAINER_NAME'
| filter resource.pod_name == 'POD_NAME'
| filter resource.namespace_name == 'NAMESPACE_NAME'
| every 1m

Kemudian lakukan salah satu hal berikut:

Jika rasio ini tinggi (>= 0,8), tingkatkan batas memori pada container.
Jika rasio ini tidak tinggi (<0,8), periksa apakah penggunaan memori pada node tinggi.

Penggunaan memori tinggi pada node

Pod dapat mengalami OOMkill jika penggunaan memori semua Pod yang berjalan di node melebihi memori yang tersedia. Jadi, periksa apakah kondisi MemoryPressure pada node tersebut adalah True.

Jalankan perintah berikut dan periksa bagian Conditions:

kubectl describe nodes --kubeconfig CLUSTER_KUBECONFIG NODE-NAME

Jika kondisi MemoryPressure adalah True, periksa penggunaan memori pada node:

fetch k8s_node
| metric 'kubernetes.io/anthos/node/memory/allocatable_utilization'
| filter (metric.memory_type == 'non-evictable')
| group_by 1m,
    [value_allocatable_utilization_mean: mean(value.allocatable_utilization)]
| filter resource.cluster_name == 'CLUSTER_NAME'
| filter resource.node_name = 'NODE_NAME'
| every 1m

Jika rasio ini tinggi (>= 0,8), berarti node tidak memiliki cukup memori untuk dialokasikan ke Pod, mungkin karena beberapa proses atau Pod lain yang menggunakan memori tinggi.

Di Konsol Google Cloud > Monitoring > Metrics explorer, di editor MQL, jalankan kueri berikut untuk memeriksa penggunaan memori untuk container pada node:
```
fetch k8s_node
| metric 'kubernetes.io/anthos/container_memory_usage_bytes'
| filter resource.cluster_name == 'CLUSTER_NAME'
| filter resource.node_name == 'NODE_NAME'
| group_by 1m,
    [value_container_memory_usage_bytes_mean:
      mean(value.container_memory_usage_bytes)]
| every 1m
```
Jika ada container yang menggunakan memori tinggi, selidiki fungsi container tersebut atau tingkatkan permintaan memori untuk container tersebut, jika diperlukan.

Jika Pod sistem yang menggunakan memori tinggi, hubungi dukungan Google.

Selain itu, Anda dapat mengaktifkan fitur penskalaan otomatis di GKE di VMware untuk meningkatkan dan memperkecil skala kumpulan node secara otomatis berdasarkan permintaan workload Anda.

Pelajari cara mengaktifkan penghitung skala otomatis.

Masalah Etcd

Terkadang cluster Anthos di VMware mungkin mengalami kegagalan container karena masalah server etcd, dan Anda mungkin mengamati hal berikut:

Log server API berulang dari formulir:

etcdserver: request timed out dan etcdserver: leader changed
Log etcd berulang dari formulir:

W | wal: sync duration of 2.466870869s, expected less than 1s dan W | etcdserver: read-only range request * took too long

Berikut adalah beberapa kemungkinan alasannya:

Throttling CPU

Server etcd mungkin lambat karena throttling CPU pada Pod server etcd dan/atau node tempat server etcd berjalan. Lihat langkah-langkah di bagian Container menjadi lambat untuk memeriksa masalah pertentangan CPU apa pun.

Jika Anda mendeteksi pertentangan CPU di Pod server ectd atau di node, tambahkan CPU ke node bidang kontrol cluster pengguna. Gunakan gkectl update untuk mengedit kolom cpus di file konfigurasi cluster pengguna.

Pod Etcd OOMkilled

Pod etcd mungkin mengalami OOMkill karena masalah pertentangan resource. Lihat langkah-langkah di bagian Pod mendapat OOMkilled (Out of Memory-Killed) untuk memeriksa apakah ada masalah pertentangan memori dengan Pod server etcd dan/atau node tempat server etcd berjalan.

Jika Anda mendeteksi OOMkill untuk Pod dlld, tingkatkan memori yang tersedia untuk node bidang kontrol cluster pengguna. Gunakan gkectl update untuk mengedit kolom memoryMB di file konfigurasi cluster pengguna.

Kelambatan disk

Jika tidak ada masalah dengan konsumsi CPU atau memori pada Pod atau node server etcd, etcd mungkin akan lambat jika datastore yang mendasarinya lambat atau dibatasi.

Periksa masalah berikut:

Untuk memeriksa apakah server etcd memerlukan waktu terlalu lama untuk membaca/menulis ke disk yang mendasarinya:
1. Ambil log etcd:
```
kubectl –kubeconfig ADMIN_CLUSTER_KUBECONFIG logs -n ETCD_POD_NAMESPACE ETCD_POD
```
2. Cari entri pola berikut untuk mendeteksi apakah etcd memerlukan waktu terlalu lama untuk dibaca dari disk:
  
  W | etcdserver: read-only range request "key:\"/registry/configmaps/default/clusterapi-vsphere-controller-manager-leader-election\" " with result "range_response_count:1 size:685" took too long (6.893127339s) to execute
3. Cari entri pola berikut untuk mendeteksi apakah etcd memerlukan waktu terlalu lama untuk ditulis ke disk:
  
  W | wal: sync duration of 2.466870869s, expected less than 1s
Jika salah satu atau kedua pola log di atas sering muncul di log etcd, hal ini menunjukkan kelambatan disk. Kemudian, periksa performa datastore dan disk.
Untuk memeriksa metrik etcd:
1. Ambil latensi sinkronisasi dll.:
  
  Di Konsol Google Cloud > Monitoring > Metrics Explorer, di editor MQL, jalankan kueri berikut:
```
fetch k8s_container::kubernetes.io/anthos/etcd_disk_wal_fsync_duration_seconds
| every 1m
| filter resource.cluster_name == 'CLUSTER_NAME'
| filter resource.pod_name == 'POD_NAME'
| filter resource.namespace_name == 'NAMESPACE_NAME'
| percentile 99
```
2. Ambil latensi operasi tulis etcd:
  
  Di Konsol Google Cloud > Monitoring > Metrics Explorer, di editor MQL, jalankan kueri berikut:
```
fetch k8s_container::kubernetes.io/anthos/etcd_disk_backend_commit_duration_seconds
| every 1m
| filter resource.cluster_name == 'CLUSTER_NAME'
| filter resource.pod_name == 'POD_NAME'
| filter resource.namespace_name == 'NAMESPACE_NAME'
| percentile 99
```
Jika p99 untuk etcd_disk_wal_fsync_duration_seconds terus-menerus lebih dari 10 md, dan/atau p99 untuk etcd_disk_backend_commit_duration_seconds terus-menerus lebih dari 25 md, ini menunjukkan kelambatan disk. Kemudian, periksa performa datastore dan disk.

Latensi baca/tulis pada disk VM

Ikuti langkah-langkah berikut untuk memeriksa latensi baca/tulis pada disk virtual VM

Identifikasi node untuk Pod etcd yang lambat:

kubectl –kubeconfig ADMIN_CLUSTER_KUBECONFIG get pods -n ETCD_POD_NAMESPACE ETCD_POD -owide

Login ke vSphere dan pilih VM yang diidentifikasi pada langkah di atas: Di vSphere, buka Monitor > Performance > Advanced, lalu pilih Virtual Disk dari bagian View untuk mengidentifikasi latensi baca dan tulis untuk disk virtual.

Jika latensi baca/tulis disk virtual tinggi:
- Periksa VM lain yang berjalan di datastore untuk memeriksa penggunaan operasi input/output per detik (IOPS) yang tinggi. Jika ada VM yang menunjukkan lonjakan IOPS, nilai fungsi VM tersebut.
- Konsultasikan dengan tim lab/infra Anda untuk memastikan bahwa bandwidth baca dan tulis tidak di-throttle atau dibatasi kapan saja.
- Konsultasikan dengan tim lab/infra Anda untuk mengidentifikasi masalah performa disk dan performa penyimpanan, jika ada.

Untuk mengetahui informasi selengkapnya, lihat praktik terbaik untuk menskalakan resource.

Masalah server API

Jika container di GKE pada VMware Anda mengalami latensi saat berkomunikasi dengan server API, atau perintah Kubectl gagal atau memerlukan waktu terlalu lama untuk merespons, hal ini mungkin menunjukkan masalah pada server API.

Berikut adalah beberapa kemungkinan alasannya:

Volume permintaan API yang tinggi

Server API mungkin lambat merespons jika frekuensi dan volume permintaan terlalu tinggi. Waktu respons yang lambat dapat tetap bertahan bahkan setelah server API mulai menekan permintaan. Jadi, periksa tingkat permintaan API di server API.

Di Konsol Google Cloud > Monitoring > Metrics Explorer, di editor MQL, jalankan kueri berikut:

fetch k8s_container::kubernetes.io/anthos/apiserver_request_total
| filter resource.cluster_name == 'CLUSTER_NAME'
| filter resource.pod_name == 'APISERVER_POD_NAME'
| filter resource.namespace_name == 'NAMESPACE_NAME'
| align rate(1m)
| every 1m
| group_by [metric.verb]

Jika ada peningkatan tak terduga dalam permintaan API, gunakan Logging audit cloud untuk mengidentifikasi Pod yang mungkin terlalu sering mengkueri server API.

Jika berupa Pod sistem, hubungi dukungan Google.
Jika ini adalah Pod pengguna, selidiki lebih lanjut untuk menentukan apakah permintaan API diharapkan.

Throttling CPU

Tingkat permintaan yang tinggi di server API dapat menyebabkan throttling CPU. Kemudian, server API mungkin menjadi lambat karena pertentangan CPU pada Pod server API dan/atau node.

Lihat bagian Container menjadi lambat untuk memeriksa masalah pertentangan CPU dengan Pod dan/atau node.

Pod server API OOMkilled

Pod server API mungkin mengalami OOMkilled karena masalah pertentangan resource. Lihat langkah-langkah di bagian Pod mendapat OOMkilled (Out of Memory-Killed) untuk memeriksa masalah pertentangan memori dengan Pod dan/atau node.

Respons etcd lambat

Server API bergantung pada komunikasi dengan cluster etcd untuk menyalurkan permintaan baca / tulis ke klien. Jika etcd lambat atau tidak responsif, server API juga menjadi lambat.

Ambil log server API untuk memeriksa apakah server API lambat karena masalah etcd:

kubectl –kubeconfig ADMIN_CLUSTER_KUBECONFIG logs -n APISERVER_NAMESPACE APISERVER_POD_NAME

Jika Anda mengamati log berulang seperti etcdserver: request timedout atau etcdserver: leader changed, ikuti langkah-langkah dalam masalah Etcd untuk menyelesaikan masalah terkait disk.