Mengamati workload hierarkis

Beta

Produk atau fitur ini tunduk pada "Persyaratan Penawaran Pra-GA" di bagian Persyaratan Layanan Umum di Persyaratan Khusus Layanan. Produk dan fitur pra-GA tersedia "sebagaimana adanya" dan mungkin memiliki dukungan terbatas. Untuk mengetahui informasi selengkapnya, lihat deskripsi tahap peluncuran.

Perhatian: Mulai Desember 2024, Anda tidak dapat lagi menginstal Pengontrol Hierarki. Config Sync akan diblokir dari upgrade jika Pengontrol Hierarki dikonfigurasi sebagai fitur armada configmanagement atau melalui ConfigManagement API. Untuk bermigrasi ke Pengontrol Namespace Hierarkis (HNC), yang menjadi dasar Pengontrol Hierarki dan menawarkan fungsi serupa, lihat Bermigrasi dari Pengontrol Hierarki ke Pengontrol Namespace Hierarkis.

Hierarchy Controller memberikan visibilitas yang lebih baik ke dalam workload Anda dengan menggunakan namespace hierarkis dan abstrak di cluster Anda. Hal ini dilakukan dengan menyebarkan label hierarki cluster ke Pod, sehingga tersedia untuk sistem apa pun yang dapat menyerap label Kubernetes, termasuk:

• Kueri Kubernetes native untuk Pod
• Cloud Logging
• Pengukuran penggunaan GKE

Misalnya, pertimbangkan workload yang berjalan di namespace dari repositori contoh pewarisan namespace. Repositori contoh pewarisan namespace memiliki arsitektur berikut:

├── namespaces # Namespace directory
│   ├── eng # Namespace directory
│   │   ├── analytics # Abstract namespace directory
│   │   └── gamestore # Abstract namespace directory
│   ├── rnd # Namespace directory
│   │   ├── incubator-1 # Abstract namespace directory
│   │   └── incubator-2 # Abstract namespace directory
|   |── network-policy-default-deny-all.yaml
|   |── viewers-rolebinding.yaml

Pengontrol Hierarki memungkinkan Anda memilih Pod, log, atau pengukuran penggunaan yang dihasilkan oleh workload apa pun yang merupakan turunan dari eng, rnd, atau namespace abstrak lainnya. Hal ini tidak hanya mencakup workload di namespace yang terletak di repositori Git seperti gamestore, tetapi juga namespace turunan Pengontrol Hierarki yang mungkin Anda buat sebagai turunan namespace tersebut.

Mengaktifkan visibilitas hierarkis

Catatan: Observabilitas hierarkis tidak didukung di cluster Autopilot untuk saat ini.

Observabilitas hierarkis disediakan oleh Pengontrol Hierarki. Untuk mengaktifkan visibilitas hierarkis, lakukan hal berikut:

1. Menginstal Pengontrol Hierarki.

2. Dalam file konfigurasi untuk Operator ConfigManagement, di objek spec.hierarchyController, tetapkan nilai enablePodTreeLabels ke true:

   # config-management.yaml
   
   apiVersion: configmanagement.gke.io/v1
   kind: ConfigManagement
   metadata:
     name: config-management
   spec:
     hierarchyController:
       enabled: true
       # Set to true to enable hierarchical observability:
       enablePodTreeLabels: true
     # ...other fields...
   

3. Terapkan konfigurasi:

   kubectl apply -f config-management.yaml
   

   Setelah sekitar satu menit, Pengontrol Hierarki dan visibilitas hierarkis dapat digunakan di cluster Anda.

Jika visibilitas hierarkis diaktifkan, Pengontrol Hierarki akan menginstal webhook izin yang berubah untuk menambahkan label hierarki ke Pod. Untuk memverifikasi bahwa webhook ini berfungsi dengan benar:

1. Mulai workload di namespace mana pun, seperti berikut:

   kubectl run websvr --image=nginx --namespace default --generator=run-pod/v1
   

