Mengamati workload hierarkis

Beta

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

Pengontrol Hierarki memberi Anda kemampuan observasi yang lebih baik ke dalam workload dengan menggunakan namespace hierarki dan abstrak di cluster Anda. Hal ini dicapai dengan menyebarkan label pohon 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 beban kerja yang berjalan dalam 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

Dengan Hierarchy Controller, Anda dapat 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 namespace turunan Hierarki Pengontrol yang mungkin Anda buat sebagai turunan dari namespace tersebut.

Memungkinkan kemampuan observasi hierarkis

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

Kemampuan observasi hierarkis disediakan oleh Hierarchy Controller. Untuk mengaktifkan kemampuan observasi hierarkis, lakukan hal berikut:

1. Instal Pengontrol Hierarki.

2. Dalam 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.

Saat kemampuan observasi hierarkis diaktifkan, Hierarchy Controller akan menginstal webhook akses masuk yang berubah untuk menambahkan label hierarki ke Pod. Untuk memverifikasi bahwa webhook ini berfungsi dengan benar:

1. Mulai beban kerja 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 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 kemampuan observasi 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 sebagai turunan dari namespace default, gunakan kueri berikut:

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

Output berdasarkan sampel 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 berdasarkan hierarki

Cloud Logging mendukung format label yang sedikit berbeda dari Kubernetes. Misalnya, untuk menelusuri workload apa pun yang berjalan di turunan dari namespace default, daripada menelusuri label Kubernetes default.tree.hnc.x-k8s.io/depth, Cloud Logging mengharapkan kueri yang mirip dengan 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!=''"

Membuat kueri pengukuran penggunaan GKE berdasarkan 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 guna mengaktifkan visualisasi untuk pengukuran penggunaan GKE.

5. Buka Looker Studio, klik Laporan Kosong, 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: penggunaan total setiap subhierarki

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

sub hierarki	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 sub-hierarki

Kueri ini menampilkan jumlah total penggunaan untuk 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	seconds	0,09
memory	byte-detik	6.315.303.690.240

Contoh: penggunaan semua namespace dalam sub-hierarki

Kueri ini menampilkan penggunaan individual setiap namespace dalam sub-hierarki 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 sendiri tidak berisi penggunaan, sehingga tidak tercantum dalam hasil kueri ini.

Keterbatasan pemantauan hierarkis

Berikut adalah batasan pemantauan hierarkis.

Perubahan pada hierarki akan diabaikan

Label hierarki pod ditambahkan ke Pod setelah 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 modifikasi hierarki biasanya sangat jarang terjadi, jika situasi ini terjadi dan menyebabkan masalah, pastikan Anda memulai ulang semua Pod yang terpengaruh setelah mengubah hierarki.

Pod tetap akan 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.

Sebagai akibatnya, bukannya berisiko mengalami pemadaman seluruh cluster, jika Hierarchy Controller 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 pada webhook akses masuk yang berubah podlabel.hierarchycontroller.configmanagement.gke.io.

Langkah selanjutnya

• Gunakan kuota resource hierarkis.

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