Memecahkan masalah pertentangan resource

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

Ringkasan

Terkadang, Google Distributed Cloud Anda mungkin mengalami perebutan 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 pengelolaan CPU dan memori

  • CPU:

    • Pod dijadwalkan ke node berdasarkan permintaan CPU yang ditentukan oleh container dalam Pod.
    • Container dalam Pod tidak dapat menggunakan lebih banyak CPU daripada batas yang ditentukan oleh container
    • Penggunaan CPU container di-throttle pada batas CPU.
    • Jika penggunaan CPU di-throttle di tingkat 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 dapat memicu OOM-Killer (Out Of Memory Killer) dan mengeluarkan Pod berprioritas rendah.

Untuk informasi selengkapnya, lihat referensi berikut:

Masalah

Container menjadi lambat

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

Penggunaan CPU yang tinggi pada container:

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

Di Google Cloud console > 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:

Penggunaan CPU yang tinggi pada node

Jika rasio batas CPU terhadap pemakaian 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 pada node:

  1. Dapatkan node untuk Pod yang bekerja lambat:

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

  2. Di Google Cloud console > 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), berarti node tidak memiliki siklus CPU yang cukup, dan kelebihan langganan. 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. Mendapatkan semua Pod di node:
    kubectl get pods --all-namespaces -o wide --field-selector spec.nodeName=NODE_NAME
    1. 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 di node, tingkatkan permintaan dan batas CPU pada container yang berjalan 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.

Oversubscription CPU di tingkat vSphere

Jika konsumsi CPU tidak tinggi di node atau Pod, dan container masih lambat, maka VM mungkin terlalu banyak menggunakan resource di tingkat vSphere. Oleh karena itu, node tidak dapat memperoleh siklus CPU yang diharapkan dari virtualisasi yang mendasarinya.

Ikuti langkah-langkah ini untuk memeriksa apakah VM kelebihan langganan. Jika oversubscription 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 cluster.
  • Tingkatkan permintaan dan batas CPU pada container. Tindakan ini akan membuat ulang Pod di node lain untuk mendapatkan siklus CPU yang diperlukan.

Pod dihentikan karena kehabisan memori (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 total memori yang dialokasikan secara berlebihan. Jadi, periksa rasio permintaan memori terhadap batas memori pada container.

Di Google Cloud console > 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:

Penggunaan memori yang tinggi pada node

Pod dapat dihentikan karena kehabisan memori 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 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, kemungkinan karena beberapa proses atau Pod lain menggunakan memori yang tinggi.

  3. Di Google Cloud console > 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 container yang menggunakan memori tinggi, selidiki fungsi container atau tambah permintaan memori untuk container, jika perlu.

Jika Pod sistem menggunakan memori tinggi, hubungi dukungan Google.

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

Pelajari cara mengaktifkan penskala otomatis.

Masalah etcd

Terkadang, cluster Anthos di VMware Anda mungkin mengalami kegagalan container 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 beberapa kemungkinan alasannya:

Throttling CPU

Server etcd mungkin lambat karena pembatasan CPU pada Pod server etcd dan/atau node tempat server etcd berjalan. Lihat langkah-langkah di bagian Penampung menjadi lambat untuk memeriksa masalah persaingan CPU.

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

Pod Etcd dihentikan karena kehabisan memori

Pod etcd mungkin dihentikan karena kehabisan memori (OOM) akibat masalah perebutan resource. Lihat langkah-langkah di bagian Pod dihentikan karena kehabisan memori (OOMkilled) untuk memeriksa masalah perebutan 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 dalam file konfigurasi cluster pengguna.

Disk lambat

Jika tidak ada masalah dengan penggunaan CPU atau memori di Pod atau node server etcd, 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 dengan pola berikut untuk mendeteksi apakah etcd membutuhkan 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 dengan pola berikut untuk mendeteksi apakah etcd membutuhkan 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 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

    2. Ambil latensi tulis etcd:

      Di Google Cloud console > 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 di atas 10 md, dan/atau p99 untuk etcd_disk_backend_commit_duration_seconds terus-menerus di atas 25 md, hal ini menunjukkan disk lambat. 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 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 dibatasi atau dibatasi kapan pun.
    • 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 Google Distributed Cloud Anda mengalami latensi saat berkomunikasi dengan server API, atau perintah Kubectl gagal atau terlalu lama merespons, hal ini mungkin menunjukkan masalah pada server API.

Berikut beberapa kemungkinan alasannya:

Volume permintaan API yang tinggi

Server API mungkin lambat merespons jika frekuensi dan volume permintaan di server tersebut terlalu tinggi. Waktu respons yang lambat dapat terus terjadi meskipun setelah server API mulai membatasi permintaan. Jadi, periksa frekuensi permintaan API di server API.

Di Google Cloud console > 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 Cloud Audit Logging untuk mengidentifikasi Pod yang mungkin terlalu sering membuat kueri server API.

  • Jika itu adalah Pod sistem, hubungi dukungan Google.
  • Jika itu adalah Pod pengguna, selidiki lebih lanjut untuk menentukan apakah permintaan API sudah sesuai.

Throttling CPU

Rasio permintaan yang tinggi di server API dapat menyebabkan pembatasan CPU. Kemudian, server API mungkin menjadi lambat karena persaingan CPU di Pod dan/atau node server API.

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

Pod server API dihentikan karena kehabisan memori

Pod server API mungkin dihentikan karena masalah perebutan resource. Lihat langkah-langkah di bagian Pod dihentikan karena kehabisan memori (OOMkilled) untuk memeriksa apakah ada masalah perebutan 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 tidak mengekspor metrik, Anda dapat menggunakan command line untuk menyelidiki perebutan 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 bagian Mendapatkan dukungan untuk mengetahui informasi selengkapnya tentang sumber dukungan, termasuk: