階層型ワークロードを監視する

Hierarchy Controller は、クラスタの階層名前空間と抽象名前空間の両方を使用して、ワークロードのオブザーバビリティを高めます。これを実現するには、クラスタのツリーラベルを Pod に伝達して、次のような Kubernetes ラベルを取り込めるシステムで使用できるようにします。

Pod に対するネイティブの Kubernetes クエリ
Cloud Logging
GKE 使用状況測定

たとえば、名前空間継承のサンプルリポジトリから名前空間で実行されているワークロードについて考えてみましょう。名前空間継承のサンプルリポジトリは次の構造になっています。

├── 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

Hierarchy Controller を使用すると、eng、rnd、その他の抽象名前空間の子孫である任意のワークロードによって生成された Pod、ログ、使用状況測定を選択できます。これには、Git リポジトリにある名前空間（gamestore など）だけでなく、それらの名前空間の子孫として作成する Hierarchy Controller の子名前空間のワークロードも含まれます。

階層型オブザーバビリティを有効にする

階層型オブザーバビリティは、Hierarchy Controller によって提供されます。階層型のオブザーバビリティを有効にするには、次のようにします。

Hierarchy Controller をインストールします。

ConfigManagement Operator の構成ファイルで、spec.hierarchyController オブジェクトの enablePodTreeLabels の値を 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...

構成を適用します。
```
kubectl apply -f config-management.yaml
```
約 1 分後に、Hierarchy Controller と階層型オブザーバビリティがクラスタで使用可能になります。

階層型オブザーバビリティが有効になっている場合、Hierarchy Controller は変更用アドミッション Webhook をインストールして、ツリーラベルを Pod に追加します。この Webhook が正しく動作していることを確認するには、以下のようにします。

次のような任意の名前空間でワークロードを開始します。

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

Pod を調べて、default.tree.hnc.x-k8s.io/depth ラベルが含まれていることを確認します。

kubectl describe pod --namespace default websvr

出力:

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

ワークロードをクリーンアップします。
```
kubectl delete pod --namespace default websvr
```

既存の Pod は Pod ツリーラベルを受信しません。これらのラベルは新しい Pod にのみ追加されます。詳細については、このドキュメントで後述する制限事項をご覧ください。

階層型ワークロードオブザーバビリティを使用する

Pod のツリーラベルが有効になると、これらのラベルは、クラスタ内と他の Google Cloud プロダクト内の両方で、階層型ワークロードのオブザーバビリティの向上のために使用されます。

階層別の Pod のクエリ

Pod のツリーラベルのクエリに、ラベルセレクタを含む Kubernetes オペレーションを使用できます。たとえば、default 名前空間の子孫で実行されているすべての名前空間の Pod をすべて表示するには、次のクエリを使用します。

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

出力は、インストールを確認するために作成したサンプルワークロードに基づいています。

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

階層ごとに Cloud Logging をクエリする

Cloud Logging では、Kubernetes とは少し異なる形式のラベルがサポートされています。たとえば、default Namespace の子孫で動作しているワークロードを検索するには、Cloud Logging では Kubernetes ラベル default.tree.hnc.x-k8s.io/depth を検索するのではなく、次に示すような Google Cloud コンソールのクエリが想定されます。

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

また、Google Cloud CLI でも同様のフィルタを使用できます。

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

階層ごとに GKE 使用状況測定をクエリする

Pod ツリーラベルを使用して、GKE 使用状況測定により取得したリクエストと使用状況を名前空間ツリーに関連付けることができます。階層別の使用状況測定を有効にするには、次のようにします。

クラスタで定期的な GKE 使用状況測定を有効にします。
データが BigQuery に取り込まれていることを確認します。Google Cloud コンソールで [BigQuery] に移動します。

BigQuery に移動
gke_cluster_resource_consumption の検出結果について確認します。
GKE 使用状況測定の可視化を有効にするには、GKE クラスタ使用状況測定の有効化の前提条件セクションをご覧ください。
Looker Studio を開いて [Blank Report] をクリックし、データソースとして [BigQuery] を選択します。
[Custom query] を選択して、プロジェクト ID を検索します。右側のテキストボックスに、カスタマイズしたクエリを入力します。カスタムクエリの例については、次のセクションをご覧ください。

例: すべてのサブツリーの合計使用量

次のクエリによって、クラスタ内のすべての正規名前空間、抽象名前空間、階層名前空間、およびそのすべての子孫の使用量が返されます。

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

部分的な出力例:

subtree	resource_name	unit	usage_amount
a	cpu	seconds	0.09
a1	cpu	seconds	0.09
a2	cpu	seconds	0
a	memory	byte-seconds	6,315,303,690,240
a1	memory	byte-seconds	1,355,268,587,520
a2	memory	byte-seconds	4,960,035,102,720

この例では、名前空間 a に起因する使用量に、その子孫の名前空間 a1 と a2 の使用量が含まれています（これらも表示されています）。

例: 1 つのサブツリーの使用量

次のクエリによって、名前空間 a とその子孫のすべての名前空間の合計使用量が表示されます。

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

名前空間 a の出力例:

resource_name	unit	usage_amount
cpu	seconds	0.09
memory	byte-seconds	6,315,303,690,240

例: サブツリー内のすべての名前空間の使用量

次のクエリは、特定のサブツリーに含まれるすべての名前空間の使用量を個別に表示します。

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

名前空間 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

名前空間 a 自体には使用量はないため、このクエリの結果には表示されません。

階層型モニタリングの制限事項

階層型モニタリングには以下の制約があります。

階層への変更は無視される

Pod ツリーラベルは、Pod の作成時に追加されます。Pod の実行後には変更されません。つまり、階層型モニタリングが有効になる前に開始された Pod は、Pod のツリーラベルを受信しません。

さらに、起動後に階層が変更された Pod（たとえば、Hierarchy Controller を使用して名前空間の親を変更した場合など）のラベルは更新されません。通常、階層への変更は非常にまれですが、変更によって問題が発生した場合は、階層の変更後に影響を受けたすべての Pod の再起動を確実に行ってください。

ラベルを適用できなくても Pod が作成される

階層型モニタリングは、kube-system や hnc-system などの主要なシステム名前空間で実行されている Pod には適用されません。ただし、Webhook の構成自体には、これらの名前空間を除外する方法はありません。したがって、Hierarchy Controller で問題が発生した場合、すべての名前空間で Pod の作成に影響が及ぶ可能性があります。

そのため、Hierarchy Controller が 2 秒以内に Pod を処理できない場合、Webhook はクラスタ全体が停止するリスクを回避するため失敗し、Pod がラベルなしで作成されます。このような Webhook の失敗は、podlabel.hierarchycontroller.configmanagement.gke.io 変更用アドミッション Webhook の失敗の有無を探すことで、Kubernetes API サーバーを介してモニタリングできます。

次のステップ

階層型リソース割り当てを使用する。
HNC ユーザーガイド: 入門ガイドで、HNC を使用して実行する一般的なタスクを確認する。