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 container Anda melambat, berperforma buruk, atau dihentikan. Hal ini dapat terjadi karena konsumsi CPU atau memori yang tinggi oleh container.

Cara kerja manajemen memori dan CPU

CPU:
- Pod dijadwalkan ke node berdasarkan permintaan CPU yang ditentukan oleh container di Pod.
- Container dalam Pod tidak dapat menggunakan lebih banyak CPU dari batas yang ditentukan oleh container
- Penggunaan CPU container dibatasi pada batas CPU.
- Jika penggunaan CPU di-throttle pada level node, container akan otomatis diberi siklus CPU yang sesuai dengan permintaan.
Pelajari lebih lanjut cara Pod dengan permintaan resource dijadwalkan.
Memori:
- Pod dijadwalkan ke node berdasarkan permintaan memori yang ditentukan oleh container di Pod.
- Container tidak dapat menggunakan memori lebih dari batas yang ditentukan oleh container.
- Jika tidak ada batas memori yang ditentukan, container mungkin menggunakan semua memori yang tersedia pada node. Kemudian, sistem dapat 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

Container 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 disetel terlalu rendah daripada yang diperlukan container. Jadi, periksa rasio batas CPU terhadap pemakaian CPU untuk container.

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 melakukan throttling pada siklus CPU container untuk menjaga penggunaan CPU agar tidak melebihi batas. Untuk mengatasi masalah ini, tingkatkan batas CPU pada container.
Jika rasio ini tidak tinggi (<0,8), periksa apakah penggunaan CPU pada node tinggi.

Pemakaian CPU yang tinggi pada node

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

Dapatkan node untuk Pod yang berfungsi 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), berarti node tersebut tidak memiliki siklus CPU yang cukup, dan kelebihan langganan. Jadi, ikuti langkah-langkah berikut untuk memeriksa penggunaan CPU oleh semua Pod lain pada 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 dan batas CPU pada container yang bekerja lambat. Tindakan ini akan membuat ulang Pod di node lain untuk mendapatkan siklus CPU yang diperlukan.

Jika Pod sistemnya berfungsi lambat, hubungi dukungan Google.

Oversubscription CPU di level vSphere

Jika konsumsi CPU tidak tinggi di node atau Pod, dan container masih lambat, maka VM mungkin akan kelebihan langganan pada 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 kelebihan langganan. Jika langganan berlebih terdeteksi, coba langkah berikut:

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

Pod di-OOMkilled (Out of Memory-Killed)

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

Penggunaan memori tinggi pada container

Pod bisa mengalami OOMkilled jika salah satu container dalam Pod menggunakan lebih dari 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 OOMkilled jika penggunaan memori semua Pod yang berjalan pada node melebihi memori yang tersedia. Jadi, pastikan kondisi MemoryPressure pada node adalah True.

Jalankan perintah berikut dan periksa bagian Conditions:

kubectl describe nodes --kubeconfig CLUSTER_KUBECONFIG NODE-NAME

Jika kondisi MemoryPressure adalah True, periksa pemakaian 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 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 atau tingkatkan permintaan memori untuk container tersebut, jika diperlukan.

Jika Pod sistem menggunakan memori tinggi, hubungi dukungan Google.

Selain itu, Anda dapat mengaktifkan fitur penskalaan otomatis di Google Distributed Cloud untuk meningkatkan skala dan menurunkan skala kumpulan node secara otomatis berdasarkan permintaan workload Anda.

Pelajari cara mengaktifkan autoscaler.

Masalah Etcd

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

Log server API berulang untuk formulir:

etcdserver: request timed out dan etcdserver: leader changed
Log dst yang berulang dalam bentuk ini:

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 menjadi 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 apakah ada masalah pertentangan CPU.

Jika Anda mendeteksi pertentangan CPU di Pod server berikutnya 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 dll. mungkin mengalami OOMkil karena masalah pertentangan resource. Lihat langkah-langkah di bagian Pod mendapatkan 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 dll, 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 server etcd atau node, etcd mungkin berjalan 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 dll.:
```
kubectl –kubeconfig ADMIN_CLUSTER_KUBECONFIG logs -n ETCD_POD_NAMESPACE ETCD_POD
```
2. Cari entri dari pola berikut untuk mendeteksi apakah {i>etcd<i} 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 dari pola berikut untuk mendeteksi apakah {i>etcd<i} 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 ditampilkan dalam log etcd, hal ini menunjukkan kelambatan disk. Lalu periksa performa datastore dan disk.
Untuk memeriksa metrik dll.:
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 tulis dst:
  
  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, hal ini menunjukkan kelambatan disk. Lalu 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 dll. 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 bandwidth baca dan tulis tidak terhambat atau dibatasi kapan saja.
- Konsultasikan dengan tim lab/infra Anda untuk mengidentifikasi masalah performa disk dan performa penyimpanan, jika ada.

Untuk informasi selengkapnya, lihat praktik terbaik untuk menskalakan resource.

Masalah server API

Jika container di Google Distributed Cloud Anda mengalami latensi saat berkomunikasi dengan server API, atau perintah Kubectl gagal atau memakan waktu terlalu lama untuk merespons, hal ini mungkin menunjukkan adanya 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 mungkin tetap ada bahkan setelah server API mulai melakukan throttling permintaan. Jadi, periksalah laju 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 terjadi peningkatan yang tidak terduga pada permintaan API, gunakan Cloud audit logging untuk mengidentifikasi Pod yang mungkin terlalu sering mengkueri server API.

Jika klien tersebut adalah 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 pada server API dapat menyebabkan throttling CPU. Maka, server API mungkin menjadi lambat karena pertentangan CPU pada Pod server API dan/atau node.

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

Pod server API OOMkilled

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

Respons dsbd lambat

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

Ambil log server API untuk memeriksa apakah server API lambat karena masalah dll.:

kubectl –kubeconfig ADMIN_CLUSTER_KUBECONFIG logs -n APISERVER_NAMESPACE APISERVER_POD_NAME

Jika Anda melihat 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 bergantung pada 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 dijalankan 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

Lihat metrik untuk semua node:

kubectl --kubeconfig CLUSTER_KUBECONFIG top node

Lihat metrik untuk semua Pod dalam namespace:

kubectl --kubeconfig CLUSTER_KUBECONFIG top pod --namespace NAMESPACE

Lihat metrik untuk container 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 container yang berjalan pada node.

Berikut dua cara untuk menjalankan perintah di dalam container:

Di workstation admin, jalankan kubectl exec untuk memasukkan shell ke dalam container. Jalankan perintah di shell.
Mendapatkan koneksi SSH ke node. Lalu, gunakan docker exec untuk memasukkan shell ke dalam container. Jalankan perintah di shell.

Langkah selanjutnya

Jika Anda memerlukan bantuan tambahan, hubungi Cloud Customer Care.