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.

Pengontrol Hierarki memberikan kemampuan observasi yang lebih baik ke dalam workload Anda dengan menggunakan hierarki dan namespace abstrak di . Hal ini dilakukan dengan cara menyebarkan label hierarki ke Pod Anda, sehingga tersedia untuk semua sistem yang dapat menyerap Kubernetes label, termasuk:

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

Misalnya, pertimbangkan beban kerja yang berjalan di namespace dari repositori contoh warisan 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 beban kerja di namespace yang terletak di repositori Git seperti gamestore, tetapi juga semua Namespace turunan Pengontrol Hierarki yang mungkin Anda buat sebagai turunan namespace tersebut.

Memungkinkan kemampuan observasi hierarki

Catatan: Kemampuan observasi hierarkis tidak didukung di Autopilot cluster pada saat ini.

Kemampuan observasi hierarkis disediakan oleh Pengontrol Hierarki. Untuk mengaktifkan kemampuan observasi hierarkis, lakukan hal berikut:

1. Instal Hierarchy Controller.

2. Di file konfigurasi untuk ConfigManagement Operator, 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 kemampuan observasi hierarkis dapat digunakan di cluster Anda.

Ketika kemampuan observasi hierarkis diaktifkan, Pengontrol Hierarki menginstal berubah webhook penerimaan untuk menambahkan label hierarki ke Pod. Untuk memverifikasi bahwa webhook ini berfungsi dengan benar:

1. Memulai workload di namespace apa pun, seperti berikut:

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

2. Periksa Pod dan pastikan Pod 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. Membersihkan beban kerja:

   kubectl delete pod --namespace default websvr
   

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

Menggunakan kemampuan observasi workload hierarkis

Setelah diaktifkan, label hierarki Pod dapat digunakan untuk meningkatkan hierarki kemampuan observasi workload baik di dalam klaster maupun di dalam produk Google Cloud tertentu.

Mengkueri Pod berdasarkan hierarki

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

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

Output berdasarkan contoh workload yang kami buat untuk memverifikasi penginstalan:

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

Mengkueri Cloud Logging berdasarkan hierarki

Cloud Logging mendukung format label yang sedikit berbeda dari Kubernetes. Misalnya, untuk mencari beban kerja yang berjalan di turunan dari namespace default, bukan menelusuri label Kubernetes default.tree.hnc.x-k8s.io/depth, Cloud Logging mengharapkan query yang mirip dengan yang berikut ini 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!=''"

Mengkueri pengukuran penggunaan GKE berdasarkan hierarki

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

1. Mengaktifkan penggunaan GKE reguler pemberian kuota pada cluster Anda.

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

   Buka BigQuery

3. Cari gke_cluster_resource_consumption.

   

   Contoh impor data yang berhasil ke BigQuery

4. Ikuti prasyarat untuk mengaktifkan penggunaan cluster GKE pemberian kuota guna mengaktifkan visualisasi untuk pengukuran penggunaan GKE.

5. Terbuka Looker Studio, klik Blank Report, lalu pilih BigQuery sebagai datanya sumber.

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

Contoh: total penggunaan setiap subhierarki

Kueri ini menampilkan penggunaan untuk setiap reguler, abstrak, dan hierarkis namespace 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

Output sampel sebagian:

subpohon	resource_name	unit	usage_amount
a	cpu	seconds	0,09
a1	cpu	seconds	0,09
a2	cpu	seconds	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 subhierarki

Kueri ini menampilkan jumlah total penggunaan pada namespace a dan semua namespace turunan:

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	seconds	0,09
memory	byte-detik	6.315.303.690.240

Contoh: penggunaan semua namespace dalam subhierarki

Kueri ini menampilkan penggunaan individu dari setiap namespace dalam subpohon:

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 sendiri tidak berisi penggunaan, sehingga tidak tercantum dalam hasil terhadap kueri ini.

Batasan pemantauan hierarkis

Berikut adalah batasan pemantauan hierarkis.

Perubahan pada hierarki akan diabaikan

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

Selain itu, setiap Pod yang hierarkinya berubah setelah Pod dimulai—misalnya, dengan menggunakan {i>Hierarchy Controller<i} untuk mengubah induk namespace—tidak diperbarui labelnya. Meskipun hierarki modifikasi biasanya cukup jarang terjadi, jika situasi ini terjadi dan menyebabkan masalah, pastikan Anda memulai ulang semua Pod yang terpengaruh setelah mengubah hierarki sebelumnya.

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 ada cara untuk mengecualikan namespace ini. Oleh karena itu, jika Pengontrol Hierarki mengalami masalah, pembuatan Pod di semua namespace dapat terpengaruh.

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

Langkah selanjutnya

• Gunakan kuota resource hierarkis.

• Pelajari lebih lanjut tentang tugas-tugas umum yang mungkin ingin Anda selesaikan menggunakan HNC Panduan Pengguna HNC: Petunjuk.