2. Periksa Pod dan pastikan Pod tersebut berisi label default.tree.hnc.x-k8s.io/depth:

   kubectl describe pod --namespace default websvr
   

   Output:

   Name:         websvr
   Namespace:    default
   # ...other fields...
   Labels:       default.tree.hnc.x-k8s.io/depth=0 # This is the Pod tree label
                 # ...other labels...
   # ...other fields...
   

3. Bersihkan beban kerja:

   kubectl delete pod --namespace default websvr
   

Pod yang ada tidak menerima label hierarki Pod; label ini hanya ditambahkan ke Pod baru. Untuk mengetahui informasi selengkapnya, lihat Batasan, nanti dalam dokumen ini.

Menggunakan kemampuan observasi workload hierarkis

Setelah diaktifkan, label hierarki Pod dapat digunakan untuk meningkatkan visibilitas beban kerja hierarkis baik di dalam cluster maupun di produk Google Cloud lainnya.

Membuat kueri Pod berdasarkan hierarki

Setiap operasi Kubernetes yang menyertakan pemilih label dapat digunakan untuk membuat kueri label hierarki Pod. Misalnya, untuk melihat semua Pod di semua namespace yang berjalan di turunan namespace default, gunakan kueri berikut:

kubectl get pods --all-namespaces -l default.tree.hnc.x-k8s.io/depth

Output berdasarkan contoh beban kerja yang kita buat untuk memverifikasi penginstalan:

NAMESPACE   NAME     READY   STATUS    RESTARTS   AGE
default     websvr   1/1     Running   0          70s

Membuat kueri Cloud Logging menurut hierarki

Cloud Logging mendukung format label yang sedikit berbeda dengan Kubernetes. Misalnya, untuk menelusuri beban kerja apa pun yang berjalan di turunan namespace default, bukan menelusuri label Kubernetes default.tree.hnc.x-k8s.io/depth, Cloud Logging mengharapkan kueri yang mirip dengan berikut di konsol Google Cloud:

resource.type="k8s_container" labels.k8s-pod/default_tree_hnc_x-k8s_io/depth!=""

Atau, Anda dapat menggunakan filter serupa di Google Cloud CLI:

gcloud logging read "resource.type=k8s_container AND labels.k8s-pod/default_tree_hnc_x-k8s_io/depth!=''"

Membuat kueri pengukuran penggunaan GKE menurut hierarki

Anda dapat menggunakan label hierarki Pod untuk mengatribusikan permintaan dan penggunaan dari pengukuran penggunaan GKE ke hierarki namespace. Untuk mengaktifkan pengukuran penggunaan hierarkis:

1. Aktifkan pengukuran penggunaan GKE reguler di cluster Anda.

2. Pastikan data ditransfer ke BigQuery. Di konsol Google Cloud, buka BigQuery.

   Buka BigQuery

3. Cari gke_cluster_resource_consumption.

   

   Contoh impor data yang berhasil ke BigQuery

4. Ikuti bagian prasyarat untuk mengaktifkan pengukuran penggunaan cluster GKE untuk mengaktifkan visualisasi pengukuran penggunaan GKE.

5. Buka Looker Studio, klik Blank Report, lalu pilih BigQuery sebagai sumber data.

6. Pilih Kueri kustom dan telusuri project ID Anda. Di kotak teks di sebelah kanan, masukkan kueri yang disesuaikan. Untuk contoh kueri kustom, lihat bagian berikut.

Contoh: total penggunaan setiap sub-pohon

Kueri ini menampilkan penggunaan untuk setiap namespace reguler, abstrak, dan hierarkis di cluster, termasuk semua turunannya:

SELECT
  REGEXP_EXTRACT(label.key, r"^[a-zA-Z0-9\-]+") as subtree,
  resource_name,
  usage.unit,
  SUM(usage.amount) AS usage_amount
FROM
  `PROJECT_NAME.DATASET_NAME.TABLE_NAME`,
  UNNEST(labels) AS label
WHERE
  regexp_contains(label.key, "tree.hnc.x-k8s.io/depth")
GROUP BY
  subtree,
  resource_name,
  usage.unit
