Cluster Anthos di VMware kini menjadi Google Distributed Cloud (khusus software) untuk VMware. Untuk mengetahui informasi selengkapnya, lihat ringkasan produk.

Halaman ini diterjemahkan oleh Cloud Translation API.

Memecahkan masalah pertentangan resource

Halaman ini menjelaskan cara mengidentifikasi dan memecahkan masalah pertentangan resource di lingkungan Google Distributed Cloud Anda.

Jika Anda memerlukan bantuan tambahan, hubungi Cloud Customer Care.

Ringkasan

Terkadang, Google Distributed Cloud Anda mungkin mengalami pertentangan resource, yang menyebabkan penampung melambat, berperforma buruk, atau dihentikan. Hal ini dapat terjadi karena konsumsi CPU atau memori yang tinggi oleh penampung.

Cara kerja pengelolaan CPU dan memori

CPU:
- Pod dijadwalkan ke node berdasarkan permintaan CPU yang ditentukan oleh penampung di Pod.
- Container dalam Pod tidak dapat menggunakan lebih banyak CPU daripada batas yang ditentukan oleh container
- Penggunaan CPU container dibatasi pada batas CPU.
- Jika penggunaan CPU dibatasi di tingkat node, container akan otomatis diberi siklus CPU yang sebanding dengan permintaan.
Pelajari lebih lanjut cara Pod dengan permintaan resource dijadwalkan.
Memori:
- Pod dijadwalkan ke node berdasarkan permintaan memori yang ditentukan oleh penampung di Pod.
- Penampung tidak dapat menggunakan lebih banyak memori daripada batas yang ditentukan oleh penampung.
- Jika tidak ada batas memori yang ditentukan, penampung dapat menggunakan semua memori yang tersedia di node. Kemudian, sistem mungkin memicu OOM-Killer (Out Of Memory Killer) dan mengeluarkan Pod berprioritas 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 penampung menjadi lambat. Berikut adalah beberapa kemungkinan alasannya:

Penggunaan CPU yang tinggi pada penampung:

Penampung dapat menjadi lambat jika tidak mendapatkan siklus CPU yang sebanding dengan permintaan CPU, atau permintaan CPU telah ditetapkan terlalu rendah dari yang diperlukan penampung. Jadi, periksa rasio batas CPU terhadap penggunaan CPU untuk penampung.

Di Konsol Google Cloud > Monitoring > Metrics Explorer, di MQL editor, 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 tindakan berikut:

Jika rasio ini tinggi (>=0,8), berarti batas CPU pada penampung rendah, dan Kubernetes membatasi siklus CPU penampung agar penggunaan CPU tetap dalam batas. Untuk mengatasi masalah ini, tingkatkan batas CPU pada penampung.
Jika rasio ini tidak tinggi (<0,8), periksa apakah penggunaan CPU tinggi di node.

Pemakaian CPU yang tinggi di node

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

Dapatkan node untuk Pod yang berjalan lambat:

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

Di Konsol Google Cloud > Monitoring > Metrics Explorer, di MQL editor, 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), artinya node tidak memiliki siklus CPU yang cukup, dan kelebihan permintaan. Jadi, ikuti langkah-langkah berikut untuk memeriksa penggunaan CPU untuk semua Pod lain di node tersebut, dan selidiki apakah ada penampung 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 penggunaan CPU di setiap penampung:

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 penampung lain yang menggunakan CPU tinggi di node, tingkatkan permintaan dan batas CPU pada penampung yang bekerja lambat. Tindakan ini akan membuat ulang Pod di node lain untuk mendapatkan siklus CPU yang diperlukan.

Jika Pod sistem yang lambat, hubungi dukungan Google.

Oversubscription CPU di tingkat vSphere

Jika konsumsi CPU tidak tinggi di node atau Pod, dan penampung masih lambat, VM mungkin kelebihan langganan di tingkat vSphere. Oleh karena itu, node tidak dapat mendapatkan siklus CPU yang diharapkan dari virtualisasi yang mendasarinya.

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

Pindahkan beberapa VM ke host lain.
Evaluasi, dan kurangi jumlah vCPU per VM, untuk host.
Alokasikan lebih banyak resource ke VM GKE Enterprise.
Meningkatkan permintaan dan batas CPU pada penampung. Tindakan ini akan membuat ulang Pod di node lain untuk mendapatkan siklus CPU yang diperlukan.

Pod di-OOMkill (Out of Memory-Killed)

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

Penggunaan memori yang tinggi pada penampung

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

Di Konsol Google Cloud > Monitoring > Metrics Explorer, di MQL editor, 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 tindakan berikut:

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

Penggunaan memori yang tinggi di node

Pod dapat di-OOMkill jika penggunaan memori semua Pod yang berjalan di node melebihi memori yang tersedia. Jadi, periksa apakah kondisi MemoryPressure di node 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 di 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 menggunakan memori yang tinggi.

Di Konsol Google Cloud > Monitoring > Metrics Explorer, di MQL editor, jalankan kueri berikut untuk memeriksa penggunaan memori untuk penampung di 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 penampung yang menggunakan memori tinggi, selidiki fungsi penampung atau tingkatkan permintaan memori untuk penampung, jika diperlukan.

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

Selain itu, Anda dapat mengaktifkan fitur penskalaan otomatis di Google Distributed Cloud untuk menskalakan dan menskalakan turun node pool secara otomatis berdasarkan permintaan workload Anda.

Pelajari cara mengaktifkan autoscaler.

Masalah Etcd

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

Log server API berulang dalam bentuk:

etcdserver: request timed out dan etcdserver: leader changed
Log etcd berulang dalam bentuk:

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 di Pod server etcd dan/atau node tempat server etcd berjalan. Lihat langkah-langkah di bagian Penampung menjadi lambat untuk memeriksa masalah pertentangan CPU.

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 dalam file konfigurasi cluster pengguna.

Etcd Pod OOMkilled

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

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

Lambatnya disk

Jika tidak ada masalah dengan penggunaan CPU atau memori di Pod server etcd atau node, etcd mungkin lambat jika datastore pokok 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 membaca 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 menulis 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 lambatnya disk. Kemudian, periksa performa datastore dan disk.

Untuk memeriksa metrik etcd:

Ambil latensi sinkronisasi wal etcd:

Di Konsol Google Cloud > Monitoring > Metrics Explorer, di MQL editor, 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

Ambil latensi tulis etcd:

Di Konsol Google Cloud > Monitoring > Metrics Explorer, di MQL editor, 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, hal ini menunjukkan lambatnya 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/infrastruktur Anda untuk memastikan bandwidth baca dan tulis tidak dibatasi atau dithrottle kapan saja.
- Hubungi tim lab/infrastruktur 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 penampung di Google Distributed Cloud 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 di dalamnya terlalu tinggi. Waktu respons lambat mungkin tetap ada bahkan setelah server API mulai membatasi permintaan. Jadi, periksa frekuensi permintaan API di server API.

Di Konsol Google Cloud > Monitoring > Metrics Explorer, di MQL editor, 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 permintaan API yang tidak terduga, gunakan Logging audit Cloud untuk mengidentifikasi Pod yang mungkin terlalu sering mengkueri server API.

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

Throttling CPU

Rasio 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 Penampung 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 gets OOMkilled (Out of Memory-Killed) untuk memeriksa masalah pertentangan memori dengan Pod dan/atau node.

Respons etcd lambat

Server API mengandalkan komunikasi dengan cluster etcd untuk menayangkan permintaan baca / tulis ke klien. Jika etcd lambat atau tidak responsif, server API juga akan 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 di Masalah Etcd untuk menyelesaikan masalah terkait disk.

Jika cluster Anda tidak mengekspor metrik

Teknik yang ditampilkan sebelumnya dalam dokumen ini mengandalkan metrik yang diekspor dari cluster Anda ke project Google Cloud.

Jika cluster tidak mengekspor metrik, Anda dapat menggunakan command line untuk menyelidiki pertentangan resource. Berikut beberapa perintah yang dapat Anda jalankan di workstation admin untuk melihat metrik.

Melihat metrik untuk node:

kubectl --kubeconfig CLUSTER_KUBECONFIG get --raw \
    /apis/metrics.k8s.io/v1beta1/nodes/NODE_NAME | jq

Ganti kode berikut:

CLUSTER_KUBECONFIG: jalur file kubeconfig cluster
NODE_NAME: nama node

Melihat metrik untuk Pod:

kubectl --kubeconfig CLUSTER_KUBECONFIG get --raw \
    /apis/metrics.k8s.io/v1beta1/namespaces/NAMESPACE/pods/POD_NAME | jq

Ganti kode berikut:

NAMESPACE: namespace Pod
POD_NAME: nama Pod

Melihat metrik untuk semua node:

kubectl --kubeconfig CLUSTER_KUBECONFIG top node

Melihat metrik untuk semua Pod dalam namespace:

kubectl --kubeconfig CLUSTER_KUBECONFIG top pod --namespace NAMESPACE

Lihat metrik untuk penampung di semua Pod dalam namespace:

kubectl --kubeconfig CLUSTER_KUBECONFIG top pod --containers --namespace NAMESPACE

Untuk mengetahui informasi selengkapnya, lihat kubectl top pod dan kubectl top node.

Anda juga dapat menjalankan perintah top dari dalam penampung yang berjalan di node.

Berikut adalah dua cara untuk menjalankan perintah di dalam penampung:

Di workstation admin, jalankan kubectl exec untuk memasukkan shell ke dalam penampung. Jalankan perintah di shell.
Dapatkan koneksi SSH ke node. Kemudian, gunakan docker exec untuk memasukkan shell ke dalam penampung. Jalankan perintah di shell.

Langkah selanjutnya

Jika Anda memerlukan bantuan tambahan, hubungi Cloud Customer Care.