Memecahkan masalah perebutan resource

Anda dapat mengatasi container yang lambat, berperforma buruk, atau dihentikan di Google Distributed Cloud dengan mendiagnosis pertentangan resource. Penyebab umumnya meliputi throttling CPU, Pod OOMKilled, latensi server etcd dan Server API, serta bottleneck CPU atau penyimpanan vSphere. Mengidentifikasi penyebabnya akan membantu Anda menyesuaikan resource untuk workload, node, dan VM agar cluster tetap stabil.

Ringkasan

Terkadang Google Distributed Cloud Anda mungkin mengalami pertentangan resource, sehingga menyebabkan container melambat, berperforma buruk, atau dihentikan. Hal ini dapat terjadi karena konsumsi CPU atau memori yang tinggi 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 CPU lebih banyak daripada batas yang ditentukan oleh container
    • Penggunaan CPU container dibatasi pada batas CPU.
    • Jika penggunaan CPU dibatasi di level node, container akan otomatis diberi siklus CPU yang proporsional dengan permintaan.

    Pelajari lebih lanjut cara Pod dengan permintaan resource dijadwalkan.

  • Memori:

    • Pod dijadwalkan ke node berdasarkan permintaan memori yang ditentukan oleh container dalam Pod.
    • Container tidak dapat menggunakan memori lebih dari batas yang ditentukan oleh container.
    • Jika tidak ada batas memori yang ditentukan, container dapat menggunakan semua memori yang tersedia di node. Kemudian, sistem mungkin akan memicu OOM-Killer (kehabisan memori) dan mengeluarkan Pod berprioritas rendah.

Untuk informasi selengkapnya, lihat referensi berikut:

Masalah

Container menjadi lambat

Masalah pertentangan CPU dapat menyebabkan container menjadi lambat. Berikut 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 lebih rendah dari yang dibutuhkan container. Jadi, periksa rasio batas CPU terhadap pemakaian CPU untuk container.

Di konsol Google Cloud > Monitoring > Metrics explorer, di PromQL editor, jalankan kueri berikut:

  avg_over_time({
    "__name__"="kubernetes.io/anthos/container/cpu/limit_utilization",
    "monitored_resource"="k8s_container",
    "cluster_name"="CLUSTER_NAME",
    "container_name"="CONTAINER_NAME",
    "pod_name"="POD_NAME",
    "namespace_name"="NAMESPACE_NAME"
  }[${__interval}])

Kemudian, lakukan salah satu tindakan berikut:

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:

  1. Dapatkan node untuk Pod yang berjalan lambat:

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

  2. Di Google Cloud console > Monitoring > Metrics explorer, di PromQL editor, jalankan kueri berikut:

    avg_over_time({
  "__name__"="kubernetes.io/anthos/node/cpu/allocatable_utilization",
  "monitored_resource"="k8s_node",
  "cluster_name"="CLUSTER_NAME",
  "node_name"="NODE_NAME"
}[${__interval}])

    Jika rasio ini tinggi (>=0,8), berarti 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 container lain yang menggunakan lebih banyak CPU.

    1. Dapatkan semua Pod di node:
    kubectl get pods --all-namespaces -o wide --field-selector spec.nodeName=NODE_NAME
    1. Periksa pemakaian CPU di setiap container:
    avg_over_time({
  "__name__"="kubernetes.io/anthos/container/cpu/limit_utilization",
  "monitored_resource"="k8s_container",
  "cluster_name"="CLUSTER_NAME",
  "container_name"="CONTAINER_NAME",
  "pod_name"="POD_NAME",
  "namespace_name"="NAMESPACE_NAME"
}[${__interval}])

    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 sistem yang berjalan lambat, hubungi dukungan Google.

Oversubscription CPU di tingkat vSphere

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

Ikuti langkah-langkah ini untuk memeriksa apakah VM mengalami oversubscription. Jika langganan berlebih terdeteksi, coba langkah berikut:

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

Pod mengalami OOMkilled (Out of Memory-Killed)

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

Penggunaan memori yang tinggi pada container

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

Di Google Cloud console > Monitoring > Metrics explorer, di PromQL editor, jalankan kueri berikut:

avg_over_time({
  "__name__"="kubernetes.io/anthos/container/memory/limit_utilization",
  "monitored_resource"="k8s_container",
  "memory_type"="non-evictable",
  "cluster_name"="CLUSTER_NAME",
  "container_name"="CONTAINER_NAME",
  "pod_name"="POD_NAME",
  "namespace_name"="NAMESPACE_NAME"
}[${__interval}])

Kemudian, lakukan salah satu tindakan berikut:

Penggunaan memori yang tinggi pada node