ORDER BY
  resource_name ASC,
  subtree ASC

Contoh output sebagian:

subhierarki	resource_name	unit	usage_amount
a	cpu	detik	0,09
a1	cpu	detik	0,09
a2	cpu	detik	0
a	memory	byte-detik	6.315.303.690.240
a1	memory	byte-detik	1.355.268.587.520
a2	memory	byte-detik	4.960.035.102.720

Dalam contoh ini, penggunaan yang diatribusikan ke namespace a mencakup penggunaan namespace turunannya a1 dan a2, yang juga ditampilkan.

Contoh: penggunaan satu sub-pohon

Kueri ini menampilkan jumlah total penggunaan di namespace a dan semua namespace turunannya:

SELECT
  resource_name,
  usage.unit,
  SUM(usage.amount) AS usage_amount
FROM
  `PROJECT_NAME.DATASET_NAME.TABLE_NAME`,
  UNNEST(labels) AS label
WHERE
  label.key="SUBTREE_NAME.tree.hnc.x-k8s.io/depth"
GROUP BY
  resource_name,
  usage.unit

Contoh output untuk namespace a:

resource_name	unit	usage_amount
cpu	detik	0,09
memory	byte-detik	6.315.303.690.240

Contoh: penggunaan semua namespace dalam sub-pohon

Kueri ini menampilkan penggunaan masing-masing dari setiap namespace dalam sub-pohon tertentu:

SELECT
  namespace,
  resource_name,
  SUM(usage.amount) AS usage_amount
FROM
  `PROJECT_NAME.DATASET_NAME.TABLE_NAME`,
  UNNEST(labels) AS label
WHERE
  label.key="SUBTREE_NAME.tree.hnc.x-k8s.io/depth"
GROUP BY
  namespace,
  resource_name

Contoh output untuk namespace a:

namespace	resource_name	usage_amount
a2	memory	4.960.035.102.720
a1	memory	1.355.268.587.520
a2	cpu	0
a1	cpu	0,09

Namespace a itu sendiri tidak berisi penggunaan, sehingga tidak tercantum dalam hasil kueri ini.

Batasan pemantauan hierarkis

Berikut adalah batasan pemantauan hierarkis.

Perubahan pada hierarki diabaikan

Label hierarki Pod ditambahkan ke Pod saat dibuat dan tidak diubah setelah Pod mulai berjalan. Artinya, Pod yang dimulai sebelum pemantauan hierarkis diaktifkan tidak akan menerima label hierarki Pod.

Selain itu, setiap Pod yang hierarkinya berubah setelah Pod dimulai—misalnya, dengan menggunakan Pengontrol Hierarki untuk mengubah induk namespace—tidak akan memperbarui labelnya. Meskipun perubahan hierarki biasanya cukup jarang terjadi, jika situasi ini terjadi dan menyebabkan masalah, pastikan Anda memulai ulang semua Pod yang terpengaruh setelah mengubah hierarki.

Pod tetap dibuat meskipun label tidak dapat diterapkan

Pemantauan hierarkis tidak berlaku untuk Pod yang berjalan di namespace sistem utama seperti kube-system atau hnc-system. Namun, konfigurasi webhook itu sendiri tidak memiliki cara untuk mengecualikan namespace ini. Oleh karena itu, jika Pengontrol Hierarki mengalami masalah, pembuatan Pod di semua namespace dapat terpengaruh.

Akibatnya, daripada berisiko mengalami pemadaman layanan di seluruh cluster, jika Pengontrol Hierarki tidak dapat memproses Pod dalam waktu dua detik, webhook akan gagal dan memungkinkan Pod dibuat tanpa label. Kegagalan webhook tersebut dapat dipantau melalui server Kubernetes API dengan mencari kegagalan webhook mutasi izin podlabel.hierarchycontroller.configmanagement.gke.io.

Langkah selanjutnya

• Gunakan kuota resource hierarkis.

• Pelajari lebih lanjut tugas umum yang mungkin ingin Anda selesaikan dengan HNC di Panduan Pengguna HNC: Cara.