Pod dapat dihentikan karena kehabisan memori (OOMkilled) jika penggunaan memori semua Pod yang berjalan di node melebihi memori yang tersedia. Jadi, periksa apakah kondisi MemoryPressure pada node adalah True.

  1. Jalankan perintah berikut dan periksa bagian Conditions:

    kubectl describe nodes --kubeconfig CLUSTER_KUBECONFIG NODE-NAME

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

    avg_over_time({
  "__name__"="kubernetes.io/anthos/node/memory/allocatable_utilization",
  "monitored_resource"="k8s_node",
  "memory_type"="non-evictable",
  "cluster_name"="CLUSTER_NAME",
  "node_name"="NODE_NAME",
}[${__interval}])

    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.

  3. Di Google Cloud console > Monitoring > Metrics explorer, di PromQL editor, jalankan kueri berikut untuk memeriksa penggunaan memori untuk container pada node:

    avg_over_time({
  "__name__"="kubernetes.io/anthos/container_memory_usage_bytes",
  "monitored_resource"="k8s_node",
  "cluster_name"="CLUSTER_NAME",
  "node_name"="NODE_NAME",
}[${__interval}])

    Jika ada container yang menggunakan memori tinggi, selidiki fungsi container atau tingkatkan permintaan memori untuk container, 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 meningkatkan dan memperkecil skala node pool secara otomatis berdasarkan permintaan workload Anda.

Pelajari cara mengaktifkan autoscaler.

Masalah etcd

Terkadang, cluster Anthos di VMware Anda mungkin mengalami kegagalan container karena masalah server etcd, dan Anda mungkin mengamati 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 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.

Jika Anda mendeteksi pertentangan CPU pada Pod server ectd atau pada 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 OOMkilled karena masalah pertentangan resource. Lihat langkah-langkah di bagian Pod mendapatkan OOMkilled (Out of Memory-Killed) untuk memeriksa masalah pertentangan memori dengan Pod server etcd dan/atau node tempat server etcd berjalan.

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

Disk lambat

Jika tidak ada masalah dengan konsumsi CPU atau memori pada Pod server etcd atau node, etcd mungkin 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 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 kelambatan disk. Kemudian, periksa performa datastore dan disk.

  • Untuk memeriksa metrik etcd:

    1. Ambil latensi sinkronisasi wal etcd:

      Di Google Cloud console > Monitoring > Metrics explorer, di PromQL editor, jalankan kueri berikut:

      histogram_quantile(0.99,
  sum by ("le") (
    increase({
      "__name__"="kubernetes.io/anthos/etcd_disk_wal_fsync_duration_seconds_bucket",
      "monitored_resource"="k8s_container",
      "cluster_name"="CLUSTER_NAME",
      "pod_name"="POD_NAME",
      "namespace_name"="NAMESPACE_NAME"
    }[${__interval}])
  )
)

    2. Ambil latensi tulis etcd:

      Di Google Cloud console > Monitoring > Metrics explorer, di PromQL editor, jalankan kueri berikut:

      histogram_quantile(0.99,
  sum by ("le") (
    increase({
      "__name__"="kubernetes.io/anthos/etcd_disk_backend_commit_duration_seconds",
      "monitored_resource"="k8s_container",
      "cluster_name"="CLUSTER_NAME",
      "pod_name"="POD_NAME",
      "namespace_name"="NAMESPACE_NAME"
    }[${__interval}])
  )
)

    Jika p99 untuk etcd_disk_wal_fsync_duration_seconds terus-menerus di atas 10 md, dan/atau p99 untuk etcd_disk_backend_commit_duration_seconds terus-menerus di atas 25 md, hal 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

  1. Identifikasi node untuk Pod etcd yang lambat:

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

  2. Login ke vSphere dan pilih VM yang diidentifikasi pada langkah sebelumnya: 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 dibatasi atau dibatasi pada titik mana pun.
    • Hubungi 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 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 mengindikasikan masalah pada server API.

Berikut beberapa kemungkinan alasannya:

Volume permintaan API yang tinggi

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

Di Google Cloud console > Monitoring > Metrics explorer, di PromQL editor, jalankan kueri berikut:

sum by (verb) (
  rate({
    "__name__"="kubernetes.io/anthos/apiserver_request_total",
    "monitored_resource"="k8s_container",
    "cluster_name"="CLUSTER_NAME",
    "pod_name"="APISERVER_POD_NAME",
    "namespace_name"="NAMESPACE_NAME"
   }[${__interval}])
)

Jika ada peningkatan permintaan API yang tidak terduga, gunakan Cloud audit logging untuk mengidentifikasi Pod yang mungkin terlalu sering mengkueri server API.

  • Jika Pod tersebut adalah Pod sistem, hubungi dukungan Google.
  • Jika Pod tersebut adalah Pod pengguna, selidiki lebih lanjut untuk menentukan apakah permintaan API tersebut memang 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 Container menjadi lambat untuk memeriksa masalah pertentangan CPU dengan Pod dan/atau node.

Pod server API dihentikan karena kehabisan memori (OOMkilled)

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

Respons etcd lambat

Server API mengandalkan komunikasi dengan cluster etcd untuk melayani 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 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 mengandalkan metrik yang diekspor dari cluster Anda ke project Google Cloud .

Jika cluster Anda 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

Melihat 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 di node.

Berikut dua cara untuk menjalankan perintah di dalam container:

Langkah berikutnya

Jika Anda memerlukan bantuan tambahan, hubungi Cloud Customer Care.

Anda juga dapat melihat Mendapatkan dukungan untuk mengetahui informasi selengkapnya tentang referensi dukungan, termasuk referensi berikut:

  • Persyaratan untuk membuka kasus dukungan.
  • Alat untuk membantu Anda memecahkan masalah, seperti log dan metrik.
  • Komponen, versi, dan fitur Google Distributed Cloud untuk VMware (khusus software) yang didukung.